Picture a project that has quietly stalled for a month. Twenty or thirty pull requests, each somewhere between half and mostly done, none of them moving. Good ideas that turned into branches and then sat there. The kind of backlog that makes you stop opening the repo. The work isn’t hard, exactly — it’s that cleaning up each piece would take just long enough that you never do, and the pile grows, and the project drifts.

Now watch it clear. In a single autonomous session of roughly five and a half hours — most of it checked from a phone — the whole graveyard gets sorted. Pull requests triaged, the dead ones closed, the survivors rebased and merged, the rest re-specced and rebuilt. A month of roadmap, shipped in a day, for about a hundred and fifty dollars all in.¹

That is roughly what Theo Browne (t3.gg) documented on his project Lakebed, with a top-tier coding model driving Claude Code. And the moment you hear it, there’s a tidy explanation waiting: the model got smarter. New frontier model, better code, more gets done. File it away, upgrade your subscription, carry on.

That is the wrong lesson. It is also the most expensive one you can take away, because it tells you to keep doing exactly what you already do — just harder. Same prompts. Same max settings. Same habit of watching every diff. And you will get a modest bump and wonder what all the fuss was about.

“This model isn’t a better Opus. The difference isn’t how much smarter it is — it’s how much further it can go: end-to-end implementation, testing, verifying, and breaking work up to hand off to sub-agents.”

Read it twice, because the whole book turns on it. The gain isn’t a taller IQ. It’s range. The model can now carry a task from idea to implementation to test to verification, decompose what’s too big, and hand pieces off to other agents. If you take a prompt that worked on last year’s model and hand it to this one, you cap it at last year’s ceiling. You’re asking a model that can run a project to fill out a form.

The bottleneck moved — and it’s you

Here is the mechanism behind the magic trick. When the model could only go a short distance before needing you, you were the engine: you held the intelligence, wrote the spec, and checked the work. That was correct for the models of a few years ago. But once the model can go a long distance on its own, the maths inverts. The thing standing between you and a month-in-a-day isn’t the model’s capability — it’s the fact that you’re still feeding it one task at a time and inspecting every result. The 30× doesn’t come from the model being 30× better. It comes from removing the bottleneck. The bottleneck is you.

This isn’t a lone hobbyist’s trick, either. The “lead agent that delegates” shape is what the model builders themselves ship in production. Anthropic’s own research system “uses a multi-agent architecture with an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel.”² The unit of serious work is becoming the org, not the oracle. Your job is to run the org.

From prompter of one to orchestrator of many

Everything in this book is one role change, worked out in detail. You stop being the smartest worker in the loop and become the one who runs the loop. The job is no longer to write the answer — it’s to staff the org that writes it, and to check the org’s work. Here is the whole shift on one page; the rest of the book is the how.

We’ll come back to this table throughout — every chapter is one row, made real.

But doesn’t everyone already know AI makes you faster?

Here’s the uncomfortable part that proves the point. Handing tasks to a smarter model, naively, does not reliably make you faster. In a controlled 2025 trial, experienced open-source developers were actually about 19% slower using AI tools than without them — the opposite of what they believed was happening.³ If a better model automatically meant more output, that result is impossible. What it tells you is that the leverage was never in the model. It’s in the operating model — the org, the routing, the gates, the loop, the envelope. Get those wrong and a genius model makes you slower. Get them right and a stalled month ships in a day.

One solo developer, out-shipping a team’s month of roadmap in an afternoon, is not a story about a bigger brain. It’s a story about a small, well-run organisation — where the organisation happens to be made of agents. Let’s go build it.

If you’re no longer the bottleneck, the very next question is: who does the work? The answer is an org. Not a bigger, smarter single model — a small organisation of them, with a clear chain of command. One high-taste, high-intelligence model sits at the top as the orchestrator. It plans, it decomposes, it delegates, and — crucially — it reads back only the compressed result of what it handed out. Everything else is a bench of cheaper, faster, “good-enough” specialists it can call on.

This isn’t a metaphor borrowed from management books. It’s the shape the model builders ship. In Anthropic’s production research system, subagents “operate in parallel with their own context windows, exploring different aspects of the question simultaneously before condensing the most important tokens for the lead.”² The lead holds the thread; the workers go wide and report back thin.

In our own language, the orchestrator is a router and the workers are disposable. Think of it as a Router–Supervisor–Worker hierarchy: the master model is the privileged control plane — it routes work, escalates when a result misses the bar, and audits what comes back — while the workers stay narrow and throwaway. It fans out, then gathers only the memos. You never let the raw context of forty agents flood the one model whose judgment you actually care about.

“You stopped being the smartest worker in the loop and became the one who runs the loop. The job is no longer to write the answer — it’s to staff the org that writes it, and to check the org’s work.”

Staff by task shape, not by prestige

Here is the move that separates people who get leverage from people who just spend money. You do not send the smartest, most expensive model to every job. You send the right-shaped model. The smartest model is for judgment and taste — the work that ships, the API a human will read, the decision that’s hard to reverse. Everything else — bulk implementation to a clear spec, migrations, digging through logs, reading a giant PDF, driving a browser, staring at hundreds of screenshots — is cheaper to explore with a near-free model and escalate only if it disappoints.

Picture the bench as a barbell: the cheapest model for exploration and bulk, the smartest model for judgment, and deliberately nothing loitering in the middle. The reason to skew cheap wherever you can isn’t stinginess — it’s that the expensive part of most work is reading, not deciding. Comprehension is the cost; judgment is the cheap flourish at the end. So you pay a near-free model to do the reading and hand the compressed findings up to the one model whose taste you’re actually buying. (We’ll put real numbers on this in Chapter 6.)

The economics are why a single well-run operator now out-ships a team. A narrow specialist on a cheap model beats one mega-brain trying to do everything, because frontier models “cost 10 to 100 times more per token than smaller alternatives on the same task” and, on analysis of real production traffic, “60 to 80 percent of requests do not require frontier model capability.”⁴ Send the 70% to the cheap bench and you’ve barely touched your budget.

There’s a caveat worth naming, because it’s the thing this whole book has to defeat. Multi-agent systems “consume approximately fifteen times more tokens” and “excel at problems that can be divided into parallel strands… but are less effective for tightly interdependent tasks such as coding.”⁵ Code is interdependent. So the trick is to route the parallel, mechanical, token-hungry work out to the bench, keep the interdependent judgment in the orchestrator, and use two mechanisms — isolation and review gates — to stop the parallel work from colliding. Those are Chapters 4 and 7.

That word — shell out — matters. You’re telling the orchestrator it may reach past its own model boundary, call another model through the shell, and fold the result back into its plan. The bench isn’t decoration. It’s how the lead does ten people’s reading without spending ten people’s money or drowning in ten people’s context.

But an org can only staff itself well if it understands your language. When you say “taste,” does the model mean what you mean? When you say “this is intelligent work,” does it know which model that points to? It doesn’t — until you write it down. That glossary is the single highest-leverage page in your config, and it’s the next chapter.

Your org is staffed, but it can’t staff itself until it speaks your language. When the orchestrator decides which model to hand a task to, it’s reaching for words — “this needs taste,” “this is just mechanical,” “this is the hardest kind of problem” — and those words mean nothing to a model until you define them. So here is the single most valuable page you will ever put in your agent config, and it isn’t a list of rules.

“If you’re customising your CLAUDE.md and agents.md, the biggest thing you can do in there is effectively a glossary.”

A glossary does two things at once. It defines your axes — the dimensions you actually pick models on — and it defines your words, so the model applies those axes the way you would. Theo scored his bench on three axes he cares about: cost, intelligence, and taste. Then, and this is the part people skip, he told the model what those words mean.

His definitions were plain and reusable: intelligence is “how hard of a problem the model can handle unsupervised”; taste covers “UI/UX, code quality, API design, and copy.” Now the model has an operational grip on both — not just a score, but a meaning it can apply to a task it’s never seen. Here is the rubric itself. Read the scores as one practitioner’s felt sense of his tools, not a benchmark; the digits will be stale by next quarter, but the method won’t be.

Values are approximate (read from screen) and vary by run — the axes and the escalation policy are the durable part, not the exact numbers.

The clause that saves you from yourself

The most important lines in that config aren’t the scores — they’re the policy underneath. Defaults, not limits. The rubric tells the orchestrator where to start, not where it’s allowed to end. If the cheap model’s output misses the bar, it has standing permission to escalate to a smarter one without stopping to ask.

Judge the output, not the price tag. Escalating costs less than shipping mediocre work.

This clause has a formal name in the routing literature: cascading routing — “progressive escalation through model tiers, starting cheap and escalating only when needed.”⁶ The same source notes RouteLLM can hit “95% of GPT-4’s performance while using GPT-4 for only 14% of queries.” The academic version is blunter still: “a query should only be routed to an expensive model if all cheaper models fail to give a promising response.”⁷ Teams that tune this report “bill reductions in the 40-85% range… without a visible drop in answer quality.”⁸ Your glossary is that router, written in English, and the escalation clause is what stops you from cost-optimising your way into shipping garbage.

There’s a matching rule at the bottom of the bench: don’t reach for a model that’s too weak for real work when a near-free capable one exists. Theo’s version is “never use Haiku” — not a slur on a model, but a rule of thumb that a barely-capable option is a false economy when a genuinely capable one costs about the same. Generalise past the specific name: the floor of your bench should still be able to do the job.

The glossary is a living thing

One more tell, because it foreshadows the whole ethic of Chapter 9. Reading his own config on camera, Theo hit a line the model itself had written — a rule about cost being a tiebreaker — decided he didn’t agree with it, and edited it live: “Real changes happening on the fly.” The glossary isn’t a stone tablet you write once. It’s a document you argue with, correct, and grow. But before we get there, we have an org that’s staffed and fluent in your language. The next question is purely mechanical: how do you actually coordinate it on a real job? There are two tools, and they are not the same.

Enough theory. Let’s watch the engine run on the actual backlog — the stalled month of Lakebed pull requests from Chapter 1. This is the worked example we’ll follow for the rest of Part II: one prompt, a five-hour loop, a month of roadmap shipped. It starts with a request that looks almost too casual for what it sets off.

The model thought for a bit, wrote itself a program, ran it, and came back with a verdict that tells you exactly how much just happened:

“All 48 agents finished: 16 investigators (one per PR), each verdict then stress-tested by a Fable + Opus judge panel.”

Two different mechanisms are doing the work in that sentence, and confusing them is where most people’s multi-agent setups go wrong. There are sub-agents, and there are workflows, and they are not two words for the same thing.

Sub-agents are fan-out. Workflows are pipelines.

Sub-agents are the fan-out primitive: the orchestrator spawns N agents, one per item, all at once, and reads back their compressed memos. Five files to analyse? Five sub-agents. Sixteen PRs to investigate? Sixteen investigators, in parallel. It’s the scatter-gather move from Chapter 2, turned into a tool.

Workflows are the pipeline primitive: a programmatic script — “a big JavaScript file the model will write” — with stages and conditional gates, where the output of one stage decides what the next stage does. Stage one investigates each PR; stage two, if a PR is flagged, routes it to additional reviewers; stage three resolves. Workflows let the model “take the results of a stage and use that to dynamically cue things in a different stage.” That’s what a plain fan-out can’t do: react.

The craft of the sub-agent half is in the briefing. Anthropic’s guidance is precise: each subagent “needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries,” because “without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information.”² The orchestrator, done right, is a good manager: it hands each worker a crisp brief, not a vague gesture.

And the scale this reaches is not a toy. The same class of dynamic-workflow tooling “orchestrates tens to hundreds of parallel subagents in one session” — in one documented case, porting “roughly 750,000 lines from Zig to Rust at a 99.8 percent test pass rate in 11 days.”⁹ Sixteen investigators is a warm-up.

Stop hand-defining the reviewers

Here’s the part that used to be busywork and now isn’t. People built elaborate tooling to define reviewer archetypes by hand: this is a review sub-agent, this is an adversarial review sub-agent, this is an exploratory one. In Theo’s words: “That was all stupid and never made sense. Now it makes even less sense because the model can invent those different archetypes depending on the needs for your specific task.”

So the shape of the Lakebed triage is now clear: a workflow the model wrote, fanning out sixteen investigators, then routing every verdict into a second stage of reviewers. Sixteen investigations, forty-eight agents, one JavaScript file, ten minutes of wall-clock. Fast, parallel, and cheap.

Which leaves the only question that actually matters. Forty-eight agents finished and handed back a triage. Why should you believe them? A verdict is only worth acting on if something independent could have overturned it — and that is the entire subject of the next chapter.

Forty-eight agents handed back a triage. Here is the uncomfortable fact that decides whether any of this is usable: a model asking itself “is my work good?” is the least reliable judge in the room. It shares every blind spot that produced the work in the first place. So you never let the author certify itself. You convene a jury — and you make sure the jurors don’t all think alike.

That’s exactly what the Lakebed workflow did. Each investigator’s verdict was “then stress-tested by a Fable + Opus judge panel. 14 of 16 calls were unanimous; I resolved the two contested ones.”¹ Note the structure: an investigator proposes, a panel of different models cross-examines, unanimity is recorded, and the human is only pulled in for the two calls where the jury split.

And the two it escalated are the tell that this is real review, not theatre. One was a pair of access-control PRs where each investigator had voted the other one “trumped” — a circular verdict a single reviewer would have shipped as noise; the panel surfaced it, and the human resolved it (close both, rewrite fresh). The other was a storage PR where “the judges overrode the investigator’s ‘trumped’ 2-1.” The reviewers didn’t rubber-stamp. They disagreed, on the record, and the disagreement is where the value was.

“No single model gets to certify its own work. Quality comes from independent adversaries cross-checking until a consensus survives. You trust the jury, not the author.”

Why the jurors must not be twins

The point of a panel is not more opinions. It’s uncorrelated ones. Two copies of the same model share a blind spot; run the same reviewer twice and you’ve learned nothing you didn’t already believe. This is not a hunch — it’s the whole finding of the review-tooling world.

CodeRabbit, which reviews code for a living, is explicit about it: “models from the same family tend to share the same blind spots… Under the hood, CodeRabbit uses an ensemble of models instead of relying on a single model.”¹⁰ The academic evaluation literature reaches the same place from the other direction: panels that incorporate “multiple agents and possibly adversarial roles… achieve higher reliability and closer alignment to human consensus than a lone model,” because “an error that one agent overlooks might be caught by another.”¹¹

So the panel is heterogeneous on purpose. On Lakebed it wasn’t just a Fable + Opus judge panel; it was that panel plus a bank of external review bots — Bugbot, Macroscope, CodeRabbit — plus GPT-5.5 (via Codex) available as an outside-vendor perspective. Different builders, different training, different blind spots. When the model reports “CI is fully green — Verify, Bugbot, Macroscope all pass,” that green isn’t one opinion repeated; it’s several genuinely independent ones failing to find a problem.

In our own language, what makes this trustworthy is an adversarial closer — something mechanically independent that can say no to the producer. Without it, a loop of agents just “converges on its own reflection” rather than on reality; that’s the correlated-checkers pitfall, and running the same judge twice walks straight into it. The rigour of the system is proven by what it’s willing to reject — the John West principle: it’s the fish it throws back that tells you the catch is good.

This is also why an adversarial council of models beats one very smart model working alone. When Andrew Ng benchmarked agentic workflows, a debate-and-review loop lifted a coding task’s success rate from roughly 48% to 95% — not because any single model got smarter, but because the disagreement did the work. That’s consistent with the broader evaluation research, where “panels of LLM evaluators can outperform single judges on both accuracy and cost… diverse juror pools mitigate blind spots.”¹²

A jury this thorough sounds ruinously expensive — sixteen investigators, a judge panel, three external bots, all running for hours. It wasn’t. The whole month of work came in around a hundred and fifty dollars, and the single biggest reason is the most counter-intuitive setting in this entire book. It’s next, and it’s the one people refuse to believe.

This is the chapter I’d ask you to sit with even if you skip the rest, because it’s the one that contradicts your instinct and costs you real money every day you get it wrong. When you have hard work and a reasoning dial that goes to max, every fibre says turn it up. Don’t. For sustained agentic work, you want high — and the tiers above it will hand you worse code at a wildly higher bill.

“High is way smarter. I know that sounds like I just made a mistake. I didn’t. xhigh and max end up second-guessing themselves too much because they run in loops… the result is often worse code that is way overdone, with way too many changes for the simple thing you’re asking, at a cost absurdly higher than it should have been.”

The dial is designed to seduce you. “They look so enticing — the fancy gradient when you hover over it, like a slot machine begging you to put another coin in.” Resist it. To understand why, you have to understand what the effort setting actually controls, because almost everyone has it backwards.

Effort is per step, not per job

The near-universal assumption is that a higher effort tier lets the model “work longer” or “solve harder problems” — that max can grind through something high can’t. That is not what the dial does. Reasoning effort is a per-tool-call budget: how hard the model thinks on each individual step. It does not govern how many steps it can take or how long it can run.

Follow the mechanism through. A real task — say a feature that takes five hundred agent steps — is five hundred small decisions, most of which are mundane: read a file, rename a symbol, add an import, run a check. Turn the dial to max and the model does not take more steps. It thinks harder on every step, including the four hundred that never needed it. You’re paying a deep-reasoning premium to have trivial changes agonised over, and the agonising doesn’t just cost money — it produces bloat, second-guessing, and “way too many changes for the simple thing you asked.” Tellingly, even the “ultra” option “uses high under the hood; it just spins up a ton more of them.” The vendor’s own default is high. There’s a reason.

And this isn’t one practitioner’s superstition. The research on test-time scaling now documents the same curve: extending thinking “initially boosts model accuracy, but performance degrades subsequently with prolonged thinking” — a non-monotonic effect the authors call overthinking.¹³ More reasoning is not more capability; past a point it’s less.

What does the top tier actually cost you?

The price is not subtle. In one controlled study, the same agent run at high effort resolved 29.1% of issues at a cost of $1,400, versus 21.0% at $400 for low — and, decisively, generating two low-effort solutions and picking the less-overthought one “nearly matches the performance of high-reasoning configurations while reducing computational costs by 43%.”¹⁴ Two cheaper tries beat one expensive over-thought one. That’s the battle of the AIs from the last chapter, showing up as a cost strategy. Vendor documentation puts the top tier at “10x+ token usage vs low.”¹⁵ You are paying an order of magnitude more to make simple changes worse.

The way to hold this in your head: whoever wins isn’t whoever spends the most tokens — it’s whoever spends them inside an apparatus that knows what to reject. The load-bearing word is discipline, not burn. More effort with no external check is just an agent over-adding code, ballooning a diff, polishing a thing that didn’t need polishing. High plus a review gate beats max plus hope, every time.

The other half: route the reading down

Effort is one lever on the bill. The other is where the tokens go. The expensive part of most work isn’t the deciding — it’s the reading. Digging through logs, chewing a giant PDF or implementation spec, driving a browser, staring at hundreds of screenshots over an hour of computer use: that’s where the tokens pile up, and none of it needs your best model. Route that comprehension work to a near-free model and have it report the findings up. Spend your frontier tokens on judgment, not on scrolling.

Put the two levers together — run at high, and route the token-hungry reading to the cheap bench — and the numbers stop looking like a frontier-model bill at all.

The whole month of Lakebed work — every investigator, judge, external bot, and implementation agent — came in around a hundred and fifty dollars, and neither subscription broke 40% usage (the cheap-model sub sat near 15%). Of the two levers, one is nearly free to pull: moving off the top effort tier, in Theo’s words, “probably cut your bill by half or more just by making that one change.”

Cheap, reviewed, and correct. Which finally makes the wild-sounding part rational: you can set a goal and walk away for five hours. That only works because of one more idea — the guardrail — and it’s next.

Everything so far has been setup. Here is where the month becomes a day. You stop writing prompts and start setting a goal: not “do this task,” but “keep going until this whole body of work is done, and here’s your standing permission to do what it takes.” Then you close the laptop.

The plan lived in a TODO.md — about 131 lines, “like a month of work in a to-do MD.” The goal pointed the model at it and set the completion criterion: every box ticked. Then: “Goal acknowledged. And then it ran for five hours. And every time I checked GitHub on my phone, more code had landed.”

“You stop writing prompts and start setting goals: keep going until every box is done; you may branch, rebase, merge, and close. Write the plan to a TODO, hand over standing permission, and let it run for hours while you sleep.”

That TODO.md is doing more than listing tasks. It’s the external memory that lets a long run stay coherent. The pattern is well documented now: for a long-horizon Codex run, the key technique was “durable project memory… the spec, plan, constraints, and status in markdown files” plus continuous verification — the direction being “less babysitting, more delegation with guardrails.”¹⁶ Stateless workers, a stateful file the run can revisit, checkpoints committed as it goes, and an explicit definition of done. That’s the skeleton of every multi-hour agent run worth trusting.

Worktrees: parallelism that can’t collide

If the model is going to run many implementation agents at once, they need somewhere to work without overwriting each other. The answer is git worktrees: each agent gets its own checked-out directory over a single shared object store, so their edits are physically isolated. Worktrees have become “the dominant isolation primitive for running multiple AI coding agents in parallel,” and they have a lovely property — they “defer the conflict problem to the PR merge stage.”¹⁷ Which is exactly where your adversarial review gate from Chapter 5 already lives. Isolation up front, reconciliation at the gate.

So the machinery is: a goal, a durable TODO, worktree-isolated agents running in parallel, and a merge gate of independent reviewers. It ran for five hours and cleared a month of backlog. And now we reach the objection everyone has been holding since Chapter 4.

“You let it merge to main? That’s insane.”

It sounds insane — a model merging its own code to main whenever it decides the work is good enough. It isn’t, and the reason is the single most important sentence in the book about safety. Autonomy is not made safe by watching every diff. It’s made safe by capping what a mistake can reach.

“Production deployments are still a human in the loop. This is just the staging deployments that happen when you merge to main. The model cannot ship or touch prod — it can use staging for basically whatever it wants.”

This is why AI-assisted coding is such a favourable place to be autonomous in the first place. The work produces a reviewable artefact (a PR), it can run asynchronously, and — critically — it routes through governance you already have: code → PR review → CI/CD → rollback. You’re not inventing new controls for the AI; you’re pouring its output into the pipeline your team already trusts. The industry consensus on autonomous pipelines lands in exactly this place: “AI agents can move quickly in lower-risk environments, but anything that can materially impact… production should pass through human review” — because of “the blast radius when something goes wrong in production.”¹⁸

The loop ran. The code landed on main and out to staging. And then something surprising happened with the bill of your attention: the cheap part turned out to be getting the work done. The expensive part — the part that now deserves most of your effort — is proving it’s right. That’s the next chapter.

The loop finished. A month of work sat on main, deployed to staging, reviewed by a jury of bots. You might think the story ends there — the code is written, ship it. It doesn’t. Because the most revealing line in this whole account isn’t about how much got built. It’s about where the money actually went.

“I burned way more tokens trying to verify the work than I burned getting the work done. And there was nothing to change — which means I’m not pushing hard enough.”

Read that again, because it’s the whole shift in one sentence. When producing work becomes cheap, checking it becomes the job. The verification wasn’t a rubber stamp: he personally stress-tested staging, then spun up fresh agents to try the new features and re-try the old ones, ported apps built the old way to see how they held up, had other agents diff production against main to catch everything that had changed, and spread the work across other machines to de-risk it. More effort went into breaking the work than into making it.

This isn’t a quirk of one workflow; it’s becoming a law of the field. Jason Wei’s “verifier’s rule” states that “the ease of training AI to solve a task is proportional to how verifiable the task is” — which makes verification the lever the whole enterprise now turns on.¹⁹ The practitioner translation is exactly the move above: you “have other people tasked with breaking the product and hunting for bugs.”²⁰ Only now the people breaking it are also agents — and the human’s role, as the model builders themselves put it, becomes “providing strategic oversight at key decision points” while agents work for hours or days.²¹

Notice one detail that matters: the verifiers are fresh agents, not the ones that wrote the code. A clean context, with no attachment to the implementation and none of its blind spots, is a better checker — the same independence principle from Chapter 5, and the same scatter-gather move from Chapter 2, now pointed at the finished work. Verification is itself a fan-out.

The clock is a diagnostic

Here’s a second instrument that falls out of all this autonomy, and it’s nearly free. The time an agent takes to solve something is a probe for the health of your codebase. Not the diff — the effort. How long it took, and how many files it had to touch, tells you where the good and bad parts of your architecture live.

The receipts make it concrete. A back-navigation bug got fixed in two minutes twenty — so fast it was almost suspicious; the model started reasoning about a “drawer” behaviour, which prompted the very useful question “do we even have a drawer anymore?” A scroll-jump bug, by contrast, took over an hour and a half, and that set off alarms: “That scares me. I’m not going to blindly merge this code. I’m going to go put a lot more time in here.” Same agent, same day — the effort it expended was the signal, and it pointed straight at the parts of the codebase that needed a human’s attention.

And the punchline of the whole verification pass? After all that stress-testing, “there was basically nothing that needed to be fixed.” A lesser engineer would call that a win and ship. The right read is the uncomfortable one: nothing to fix means you didn’t push hard enough. The frontier of useful work has moved from can the model do it to can you find where it’s wrong — and if you can’t, aim higher.

That completes the engine: glossary, org, gates, effort, goal-loop, blast radius, verification. Two things remain. First, none of it sticks unless you own it — and the fastest way to fail is to copy someone else’s config. Then, the part that’s bigger than code: the same operating model runs almost anywhere. Part III.

You could take every config in this book, paste it into your repo, and get worse results than you have now. That’s not a paradox — it’s the whole point of this chapter. The glossary, the skills, the routing rules: they aren’t an expert’s setup you copy. They’re a living document you grow from your own failures. The scarce human skill in this new world isn’t writing code. It’s authoring and evolving the config — and talking to your agents.

A skill is a description plus a body it loads on demand

Start with the mechanics, because they shape the craft. A skill is just two things: a description the model always sees, and a body it only pulls in when it decides to use the skill. “The model only sees the description of the skill until it uses it — and once it uses it, it pulls in all the rest of the text.” So the description has to carry everything the model needs to decide whether to reach for the skill; the body carries the how.

And the body is grown, not authored in one sitting. Watch how a real skill matures. Theo’s Codex-review skill kept hitting a small, maddening failure: when Codex found no issues, the parent model got confused and re-ran the whole review. The fix wasn’t a redesign — it was a line appended after the failure: if Codex finds nothing, say that clearly and name the review target it inspected. “That ended up reducing the issues I had a ton.”

That’s the loop, and it’s almost embarrassingly simple: hit a failure → ask the model how to prevent it next time → tell it to cut its suggestion in half → paste the survivor into your config. “Most of this wasn’t me having an epiphany on how to get it all right. I spent about half an hour getting it mostly working, then as I ran into problems I’d go back and tell it to cut them in half and put them in here.” Your config is a scar tissue of every problem you’ve actually hit — which is exactly why someone else’s config is worthless to you.

Don’t copy it. Learn it. Break it. Own it.

This is why there are no download links. “You need to set this up for yourself. Don’t just blindly copy-paste my stuff… Do it. Learn it. Change it. Experiment. If you’re scared of going in and editing these files, you need to get over that.” The fear of breaking your own tooling is the thing to defeat first — because a config you’re afraid to edit is a config that stops evolving the day you inherit it. Screenshot someone’s setup if you like, hand it to a model, and say “help me build my own version of this.” Then start breaking it.

There’s a reason ownership matters this much rather than being a motivational aside. Even at the frontier, delegation is partial. Anthropic’s internal study found a 67% increase in merged pull requests per engineer per day after Claude Code adoption — and, in the same breath, that engineers could “fully delegate” only 0–20% of their tasks; AI augments judgment, it doesn’t replace it.²² That 80–100% of judgment that stays with you? It lives in the config. The leverage isn’t in the code the model writes; it’s in the taste you encode into how it works.

“Don’t inherit someone’s config — grow your own from your own pain. The goal isn’t to copy an expert’s setup. It’s to influence your agents to have the same psychosis as you.”

“Have the same psychosis as you” is a joke that’s completely serious. Your config is where your standards, your pet peeves, your sense of what “good” looks like get transferred into a machine that will then apply them a thousand times while you sleep. Copy a stranger’s and you’ve installed their taste, their blind spots, their psychosis. The whole point is that it should be yours.

You now own the machine and you know how to grow it. One question is left, and it’s the biggest: what if this was never really about code at all?

Everything you’ve read used pull requests and CI pipelines as its stage, so it’s easy to file it under “a clever way to code.” That undersells it. Nothing in the operating model is really about code. Strip the software away and what’s left is a portable pattern: staff an org, encode your judgment, gate the work with independent adversaries, run it cheaply and autonomously inside a bounded lane, then verify harder than you built. That pattern runs almost anywhere.

Here is the whole engine as a checklist you can carry into any domain. Each line is a chapter you’ve already read; the point is that they compose into one repeatable move.

The same shape, three other jobs

The variants below aren’t new frameworks — they’re the same doctrine, re-aimed. Watch the artefacts stay identical while the domain changes.

The test for whether any job fits is the same three questions every time: is the work batchable (can it run off the clock?), reviewable (does it produce an artefact a jury can inspect?), and cage-able (can you bound the blast radius?). If yes, it’s a clean lane — deploy aggressively. If a job forces real-time answers with irreversible, public consequences and no reviewable artefact, that’s the wrong lane; redraw the boundary before you automate it.

One honest boundary. Multi-agent orchestration shines on work that decomposes into parallel, reviewable strands, and it’s weaker on the tightly interdependent kind.⁵ The doctrine’s answer is not to force it — it’s to decompose the work into reviewable artefacts until it fits, which is exactly what “ship the artefacts” means. And wherever the stakes are real, the guardrail holds: keep humans in the loop for production and irreversible decisions — that gate is “an investment in safety,” not a tax on speed.²³

The bottleneck used to be typing

Come back to where we started: a project stalled for a month, twenty or thirty half-finished ideas going nowhere, shipped in a single afternoon for the price of a nice dinner. It was never a story about a bigger brain. It was a story about a small, well-run, adversarial organisation — that happened to be made of agents — and a person who stopped doing the work and started running the org.

“The bottleneck used to be typing. Now it’s judgment — knowing what to build, whether to trust it, and where the architecture is lying to you. We spent five years learning to prompt one model. The model turned into a team. Time to learn to lead it.”

That’s the shift, and it’s already happened whether or not you’ve reorganised for it. The people getting a modest bump from the new model are still prompting one genius at max effort and watching every diff. The people doing a month’s work in a day rebuilt the operating model around it. The gap between them isn’t talent or budget. It’s an org chart, a glossary, a gate, a goal, and a blast radius.

The sources behind every external claim in this book — and a note on which figures are the practitioner’s own — follow in the References.