Agentic Coding — Directing the Machine That Builds

It's 2:14 in the morning. A founder named Maya is sitting on her kitchen floor, laptop balanced on her knees, watching a cursor she isn't controlling.

On the screen, an AI agent is halfway through ripping out the authentication system of her three-year-old codebase. It has already read forty-one files. It found a security hole nobody on her old team ever flagged — a session token that never expired. It wrote a migration, generated a test that reproduces the bug, watched the test fail, rewrote the fix, watched the test pass, and is now updating every caller that touched the old function. Maya hasn't typed a line of code in two hours. She typed paragraphs. She described what "correct" looks like, set the boundaries, and is now reading diffs as they scroll by — approving, rejecting, redirecting.

Her co-founder, asleep in the next room, will wake up to a pull request titled "Harden session lifecycle (closes the token-never-expires bug)." He'll assume Maya pulled an all-nighter writing it. In a sense, she did. But the work she did wasn't typing. It was directing.

This is the moment Part VI is about. For the first five parts of this book, we assumed a fixed division of labor: you write the system, and the AI is a clever component living inside it — a model you call, a retriever you wire up, an agent you architect. The human holds the keyboard. The machine answers when spoken to.

Part VI inverts that. Now the machine holds the keyboard, and your job moves up a level — to specification, orchestration, verification, and judgment. You stop being the person who writes the code and become the person who decides what correct means and proves it got there. This chapter teaches the operating model for that inversion. Not the tools — you met those in Chapter 19. The mindset.

The Inversion, Stated Plainly

Let's name what changed, because most people feel it before they can articulate it.

In the old model, your scarcest resource was typing throughput. How fast could you turn an idea into working code? The bottleneck was your hands, your knowledge of the framework, the hours in the day. Senior engineers were valuable largely because they had internalized so much that they typed the right thing faster than juniors typed the wrong thing.

In the agentic model, typing is nearly free. An agent can produce a thousand lines of plausible code in the time it takes you to read a tweet. The bottleneck moves. Your scarcest resource is now specification and verification — your ability to say precisely what you want and to confirm, rigorously, that you got it.

That last sentence is the whole chapter in miniature. Leverage cuts both ways. The same machine that lets a careful builder ship ten features a week lets a careless one ship ten bugs a week, beautifully formatted, with confident commit messages. The discipline that separates the two is what we're going to install.

The Core Loop: Spec → Generate → Verify

Underneath every effective agentic workflow — no matter which tool, no matter how big the task — is one loop. Learn it once and you can drive any coding agent on the market.

THE AGENTIC CODING LOOP
==============================================================

       +----------------------------------------+
       |                                        |
       v                                        |
  +---------+      +-----------+      +---------+|
  |  SPEC   |----->| GENERATE  |----->| VERIFY  ||
  |         |      |           |      |         ||
  | say     |      | agent     |      | prove   ||
  | exactly |      | reads,    |      | it does |
  | what    |      | writes,   |      | what    |
  | "done"  |      | runs,     |      | you     |
  | means   |      | iterates  |      | meant   |
  +---------+      +-----------+      +----+----+
       ^                                   |
       |          pass: ship               |
       |          fail: refine the SPEC ----+
       |          (NOT just "try again")
       +-----------------------------------+

  Most beginners live in GENERATE.
  Builders who ship live in SPEC and VERIFY.

Look closely at the feedback arrow. When verification fails, the loop does not route back to "generate again." It routes back to spec. This is the single most important habit in agentic coding, and almost everyone gets it wrong at first.

When an agent produces the wrong thing, the instinct is to mash the button — "no, try again," "that's not right, fix it," "still broken." You're treating the agent like a slot machine, pulling the lever hoping for a jackpot. But the agent didn't fail randomly. It failed because your spec was ambiguous, and it filled the ambiguity with a guess. Pulling the lever again just generates a different guess against the same ambiguity.

When the output is wrong, the spec was incomplete. Fix the spec, not the symptom. Tell it the constraint you left implicit. "Right — and it must not change the public API." "Right — and use the existing Money type, never raw floats." Each refinement of the spec collapses a whole branch of wrong futures.

Let's walk through each stage of the loop in detail, because each one demands a different muscle.

Stage 1: Spec — Saying What "Done" Means

A specification, in agentic coding, is not a formal document. It's the gap between "make the dashboard better" and "the dashboard at /app/dashboard loads in under one second on a cold cache; the analytics query is the bottleneck; cache it for sixty seconds; do not change the UI; do not add dependencies."

The first prompt is a wish. The second is a spec. The difference is constraints made explicit and success made measurable.

A good spec answers four questions before the agent writes a line:

• What is the outcome? (Not the implementation — the outcome.)
• Where does it live and what does it touch? (Files, modules, boundaries.)
• What must NOT change? (The blast radius. The sacred parts.)
• How will we know it worked? (The test, the metric, the observable behavior.)

That fourth question is the one beginners skip and builders obsess over. If you can't state how you'll know it worked, you don't have a spec — you have a hope. And the agent will happily satisfy your hope with code that looks right and isn't.

Stage 2: Generate — Letting the Machine Build

This is the stage everyone pictures when they hear "AI coding," and it's the stage that matters least to your success. Once the spec is sharp, generation mostly takes care of itself. The agent reads the relevant files, plans, writes, runs the tests, reads the errors, fixes, and iterates — the autonomous write-run-fix loop you saw demonstrated in Chapter 19.

Your job during generation is not to watch every keystroke. It's to stay available for the moments the agent gets stuck or reaches a fork it can't resolve from the spec alone — "should refunds be prorated or full?" — and to not interrupt when it's making progress. Hovering and second-guessing a working agent is like standing over a junior engineer's shoulder narrating their typing. It slows everyone down and teaches you nothing.

The skill here is restraint paired with vigilance. Let it run — but keep one eye on the diffs.

Stage 3: Verify — Proving It Did What You Meant

Verification is where builders are made. It is the discipline that the prompt-and-pray crowd skips, and it is the entire reason careful builders ship reliable software with agents while careless ones drown in plausible garbage.

Verification has a hierarchy, from weakest to strongest:

THE VERIFICATION LADDER (weak -> strong)
==============================================================

  weakest   "It looks right."         <- reading, vibing
     |      "It ran without error."   <- the happy path lied
     |      "I clicked it once."      <- one manual sample
     |      "I read the full diff."   <- you saw every change
     |      "A test covers it."       <- repeatable evidence
     v      "The test FAILED first,
  strongest  then passed."            <- it tests the real thing

  Rule: the higher you stand on this ladder,
  the less you need to trust the agent at all.

The bottom of the ladder — "it looks right" — is where AI slop is born. Code that looks right is the agent's specialty; producing plausible-looking output is literally what a language model does. The top of the ladder — a test that you watched fail before it passed — is evidence that survives the agent's persuasiveness, because a test doesn't care how confident the commit message sounds.

Trust the process, verify the output. You don't have to read every line the agent writes if a test you trust proves the behavior. But something on this ladder has to be true before you ship, and the higher it is, the less faith you're running on.

The AI as Your Team: An Org Chart in Your Terminal

Here's the mental reframe that makes everything click: stop thinking of the agent as a tool and start thinking of it as staff.

A tool does exactly what you do with it — a hammer never surprises you. Staff have judgment, initiative, blind spots, and the capacity to confidently do the wrong thing while believing they're helping. That's precisely what coding agents are like. So the right management instincts come not from software but from leadership (the subject of Chapter 27, now suddenly load-bearing).

The most useful model is a sliding scale of seniority. The same agent behaves like a different employee depending on the task and how much you've specified.

THE AGENT-AS-EMPLOYEE SCALE
==============================================================

  INTERN          JUNIOR DEV       SENIOR DEV       STAFF/CTO
  ------          ----------       ----------       ---------
  Spell out       Give a task,     Give an          Give a goal,
  every step.     review every     outcome, trust   debate the
  Check all       diff. Catch      the how, spot-   approach,
  work.           the obvious      check the diff.  then get out
                  mistakes.                         of the way.

  trust: LOW ------------------------------------> trust: HIGH
  verify: ALL -----------------------------------> verify: SAMPLED

  WHERE an agent sits depends on:
   * how well-specified the task is
   * how reversible the change is
   * how much the domain is "common" vs. your secret sauce

A boilerplate CRUD endpoint following patterns the agent has seen ten million times? Treat it like a senior dev — give the outcome, glance at the diff, move on. A change to your billing logic that decides how much real money real customers get charged? Treat the same agent like an intern — spell out every rule, demand a test for every branch, read every line. The agent didn't get dumber. The stakes changed, so your verification changed with them.

This is what people mean when they say "AI as CTO" or "AI as collaborator" — phrases that sound like hype until you've felt them. It doesn't mean the AI is in charge. It means you've stopped relating to it as autocomplete and started relating to it as a capable colleague whose work you are accountable for. A real CTO doesn't write every line; they hold the engineering bar, ask the questions a junior wouldn't, and own the outcome. That's now your job description, with the agent as the team.

Plan-Mode vs. Auto-Mode: Two Gears for Two Risks

Every serious coding agent gives you (at least) two gears, even if it names them differently. Knowing which gear to be in is one of the highest-leverage judgments you'll make.

Auto-mode is the agent driving end-to-end: read, write, run, fix, commit, with minimal stops. It's a race car — fast, exhilarating, and unforgiving if you point it at the wrong corner. It is correct for tasks that are small, reversible, and well-trodden. Renaming a variable across forty files. Adding a log line. Writing tests for code that already exists. Fixing a typo'd import. You want speed; the blast radius is tiny; if it's wrong, git undoes it in a second.

Plan-mode is the agent thinking out loud before it touches anything — reading the codebase, proposing an approach, listing the files it intends to change and what could go wrong, and then stopping to let you approve. It's slow on purpose. It is correct for tasks that are large, architectural, or hard to reverse. Choosing a payments architecture. Designing a database schema. Anything where the wrong approach means ripping out a day of work.

WHICH GEAR? A DECISION TREE
==============================================================

            Is the change easy to UNDO?
                   /            \
                YES              NO
                 |                |
        Is it SMALL &        --> PLAN-MODE
        well-trodden?            (review the
            /     \               approach before
          YES      NO             a single line
           |        |             is written)
      AUTO-MODE   PLAN-MODE
      (let it     (touches many
       rip)        files / your
                   secret sauce)

  Cheap heuristic: if you'd want a human senior dev
  to write a one-paragraph design doc first, you want
  plan-mode. If you'd just say "go," you want auto-mode.

The cost asymmetry is the whole argument. A plan costs you a few hundred tokens and ninety seconds of reading. A wrong architecture, discovered after the agent has confidently built on it for an hour, costs you that hour plus the untangling. Planning is the cheapest insurance in software, and agents make it nearly free — which is exactly why skipping it is such a common, expensive mistake.

Reading Diffs: The Builder's Most Underrated Skill

If specification is the input discipline, reading diffs is the output discipline — and it is shockingly neglected by people who consider themselves advanced.

A diff is the precise set of changes the agent made: this line removed, that line added, this file created. In a world where you don't type the code, the diff is your primary window into reality. It is the difference between believing the agent did what it said and seeing what it actually did. The commit message is the agent's claim. The diff is the evidence.

Reading diffs well is a learnable skill with a specific shape:

• Scan the file list first. Before reading a single line, look at which files changed. Did it touch a file it had no business touching? An agent asked to fix a CSS bug that also "helpfully" edited your auth middleware is waving a red flag. Scope creep shows up in the file list before it shows up in the lines.
• Read deletions as carefully as additions. Beginners read what was added and feel reassured. The danger usually lives in what was removed — a deleted null check, a dropped error case, a guard clause that quietly vanished because the agent decided it was "unnecessary."
• Hunt for the silent assumption. The agent picked a default — a timeout, a sort order, a rounding rule, a status code. It rarely announces these. The diff is where they hide. Find them and ask: did I want that, or did I just inherit a guess?
• Watch the blast radius. A three-line spec that produced a three-hundred-line diff is not impressive. It's a question: why did such a small ask require such a large change? Sometimes the answer is good. Often it's the agent gold-plating — solving problems you didn't have.

When to Trust and When to Verify

You cannot verify everything to the maximum at all times — you'd never ship. And you cannot trust everything blindly — you'd ship disasters. The builder's judgment is allocating your verification budget to where the risk actually is.

Three dials set the budget for any given task:

THE TRUST/VERIFY DIALS
==============================================================

  REVERSIBILITY    can I undo this in seconds?
     reversible -----------------------> irreversible
     (trust more)                        (verify more)
     e.g. a log line                     e.g. a DB migration,
                                         a prod deploy, an
                                         email blast

  BLAST RADIUS     how much breaks if it's wrong?
     contained -----------------------> systemic
     (trust more)                        (verify more)
     e.g. one component                  e.g. shared auth,
                                         the payment path

  NOVELTY          has the model seen a million of these?
     common ----------------------------> bespoke
     (trust more)                          (verify more)
     e.g. a REST CRUD route                e.g. YOUR pricing
                                           algorithm, YOUR
                                           secret sauce

Turn the dials and read off the answer. A reversible, contained, common change — add a logger to one function — barely needs review; trust it, glance, move on. An irreversible, systemic, bespoke change — a migration that rewrites how your proprietary billing engine computes charges — gets the full treatment: plan-mode, a test per branch, every line read, maybe a second agent reviewing the first.

Match the verification to the risk, not to your mood. The mistake isn't trusting too much or verifying too much in the abstract — it's mismatching. Verifying a log line to death while rubber-stamping a billing migration is the worst of both worlds: slow and dangerous.

The Discipline That Separates Shippers from Drowners

We've covered the loop, the team model, the gears, the diffs, and the dials. Underneath all of it is a single distinction, and I want to make it explicit because it's the thing you'll actually live or die by.

There are two kinds of people using coding agents right now. One kind ships steadily — features that work, that hold up, that they understand and can defend. The other kind generates furiously and drowns — a rising tide of plausible code they don't fully understand, can't fully verify, and increasingly can't fix when it breaks. The drowner is faster at first. That's the cruel part. The discipline feels like friction precisely when the slop feels like speed.

Here is the watchlist. Each item is a small habit, and together they are the difference.

• Specify before you generate. The five seconds of writing a real spec saves the five minutes of redoing wrong work — and the five hours of debugging slop you shipped because you never said what correct meant.
• Route failures to the spec, not the button. When it's wrong, ask what did I leave ambiguous, not let me try again.
• Stage large work into readable diffs. If a diff is too long to review, the task was too big. Shrink it until each step is something you can actually be accountable for.
• Read deletions. The bug is usually in what disappeared.
• Keep one thing on the verification ladder true before you ship. Ideally a test you watched fail first. Never just "it looks right."
• Stay able to read the code. The instant you can't understand what the agent wrote — when you're approving on faith because the language is unfamiliar — you've stopped being the CTO and become a spectator. Slow down. Ask the agent to explain it. Use it as the learning tool it is (Chapter 19's "learning mode"), because the moment you can't verify is the moment you've lost control of your own product.

The Builder You're Becoming

Go back to Maya on the kitchen floor. What was she actually doing for those two hours?

She was specifying — naming what "hardened" meant, where the boundaries were, what must not change. She was orchestrating — letting the agent run the parts it knew cold, stepping in at the forks it couldn't resolve. She was verifying — reading every diff, and catching, in a deletion, the security hole that would have shipped. And underneath all of it, she was exercising judgment — deciding, moment to moment, when to trust and when to check, what gear to be in, whether this diff was small enough to be accountable for.

Notice what she was not doing: typing code. That skill — the one that took years to build, the one the old world rewarded — was the least of what made the night a success. The skills that mattered were specification, orchestration, verification, and judgment. Those are not coding skills. They are the skills of someone who directs builders — which is what you now are, with a fleet of tireless, brilliant, occasionally overconfident builders at your command.

That's the operating model. The rest of Part VI is what you do with it. In Chapter 36 you'll stop using the agent's tools and start building them — authoring your own MCP servers so your agents can reach into systems no one else's can. From there: agents that drive browsers and operating systems (Chapter 37), the engineering of context and memory so your agents remember across time (Chapter 38), evals as the test suite that keeps a non-deterministic system honest (Chapter 39), and finally the orchestration of whole fleets working in parallel (Chapter 40). Every one of those chapters assumes the discipline of this one. The loop — spec, generate, verify — doesn't get left behind as you scale up. It gets multiplied.

You came into this book never having written a line of code. You're leaving it able to command machines that write thousands. The keyboard was never the point. Direction was.

Chapter endnotes

1. The spec → generate → verify loop is not specific to any product. It describes the underlying control loop of every agentic coding tool — Claude Code, Codex, Cursor's agent mode, and their successors. Tools change; the loop is invariant. This chapter is deliberately tool-agnostic for that reason; Chapter 19 covers the specifics of one such tool.

2. The "route failures to the spec, not the button" principle is a restatement of a classic engineering-management insight: when a delegate repeatedly produces the wrong result, the defect is usually in the brief, not the delegate. Agents make this visible faster than humans do because they execute the ambiguity literally and instantly.

3. The "verification ladder" is a synthesis, not an official framework. Its claim — that a test you watched fail before it passed is the strongest cheap evidence available — is the same reasoning that underlies test-driven development, applied to a setting where the author of the code is a machine you must hold accountable.

4. The agent-as-employee seniority scale is the author's framing, observed across hundreds of agentic sessions. It maps the management intuition of "match oversight to risk and competence" onto the practice of delegating to coding agents, where the same agent occupies different rungs depending on the task's stakes and shape.

5. The claim that this Second Edition was itself produced through the spec → generate → verify loop is literal. The voice contract, the per-chapter theses, the anti-redundancy rules, and the ≤72-column print constraint were specifications; chapters were generated by parallel agents; an automated verification pass measured line widths, ARIA-box counts, and structural conformance before any chapter was accepted.

6. Anthropic's reported figure for Claude Code autonomously resolving the majority of its own internal bug reports end-to-end (read ticket → locate code → fix → test → PR) is discussed in Chapter 19. It is cited here not as a tool capability but as evidence for a management claim: well-specified, well-tested, common-shaped work can be delegated as a whole loop, while bespoke or irreversible work cannot.

7. The pilot/autopilot analogy reflects a well-documented phenomenon in aviation human-factors research known as automation complacency — the tendency of human monitors to disengage when automation is reliable, precisely the moments before it is most dangerous. The lesson transfers directly to agentic coding: reliability invites the inattention that causes the rare catastrophic failure.