Turn the AI into a demanding reviewer on readability, bugs, and security, and sharpen your judgment by defending your choices against its remarks.
Open this lesson in KodokonPeer code review is one of the most well-documented accelerators of growth in the field - and one of the hardest to access when you work alone. AI offers a reviewer available around the clock, on one condition: you have to configure it. By default, a model is compliant: it praises your effort, flags two trifles, and concludes that "overall, this is good work." That's not a review, it's a pat on the back. The mirror-image mistake is asking "rewrite my code cleanly": you get code you never reasoned through, and you learn nothing. The right approach: demand a structured critique - readability, bugs, security - with calibrated severity and justifications.
You're a demanding senior reviewer, as in a team code review. Your goal is to make me improve, not to go easy on me.
Here's my code ([language], context: [what it's for, the project's constraints]):
[paste the code]
Analyze it along three axes:
1. Readability: naming, structure, needless complexity, unclear intent.
2. Bugs: unhandled edge cases, silent errors, inconsistent states, concurrency.
3. Security: unvalidated inputs, injections, exposed sensitive data, permissions.
Output format: for each remark - the line or block concerned, the axis, the severity (blocking / important / minor), and the WHY in one or two sentences.
Constraints: don't rewrite my code. At most 8 remarks, the most serious first. If a debatable choice can be defended depending on the context, say so explicitly instead of counting it as a flaw.Notice the cap of 8 remarks ranked by severity: without it, you get 25 nitpicks where a missing input validation weighs the same as a naming preference. Notice too the clause on defensible choices: it forces the model to distinguish the objective flaw from the debatable convention. Then comes the most formative part, the one almost everyone skips: defending your choices. A review isn't a verdict to apply, it's a dialogue. When a remark seems unjustified, argue back. Either your reasons hold and you've finally spelled them out, or they collapse and you discover that this "choice" was just a habit.
Let's revisit your remark number [X]: you consider that [restate the remark].
I disagree, and here are my reasons: [your arguments - measured performance constraint, consistency with the rest of the code, deliberate simplicity, deadline...].
1. Honestly assess each of my arguments: which hold, which are rationalizations?
2. Give the strongest possible counter-argument to my position, as an experienced colleague who disagrees would.
3. Conclude: in MY specific context, is the change worth its cost? Answer yes or no, then justify in three sentences maximum.
Don't try to prove me right: if my arguments are weak, say so bluntly.Two classic traps of AI review. First trap: false alarms delivered with confidence - the model flags a race condition that's impossible in your architecture, or a "bug" that isn't one in your version of the language. Treat every remark as coming from a brilliant colleague who doesn't have access to all the context: plausible, to be verified. Second trap: security theater. The AI is very good at spotting classic patterns (SQL injection, XSS, cleartext secrets) but misses business-logic flaws - a missing authorization check on a route, an exploitable intermediate state. An AI review complements, it replaces neither an audit nor your domain knowledge.