I 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.
I recently saw this post on X (it's no longer a tweet on Twitter, but that's a story for another day):
Technical debt used to be something you just had to live with in a sufficiently large codebase. No longer.
The replies and reposts were all over the place, but a number of them went like this:
The 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.
Technical 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).
But 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.
Codebases 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.
Some technical debt is simply the gap between the decisions we made then and what we learned we actually needed later.
It used to take time to turn an idea into a large system. And while we were building, we were also learning.
Remember the friction we talked about before? 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.
Now, engineering teams can accumulate an entire system before they fully understand what they're building (or what they've built).
AI can compress implementation time. It can't necessarily compress the time it takes to learn what the system needs to become.
I'm not arguing that slow development was good. But some of the time we're eliminating was time we spent learning.
Some of my hardest lessons came from production issues that were nearly impossible to reproduce in a test environment.
Threading 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).
A 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.
An agent might build a system that performs exactly as expected. It might even anticipate problems we wouldn't.