{"slug": "ai-wrote-half-my-codebase-the-maintenance-bill-showed-up-in-month-three", "title": "AI Wrote Half My Codebase. The Maintenance Bill Showed Up in Month Three.", "summary": "A developer who uses AI coding tools daily reports that while AI-generated first drafts cut generation costs to near zero, review and maintenance costs stayed flat, producing projects that look highly productive in week one but grow increasingly expensive by month three. The engineer cites a 2025 METR study finding experienced open-source developers using AI tools took 19% longer despite believing they were faster, and built four tools — CauterRule, ai-tierforge, and LoopGuard — to instrument the hidden ownership costs of debugging generated code, per-task cost tracking, and runaway agent loops.", "body_md": "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.\n\nI 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.\n\nSo 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.\n\nEvery 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.\n\nAI 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.\n\nSo 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.\n\nThe 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.\n\nWe caught it later, after downstream behavior stopped matching what users expected.\n\nWhat 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.\n\nI wrote about this at the time in [AI-Assisted Engineering: Faster to Build Isn't Cheaper to Own](https://dev.to/debashish_ghosal/ai-assisted-engineering-faster-to-build-isnt-cheaper-to-own-1lh). 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.\n\nOver 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.\n\n**1. Debugging generated code, including your own.** [CauterRule](https://github.com/deghosal-2026/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*.\n\n**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](https://github.com/deghosal-2026/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.\n\n**3. Loops that never terminate.** A generated agent loop with no circuit breaker doesn't fail loudly. It fails expensively and quietly. [LoopGuard](https://github.com/deghosal-2026/ai-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.\n\n**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.\n\nIt'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.\n\nWhat 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.\n\nThere'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.\n\nNot \"use less AI.\" I changed where the human attention goes.\n\nI 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.\n\nI'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.\n\nBut 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.**\n\nEvery team I talk to is measuring generation velocity. Almost none are measuring ownership cost. What would change if you did?\n\n**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.", "url": "https://wpnews.pro/news/ai-wrote-half-my-codebase-the-maintenance-bill-showed-up-in-month-three", "canonical_source": "https://dev.to/debashish_ghosal/ai-wrote-half-my-codebase-the-maintenance-bill-showed-up-in-month-three-lhp", "published_at": "2026-09-15 21:03:14+00:00", "updated_at": "2026-09-15 21:38:30.025434+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents", "ai-products", "mlops"], "entities": ["METR", "CauterRule", "ai-tierforge", "LoopGuard", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/ai-wrote-half-my-codebase-the-maintenance-bill-showed-up-in-month-three", "markdown": "https://wpnews.pro/news/ai-wrote-half-my-codebase-the-maintenance-bill-showed-up-in-month-three.md", "text": "https://wpnews.pro/news/ai-wrote-half-my-codebase-the-maintenance-bill-showed-up-in-month-three.txt", "jsonld": "https://wpnews.pro/news/ai-wrote-half-my-codebase-the-maintenance-bill-showed-up-in-month-three.jsonld"}}