Vibe Coding in Production: The Cleanup Bill 74% of Teams Never Budgeted

Vibe coding does not fail on the day you ship it. It fails about two quarters later, in a rework line nobody put in the budget. 74% of technology leaders now say at least a quarter of their AI-generated code needs significant rework, and 94% of those same leaders graded that code as higher quality than human-written code at the moment of review.

What vibe coding actually means once it reaches production

Vibe coding is the practice of prompting a model for code, skimming the result, and committing it without a line-by-line read. It is a review posture, and in production it converts review time into incident time.

That definition matters because most of the public argument is aimed at the wrong object. The tooling comparison is a real question and we have covered it in the three scoreboards that AI coding tools are actually judged on. It is not the question that decides your rework line.

Vibe coding is a review posture, not a tool

Stack Overflow's 2025 developer survey found more developers actively distrust the accuracy of AI tool output (46%) than trust it (33%), and only 3.1% say they highly trust it. Distrust has not slowed usage. It has simply moved the verification work downstream.

The most-cited frustration in that survey is the tell: 66% of respondents named AI solutions that are almost right, but not quite. Almost-right code passes a skim. It does not pass a load test six weeks later.

Prototype risk and production risk are not the same

A vibe-coded prototype is close to free. If it is wrong you delete it, and the cost was an afternoon. A vibe-coded payments path is a different object entirely, because the cost of being wrong is paid by someone who is not in the room.

Most engineering organisations have not drawn that line explicitly. They adopted one posture and applied it uniformly, which is how a technique that is excellent for throwaway work ended up inside authentication code.

The cleanup bill, measured three ways

Three independent measurement approaches now point at the same conclusion from different angles. A survey, a telemetry study and a static analysis of commits fail in different directions.

Two of these four organisations sell products that address the problem they measured, which is why the survey rows deserve less weight than the telemetry and commit-analysis rows.

What the leaders report

The New Relic study captured both sides of the gap from the same respondents. 94% rated AI-generated code as higher quality than human-authored code at review. Then 78% reported an increase in production incidents, 86% reported senior engineers spending more time fixing code, and 82% had at least one production failure tied to AI-generated code in six months.

Read those numbers together rather than separately. A population that grades code well at review and then absorbs more incidents is not describing bad code. It is describing code whose defects are invisible at the moment anyone looks at it.

What the telemetry shows

Faros AI compared each organisation's lowest and highest AI adoption periods across two years of delivery data. Task throughput per developer rose 33.7% and epics completed per developer rose 66%. Monthly incidents rose 57.9% and bugs per developer rose 54%.

The ratio is the number that matters for planning: for every change merged, the probability of a production incident more than tripled. Throughput improved and reliability per unit of throughput got much worse, which is exactly the shape a cleanup bill takes before anyone names it.

What developers feel

Developer sentiment is the least rigorous of the three views and the most immediately actionable. 45.2% of Stack Overflow respondents named more time-consuming debugging of AI-generated code as a significant frustration. That is a self-report, so treat it as directional.

The people reporting it are the ones absorbing the cost, and the rework does not appear in a budget line. It appears as a senior engineer's Thursday.

Review is the bottleneck the tools created

Generation got roughly an order of magnitude cheaper. Review did not. Every stage that depends on human attention became the constraint, starting with code review.

Faros measured median time in review rising 441.5% and median time to first review rising 156.6%. At the same time, pull requests merged with no review at all rose 31.3%. Those two numbers describe one behaviour: reviewers fell behind, and the queue drained itself.

The pull requests themselves also changed shape. Apiiro's analysis of code across tens of thousands of repositories found that AI assistants tend to pack more changes into fewer pull requests, touching more parts of the codebase per review. One example the firm published involved an altered authorization header that produced a silent authentication failure in a different service.

I do not believe AI review tooling fixes this on its own. Adding a machine reviewer to a queue that is already failing on volume treats the symptom, and it moves the accountability question somewhere nobody wants it. The organisations getting this right are pushing the check earlier instead. The wider pattern of agent deployments that stall at exactly this handover point is covered in the analysis of where agent pilots actually fail.

What actually degrades inside the codebase

GitClear's July 2026 research analysed 623 million code changes from 2023 to 2026, a period in which AI-assisted commits reached roughly a quarter of all commits, and tracked eight maintainability signals. Seven of them moved the wrong way.

Duplication up, reuse down

Code block duplication, measured as five or more consecutive repeated meaningful lines, rose 81%. Within-commit copy and paste rose 41%. Cross-file function calls, which are a proxy for reuse, fell 35%.

The pattern underneath is consistent: a model asked for a capability will write that capability rather than find the version of it that already exists. Bill Harding, GitClear's chief executive, framed the wider issue as not just duplication, but not tending to legacy code. Long-term maintenance of code older than twelve months fell 74% against 2023, and refactoring line moves fell 70%.

Error masking is the quiet one

The signal that concerns me most is the smallest headline. Error-masking constructs rose 47%. That means code which catches an error and continues without evaluating what caused it.

Masked errors are worse than crashes for one specific reason. A crash gets a ticket. A swallowed exception gets discovered during an incident, months later, by someone who did not write it and cannot tell whether the silence was deliberate.

Security is the part that has not improved

Model capability has climbed steeply on almost every benchmark that gets published. Security is the exception, and the flatness is the finding.

Veracode's Spring 2026 update tested more than 150 models against 80 coding tasks across Java, JavaScript, C# and Python. The security pass rate came in at 55%, effectively unchanged from the 2025 report. Syntax correctness now exceeds 95%. Veracode's own summary of that divergence is blunt: models have become excellent at writing code that compiles, and have not become better at writing code that is safe.

The distribution matters more than the average. Java passed 29% of the time while Python passed 62%. Cross-site scripting passed 15% and log injection 13%, against 82% for SQL injection. If you run a Java estate, the industry average is not your number.

The flaws changed shape

Apiiro's repository telemetry describes the same shift from a different direction. AI-assisted developers produced three to four times more code than unassisted peers and generated roughly ten times more security findings, reaching over 10,000 new findings a month by June 2025.

Underneath that total, the mix inverted. Syntax errors fell 76% and logic bugs fell 60%, while privilege escalation paths rose 322% and architectural design flaws rose 153%. Developers using assistants exposed sensitive cloud credentials at nearly twice the rate of those who did not. Itay Nussbaum of Apiiro summarised it as AI fixing the typos and creating the timebombs.

That inversion is the whole problem in one line. Cheap defects got cheaper to avoid and expensive defects got more common. Static analysis catches the first category well and the second category poorly.

Why nobody budgeted for the cleanup

Every organisation in these studies had a budget process and none put a line in it for this. The reason is not negligence, it is a measurement error that is hard to see from the inside.

METR ran a randomised controlled trial with 16 experienced open-source developers across 246 real tasks in repositories they maintained. Developers forecast a 24% speed-up before starting. Afterwards they estimated they had been 20% faster. They were in fact 19% slower on tasks where AI was allowed.

Practitioners consistently overestimate the benefit while performing the work, which means self-reported productivity gains are not a safe basis for a capacity plan. The broader version of this measurement problem, at the level of national output rather than a sprint, is covered in the piece on the AI productivity paradox.

Review grades measure the wrong moment

Code is graded at review, where AI-generated output looks tidy, conventional and well formatted. The cost lands in production, where the defect classes that survive review were never visible in a diff. A team that trusts its review grade discovers the rework three quarters later, when it competes with the roadmap and loses.

Eight guardrails that keep the speed and cap the bill

None of this is an argument for banning the tools. The argument is that the second-order costs are predictable, which means they can be engineered against rather than absorbed.

Review capacity is the resource AI consumed first, so a control that fires before a pull request opens is worth several that fire after. I would put a diff-size cap in before buying any AI review product.

Three of these deserve expansion, because they are the ones teams skip.

Labelling AI authorship is the cheapest and the most valuable. Without it every figure in this post remains someone else's research rather than your number. If I had to run this on one metric, it would be that ratio rather than throughput.

Ring-fencing is a written artefact or it does not exist. A shared understanding that authentication is sensitive will not survive a deadline. A list of paths in the repository, enforced by a code owners file, will. The same reasoning applies when you decide which parts of the stack to build with agents at all, which is the question examined in the build versus buy analysis for coding agents.

Booked remediation capacity is a budget decision, not an engineering one. If 74% of leaders report significant rework and none of them planned for it, the correct response is a standing allocation defended at the same level as the roadmap.

The 2025 DORA report, drawing on nearly 5,000 technology professionals and more than 100 hours of interviews, supports the shape of this list from a different direction. It found AI adoption positively related to throughput and negatively related to delivery stability, and identified seven capabilities that amplify the benefit. Two of them are strong version control practices and working in small batches, which is the same instinct as the first guardrail above. Google's own framing is that AI does not fix a team, it amplifies what is already there.

Guardrails do not fix the gap between benchmark performance and what an agent can do in a repository with ten years of history. That separate constraint is covered in the analysis of how coding agents perform on real repositories.

Where this argument is weakest

Four objections are strong enough that I would raise them myself before acting on anything above.

Most of this research is sold by people who fix the problem. New Relic sells observability. Faros AI sells engineering intelligence. Apiiro and Veracode sell application security. GitClear sells developer productivity analytics. Each published a methodology and a sample, which is more than most vendor research does, and each still has a commercial interest in the direction of the finding. Weight the telemetry and commit-analysis studies above the opinion surveys for that reason.

Correlation is doing heavy lifting. The Faros comparison is between low and high adoption periods, not a controlled experiment. The same period saw hiring changes, more greenfield work and pressure to ship faster for reasons unrelated to AI. Attributing the entire incident rise to code authorship overstates the case.

The strongest counter-evidence is the METR study itself. It is 16 developers, on mature open-source repositories they knew intimately, using early-2025 tooling. METR now labels the result historical and says it does not necessarily reflect current tools. Anyone quoting the 19% figure as a current fact, including anyone quoting it back at me, is overreaching.

Some signals are stabilising. GitClear's mid-2026 data showed several maintainability indicators levelling off rather than continuing to worsen. If that holds, this was an adoption-shock cost rather than a permanent tax, and the cleanup bill is a one-off rather than an annuity. I do not think there is enough data yet to settle which, and I would plan for the annuity while hoping for the one-off.

Frequently asked questions

Where to start this week

Three moves, in this order, because each one makes the next one cheaper.

Start by making authorship visible. Add a commit trailer or a pull request label marking AI-assisted changes, and backfill nothing. Within a month you can compute your own incidents-per-change ratio and stop reasoning from other people's samples.

Then write the ring-fence down. List the paths where the vibe coding posture is not permitted, put them in a code owners file, and name an owner for each. Authentication, payments, data migrations and anything that writes to a permissions table are the usual starting set.

Last, put a number in the plan. Pick a share of next quarter's engineering capacity for remediation and write it into the roadmap before anything else claims the space. Defend it with the incident ratio you started measuring in step one. A wrong number that is defended beats an accurate estimate produced after the outage.

Related reading