AI-generated code shares one striking trait: it looks correct. The names are consistent, the structure is clean, the comments are complete, and the program runs. It may look neater than code written by many people. That polish makes AI code especially vulnerable to rubber-stamp review: glance over it, decide it looks fine, approve. The real problems are often hidden inside the convincing parts—a boundary condition changed without notice, a call to an API that does not exist, or an exception silently swallowed.
Reviewing AI code is different from reviewing a colleague's work. A colleague may leave a TODO or ask when uncertain. AI writes correct and incorrect code in the same confident voice. This guide provides a checklist and review method designed specifically for AI-generated changes.
The first rule of reviewing AI code: the more harmless a section looks, the more deliberately you should verify it.
Inspect the Scope Before the Code Quality
The order of review should be reversed for AI code. With a colleague, you generally trust that only relevant files changed and begin with the logic. With AI, first determine what it changed and whether the work exceeded the task. Scope creep is common: ask it to fix one function and it “improves” three nearby functions; ask it to add one field and it rearranges the entire data structure; ask it to change A and it deletes B, which appears unused but is not.
Use a Git Worktree or branch diff to frame the complete change set. On the first pass, ask one question only: Should this task have changed every one of these files and lines? Remove out-of-scope edits and evaluate them separately. Do not let them pass unnoticed as part of the main feature.
Six Places AI Code Fails Most Often
In approximate order of frequency, focus on these areas:
1. Hallucinated APIs and Dependencies
AI may call a nonexistent function, supply arguments in the wrong order, import a package that cannot be found, or use an API a library deprecated long ago. It shows no awareness of the mistake and remains equally confident. Check every unfamiliar API against the official signature. For a new dependency, verify that it exists, is actively maintained, and uses a compatible license. Hallucination is the source of this problem, and code style alone cannot reveal it; cross-checking is mandatory.
2. Edge Cases and Error Handling
AI often writes the happy path well and improvises around the edges: empty arrays, null, very long input, concurrency, and network failures. It may ignore them or use catch {} to make the error disappear silently. Check deliberately: Are empty values and boundaries covered? Was the exception handled or merely hidden? Can a failure path leave dirty or inconsistent data behind?
3. Security Problems
AI can concatenate SQL and introduce injection, hard-code secrets in source, fail to validate user input, print sensitive information in logs, or omit a permission check. It optimizes for making the feature run, not making it secure. Apply a security checklist to every change involving input, authentication, a database, or an external request.
4. Behavior Changed Quietly
This category is the hardest to spot. Ask AI to refactor and it may change >= to >. Ask it to “optimize” and it changes a default value, reorder results, or alter a cache lifetime. The feature still looks like the same feature, but its behavior is different. Compare the old and new code closely and confirm that semantics did not change unintentionally. This is the most important review step for an AI refactor.
5. Invented Tests
When asked to write tests, AI may produce tests that are guaranteed to pass: assertions are too broad, the mock replaces the very logic under test, or the test merely codifies the incorrect behavior the AI just introduced. Read what each test actually asserts; do not let a green check mark reassure you. Add boundary cases the AI did not consider.
6. Overengineering
AI tends to make code look professional. It introduces a design pattern for a simple requirement, adds numerous configuration options, or creates an interface layer with no current use. This may not be a bug, but it creates maintenance debt. Ask whether the requirement demands the complexity or the AI added it on its own.
Among the six high-risk areas, quiet behavior changes and hallucinated APIs are the hardest to detect because both disguise themselves as correct code.
A Printable Checklist
□ 改动范围：只动了该动的文件和行？超范围的已剔出单独评估？
□ API 核对：不熟悉的调用查过官方文档？新依赖真实存在且合规？
□ 边界：空值/null/超长/并发/失败路径都处理了？
□ 异常：是处理了，还是被 catch{} 吞了？
□ 安全：SQL 拼接、硬编码密钥、输入校验、权限、日志脱敏？
□ 语义：重构处对照原逻辑，行为没被悄悄改动？
□ 测试：断言是否真的验证了逻辑？边界用例够吗？
□ 复杂度：这些抽象和配置是需求要的，还是 AI 加戏？
□ 运行验证：真的跑起来看过效果，而不只是读代码？The last line is the most important and the most frequently skipped: AI-generated code must be run and verified, not merely read. Reading can reveal obvious problems, but boundary behavior, integration failures, and side effects appear only in execution. When a change has a visible result, exercise it in the browser or a test and inspect the real behavior.
Using AI to Review AI: Helpful, but Do Not Delegate Ownership
A useful technique is to ask a second AI—or the same AI under a different prompt—to review generated code. It can find syntactic mistakes, obvious security patterns, and inconsistent naming. Many tools, including review features in Claude Code and AI reviewers integrated with CI, make this a one-click workflow. AI code review tools are now a mature category.
Remain clear-eyed: an AI reviewer and AI coder share many blind spots. Both may miss the same hallucinated API, and both may admire the same overengineered code as “professional.” Treat AI review as a first-pass pair of eyes. It can catch routine errors and save time, but a person must still decide whether the business logic is correct, whether behavior changed, and whether the change fits the system design. AI can help you review; it cannot assume responsibility for you.
Use AI reviewers for the first pass and people for final approval. Their blind spots overlap, so one cannot replace the other.
Who This Is For and Workflow Recommendations
This checklist is for every developer and team that uses AI to write code and remains responsible for code quality. Three recommendations make it practical:
- The larger the change, the slower the review should be. When AI modifies hundreds of lines at once, do not rely on one uninterrupted read. Review one logical section at a time, or ask for several smaller changes. Small commits are themselves a risk-control measure.
- Establish team rules for AI-generated code: Document where AI may lead, which areas must be written by a person—security-critical and payment logic, for example—and which checks must pass before merging. Add the policy to the team's AI collaboration agreement.
- Use CI as a safety net: Type checks, linting, tests, and security scans automatically reject many mistakes and let human reviewers focus on semantics and design that machines cannot judge.
Frequently Asked Questions
Q: Does reviewing AI-generated code take longer than reviewing human-written code? A: Reading it may be faster because AI code is usually orderly, but verification takes longer because its boundary behavior and API use cannot be trusted. Do not spend the entire amount of time saved in coding; reserve enough of that budget for review.
Q: Does a tiny change need the entire checklist? A: Scale the checklist to risk. A one-line copy change does not require a ceremony. If a change touches logic, data, security, or an external call, apply every relevant item even if only a few lines changed. Risk is not determined by line count.
Q: How do I stop myself from becoming a rubber stamp? A: Enforce a “run before approval” rule: no AI change is merged without actual execution and verification. Running the change forces you to confront real behavior instead of being lulled by tidy code.
Summary
The principle for reviewing AI code is simple: the more correct it looks, the more carefully you must verify it. Define the scope first to prevent overreach. Focus on hallucinated APIs, edge cases, security, quiet behavior changes, fake tests, and overengineering. Then run the code. AI can help with the first pass, but when code reaches the main branch, you—not the model—are responsible.