Reviewing Code You Did Not Write

You already know how to review a colleague's pull request. Generated code needs a different pass, because it fails in different places.

A colleague's code is usually wrong because they misunderstood the requirement. Generated code is usually wrong because it produced the most statistically typical version of what you asked for — which is subtly not your version.

The six checks, in order

1. Does every import and API call actually exist? Invented functions are the single most common failure. Your editor catches most of this instantly — trust the red squiggle over the confident explanation
2. Are the error paths real? Models love `catch (e) { console.log(e) }`. Swallowed errors are how a bug becomes a silent bug
3. Are the edge cases handled? Empty array, null, zero, a string where a number was expected. Generated code is written for the happy path unless you ask otherwise
4. Does it match your conventions, or its own? Correct code in the wrong house style is still a maintenance cost
5. Are there new dependencies? Models reach for a package where four lines would do. Every dependency is a permanent obligation
6. What does it do with untrusted input? String-concatenated SQL, unescaped HTML, unvalidated request bodies — this is where generated code is genuinely dangerous

Plausible-but-wrong: what it looks like

• Off-by-one in slicing and pagination — the logic reads correctly and the boundary is wrong
• Comparing floats with `===`, or rounding money in the wrong place
• Timezone handling that works on your machine and breaks in UTC
• `async` functions where the return value is never awaited — no error, just a promise nobody resolved
• Retry loops with no backoff and no maximum, which turn a brief outage into a self-inflicted denial of service
• Caching with no invalidation, which works perfectly until data changes

Using a model to review a model

Asking a second, fresh conversation to review the code works better than you might expect — it has no attachment to the earlier answer, so it is not defending anything.

Give it an adversarial brief. 'Review this' produces compliments. 'Find the input that breaks this' produces findings.

Review this function as a hostile reviewer.

For each problem: the exact input or condition that triggers it,
what goes wrong, and the minimal fix.

Check specifically:
- edge cases (empty, null, zero, very large)
- error paths that are swallowed or misreported
- concurrency: what happens if this runs twice at once
- untrusted input reaching a query, a filesystem path, or HTML

If you find nothing serious, say so — do not invent issues.

[code]

The habit that matters most

Run it before you believe it. Not the whole suite — just enough to prove the thing exists and does roughly what it claims. A one-minute check beats twenty minutes of careful reading, because the failures that matter most here are the ones that show up immediately.