Review a diff for production risks

Review this change for what breaks in production. Ignore style.

Diff:
[PASTE THE DIFF]

What this change is meant to do: [ONE OR TWO SENTENCES]
Where it runs: [SERVICE, AND WHETHER IT IS A REQUEST PATH, JOB, MIGRATION, OR STARTUP]
Scale it sees: [REQUESTS OR ROWS, ROUGHLY]
What it talks to: [DATABASE, QUEUES, EXTERNAL APIS, CACHES]
How it gets deployed: [ROLLING, ALL AT ONCE, BEHIND A FLAG]

Produce four sections.

1. WILL BREAK — things that fail under conditions this code will actually meet: empty and enormous inputs, concurrent execution, partial failure of something it calls, retries, a request arriving mid-deploy while old and new code both run. For each: the condition, what happens, and how bad.

2. WILL DEGRADE — no error, worse behaviour. Queries whose cost grows with data, work added to a hot path, a lock or transaction held longer, unbounded memory, a new synchronous call to something that can be slow.

3. NOT COVERED BY TESTS — go through the behaviour this diff introduces or changes and say which parts no test in the diff exercises. Name the specific case, not "add more tests". Include error paths and the boundaries of any new condition.

4. IRREVERSIBLE — anything that cannot be undone by rolling back the code: schema changes, data written in a new shape, messages published, external calls with side effects.

Rank sections 1 and 2 by expected damage. If the diff is missing context you need, say which file. Do not comment on formatting or naming.

The reason a passing review does not prevent an incident is that reviewing reads the code, and production runs it — against data nobody wrote a fixture for, at a concurrency nobody simulated, while a deploy is halfway through and two versions of the code are live at once. Asking plainly for a review gets you a competent read of the code as written: naming, structure, an off-by-one. Useful, and not the thing that pages you at night.

This prompt names the production conditions explicitly, which is the whole trick — the model is entirely capable of spotting the query that gets slow at a million rows or the migration that breaks the old code still serving traffic, but only if it is asked about that rather than about the diff in the abstract. That is also why the context questions matter: a change to a request path and the same change in a nightly job have different failure modes, and without knowing which one it is the review defaults to generic.

Section three is the second output. Naming which specific new behaviour has no test is more useful than any coverage number, and it is the section people find uncomfortable, which is a reasonable sign it is working.

1. Give it the deploy model

   Rolling deploys mean old and new code run simultaneously for minutes. A large share of real incidents live in that window, and it is invisible from the diff alone.

2. Be honest about scale

   'A few thousand rows' and 'forty million rows' produce completely different section-two findings. If you do not know the number, say the order of magnitude.

3. Include the tests in the diff

   Section three needs to see what you tested. Without the test files it will list everything as uncovered, which is noise you will learn to skip past.

4. Push back on findings that do not apply

   Tell it which constraint makes a finding impossible — 'this only ever runs single-threaded' — and ask it to redo the ranking. That is faster than re-reading the diff yourself, and it usually surfaces something adjacent.

• On a diff that touches many files at onceIt sees the changed lines, not the system. Cross-file interactions and callers outside the diff are where it is weakest — review large changes in coherent pieces.
• For security review specificallyIt will notice obvious injection and missing authorisation. It will not reason reliably about your threat model or your auth architecture, and a clean answer here is not a security sign-off.
• When the risk is in the design rather than the codeA well-implemented wrong approach reviews cleanly. This finds failures within the chosen approach; it will not tell you the approach was the mistake.

• CodingRagnarökDebug a stack traceTurns an error and its stack trace into an ordered list of what could cause it, each with the specific check that would rule it in or out.
• CodingApolloWrite a spreadsheet formula and understand itBuilds the Excel or Sheets formula you described, explains each part, and supplies the data that makes it return the wrong answer without erroring.
• CodingApolloWrite and test a regex or SQL queryWrites the pattern or query you asked for, explains it piece by piece, and then supplies the inputs that make it silently return the wrong thing.
• WritingApolloRemove AI tells from a draftRewrites text that reads as machine-written, then lists the specific phrases and structures that gave it away so you stop producing them.