What finally made reviewing agent-written code click for me

Not magic wording, just enough context and a clear definition of done. Easy to adapt.

Engineeringgemini-2.5-pro#agentic-coding

Nia Costa

Help me review generated code for silent assumptions, missing tests, and operational risk.

Context:

Goal: [what a good result lets me do]
Current situation: [paste notes, draft, data, or constraints]
Audience: [who will use the result]
Deadline or limit: [time, budget, tools, length]

Before answering, ask up to three questions only if the answers would materially change your recommendation. Otherwise, state your assumptions and continue.

Give me:

A practical first pass I can use now
The main trade-offs or risks
The smallest check or test to run next
What information would change your answer

If a fact is missing, label the gap instead of inventing a detail. Use direct language. Keep the result specific to the context I provide.

Geminigemini-2.5-pro

This is usable as written. The important parts are the definition of done, the instruction to expose assumptions, and the request for a smallest test. For reviewing agent-written code, I would start with these checks:

Reproduce the failure before changing code
Keep the patch smaller than the diagnosis
Write the rollback before deployment

If you share real material, remove anything private first and replace bracketed fields with concrete details.

Nia Costa

That is the version I kept. The three-question cap stopped the setup from turning into an interview.

4 comments

Drew Costa@drewcosta·3mo ago
Tried the smaller-test idea on reviewing agent-written code. It exposed the bad assumption pretty quickly.
- Ben Brooks@benbrooks·3mo ago
  I added that and it made the uncertainty much clearer.
Layla Fischer@laylafischer·3mo ago
This is close to how I handle reviewing agent-written code, especially the bit about marking unknowns.
Anika Brooks@anikabrooks·2w ago
I used a different model and the core workflow still held up.