AI made the first draft free. I treated that as the win. The bill arrived later, not in dollars, in the parts of the system nobody on the team fully understood anymore.
I like AI coding tools. I use them every day. I've shipped more open-source projects in the last few months than in years prior, and a lot of that is leverage. Scaffolding is faster. Boilerplate is cheaper. First drafts come together in minutes.
So this isn't an anti-AI post. It's an accounting post. We've gotten very good at measuring the first draft and very bad at measuring what comes after it, and the after is where the actual cost lives.
The ratio that should worry you
Every stage of the development cycle used to have roughly proportional cost. You wrote code, you reviewed code, you maintained code, and those costs were in the same order of magnitude. The economics were stable enough that you could reason about them.
AI broke the ratio. Generation dropped to near zero. Review stayed flat. Maintenance didn't move at all, and maintenance is the longest phase of any codebase's life.
So we get a new shape: projects that look extremely productive in week one and increasingly expensive in month three. The "month three" isn't one project's stopwatch. It's the pattern I keep seeing across the tools I've shipped this year, and it's slow. No giant outage. Just an accumulation of code that looked more trustworthy than it was, sitting in places that later changes had to work around.
The bug that changed how I read AI code
The moment that stuck with me wasn't a fire. It was a small bug in a very clean-looking change. The code read well, the tests passed, the comments looked thoughtful. Nothing about it was reckless. But it misread an API response when an optional field was missing. It handled the happy path and missed the absence.
We caught it later, after downstream behavior stopped matching what users expected.
What stayed with me: we approved code none of us had really interrogated. I didn't catch it either. And that is the whole problem, because the code looked more trustworthy than it was, which is exactly why it got less scrutiny.
I wrote about this at the time in AI-Assisted Engineering: Faster to Build Isn't Cheaper to Own. The reaction told me the feeling is widespread. The METR study from 2025 is the quantitative version: experienced open-source developers using AI tools took 19% longer, even though they believed they were faster. Not because AI is useless, but because it's easy to feel faster when the first draft arrives quickly.
Where the bill actually shows up
Over the last few months I've instrumented four places where the ownership cost lands. None of them are line items on a typical AI ROI dashboard.
1. Debugging generated code, including your own. CauterRule exists because repeated agent failures kept coming back. To debug it properly I had to run a 4,768-trajectory field test, and it took a runner hardening change (per-trajectory timeouts, quarantine, token caps) just to get a run that didn't die halfway. That's the shape of the bill: the code was written in days and needed infrastructure to be understood.
2. Cost that only appears per task, not per call. A cheap model call, a failure, a retry, a failure, an escalation. Your dashboard shows $0.001. The task cost $0.053. I built ai-tierforge because almost nobody tracks cost per completed task, and the real-world savings were 44.8% versus sending everything to one model. The number isn't the point. The point is that per-call pricing hid the actual behavior.
3. Loops that never terminate. A generated agent loop with no circuit breaker doesn't fail loudly. It fails expensively and quietly. LoopGuard is a circuit breaker for agent loops, and the reason it needed 391 tests is that the failure mode is the system doing work forever.
4. Understanding you outsource before you learn it. This is the one I can't put a number on, and I think it's the biggest. When a model helps someone ship something that looks professional before they've built the habit of questioning architecture and tradeoffs, the missing judgment has to show up somewhere. Usually it shows up in review, as someone else's time.
The part I keep coming back to
It's tempting to read this as "AI makes codebases worse." That's not what I think. Mixed is the honest word. Teams move faster in some parts of the work and pay more in others.
What concerns me is that the visible metrics got better and the invisible ones got worse. More PRs, faster demos, more movement. Those are real signals, but they don't tell you whether understanding kept pace, whether review quality held, or whether you pulled future maintenance pain into a prettier present.
There's also a second-order effect I keep thinking about. If the model writes the first draft, then the reasoning that used to happen while writing now has to happen somewhere else, or it doesn't happen at all. That's a process design choice, not a tooling choice, and most teams haven't made it explicitly.
What I changed
Not "use less AI." I changed where the human attention goes.
- Push more into automation. Humans don't scale attention linearly once volume rises. Deterministic gates don't get tired.
- Review for reasoning, not cosmetics. "Do we understand why this works, what it assumes, and how it fails?" replaces "does this look clean."
- Ask for explanation earlier. If AI can generate a decent draft, then part of the job is making sure judgment still gets trained on purpose, especially for junior engineers.
- Track ownership, not just output. The question isn't how fast we shipped. It's how expensive the next change will be.
I didn't get this right immediately. Some of it only became obvious after the review load got heavier and I realized I was treating symptoms instead of changing the workflow.
The honest limitation
I'm describing a pattern from my own projects. I don't have a clean controlled experiment proving that AI-assisted code costs more to own, and I'd be suspicious of anyone who claims they do. The METR result is a hint, not a verdict. Code quality depends on teams, domains, and how the tool is used.
But I don't need a controlled experiment to say this: if your definition of "faster" stops at the merge, you're measuring the cheap half of the lifecycle.
The question I actually care about
Every team I talk to is measuring generation velocity. Almost none are measuring ownership cost. What would change if you did?
So have you felt the maintenance bill yet, and where did it show up? I'm especially curious whether it landed in review time, in debugging, or in the parts of the system that got harder to change.
