Why Most Code Reviews Should Never Happen

Code reviews have been one of the most successful quality practices in software engineering.

Long before AI coding agents existed, they solved a very real problem. Software was becoming increasingly complex, testing was often incomplete, and developers were working on parts of the system they did not fully understand. Having another engineer inspect a change before it reached production was often the cheapest and most effective way to catch mistakes.

But code reviews were never just about finding bugs. Over time they became the place where teams enforced coding standards, verified architectural decisions, shared knowledge, discussed requirements, identified security concerns, challenged design choices and helped junior engineers grow. An activity that started as a quality control mechanism gradually accumulated responsibilities from almost every other part of the software delivery process.

This made perfect sense. A developer would spend hours or days writing a relatively small amount of code. The volume was manageable. Another engineer could realistically inspect every meaningful change, understand the implementation and provide thoughtful feedback before the code was merged.

The economics worked because the effort required to review the code was significantly smaller than the effort required to produce it.

Fast forward to the AI-Assisted Engineering era and those economics have flipped. The effort required to review the code is now often substantially higher than the effort required to produce it. That is why code reviews are rapidly becoming a fundamental bottleneck.

One of the key ideas behind Cycle-Driven Engineering is that, if we want AI-Assisted Engineering to work in practice, we should aim to eliminate as many code reviews as possible. I am aware that this sounds like a terrible idea at first glance. The goal is not to lower quality standards. The goal is to move the different responsibilities traditionally carried by code reviews into other layers of the engineering loop, where they can be handled more effectively and more consistently.

It is also important not to treat the elimination of code reviews as a dogma. It is an idealized target state that we will never fully reach. There will always be situations where human review is the right tool for the job.

What matters is having a framework that continuously pushes us in that direction. Every responsibility that can be removed from a code review and enforced elsewhere should be removed. Every review that can be automated should be automated.

The end goal is not to eliminate every review. The end goal is to ensure that the reviews that remain are the ones that genuinely matter.

Organizational Alignment

The first responsibility that should leave traditional code reviews is organizational alignment. Many review comments are not actually about code quality. They are attempts to enforce architectural decisions, coding standards, team agreements or domain boundaries that were never made sufficiently explicit.

In healthy engineering organizations, those decisions should not live in the heads of a few senior engineers. They should be visible, documented and accessible to everyone involved in the delivery process.

This creates an environment where engineers can make autonomous decisions within clearly defined boundaries. Architects and senior engineers still define those boundaries, but we need to change where those boundaries are enforced.

Instead of discovering architectural violations during a code review, we create teams where both humans and AI agents already understand the rules before implementation begins. The goal is not to review whether developers followed the rules, but to make the rules sufficiently clear that following them becomes the default outcome.

Shifting Reviews Left

Once the organizational foundations are in place, the next step is to move as much review activity as possible into the Planning Layer of Cycle-Driven Engineering.

One of the most common review comments in software engineering is some variation of: “This should be implemented like we did in feature X” or “We already have a pattern for this elsewhere in the system.” In traditional development, these comments appear after the code has already been written. The reviewer identifies the inconsistency and asks for changes.

Cycle-Driven Engineering takes a different approach. If we already know how a particular problem should be solved, why are we waiting until the review stage to communicate that information?

Part of that knowledge belongs in the Constraint and Context Layers. Architectural decisions, coding standards, implementation patterns, examples and reusable skills can be captured in CLAUDE.md files, agent skills, rules and other forms of persistent guidance. Every review comment that occurs repeatedly should eventually become a constraint, an example or a piece of reusable context.

The more interesting shift happens in the Planning Layer. One of the core ideas behind Cycle-Driven Engineering is that plans should not stop at requirements and acceptance criteria. A good implementation plan should already contain many of the decisions that would traditionally emerge during review. If a repository should be used in a particular way, the plan should contain a concrete example. If a specific architectural pattern should be followed, the plan should demonstrate it. If certain edge cases need to be handled, they should already be identified before implementation starts.

The same applies to testing. Whether a team follows TDD or a more traditional workflow, the tests that need to exist should be defined and validated during planning. By the time implementation begins, both the expected behaviour and the mechanisms used to verify that behaviour should already be clear.

Viewed through this lens, a surprising amount of modern code review activity turns out not to be review activity at all. It is architectural guidance, implementation guidance and test design arriving after implementation has already started.

The Quality Layer

Once architectural guidance, implementation patterns and test expectations have been moved into the earlier layers of the loop, another large category of code review comments starts to disappear naturally.

Historically, reviewers spent a significant amount of time validating behaviour. They checked whether edge cases had been considered whether the implementation satisfied the requirements and whether the tests covered the intended scenarios. In many organizations this became one of the primary purposes of code review.

Cycle-Driven Engineering pushes these activities into the Quality Layer.

By the time implementation starts, the expected behaviour should already be documented in the plan, together with the tests required to validate it. As implementation progresses, those expectations are continuously verified through automated tests, integration checks, static analysis, security scanning and other quality gates. Confidence is built incrementally throughout the loop rather than concentrated in a single review activity at the end.

This approach scales particularly well in AI-Assisted Engineering. Human reviewers can only process a limited amount of code and must infer behaviour from implementation details. Automated verification evaluates the behaviour directly and does so consistently regardless of whether the implementation was produced by a human or an AI agent.

The Quality Layer is therefore responsible for proving that an implementation satisfies the expectations established earlier in the cycle. Every defect detected automatically is one less defect that depends on a reviewer noticing it. Every expectation that can be verified systematically reduces the amount of information that has to be carried by individual engineers.

As organizations mature their quality practices, code reviews gradually stop being the primary mechanism through which quality is enforced. Their role becomes narrower and more focused, which turns out to be exactly what we need for the final category of reviews that remains.

Deciding What Still Deserves Review

At this point, an obvious question emerges. If organizational alignment is handled through explicit constraints, implementation guidance is captured in context and plans, and correctness is continuously validated through the Quality Layer, what remains for a human reviewer to do?

While thinking about this problem, I found myself repeatedly coming back to Birgitta Böckeler’s article “To vibe or not to vibe”, published on Martin Fowler’s website. The article proposed a framework for deciding when vibe coding is acceptable and when additional oversight is justified.

Although it was not intended as a code review framework, I believe the same reasoning can be adapted to determine when a code review is justified after the responsibilities traditionally carried by reviews have already been redistributed across the various layers of Cycle-Driven Engineering.

The framework evaluates three dimensions:

Probability: How likely is the implementation to contain defects or incorrect assumptions?

Impact: What are the consequences if those defects reach production?

Detectability: How likely is it that existing safeguards will identify the problem before users are affected?

These three dimensions can then be used to determine whether a human review adds enough value to justify its cost.

Probability	Impact	Detectability	Review Strategy
Low	Low	High	No review
Low	Medium	High	No review
Medium	Medium	High	No review
Medium	High	Medium	Review required
High	High	Medium	Review required
High	High	Low	Review required

A useful way to think about this matrix is that the earlier layers of Cycle-Driven Engineering continuously push changes towards the top of the table. Constraints reduce ambiguity. Plans reduce implementation variance. Automated quality controls increase detectability. Every improvement made to those layers reduces the number of situations where human review remains the best available control.

Closing Thoughts

AI-Assisted Engineering has changed the code review equation. The response should not be to abandon quality controls, nor to insist on preserving existing processes unchanged. The opportunity is to rethink where and how those controls are applied. Constraints, context, planning and automated verification are all capable of carrying responsibilities that historically accumulated inside code reviews simply because there was nowhere else to put them.

Viewed through that lens, the goal is not to eliminate code reviews. The goal is to make them sufficiently rare that every remaining review addresses a problem worth a human’s attention. When that happens, reviews stop being a routine administrative step in the delivery process and become what they should have been all along: a deliberate investment in managing risk.

FAQ

Why are code reviews becoming a bottleneck in AI-assisted engineering?

The economics that justified code review have flipped. Reviews used to cost far less effort than writing the code, because a developer produced a small, manageable volume of changes. With AI coding agents, the effort to review the code is now often higher than the effort to produce it, so review becomes the constraint on delivery.

Does eliminating code reviews mean lowering quality standards?

No. The point is to move the responsibilities code reviews accumulated, organizational alignment, architectural guidance, implementation patterns and behaviour validation, into earlier layers of the engineering loop where they can be enforced more consistently. Quality is built incrementally through constraints, planning and automated quality gates rather than concentrated in one review at the end.

How does Cycle-Driven Engineering reduce the need for review?

It redistributes review work across layers. Coding standards and architectural decisions live in constraints and context such as CLAUDE.md files and agent skills. Implementation patterns, edge cases and tests are decided during planning. Correctness is checked continuously in the Quality Layer through automated tests, static analysis and security scanning, so fewer issues are left for a human to catch.

When is a human code review still justified?

When the value it adds outweighs its cost. Adapting Birgitta Böckeler’s framework, a review is warranted when the probability of defects is high, the impact of a defect reaching production is high, and detectability through existing safeguards is low. As the earlier layers improve, more changes move into the “no review” zone and the reviews that remain are the ones that genuinely matter.