Humans should review less code

Code review is becoming a bottleneck.

AI-assisted teams can produce changes much faster than humans can review them. If every generated line still waits for the same manual process, implementation gets faster while delivery does not. The queue simply moves from writing code to approving it.

We need to reduce the amount of code reviewed by humans while maintaining the same quality bar. The answer is not to stop caring about quality. It is to stop treating human attention as the only way to produce it.

Our default is simple: AI reviews the change first. The project then decides whether the change needs a human based on consequence, not size. Tests and static analysis handle repeatable quality checks. People stay responsible for security, sensitive business logic, architecture, and the parts of the system where being wrong is expensive.

Scope matters. This policy assumes an experienced team, reliable automated gates, and non-safety-critical product software whose failures are observable and recoverable. It is not a career-development model, and it does not replace the assurance process required for regulated or safety-critical systems.

Review less code, understand the system better

Code review has always done two jobs.

The obvious job is finding defects before they ship. The less obvious job is retaining architecture knowledge inside the team. Research at Microsoft found that modern review also produces knowledge transfer, team awareness, code understanding, and alternative solutions. A good review forces someone other than the author to understand why the change belongs in this part of the system, which assumptions it relies on, and what will happen when it fails.

That second job matters more as agents write more code. One of the biggest risks in an AI-heavy development platform is becoming dependent on AI not only to implement the system, but also to explain and debug it. At that point the team may own the repository without really owning the architecture.

Human review is a useful retainer for that knowledge. It regularly brings another engineer into the important paths of the product.

Selective review only works if the team spreads that context deliberately. Rotate reviewers across critical subsystems, keep design decisions visible, and use incidents and rollbacks as shared learning. Otherwise the team can replace a human bus factor with an AI-mediated one.

This article is about review policy for experienced teams. It is not an argument that less-experienced engineers need less human feedback. Junior and mid-level developers still need pairing, explanations, and progressively harder review ownership. AI feedback can supplement that loop, but it has not been shown to replace it. We cover that development path separately in why AI makes mentorship more important, not less.

This does not mean a person should read every diff. Blanket review is a weak way to preserve understanding because most routine changes contain very little architectural information. The goal is to put people into the loop where understanding compounds: new boundaries, security decisions, data models, shared infrastructure, and business rules that are difficult to reconstruct after the fact.

Default to AI, then gate by consequence

Every change should receive an AI review. That gives the team a broad additional signal without putting every pull request into a human queue. It is not proof of correctness. The 2025 DORA report describes AI as an amplifier of an organization’s existing strengths and weaknesses. Weak tests, unclear ownership, and poor incident learning do not become strong because a model joined the review.

The review system then needs a risk gate. It should use deterministic project knowledge as well as the AI findings: changed paths, code ownership, new endpoints, database writes, migrations, permission checks, concurrency, public APIs, latency and capacity budgets, availability, resource use, and whether the affected behavior has reliable test coverage.

When a risk signal fires, the system should assign a named reviewer who understands that area. A random approval is not the objective. The person who knows why an organization boundary exists or how credits reconcile can review the actual contract rather than the syntax around it.

Change class	Automated gate	Human policy
Authentication, authorization, sessions, secrets	Static security checks, negative tests, permission rules	Mandatory security-aware reviewer
Payments, payroll, pricing, credits, entitlements	Boundary, idempotency, reconciliation, and failure-path tests	Mandatory domain owner
Migrations, backfills, destructive data changes	Schema checks, realistic dry run, rollback validation	Mandatory rollout review
Shared architecture, public APIs, concurrency	Contract, integration, compatibility, and load checks	Senior engineer reviews system impact
Reliability, latency, capacity, resource use, cost	Benchmarks, profiling, load tests, and service-level objectives	Domain owner reviews changes that threaten an agreed operational budget
Safety-critical or regulated behavior	Requirements traceability, hazard analysis, and prescribed verification evidence	Independent human assurance under the applicable standard
Routine UI, local refactors, generated artifacts	Typecheck, lint, static analysis, and tests at the appropriate layers	AI review unless a risk signal fires

Security automation is not an exemption from human accountability. NIST’s Secure Software Development Framework combines review, analysis, and executable-code testing rather than treating any one signal as sufficient. In one controlled study, participants with an AI assistant produced significantly less secure code and were more likely to believe their code was secure. That result came from a specific model, population, and set of tasks, but it is enough to reject blind trust on security-sensitive changes.

Safety-critical and regulated systems are a harder boundary. Aviation guidance requires lifecycle objectives, verification activities, and evidence proportionate to software criticality. FDA validation guidance similarly treats validation as a documented lifecycle responsibility. In these domains, the applicable assurance process decides what can be automated. An AI-first review policy does not override it.

The gate also needs memory. A security finding should not disappear because a second model says the thread looks resolved. A broad rewrite or force-push may need the full review again. A normal follow-up can review only the delta. The system should spend attention in proportion to what changed.

Routine code review is becoming an anti-pattern

Line-by-line human review of low-consequence implementation is increasingly a poor use of senior engineering time.

Take a frontend component. If it renders the right states, stays accessible, performs within the agreed budget, and passes a reliable user journey, then a merely non-ideal implementation often does not matter. If someone would have preferred a different internal structure, ultimately, who cares? The customer does not receive more value because the pull request matched a reviewer’s personal implementation taste.

This only works when the project has rigorous behavioral tests. For routine product code, behavioral evidence at the cheapest reliable layer is a stronger gate than human preference. Unit, contract, integration, and E2E tests answer different questions. Use E2E tests for critical user journeys, not as a substitute for evidence at every layer: large E2E suites tend to become slow, unreliable, and difficult to diagnose. The suite still has to cover the success, failure, and boundary states of the contract. A happy-path screenshot is not an E2E strategy.

Repeatable objections belong in static analysis. A mature pipeline should combine typechecking, linting, framework-specific analysis, and tests at the appropriate unit, contract, integration, and E2E layers. It should also encode project-specific invariants. For example, a custom syntax rule can reject a tenant-scoped operation unless an awaited authentication gate appears before it in the handler.

That local rule is more valuable than asking a reviewer to remember the invariant on every pull request. It runs every time, has one interpretation, and cannot get tired. The same principle applies to dependency boundaries, unsafe data access, naming conventions that carry meaning, and framework-specific mistakes.

If a review comment can be expressed as a deterministic check, move it into the pipeline. Human attention should not pay the same tax twice.

Make quality a software lifecycle

Review should be one stage in a strict software lifecycle, not the place where the team hopes every quality problem will be discovered.

Every change should pass through multiple independent signals. Each one answers a different question. None of them can replace the others.

1. Classify the change.Mark security, financial, data, migration, public API, concurrency, performance, reliability, regulatory, and architectural boundaries before the review starts.
2. Run deterministic gates.Format, typecheck, lint, enforce project-specific AST rules, scan dependencies and secrets, and build the real artifact.
3. Prove behavior.Run unit, contract, integration, and E2E tests against the success, failure, retry, and boundary cases touched by the change.
4. Prove operational behavior.Check latency, capacity, availability, resource use, cost, and degradation against explicit budgets where they matter.
5. Measure coverage.Use coverage to find behavior the suite never exercised, not as proof that the exercised behavior was tested well.
6. Judge test validity.Give the requirement, production diff, and test diff to a separate agent whose only job is to challenge whether the tests prove anything.
7. Review with AI.Check correctness and project conventions, prioritize findings, remove duplicates, and escalate low-confidence or high-consequence areas.
8. Route the human.Assign the right owner to security, business logic, architecture, migrations, or behavior that remains weakly observed.

The important part is that all code goes through the lifecycle. A persuasive pull-request description cannot compensate for missing behavioral evidence. A human approval cannot compensate for a migration that was never tested on realistic data. An AI review cannot compensate for tests that were designed only to stay green.

Coverage is not test validity

The predictable objection is correct: when an implementation agent also writes the tests, it can reward-hack.

Ask an agent to deliver a feature with a green build and high coverage, and it may satisfy those visible metrics without proving the behavior. It can execute a branch without making a meaningful assertion, mock the behavior it was supposed to exercise, mirror the production algorithm inside the test, or verify that its own mocked collaborator was called. The suite passes. Coverage rises. Confidence should not.

This is why test validity needs its own gate and its own agent.

The test judge receives the requirement, the production change, and the tests. It cannot edit the implementation or repair the suite. It has no coverage target and no delivery reward for accepting the patch. Its role is only to find reasons the tests may be invalid.

That separation reduces the direct incentive to accept weak tests. There is nothing for the judge to make pass. It can still share the implementation agent’s blind spots, misunderstand the requirement, or prefer a persuasive explanation over valid evidence. Research on LLMs acting as judges documents position, verbosity, and self-enhancement biases, as well as limited reasoning ability. This is a useful control, not an independent source of truth.

There is also a deeper test-oracle problem: running a test is separate from knowing whether the observed result is correct. Before the test judge earns authority, calibrate it against human decisions, seeded faults, and known-invalid suites. Keep sampling its accepted changes after deployment.

The judge should ask concrete questions:

• What plausible wrong implementation should make this test fail?
• Does deleting or inverting the changed branch break the test for the intended reason?
• Is the assertion checking behavior, or only proving that the setup ran?
• Did the test mock the exact boundary it was meant to verify?
• Are failure, retry, rollback, partial-success, and authorization paths represented?
• Does the test describe the product contract, or merely repeat the implementation?

Many of these problems leave detectable evidence in the test diff: tautological assertions, broad mocks, implementation coupling, and missing negative cases. Their absence is not proof that the suite is valid. For higher-risk changes, the judge can be backed by hidden tests, seeded faults, mutation testing, or human review of the test plan.

Coverage still matters. It tells us where the suite did not look. It does not tell us whether the assertions were meaningful, a distinction reflected in Google’s code coverage guidance. Test validity tells us whether looking there produced useful evidence. A serious quality gate needs both.

The operating rule

The policy is not “replace code review with AI.” It is to design the review system around the strengths of each participant.

• AI covers breadth.
• Static analysis enforces known rules.
• Behavioral tests at the appropriate layers protect observable behavior.
• An independent judge challenges whether the tests are real evidence.
• Humans retain the architecture, develop other engineers, and own decisions where context and consequence matter.

That lets the team review less code without lowering the bar. More importantly, it keeps people responsible for the parts of the system they will eventually have to explain, operate, and debug.