Software Development basics for Claude Code Beginners

Learn why the "Competence Trap" — getting working code from AI without the engineering judgment behind it — is the central challenge for non-programmers who run AI-generated scripts. AI tools generate code that works under ideal conditions but skip the failure modes, edge cases, and security context that engineers learn over years. This lecture explains why that gap exists and why closing it is exactly what this course is for.

Understand what actually happens when you execute an AI-generated Python script — including what permissions it runs with, what data it can access, and what consequences it can have that the original author never considered. Scripts run with your credentials, your access level, and your file system; there's no safety net built in. This foundational lecture establishes why "it worked on my machine" isn't a guarantee of safety.

Learn why AI-generated code is optimized for the "happy path" — the scenario where your data is clean, files exist, and APIs respond — and why real-world data always has exceptions that break that assumption. Blank rows, missing files, API timeouts, and unexpected file counts can cause scripts to fail silently or produce wrong output with no error message. This lecture introduces five failure-mode questions to ask before running any script on real data.

Understand why a three-line script can have irreversible consequences — including deleting folders, exposing database credentials, or overwriting years of data — regardless of how short or simple it looks. The Consequence Spectrum (Tier 1: recoverable, Tier 2: recoverable with difficulty, Tier 3: irreversible) gives you a practical framework for assessing what actually matters about any script. The length of the code is not a proxy for its risk.

Identify the seven critical questions AI tools never ask — including whether your data is sensitive, regulated, or subject to compliance requirements — and understand why the absence of a warning is not the same as reassurance. AI-generated code looks complete and confident, but it was written without knowledge of your specific environment, access level, or regulatory obligations. This lecture closes the "Confidence Packaging Problem" that makes AI output feel safe when it isn't.

Learn the four properties that make an AI-generated script genuinely low-risk: it's reversible, isolated, contains no credentials, and makes no network calls — and understand why three out of four puts you in a different risk category entirely. This framework lets you quickly distinguish safe one-off automations from scripts that need more careful review before running on real data. All four properties must apply; partial credit doesn't count.

Understand why scheduling an AI-generated script — even a working one — transforms it from a disposable tool into infrastructure with five new failure modes: no one present when errors occur, undetected failures, unexpected data volumes, growing log files, and colleagues who discover problems before you do. A script that runs once is a different risk category than one that runs nightly, even if the code is identical. Learn the idempotency requirement that every recurring script must meet before it runs unattended.

Learn the three-level approach — test_data folder, read-only operations, and dry-run mode — that catches most mechanical surprises before an AI-generated script touches your real files or production data. A ten-minute setup process, including copying edge-case samples into a test folder, prevents the most common class of accidental data damage. This technique reduces surprise; the checklist tools in later lectures cover the rest.

Recognize when AI-generated safety recommendations — Docker containers, virtual environments, IAM roles, test databases — are technically correct but disproportionate to the actual task, adding 90 minutes of setup overhead for a five-minute job. The Feasibility Pre-Flight Card (five questions to ask AI before committing to a setup) helps you calibrate advice before you start. Practical alternatives — duplicate folder, test account, zip backup, --dry-run flag — often provide the same protection in under two minutes.

Walk through the five pre-run questions every non-programmer should ask before running an AI-generated script on real data: what does it do, what data does it touch, what are the failure modes, has it been run before, and will it run again. This downloadable checklist (printable wallet size) takes three minutes and catches the most common and costly mistakes before they happen. Includes two worked examples showing exactly where the checklist stops dangerous scripts in their tracks.

Learn how a simple AI-generated CSV cleaner can quietly become an unsupervised production pipeline with hardcoded credentials — not through one bad decision, but through seven individually reasonable steps that accumulate into a high-risk system. Scope creep in AI-generated automations leaves recognizable marks: more dependencies, more users, more modifications, and security shortcuts that made sense in week one but are dangerous by month six. This lecture teaches you to see that progression before it completes.

Learn the five STOP flags in AI-generated code — hardcoded credentials, untrusted internet scripts, debug output on sensitive data, AI-generated infrastructure code, and root-level cloud credentials — that must be addressed before any use on real data, without exception. STOP means stop: not a yellow light, not a caution, not "fix it soon." Each flag has a clear, straightforward fix that typically takes under an hour to apply.

Identify the six RED flags that will cause problems under real-world conditions — file operations without a dry-run, missing error handling, database connections without parameterization, print statements outputting real data, scheduled scripts with no failure notification, and business-critical scripts without a recovery procedure. Two or more RED flags triggers a recommendation for engineering review before you proceed. Most RED flag fixes are straightforward and take under an hour.

Recognize the four categories of AMBER flags — what the script does, how it's used, its structural properties, and whether setup overhead is disproportionate — that signal an AI-generated automation is heading toward project territory. AMBER doesn't mean stop; it means this pattern commonly becomes a problem, so watch it closely. Five AMBER flags with zero RED flags is a script approaching the complexity and risk of a real software project.

Apply the full STOP/RED/AMBER framework to a realistic AI-generated script — a database pull, process, and email workflow — and learn to read the findings, score the result, and determine whether to fix and proceed or escalate to engineering review. This downloadable one-page checklist is the practical output of Modules 2 and 3, ready to use immediately on any AI-generated script. Includes the scoring guide: any STOP = stop; three or more RED = engineering review; five or more AMBER = project territory.

Understand why AI-generated infrastructure code — Terraform, CloudFormation, Kubernetes YAML, GitHub Actions — is a categorically different risk tier from regular scripts, and why running terraform plan is not a security review. Two real examples show how syntactically correct, deployable infrastructure left an S3 bucket publicly accessible for three weeks and opened an RDS database to any IP address on the internet. The rule is absolute: no AI-generated infrastructure applied without review by a cloud engineer.

Learn the six ways credentials escape from AI-generated code — hardcoded in scripts, left in git history, accidentally committed in .env files, captured in screenshots, embedded in CI/CD configuration, and exposed through service account JSON key files. Once an API key or password appears in a git repository, automated scanners can find it within minutes of the repo going public. The standard: no credentials in source files, ever — use environment variables, and rotate immediately if any credential was committed.

Description: Understand the four high-risk file operation patterns in AI-generated Python scripts — glob patterns that match far more files than intended, relative vs. absolute path confusion, shutil.rmtreeand rm -rf, and overwriting without checking — and why file operations are fast, irreversible, and broader than expected. A glob pattern intended to match 12 files can silently match 847; a relative path can resolve differently in a different environment and delete an entire project folder. Always dry-run destructive file operations before running on real data.

Discover why the print statements AI tools include for debugging and transparency are a data exposure risk — outputting real customer emails, patient data, or financial records to terminal scroll history, log files, and screen recordings. This is a RED flag for any real data and a STOP flag for regulated data (health, financial, or PII). The fix: search for print( in any script handling real data and replace actual values with counts or redacted labels.

Learn the five AI code execution trust failures non-programmers most commonly encounter — curl | bash pipelines, eval() calls, pickle file loading, high-upvote community scripts, and AI-generated infrastructure — and why social proof (1,200 GitHub stars, 800 forum upvotes) is not equivalent to a security review. Trust is a property of the review process, not the source. The standard: read every script before running it, regardless of where it came from or how many people upvoted it.

Understand what happens when an AI-generated script makes network requests — including which data leaves your machine, whether it's transmitted over HTTP or HTTPS, potential terms of service violations, and the metered API cost risk that AI tools almost never address with a budget ceiling. A script calling an enrichment API at $0.02 per record with no max_records limit can generate a $1,700 bill in a single run against 85,000 records. Always calculate expected API cost and add a max_records parameter before running any networked script on real data.

Learn how cloud IAM (Identity and Access Management) works, why AI-generated scripts default to broad permissions like AdministratorAccess to get cloud connections working quickly, and why the principle of minimum permissions — only what the script actually needs — is essential for any automation touching AWS, GCP, or Azure. Two real examples show AI-generated configuration leaving an S3 bucket publicly accessible for three weeks and opening an RDS database to any IP on the internet. Budget alerts are mandatory for any cloud-connected AI-generated script.

Apply the six-category security checklist — credentials, filesystem operations, data exposure, code trust, network and cost, and cloud IAM — as a post-coding review for any AI-generated script that touches sensitive data, cloud services, or files you can't recreate. This downloadable one-page reference isn't a comprehensive security audit, but it prevents the most common incidents covered in Module 4. Each category maps directly to the specific security risks in Lectures 17–22.

Understand why every convention in professional software engineering — version control, testing, error handling, backups, idempotency — has an origin story that is a real failure, and why those failures are now yours to avoid rather than repeat. The calibration question for this module: "What do I lose if this goes wrong — and who else does it affect?" Five fundamentals covered in Lectures 25–28 apply to any non-programmer running AI-generated automations against real data.

Learn how to use git as an insurance policy — not just a collaboration tool — so that a breaking automation at 6 AM has a "get back to last Tuesday" option, not just a broken workflow. Four minimum git habits for non-programmers: git init, git add + git commit, knowing what counts as a significant change, and git checkout for recovery. Critical: create a .gitignore before the first commit — credentials committed by accident become a permanent part of your repository history.

Learn the practical five-step testing process for AI-generated scripts — not formal unit tests, but running dangerous operations on a test_data folder with realistic samples before touching real files or production data. Realistic test data includes weird rows, special characters, and unusual formats — not clean synthetic examples — because that's what the actual data contains. The "run it twice" test reveals idempotency issues that only appear when a script operates on already-processed data.

Learn three engineering habits that make AI-generated scripts safe to operate: error handling that makes failures visible instead of silent, backups that make failures recoverable with a dated copy of source files, and idempotent design that makes running a script twice produce the same result as running it once. Silent failures look like success — a script that completes without output may have done nothing, or may have created thousands of duplicates without telling you. These three habits apply to any script that touches real data.

Apply the five permanent pre-flight questions — what does it do, what can go wrong and is it reversible, does it touch credentials or irreplaceable files, does it have error handling, and is it a one-off or recurring — as a daily two-minute check before running any AI-generated script on real data. This downloadable wallet-sized card distills everything from Modules 2 and 5 into a review that pairs with the Feasibility Pre-Flight Card from Lecture 9. Use it before every run, not just the first one.

Understand the four genuine strengths of AI code generation tools — boilerplate and scaffolding, syntax translation, known library usage, and code explanation — and why most tasks non-programmers use AI for (spreadsheet automation, API integration, data transformation, report generation) fall squarely within those strength zones. Issues don't arise because the tool is bad; they arise at the boundary between what was in the prompt and what wasn't. Security, edge cases, and cost models weren't asked for, so they aren't in the code.

Learn the eight predictable patterns where AI code generation tools consistently produce unsafe output — organized into three groups: safety omissions (happy path only, no error handling, hardcoded credentials), missing safeguards (no dry-run mode, no budget ceiling, debug print statements), and cloud-specific failures (IAM over-permissioning, infrastructure without explicit security settings). These failures are features of how models are trained, not random accidents — they're predictable, which means you can look for them in every generated script.

Understand how the same prompt sent to different AI models — or the same model at different times — can produce meaningfully different code quality, including differences in error handling, security awareness, and edge case coverage. Faster, lower-cost models have different safety characteristics than flagship models, and that quality gap is also a safety gap for non-programmers running code against real data. Four habits: know which model generated your scripts, use the highest-capability model for sensitive data, and pin to a specific version where possible.

Learn four specific additions to any AI code generation prompt — explicit error handling for named failure scenarios, environment variables instead of hardcoded credentials, a dry-run mode flag, and a max_records parameter — that consistently produce safer scripts from ChatGPT, Claude, or Copilot. A fifth prompt for cloud code asks for the minimum IAM policy the script needs, preventing over-broad permissions by default. Prompting improves the floor; the Red Flags Checklist is still the ceiling.

Apply a five-point audit prompt — checking for hardcoded credentials, missing error handling, unintended side effects, data exposure, and over-broad permissions — in a fresh AI session to catch problems in scripts generated in a previous session. Running the audit in a new session is critical: a fresh context can see the code without the original intention that caused the generator to miss the gap. AI audit narrows the problem set in 30 seconds; the checklist closes it.

Understand why AI-generated infrastructure code — Terraform, CloudFormation, Kubernetes YAML, GitHub Actions — requires an engineering review before it is applied, without exception, because the same prompt can produce meaningfully different security defaults and the consequences of misconfiguration are immediate and often irreversible. A syntactically correct, deployable S3 bucket configuration with a missing block_public_access setting left production data publicly accessible for three weeks. The rule: every time, no exceptions — "I need this reviewed before I apply it."

Learn the five transition markers that signal an AI-generated script has become a real software project — three or more people depending on it, versions in production and development, dependencies needing updates, change management required, and an operational owner who isn't the original builder. The shift from "quick automation" to "production system" happens without a deliberate decision; the engineering standards that should follow it often don't. Recognizing this threshold is correct judgment, not a sign of failure.

Apply the six-question decision flowchart to any AI-generated automation — including whether three or more people depend on it, whether it runs on schedule without you, whether it would take more than a day to rebuild, and whether it touches production credentials or cloud infrastructure — to determine whether you're in script territory or project territory. This downloadable one-page flowchart takes five minutes and tells you clearly: proceed as-is, apply full engineering fundamentals, or get IT involved now. Recognizing the transition is the skill.

Learn how to frame a conversation with IT, security, or a compliance team about AI-generated automations running against company data — including what "shadow IT" means, what the actual organizational risks are, and how to present as someone who identified a risk and took it seriously rather than someone who made a mistake. The difference between a damaging framing ("I've been running unauthorized scripts") and a productive one ("I identified a risk and I'm bringing it to the right person") is vocabulary and preparation. This lecture gives you both.

Build practical vocabulary around four compliance frameworks — GDPR (EU/UK personal data), HIPAA (US health information), PCI-DSS (credit card data), and SOX (financial reporting at public companies) — so you can have an informed conversation with a compliance team about whether your AI-generated scripts are in scope. The quick test: "What would happen if this data were leaked?" — a lawsuit, fine, or mandatory notification obligation means regulated territory. This lecture provides awareness and vocabulary, not legal advice.

Understand the four valid directions after applying the frameworks from this course — continue operating with your new safety framework in place, fix what you found in existing scripts, escalate appropriately to IT or engineering, or pause a specific automation until it can be reviewed — and learn how to choose based on what you actually found. Two character examples show what the pause this course creates looks like in practice: answering a compliance officer's question with vocabulary instead of silence, and catching credentials in a deliverable before they're sent.

Review the seven downloadable reference tools built across this course — the Feasibility Pre-Flight Card, Before I Run This Checklist, Red Flags Checklist, Security Minimum Viable Checklist, Extended Conventions Reference, Five Questions Card, and Is-This-a-Project Flowchart — and understand when to use each one. You now carry the context that normally takes software engineers years to accumulate, delivered without the years of failures required to develop it the usual way. Three next steps: run the checklist on your next script, share the course, and come back to it as a reference.