{"slug": "what-happens-to-technical-debt-when-ai-makes-code-cheap", "title": "What happens to technical debt when AI makes code cheap?", "summary": "Jenna Pederson, a software engineer, explores how AI's ability to generate code cheaply affects technical debt. She argues that while AI can help fix technical debt by automating refactoring and testing, it also makes it easier to create debt by compressing implementation time, which reduces the learning that traditionally occurred during development. Pederson suggests that teams should use the time saved to ship sooner and learn from production, rather than accumulating large systems without understanding them.", "body_md": "Dear past Jenna,\n\nI know you're used to dealing with large, complex, legacy codebases riddled with technical debt. And for the longest time, that was kind of your thing. You'd unwind them, figure out how to insert a feature here without breaking functionality there, or discover that customers had come to depend on something that was technically a bug.\n\nI recently saw this post on X (it's no longer a tweet on Twitter, but that's a story for another day):\n\nThe replies and reposts were all over the place, but a number of them went like this:\n\nThe technical debt is the whole codebase now.\n\nThe thing is, both might be right: AI makes technical debt easier to fix. Agents can refactor repetitive patterns, migrate dependencies, add tests around legacy behavior, and tackle cleanup work that might otherwise sit in the backlog forever.\n\nCodex, go fix all the technical debt in this repo.\n\nA reasonable request with no follow-up questions whatsoever.\n\nBut AI also makes technical debt incredibly easy to create.\n\nTechnical debt has never just meant bad code, and it isn't necessarily the result of bad engineering. It's often the result of intentional tradeoffs we made at a specific point in time (except for that one guy who just refused to write unit tests).\n\nBut a lot of it comes from perfectly reasonable decisions that became wrong as we learned more about how the system would actually be used and how it needed to evolve.\n\nCodebases grew. Requirements changed. Customers started relying on buggy functionality (congrats, it's a feature now). Systems scaled across teams. Teammates came and went. Dependencies aged. The architecture that made perfect sense three years ago became the thing standing in our way today.\n\nWe made the best decisions we could with what we knew at the time.\n\nThen we put the software in production and learned more.\n\nSome technical debt is simply the gap between the decisions we made then and what we learned we actually needed later.\n\nIt used to take time to turn an idea into a large system. And while we were building, we were also learning.\n\nRemember the [friction we talked about before](https://www.jennapederson.com/blog/you-can-build-it-should-you/)? Some of that friction forced us to pause and ask important questions like, \"Should we build this?\" Designs changed. Requirements were questioned. Implementation and learning happened somewhat concurrently.\n\nNow, engineering teams can accumulate an entire system before they fully understand what they're building (or what they've built).\n\nAI can compress implementation time. It can't necessarily compress the time it takes to learn what the system needs to become.\n\nI'm not arguing that slow development was good. But some of the time we're eliminating was time we spent learning.\n\nSome of my hardest lessons came from production issues that were nearly impossible to reproduce in a test environment.\n\nThreading and concurrency bugs. Or those bugs that required a very specific alignment of the stars between customer data, system state, timing, and apparently the current phase of the moon (I'm looking at you, VAT tax calculator of 2009).\n\nA design can appear completely reasonable until you put real traffic on it. Real traffic introduces timing problems, race conditions, and interactions you didn't anticipate.\n\nAn agent might build a system that performs exactly as expected. It might even anticipate problems we wouldn't.\n\nBut neither of us has a crystal ball.\n\nWhile [agents can help us implement faster](https://www.jennapederson.com/blog/are-we-the-abstraction-ai-and-the-future-of-software-engineering/), that's not the same thing as learning faster.\n\nInstead of:\n\nbuild → build → build → build → build → ship → observe → learn → change\n\nWhat if turning five weeks of implementation into one meant you could get to production and start learning sooner?\n\nbuild → ship → observe → learn → change → repeat\n\nImplementation has gotten much cheaper. But reviewing, testing, validating design decisions, securing, operating, and learning from production haven't gotten cheaper at the same rate.\n\nI ran across [Brandolini's law](https://en.wikipedia.org/wiki/Brandolini%27s_law) (the \"bullshit asymmetry principle\") last week:\n\nThe amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.\n\nThe code can be perfectly fine and still take much longer to review than it did to generate.\n\nCodex, refactor this module without changing its behavior.\n\n87 files changed.\n\nAn agent can produce a giant PR in minutes. Figuring out whether it should even exist, whether it's correct and secure, fits the system, and will be maintainable can still take hours.\n\nAnd all of this is happening in an environment that's now go, go, go.\n\nThe expectation that \"agents make you faster, so now you can do more work, all the time\" is real. If leadership sees faster implementation and responds by asking for more of everything, then we're pushing more software through engineering processes that haven't experienced the same speedup.\n\nThe problem starts when we spend all of that speed on more implementation before we’ve learned enough to know it's worth spending time on.\n\nI hope AI really does mean we won't have to live with technical debt the way we have in the past. Maybe agents will eventually manage much of it continuously, without us even thinking about it. And how we create, carry, and pay down technical debt may look completely different in a few years. I just don't know yet.\n\nWhat I do know is that we don't have to spend all the time AI gives us on more code.\n\nWe can ship something, find out where we were wrong, change it, and do the whole thing again.\n\nSo for now, maybe we use faster implementation to shorten the whole learning loop.\n\nUntil the next postcard.", "url": "https://wpnews.pro/news/what-happens-to-technical-debt-when-ai-makes-code-cheap", "canonical_source": "https://dev.to/jennapederson/what-happens-to-technical-debt-when-ai-makes-code-cheap-9oa", "published_at": "2026-09-01 14:01:00+00:00", "updated_at": "2026-09-01 14:23:58.757569+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "ai-agents", "artificial-intelligence"], "entities": ["Jenna Pederson", "Codex"], "alternates": {"html": "https://wpnews.pro/news/what-happens-to-technical-debt-when-ai-makes-code-cheap", "markdown": "https://wpnews.pro/news/what-happens-to-technical-debt-when-ai-makes-code-cheap.md", "text": "https://wpnews.pro/news/what-happens-to-technical-debt-when-ai-makes-code-cheap.txt", "jsonld": "https://wpnews.pro/news/what-happens-to-technical-debt-when-ai-makes-code-cheap.jsonld"}}