my-git

How to Review AI-Generated Code

English

The risk with AI-generated code is that it often changes boundaries, semantics, dependencies, and long-term maintenance costs while in a state that “looks reasonable.”

When reviewing AI code, review the intent first, then the diff, and then the validation.

1. Review Order

Understand Intent First

Ask first:

What problem is being solved this time?
What are the success criteria?
Which behaviors should not change?
What are the scopes of impact?

For an AI diff without clear intent, do not enter code details first.

Then Look at Diff Size

git diff --stat

If the number of files is too large, split them first:

Behavioral fixes
Test additions
Refactoring and cleanup
Documentation descriptions
Dependency or configuration adjustments

Then Look at Behavioral Changes

Focus checks on:

Public API
Error codes
Configuration default values
Database reads and writes
Concurrency and retries
Permissions and security
Compatibility

Finally Look at Tests

AI-written tests easily verify only “the implementation it just wrote” and do not verify real business boundaries.

Good tests should answer:

Will it fail before the fix?
Does it cover exception paths?
Does it cover boundary conditions?
Is it just proving itself correct in a mock?

2. High-Risk Signals

Large amounts of irrelevant formatting
Modifying multiple business problems at once
Adding a new abstraction but with only one call point
Changing configuration without explaining runtime impact
Modifying lock files without explaining dependency changes
New tests not asserting core behavior
Deleting exception handling or swallowing errors
Modifying public API without compatibility notes
Appearance of hard-coded tokens, keys, accounts, or internal addresses

3. Review Checklist

I can explain the goal of this change in one sentence.
The diff can be reviewed within a reasonable time.
Irrelevant changes have been split out.
Behavioral changes are clearly marked.
Error handling has not become weaker.
Tests can prove real behavior.
No sensitive information has been added.
No unnecessary dependencies have been introduced.
The rollback path is clear.

4. Prompt Examples

Let AI Perform Risk Review

Please review the current git diff.
Output only specific risks, do not provide vague summaries.
Focus checks on: behavioral boundaries, compatibility, error handling, test validity, security risks, and irrelevant changes.
Give file paths, risk descriptions, and suggested modification methods for each problem.

Let AI Split Commits

Based on the current git diff, please suggest how to split it into multiple logical commits.
Provide a title, included files, and reason for splitting for each commit.
Do not modify files.

Let AI Generate PR Description

Please generate a PR description based on the current git diff.
Include What changed, Why, How tested, Risk, and Rollback plan.
Mark content that cannot be confirmed from code as "requires manual input."

5. Humans Assume Final Responsibility

AI can help you find problems faster, but it cannot assume merge responsibility for you.

The final reviewer should at least confirm:

They understand this change.
The validation results are credible.
The risks and rollback plans are acceptable.
They can locate responsibility boundaries if problems occur after merging.

6. How to Use AI Review Tools

AI Review tools are suitable for the first round of scanning, especially for finding obvious bugs, test gaps, security risks, irrelevant changes, and maintainability issues.

Teams should maintain three boundaries when using them:

AI review results do not constitute owner approval.
High-risk directories still require human owner review.
False positives and false negatives of AI review should be periodically reviewed.

Put AI review results into the PR process, but do not let them replace human merge judgment.

Extended Reading

This site is open source. Improve this page.