AI code review covers two jobs: an AI tool reviewing a code change, and a person reviewing code that an AI tool wrote. This article is about the second job: a repeatable way to review AI-generated code in pull requests, decide who approves each change, and keep the evidence that justifies the merge. It is not a comparison of AI code review tools. It covers the two meanings of AI code review, the reasons AI-generated code needs a human approver, a five-layer review process, the evidence each pull request needs, and when a change should be escalated beyond routine review.
TL;DR
AI code review means an AI tool checking code, or a person checking code an AI wrote. AI-generated code needs the second as the final approval, because a review based only on the diff and the repository can miss business rules and data boundaries that were never documented or supplied.
- Two meanings, one gap: review by an AI tool flags known bug and style patterns in a diff; review of AI-generated code confirms that the change does what the business needs, safely, before it merges.
- Four reasons AI-generated code needs a human approver: AI reviewers often work from the same limited context as the AI author, clean code can still do the wrong thing, AI tools can suggest packages that do not exist, and more code merges each week than anyone reads.
- A five-layer review process runs two automated layers (pipeline checks, an AI reviewer) and three human layers (business rules, trust boundaries and data, review depth by blast radius), each with a named owner and recorded evidence.
- Escalate a pull request when the reviewer cannot confirm the business rule, reproduce a permission check or explain a migration’s effect on existing data; hold the merge until a qualified reviewer closes the gap.
The wider question of running an AI-built product with real users is covered in the guide to ai-generated code in production. This article goes one level deeper, into the review of each pull request.
What AI code review means: two different jobs
AI code review means either a review done by an AI tool, where a language model comments on a pull request, or a review of AI-generated code, where a person checks code that an AI tool wrote. The two jobs answer different questions and stop at different limits. A pull request is a proposed change that someone approves before it is merged; a diff is the list of lines that change.
| Meaning | What it is | Question it answers | Limit |
|---|---|---|---|
| Review by an AI tool | An LLM-based reviewer comments on pull requests or in the editor | Does this change contain known bug, security or style patterns? | Works from the context it is given: usually the diff and the repository, rarely the contracts, users or unwritten business rules |
| Review of AI-generated code | A person, inside a defined process, approves code an AI tool wrote | Does this change do what our business needs, safely, and is the evidence on file? | Needs someone who knows the business and can read code, or an independent reviewer |
GitHub’s guidance on reviewing AI-generated code makes the same split from the developer side: AI-assisted review tools are one step in a process that still includes a human check of context and intent. The general trade-off between people and tools is covered in the guide to manual and automated code review.
Why AI-generated code needs human review
AI-generated code needs a human approver because an AI-generated change can look finished before it is correct, and a review based only on the diff and the repository may not catch the difference. Four mechanisms explain the gap.
The AI reviewer shares the AI author’s blind spots
An AI reviewer sees what it is given: the diff, the repository and sometimes the prompt history. When the product specification, the pricing rules or the role matrix are not supplied, the AI reviewer cannot check the change against them. Two models trained on similar public code also tend to accept the same patterns, so a mistake that looked normal to the author model can look normal to the reviewer model.
AI reviewers do find real issues in generated code, especially when they receive the product specification and the relevant tests. The risk sits in rules that were never written down or supplied. A human approver should confirm the expected behaviour with the product owner, inspect changed tests and require evidence for high-risk paths before merge. The study evidence on AI tools checking their own output is summarised in the guide to AI-generated code in production.
Clean-looking code that does the wrong thing
Readable code and passing tests are not evidence of correct behaviour. Take an illustrative scenario: a scheduling app for Dutch installation companies. An AI refactor stores appointment times with a fixed UTC offset of +02:00 instead of the Europe/Amsterdam time zone. When the Netherlands moves from summer time (CEST) to winter time (CET) on 25 October 2026, every appointment created for a date after the switch shows one hour late.
The test suite stays green in this scenario, because the same AI change also updated the test expectations to match the new behaviour. The lesson for any review of AI-generated code: review the tests as well as the code, and flag every pull request that changes code and its tests at the same time.
Packages and functions that do not exist
AI coding tools sometimes suggest libraries or functions that do not exist, a failure known as package hallucination. In the test set of Spracklen et al., 16 code-generating models produced 576,000 code samples, and the average rate of hallucinated packages was at least 5.2% for commercial models and 21.7% for open-source models (“We Have a Package for You!”, USENIX Security 2025). The rates describe that study’s prompts and models, not every product.
Attackers can register invented package names and publish malicious code under them, a tactic called slopsquatting. A dependency is an external library the product relies on. Every new dependency in AI-generated code needs a recorded decision: the package exists, is maintained and is the one the team meant.
More code than anyone reads
AI coding tools raise the amount of code each developer produces, and review becomes the step that teams skip. The 2024 DORA research found that a 25% increase in AI adoption was associated with a 7.2% decrease in software delivery stability and a 1.5% decrease in delivery throughput (DORA, Impact of Generative AI in Software Development). DORA reports these as associations, not proof of cause.
The practical threshold: if more code merges each week than one person can read, decide which parts of the product a person must read. Layer 5 of the review process sets that rule.
How to review AI-generated code: five layers
Review AI-generated code in five layers: two automated and three human. Each layer has an owner, one concrete check and a piece of evidence that goes into the pull request. The five layers are a Sunbytes editorial model, not a NIST framework; the model is consistent with practice PW.7 of the NIST Secure Software Development Framework (SP 800-218, v1.1), which calls for reviewing or analysing human-readable code to find vulnerabilities and verify security requirements.
Layer 1: let machines check what machines can
Layer 1 runs automated checks on every pull request in the CI pipeline: the code compiles, existing tests pass, linters and type checks run, and secret scanning and dependency scanning look for leaked keys and known-vulnerable libraries. A linter flags code style and common errors; a secret is a password, token or API key that should never sit in the code. The owner is whoever runs the pipeline, and the evidence is the pipeline result attached to the pull request.
The check people forget in AI-generated code is whether tests were deleted, skipped or rewritten to pass, a pitfall GitHub’s guidance also lists.
Layer 2: use an AI reviewer as a second pass
Layer 2 puts an AI reviewer on each pull request to catch pattern-level problems fast: duplicated logic, unsafe functions, missing error handling, inconsistent naming. Give the AI reviewer the team’s rules and, where possible, the specification for the change; treat its comments as suggestions, not approval. The owner is the lead developer, who records which comments were acted on. Free and open-source review tools can run this layer; the tool matters less than who acts on its comments. How scanners and human security review split the work in a pipeline is covered in secure code review vs automated SAST.
Layer 3: a person checks intent and business rules
Layer 3 is a person confirming that the change does what the business needs, not only what the prompt said. The reviewer puts the original prompt or ticket next to the change and checks the edge cases AI-generated code often gets wrong: empty lists, missing values, two users acting at once, time zones and daylight saving, currencies and VAT rounding, refunds and cancellations.
The owner of layer 3 is someone who knows the product rules; the evidence is that person’s confirmation of the expected behaviour, ideally as concrete examples. A reviewer who cannot state the pricing rule should not approve a change to it.
Layer 4: a person checks trust boundaries and data
Layer 4 is a person checking every trust boundary in the change. A trust boundary is any point where the code decides who someone is and what they may do. The reviewer checks authentication and roles, who may read or change which records, secrets in code or in the front end, input from users and third parties, and logging of personal data. Broken Access Control is ranked A01 in the OWASP Top 10:2025, and the evidence for layer 4 is a permission check verified for each affected role.
Article 32 of the GDPR requires security measures appropriate to the risk for personal data. The GDPR does not prescribe human code review; a policy that code handling personal data gets a person’s review before merge is our recommendation for meeting that risk-based duty. The common risks in AI-built apps are covered in vibe coding security risks.
Layer 5: set review depth by blast radius
Layer 5 decides which changes need a deep human review. Blast radius means what breaks, and for whom, if a change is wrong. Trunk code is the code many features depend on: login, payments, the data model, permissions and integrations. Leaf code sits at the edge, such as copy and layout. The owner is the founder or CTO, who agrees the map of trunk areas once and updates it when the product changes.
How deep to review: match effort to blast radius
Review depth for AI-generated code should follow what breaks if the change is wrong, not how many lines the change has. A three-line change to a permission check can expose customer data, while a large layout change usually cannot, unless it also touches exports, permissions or data queries. Table 2 sets the depth per area of the product.
| Area | Example | Review depth | Who signs off |
|---|---|---|---|
| Authentication and roles | Login, password reset, admin role | Deep human review + test evidence | Named approver, not the author |
| Payments, invoices, VAT | Checkout, refunds, VAT rounding | Deep human review + test evidence | Named approver, not the author |
| Data model and migrations | New column, changed date format | Deep human review + test evidence | Named approver, not the author |
| Personal data handling | Exports, logs, profile pages | Deep human review + test evidence | Reviewer with security depth |
| Integrations and API keys | Payment provider, CRM sync | Human review | Lead developer |
| Business rules | Pricing, scheduling, eligibility | Human review | Someone who knows the rule |
| Internal reports and admin views | Weekly sales report without exports | AI reviewer + spot check | Any developer |
| UI text and layout | Button copy, spacing | AI reviewer + spot check | Any developer |
A review record makes the depth visible. The example below shows the minimum record for an AI-generated payment change.
| Field | Entry |
|---|---|
| Change intent | Correct refund VAT rounding for Dutch customers |
| AI-generated scope | src/billing/refunds and refund tests |
| Automated evidence | Build, unit tests and dependency scan passed |
| Business-rule evidence | Finance owner approved the expected rounding examples |
| Regression evidence | Previous refund examples still pass; changed test expectations were reviewed |
| Security evidence | Refund permissions verified for customer and admin roles |
| Decision | Approve only after a non-author reviewer signs off; otherwise hold the merge |
If a trunk area has no named person who can review it, that gap is the reason to bring in an outside reviewer.
What a founder can check without reading code
A founder can run four checks on every pull request without reading a line of code. Each check is visible on the pull request page of any common code platform.
- The pull request states in one sentence what it should do and links the ticket or prompt.
- A change to a trunk area names a human approver who is not the author.
- Test evidence is attached, and test files changed in the same pull request are flagged.
- New third-party packages are listed with an approve or reject decision.
If a high-risk pull request lacks a non-author approver, relevant test evidence, or a decision on a new dependency, do not merge it. Assign an owner and close the gap in that pull request; do not wait for a recurring process failure.
Layers 1 and 2 run on their own. Layers 3 to 5 need a person who knows what to look for.
If nobody on your team can approve AI-generated code against your business rules and your customers’ data boundaries, an independent reviewer can cover that part. An AI-built product review is independent of whoever fixes the code, and the findings come back in plain English, ranked into a prioritised action plan.
What evidence a pull request needs before merge
An AI-generated pull request is ready to merge when the evidence for each relevant question is on file, not when a tool or a person says it looks fine. AI reviewers and scanners produce part of that evidence; the rest needs a person with access to the rules, the roles and the test results. Table 4 lists the evidence per question.
| Question | Evidence an AI reviewer or scanner can provide | Evidence a person must add |
|---|---|---|
| Is style and structure consistent? | Linter and AI review comments | None, unless the comments are disputed |
| Does the code match a known vulnerable pattern? | Scanner findings and AI review comments | Decision on each finding: fix, accept or false positive |
| Does a new dependency carry risk? | Dependency scan output | Approve or reject decision per new package |
| Does the feature follow the business rule? | Can flag mismatches if the specification was supplied | Product owner’s confirmation with concrete examples |
| Can one customer reach another customer’s data? | Can flag candidate access-path issues | Role matrix and permission tests for each affected role |
| Were tests weakened to make the change pass? | Can flag changed or deleted test files | Reviewer’s note on why each expectation changed |
| Is this the right finding to fix first? | Severity labels | Priority decision by the owner of the release |
We’d recommend keeping the AI reviewer on every pull request, because it removes routine findings before a person spends time on the change. The condition: on trunk code, the AI reviewer is never the only approval.
When to escalate an AI-generated pull request
Routine review is not enough when a change touches an area no one on the team can verify. Hold the merge if the reviewer cannot confirm the applicable business rule, reproduce a permission check, or explain a migration’s effect on existing data. Assign a qualified reviewer, document the missing evidence, and rerun the relevant tests before approval.
A separate decision arises when you need confidence in the whole product: before launch, before an enterprise customer’s security questionnaire, during due diligence, after a large AI-generated rewrite or at an engineering handover. That is the scope of an independent AI code audit, not the approval of a single pull request. Enterprise buyers in the EU often ask about secure coding and security testing, the subjects of ISO/IEC 27001:2022 Annex A 8.28 and 8.29 (ISO/IEC 27001:2022).
How Sunbytes reviews AI-generated code
An AI code review succeeds when someone approves the code against how the business works, not against the prompt that produced it. Layers 3 to 5 are where an AI reviewer has the least to compare against: business rules, customers’ data boundaries and the parts of the product with the largest blast radius.
Sunbytes puts an independent reviewer on exactly those questions through an AI-built product review. The reviewer did not write or prompt the code and is not contracted to fix it. Where findings touch access control, secrets or GDPR evidence, the review applies the security depth and comes back in plain English with a prioritized action plan, so the reviewer, the evidence and the fix work stay separate.
About Sunbytes
Sunbytes is a Dutch-founded technology, cybersecurity and workforce partner, headquartered in Utrecht with a delivery hub in Ho Chi Minh City. Over 15+ years, we has delivered 300+ projects for clients in 20 countries under an ISO/IEC 27001-certified information security management system. Code access during a review is handled under that system, with Netherlands-led governance.
Does anyone on your team own layers 3 to 5 today? → Discuss your AI-built product.
