Johnny Unarthe numbers that should worry you
CloudBees ran a survey of more than 200 tech leaders earlier this year and the result is the kind of thing you read twice because the two halves contradict each other. 92% said they felt confident about their code before it shipped. 81% reported more production failures coming out of AI-generated code than they had a year ago. Both numbers came from the same people. Sit with that for a second, because it's not noise, it's a signal about how broken the feedback loop has become between what your CI tells you and what actually happens when the code meets real traffic.
Lightrun's telemetry puts a sharper edge on it. They found 43% of AI-generated changes needed debugging in production after passing QA. Not after skipping QA. After passing it. So almost half of the AI code that cleared every gate your team built, the linters, the unit tests, the integration suite, the staging smoke tests, the manual PR review, still fell over once it was live.
The instinct in most engineering orgs right now is to read this as a volume problem. We're generating more code, therefore more bugs slip through, therefore we need more gates. That instinct is wrong and it's going to cost a lot of teams a 2am incident before they figure out why. The volume isn't the issue. The verification model is the issue, and adding more of the same verification just makes the pipeline slower without making it catch the things it was never designed to catch.
why your pipeline was built for a different kind of code
Think about what a human pull request actually encodes. When one of your engineers writes a function, the diff is the visible artifact, but behind it sits a mental model. They know why they reached for a map instead of a slice, they remember that the upstream service returns nulls in three specific edge cases, they carry an intuition about which part of the codebase is fragile because they were the one who got paged the last time it broke. The code review process was designed around the assumption that this mental model exists and that a reviewer can interrogate it by asking questions in the PR thread.
AI-generated code has no mental model attached to it. The diff is the entire artifact. There's plausible-looking error handling that was pattern-matched from training data rather than reasoned about, there are assumptions baked into the code that the model could not have known were wrong because it never saw your production traffic, and there's a confident-looking happy path that handles exactly the cases the prompt mentioned and silently ignores everything else.
Your deterministic pipeline checks whether the code is internally consistent. Does it compile, do the tests pass, does it match the style guide, does it satisfy the contract the tests assert. What it cannot check is whether the assumptions the code is built on match reality, because nothing in a unit test suite encodes the messy, undocumented behavior of the system the code will actually run inside. A human author used to carry that context in their head and a reviewer used to extract it through conversation. Strip out the human, and you've removed the layer your entire verification architecture quietly depended on, while keeping all the gates that assumed it was there.
the tests pass because the tests are the wrong test
Here is the part that trips up smart teams. When an AI writes a feature and also writes the tests for that feature, the tests pass at a rate that feels reassuring and is actually meaningless. The model generated code under a set of assumptions and then generated tests under the same set of assumptions. Of course they agree with each other. You've built a closed loop where the thing being verified and the thing doing the verification share the same blind spots.
We saw this concretely on a document processing pipeline we picked up for a client last quarter. The previous team had used an AI tool heavily and the test coverage report showed 94%, which on paper is excellent. The production logs told a different story, with a steady trickle of failures on PDFs that used a particular embedded font encoding. The generated parser handled the encodings the model had seen examples of, the generated tests fed it exactly those encodings, and the whole thing was green across the board while quietly dropping maybe 6% of real documents. No CI gate would ever have caught it, because every test in the suite was written against the parser's own assumptions about what a PDF looks like.
This is the structural problem the surveys are measuring. The CloudBees confidence number is high precisely because the tests are passing, and the tests are passing precisely because they're testing the code against itself rather than against reality. Adding another gate to that pipeline, a mutation testing pass, a stricter coverage threshold, an extra reviewer, doesn't help, because every one of those gates is still operating on the same closed assumption set. You can stack ten deterministic checks and they'll all agree with each other and the code will still break when it meets the one input nobody, human or model, thought to imagine.
what actually moves the needle
The fix isn't more CI, it's a different category of verification that targets the assumption layer instead of the consistency layer. A few things that have worked for us and for clients we've helped untangle this.
Force the model to surface its assumptions explicitly, before you ever look at the code. When we generate a non-trivial change, the first artifact we want isn't the diff, it's a written list of every assumption the implementation depends on. What inputs does it expect, what failure modes does it assume can't happen, what upstream behavior is it trusting. A senior engineer reading that list catches the wrong assumption in thirty seconds, where they'd never catch it reading three hundred lines of plausible code.
Test against production-shaped data, not synthetic data the model invented. Shadow traffic, replayed real requests, recorded payloads from staging that came from actual integrations. The 43% Lightrun number lives almost entirely in the gap between what the model imagined inputs look like and what they actually look like, so the cheapest high-leverage move is to put real inputs in front of the code before it ships, not after.
Treat AI changes as higher-risk by default in your deploy strategy. Smaller blast radius, more aggressive canarying, faster automated rollback triggers tied to error rate and latency rather than to a human noticing. If you accept that a meaningful fraction of this code carries hidden wrong assumptions, the rational response is to make the cost of a wrong assumption cheap to discover and cheap to reverse, instead of pretending you can verify it away upfront.
And keep a human owning the integration boundaries. Let the model write the internals all day, but the places where the new code touches the rest of your system, the contracts, the data shapes, the failure handling at the seams, those need a person who understands the system holding the pen, because that's exactly the context the model doesn't have and your test suite doesn't encode.
decide this before the incident decides it for you
Most of the teams I talk to are going to set their AI governance policy reactively, in a war room, the week after a generated change took down checkout for forty minutes. That's a bad time to think clearly about architecture, and the policies that come out of those meetings tend to be either useless theater or a blanket ban that your engineers route around within a month anyway.
The better move is to write down, now, while nothing is on fire, that AI-generated code goes through a different verification path than human code, and to mean it structurally rather than as a memo. That means different artifacts required in the PR, different test data, different deploy treatment, and a clear rule about which parts of the system a model is allowed to touch unsupervised. It's not a lot of process and most of it is things a good team half-does already, the difference is making it explicit and making it the default rather than the exception you remember on the days you're paying attention.
We build a lot of AI-powered tooling at steezr, automation pipelines, document processing, internal systems that lean hard on generated code, so this isn't an argument against using these tools. We use them constantly and they make us faster. The argument is narrower than that. The pipeline you built for human code is the wrong instrument for verifying machine code, the CloudBees and Lightrun data is just the sound of that mismatch finally getting loud enough to measure, and the teams that come out of 2026 in good shape will be the ones who rebuilt the verification layer instead of bolting another gate onto the old one and hoping the next 43% lands on someone else.
