Design reviews for AI agent code still matter, and they belong before the pull request, because code review was never good at the job a design review does. Diego Quiroga makes the case for keeping design reviews in a recent article, and this piece extends one claim from it: that code review is the wrong place to discover the design.
Quiroga argues that agents skip the design step without removing the need for it
Quiroga opens with a team whose feature went straight from a product requirements document to code written by agents across several repositories. The code did what was asked, but reviewers saw assumptions borrowed from individual codebases and missing precautions on critical paths. They asked the author for a two-page write-up of intent and approach so they could discuss the design instead of piecing it together from separate pull requests. That slowed the feature and brought it back in line with the organization’s architecture.
His recommendation is to keep the review and make it smaller. A one or two page brief covers the problem, the chosen approach, the alternatives, the tradeoffs, the failure modes and the open assumptions. It is reserved for changes that cross service or team boundaries, touch persistent data or public contracts, carry real security or reliability risk, or are costly to undo. He is explicit that "Using an agent is not, by itself, a reason to require a review."
Code review research says understanding the change is the bottleneck
The reviewers in Quiroga’s example were stuck on one task: working out why the code was built the way it was. That task has been studied. In Expectations, Outcomes, and Challenges of Modern Code Review, presented at ICSE in 2013, Alberto Bacchelli and Christian Bird observed, interviewed and surveyed developers and managers at Microsoft and manually classified hundreds of review comments. Their abstract reports three findings that bear directly on this argument. Finding defects was the main motivation for review, yet reviews turned out to be less about defects than expected. Reviews also produced alternative solutions to problems. And understanding the code and the change was the key aspect of reviewing, with most of reviewers’ understanding needs not met by current tools.
Put those findings next to Quiroga’s example. Code review already spends most of its effort on understanding, and some of its value comes from proposing alternatives. When the design was never written down, reviewers have to do both of those jobs from the diff alone, after the implementation exists. Proposing an alternative at that point means asking someone to throw work away, which is the most expensive time to have that conversation.
Agent-written pull requests make the understanding problem larger
Coding agents change the inputs to code review in two ways that make the understanding problem worse. The first is spread. Quiroga’s example involved several plausible pull requests across multiple repositories, so no single diff held the whole design. A reviewer who sees one repository can judge the change in front of them but cannot see the dependency or inconsistency it creates elsewhere.
The second is confidence. In Do Users Write More Insecure Code with AI Assistants?, Neil Perry, Megha Srivastava, Deepak Kumar and Dan Boneh ran a user study on security tasks. Participants with access to an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure. Participants who trusted the AI less and engaged more with their prompts produced code with fewer vulnerabilities. The study used an older Codex model and focused on security, so it does not measure design quality in agent workflows. I read it as evidence for a narrower point: AI assistance can raise an author’s confidence faster than it raises the quality of the work, and code review has to absorb the gap.
A design brief moves the understanding work to where it is cheap
Seen through the Bacchelli and Bird findings, Quiroga’s brief is a comprehension tool. It hands reviewers the context they would otherwise have to rebuild from the code, at a point where changing course costs a conversation. His list of contents lines up with what reviewers struggle to recover from a diff: the constraints the author assumed, the alternatives rejected, and the failure modes accepted.
The same logic sets a limit on agent help. Quiroga says agents can help investigate options and draft the document, and that the author must be able to explain the tradeoffs without relying on the agent. The Perry study gives that requirement a reason. If assistance raises confidence on its own, a fluent agent-drafted brief can carry the same false assurance as fluent agent-written code. The test of a brief is whether its human author can defend each rejected alternative when a reviewer pushes on it.
Leaders can measure where design objections arrive
Bacchelli and Bird classified review comments by hand, and leaders can borrow that method on a small scale. Take the last few months of pull requests that crossed a service or team boundary. Sort each substantive review comment into one of two groups: comments about the implementation, and comments that question the approach itself. Then repeat the count each quarter.
If approach comments make up a growing share of code review, design discussion is arriving after the code, and the brief is worth introducing for that class of change. If approach comments are rare and incidents do not trace back to missed constraints, the existing process is working, which matches Quiroga’s own advice to reduce the review requirement where agents consistently propose sound approaches. This classification is my own proposal and does not come from his article. It costs a few hours of a senior engineer’s time per quarter.
There are boundary conditions. A small team where the same three people write and review every change may hold the design in shared memory, and a written brief would add little. Comment counts also miss the problems nobody noticed. Treat them as a prompt to investigate. They do not prove on their own whether design review is working.
Why This Matters for Engineering Leadership
Agents make implementation cheap, and code review was already built mainly for understanding a change. When design discussion moves into code review, organizations pay for it at the most expensive moment, with reviewers rebuilding intent from several diffs while the author has already committed to an approach. From an AI governance view, the brief also records who chose the approach and why, which is the record you need when an incident traces back to a constraint nobody considered. Quiroga’s two-page brief, applied only to the risky class of changes, is a modest cost against that.
FAQ
Do coding agents make technical design reviews unnecessary?
No. Diego Quiroga argues that agents shorten the path from requirements to code without removing the need to challenge the technical approach first.
Why is code review a poor place to challenge a design?
Bacchelli and Bird’s 2013 study of code review at Microsoft found that understanding the code and the change is the key aspect of reviewing, and that most of reviewers’ understanding needs were not met by tools. Reconstructing a design from several pull requests is that understanding problem at its hardest.
What should a design brief for agent-written work contain?
Quiroga proposes one or two pages covering the problem and constraints, the proposed approach, alternatives considered, key tradeoffs, failure modes and reversibility, and open assumptions.
Which changes need a design review?
Quiroga reserves it for work that crosses service or team boundaries, changes persistent data or public contracts, carries meaningful security or reliability risk, or is expensive to reverse.
Can an agent write the design brief?
It can help prepare it, but the human author has to be able to explain and defend the tradeoffs. A 2023 study by Perry and colleagues found that people using an AI assistant wrote less secure code and were more confident that it was secure.
How can a leader tell whether design review is happening too late?
Classify review comments on cross-service changes as implementation comments or approach comments. A rising share of approach comments in code review means design discussion is arriving after the code.