Rachel Laycock wrote a post called Maybe We Shouldn’t Be Reviewing All This Code. It is a response to Brian Houck, who worries that automating code review away will cost us everything else that review gives us: knowledge sharing, mentoring, collective ownership, architectural understanding.

Her answer is simple and I agree with it. Why are we waiting until code review to have those conversations at all?

I want to add one thing to her argument. Moving the conversation earlier is right. But a conversation alone does not survive the sprint.

Where I agree

Laycock’s list is hard to argue with:

  • If you want to explore alternatives, do it before you implement one of them.
  • If you want knowledge transfer, pair.
  • If you want architectural alignment, design together and encode the constraints as fitness functions.
  • If it can be linted, tested, or scanned, automate it.

And her point about scale is the one that matters most. If an agent produces ten times the code, and every line still queues up for a senior engineer to inspect, you have not built a ten-times organisation. You have built a backlog.

She also makes room for review by exception. Fundamental architecture changes, security boundaries, a big blast radius, or simply a team that says “I am not confident about this”. That is where a human should look. Not everywhere else, out of ceremony.

The part I want to push on

Her remedies are pairing, mob programming, and team design sessions at a whiteboard.

All of those are synchronous. All of them are spoken. And none of them leave anything behind.

Brian Houck’s concern was cognitive debt: the software grows while the humans responsible for it understand less and less about why it works the way it does. A whiteboard session does not pay that debt down. It creates understanding in the room, on that afternoon, in the heads of the people who were there. Six months later the whiteboard is wiped, two of those people have moved on, and the third remembers the decision but not the reason.

So we shift the judgment left, and then we let the result evaporate.

Shift the artifact left, not only the discussion

This is what the AI Unified Process is built around. The conversation moves before the code, same as Laycock proposes, but it produces something durable:

  • A requirements catalogue instead of a shared feeling about scope.
  • Use case specifications with main flow, alternative flows, and business rules, instead of a whiteboard photo in someone’s chat history.
  • An entity model instead of a schema that only the author can explain.
  • A harness layer of tests, fitness functions, and automated checks that keeps the code honest against all of the above.

The whiteboard session still happens. It just does not end when people leave the room.

What this does to code review

Once the specification exists, the review question changes.

The old question was: is this code correct? That question is nearly unanswerable at scale, because answering it means reconstructing the intent from the diff. That is exactly the work agents have made impossible to keep up with.

The new question is: does this implementation satisfy the use case, and why was it built this way? That is a much smaller question. It has a fixed reference point. And you can answer it in minutes rather than hours.

Why synchronous review still earns its place

In my experience the most effective code review is not asynchronous comments in a tool. It is the author explaining the code to someone else, out loud.

The reason it works is that explaining forces a coherent story. While you are writing code you can bridge a gap with “that is fine for now”. While you are explaining it, you cannot. The author usually finds the problem before the listener says a word.

With agent-generated code this gets more important, not less. If a developer cannot explain the code the agent produced, that is the signal. Either they did not understand the specification, or the specification was too weak. Both are useful things to learn, and an asynchronous pull request will not surface either, because a reviewer skimming a large diff nods along just as easily as the author did.

The specification gives that conversation something to be about. Without it, “explain this to me” means walking through the diff line by line. With it, it means walking through one use case.

The trade-offs

Synchronous review does not scale for free. It needs two people at the same time, and it leaves no written record. In a regulated environment where an audit trail is required, the outcome still has to be captured somewhere.

And specifications are not free either. They cost effort up front, they go stale if nobody maintains them, and a team that writes them and then ignores them has added ceremony rather than removed it. That is a real failure mode and I have seen it. The defence is that the specification has to be load bearing. If the tests trace back to it and the agents work from it, it stays true. If it is only a document, it rots.

What I take from her post

Laycock is right that we loaded too much onto the pull request: quality gate, security check, architecture review, mentoring, knowledge sharing, ownership. That worked while humans were the constraint on how fast code appeared. That constraint is gone.

Her conclusion is that engineers should understand systems, not diffs. I agree completely. I would only add that understanding a system is not something you can hold in a team’s collective memory and hope it stays there. It needs a written form that outlives the meeting.

Move the conversation left. Then write down what it decided.