Summary: Reviewing AI-generated code means a human checks what automated and AI reviewers tend to miss: business rules, authorization, data handling, invented packages or APIs, and tests that verify nothing. VAON combines automated gates, an AI pass and a human reviewer in a 7-step process, and keeps review and test records that customers can open.
Contents
- Why does AI-written code still need a human reviewer?
- Which viewpoints should a human reviewer cover?
- How do you spot a meaningless test or a package that does not exist?
- How do automated tools, AI and people split the work?
- What records does VAON's 7-step process leave behind?
- When is this approach not enough?
- FAQ
1. Why does AI-written code still need a human reviewer?
AI-written code still needs a human reviewer because AI answers "does this code run?" far better than "is this correct for this customer's company?". A neat function with comments and tests can still break a rule that only someone inside the business knows.
Customers ask VAON about this directly. "Who checks the code the AI wrote?" was one of the three questions they asked most in 2026. "We trust the AI" is the wrong answer, and so is "we don't use AI". The useful answer is a list of what people do, plus proof that they did it. The general risks of AI-generated code are covered in Shadow AI and the risks of AI-generated code, so this article stays on two things: what the reviewer looks at, and which records are kept.
2. Which viewpoints should a human reviewer cover?
A human reviewer of AI-written code should cover the eight viewpoints below, because these are the places where scanners and AI reviewers usually lack the context to reach a conclusion.
| Viewpoint | Common failure | Reviewer's question |
|---|---|---|
| Business rules | Code follows what the AI guessed, not the real rule (rounding, closing dates, exceptions for special accounts) | Which item in the requirements document does this rule come from? Who confirmed it? |
| Authorization | The UI hides a button, but the API still returns data to a user without permission | What happens if this user calls the API directly? |
| Data handling | Personal data written to logs, queries missing a filter by user or tenant, extra fields in responses | What data leaves the system or lands in a log? |
| Invented packages and APIs | A package, function or parameter the AI made up, or took from an older version | Does the package exist in the official registry? Does the function exist in the version we use? |
| Meaningless tests | No assertion, an assertion on something obvious, or a mock that always returns what the test expects | If I break the code on purpose, does the test turn red? |
| Error handling and edge cases | Errors swallowed and replaced by a silent default; empty, duplicate and concurrent cases ignored | What happens with empty, duplicate or oversized input? |
| Changes outside the request | The AI edits unrelated files, renames things in bulk, deletes "unused" code that is in fact used | Does every changed line belong to this change? |
| Keys and configuration | Real keys or environment addresses inside sample code and tests | Is any value valid only on one person's machine? |
Business rules and authorization are the two places a reviewer cannot hand to a machine. A scanner cannot tell whether "orders above a certain amount need manager approval" is the customer's policy or an accident of the code. Only someone who has read the requirements can.
3. How do you spot a meaningless test or a package that does not exist?
A reviewer spots a meaningless test by breaking the code on purpose, and spots a package that does not exist by looking the name up in the official registry instead of trusting the AI's suggestion.
Tests. AI often writes tests to match the code it just produced, so if the code is wrong, the test accepts the wrong behavior. The cheapest check: flip a comparison operator or remove a condition, then rerun. If the test stays green, it protects nothing. A better defense is to write test scenarios from the requirements rather than from the code.
Packages and APIs. When a pull request adds a package, the reviewer opens the official registry and checks that the name exists, who maintains it, and when it was last updated. A plausible name can be one the AI invented, and an attacker may have registered it in advance. For an unfamiliar function or parameter, open the documentation for the exact version in use, or run it. Reading alone is not enough, because invented code tends to look natural.
4. How do automated tools, AI and people split the work?
On VAON projects, automated gates stop errors with a recognizable pattern, an AI pass reads the change again, and a person decides everything that needs context. Each layer adds to the others and none replaces another.
| Layer | What it does | Limit |
|---|---|---|
| Automated gates on every pull request | Secret scanning, dependency scanning, static analysis (SAST). The main branch is locked, so nothing merges without review | Only finds issues with a known pattern; knows no business rules |
| AI security pass on the change | Reads the diff and flags suspicious spots | Produces false alarms and can miss things |
| Human reviewer | Reads the output of both layers, then checks the eight viewpoints in section 2 | Depends on the reader's time and expertise |
Two points need saying plainly. First, the AI security pass supports people and does not replace them. False alarms are normal, so a person always reads the result and decides. Second, when a customer has not allowed their source code to be fed into AI tools, the AI pass does not run. The project then relies on the automated gates and the human reviewer. VAON's secure development process uses NIST SSDF (SP 800-218) as a reference.
5. What records does VAON's 7-step process leave behind?
VAON's 7-step process leaves at least one trace at every step, and every project keeps review and test records that the customer can open. For each change the team goes through:
- Planning. Trace: the change description and its scope.
- Challenge by another engineer. Trace: comments on the plan, before any code is written.
- Confirmation. Trace: the decision to proceed or revise.
- Build. AI assists, a person checks. Trace: a pull request with the reason for the change.
- Cross-check and team lead approval. Trace: review comments, the approver's name, the result of the automated gates.
- Testing in a separate environment. Trace: test scenarios and run results.
- Release. Trace: release notes and a tag.
VAON engineers use Claude Code and GitHub Copilot every day. AI rereads code, generates tests and syncs documentation, and a person checks before release. Step 2 is the one that surprises customers most: the challenge happens before the build, not after, because fixing a wrong plan costs far less than fixing a finished pull request.
For the customer, these records answer "who checks the AI's code?" directly: who read which change, which tests ran, which release carries which tag. The format can differ between projects, so if you have requirements on how records are kept, raise them at kickoff. The verification loop for AI-assisted testing is described in AI in QA: a four-step verification loop.
6. When is this approach not enough?
Human review, however careful, does not catch every defect, and three situations are worth knowing in advance.
- An overloaded reviewer. AI increases the amount of code, but not the hours a person can read. The bigger the pull request, the more the reader skims. Keep changes small and work in short increments that run, so each review can be read in full.
- A reviewer without the business context. If requirements are not fixed in writing, the reviewer has nothing to compare against, and the first two viewpoints in section 2 lose their value.
- A throwaway prototype. The full process is too heavy for a demo discarded in a few days. Say clearly that it is a prototype and keep it off production.
7. FAQ
Is using AI to review AI-written code enough? No. An AI reviewer is useful for surfacing suspicious spots, but it raises false alarms and can miss things, especially around business rules and authorization. VAON uses AI as an extra layer, and a person reads the result and decides.
Can customers see the review and test records? Yes. Every VAON project keeps review and test records, and the customer can open them. Agree at kickoff where they are stored and how you will access them, so you are not searching for them when you need them.
What if the customer has not allowed source code to be used with AI tools? The project still runs, with one layer fewer. The AI pass is skipped, while secret scanning, dependency scanning, static analysis on every pull request, and human review stay in place.
Where should a reviewer start with a large pull request written by AI? Start with the change description and the related requirement, then read authorization and data changes before the UI. If the change is too large to read in full, ask for it to be split instead of skimming.
If automated tests are good, can we skip human review? No. Tests only check what the test author thought of, and AI-generated tests can be written to match wrong code. Tests and review check different things.
Want to see what a review process looks like on a team that uses AI before you hand over work? VAON walks you through the process and shows sample review and test records in a 60-minute session with the CEO. No documents needed, no obligation. Book a free 60-minute consultation
See also: 12 things to confirm before outsourcing AI-driven development and AI coding security guidance for software vendors from the Japanese government.
References
- NIST, Secure Software Development Framework (SSDF) Version 1.1, SP 800-218, February 2022: https://csrc.nist.gov/pubs/sp/800/218/final (opened Oct 17, 2026)
