Cognitive Debt Is the Real Cost of Agent-Written Code

The vibe-coding debate of the last year has been fought over the wrong ground. One side says let the agent write everything and ship fast; the other says the code is buggy, unmaintainable slop. The framing on both sides is correctness — will it run, will it break, will the tests pass. That’s a real concern, but it’s not the one that compounds.

The cost that actually accumulates when agents write your code is cognitive debt: systems that run fine and that no single human can fully explain. Not buggy code. Working code you’ve lost the ability to reason about.

Why the bugs framing misses it

“Bugs” is a problem you notice immediately. A test fails, a user reports an error, a deploy breaks — you find it, you fix it, you move on. It’s loud and short-lived.

Cognitive debt is quiet and long-lived. The agent produced a module that works. The tests are green. Nothing is technically wrong. But six months later, when the behaviour needs to change, nobody can say with confidence why it works the way it does — which lines are load-bearing and which are artefacts of a prompt the model has since forgotten. The code is legible to the thing that wrote it. It is increasingly illegible to the people who own it.

That’s a different failure mode, and it doesn’t show up in a code review the way a bug does. It shows up the day someone has to reason about the system rather than just run it.

Why this converts from nuisance to liability

In a consumer tool, cognitive debt is a maintenance tax — annoying, survivable, the cost of moving fast. I build plenty of those, and the velocity is worth the trade.

In a regulated domain it’s something else entirely. Proven Duty automates FCA Consumer Duty compliance for financial advisers. There, “it works” is not the standard. The standard is defensible — can you show a regulator, on demand, why this decision was made, against which versioned rubric, by what reasoning. A system no human can reason about cannot be defended. It can only be asserted.

That’s the line where agent-written code stops being a craft preference and becomes a liability. The repo being the proof cuts both ways: the proof has to be legible to a human, or you haven’t shipped a system you own. You’ve shipped a dependency on the model that generated it — and a dependency you can’t reason about is one you can’t be responsible for.

The gate that keeps code legible

The fix isn’t to stop using agents. The fix is to make the review loop do double duty — as a readability gate, not just a correctness one. Every agent-written change has to clear two questions, not one:

• Does it work? (correctness)
• Can the next person — or a regulator, or me in six months — explain why? (legibility)

That second question is the one vibe-coding culture quietly dropped, and it’s the one that determines whether the system you shipped is yours or rented. It’s also the same loop I described for evaluation — score, threshold, route, audit — only now the rubric includes “is this legible to a human,” not just “is this correct.”

The trade nobody names

The promise of agentic engineering is that one person can now ship what took a team. That’s true, and it’s the whole premise of how I work. The trade nobody names is that the same leverage lets one person accumulate, at machine speed, a system too large and too opaque to ever fully understand again. Velocity without legibility isn’t a shortcut to a shipped product. It’s a shortcut to owning something you can’t actually run.

The agents that age well are the ones whose builders treated “can a human still explain this?” as a first-class requirement, checked on every change, the same way they checked the tests. The ones that don’t are the systems people eventually throw away and rewrite — not because they broke, but because nobody could remember how to think about them.

---

“It works” is the floor. “I can explain why it works” is the product. The first you can delegate to an agent; the second is the job that’s left.