Uncle Bob Rebuilt His Practice Around Agents. The Instruction File Went First.

Ask Robert C. Martin what happens to the rules you write into an agent’s prompt and he reaches for a film reference. Models, he told Matt Pocock in August 2026, “treat those rules in the uh Pirates of the Caribbean sense. They’re more like guidelines, you know, might follow.”

Martin has been programming since 1964. He wrote the book most engineering teams cite when they argue about code quality. Between December 2025 and August 2026 he rebuilt his own practice around coding agents, and the instruction file was the first thing he stopped relying on.

We made the case earlier today that a deterministic checker beats a paragraph in AGENTS.md. Martin arrives at the same place from fifty years of the opposite direction, and then keeps going to a conclusion we had not reached: the human disciplines do not transfer to agents. Only the human values do, and the thresholds have to be re-derived.

The technical reason the prompt decays

Martin names a cause, not a vibe. Material at the start and end of a context window carries more prominence than material in the middle, the effect the literature calls lost-in-the-middle. A long opening prompt pushes its own later sentences into the region the model weights least. A rule written near the end of a long instruction file sits in exactly that region.

His prescription follows directly. “The key with agents is to trim that initial prompt down to its absolute minimum so that you can get as much of it as possible into its priority,” he says, and “then do deterministic tools after the fact.”

The second half is where the practice lives. A deterministic tool works by putting the agent in a loop: the agent must keep changing the code until the tool reports that the code is acceptable. Nothing about that mechanism depends on the model reading a sentence and choosing to honour it. Martin adds an honest caveat. There must be a point at which enough checks slow agents below human speed and the arrangement stops paying. By his account he has not found it yet.

Values transfer. Disciplines do not.

Here is the sentence worth taking to your next standards meeting, verbatim: “it’s probably a mistake to impose a human discipline on an agent. It is not a mistake to impose human values on the agent, but there may be thresholds that we need to change.”

Martin then applies it to the discipline he is most identified with. He advocates test-driven development for humans. He will not enforce it on agents. He does not think it makes sense for an agent to alternate a line of test with a line of production code, and he reports letting agents write a function and then its test, even on runs where he instructed them to do TDD.

The value underneath TDD survives that. Code arrives with tests that constrain it. The ritual that produces that value in a human is a separate thing, and Martin’s stated reason for leaving it behind is plain: TDD is a discipline that exists because humans are wired a certain way. Agents are wired differently, so the ritual buys nothing, and by his account they drift back to function-then-test whatever he instructs.

The threshold moves with it. Martin keeps the CRAP score below four for human-written code. For agents he has “set this at six,” and says “maybe I’ll push it to eight.” His stated reason for the move is that agents carry a far larger and, in his description, perfectly accurate short-term memory. Same value, different worker, recalibrated number. I have yet to see a team ask which of its thresholds are properties of the standard and which are properties of the human who had to meet it.

Two ideas from the year 2000 that only now became affordable

CRAP is an early-2000s metric that folds test coverage and cyclomatic complexity into one score for how bad a function is. Mutation testing flips operators in the source and demands that the suite go red; a mutant that survives marks a hole in the tests. Martin says both were good ideas he set aside around 2000, because the human labour they required was impractical.

Agents changed the arithmetic. They are fast, and they do not care how boring the work is. Two metrics that were academically respectable and operationally dead are now cheap enough to run in a loop, which is why Martin picked them back up.

The same shift explains a smaller finding in the interview that deserves attention from anyone running agents on an old codebase. Messy code degrades agents, not only humans. Martin describes an agent that would change one thing, inadvertently break another, and start going in circles, and says one agent effectively gave up on a codebase. Agents are, in his phrasing, “as subject as humans are to messy code,” possibly at a different threshold. That is first-hand confirmation of one mode in the decay taxonomy rather than a new mechanism.

He throws out the plan and keeps the constraint

Martin’s rejection of spec-driven development is narrower than the headline suggests, and the distinction is the whole point.

What he rejects is heavy up-front planning. He says he has tried it with agents and “it’s always a disaster,” with the same shape every time: partway through the run the humans realise the agents cannot follow the plan, because the plan did not anticipate everything. Work stops. The plan is rewritten. The agents restart. He compares the pull toward it with the pull that produced waterfall in the 1970s, and notes that agents love to write plans and that the plans they write are elaborate.

What he keeps is executable. His own pipeline emits Gherkin acceptance criteria and a QA procedure. His dependency rules live in a persisted specification file that defines which module may depend on which and how dependencies should flow, enforced by a checker that runs at the end and that the agents must satisfy, usually by inverting a dependency, inserting an interface, or splitting a module. He also had agents build him an architecture viewer that renders the module structure and drills down into the code.

Written specifications he treats as disposable. He says his specifications are ephemeral, that he does not keep them in the repo, and that he treats the end result as the specification. He tells people not to download his tools, but to point their agents at them and have the agents build their own.

One step resists all of this. Automating the module design itself is where he is stuck. He describes interrogating agents about module structure, being alarmed by the answers, and doing the partitioning himself. On automating that, by his own account, he is “having not a lot of luck” so far. His agreement with John Ousterhout on deep modules explains part of the stakes: a small interface over a large hidden implementation suits models, because the model can read the interface without reading the implementation. Martin calls that an advantage and a danger, and adds that it holds only while the code is consistent. Agents also read the tests to work out what the system does, which is another reason the partitioning has to be right before the agents are turned loose on it. The strategic-versus-tactical framing underneath that is one we have written about separately.

What the gauntlet costs

Martin’s five stages run in order: a specifier that turns a human-written document into a Gherkin acceptance test and a QA procedure written from the point of view of a human operating the UI; a coder that writes the unit tests and the implementation; a cleaner that runs CRAP analysis and general review; a hardener that runs mutation testing and is described as merciless about coverage; and a QA agent that turns the QA document into an executable script with a deterministic result.

The figures are his own, from his own practice, with no benchmark behind them. A task a single agent finishes in about five minutes with questionable results takes about an hour through the chain. A person takes about half a day. He calls that “a factor of four factor of five improvement in productivity.”

Treat that as one practitioner’s data point for the argument that the velocity gain decays without verification in the loop, not as a measured finding. The five-minute number and the one-hour number are the interesting pair. Roughly twelve times the wall-clock cost buys the difference between output and output you can merge.

Sort your standards this week

Take your AGENTS.md, your engineering handbook, or whatever document your agents are supposed to honour. Go through it line by line and put every rule in one of two columns.

Column one: values your agents should inherit. Code arrives with tests. Dependencies point inward, and functions stay small enough to hold in one reading. These belong to the work, not to the worker, and each one needs a checker that runs in a loop, plus a threshold you have deliberately re-derived for a worker with different memory and different speed.

Column two: human disciplines you have been imposing by reflex. Ritual ordering. Commit granularity. Anything whose justification, when you say it out loud, is about how a person’s attention behaves. Those rules earn nothing from an agent and cost prompt priority that a real constraint could be using.

In my experience the second column comes out longer than anyone expects, and almost nothing in the first column turns out to be enforced by anything other than a sentence. That is the work. The harness is where governance lives, and a rule that only exists as prose is a rule the model is free to treat as a guideline.

Martin’s closing warning is about what happens to the fundamentals in the middle of all this: “The rules you throw away are the ones you’re going to pick up off the floor in a year and dust off and remember why you need them.” He argues that software is the most complicated thing humans have attempted, an idea he attributes to Dijkstra while saying himself that he expects to get the attribution wrong, and that fundamentals are how that complexity gets organised into a form both humans and models can hold, since the models are modelled after us.

This analysis synthesizes LIVE: Uncle Bob on Software Fundamentals in the Age of AI (Matt Pocock, in conversation with Robert C. Martin, August 2026).

Victorino Group helps engineering teams convert written standards into deterministic checks their agents cannot treat as guidelines. Let’s talk.