Guides·27 July 2026·7 min read

Why AI coding assistants miss deep performance bugs — and how to catch them anyway

Ask engineers what they still don't trust AI coding with and the answers cluster tightly: deep performance work, scalability, the failure modes you only meet at 3am. The scepticism is earned — but the usual conclusion (“so a human must review everything”) doesn't scale at AI generation speed. It's worth being precise about why assistants miss these bugs, because the why points at the fix.

The bug the assistant can't see in its own diff

Here's the shape, reduced to its essence — twelve plausible lines:

looks fine in a diff

async function applyRefunds(orderIds) {
  const results = [];
  for (const id of orderIds) {
    const order = await api.getOrder(id);      // roundtrip per item
    const refund = await api.refund(order);    // second roundtrip per item
    results.push(refund);
  }
  return results;
}

It passes tests (fixtures have three orders). It reads fine (idiomatic async/await). In production with 100 orders it's 200 sequential roundtrips — tens of seconds on a blocking path — and it trips the payment provider's rate limit partway through a batch of refunds, leaving money in an inconsistent state. When we run this class of snippet through our own gate it comes back REJECTED — 30.8/100, with the latency arithmetic spelled out. The verbatim verdict is on the MCP page.

Why generation can't self-check this

The defect isn't in the tokens. Every line is individually correct. The bug lives in the product of loop size × latency × rate limit — quantities that appear nowhere in the code the model is scoring itself on.
Training data rewards the shape. Loop-and-call is the most common pattern for this task online. Fluency and correctness diverge exactly here.
Self-review inherits self-blindness. Asking the generator to review its own output re-runs the distribution that produced the bug. It usually says the code looks good, because by its lights it does.

What deep review actually requires

Catching this class of defect requires review that is independent of the generator and structured around production quantities, not code aesthetics:

Complexity on the I/O path, not just big-O on CPU: roundtrips per request, per item, per retry.
Concrete arithmetic against realistic scale — what does N=100, N=10,000 do to latency, memory, connection pools?
Rate limits and quotas of every external service on the path, checked against the worst-case call pattern.
Blocking behaviour: what thread or event loop does this occupy, and for how long?
Failure-mode review to a published standard — ISO/IEC 25010 reliability and performance-efficiency characteristics — so the bar is stable across changes and models.

None of this is beyond automated review — it's beyond self-review. An external gate that receives the diff, reasons about scale, and returns severity-ranked findings with the math catches the N+1 in seconds. The same gate has veto power over the reality failures (invented APIs, faked outcomes, mocks in the wire path) before performance review even begins.

Wiring it into the loop

The place to run deep review is inside the assistant's own loop, via MCP: the assistant calls validate_ai_output before presenting work, analyze_code for an on-demand deep pass, and fixes findings while the context is hot. Setup is a one-block config in Claude Code, Cursor or Windsurf — the step-by-step is in our setup guide.

The standard to hold

“AI can't do deep performance work” is half right: generation can't, reliably. Generation plus an independent, veto-empowered review that does the production arithmetic is a different system — one where the bug above never survives to a pull request, whichever model wrote it.

FAQ

Why do AI assistants write N+1 bugs so often?

Because the N+1 shape — loop over items, call an API or query per item — is locally correct and extremely common in training data. The defect only exists at the interaction of loop size, network latency and rate limits, none of which are visible in the snippet the model is optimising to look right.

Won't tests catch performance bugs?

Rarely. Unit tests run with N=3 fixtures and mocked I/O, which is precisely the configuration where an N+1 or a blocking call is invisible. Performance defects need review that reasons about production scale — item counts, roundtrip latency, rate limits, thread pools — before the code merges.

Can a review gate really quantify a performance bug?

Yes, when it reasons from the code's structure: 100 items × 1 synchronous roundtrip ≈ 100 roundtrips ≈ 10–20 s on typical API latency, on a blocking worker thread, against a provider limit of 100 req/s. That arithmetic is exactly what a validation gate can produce in seconds, per change.

Put a real gate on your AI output.

Verificate MCP runs deterministic reality gates plus an enterprise-grade review on every AI output — in Claude Code, Cursor, Windsurf or any MCP client. 30-day free trial, no card required.

Start 30-day free trial See how the gate works