What an 8-Year-Old Codebase Taught Me About AI's New Speed Expectations

A few months back I gave a talk at work on how to use AI more efficiently in your workflow, right around when “agentic coding” was still a term people were testing out loud before they trusted it in production. The session was playful, the whole team throwing ideas at each other, nobody taking any of it too seriously yet. It felt like a fun problem to poke at.

It doesn’t feel playful anymore. A few months later, the expectation from us as engineers has blown past anything I’ve seen in six years of doing this. People believe AI lets a team finish work in a fraction of the time it used to take. They’re right. Just not in the way most of them think.

The rewrite I wanted, and the migration I got

Around that same stretch I was looking at a frontend codebase that hadn’t been meaningfully touched in 8 years, Backbone tightly coupled with React 16, running on Express. My read on it was simple: this doesn’t need a migration, it needs a full rewrite, with a proper design system sitting under it so every team could actually work off the same brand guidelines instead of guessing at them project to project. The product team agreed. Our designer and I started in parallel, he already had the foundation and a few core flows designed, and we spent a good 2-3 months on customer validation calls making sure what we were building actually matched what people needed.

Then someone in upper management decided our UI was fine (it was not) and said we didn’t need any of that, just migrate the old Backbone code over to React. I tried explaining that dragging 8 years of clutter and complexity into newer tech without fixing the architecture underneath it just moves the mess, it doesn’t clean it. I failed to convince them.

I was frustrated enough that I did the exact opposite of what I should have done. I decided the project wasn’t worth my full attention, and I still stand by that opinion, but I should have picked it up more seriously anyway instead of taking it out on the execution. I didn’t plan the migration. I delegated most of it straight to AI, built out a more sophisticated setup as things kept breaking, having the agent make file changes, review them, test them before QA even saw the work, and our usage climbed high enough that I had to tone it down, because there was no allocated AI budget for this, just Claude credits we were burning through.

It broke things left and right, bugs that were entirely avoidable on my end, and the whole thing still took far longer than leadership expected, they’d hoped this would wrap in a week or two, which was pretty ignorant of what we were actually working with.

Why the timeline was never realistic

Two reasons, and neither of them is exotic. The codebase was vast, tangled, and had 8 years of decisions nobody went back to clean up, so almost every change surfaced more things that needed fixing first. And migrating Backbone to React 16 on its own added close to zero value anyway, we’d have still needed to go from 16 to 18 or 19 before any of the structural cleanup that actually mattered was even possible. The move that would have paid off was the one they killed, building the new system on the side with clean architecture and real design decisions, from scratch.

Expecting that to happen in a month or two was, in my opinion, stupid, not because the ambition was wrong but because nobody sat down and looked at what an 8-year-old codebase with active development still running on it actually requires before you touch it safely.

The debt nobody’s pricing in

Technical debt doesn’t announce itself. You don’t feel it accumulating, you just notice, one day, that infra breaks in places it shouldn’t or a flow fails silently and you’re the one left figuring out why. It builds fastest exactly when you’re moving fast, because speed is what makes you skip the engineering decision you should have made at the time a feature or fix went in. A well-architected codebase doesn’t make you immune to debt, it just makes debt easier to clear when you finally go looking for it.

That’s the part of this trend I don’t think most people are accounting for. AI genuinely does let a team ship faster, 5x or 10x faster at a lot of workplaces now, and I’d guess you’re already seeing that expectation land on your own team if it hasn’t already. What nobody’s pricing in is the debt that speed is quietly stacking up, debt someone is going to have to deal with later, usually under worse conditions than the ones that created it.

The lesson I keep re-learning

I’ve been doing this for six years now, starting from coding on paper because I didn’t own a laptop yet, to today, where I’m not even writing the code myself half the time, just directing an agent to do it. Different phase, same problem every time: I plan badly, or not at all, before I start. I’ve learned this lesson enough times now that calling it a lesson feels generous. It’s a habit I still haven’t built.

Engineering was never just about solving the problem. I mean, it is, but that’s not where it shows its value, you go back for efficiency once the solution already exists, and that pass is the part that actually separates engineering from just getting something to run. Speed without it isn’t engineering moving faster, it’s debt piling up quicker, and somebody’s going to be the one clearing it later.