Code Review Alone Cannot Govern AI-Generated Software

Most software organizations still treat the pull request as their main control point. Code is produced, tests run, reviewers inspect the change, and someone decides whether it can enter production.

That model assumes implementation and review operate at roughly compatible speeds.

AI changes that balance.

A coding agent can generate, revise, and expand a change much faster than a human can understand its architectural implications. The resulting code may compile, pass its tests, and look reasonable in isolation while still conflicting with system boundaries, operational expectations, or decisions that were never written down.

The answer is not to remove human review. It is also not to place another AI reviewer in front of every AI-generated pull request and assume the problem has been solved.

The deeper issue is that code review is being asked to carry more supervisory work than a single downstream checkpoint can handle.

The new bottleneck is supervision throughput

AI-assisted development does more than increase code volume. It increases the number of decisions that must be constrained, checked, interpreted, and eventually revisited.

A recent ESEM 2026 practice-track study describes this as a transition from review-centric guardrails to layered supervision. The researchers interviewed five software engineering practitioners and situated those interviews within a survey of 50 respondents.

The study is exploratory. Its interview sample is small, its survey used convenience sampling, and the findings represent reported practices rather than direct longitudinal observation. It should not be read as a universal benchmark.

It does, however, offer a useful operating model.

The practitioners described code that appeared locally correct but was difficult to validate against architectural intent, organizational context, explainability requirements, or long-term maintainability. The researchers call this pattern false correctness.

False correctness is why a green test suite and a plausible diff are not always enough. The code can satisfy its immediate checks while moving the system in the wrong direction.

Trying to discover every such problem during final pull request review creates a throughput mismatch:

Generation scales with models and compute.
Contextual judgment scales with experienced human attention.
Review queues absorb the difference.

That is not merely a review tooling problem. It is a governance design problem.

Supervision needs more than one layer

The ESEM study groups supervision into three complementary layers: preventive guardrails, executable guardrails, and human oversight.

Layer	Primary role	Typical mechanisms	What it helps prevent
Preventive guardrails	Shape the change before and during generation	Specifications, architecture decisions, repository instructions, AGENTS.md, ownership boundaries	Correct-looking code built from incomplete or incorrect assumptions
Executable guardrails	Check rules consistently against the output	Tests, linting, type checks, CI/CD, policy-as-code, architectural fitness functions	Repeatable violations that should not consume human review time
Human oversight	Interpret what cannot be encoded reliably	Architectural judgment, risk assessment, explainability, operational reasoning	Locally valid changes that are inappropriate for the wider system

No layer is sufficient on its own.

Preventive guidance cannot anticipate every trade-off. Automated checks cannot determine whether every locally correct decision is contextually appropriate. Human reviewers cannot inspect unlimited volumes of generated code with equal depth.

The purpose of layered supervision is not to eliminate responsibility. It is to place each kind of responsibility where it can work best.

Layer 1: Shape the output before it exists

The pull request is a late place to discover that an agent misunderstood the task.

Preventive guardrails move important context upstream. They turn implicit team knowledge into instructions that can influence generation before a large change exists.

Examples include:

The architectural boundary a feature must respect
The source of truth for a business rule
Dependencies that must not be introduced
Data migration and backward-compatibility requirements
Required tests and observability
Security or privacy constraints
Conditions that require human escalation
The expected rollback path

Repository-level files such as AGENTS.md can carry part of this context. A 2026 exploratory study of configuration practices across 2,853 GitHub repositories found that context files dominated the configuration landscape and that AGENTS.md was emerging as an interoperable convention across coding tools. More advanced mechanisms such as skills and subagents were much less common.

That finding does not mean more context is always better. Instructions still need to be relevant, current, scoped, and testable. A large collection of outdated rules can create a different form of ambiguity.

The goal is not to tell the agent everything the organization knows. It is to make the constraints that matter for the current decision explicit.

Layer 2: Turn recurring review comments into executable rules

If reviewers repeatedly identify the same violation, that concern should become a candidate for automation.

A convention that matters only when a reviewer remembers it is not a reliable organizational control.

Executable guardrails can include:

Linters and formatters
Unit, integration, and contract tests
Dependency and license policies
Static analysis and security checks
Schema compatibility tests
Architectural boundary checks
Required observability or migration checks
CI rules that block incomplete changes

This changes the economics of review. Machines handle repeatable checks, while humans spend their limited attention on questions that require context.

The principle is straightforward:

Repeated review findings should become reusable controls whenever they can be expressed reliably.

This does not make the build pipeline the final authority on quality. A pipeline can enforce what the organization has managed to encode. It cannot guarantee that the encoded rules are complete, current, or appropriate for every situation.

Executable guardrails reduce recurring supervision work. They do not eliminate judgment.

Layer 3: Reserve human attention for what cannot be encoded

Human review becomes more valuable when it is not consumed by issues a deterministic check could have caught.

In an AI-assisted workflow, the reviewer’s most important questions move above the level of syntax:

Does this change belong in this part of the system?
Which assumptions are hidden inside the implementation?
Is the failure and recovery behavior acceptable?
Can the team explain why the system behaves this way?
Does the change create an ownership gap?
Will another engineer be able to modify it safely six months from now?
Is the operational risk proportionate to the value being delivered?

This is supervisory interpretation rather than exhaustive line-by-line inspection.

The required depth should also depend on the stakes. A disposable prototype, a payment workflow, and a database migration should not pass through identical oversight. System criticality, reversibility, data sensitivity, and expected lifespan should determine how much human understanding is required.

Human oversight is therefore not a bottleneck that organizations should simply automate away. It is a scarce engineering capability that should be directed toward the decisions where it adds the most value.

An AI reviewer does not remove the accountability problem

AI review tools can expand coverage, summarize changes, identify patterns, and help route pull requests. A proposed agentic code review model extends AI assistance across pull request creation, augmentation, reviewer selection, review, and retrospective analysis.

That can improve the review system.

It does not answer who remains accountable for the final decision.

An AI reviewer can inspect another agent’s output, but both systems may share similar blind spots, incomplete context, or incorrect assumptions. Agreement between agents is not independent evidence that a change fits the organization’s architecture or risk tolerance.

The responsible model is not AI generation followed by AI approval. It is AI assistance operating inside explicit controls, with human authority retained for consequential decisions.

Do not blame every review trend on AI

Teams also need care when interpreting their own metrics.

Another ESEM 2026 study examined 669 developers across 103 repositories and used 228 developers from repositories without agent activity as a control group. After agent adoption, reviews appeared faster, less detailed, and more permissive.

However, similar patterns appeared in the control repositories. The researchers therefore concluded that those review changes were better explained by broader ecosystem trends than by agent adoption alone.

This is an important warning for engineering leaders.

A change that happens after AI adoption is not automatically caused by AI adoption.

Team composition, repository maturity, task mix, release pressure, process changes, and broader engineering trends may all affect the same metrics. External benchmarks can suggest useful questions, but they cannot replace an organization’s own baseline and comparison groups.

The useful question is not:

Do AI-assisted teams review code faster?

It is:

What changed in our teams, repositories, and outcomes after AI adoption, compared with a relevant baseline?

The missing layer is evidence after merge

Preventive, executable, and human guardrails operate mainly before or around the merge decision. They help answer whether a change is ready to enter production.

They cannot fully answer what happens afterward.

A change can pass every gate and still be:

Rewritten shortly after release
Replaced rather than extended
Removed because its assumptions were wrong
Followed by corrective work
Technically successful but economically unproductive
Difficult for the team to own over time

This creates a fourth requirement—not another approval gate, but a post-merge evidence loop.

Moment	Core question
Before generation	Have we made the important constraints explicit?
During implementation	Are enforceable rules checked automatically?
Before merge	Does a responsible human accept the contextual and operational risk?
After merge	Did the change produce durable value, or did later work reveal hidden cost?

The fourth question matters because merge-time confidence is still a prediction. Post-merge codebase history provides the evidence.

Where GitMe fits

GitMe does not replace specifications, tests, CI, code review, or engineering judgment. Its role begins where those controls have made their decision.

GitMe helps engineering organizations examine what happens to the work after it enters the codebase.

That includes questions such as:

How much of the contribution was human- or AI-assisted?
Did higher AI participation produce measurable AI Leverage, or merely more activity?
How much modeled engineering effort remains active over time in the Effort Survival Cohort?
Is new output being extended and retained, or repeatedly replaced?
Does accelerated generation correspond with durable engineering value?

This distinction is essential.

AI usage is an input. AI Leverage is an outcome.

A team can use AI frequently without achieving meaningful leverage. It can also generate more code while increasing rework or reducing the lifespan of what it ships.

Post-merge evidence closes the supervision loop. It allows teams to update their instructions, tests, review standards, and AI policies based on what actually survived—not only on what looked acceptable at merge time.

A practical operating loop

Layered supervision becomes useful when it operates as a learning system:

Externalize important intent. Record architecture, constraints, ownership, and escalation conditions in forms that both humans and agents can use.
Automate recurring checks. Convert repeatable review findings into tests, linting rules, policies, or architectural checks.
Focus human judgment. Reserve reviewer attention for context, trade-offs, explainability, risk, and long-term ownership.
Observe post-merge outcomes. Measure whether the work survives, requires rework, creates leverage, and continues producing value.
Feed evidence upstream. Use production history to improve specifications, agent instructions, executable controls, and review policy.

This loop changes the purpose of measurement.

Metrics are no longer only a report about past activity. They become feedback for designing the next generation of guardrails.

What engineering leaders should do now

Engineering leaders do not need to choose between AI speed and human control. They need to scale control differently.

A practical starting point is to:

Keep AI-generated changes small enough to understand and reverse.
Define different oversight levels for different risk classes.
Treat repeated review comments as automation candidates.
Protect senior architectural and operational judgment as capacity.
Measure review, rework, and durability alongside output.
Compare teams and repositories against their own relevant baselines.
Revisit guardrails when post-merge evidence contradicts merge-time confidence.

The wrong response to AI-generated volume is to demand that humans read every additional line with the same depth.

The equally wrong response is to remove humans because they cannot keep up.

The better response is to distribute supervision across layers and use evidence to improve those layers continuously.

The research is directional, not final

The layered-supervision study is based on five practitioner interviews, a convenience-sampled survey, and reported experiences. Its authors explicitly caution against treating the findings as statistically representative.

The framework should therefore be used as a hypothesis for organizational design, not as a universal prescription.

But its central insight is difficult to ignore:

When implementation throughput increases, validation capacity and feedback systems must evolve with it.

Otherwise, faster code generation does not remove engineering work. It moves that work into review queues, architectural uncertainty, operational risk, and future rework.

Conclusion

Code review remains essential. It is simply no longer sufficient as the primary container for every form of supervision.

AI-generated software needs:

Preventive guidance before code is produced
Executable checks while it is being built
Human judgment where context and accountability matter
Post-merge evidence showing whether the result delivered durable value

The future of software governance is not one perfect reviewer, human or artificial.

It is a learning system in which each layer does the work it can perform best—and production evidence determines whether the system is actually working.

GitMe helps engineering leaders distinguish AI activity from AI Leverage and observe whether modeled engineering effort remains active over time.

Start with GitMe