AI Generates 90% of the Code: Are Six Review Gates Enough?

When AI coding tools contribute 90% of the commits in a repository, the object of code review changes fundamentally. Reviewers used to read “what a person was thinking.” Now they more often read “how a model interpreted the requirements.” Generation speed has increased by an order of magnitude, while human review capacity has not. As a result, teams commonly move review earlier, automate checks, and replace line-by-line reading with a series of gates.

1. Why Review Must Be Mechanized First

Traditional review assumes an implicit premise: the code volume is limited and a person can read it all. That premise no longer holds. The practical response is not to ask people to read more, but to restructure the review process: remove judgments that machines can make from human reviewers, and reserve human attention for parts only humans can judge.

Machines can judge: whether the code compiles, whether tests pass, whether static rules are violated, whether dependencies contain known vulnerabilities, whether the change size exceeds limits, and whether assertions actually verify behavior.

Humans must judge: whether the change is what the requirement wants, whether the business meaning of edge cases is correct, and whether it silently changes architectural constraints.

2. Gate 1: Verify the Work Before Anyone Sees It

This is the easiest step to skip and the highest-return step. Most review delays do not come from difficult-to-read code, but from the fact that “the author has not yet confirmed that it runs.”

The key is to require the submitter to provide executable verification methods and output evidence, rather than a statement that it is “done.” For code-generation agents, explicitly require them to perform the following actions and attach the results to the change description:

• Run the build and confirm that compilation and dependency resolution succeed.
• Run the tests related to the change and paste the complete output rather than a summary.
• For UI changes, compare rendered results with the design screen by screen and output a difference report.
• For data/API changes, provide request examples, response examples, and key metrics such as latency, error rate, and record count.

The next step is to introduce a subagent that performs diff review using fresh context. The reason is straightforward: the agent that generates code carries the prior assumption of “what I intend to do.” It treats its own intention as fact and therefore has difficulty discovering its own misunderstanding. A reviewer without that conversation history can only infer intent from the diff itself, which is closer to the perspective of a human reviewer. This combination of self-verification plus context-isolated review is currently the most stable pair of practices.

Illustrative gate skeleton (pseudo-configuration, expressing stage division only):

stages:
  - self_verify:        # before submission: author-side self-verification
      - build
      - run_related_tests
      - collect_evidence   # screenshots, samples, metrics written into the change description
  - independent_review: # diff review in a fresh context
      - static_analysis
      - security_scan
      - dependency_and_license_check
      - diff_summarization
  - human_review:       # humans handle only what machines cannot decide
      - design_intent_check
      - architecture_impact
  - release:
      - canary
      - metrics_watch
      - auto_rollback

3. Gates 2–6: Automate All Deterministic Judgments

• Semantic and static checks: types, null paths, swallowed exceptions, proper resource release, and logs that leak sensitive fields.
• Security scanning: injection vulnerabilities, missing authentication, hard-coded secrets, deserialization and path traversal, and known vulnerabilities or license compliance issues in dependency components.
• Test validity verification: this is the most easily overlooked. Generating tests at the same time as the implementation allows the same misunderstanding to contaminate both code and assertions. The countermeasure is to have tests produced by independent sources—requirement items, existing contract tests, or supplements from reviewers—and to check incremental coverage, mutation-test survival, and whether assertions only verify state instead of behavior.
• Impact analysis: who calls the modified function, which interface contracts change, and whether consumers and data migrations must be updated.
• Change grading and staged rollout: grade changes by risk, limit single-diff size, force human review on critical paths such as payments, permissions, data deletion, and configuration delivery; roll out gradually with metrics dashboards and automatic rollback.

4. Core Risks the Gates Do Not Cover

Honestly speaking, six gates plus rollback cover determinable risks; the rest still requires humans.

1. Design intent deviation: the code is “correct,” but it does the wrong thing. Machines cannot judge whether the requirement interpretation is correct; only clear acceptance criteria and requirement items can help.
2. Implicit requirements and non-functional constraints: performance capacity, cost limits, observability, multi-tenant isolation, and compliance records are usually not written in the code; they need to be converted in advance into testable gate metrics.
3. Architecture drift: individual diffs may look fine, but cumulatively they break layering and module boundaries. This requires rule-based architecture constraint checks, not intuition from successive reviews.
4. Reviewer rubber-stamping effect: when AI handles both implementation and explanation, the reviewer’s cognitive load increases, and “looks reasonable” is easily mistaken for “already correct.” The countermeasure is to limit the number of changed lines per diff and require reviewers to restate intent before approval.
5. Self-verification bias: agents only run scenarios they think of. A fixed regression set and fault injection are needed as baselines.
6. Supply chain and prompt injection: comments in the repository, dependency documentation, and externally fetched content may carry instructions that induce malicious logic. External content must be treated as untrusted input.
7. Technical debt compounding: generated code tends to follow existing patterns, and defect patterns are also copied in bulk. This requires periodic dedicated governance, not only incremental gates.
8. Rollback is not a universal fallback: stateful changes—database structures, message formats, already-emitted events—cannot be undone by rollback. Rollbackability must be guaranteed at the design stage, for example through backward-compatible migrations, feature flags, dual writes, and gradual reads.

5. Implementation Guidance

To judge whether this system is effective, look at three metrics rather than the number of gates: escaped defect rate (the proportion of defects found by humans after release), rework rate (the rate of resubmission due to review comments), and rollback rate and rollback time. If gates increase but escaped defect rate does not fall, the new additions are ceremony rather than constraints.

At the same time, clearly define the human-machine division: machines are responsible for “whether it conforms to rules,” humans for “whether it conforms to intent”; gates intercept deterministic errors, rollback limits the blast radius of uncertain errors, and the correctness of requirements and architectural direction can still only be borne by humans.