Gains:
- Ability to use AI as an initial review filter with categories and severity tags
- Ability to filter findings with human mind to verify/false positive/apply
- Ability to enforce human approval requirements on business rule, architecture and security-critical decisions
Code review is when a change written by a developer is reviewed by someone else before it is merged. Good review; It catches bugs early, shares information, and keeps the code base consistent. But reviews are tiring, prone to distraction, and become superficial under time pressure. Artificial intelligence is a two-fold assistant here: it allows you to both pre-clean your own code that you submit for review and to examine someone else's PR (pull request) with a sharper eye.
The critical distinction is this: AI speeds up and enhances review, but it cannot take over the responsibility for approval. The sentence "AI looked, it's clean" is not an endorsement. The final "merge" decision is up to an engineer who knows the code and context.
What AI is Good and Bad About in Review
Good for: Null check misses, resource leaks (file/link remaining open), uncaught exceptions, obviously wrong conditions (>= instead of >), renaming suggestions, readability, missing edge case, simple security smells (like SQL string concatenation), duplicate code detection.
Weaknesses: Deep flaws that violate your business rule but require context and timing, such as syntactically correct logic, architectural compliance, real performance bottlenecks, concurrency errors. AI also produces false positives (mistaking something that is not actually a problem for a problem) and false negatives (missing the real bug). Therefore, its output is a "caution list", not a definitive verdict.
Caution: Just because the AI says "no problem" does not prove that the code is correct. False negatives are silent; The most dangerous mistakes are those that are never mentioned in the review.
Systematic Review Steps
- Give the context. Add the purpose of the change, the relevant issue and the acceptance criteria, if any, to the prompt. Purposeless review produces purposeless interpretation.
- Break it down into categories. Ask the model to classify the findings as "bug/security/performance/readability/style"; so you separate the critical from the noise.
- Request a severity label. Give each finding a "high/medium/low" rating and include "cause" and "recommended correction."
- Filter it with your own eyes. Evaluate each finding: is it real (verify), is it a false positive (write justification), is there anything missing (add your own knowledge).
- Verify critical paths manually. Read and execute routes involving money, identity, authorization and data deletion yourself without relying on AI.
Three Mini Cases
Case 1 — Silent null error caught. One team had AI pre-review a 380-line PR. The model flagged a way in which an external service response could be null, but no checks were made for this in the code. The human reviewer verified this path and added a null check; A similar error caused a 2-hour interruption in production in the previous quarter.
Case 2 — False positive elimination. The AI flagged a “possible performance issue” in a loop. The reviewer closed this as a false positive, knowing that the loop only works with a maximum of 5 elements (it loops over an enum). The model, who did not know the context, warned; The person who knew the context made the right decision.
Case 3 — AI missed business rule error. While a discount account should be a maximum of 30% according to the campaign rule, the code allowed 50%. The AI never noticed this syntactically perfect logical error; because he didn't know the rule. The bug was caught in the review by the product owner who knew the acceptance criteria. Lesson: business rule validation is a human job.
Four Copiable Templates
Purpose-oriented, categorized review:
Role: Meticulous code reviewer. Purpose of change: {{purpose / issue}}Review this diff. Provide findings in these categories: [Bug] [Security][Performance] [Readability] [Style]. For each finding: file:row, severity(high/medium/low), cause, recommended fix. Mark "possible" if you are not sure. You don't know the rules of business; Ask me about places that require rules.{{diff}}
To prepare to review your own code:
Review this change before opening a PR. Look for: missing null/bugcheck, resource leak, edge case, secret, untested branch. List the findings in order of priority; suggest correction 1 line for each.{{code}}
Edge case hunt:
List the inputs and situations where this function might break: empty, null, too large, negative, concurrent call, network error, partial data. For each case, write the expected behavior and what the current code will do.{{function}}
Security scent scanning (pre-screening):
Look for common security smells in this code: SQL/command concatenation, unvalidated input, immutable embedded secret, insecure deserialize, lack of privilege checking. Separate the findings into "certain / probable / knowledge". This is a preliminary screening; It is not a definitive ruling.{{code}}
Weak prompt / Strong prompt
Weak: “Is there a mistake in this PR?”
Strong: "Purpose: add coupon discount to cart total (discount must be no more than 30% — you can't verify this rule yourself, just tell me if the code imposes an upper limit). Examine diff; give findings by category + severity + suggested correction, mark 'possible' if unsure. [diff]"
The strong version clearly states the intent, business rule, and boundary of the AI; Thus, useful findings come and the area unknown to the model remains clear.
Finding type
AI reliability
man's role
Null/error check missing
high
Verify and apply
Readability/style
high
Choose by preference
Simple security smell
medium
Finalize, scan with vehicle
Business rule compliance
low
It's entirely human.
Concurrency/architecture
low
Expert review is required
AI Review Is Not a Replacement for Human Review
Position AI review as a “first filter”: a cheap, fast, tireless preliminary pass. This filter frees the human reviewer's attention from unimportant details (a space, a name) and directs it to places that really require thought—the business rule, the architecture, the security result. But merge approval is the signature of an accountable person within the team. Independent review by at least one competent engineer is mandatory for safety-critical changes.
Tip: Read the list of findings that the AI produces as a “things to check” rather than a “to do”. Either verify and apply each item or write down in one sentence why you passed it; this trace makes the review auditable.
Common mistakes
- It means "AI looked, it's clean". This is a false sense of confidence because of false negatives.
- Not giving context. Without purpose and acceptance criteria, the model produces only superficial style interpretations.
- Blindly applying false positives. Fixing every warning of the model could break running code.
- Asking the model about the business rule. The model does not know the rule; It is up to man to verify it.
- Do not discriminate against violence. Putting a critical security finding and a name suggestion in the same bag overshadows what is important.
In summary
AI is a tireless first filter in code review: it catches null/error misses, edge cases, and simple security smells well; but it is weak on context-requiring flaws such as business rule, architecture, and concurrency, and produces both false positives and false negatives. Request findings by category and severity, filter each with human intelligence, manually verify critical paths. Approval is always the signature of an accountable engineer.
Application task
Select a real or recent PR/diff. First, have the AI review it with the “objective-oriented, category review” template. Put the findings in a table and decide for each one: true (I verified), false positive (here's my reasoning), or to be implemented. Then take a tour yourself and try to find at least one thing (especially a business rule or edge case) that the AI is missing and write it down.
checklist
- [ ] I use AI review as a first filter, not an endorsement.
- [ ] I add the purpose and acceptance criteria to the review prompt.
- [ ] I separate the findings from the noise by category and strongly wanting them.
- [ ] I consciously filter each finding to confirm/false positive/apply.
- [ ] As a human, I check business rule and architectural compliance.
- [ ] I require approval from a qualified engineer for safety-critical changes.