Template — review this

and why you shouldn't ask in the same chat

What it is

A review is a request to find problems in code. It has a peculiarity the others don't: an AI is bad at criticising code it has just written itself. In the same conversation it tends to confirm its decisions rather than challenge them.

So a review almost always starts by moving the code into a clean session.

What it looks like in code

Bad

Review this code

With no indication of what to look for, you get a list of generalities: "add error handling", "use type annotations", "extract the constants". All true and all useless — the same list could be written without looking at the code.

Good

Here is a function from my project. I didn't write it;
I need an analysis.

Look in this order:
1. Cases where it returns a wrong result silently, with no error
2. Unhandled edge cases: empty data, None, a dropped connection
3. Anything that breaks if it is called from two places at once

Don't comment on style or naming.
For each finding: what breaks and on what data.
If there are no findings, say so — don't invent any.

<code>

Three differences: the order of importance is set, the noise is cut off, and finding nothing is explicitly allowed.

The sentence that changes the result

Here is a function from my project. I didn't write it.

It takes away the AI's role as the author defending their work. Easy to verify: ask for a review of your own code in the same chat and in a new one — the difference is immediate.

What to tell the AI

Set an order, not just a list

Without priorities a review turns into twenty items where a typo in a comment sits next to data loss. Ask for them sorted by the weight of the consequences:

Sort the findings from the most dangerous to the most trivial.
For each one, say what happens if it isn't fixed.

Allow it to find nothing

An AI tends to produce findings because that is what it was asked for. If there are none, it will invent some. One sentence removes that:

If there are no serious problems, say so plainly.
Don't make up remarks.

Three questions instead of a review

When the whole code does not need going through, short, targeted questions work:

Is there a place here where data can be lost without an error?

Which of this breaks if the function is called twice in a row?

Which line would you rewrite first, and why?

The last one is especially good: it forces a choice rather than a list of everything.

What to look for

A review made of generalities. "Add logging", "think about performance" — remarks that fit any code at all. A sign the prompt never said what to look for.

Invented problems. The AI cites library behaviour that doesn't exist, or an edge case impossible given the project's logic. Check against the code and the docs.

The main thing missed. No findings does not mean the code is good — only that the AI found nothing. It does not cancel your own check.

Reviewing its own code in the same chat. The most common mistake. A new session costs thirty seconds and changes the quality of the analysis more than any wording does.

Cheat sheet