You Can Outsource Execution. You Cannot Outsource Understanding.

Broken output is cheap. You read it, you throw it away, and you've only lost a few minutes. But almost-right output is the expensive kind. It passes review and then a demo, and three weeks later somebody who understands the goal reads it properly and finds the problem.

The third study is admittedly small. Sixteen developers, and METR now calls the result "historical," so I wouldn't treat the number as settled. The part that interests me isn't the 19%. It's that these developers did the work, got slower, and came out the other side still convinced they'd been faster. METR's explanation is that the review and correction time felt like normal engineering, so nobody counted it against the tool.

A convincing answer and a correct answer look the same on the page. Somebody has to know which one they have.

Four disciplines decide whether anybody does: the spec, the verification, the environment, and the guardrails. Each one puts a human somewhere the agent can't route around.

Execution Is the Cheap Part. Understanding Isn't.

By execution I mean the activity. Decomposing the task, writing the code, drafting the email, generating test cases, running the lookup. Models are fast at that and getting faster, so hand the tasks over. But there are two things you shouldn't: the understanding and the judgment. They're the same faculty at two ends of the work.

Understanding comes first: why this task, what the real goal is, what breaks if the premise is wrong, which constraints nobody wrote down. Judgment is that same understanding applied once there's something in front of you: whether the output is right, which of the ten drafts to keep, when to break the pattern the agent defaulted into. You can't do the second without the first, which is why the agent that skipped your spec can't be trusted to grade its own work.

A better model narrows that work. It asks sharper questions, catches more of its own mistakes, needs less correcting. What it can't do is carry the consequences, and whoever carries those makes the call.

That's the trade. Hand over the execution and your senior consultants get their hours back for the parts only they can do. Hand over the understanding and the judgment as well, and you've built something fast and confident that produces the wrong outcome on a schedule.

Find the Bug in the Spec. Or Pay for It in Production.

The spec is the first discipline, and it exists to force the understanding into the open before anything gets built. Three instructions go into every spec I hand an agent, and each one is there to keep a human on the hook.

Interview me to find the real goal, not the task I happened to describe. Bias toward small, compartmentalized specs. Make me verify the key decisions explicitly, so nothing gets assumed on my behalf.

None of that's new. It's the discipline that worked when people wrote all the software themselves, and it only sounds new because two decades of "just start coding" trained a generation to skip it.

Skipping it has always been expensive. With agents it gets expensive faster, because an agent won't push back on a vague brief the way a good senior engineer will. It accepts your framing, runs, and then returns something convincing. By the time anyone works out the framing was wrong, the thing is built and reviewed, and now the argument is about sunk cost instead of the goals or outcomes.

The first instruction does the most work. I can't write the spec until I've said out loud what the goal is, and that's the step I skip when I'm in a hurry. Three questions, before the agent moves. What outcome are we after? What tells us we got it right? What tells us we got it wrong?

If nobody can answer those, the agent can't save the project. It will run faster in the wrong direction.

Done Stays a Claim. Not a Proof.

Verification is the second discipline, and it's where judgment does most of its work. Before you accept anything an agent hands back, the question is how you'd know if it were subtly wrong.

Start with the criteria, and write them down before the agent runs. Define what a good result looks like while the goal is still abstract, in numbers wherever numbers apply. Set the bar after you've seen the output and you don't have a bar. You have whatever the agent produced, plus a story about why that's fine.

Be precise about it, because vague criteria are worse than none. "Well structured" is not a criterion. "Every public function has a test that fails when the function breaks" is. You can talk your way past the first one when you're tired. The second one either passes or it doesn't.

This isn't only a code problem. A recommendation that has to cite primary sources. A model that has to reconcile to a defined total. A client email that has to name an action and a date. Same test either way: could somebody check it without asking you what you meant?

Then give the agent a format to match. This is the mechanic I use more than any other and the one I see skipped most often: hand it a past piece of work that already cleared the bar, and tell it to match that. Written criteria are easy to argue with. A known-good example isn't, and it carries the part of your standard you never managed to put into words.

Criteria still need somebody to apply them, and that's where volume becomes the problem. One reviewer reading carefully cannot keep up with ten artifacts an hour, so human review becomes the constraint. That's the bill the 45% describe when they say debugging generated code costs more than writing it. You can't read all of it, and reading none of it is how almost-right output reaches production.

So use a second model to decide where you look. On a complex build we put the finished artifact back through Codex, ask it to grade what the first model produced, and mark every place the two disagree. Most of those disagreements are noise. A few sit on the exact spot where the first model was confident and wrong. Where they disagree is where you read. The critic doesn't replace your reviewer, it tells you which three of the ten deserve real attention.

One caveat, and it's the one that gets skipped. Two models from the same family share the same blind spots. Point both at the same artifact and they will agree, confidently, and be wrong together. So "done" stays a claim, not a proof. Different families give you more useful disagreement, but don't mistake that for independence: both models can still inherit the same thin context and the same flawed spec. And when both approve something you'd have caught yourself, you've learned something about your critic, not about your output.

The Environment Is a Product. Own It Like One.

The third discipline is the environment, and it decides whether any understanding survives past Friday. Every agent conversation starts somewhere. Start from zero and your team spends the week re-explaining the same things: codebase rules, architecture, where the work stands, the constraints that only live in somebody's head.

The environment is where that stops. A CLAUDE.md or AGENTS.md at the top of the repo with the mechanics, the architecture, the project lifecycle and the working rules. A knowledge base you build by putting source documents into a raw directory and compiling them into a backlinked wiki. A registry of skills that get better the more they're used. A rules file the agent reads before it touches anything.

None of that comes from the model. It comes from the team, and the teams getting real returns treat it as a product they own: versioned, reviewed, corrected when it drifts.

The ones who don't are usually the ones telling me an agent "forgot" something obvious. It didn't forget. Nobody wrote it down.

Prompts Express Intent. Tools Enforce Boundaries.

The fourth discipline is where judgment stops depending on anybody's attention. A prompt tells the agent how you'd like it to behave, and an agent can ignore that. A guardrail at the tool level decides what it's allowed to do, and when the guardrail says no, the tool doesn't run.

This is the one most enterprise teams skip and then pay for. In practice it's a pre-tool hook with a handful of rules that apply at the moment of execution instead of the moment of intent.

Every one of those rules already exists in somebody's working agreement. The hook makes it part of the system instead, so the agent doesn't have to remember and nobody has to trust.

This is usually what separates a pilot that scales from one that gets canceled. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, and it names three causes: escalating costs, unclear value, inadequate risk controls. All three describe the same condition. Nothing at the tool level kept the agent inside the bounds the humans cared about.

Four Disciplines. One Delivery Model.

In our own delivery model these four aren't add-ons next to the work, they are the work. The Working Session at the front of an engagement is the spec discipline: senior consultants interview the goal rather than the task, and they leave with a scoped brief and written verification criteria before any code moves. The Pulse cycle covers verification. The repo and the knowledge base are products in their own right, and the guardrails sit in the delivery system, where nobody in the swarm gets around them.

The result is not faster typing. Understanding happens earlier and the judgment is sharper, because the agents took the execution and gave those hours back.

Who This Is For (and Who It Isn't)

The agents keep getting better, but nobody builds the discipline around them for you. So before the next one runs, somebody has to be able to say what good looks like and point at where it's written down, and somebody has to be willing to read the output and make the call. If nobody can do the first, the problem was never the agent. If nobody will do the second, you won't find out until production.