When AI coding works brilliantly. And when it fails.

Why balance is the whole point of this lesson CORE

There are two lesson-plans you could write about AI coding, and neither of them is honest on its own.

The first is the enthusiasm lesson. It describes the brilliant moments — the afternoon an agent wrote a hundred lines of working code in five minutes, the two-hour debug it collapsed into twelve seconds — and leaves the student thinking the tool is universal. That student over-relies, hits a silent failure on real work, and sometimes does not recover their confidence from the first big miss.

The second is the warning lesson. It describes every failure mode, catalogs every hallucination, and leaves the student thinking the tool is unreliable. That student under-uses, avoids the tool on the exact tasks where it would have saved them hours, and does not develop the directing muscle at all.

The honest lesson is a map of both zones. There are kinds of work where a good coding agent, directed by a skilled student, is so much faster and so much more thorough than solo human programming that the comparison is not close. There are kinds of work where the same agent produces confident, plausible, wrong output that will cost you hours if you merge it.

Becoming a good director of AI coding is almost entirely about learning which zone a given task lives in — before you start — and adjusting what you ask for and how you review it accordingly.

The four zones where AI coding is brilliant CORE

These are the situations where a frontier coding agent, directed well, can reliably do the work faster and more thoroughly than a skilled human programmer working solo.

Bounded, well-specified changes. A bug with a reproducible symptom; a feature with a clear acceptance test; a refactor where the target pattern is explicit. The tighter the specification, the better the agent does. “Fix the .tar.gz compound-extension bug so that test_compound_extensions passes” is a bounded change. The agent thrives on it because it can locate, plan, write, and verify against a clear signal.

Mechanical transformations across many files. Rename a variable across 47 files. Add a docstring to every public function in a module. Convert a codebase from one logging library to another. The agent’s cost to touch the 47th file is the same as its cost to touch the first; the human’s cost rises with attention fatigue. On mechanical work, humans are the ones who make small inconsistent mistakes, and the agent — paired with a test suite that catches the consequences — is more thorough.

Exploring an unfamiliar codebase. “Where in this project does login happen? What files would I need to change to add two-factor auth?” A good agent can read, search, and summarize structure in minutes that would take a new human programmer a full afternoon. The agent is not always right — and the student still checks the claims — but as an exploration partner it saves real time on the most expensive part of working in someone else’s code.

First drafts of structured artifacts. Tests, scaffolds, configuration files, boilerplate, README sections that follow a standard shape. The agent has seen thousands of these; it produces a draft in one pass that would take a human fifteen minutes to type. The draft will not be perfect. It will be a 60–80% version that you edit rather than a blank page you start from, and that is genuinely valuable.

Notice what these four have in common: the goal is legible (you can state it in one sentence), the signal is concrete (there’s a test, a runnable output, or a pattern to match), and the reference material exists (there are lots of similar solutions the agent has seen before). When those three hold, the agent is in its strong zone.

The eight tripwires — where AI coding fails CORE

Eight failure modes show up often enough that each deserves its own name. Some you saw in Lesson 3.3 as diff-review failure modes; here we are naming the situations that produce them, so you can predict them before the diff exists. We call them tripwires because each one is a cue to slow down, not a reason to stop using the tool.

Tripwire 1 — Unfamiliar libraries or new-in-the-wild frameworks. Agents are trained on code that existed months or years before they were released. A library that came out last month, or whose API broke in its latest major version, is a zone where the agent confidently uses the old API — which does not exist anymore. The cue: the agent is calling functions the docs do not mention, or imports that throw errors. The move: paste the relevant doc page into the prompt yourself.

Tripwire 2 — Tasks that require running code to know the answer. “Will this query be fast on a 10-million-row table?” “Does this cleanup script handle files whose names contain emoji?” The agent cannot know without running. The move: if your agent’s tools include code execution, make it run something; if not, assume its answer is a guess dressed as a fact, and plan to verify yourself.

Tripwire 3 — Work where the goal is not legible. “Make the code nicer.” “Improve performance.” “Refactor this.” These prompts produce confident, sweeping, and scope-crept diffs, because the agent has no concrete signal to stop. The move: make the goal legible. “Reduce the cold-start time from 3.2 seconds to under 1 second” is a goal you can verify; “make it nicer” is not.

Tripwire 4 — Your own unfamiliarity with the codebase. If the agent writes a change to a part of the project you have never looked at, you cannot tell whether the change makes sense in context — you don't know what file the change should be in, what behavior the existing code already has, or what an unexpected side effect would look like. The agent may still do good work; you cannot know that it did. The move: have the agent walk you through the relevant files before it edits — "Before you change anything, read these files and tell me in plain English what they do, what depends on them, and what could break if their behavior changed." The agent does the reading; you get the context you need to review its edit honestly.

Tripwire 5 — Load-bearing deletions and rewrites. Any prompt that starts “remove this” or “rewrite this” is a tripwire by default, because deletions are the hardest diff category to review (Lesson 3.3, failure mode 3). The agent is not especially worse at writing removals than additions — but the review cost on the human side is higher, and that asymmetry is what produces silent-deletion bugs. The move: ask for additions rather than rewrites where possible, and when you do ask for a rewrite, have the agent first summarize what the existing code does so you can check against that summary.

Tripwire 6 — Security-sensitive or safety-critical code. Authentication, encryption, permission checks, payment flows, code that touches PII, code that will run against a production database. Frontier models are adequate here and sometimes excellent, but the cost of a silent mistake is multiplied. The move: treat these diffs as first-draft only — never merge a security-sensitive change without a second human pass, even if you read the diff carefully.

Tripwire 7 — When your tests do not actually test the thing you care about. The verify step is only as strong as the test suite. If the test passes because it never exercises the failure mode that motivated the fix, you are in the plausible-wrong zone (Lesson 3.3, failure mode 4). The move: before you accept “tests pass” as a merge signal, confirm the tests exercise the goal, not just the old behavior.

Tripwire 8 — Autonomy drift over a long session. In a multi-hour session, agents (and directors) drift. The agent starts proposing larger changes. The director starts approving quicker. The six-hour mark looks nothing like the thirty-minute mark. The move: reset on purpose. End sessions early when the goal is met, and when a session stretches past two hours, start a fresh Code-tab session (or a fresh CLI run, if that's where you're working) with a clean prompt. Long sessions are not free; they are a quiet tax on review quality.

Matching the task to the zone CORE

Most students, when they first learn the zone map, try to use it in reverse: “Is what I want to do in the brilliant zone? If yes, go.” That is a rookie move. Good directors do the opposite — they use the map to adjust the work to fit the zone the tool is strong in.

Three habits come out of this reframe.

Make the goal legible before you prompt. If your first draft of a prompt is “clean up this code,” stop. Ask yourself: what specifically is wrong with it, and what specifically would “clean” look like? Even the exercise of rewording to “extract the duplicate date-parsing logic into a helper function used by the three places that currently duplicate it” moves the task one zone closer to brilliant.

Convert rewrites into additions when you can. Instead of “rewrite this module with better error handling,” try “wrap the three calls in this module that can raise IOError with explicit error messages, and keep the rest unchanged.” You moved a sprawling rewrite into a bounded addition.

Build the verify signal you wish existed. If the work is in a tripwire zone because your tests don’t cover the goal, add the test first. Seriously. Ask the agent to write a failing test that would only pass if the bug were fixed, run it (watch it fail), then ask for the fix. The test gives you a concrete signal, and the agent is now doing bounded, well-specified work instead of vague “fix this” work.

These three moves are the quiet difference between a student who uses an agent well and a student who hits the same frustrations every week.

Where this gets you wrong — and the clean recovery path CORE

Even with the best zone-mapping discipline, you will merge a bad change sometimes. The goal of this lesson is not zero mistakes; it is fewer mistakes, caught earlier, with a clean recovery path.

The clean recovery path has three parts.

Small commits. Commit the agent’s work in small increments. A 20-line commit is easier to revert than a 500-line “afternoon’s worth of edits” commit. Git is very good at undoing one commit; it is not good at surgically undoing a quarter of one.

A working baseline you can return to. Before starting serious directed work on a repo, confirm main (or whatever your baseline branch is) is clean and known-good. If you break it, git checkout main✓ should bring you home — that command returns your working files to the last clean state of the baseline branch. This is why Lesson 3.2 had you work from a clean starter-repo clone; the starter repo is always exactly one git reset away.

Willingness to say “I was wrong to merge this, reverting.” The hardest recovery habit is the one where you notice, a day later, that the cute change you merged is doing something subtle and bad, and you revert it rather than defending it — git revert <commit> creates a new commit that undoes a named earlier one without rewriting history. Agents do not have ego about their diffs; you should not develop one about theirs.

These three practices are not glamorous. They are what separates a student who can productively use AI coding tools at scale from one who will lose a weekend to an unrecoverable merge.