How we keep AI-generated code reviewable

A growing share of the code we ship starts as a prompt, not a keystroke. An agent drafts the change, runs the tests, and hands us a pull request. That’s a genuine speed-up — but it quietly moves the hard part of the job. When a model can produce a plausible four-hundred-line PR in minutes, “looks fine” stops being a safe thing to say. This post is about how we keep AI-generated code to the same standard as anything else that carries a client’s name.

The bottleneck moved, so we moved with it

For years the expensive step was writing the code. Review was a lightweight check on top of slow, deliberate work. That ratio has flipped. Writing is now the cheap part; understanding, deciding, and verifying are what take the time. So we stopped treating review as a formality and made it the centre of gravity. We don’t review keystrokes — we review intent and behaviour: did this do what we actually wanted, and was what we wanted correct in the first place?

Small diffs, still

A model will happily generate a sprawling change that touches twelve files when the task needed two. We don’t let it. The old discipline matters more now, not less: one logical change per pull request, scoped tightly enough that a human can hold the whole thing in their head. If an agent’s output sprawls, that’s not a review comment — it’s a signal to reject the diff and re-prompt with a narrower brief. Reviewer attention is the scarce resource now, and we spend it deliberately.

The prompt and the plan are part of the review

Because the code is cheap to regenerate, the thing worth getting right is the specification behind it. We keep the ticket as the single source of truth — the intent, the constraints, the designs, the edge cases all live in one place, not scattered across a Slack thread. A PR is reviewed against that ticket, and half the value of the review is checking the brief, not just the output. A model that faithfully builds the wrong thing is still building the wrong thing.

We read it like we don’t trust it

AI-generated code fails in its own characteristic ways, and we review for them on purpose:

• Confident invention. Calls to APIs, flags, or fields that look exactly right and don’t exist. Plausible is not the same as real.
• Subtly wrong edges. The happy path works; the empty list, the timezone, the retry, the null all quietly don’t.
• Over-broad changes. A one-line fix that also “helpfully” refactored an unrelated module, or removed a guard clause it didn’t understand.
• Silent scope creep in dependencies. A new package pulled in to solve something we already had a way to solve.

And we don’t just read it — we run it. If we can’t reproduce the behaviour the PR claims, the PR isn’t done.

Tests are the contract, not decoration

Models write tests, too. But a test the model wrote to make its own code pass is not evidence that the code is correct — it’s evidence the code is consistent with itself. So we treat the tests as the part we most need to own. We write or curate the cases that define correct behaviour, we add the adversarial ones the model wouldn’t think to, and we read every generated test asking a single question: would this actually fail if the code were wrong? Behaviour covered, not lines counted.

Guardrails that don’t depend on the reviewer being perfect

Human judgement is the last line, not the only one. Everything an agent produces goes through the same automated gate as everything else: type checks, linting, and the security scanning in our Secure SDLC — dependency review, secret detection, static analysis. The machine catches the mechanical failures so the human can spend attention on the ones that need judgement. And one rule doesn’t bend: a person owns the merge. The model can propose; it never approves.

Why it matters

The accountability never moved. When we ship to a client, their system is our responsibility regardless of whether a person or an agent typed the diff — and “the model wrote it” is not something anyone wants to read in a post-mortem. Used well, AI lets a small team move at a speed that used to require a large one. Reviewability is what keeps that speed from turning into risk: it’s the difference between shipping fast and shipping things you can stand behind.

If you’re weighing how to bring AI into a codebase you have to keep trustworthy, we’re happy to talk.