Dear past Jenna,
I know you're used to dealing with large, complex, legacy codebases riddled with technical debt. And for the longest time, that w...
For further actions, you may consider blocking this person and/or reporting abuse
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
Yeah, I feel like we're all being pushed to just start more work with that 20%, but I also don't think that everyone realizes/acknowledges we're doing this (other than those added pressures to do more, bigger, better, faster, all the time) - to some extent, this is all still so shiny to us.
Thanks for reading Ben!
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.
Agreed. Thanks for reading!
"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!
Yes, totally! I feel like we've got the blinders on right now though and forget this sometimes.
Thanks for reading!
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.
The "build faster than we learn" line is the real trap. When I let coding agents rip through a refactor, the PR looks clean and the debt just moved: duplicated helpers, half migrated call sites, tests that assert the new wrong shape. Cheap code makes the backlog of "we should clean this" grow faster than any agent can burn it down, because the expensive part was never typing. It was noticing which shortcuts became load bearing after real traffic hit them.
Good technical content. I'd love to see more exploration of the edge cases and failure modes — understanding when and why these patterns break down is often more valuable than knowing how to implement them.
I think “we can build faster than we learn” is a key point. The opportunity isn’t simply to use AI to produce more code in the same amount of time. It’s to shorten the entire learning loop—get something into use, understand what is actually happening, compare that with what we intended, and feed what we learn into the next iteration.
Otherwise, we’re generating code faster while still relying on disconnected dashboards, support tickets, postmortems, and people’s memories to tell us what should change. That may actually accelerate the accumulation of technical debt.
The bottleneck hasn’t disappeared. It has moved from creating software to evaluating it, learning from it, and deciding what to do next.
The characterization-test-first loop is the right instinct. AI-generated debt is harder to catch because it's locally coherent, each file looks fine but the week-one assumption got silently propagated across 87 files before anyone noticed.
The expensive part was never writing the code. It was understanding which shortcuts became load bearing after real traffic. That's still a human job.
The line that got me: "AI can compress implementation time. It can't necessarily compress the time it takes to learn what the system needs to become."
We hit this building automation at viaSocket. An agent can wire up an integration in minutes that used to take a day. But the failure modes only show up after real traffic hits it - a webhook that fires twice, a rate limit that only trips at scale, an edge case in someone's actual data. None of that shows up in a demo, no matter how fast the agent built it.
The scary part isn't more technical debt. It's that debt used to be visible - you could point at the ugly function and say "that's debt." When an agent writes something clean and readable that just happens to be wrong about how the system actually gets used, it doesn't look like debt. It looks like good code. You only find out in production, same as always, except now there's ten times more of it to find out about.
“Implementation can move faster than learning” gets to the heart of the risk. When AI lowers the cost of writing code, the response shouldn't be bigger backlogs—it should be tighter validation loops: smaller increments, explicit acceptance criteria, and intentional debt checkpoints. Accelerating output without accelerating feedback just compounds wrong assumptions faster.
Appreciate the practical approach here. The real test of any pattern is how it holds up over time — would be interesting to see a follow-up covering how this has scaled as the project grew.
Solid write-up. For anyone implementing this in production, I'd recommend starting with the simplest version that works and iterating based on actual metrics rather than premature optimization.