Diff Review Loops

The most dangerous moment in AI-assisted development: you're looking at a diff that looks correct. Code is clean, logic seems right, tests pass. You approve it. Two days later, bug in production.

AI-generated code has a specific failure mode — correct for the happy path, wrong for the edge cases. The code looks right because the structure is right. The bug is in the behavior.

The diff review mindset

Reviewing an AI diff requires a different mindset than reviewing a human-written one. With human code, you're checking for mistakes. With AI code, you're checking for plausible-looking mistakes — code that looks right but isn't.

A concrete example: you ask the model to add pagination to a list. It returns this:

const start = (page - 1) * pageSize;
const end = start + pageSize - 1;
return items.slice(start, end);

Looks right, but slice treats its end index as exclusive. Subtracting one means every page returns pageSize - 1 items. A test that only checks the first item or verifies that the result is non-empty can still pass while every page silently drops its final item.

The code is clean, the logic is almost right, and nothing in the diff signals the problem. That's the failure mode.

Questions I ask:

• What edge cases does this not handle? The model tends to handle the cases it was asked about and miss the ones it wasn't.
• Does this change the behavior in ways that aren't visible in the diff? Changing a function's return type, modifying shared state, altering execution order.
• Are the tests testing the right things? AI-generated tests often test the happy path and miss the edge cases.
• Does this introduce any implicit dependencies? New imports, global state, environment variables.

Ask the model to break it

After the model generates code, ask it to try to break it. "What inputs would cause this to fail? What edge cases does this miss?"

Works because the model is in a different mode — looking for problems rather than generating solutions. It often finds issues it missed during generation.

Patterns that indicate risky diffs

Patterns I've learned to scrutinize:

• Simplified conditionals. The model often simplifies complex conditions. Sometimes correct, sometimes it removes an edge case handler.
• Changed function signatures. Even small signature changes can break callers in non-obvious ways.
• New async/await patterns. Async code is where subtle bugs hide. Any change here deserves extra attention.
• Modified error handling. The model tends to add or remove error handling in ways that change behavior silently.