What review is for when the author cannot explain itself
Code review was always half a conversation with a person who held the intent. Remove the person and most of the ritual stops working. What survives is narrower and more valuable than what we lost.
The most useful thing I ever did in a code review was ask “why did you do it this way” and get an answer that changed my mind. That exchange is the load-bearing part of the practice, and it depends entirely on there being someone at the other end who knows why.
An agent does not know why. It can produce a plausible reason on request, which is worse than silence, because a plausible reason is indistinguishable from a real one and stops the enquiry.
My position: with agentic authorship, review has to stop being an interrogation of the author and become a conformance check against a written intent. Teams that do not make that shift explicitly end up doing archaeology instead, and archaeology does not scale.
What the conversation was actually doing
Strip the ritual back and human review was doing four jobs at once.
It checked correctness, which tests do better when they exist. It checked fit with the system, which is judgement and remains irreducible. It transferred knowledge, mostly downward from senior to junior. And it recovered intent, by asking the author what they were trying to achieve so the reviewer could evaluate whether the change achieves it.
That fourth job was invisible because it was free. The author was right there. You could ask.
Now consider a pull request written by an agent from a two-line ticket. The reviewer opens it and has no source of intent at all. The ticket is thin. The commit message describes what changed, not what for. The agent will answer any question you put to it, fluently, and its answer is a reconstruction rather than a recollection. There is no fact of the matter it is reporting.
So the reviewer does archaeology. They read the diff, infer a purpose, then assess the change against the purpose they just invented. This is a closed loop. Almost anything internally consistent passes it, which is exactly the failure mode that gets described as context blindness: output that is coherent on its own terms and wrong against the repository, referencing APIs that do not exist and violating conventions nobody wrote down.
Review with a human author
- Intent is recoverable by asking
- Disagreement produces a real argument
- The author defends or concedes
- Reviewer learns the system
Review with an agent author
- Intent must exist before the change, in writing
- Questions get fluent reconstruction
- Nothing pushes back on a wrong premise
- Reviewer learns the diff, not the system
The shift: intent moves upstream or it does not exist
If intent cannot be recovered from the author after the fact, it has to be fixed before the fact. That is the whole of the change, and everything else follows from it.
Practically, it means the acceptance criteria stop being a formality on the ticket and become the reference document the review is conducted against. The reviewer’s question changes from “why did you do it this way” to “does this satisfy what we said done means, and does it fit the system”. The first half of that becomes largely mechanical. The second half is where the human belongs.
There is evidence this pays. Controlled studies have found human-refined specifications cut errors by up to 50 percent. I read that as a statement about where the judgement gets applied rather than about specification as a genre. The same person spending the same care produces a better outcome earlier in the process than later, because earlier the decision space is still open and later they are adjudicating a fait accompli.
What review is for now
Three things, and I would resist adding a fourth.
Fit. Does this change belong in this system in this shape. Does it duplicate an abstraction that exists two directories away. Does it introduce a second way of doing something we already do one way. No amount of specification precision answers this, because it depends on holding the whole system in your head, and that is the thing you cannot generate.
Consequence. What can this reach. Not how big is the diff, but what happens if the assumption inside it is wrong. This is where senior attention has the highest yield and where I would spend all of it if forced to choose.
Evidence. Is there a durable record of what was checked and against what. Under the EU AI Act, which came into enforcement on 2 August 2026, Article 12 obliges automatic logging of events relevant to risk and traceability, tamper-evident and retained for six months. Whatever you think of the regulatory framing, the underlying demand is one engineering leaders should have made of themselves years ago: an approval that leaves no artifact of what was verified is not evidence of anything.
The trap of asking the agent
I want to name this directly because it is becoming standard practice. Teams are wiring up flows where the reviewer asks the agent to explain its change, and the explanation goes in the pull request description.
The explanation is generated from the diff. It will be coherent, it will be well written, and it will describe a rationale that the agent did not have when it produced the code. It cannot report a decision process it did not run. What you get is a persuasive account fitted to the artifact, and persuasive accounts are precisely what a reviewer under time pressure will accept in place of reading.
I would rather have a pull request with no description than one with a confident invented one. At least the empty one does not consume the reviewer’s scepticism budget.
Where this breaks down
Human intent recall was never as good as I am implying. Ask an engineer why they made a choice three weeks ago and you frequently get a post-hoc rationalisation too. The difference between that and an agent’s account is one of degree, not kind. My defence is that the degree matters a great deal, and that a human can say “I do not remember” and an agent structurally cannot.
Specifications precise enough to review against are expensive and often nobody’s job. The person writing the ticket is measured on throughput of tickets, not on downstream review cost, and the benefit of their precision lands in somebody else’s team. This is the real reason the upstream fix stays rare, and it is organisational, not technical. Any argument that ends in “just write better criteria” has skipped the hard part.
Over-specification produces its own failure. Criteria detailed enough to be mechanically checkable can be satisfied to the letter while missing the point entirely, and an agent optimising against them will find that gap reliably. Specification does not eliminate judgement, it relocates it. Sometimes it relocates it to a worse place.
Some agent output genuinely is explicable. Where the change is a direct transformation of a well-specified input, the account of why is close to complete and treating it as fabrication is paranoid. The distinction I am drawing is sharpest for open-ended design work and softest for mechanical change.
And the knowledge transfer loss is not obviously replaceable. I have said it needs a deliberate replacement. I am not confident the replacements work as well. Reading a senior’s comments on your own code was a remarkably efficient teaching mechanism and nothing I have seen since matches it.
The takeaway
Code review was built around an author who could be questioned. That premise is gone for a growing share of changes, and the practices built on it degrade into inferring a purpose from the artifact and then checking the artifact against the purpose you inferred.
Intent has to be written down before the work starts, or it does not exist. What review retains is fit, consequence and evidence, which is a narrower job than review used to do and a more honest description of what a senior engineer can actually add at that point in the process.
If you take one thing into next week: pick five recent agent-authored merges and try to establish, from the record alone, what each was supposed to achieve. Whatever you cannot answer, the reviewer could not have answered either.