AI Made Code Faster. The Team Stopped Reading It.
The team added three AI reviewers after human reviews fell to almost zero. Who could still explain how the code worked?
- A team made reviews optional on a greenfield product; the wait disappeared, and so did most human review.
- Multiple review agents can find defects, but they do not create a person who understands the design and can defend or maintain it.
- Keep mandatory human review for authentication, money, data, public interfaces and irreversible operations.
Five months earlier, every pull request on one developer’s team had at least two readers: the engineer submitting the change and one or more peers. Then the team started a greenfield product and made code review optional to move faster.
Most changes were still reviewed at first. But shipping in minutes instead of waiting hours was addictive. Over the following months, human reviews fell to almost zero.
The team added an automated stage in which three agents reviewed the code under different instructions and reconciled their findings. The unresolved problem was ownership. Who had followed the implementation closely enough to explain the design, answer questions and repair it later?
Optional review becomes the rule on the busiest day
An optional control works only when time is available. As deadlines tighten and AI increases the number of pull requests, review is the first step teams skip. Generation gets faster; human judgment does not scale at the same rate.
In another developer discussion, a reviewer described receiving AI-heavy pull requests with 1,000 to 2,000 lines and obvious repetition. The strongest response was not to review every flawed segment on the author’s behalf. It was to return the pull request as not ready until its owner had reviewed it.
The bottleneck has moved. Producing code is cheap. Turning it into a reviewable change—small enough to reason about, tied to one intent, tested against real failure modes—still takes engineering work.
Three AI reviewers still do not create an owner
Automated review can identify duplication, missing tests, common security mistakes, type errors and scope drift. Different models or reviewer prompts can catch issues another pass misses.
| Question a human must answer | Why automation is insufficient |
|---|---|
| What business problem does this solve? | Repository context rarely settles customer impact and priority |
| Why was this design chosen? | Several implementations may work, but the team must maintain one |
| What data can be damaged? | Production states and recovery order require operational knowledge |
| Who can repair it? | A generating model has no on-call responsibility or organizational memory |
| When should it be rolled back? | Rollback depends on product metrics and customer impact |
Automated review belongs before human review, not in place of it. Let machines remove mechanical noise so people can focus on design, authorization, data integrity and recoverability.
Shipping code and understanding code are different outcomes
A 2026 controlled study measured both productivity and code ownership. Participants using an AI assistant were less able to answer technical questions about the code they had implemented, with a reported 12.5% reduction on the ownership measure.
Anthropic’s analysis of roughly 400,000 Claude Code sessions found that people made about 70% of planning decisions but only 20% of execution decisions. Users usually decided what to build while Claude decided more of how to implement it. That workflow makes a deliberate comprehension step more important, not less.
The GraalVM project turns the principle into policy. Using a coding assistant does not remove review, testing, licensing or ownership requirements. Contributors are expected to understand the submission, answer reviewer questions and maintain the change.
Review by consequence, not by line count
| Risk | Examples | Human review |
|---|---|---|
| Low | Documentation, copy, isolated tests, internal tooling | Automated checks plus author review may be enough |
| Moderate | UI state, internal APIs, noncritical batch jobs | One peer checks intent, boundaries and tests |
| High | Authentication, authorization, billing, public APIs, migrations | Two reviewers including a domain owner |
| Critical | Deletion, encryption, access control, irreversible actions | Approve execution, rollback and observability before release |
Line count is a poor proxy. One configuration line can expose an authentication boundary, while 500 generated test lines may not alter production behavior. Money, permissions, data, public contracts and reversibility matter more than diff size.
Make the PR owner explain four things
- Intent: the problem it solves and what it deliberately does not change.
- Critical path: where input enters and which state changes.
- Failure modes: the inputs, permissions, network conditions or data states that break it.
- Recovery: what to observe after deployment and when to roll back.
The owner may use AI to draft that description, but must answer follow-up questions and make the repair decision. If the owner cannot explain those four points, the change is not ready for review.
Preserve speed by shrinking the change. Set acceptance criteria and risk before implementation, ask the agent for one intentional change at a time, remove mechanical defects automatically, then apply the human review required by the risk tier.
Code review preserves the team’s memory
Review is not only a bug-catching ceremony. It distributes knowledge of why the system looks this way, who understands it and where an incident investigation should begin.
The faster AI produces code, the more important that function becomes. Unread code may pass today’s tests. When it fails later, the time saved during generation returns as incident cost if nobody can explain the system.
AI can write the pull request. The person whose name is on it must still explain the intent, failure modes and recovery. A change nobody can explain is not finished code.
Frequently asked questions
Does every line of AI-generated code need human review?
No. Documentation and isolated tests may need only automated checks plus author review. Authentication, authorization, billing, migrations, deletion and other high-consequence changes need mandatory human review.
Can several AI code reviewers replace a human reviewer?
They can remove mechanical defects and flag common mistakes. They do not create a person who owns the design, understands operational impact and can decide when to roll back.
What should the owner of an AI-assisted pull request explain?
The owner should explain the intent, critical execution path, failure modes and recovery plan in their own words. If they cannot, the change is not ready for review.
How can teams keep code review from becoming the new bottleneck?
Split generated changes by intent, use automated checks first, and apply deeper human review according to money, permissions, data, public contracts and reversibility.