Eighteen Cents on the Dollar: What AI Coding Tools Really Cost Once the Bugs Come Due

Column Overview

Ask a room full of engineering leaders whether AI coding assistants have made their teams faster, and almost everyone will say yes. Ask them to show the receipt, and the conversation gets a lot more uncomfortable. Two pieces of data published within weeks of each other this year have quietly reopened a debate that most of the industry thought was settled: is AI-generated code actually cheaper to ship, or have we just moved the cost somewhere we're not looking?

The bill nobody itemized

The number that lit up developer Twitter came from Entelligence AI, which pulled usage data across 2,444 companies and did something almost nobody bothers to do: it traced every dollar spent on AI coding tokens all the way through to production. The split was not subtle. For every dollar spent, 44 cents went toward fixing bugs the AI itself had introduced, 27 cents went toward rewriting AI-generated code that didn't hold up, and another 11 cents evaporated into the friction of code review and merge delays as humans tried to figure out what the model had actually done. Add it up and roughly 18 cents of real, shippable value survives out of every dollar spent. A hundred-thousand-dollar token budget nets you about eighteen thousand dollars of code that actually makes it to production.

That framing spread fast because it's brutally legible — a single ratio anyone can repeat in a meeting. It also drew pushback almost as quickly, and for good reason: a viral tweet distilling a vendor's aggregate survey data is not a controlled study, the "18 cents" figure conflates very different kinds of engineering work under one number, and teams vary enormously in how disciplined their review process is. A rebuttal making exactly this point, "Eighteen Cents on the Dollar," is worth reading alongside the original claim rather than instead of it — it doesn't disprove the underlying pattern so much as argue the specific number is being asked to carry more precision than it can support. The point worth keeping isn't the second decimal place. It's the shape of the finding: a meaningful share of AI coding spend isn't creating new value, it's cleaning up after the same tool that created the mess.

Why "twice as fast" can still lose you money

If the Entelligence number is a snapshot, James Shore's essay "You Need AI That Reduces Your Maintenance Costs" — which climbed to the top of Hacker News and stayed there through a genuinely split comment section — is the mechanism that explains why the snapshot looks the way it does. Shore's argument doesn't require you to believe AI writes bad code. It only requires you to accept an accounting identity that most ROI pitches conveniently skip: total maintenance burden scales with the volume of code you're maintaining, not with how quickly you produced it.

Run the model forward. An AI agent lets a team double its output — twice as many features, twice as many files, twice as many edge cases baked into the codebase. If the maintenance cost per unit of code stays flat, which is the optimistic case, you haven't cut your maintenance bill; you've doubled it, because you now have twice as much code generating twice as many support tickets, security patches, and integration headaches. Shore's model pushes the timeline out to make the point concrete: on a plausible set of assumptions, maintenance work climbs to consume more than half of a developer's time within about two and a half years of adopting AI-accelerated development at scale. Velocity went up. Net capacity to do new work did not — because the tax on old work grew right alongside it.

The Hacker News thread underneath the post is worth treating as its own source, not just an engagement metric. The disagreement splits roughly where you'd expect: teams with strong test coverage, tight review discipline, and senior engineers steering the AI report the compounding effect is real but manageable, closer to a 20-30% maintenance tax than a runaway spiral. Teams that let AI-generated code ship with looser oversight describe something closer to Shore's worst case. That split matters more than either extreme, because it suggests the outcome isn't determined by the tool — it's determined by whether an organization was already disciplined enough to catch the debt before it compounded.

The dependency nobody wants to admit

Layer a third data point on top and the picture sharpens uncomfortably. TechCrunch's reporting on developers who now refuse to write code without AI assistance describes a workforce that has crossed a threshold quietly, without much internal debate about whether it should. It's one thing to adopt a tool because it makes you faster. It's another to reach a point where working without it no longer feels like an option — where the skill of writing code unassisted has atrophied enough that going back isn't really on the table.

Put that alongside the maintenance math and you get a genuinely awkward combination: a workforce increasingly dependent on a tool whose output creates a maintenance bill many of the same developers aren't equipped, or resourced, to pay down manually. If AI writes it and AI can't be trusted to maintain it as cheaply as it was written, and the humans who'd normally do that maintenance are the least practiced at doing it without AI in the loop, the debt doesn't get serviced — it gets deferred. That's not a hypothetical failure mode. It's the exact mechanism Shore's essay describes, just viewed from the human-capital side instead of the codebase-size side.

The metric the industry forgot to build

None of this adds up to "AI coding tools don't work." Every source here, including the skeptical ones, takes for granted that these tools genuinely accelerate the writing of code — that's not in dispute. What's in dispute is whether the industry has been measuring the right thing. Lines of code per hour, PRs merged per sprint, tokens spent per feature shipped — these are all production-side metrics. They tell you how fast the front end of the pipeline is moving. None of them tell you what happens six months later when that code needs to be modified, debugged, or extended by someone who didn't write it and possibly didn't review it closely the first time either.

That's the actual variable this whole debate turns on: AI's net impact on software teams isn't a question you can answer by measuring output velocity, because velocity is exactly the number that goes up right before the bill comes due. A more honest ROI model would treat AI-assisted code the way a lender treats a loan — value delivered today, weighed against a repayment schedule that starts showing up in the maintenance ledger a few quarters later. Some teams are already structuring their AI adoption that way, with tighter review gates and mandatory test coverage on anything AI-generated specifically because they've internalized this tradeoff. Most teams, based on the numbers above, are still counting the loan as if it were a grant. The 44-cents-on-the-dollar figure and the two-and-a-half-year maintenance curve are two ways of describing the same unpaid invoice. Whether that invoice stays manageable or becomes the dominant cost of software development this decade depends less on which model or which agent you're using, and more on whether your organization decided to look at it before it arrived.