What happens to technical debt when AI makes code cheap?

What if turning five weeks of implementation into one meant you could get to production and start learning sooner?

Getting to 80% good enough is the part that is practically instant now, but as you get into, we don't really bottle up that win and spend it well

One thing AI probably makes cheaper is replacing code. What it doesn’t automatically make cheaper is replacing history. Ten years of edge cases, operational knowledge and customer dependencies can still be hiding behind a module an agent can rewrite in an afternoon.

"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."

This resonated with me beyond just coding, building, and architecture. It's philosophical. Aren't we all doing this all the time? Making reasonable, grounded decisions with the information we have in the moment. I look back at my early builds and think they're silly. I look back at decisions I made in my 20s and those are even sillier.

Great post!

The "build faster than we learn" part is where I keep getting burned. I've spent weeks helping untangle prompt templates from a pipeline where someone encoded a data assumption in week one and then everyone just built on top of it. Nobody wanted to touch it because by week four there were six tools downstream that all expected that shape. AI made it trivially easy to add more things on top of the wrong foundation, and that version of debt is somehow even less visible than messy code.

"AI can compress implementation time, not learning time" - agreed, and there's a second asymmetry hiding underneath it: learning doesn't accumulate by default. The lesson production teaches you in week 40 usually lives in a postmortem, a Slack thread, or one engineer's head - and the next build starts from the same priors that created the debt. Faster implementation without retained learning isn't a shorter loop; it's the same loop at higher RPM. You re-make the week-one assumption Tae describes, faster, in three more places.

So I'd give "spend the speed on learning" a storage half: when a decision turns out wrong in production, record it at the moment it resolves - not the week-one symptom, but the triple of what we assumed, what broke it, and what holds now - and make that land in front of whoever (or whatever agent) makes the next adjacent decision. We got a live demonstration of the gap this week: our own monitoring had been announcing a failure for hours while the "learning" sat unconnected in an alert channel; the fix took minutes once someone carried the alert to the code. Debt as "the gap between what we decided then and what we learned later" shrinks exactly as fast as that feedback gets fed back into the next decision - and no faster.

The framing that really lands for me: technical debt as "the gap between decisions we made then and what we learned later" — that's not a code quality problem, it's a learning latency problem, and AI agents can't fix that part.

Where I've seen AI genuinely help on the debt side: running it against legacy code with a characterization-test-first loop. I point a local agent (Ollama + an open model, costs me $0 and the code never leaves my machine) at one gnarly module, have it write tests that pin the current behavior — bugs included — and only then let it refactor. The "congrats, it's a feature now" class of debt survives the refactor because the tests encode it. Without that step, the agent happily "fixes" the bug that three customers depend on.

But your other point is the one that keeps me up: AI makes debt incredibly easy to create. Velocity went up 3x in my side projects, and so did the half-finished abstractions I only half-reviewed. Cheap code means the review bottleneck, not the writing bottleneck, is now where debt accrues.

Curious how others handle this: do you review AI-generated code with the same rigor as a junior dev's PR, or have you built a different gate (evals, mutation testing, something else)?

Most of the thread is about spending the speed better inside engineering. The thing I'd add is that in some places the loop has a floor engineering doesn't control.

Regulated change runs on process time — approval, evidence, anything that moves money or touches customer data. Those cycles are set by other people's calendars, not by how fast the code appeared. So compressing five weeks of implementation into one doesn't put you in production five times sooner. It queues five times as much work in front of a stage that never sped up. And piling work in front of a fixed bottleneck doesn't just fail to help, it makes things worse: bigger batches, longer waits, more work sitting in the queue going stale while it waits.

Which sharpens your conclusion rather than arguing with it. If there's a floor, then more implementation is the single worst place to spend the speed. The interesting spend is on whatever the gate actually consumes, which is evidence. Most of what makes an approval slow is a human reconstructing what changed and why it's safe to ship. That part is generatable now, and unlike code, nobody is flooding that queue yet.

Brandolini's law applies to diffs too. 87 files is cheap to produce and expensive to refute.

The practical guardrail I’ve found is to make the learning loop explicit in the delivery contract: every agent-sized change gets a small production hypothesis, an observable signal, and a rollback or feature-flag path. That keeps “ship sooner” from becoming “merge faster and learn later.” It also makes review cheaper because the question is not only whether the diff is correct, but what evidence will tell us the design was wrong.

This landed for me as a freelancing problem as much as an engineering one. When agents make the first draft cheap, the temptation is to fill the calendar with more build tickets — and that’s exactly when “reasonable week-one assumptions” calcify into debt nobody wants to reopen.

A habit that helps on client work: spend part of the speed budget on a one-page learning brief before the next feature dump. Three lines only: what we assume is true, what production signal would falsify it, and what we’re deliberately not building this week. It forces the observe → learn → change loop you describe instead of build → build → build.

I’ve also started treating giant AI PRs the way Brandolini would: if review energy is 10× generation, the deliverable isn’t “more files,” it’s a smaller change with an explicit hypothesis. Curious whether others gate agent work on a written learning question, or if you only add that after something breaks in production.

Interesting perspective. One thing I'd add is that context matters a lot here — the right approach depends heavily on team size, project stage, and existing infrastructure. There's rarely a one-size-fits-all solution.