Section 14Judgment — and when NOT to use agents

The last skill is knowing when to close the laptop. Agentic coding amplifies judgment; it doesn't replace it. Four things stay yours.

Section 13 ended on an admission. Everything this guide can hand you is file-shaped — config, templates, skills, hooks, gates — and file-shaped things can be inherited, audited, and improved by machinery. What cannot be is the deciding: whether a task should go to an agent at all, how hard to look at what comes back, when to overrule a green pipeline, when to stop. No hook fires when you delegate something you shouldn't have. No template contains the moment you realise a confident answer sits outside what you can judge. That remainder is this chapter — and it's why the chapter is short. Judgment is quick to state and slow to build, and most of the building happens in your projects, not on this page.

There's also an economic reason this last skill matters more, not less, as your system improves. Every preceding section made some part of software cheaper: implementation (Section 5), verification (Section 6), even architecture review (Section 10). None of them touched the decisions — what to build, what "done" means, which risks are acceptable. Cheap code doesn't dilute those decisions; it concentrates them. When a feature costs an afternoon instead of a month, choosing the wrong feature costs proportionally more of your total effort, because choosing is now most of what you do. The salon owner's template can stamp out her gift-voucher shop at rung 4 in a minute — but nothing in the template knows whether a voucher shop is what her business needs, whether the discount rule she described is the one she meant, or whether the agent's confident paragraph about voucher-expiry law is true. Those calls were always hers. Agents just removed everything that used to hide them.

Four things that stay yours

Four responsibilities never transfer to the agent, however good the machinery gets. Each card names one; the sections that follow take the harder ones apart.

Take the first card slowly, because the other three grow out of it. Accountability is where Section 1 started the whole mindset: because you are accountable for output you didn't type, you're forced to build ways of knowing it's correct that don't depend on having typed it. Fourteen sections later, you have those ways — tests written before code, a second agent's review, demo reels, CI gates. But notice what the machinery changed and what it didn't. It changed how you know. It never changed who answers. If the booking app texts one customer another customer's appointment details, the salon owner's name is on the apology, the fix, and — if it comes to that — the regulator's form. The agent that wrote the bug has no name to put on anything. Review effort, gate strictness, rollback rehearsal: all of it is sized to that fact.

Keeping your edge — what routine assistance costs

Skill atrophy sounds like a moralising worry — the sort of thing once said about calculators — so it's worth knowing that medicine has now measured it. A 2025 study in The Lancet Gastroenterology & Hepatology followed four endoscopy centres that had introduced AI assistance for spotting polyps during colonoscopies. After a few months of routine AI use, the doctors' detection rate in procedures without the AI had fallen from 28.4% to 22.4% — roughly a fifth of the skill, gone, in months, in experienced specialists, while the tool worked exactly as intended. The researchers described it as the first real-world evidence of automation-induced deskilling tied to patient outcomes. The mechanism wasn't laziness; it was practice quietly leaving the schedule.

Translate that to this guide and the skill at risk isn't typing — nobody mourns typing. It's the skills rung 3 runs on: reading a diff and feeling where it's wrong, diagnosing a failure from its symptoms, smelling a design that will hurt in six months. Those are exactly the capacities you spend at every review and every gate, and they fade the way detection rates did — invisibly, while everything seems fine, because the agent is covering the gap. The counter-measure is the one aviation reached decades ago: schedule the manual practice deliberately. Take one small ticket a week fully by hand. When a bug appears, write down your predicted cause before asking the agent to diagnose it, then compare — a free calibration exercise. Do the high-stakes reviews yourself rather than delegating all reading to the reviewing agent. None of this slows the system down measurably. All of it keeps the judge in shape to judge.

Calibrated trust — spend attention where a mistake would hurt

The third card compresses two earlier sections into one dial. Section 6 introduced risk-tiered review — a copy tweak gets a glance; anything touching money, auth, data deletion, or migrations gets a real read plus the demo. Section 10 gave the architectural version: reversible changes run on light oversight; a one-way door gets your full attention. Trust calibration is the general principle under both: your attention is a finite budget, and both ways of spending it flat are failures. Rubber-stamping everything is rung 1 with extra ceremony. Re-reading everything is rung 2 — the bottleneck — with a subtler cost on top: attention spent evenly is attention diluted, and the dangerous change ends up getting the same tired skim as the trivial one.

Calibration is also a moving target, not a setting. Tighten the dial when anything underneath you changes: a new model version, an unfamiliar domain, a run of sloppy diffs. Loosen it where a long track record on a stable pattern has earned it — the hundredth routine endpoint doesn't need the scrutiny of the first. The failure mode to watch in yourself is drift-by-comfort: trust that ratchets looser every quiet week and never ratchets back. Let evidence move the dial in both directions, the way Section 13's DORA stability numbers were allowed to demand tighter gates.

Circle of competence — where plausible beats good

The fourth card is the quiet one, and the most dangerous to ignore. Section 0 established that a model's output is optimised to be plausible — that's the game it plays, and hallucination is what plausibility looks like when it happens to be wrong. Inside your circle of competence, plausible-but-wrong is cheap: you catch it on sight, the way the salon owner would instantly catch a booking flow that lets two customers claim one chair — she has stood at that counter for years. Outside the circle, plausible-but-wrong and genuinely-good are indistinguishable to you. The same owner reading the agent's confident, well-structured paragraph about how long she may retain customer data, or its choice of password-hashing configuration, has no red pen to grade it with. The text reads exactly as right whether it is or isn't — that is precisely what the model is good at.

At the boundary, three moves are honest. Slow down and learn until you can grade the answers — the right choice for domains you'll live in, like the basics of the law your own product is subject to; Section 9 exists because of this. Buy the judgment — an hour of a specialist reviewing the agent's data-retention setup costs less than one confidently wrong month; this is the salon owner borrowing a circle she doesn't own. Or shrink the task until it fits back inside your circle — don't have the agent build card handling you can't evaluate; let the payment provider's hosted checkout page do it, which turns "is this cryptographically sound?" into "does the redirect work?", a question she can grade. (The same instinct is behind Section 9's rule that payments are automatic real-read territory.) The one move that isn't honest: asking the agent whether it got it right. That's grading a student with an answer sheet the student wrote.

When to close the laptop

Everything above is about staying in charge while delegating. The sharper form of judgment is noticing the tasks where the right amount of delegation is none.

Sometimes the right call is to write it yourself: a tiny change where setup costs more than doing it; a novel core algorithm that is the product; a domain with life-or-safety stakes and no room for a plausible-but-wrong answer. Reaching for an agent is a choice, not a reflex — and choosing well is the real skill this guide is training.

Make the three cases concrete on the salon app. The tiny change: a typo in the confirmation SMS. Opening a session, briefing an agent, reviewing its diff, and merging costs a multiple of the forty seconds the fix takes by hand — the agent loop has a fixed overhead, and below some threshold the overhead is the task. The novel core: if the owner's real edge over every competing booking product were a scheduling algorithm that fills chairs better than anyone else's, that algorithm is the business — she'd want the thinking-hours in her own head, and the agents deployed around it: writing the test harness that proves it, building the mundane shell that delivers it, never sketching the core insight she'd then be reduced to grading. And life-or-safety: nothing in a salon qualifies, which is itself a useful reading — most of a small product's surface is safe to delegate, and the discipline is naming the parts that aren't before work starts, not discovering them in review.

There's a fourth case the three imply: when the point of the work is learning it. Delegate the thing you're trying to learn and you receive the artefact without the ability — and this guide's whole premise is that the ability, not the artefact, is what you're ultimately paid for. That's the atrophy section again, seen from the other side: hand-work isn't only maintenance for the skills you have; it's the only way to acquire the ones you don't. Someone who has never once built the thing by hand has no circle of competence to calibrate from.

One boundary case this guide has mostly set aside — adopting the workflow in an existing, already-messy codebase rather than a project born under the method — is its own climb, walked separately in Existing code: adopt and rescue.

One more class of judgment call arrives around month two, when the novelty has worn off and the product is real enough to be work: keeping yourself going. The failure modes here are the builder's, not the agent's. Scope discipline gets harder precisely because building is cheap — every session could add a feature, so the decision not to add one falls entirely on you, and the two-sentence product definition from Section 3 is the thing to reread before every "while I'm at it." A sustainable shipping cadence beats a heroic launch: a few gated features a week you can repeat for a year compound past any single sprint that leaves you flat. And sunk cost is a judgment call too — six weeks of agent-built code is still six weeks of your attention, and walking away from a product the validation no longer supports is the same skill as closing the laptop on a task, applied at project scale.

The ladder, one last time

Look back down the ladder from here. Section 1 promised that climbing it would mean building machinery, not buying intelligence, and every section since has kept that promise in a specific way. Sections 0–2 gave you the vocabulary and a working setup. Sections 3–6 built the loop: shared understanding grilled into a written PRD, plans before code, tests before implementation, verification by evidence instead of by reading. Sections 7–9 built the large invisible fraction a demo hides — the four-fifths, give or take: production readiness, a pipeline, security and law. Sections 10–13 scaled it — architecture agents can navigate, parallel workers, a protected context budget, and finally a system that makes all of it inheritable. At every step, the same trade: your effort moved away from producing the work and toward specifying, gating, and judging it. The one-line summary below isn't a slogan; it's the literal shape of that migration.

Notice, too, what the ladder does with your mistakes. Every error your judgment catches — a review that found the flaw, a trust dial that had to tighten, an afternoon lost to something a gate should have stopped — is a lesson, and Section 13 built the place lessons go: compounding engineering, the reflex of patching the template, a skill, or the global config instead of only today's repo. That closes the loop between the guide's last two sections. The system cannot judge, but it can keep every judgment you've already made; you cannot remember every lesson, but you can decide which ones deserve to become machinery. Feed that loop deliberately — end significant sessions by asking which lesson belongs upstream — and the guide keeps improving long after you've finished reading it.

The last page — and your first project

What follows this chapter is not another chapter. The guide's argument ends here; the remaining pages are the reference shelf you'll come back to while working. The day-in-the-life quick reference replays everything above as one concrete working day, one move at a time — the page to keep open in your first weeks. The glossary holds a plain-language definition of every term this guide leaned on. And the curated resources list the practitioners whose published work this guide is built from — where to go when you want more depth than a field guide carries.

The real next chapter isn't on this site at all. Section 0 gave the advice at the start, and it's worth repeating at the end: pick something small and real — your own salon app, whatever shape it takes — and run the loop on it, from the first grilling to the rehearsed rollback. A guide can hand you the ladder and the map; the climbing happens in a repository. This chapter opened by saying the last skill is knowing when to close the laptop. Second-to-last, really. The last is knowing when to open it again — on a project of your own, with the machinery from these fourteen sections waiting, and judgment growing the only way it grows: one shipped, gated, honestly-judged feature at a time.

Quick check: after fourteen sections, what actually got better — the model, or you?

You. The model never changed — the same model sits under rung 1 chaos and rung 4 systems. Everything this guide added lives around it: the machinery you build and the judgment you apply.

The whole guide in one breath: software is text files in a repository, which is why a text-reading, text-writing model in a loop of tools can build it at all — and a working demo is maybe a fifth of a real product, so the craft lives in the invisible rest. You stay accountable for output you didn't type, so you demand evidence over claims: understanding grilled into a written PRD, plans approved before code, tests written first, verification by a separate agent's tests and a recorded demo. Production means the four-fifths — readiness gates, a pipeline with staging, flags, and rehearsed rollback, security and law treated as merge gates rather than vibes. Scale comes from architecture agents can navigate, parallel workers behind deterministic gates, and a context budget you protect. Then make it a system — global config plus a golden-path template — so every project starts where this one ended. And over all of it, judgment: four responsibilities that never transfer, tasks you keep entirely for yourself, trust calibrated to blast radius, and the honesty to know where your circle ends. The exit was never reading faster. It was building the machine that makes reading every line unnecessary — and staying sharp enough to judge what it produces.