There are two confident stories about technical debt right now, and they can’t both be right.
The first is the one you’ve heard for a decade: debt is a time bomb. Every shortcut, every duplicated block, every “we’ll clean it up later” compounds silently until one day the system is too brittle to change and the interest payment comes due all at once. Ship fast, pay forever.
The second story is newer, and it’s being told by people worth listening to. On a recent episode of DevOps Paradox, Viktor Farčić — someone who spent years evangelizing clean code — walked his own religion back in real time. Asked how to prepare for the coming wave of technical debt, he said that six months ago he’d have given the standard sermon about readable, well-structured, DRY code, and now he isn’t sure it matters. Why did duplication ever cost you? Because fixing it in five places took five times as long. “Okay, so it takes a full minute instead of 10 seconds,” he said. “So what?” Refactoring, he pointed out, is now one of the easiest things you can hand an agent — far easier than getting it to build the feature in the first place. Tell it to find the repeated pattern, extract it, re-run the tests, done in half an hour. By that logic the time bomb has been defused. Accumulate freely; remediation is cheap now.
He’s right. And the conclusion is still wrong — because “technical debt” was never one thing, and AI made one half of it cheap while making the other half worse.
Code was the toll booth
Split the debt in two.
There’s code debt: the implementation is messy, duplicated, badly named, over-complex. This is what Farčić is talking about, and this is the half that got cheap. An agent can rewrite a hundred thousand lines of it overnight. Caring whether a function is camelCase is, fairly, a worse use of your attention than it used to be.
Then there’s decision debt: the unrecorded why behind a system. Why this data model and not the three you rejected. Whether the thirty-day retention window was a hard requirement or a default nobody questioned. Which strange behavior users have quietly come to depend on. What you deliberately chose not to build, and why. None of that is code. It’s the set of decisions the code is the output of.
Here’s the part the cheap-code story misses. For the entire history of software, writing code was how you paid for those decisions. You couldn’t build the thing without making the calls — the act of implementation forced them out of you, one at a time, and left a trail: in your head, in commit messages, in the branches you abandoned. Expensive code was a toll booth. It was slow and it was annoying and, as a side effect nobody noticed, it guaranteed that by the time a system existed, someone had decided why it was that way.
AI tore the toll booth down. That’s the whole promise — describe the outcome, skip the implementation. But the implementation was doing a second job. Remove it and you can now produce a complete, running, plausible system having made almost none of the decisions consciously. The model made them — picked the data model, the auth pattern, the retention window, the error handling — implicitly, invisibly, and you never saw a choice presented as a choice. The code got cheaper. The decisions didn’t get made.
Why the prototype is where you can see it
Watch this play out in the artifact everyone agrees is disposable: the vibe-coded prototype.
In the healthy version Farčić describes, an experienced engineer takes a prototype, learns what it reveals, and throws it away — “this goes to trash and we start over.” This is supposed to be fine, and it is, but pay attention to what survives the deletion. The code is gone; the decisions aren’t. Building it forced the engineer to choose, and they keep those choices. That’s exactly why the restart is fast — the valuable residue was never the code.
Now run it without the engineer. A non-technical team vibes a tool for six months — Farčić’s own example — until it’s quietly become the system they depend on and hits the point where it has to be rebuilt or replaced. Nobody ever decided to promote it to production; it accreted there. And when you throw this prototype away, there is nothing in anyone’s head to keep, because no human made the calls. The model did, as defaults, and half of them were coin-flips indistinguishable from the load-bearing ones.
That’s the hinge, and it’s the inversion of the throwaway wisdom: the old throwaway prototype lost the code and kept the decisions. The vibe-coded one keeps the code and never had the decisions. “Throwaway” used to describe the cheap part you were glad to discard. Now it quietly describes the expensive part too — except you can’t discard what you never had, so it doesn’t feel like a loss. It feels like an asset. It runs.
The debt AI can’t refactor
This is why decision debt is the half that got worse, not better, in the exact moment code debt got cheap.
Refactoring — Farčić’s escape hatch, and a real one — operates on code. Point an agent at a tangle and it untangles it. But a decision that was never made is not in the code for an agent to find. Ask the model why retention is thirty days and it will invent a reason as fluently as it would recite a real one; it has no idea, because there wasn’t one. Cheap execution can regenerate the implementation endlessly and cannot reconstruct a single decision nobody recorded. The bill doesn’t come due at ship time, when everything works and everyone’s pleased. It comes due at change time — when you need to know what’s safe to touch and discover that the thing you depend on was assembled by no one, defended by no one, and understood by no one.
Farčić is right that you’re rarely stuck — the code will bend. What won’t bend is your ignorance of why it’s shaped the way it is. That’s not a refactoring problem. There’s nothing to refactor.
Put the toll booth back — on purpose
The fix is not to slow down, and it is emphatically not to hand-write code again to keep a discipline that hand-writing used to enforce for free. The toll booth is gone and good riddance. But it was doing real work, so that work has to be done deliberately now instead of arriving as a side effect.
Installing forcing functions once the natural ones disappear is, more or less, the entire premise of ProductHarness — and the same logic already runs through it. Its governance model doesn’t trust anyone to keep a decision record current out of goodwill; it makes the upkeep a scheduled and event-driven obligation, because “the schedule creates the forcing function.” Its hypothesis and experiment records are deliberately separate, first-class, version-controlled artifacts, written in a fixed order so the important call can’t quietly bend to the convenient one. The friction is the point.
Decision debt is that same problem one level down. Treat the decisions a system embodies the way the framework already treats a hypothesis: as a required artifact, distinct from the implementation and not derivable from it — the data model and the ones it beat, the assumptions baked in, the behaviors now load-bearing, the things deliberately left undone. Not documentation of the code; the code documents itself well enough, and an agent can re-derive it. This is the record of intent the code can no longer be trusted to imply, because a human no longer had to form that intent to produce it. In ProductHarness’s own model of the work, a prototype is a discovery step whose job is to produce validation and acceptance criteria before anything crosses into delivery. The vibe-coded disaster is a prototype that skipped its own loop — it crossed into production without ever paying out the decisions the crossing was supposed to collect.
Do that and the prototype goes back to being safely disposable: keep the decisions, bin the code, the way it was always supposed to work. Skip it and you get the thing that looks like a gift and is actually a loan — a system that runs, that no one chose, accruing the one kind of interest your agents can’t pay down.
Half your technical debt did just get cheap. The other half moved somewhere refactoring can’t reach — and the only thing that pays it down is deciding, on purpose, what the cheap code no longer makes you decide.
Source. Viktor Farčić and Darren Pope (hosts), “DOP 329: Vibe Coding and the Technical Debt Time Bomb,” DevOps Paradox, YouTube, published December 17, 2025: youtube.com/watch?v=ayDQs_pgnv4. All characterizations of their remarks are drawn from this episode; quotations are transcribed from it and lightly punctuated for readability. The reversal-on-clean-code argument and the “a full minute instead of 10 seconds” and “this goes to trash and we start over” remarks are Farčić’s. I have no relationship with DevOps Paradox or either host.