AI can write the code. Your team still has to understand it.
Code review is not only a bug-catching gate. It is how a team understands, accepts, and retains ownership of every change entering its codebase.
“If AI can generate code and review its own work, do we still need people reviewing every change?”
The short answer
Yes—because code review was never only about catching bugs.
Code review is the moment a team decides whether it understands and accepts a change entering its system. It spreads context, protects architectural decisions, exposes operational risk, and creates shared ownership of what the company will run in production.
AI can produce the implementation. It cannot accept accountability for the codebase.
Code review is an ownership transfer
The common explanation for code review is that a second set of eyes catches mistakes. That matters, but it is only one part of the job.
A good review also answers:
- Does someone besides the author understand what this change does?
- Does it fit the architecture and conventions we have already chosen?
- Do we understand how it can fail and how we would recover?
- Is the reason for the change preserved somewhere the team can find later?
- Is another engineer prepared to maintain this after it merges?
That is why review matters even when the code is correct.
The pull request turns an individual change into team knowledge. The reviewer is not merely checking syntax. They are accepting part of the responsibility for what happens next.
AI makes code cheap and understanding expensive
AI-assisted development changes the economics of software delivery. A developer can produce a working implementation, tests, documentation, and configuration much faster than before.
The team’s capacity to understand changes has not accelerated at the same rate.
That creates a new bottleneck: comprehension.
When generating another hundred lines is nearly free, it becomes easy to submit more code than anyone has carefully reasoned through. The code may be clean, well-named, and accompanied by convincing tests. It may still encode the wrong assumption, duplicate an existing capability, weaken an architectural boundary, mishandle a failure mode, or add a dependency nobody intended to operate.
AI-generated code often looks finished before it is understood. That polish can make a shallow review feel responsible.
It is not.
Green checks are evidence, not understanding
Builds, tests, linters, type checkers, security scans, and AI review tools should all run before a person spends time on a pull request. Machines are good at applying repeatable rules quickly and consistently.
But a green pipeline cannot tell you whether the team should own this change.
A test suite only proves the cases somebody thought to encode. A static analyzer cannot decide whether a new abstraction belongs in the system. An AI reviewer can identify patterns and suggest risks, but it does not carry the operational context, customer commitments, or architectural history that make those risks meaningful.
Automation can tell a reviewer, “the defined checks passed.” It cannot honestly say, “we understand the consequences.”
Faster review is not automatically better review
DORA’s research on generative AI in software development found that greater AI adoption was associated with faster code review and approval. The same research cautioned that faster review does not necessarily mean more thorough review.
It also found an association between increased AI adoption and lower delivery stability. DORA offered one likely explanation: AI lets teams generate more code in the same amount of time, which can increase change size. Larger changes are harder to understand, slower to recover from, and more likely to create instability.
The practical lesson is not to avoid AI. It is to preserve the delivery practices that make speed safe.
Keep changes small. Make intent explicit. Automate repeatable checks. Require a person to understand the behavior before approval.
The five questions every reviewer should answer
In an AI-assisted workflow, I would rather see a reviewer answer five meaningful questions than leave twenty comments about formatting.
- What behavior changes? Explain what users, systems, operators, or data will experience differently after this merges.
- Why is this the right design? Confirm that the change fits current architecture and is not adding unnecessary abstraction, duplication, or dependency.
- How can it fail? Consider invalid inputs, partial outages, permissions, concurrency, data loss, security boundaries, and third-party failure.
- What evidence supports it? Review the tests, manual validation, observability, rollout plan, and assumptions—not only whether CI is green.
- Can the team operate it? Make sure somebody besides the author could diagnose, roll back, change, or remove it under pressure.
If the reviewer cannot answer those questions, the review is not complete. That may mean the pull request needs a clearer description, a smaller diff, better tests, a design note, or a conversation with the author.
“I do not understand this yet” is valid review feedback.
Make AI explain the change, but do not outsource the decision
AI can make a human review better. It can summarize a large diff, trace a call path, identify missing tests, compare an implementation with project conventions, or generate questions about security and failure handling.
Use it as a research assistant for the reviewer.
Do not treat its approval as accountability. The human reviewer still needs to verify the explanation against the code and decide whether the change belongs in the system.
A useful rule is simple:
AI may help explain the change. A person must be able to defend the decision to merge it.
Change the pull request template before adding another tool
Many teams respond to AI-generated code volume by adding an AI code-review product. That can help, but it does not fix unclear ownership or weak review expectations.
Start with a pull request template that requires the author to provide:
- Intent: What problem are we solving, and for whom?
- Approach: What changed, and what important alternative was rejected?
- Risk: What can fail, what data or permissions are affected, and what is the blast radius?
- Evidence: Which tests, checks, screenshots, or observations support the change?
- Operation: How will we deploy, observe, roll back, and eventually remove it?
The author remains responsible for those answers even when AI wrote most of the code. “Generated by an agent” explains how the text was produced. It does not explain why the company should run it.
Use AI to document the review, not replace it
I turned the five review questions into a reusable Codex skill. Give $write-pr-description a GitHub pull request URL and it inspects the diff, existing description, linked issues, checks, review discussion, and repository guidance. It then drafts the five sections using evidence from the change instead of generic boilerplate.
Download the write-pr-description skill, then save it as ~/.codex/skills/write-pr-description/SKILL.md.
Invoke it with:
Use $write-pr-description for https://github.com/owner/repository/pull/123The skill can surface missing context, organize evidence, and make a pull request easier to review. It deliberately marks unsupported claims as Not verified or Author input needed, and it shows the complete draft before asking permission to update the remote pull request.
That output is still a draft of the team’s understanding—not a replacement for it.
The author must verify every claim against the code. The reviewer must still read the diff, challenge the design, inspect the evidence, and understand the failure and recovery paths. If nobody can explain the change without asking AI to summarize it again, the review is not finished.
The success measure is not a polished pull request description. It is a teammate who can explain what will happen after merge and take responsibility when it does not go as planned.
Keep reviews proportional, not ceremonial
Review does not need to become a heavyweight approval board. A copy change and a database migration should not receive the same process.
Scale the review to the risk:
Low-risk changes can rely on automated checks and one quick human review.
Material application changes should include an accountable reviewer who understands the affected domain.
High-risk changes involving authentication, payments, customer data, infrastructure, or destructive operations may need a specialist, a rollout plan, and explicit rollback evidence.
The standard is not “every diff receives the same ceremony.” The standard is “every change is understood by people capable of owning its consequences.”
How this connects to the work I do
When I work with a company as a Fractional CTO, code review is one of the clearest windows into how the engineering organization actually operates.
It shows whether architecture decisions are understood or merely documented. It reveals whether senior engineers are spreading context or becoming bottlenecks. It exposes whether vendors, internal teams, and AI tools are contributing to one coherent system or simply adding code.
I help teams design a review system appropriate to their stage: protected branches, clear ownership, small changes, automated quality gates, risk-based review expectations, and a durable record of what changed and why. The goal is not more process. The goal is a delivery system leadership can trust without slowing the team to a crawl.
That review history also matters beyond engineering. It supports incident response, technical diligence, customer security reviews, and change-management evidence for SOC 2. An approval record alone does not prove a change was good, but a consistent review process shows who evaluated it, what evidence they considered, and how it entered production.
This becomes especially important as AI increases output. If code enters the system faster than knowledge spreads through the team, velocity is temporary. The company is accumulating a codebase it cannot confidently change.
The leadership rule
Never merge code that only the AI understands.
AI can write more of the implementation. It can help test, document, and review it. Use that leverage.
But before the change becomes part of the product, someone on the team must understand what it does, why it belongs, how it fails, and how to take responsibility for it.
The codebase may be increasingly machine-written. It still has to remain human-owned.