Companion to Understanding Is All You Need
None of this is "use AI less". All four are about deciding, once and in advance, which changes a human still has to hold in their head, and then making that decision run itself.
Practice one
A small program that runs when a pull request opens, looks at what it touches, and decides whether a human needs to read it. You build it once. It runs on everything after that.
Cannot page anyone.
On rails you already built.
Blast radius, not difficulty.
Routed by what a change can break, not by how hard it was to write. Runs on open, gates the merge.
The problem it solves. Right now nearly every pull request gets the same treatment, usually a quick skim, whether it is a typo fix or a schema migration. That spends attention on changes that never needed it and leaves none for the ones that did. Sorting first is what makes the remaining attention go to the right place.
What it keys on. The signals are already in the diff and none of this needs a model: which paths were touched, whether it crosses a service boundary, whether it reaches auth, money, migrations or infrastructure, and whether it can be undone. Start with paths. That alone gets you most of the way.
Define the rules once, calmly, and let the machine apply them every time. This is the whole reason to automate it. Deadline pressure retroactively demotes everything to skimmable: a human classifying at 2am always classifies it as fine. A rule written on a Tuesday afternoon does not.
Every organisation draws its own lines. What is routine in your codebase is a blast radius in someone else's. The point is not to copy these three buckets, it is that the lines exist somewhere executable rather than in people's heads.
Not a new idea, just an unapplied one. NASA has sorted every system containing software into six classes, A through F, for decades. The same shape exists as DO-178C levels, ISO 26262 ASIL and IEC 62304 classes.
What does not exist: across fourteen research passes, no engineering organisation was found publishing a blast radius matrix for AI assisted changes. The Linux kernel comes closest, but sorts by how much was machine generated, which is a different axis.
Practice two
The what survives in the code. The why lives in the thread that produced it, and we throw that away every time.
Looks fine. Approve.
The diff is a workaround. Nothing in the code says so.
For anything the classifier routes to a human, reading the diff is not review. Read what was tried and rejected, and what the agent was told not to do.
You cannot check the tests instead. Eighty six programmers judging AI written assertions were 74 percent accurate on the correct ones and 49 percent on the incorrect ones, equally confident either way.
Let me argue against myself, because this idea has failed before.
Capturing design rationale is a forty year old research field, and it mostly failed. A 2006 paper asks why the pile of papers describing rationale systems is so much bigger than the pile describing successes. The answer was always that capture was disruptive: somebody had to stop and write it down.
That objection is now dead, and that is the whole point. With an agent the conversation is a byproduct of the work. The capture cost is near zero for the first time. Keeping it is no longer discipline, it is just not deleting it.
The kernel already allows for it: its generated content documentation lists including your prompts in the changelog as a way to be transparent.
The behaviour predates the idea: the DevGPT dataset collected 29,778 shared prompt threads already linked by developers to their own commits and pull requests, in 2023.
Honest limit: raw transcripts are weak alone. "yes, do that" carries nothing. Keep a compact decision record for routine work, full threads only for what the classifier flags and for incidents.
Practice three
That person is you, and they will have forgotten. Not because anything went wrong, but because the reasoning was never theirs.
Understanding does not fail loudly. No test goes red when the last person who knew why a thing exists stops knowing. You find out at two in the morning.
So carry enough for a stranger to reconstruct the decision: what problem it solves, what else was considered, what it touches, and what breaks if you delete it.
The gap is measured. Across 11,048 closed agentic pull requests, 33 percent left no observable decision rationale at all, and only 35.7 percent of rejections were clear agent failures.
And nothing checks afterwards. Tools exist that quiz you on a pull request and block the merge, but every one gates before merge. Nothing returns to code shipped three months ago to ask whether you still understand it.
Practice four
Buckets, gateways, reviews and commits should have the same shape everywhere. A rule that varies per team is a rule nobody can enforce.
If one team's third bucket is another team's auto merge, you do not have a policy, you have preferences. And once an agent moves work between repositories, which is now normal, the weakest standard becomes the organisation's standard.
Write it as a procedure, not a principle. "Be careful with risky changes" is unenforceable. A numbered sequence an agent and a human both follow survives the person who wrote it leaving.
The kernel shipped exactly this. Linux 7.2, released 16 August 2026, includes a nine step procedure an AI assistant must follow to find and fix a bug. Not guidance, a sequence.
And note what AGENTS.md is not. Real adoption, tens of thousands of projects, but it constrains an agent's context, not its flow. What to know, not what order to work in.
The proof this is worth doing
All of this costs time, so it is fair to ask what it buys. Meta measured its own automated review layer across more than 535,000 reviewed changes.
Hold that against the other large telemetry set. Across 22,000 developers on 4,000+ teams, median time in review rose 441 percent, merges with no review at all rose 31 percent, and incidents per pull request more than tripled.
Both are real telemetry from real organisations, pointing opposite ways. The visible difference is whether the organisation built a review layer. That is not proof of causation, and one of the two has an arithmetic error in its own abstract you should not quote from. But it is the closest thing to evidence that this is worth the effort.
And there is a measured price for skipping it. Across a year of agentic contributions, each ten point rise in a project's no review rate tracked roughly 6 percent more corrective maintenance, plus more security weaknesses. The work does not disappear. It moves.
Speed up the parts that cannot hurt you. Slow down the parts that can. Decide which is which before you start, not at two in the morning.