Verification and quality gates for AI-generated code

For most of the history of software teams, the slowest step was writing the code. By the time a pull request appeared, the hard part was over. The author had already run it in their head and thought through the edge cases along the way. Review came last, and it was never the thing holding everything up.

That balance has flipped. A well-prompted agent turns out a working pull request in minutes, and the code still has to land safely. But it now arrives in one drop, so the checking happens afterwards, on a pile that keeps growing, reviewed by a team exactly the size it was last year.

Picture a team whose PR volume jumps from 5 a day to 25 the month they pick up AI tools. At 5 a day, careful review is easy. Run the same process against five times the volume and something has to give. It is almost always quality. Approvals get faster. Comments get shorter. The LGTM rate creeps up. A review that used to take an hour now takes five minutes.

None of that is laziness, just the only sane response to a workload that cannot be done properly. But the final safety check everyone is quietly counting on has turned into a rubber stamp, which gives you the reassurance of a safety net and none of the protection.

The layers are a stack of filters, each leaning on the ones before it. The early ones are cheap and fast and catch the bulk of the problems. The later ones are slower and pricier, and exist for the handful of things only a live system can reveal.

You sit outside the stack and above it, doing the work no layer can: setting the intent the pipeline builds toward, deciding which changes the machinery may merge on its own, and judging the few it routes up. The machinery settles whether the code is correct. You answer the question it cannot. Is this the right thing to build, built the right way?

An agent works in a loop: reason, act, observe, adjust. The observe step is what closes it. When you run the agent's new code through your tests, a failure becomes an observation the agent can act on. It reads the failure, works out what broke, and tries again. That is why a test suite is the main way an agent can tell whether its own changes actually work.

A good harness pushes this earlier still. The agent runs the whole local gate set (lint, type check, tests, build) before it ever opens a pull request. If something fails, the branch does not get pushed. The agent fixes the error and runs the gates again, and again, until everything is green.

It does not stop at unit tests. Hand the agent a headless browser through an MCP server and it can launch the app, click through a real user flow and look at what actually renders. It writes an end-to-end scenario, runs it, reads the failure, fixes the code, and runs it again. At that point the agent is driving the thing it built and repairing what breaks.

If you already have a CI pipeline, none of this is new. The only thing that changed is how hard you now have to lean on it, because the volume of code pouring through it just multiplied.

That gap is what LLM review fills. An LLM can read the diff the way a person would, weigh it against the intent and the code around it, and form a judgment. Unlike the deterministic gates it does not hand you a hard yes or no. It gives an opinion, and like any opinion it can be wrong. What it can do is reason about the questions no deterministic check reaches.

The review can run in three places, and they do not compete:

Most mature setups run more than one. The local pass kills the obvious problems before they are ever published. The PR-stage reviewer then gives the team a shared, visible second opinion.

That is the sycophancy problem pointed at review: models tend to agree with what is already in front of them. So do the opposite. Open a fresh session with no memory of writing the code, give it only the diff and the context, and hand it a hostile brief.

A fresh context with that framing turns up a surprising number of first-draft mistakes: the unhandled null, the off-by-one, the case nobody put in the original prompt. One more tweak probably helps, though treat it as a rule of thumb rather than a proven result. Run the pass on a different model. Reviewing code with the model that wrote it is like proofreading your own writing.

Does the change fit?

Is the change risky?

Is the change finished?

A well-tuned reviewer carries your conventions, your past incidents, your glossary, and a flat list of files it must never comment on, which is context engineering turned onto the reviewer itself. The shape matters more than the exact words:

# Role
You are a senior backend reviewer for our payments service.
Review the PR diff below. Be concise. Only raise issues that matter.
If the PR is solid, say so and stop. Do not invent problems.

# Our conventions
- All money values are integer cents, never floats. Flag any float math on money.
- Every external API call must have a timeout and a retry policy.
- Database access goes through the repository layer only. No raw SQL in handlers.

# Past incidents to watch for
- INC-204: a missing idempotency key caused double charges. Flag any new
  payment write that is not idempotent.
- INC-181: an unbounded query took down the DB. Flag queries without a limit.

# Do not review
- Anything under /generated or /vendor
- Snapshot test files (*.snap)

# Output
For each finding: file and line, severity (blocker / warning / nit), and a
one-sentence fix. End with a one-line verdict: APPROVE or REQUEST_CHANGES.

The conventions are concrete enough to check a diff against. Two real incidents become specific things to watch for, which beats "check for bugs" every time. The prompt says plainly what to ignore, killing a whole class of noise, and it pins down the output format so the result is quick to scan. Every time the reviewer gets something wrong, you edit this file and it sharpens.

This was always true. What changed is the volume. Ship 25 AI-generated PRs a day instead of five and your pre-merge layers catch a bigger share than they ever did, while the raw number that slip through still rises.

So the deploy itself has to become a safety layer. None of these techniques is new. Feature flags, blue-green, canaries and automated rollback are well-worn DevOps practice. What AI changes is the stakes. When more code ships faster with less human attention on each change, they go from being nice to have on the scary releases to being the layer that holds up the whole delivery process.

No feature flag can undrop a column. No blue-green swap unsends the duplicate emails your retrying worker already fired off. No canary uncharges the customers your non-idempotent payment job billed twice. Application code can usually be rolled back. State usually cannot.

An agent writing a migration sees the code, not the operational world around it. It does not know this table has half a billion rows, so it writes a migration that locks it for an hour. It does not know this consumer can receive the same message twice but must not act on it twice. It produces a change that is correct in isolation and dangerous in production, without a flicker of doubt. So stateful changes need more human attention, not less, even while the rest of the pipeline gets more automated.

Observability rests on three kinds of signal. Logs are timestamped records of discrete events. Metrics are numbers tracked over time. Traces follow one request through all your services. Those three are the raw material, and that has a blunt consequence. You cannot skip the instrumentation. An AIOps agent that promises to find your bugs is only as good as the signals it can read.

1. 01

   Anomaly detection

   Models that learn the normal shape of your traffic, latency and error rates, including daily and weekly rhythms, and flag outliers without you hand-tuning a number per metric. The most mature step in the loop. It deals in probabilities, though, so let it surface candidates for a human to look at and keep irreversible actions off it.

2. 02

   Post-deploy analysis

   A sidecar agent wakes on every deploy, compares signals before and after, and pins a regression on the PR that just shipped. Then it either trips the automated rollback or files a bug with the evidence attached. Flagging is safe and valuable. Acting on a fuzzy hunch with no human is where to tread carefully.

3. 03

   Root-cause analysis

   When an alert fires at 3am, the on-call engineer burns the first miserable stretch just gathering context. An agent pulls the traces, recent deploys, error stacks and dashboards and drafts a first cut of the timeline. Draft is the operative word. The agent assembles the evidence and proposes a cause, and the engineer confirms or corrects it.

4. 04

   Bug resolution

   An agent watches errors landing in your tracker, deduplicates against existing tickets, opens one with reproduction steps and a stack trace, and routes it to the team that owns the code. The same pipeline handles human reports. Only the trigger differs. Precision decides whether it helps or just recreates alert fatigue one floor up.

5. 05

   Back to the coding agent

   The ticket goes to a coding agent, which opens a draft PR with a candidate fix. That PR gets no special treatment whatsoever. It re-enters the exact pipeline above, from deterministic gates through LLM review to a flagged, canaried deploy, with a human approving at the gate.

Running the whole loop hands-off, with no human at the gate, is still aspirational. A few teams are stitching the pieces together. Almost nobody lets it run end to end unattended, and for anything that matters you should not want to yet. Build it anyway, one step at a time. Each piece is useful on its own, long before the full loop exists.

Your judgment is the scarcest, most expensive thing in the system, and the machinery's job is to spend it well. It should route to you only the changes where your attention changes the outcome, and let everything else flow through. Putting a human in front of every PR again would throw away everything the four layers just bought you.

This is the routing question, and it is the narrow end of a wider one. Human-in-the-loop collaboration covers the rest of it: which artifacts are worth reviewing, when an agent should stop and ask rather than wait to be checked, and how to trade speed against accuracy without guessing.

The gate covers the cases where you already know a human has to look. The scorer takes the long, ambiguous middle, where the honest answer is "it depends" and you want a fast, cheap recommendation instead of a hand-maintained rule.

# Any change to these paths requires human review.
services/payments/**
**/auth/**
**/*crypto*
**/migrations/**
infra/**
**/*.tf
.github/workflows/**

These are the spots where one bad merge will lose money, leak data or take production down. You can push the same idea further and match on the content of the diff as well as the path: a SQL DELETE or DROP, a call to a known dangerous function, the shape of a hardcoded credential, a feature flag being deleted instead of disabled. Still deterministic, still boring, which is precisely why it belongs in the gate and not the scorer. A destructive SQL statement is not a judgment call.

Deterministic matching only ever catches the patterns you can name in advance. It will never catch the subtle logic error, or the architecturally wrong but syntactically spotless refactor. That gap is what the scorer is for.

When the scorer is unsure, it must escalate to a human and never wave the change through. A scorer that fails open, defaulting to "looks fine" when it is confused, is worse than no scorer at all. It hands you false confidence at the exact moment the change was strange enough to confuse it.

You can stand one up today with a prompt:

# Role
You are a release risk assessor. You do NOT decide style or correctness.
You decide how much human review this change needs before it merges.
(The deterministic path gate has already run; you only see changes that
cleared it, so your job is the ambiguous middle.)

# Method
1. Read the file paths first. They tell you where the change lives
   (a service, a script, a config) and how much is at stake.
2. Weigh what the change DOES. Consider: blast radius, reversibility,
   test coverage of the touched code, diff size, and whether it touches
   a hot or fragile file.
3. If you are uncertain, round UP. Default to requiring a human.

# Output (JSON)
{
  "risk": "low | medium | high",
  "recommendation": "auto_merge | one_human | multiple_humans",
  "reviewer_domain": "e.g. payments, auth, frontend, or null",
  "what_could_go_wrong": "one or two plain sentences",
  "reason": "why this risk level, referencing the diff"
}

Deciding that a human is needed is only half the job. The other half is picking which human. Handing a payments change to someone who has never touched payments is a review in name only. A CODEOWNERS file maps path patterns to owners, and the reviewer_domain field above covers the cases where no ownership file applies.

Hunting for the missing null check or the off-by-one is no longer the point, because the machine does that better and faster than a tired reviewer at 5pm. The human does the thing only a human can do, which is judging intent and fit. Does this match the spec we agreed on? Does it move the system where we actually want it to go? Is this even the right thing to build?

That last question is the one no automated gate can answer, because it rests on goals that live outside the code. It is a better use of a senior engineer's time, and far harder to fake your way through than a line-by-line pass, which is part of why it is the right job to leave in human hands.

The cheap gates only earn their keep if nothing expensive runs ahead of them. An LLM reviewer needs the deterministic gates reliably green before it has a clean baseline to work from, so that it never burns its judgment on code that will not compile. Put a risk scorer on top of layers that do not yet catch the mechanical problems and you are just shipping bugs faster. And the AIOps loop wants instrumentation, clear SLOs and a safe deploy path underneath it before it can do anything except page you.

Assembling that, and knowing when your team is ready for the next layer, is its own body of work. It did not fit in an essay.