# AI made code abundant. Nobody scaled the part that checks it works. > 81% of enterprise tech leaders say AI-generated code is causing more production failures, while 92% still think their code was ready to ship. The gap between those two numbers is the whole problem. - **Pillar:** Unit Economics - **Author:** Aditya Marin Gasga (Founding Editor) - **Published:** 2026-07-15T13:30:00.000Z - **Tags:** ai-code, production-failures, code-review, engineering, finops ## TL;DR A CloudBees survey of 213 enterprise technology leaders found 81% reporting increased production failures tied to AI-generated code, even as 92% said they were confident the code was production-ready before shipping. The failures surface after code passes review and deployment gates, which means the checking process, not the code generation, is what failed to scale. It is a vendor-commissioned study, but independent research points the same direction. ## Key takeaways 1. In the CloudBees survey, 81% of technology leaders reported more production failures from AI-generated code while 92% said they were confident it was production-ready before shipping — largely the same respondents, which is what makes the gap read as a blind spot rather than a risk teams were pricing in. 2. The failures surface after code has passed review and every deployment gate, pointing at validation that has not scaled with output: generation moved to machine speed while review, testing, and validation stayed at human speed. 3. The true cost of AI-generated code is not just the tokens — it is the tokens plus the post-deployment incidents plus the engineering time to fix what shipped broken, the bill that lands when the checking does not keep pace with the generating. import Figure from '../../components/article/Figure.astro'; There is a number in a recent enterprise survey that, sitting next to another number from the same survey, tells the whole story of where AI coding actually is right now. Eighty-one percent of technology leaders say AI-generated code is causing more production failures. Ninety-two percent say they were confident the code was ready to ship. Both groups are mostly the same people. The gap between what they believed and what happened is the problem, and it is not a problem of code generation. It is a problem of everything that was supposed to catch the failures and didn't. ## What the study says In a study it published in May 2026, [CloudBees](https://www.cloudbees.com/newsroom/enterprise-technology-leaders-report-production-failures-from-ai-generated-code), an enterprise software-delivery company, surveyed 213 technology leaders (the fieldwork was run by an independent agency, TrendCandy, with a stated ±8% margin of error at a 95% confidence level). The headline: 81% reported an increase in production failures tied to AI-generated code. Alongside it, 63% reported compliance violations introduced by AI code, and 61% said their code is now AI-generated or AI-assisted. So more than eight in ten are seeing more things break in production, at organizations where the majority of code now has AI in its lineage. The detail that matters most is *where* the failures happen. According to [independent reporting on the study by The Register](https://www.theregister.com/ai-ml/2026/05/20/ai-code-boom-drives-production-failures-higher-spending/5243787), these are not build failures or tests that go red before release. They are functional bugs, performance problems, and security holes that surface *after* deployment, on code that had already passed review and every gate on the way out. As Sunil Gottumukkala, CEO of Averlon, put it: "When failures happen post-deployment, it signals that the validation process itself isn't keeping pace with what AI is producing." ## The confidence gap is the finding Put the two numbers back together. Eighty-one percent seeing more failures; 92% confident the code was production-ready. That is not a contradiction the respondents are aware of, which is exactly what makes it dangerous. If teams knew their AI code was risky, they would check it harder. The problem is that it *feels* fine, it passes the tests, it survives code review, it works in staging, and then it breaks on real users and messy data. The confidence is earned by the old signals (it passed the gates) and the gates were calibrated for a world where a human wrote and read every line.
Code generated AI scaled this — way up Review + test + validation capacity Stayed roughly flat — the gap is where failures escape
The generation side scaled almost overnight; a developer with an AI assistant produces far more code than before. The checking side, code review, testing, validation, is still done at human speed, and mostly by the same number of humans. So the ratio of code-produced to code-genuinely-verified moved sharply in the wrong direction, and the overflow lands in production. ## Read the source with open eyes One honest caveat, because it matters and because ignoring it would be exactly the kind of thing this publication exists to avoid. CloudBees sells software-delivery and test-governance tooling, the product that addresses this exact problem. So this is vendor-commissioned research, and a company finding that the market urgently needs the category it sells is not a neutral result. That said, two things keep the finding standing. The survey was conducted by an independent agency rather than in-house, and the direction is corroborated by research with no such interest. Google's [DORA 2024 report](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report) found that greater AI adoption was associated with lower delivery stability (an estimated 7.2% reduction for every 25% increase in AI adoption), and [separate surveys have found large shares of AI-generated code needing post-deployment debugging](https://venturebeat.com/technology/43-of-ai-generated-code-changes-need-debugging-in-production-survey-finds). The specific 81% is CloudBees' number; the underlying pattern, that AI code breaks in production more than teams expect, is not just theirs. Read the figure as directional and vendor-flavored, and the trend as real. ## The governance vacuum underneath The survey's less-quoted numbers explain why the failures persist. [Ninety-three percent of organizations said they have a formal process for reviewing and releasing AI-generated code, but only 56% said that process is always enforced](https://www.theregister.com/ai-ml/2026/05/20/ai-code-boom-drives-production-failures-higher-spending/5243787). A written process that is followed a bit more than half the time is not a control; it is a document. Only 12% had a dedicated AI governance function. And when something breaks, accountability defaults upward: 46% put it on the CTO or VP of engineering rather than on a defined process or the developer who shipped the code, which tells you the organization has not actually decided who owns AI-code quality. This connects directly to the cost story playing out in parallel. Enterprises are already discovering that [AI coding tools are expensive and hard to budget](/claude-code-cost), that the spend is hard to tie to results, and that the bills can climb fast enough to force [hard caps on employee AI use](/ai-cost-crackdown). Add production failures that arrive after deployment, and [the true cost of AI-generated code](/the-full-bill-for-one-agent) is not just the tokens. It is the tokens, plus the incidents, plus the downstream engineering time to fix what shipped broken, minus whatever governance you never built. ## The takeaway AI did the thing it was supposed to do: it made code cheap and abundant. What it did not do, and was never going to do on its own, is scale the judgment that decides whether the code is any good. That judgment still runs at human speed, and most organizations have not expanded it, enforced it, or assigned it an owner. The result is a lot of confident teams shipping a lot of code that passes every check they have and breaks anyway. The fix is not to generate less. It is to make the checking match the making, enforced review, test coverage that keeps pace, and a named owner for AI-code quality, before the gap between "we were confident" and "it failed in production" becomes the defining cost of the whole exercise. ## FAQ ### What did the CloudBees study find? In a survey of 213 enterprise technology leaders (conducted by independent agency TrendCandy for CloudBees, ±8% margin of error), 81% reported an increase in production failures tied to AI-generated code, while 92% said they were confident their code was production-ready before shipping. 63% reported compliance violations from AI code. 61% of their code is now AI-generated or AI-assisted. ### Why do these failures matter more than normal bugs? Because they surface after deployment. The failures happened to code that had already passed review and every deployment gate, then broke in production anyway. That points to the validation process failing to keep pace with how much code AI now produces, rather than to individual bad commits. Post-deployment failures are the most expensive kind to fix. ### Should the study be taken at face value? With one caveat: CloudBees sells software-delivery and test-governance tools that address exactly this problem, so it has a commercial interest in the finding. The survey was run by an independent agency, and the direction is corroborated by other research (Google's DORA 2024 report found AI adoption associated with lower delivery stability, an estimated 7.2% reduction for every 25% increase in adoption; a Lightrun survey found a large share of AI code needed post-deployment debugging). The finding stands, but it is vendor-commissioned research and worth reading as such. ### What is the actual fix? Not slower code generation, but validation that scales with output: enforced review that is actually applied (only 56% of organizations with a formal AI-code review process said it is always enforced), test coverage that keeps pace, and governance that assigns clear ownership. Only 12% of surveyed organizations had a dedicated AI governance function, and accountability for failures defaulted upward to the CTO or VP rather than to a defined process.