A 2025 study of 470 pull requests found that AI-generated code shipped roughly 1.7x more issues and about 1.4x more critical defects than human-written code. Nobody serious reads that as “AI code is bad,” and I’m not arguing it either; much of what an agent writes is clean, idiomatic, and correct. The trouble starts when you sit a real workflow on top of that number: volume times defect rate, pointed at the part of the system that hurts most when it breaks.

Think about what changed in your loop this year. You went from typing most of your code to reviewing most of your code. The agent proposes, you skim, you approve, you move on to the next thing, and you do that many more times a day than you used to write functions by hand. Throughput went up, and judgment calls per hour went up with it. Now the study says the defect density of what’s flowing through that faster pipe went up too. So there’s more code, with more defects per unit of it, and more of the critical kind; every multiplier stacks in the wrong direction.

Now ask which defects you catch when you review. The correctness ones, mostly, because those are what review is good at. Wrong output, an off-by-one, a null you didn’t handle, a test that goes red. What you don’t reliably catch, skimming an agent’s diff at speed, are the reliability defects: the retry with no backoff, the unbounded concurrency against a downstream that can’t take it, the new call inside a hot path that quietly couples two services that were independent yesterday. Every one of those is correct code. It compiles, it passes, it does what you asked. A compiler stops when something is wrong, but nothing stops you when the correct code you just approved is how an outage starts.

Why the agent makes this worse

An AI coding agent works from context it doesn’t fully have. It sees the file, maybe the neighboring files, maybe a chunk of the repo. It doesn’t see how your services actually talk to each other under load, which dependency is already running hot, what your last three incidents were about, or that this exact retry pattern took down a system a lot like yours somewhere else last year. Reliability lives in the interactions between components, and the interactions are the one thing the model can’t see. So it writes each piece plausibly and locally correctly, and the risk accumulates in the gaps between the pieces, which is where incidents come from.

The agent is a fast, capable, cheerful contributor with no memory of production and no scar tissue. It has never been paged. I don’t mean that as a knock on the tool (I use one constantly); I mean it as a description of where the tool needs backup. Reliability judgment is exactly the kind of thing you’d want a machine to hold for you, because the human reviewing forty diffs a day can’t hold all of it either.

The expensive place to find out

So where does the reliability defect get caught today? Usually one of three places, in ascending order of cost.

Sometimes in CI, if you have a check for it, which for reliability you almost certainly don’t. And even when CI catches something, CI is the worst-feeling place to get blocked. You’ve already context-switched to the next task, and now you’re yanked back to a diff you mentally filed away twenty minutes ago, waiting on a pipeline to tell you what a check at your keyboard could have told you instantly.

Sometimes in production, at 2am, as an incident. This is the expensive one. High-impact outages run a median of roughly $2M per hour, and that’s before you count the on-call burnout, the trust you spend with customers, and the day of engineering that goes to the incident review and follow-up instead of the roadmap. The reliability defect a review missed doesn’t disappear; it sits in production waiting for the load pattern that trips it, then bills you at the worst possible rate.

And often, on a mid-market team, nowhere at all until it becomes an incident, because there’s no SRE whose job it is to be looking. The AI made you faster without hiring the person who catches what that speed introduces. If you have SREs, this is the work that lands on them after the fact; if you don’t, it’s work nobody currently owns.

Move the check to where the code is written

Slowing the agent down isn’t the fix; keep using it for the things it’s good at and you’d rather not do by hand. What needs to move is the reliability check. Put it where the agent already works: the local dev loop, before the commit, while you still have the context that produced the change.

This is the part I think most people don’t understand yet. Because AI writes more of the code now, the leverage point moved earlier, to the moment of authorship. If reliability context is in front of the agent while it writes, the agent gets the timeout, the backoff, and the circuit breaker right the first time, and there’s no defect to catch later. A code-review bot works from the other end: it reads the finished result at the pull request, after the design decisions are already woven into the change, which is exactly when design-level reliability defects get expensive to undo. By all means keep a CI check as a backstop. But authorship is where this problem is cheapest to fix, by a wide margin.

That’s what Revelara does. It runs inside the coding agent, over MCP, and reads the change you’re about to make for reliability risk, in seconds, before you commit. It skips style and correctness and looks for the outage-shaped stuff, and it isn’t pattern-matching against generic best-practice lint. Its findings are grounded in a corpus of thousands of real public production incidents, so when it flags the unbounded retry, it can often point at the kind of real outage that pattern has caused. The finding reads less like “consider adding backoff” and more like “this is the retry pattern behind real production floods, here’s the mechanism, here’s the call site.” The findings come from real incidents. And it doesn’t wait for CI to block you or for production to page you. And yes, you can bring your own data as well.

So the year adds up like this: AI writes more of the code and ships more of the defects, and the critical ones concentrate in the problems your review is worst at seeing and your infrastructure is most expensive at surfacing. You can meet that risk at 2am, or you can meet it at authorship time, in the tool you’re already typing in, before it gets a chance to page you. One of those runs a median of $2M per hour. The other takes a few minutes and some tokens.