← All writing

The Second Invoice: What AI-Generated Code Costs After the Meter Stops

The token bill is the cheap part. AI-generated code moves most of its real cost downstream—into review time, rework, failed builds, and the compute burned re-running pipelines. Here is how to find that cost before it finds your budget.

A Flood the Maintainers Can Measure

On July 11, the Financial Times ran a feature by Sam Learner under a deceptively light headline—“Who cleans up after the vibe-coding party?”—about the unpaid people whose maintenance work keeps open source running, and the rising tide of AI-generated contributions now burying them.1 The framing was fresh for a mainstream financial readership. The phenomenon was not. For the whole story compressed into a single project, look at curl, whose libcurl component has been installed more than twenty billion times and yet is maintained largely by one man.

Daniel Stenberg, curl’s Swedish creator, kept a tally of security submissions his team judged to be AI-generated noise. In 2023 there were two. In 2024 there were six. In 2025 there were thirty-seven, and by his account not one turned out to be a real vulnerability.2 For years the project ran a bug bounty that paid outside researchers who found genuine flaws; the largest single award was $4,660, for a heap-based buffer overflow in curl’s SOCKS5 proxy handshake. In January, citing an “explosion of AI slop reports,” Stenberg wound the programme down. The submissions, he wrote, “take a serious mental toll to manage and sometimes also a long time to debunk. Time and energy that is completely wasted while also hampering our will to live.”3

Fig. 1 — AI-generated security reports to the curl project rose from 2 in 2023 to 37 in 2025; by the maintainer's account, none were valid vulnerabilities.

curl is unusually visible, so it makes a clean example, but the burden is spread across the commons. Volunteer security teams now report spending anywhere from two to eight hours triaging a single fabricated report, time that used to go toward actual defects.4 Rémi Verschelde, who helps run the Godot game engine, called the triage work “draining and demoralizing.”5 A study of maintainer discussions published in March catalogued the same complaint in quantitative form: one team described receiving thirty pull requests a day across six reviewers, and several projects had resorted to hard limits—no PR over five hundred lines, or we will not look at it.6

None of this is a story about bad actors, mostly. It is a story about arithmetic. Generating a plausible-looking contribution went from expensive to nearly free, while the work of reading one, understanding it, testing it, and deciding whether it belongs did not get cheaper at all. The maintainers Learner interviewed have a name for what results: the extractive contribution, one whose review costs more than the contribution is worth. When the price of production falls toward zero and the price of verification holds steady, volume floods the side of the system that still runs on human hours.

The signal beneath the signal The maintainer flood is not primarily a security problem or a spam problem. It is the most visible instance of a cost that AI-assisted development moves downstream—off the meter you are watching and onto the ones you are not.

That relocation of cost is the subject here. Open source is simply where it showed up first and loudest, because maintainers are unpaid and feel every hour. Inside the enterprise the same forces operate, but the costs hide in salaries, cloud invoices, and incident reviews, where they are easy to ignore.

The Cost Did Not Disappear; It Changed Departments

Most enterprise conversations about the price of AI coding still orbit the token meter—the per-seat license, the inference bill, the model consumption that finance can put in a line item. That number is real, and it is also the least interesting one. It is the visible tip of a cost structure whose bulk sits below the waterline, in the parts of the software lifecycle that generation does not touch.

Consider what a coding agent actually changes. It compresses the time from intent to a diff. It does little for the time from a diff to a merge you can trust, and may lengthen it, because a reviewer now confronts more code, produced faster, with less context about why it looks the way it does. The bottleneck moves downstream, and bottlenecks accumulate the value that flows toward them.

An analysis published in early July by Entelligence, which examined more than a million pull requests across 2,444 companies, tried to put a figure on where that value ends up. Its headline result: for every dollar an organization spends on AI to generate code, roughly forty-four cents is later spent fixing bugs in that code, twenty-seven cents rewriting it, and eleven cents absorbing review and merge delays. By that accounting, about eighty-two cents of every AI dollar is consumed before a single feature reaches a user, leaving eighteen cents of net delivery.7 Treat the precise split with appropriate caution—it is one firm’s model, not an audited standard—but the shape of it lines up with everything else the data is showing.

Fig. 2 — By one firm's accounting, roughly 82 cents of every dollar spent generating code with AI is later spent fixing, rewriting, or waiting on it, leaving 18 cents of net delivery.

$0.82
Spent on rework, fixes, and delays per $1 of AI generation (Entelligence, 2026)
+441%
Change in median PR review time, heaviest AI adopters (Faros telemetry, 2026)
37
AI-generated “slop” security reports to curl in 2025—none valid
~30%
Of Python committed by US GitHub users now written with substantial AI assistance

The most instructive numbers come from engineering telemetry rather than surveys, because they measure behavior instead of opinion. Drawing on instrumented data across many organizations, Faros AI reported that developers making heavy use of AI merged far more pull requests per person—on the order of a ninety-eight percent increase—while the median time to review a pull request rose ninety-one percent in 2025 and, in the 2026 cohort, more than five-fold. Over the same period, bugs per developer climbed from a modest single-digit uptick to fifty-four percent, and incidents traced to individual pull requests rose by roughly two hundred forty percent.8 Throughput went up. So did nearly everything downstream of throughput.

Fig. 3 — Among the heaviest AI adopters, pull requests merged per developer roughly doubled, but review time, defects, and incidents per pull request rose faster still.

This is the mechanism behind the abstraction. More diffs enter the pipeline; each one is a little less trusted; reviewers slow down to compensate; some defects slip through anyway; the ones that slip through surface later as incidents, which are the most expensive place a bug can be found. Guido van Rossum, Python’s creator, put his finger on part of why each review takes longer: language models “have a tendency to touch many parts of a file not directly related to the problem that they are trying to solve,” so the reviewer must reason about changes the task never required. A separate review-tool vendor found that pull requests with an AI co-author carried about 1.7 times as many issues as fully human-written ones—consistent with the idea that the generation step is not producing worse engineers, it is producing more code per reviewer than the review step was designed to absorb.9

What the Machines Never Touch: Build Minutes and Iron

There is a second hidden cost that sits even further from the token meter, and it is one the open source framing barely mentions: the compute burned running everyone’s code, valid or not.

Every pull request that enters a modern pipeline triggers work that has nothing to do with inference. Continuous integration spins up runners. Test suites execute. Containers build. Static analysis and security scanning walk the diff. On a hosted service this is metered by the minute, and the rates are not trivial once volume moves. GitHub-hosted Linux runners bill around six-tenths of a cent per minute for a two-core machine, rising to roughly two-and-a-fifth cents for eight cores; Windows minutes are counted at double weight and macOS minutes at ten times against an organization’s quota, and artifact storage runs a quarter per gigabyte-month beyond the included allowance.10 None of those figures is large on its own. That is precisely why they escape scrutiny.

Fig. 4 — Per-minute rates for GitHub-hosted runners in 2026. Small numbers individually, but every re-run of a pipeline is a fresh allocation of billed compute.

Now apply the volume multiplier. If AI-assisted teams are opening pull requests at nearly twice the prior rate, and a meaningful share of those PRs are revised, re-pushed, and re-run several times before they either merge or get abandoned, the pipeline is doing far more work per shipped feature than it used to. Each re-run is a fresh allocation of CPU and memory, whether the code is destined for production or destined for the trash. For teams running their own runners the cost simply moves from a line item to a depreciation schedule and an electricity bill, but it does not vanish—the CPUs and the memory are allocated all the same, and the finite capacity they represent is spent on churn.

A working definition The hidden cost of AI-generated code is the sum of everything the generation step does not perform: reviewing it, testing it, running it through the pipeline, fixing it, rewriting it, and managing the people and machines doing all of the above.

The labor side compounds the compute side. Senior engineers are the scarcest resource in most organizations, and review is disproportionately their job. When median review time stretches, that time is drawn from the most expensive calendars in the building, and it is drawn quietly—no purchase order, no vendor negotiation, just a slow thickening of the queue and a creeping sense that shipping got harder. There is even reason to doubt the individual speed-up that justified the spend in the first place: a controlled study by METR, in which experienced open source developers worked on their own repositories, found them nineteen percent slower when using AI tools, even though the same developers believed they had been faster.11 Perceived velocity and measured velocity are not the same quantity, and budgets built on the former will miss the latter.

The Exposure Runs in Both Directions

For a technology leader deciding how to price all of this, the open source flood is not a distant morality tale. It is a direct exposure, because the enterprise sits on both sides of the transaction.

On the consumption side, essentially every commercial codebase is built on open source, and the health of that foundation is a real input to enterprise risk. The 2026 open source security and risk analysis of nearly a thousand commercial codebases found that ninety-three percent contained components with no meaningful development activity in the previous two years.12 Maintainers burning out under a slop flood, or walling off their projects behind contribution limits, is not a philanthropy problem for the firms downstream—it is a supply-chain problem, because those projects are load-bearing dependencies in products that generate revenue.

On the production side, the enterprise is now generating its own version of the same flood internally. The GitHub ecosystem gives a sense of the raw scale that AI has unlocked: something like thirty-six million developers joined the platform in the past year, new repositories are created at a rate near two hundred thirty a minute, and a large majority of newcomers are using an AI assistant within their first week.13 The share of code itself has shifted just as fast; a classifier applied to more than thirty million commits estimated that close to thirty percent of the Python written by US GitHub users now carries substantial AI assistance, up from near zero before 2021.14 Most of that energy is genuinely productive. The same asymmetry that overwhelms a volunteer maintainer—cheap to produce, expensive to verify—operates inside a private monorepo too, with the added twist that the reviewers are salaried and the compute is invoiced.

There is a longer-horizon exposure that the maintainer story makes vivid. Miklós Koren, an economist at Central European University, has modeled what happens when the consumers of open-source packages are increasingly AI agents rather than people. Developers contribute, in his account, partly because they want their work used and noticed by other humans; when the audience becomes bots that install a package without ever engaging with its author, that motivation decays, and in the model it outweighs the fact that AI helps individual developers write code faster. His paper, pointedly titled “Vibe Coding Kills Open Source,” concludes that “under the traditional business model, where developer revenue depends entirely on direct user engagement, the open-source ecosystem cannot survive widespread AI adoption.”15 It is a strong claim and a contested one. But for a company whose products rest on that ecosystem, even a diluted version of it is a supply-chain risk with a long fuse.

“In general, writing code the first time was never the problem for any project. The challenge for any project is maintaining it over time.”

— Daniel Stenberg, creator of curl, in the Financial Times, July 2026

The uncomfortable part, and the reason this deserves a place in an operating budget rather than a blog post, is that the industry-level data has not yet shown the promised payoff at the level that matters. The 2025 DORA research, drawing on tens of thousands of practitioners, found AI adoption effectively universal and individual productivity broadly up, and yet organizational software-delivery performance largely flat, with AI acting as an amplifier that improves throughput while straining stability wherever the underlying system was already shaky.16 Faster individuals, unchanged delivery. The gap between those two facts is exactly the second invoice.

Read the Roadmaps, Not the Keynotes

Vendors are not blind to this, and the more candid signal is in what they are building rather than what they are claiming. The tooling is quietly pivoting from helping you write code to helping you survive the volume of code now being written.

GitHub has moved to give maintainers direct relief, shipping controls that let a project throttle or cap incoming pull requests from outside contributors—a blunt instrument, but an honest acknowledgment that unbounded contribution volume is now a liability rather than an unalloyed good.17 Alongside that, its Copilot code-review and Autofix capabilities are aimed squarely at the verification bottleneck, using models to triage and annotate diffs and to propose fixes for scanning alerts, so that some of the review load lands on machines before it reaches a person.18 The logic is consistent: if generation is going to scale, the reviewing and remediation layers have to scale with it, or the whole pipeline tips over.

Others are converging on the same conclusion from different starting points. Security intermediaries such as HackerOne have introduced AI filtering to keep fabricated vulnerability reports away from human triage. Independent review tools have built their businesses on the premise that AI-authored code needs AI-assisted scrutiny to stay affordable. The through-line across the field is an admission the marketing decks rarely make out loud: the expensive part of software was never the typing.

Cost categoryOn the token meter?Where it actually lands
Model inference / seat licensesYes—visible line itemVendor invoice, finance-owned
Code review laborNoSenior engineer salaries; slower queues
Bug fixing and reworkNoSprint capacity; delayed roadmaps
CI/CD runner minutesPartly—buried in cloud spendPer-minute compute on every re-run
Incident and outage responseNoOn-call time; reliability and trust
Dependency / supply-chain riskNoStalled upstream projects you rely on

Pricing the Whole Thing Before It Prices You

The correction here is not to slow adoption. AI-assisted development is a genuine capability, and the individual gains in the telemetry are real. The correction is to account for the full cost so that the tool is aimed at net delivery rather than gross output. A few moves matter more than the rest.

Start by instrumenting the downstream, not just the meter. If the only number you track is token spend and seats, you are measuring the cheapest input and none of the expensive ones. Bring review latency, rework rate, change-failure rate, and CI minutes per merged pull request into the same dashboard as the license cost, and the real unit economics of a shipped feature become visible for the first time. You cannot manage a cost you have decided not to look at.

Second, treat the verification layer as the constraint it now is, and fund it deliberately. That means budgeting reviewer capacity in proportion to generation capacity, routing first-pass review to automated tooling where it genuinely reduces human load, and resisting the temptation to measure a team by pull requests opened—a metric that AI makes almost meaningless. Throughput at the top of the funnel is not the same as value at the bottom.

Third, put governance around agent-generated contributions before the volume forces your hand. A short, practical set of controls goes a long way: attribute AI-authored code so you can measure its defect and rework profile separately, cap the size of automated diffs so review stays tractable, gate the pipeline so that speculative or repeatedly failing runs do not consume compute without limit, and give reviewers explicit permission to reject volume that does not carry understanding with it. The maintainers who imposed line limits were not being precious. They were doing capacity planning.

Fourth, extend the same scrutiny to the dependencies you consume. Know which upstream projects are load-bearing in your products, track their maintenance health as a risk input, and weigh whether sponsorship or contributed maintainer time is cheaper than the outage you would eventually inherit from a stalled dependency. The commons is part of your supply chain whether or not it appears on a contract.

None of this argues against the machines. It argues for reading the whole invoice.

One Bill, Two Desks

The token meter was always a comforting number: small, and on time. The costs that matter most arrive late and from somewhere else—the senior engineer’s afternoon spent untangling a plausible diff, the pipeline re-running for the fifth time on code no one will merge, the two a.m. incident traced to a change that looked fine, the upstream maintainer who finally walked away. AI made the first invoice cheaper and the second one larger, and it put the two on different desks so they would be hard to add together. The organizations that win the next phase will not be the ones generating the most code. They will be the ones that learned to read both invoices as a single bill.

References

  1. Sam Learner, “Who Cleans Up After the Vibe-Coding Party?” Financial Times, July 11, 2026.
  2. Daniel Stenberg, “The End of the curl Bug-Bounty,” daniel.haxx.se, January 26, 2026; “AI-generated abandonware is hollowing out open source,” LeadDev, 2026.
  3. Learner, “Who Cleans Up After the Vibe-Coding Party?” Financial Times, July 11, 2026 (largest bounty and closure quote); “Curl ending bug bounty program after flood of AI slop reports,” BleepingComputer, 2026.
  4. “AI agents are flooding open-source maintainers with security reports,” Axios, March 10, 2026.
  5. Axios, March 10, 2026; “Open source maintainers are drowning in AI-generated pull requests,” The New Stack, 2026.
  6. Sebastian Baltes, Marc Cheong, and Christoph Treude, “‘An Endless Stream of AI Slop’: The Growing Burden of AI-Assisted Software Development,” arXiv:2603.27249, March 28, 2026.
  7. “For Every $1 Spent on AI, Companies Pay $0.44 Fixing Bugs, $0.27 Rewriting Code, and $0.11 on Review Delays,” Tech Startups, July 6, 2026, reporting Entelligence AI Research analysis of 2,444 companies and more than one million pull requests.
  8. Faros AI engineering telemetry, as compiled in “Key Takeaways from the DORA Report 2025,” Faros AI, 2026.
  9. CodeRabbit research on AI-co-authored pull requests, CodeRabbit, 2026.
  10. “Actions runner pricing,” GitHub Docs, 2026; “GitHub Actions Pricing 2026,” CICDCalculator.com, 2026.
  11. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” METR, July 10, 2025 (arXiv:2507.09089).
  12. “Open Source Security and Risk Analysis (OSSRA) Report 2026,” as reported in LeadDev, 2026.
  13. GitHub Octoverse data, as reported in “AI-generated abandonware is hollowing out open source,” LeadDev, 2026.
  14. Daniotti, Wachs, Feng, and Neffke, “Estimated share of Python committed by US GitHub users written with substantial AI assistance,” 2025, as cited in Learner, Financial Times, July 11, 2026 (classifier applied to more than 30 million contributions).
  15. Miklós Koren et al., “Vibe Coding Kills Open Source,” working paper, Central European University, 2026, as cited in Learner, Financial Times, July 11, 2026.
  16. “DORA 2025: State of AI-assisted Software Development,” DORA / Google Cloud, 2025; “State of DevOps 2025,” Splunk, 2025.
  17. “GitHub ponders kill switch for pull requests to stop AI slop,” The Register, February 3, 2026; “GitHub Adds PR Caps to Help Maintainers Combat AI Slop,” CodeRabbit, 2026.
  18. “About GitHub Copilot code review,” GitHub Docs, 2026; “Responsible use of Copilot Autofix for code scanning,” GitHub Docs, 2026.