Output can be parallelized, understanding can't. Why organizations are quietly converting responsibility into risk right now — and why it only surfaces when something breaks.
The bill nobody adds up
There's a lot of celebrating in team chats right now. Twenty pull requests this week, thirty next. The agents run overnight, the diff is ready in the morning, the pipeline is green. Throughput is the metric of the hour, and it's pointing steeply up.
One question rarely comes up in these chats: how many of these changes has anyone actually understood? Not skimmed, not waved through because the tests passed — understood in the sense of: I can explain why this change is right, what it moves in the system, and what happens if it doesn't.
That the question is missing isn't the failing of individual teams. Throughput can be counted, understanding can't, and what can't be counted shows up on no dashboard. It's only noticed once it's missing.
And yet the underlying limit isn't new. A developer can review one change thoroughly. Maybe five. Maybe twenty, if they're small and the tests are good. Somewhere past that, review turns into skimming, and skimming into spot-checking. This limit was always there — it was just never reached, because humans couldn't write code at the pace agents produce it today. Now it's crossed weekly, and the gap between what gets produced and what someone understands keeps growing.
The industry has learned to scale output. The number of people who can speak for that output has stayed the same.
What happens to responsibility when nobody wants it
The obvious expectation would be: organizations notice this gap and appoint someone to close it. Someone accountable for what the agents build.
In most companies that won't happen, and it's worth being honest about why. Responsibility is an uncomfortable cost item. Organizations rarely handle uncomfortable cost items by assigning them to a person — they spread them until no one can see them anymore. The team is responsible. The process was followed. The vendor is liable per the contract. Insurance covers the rest. Each of these answers is reasonable on its own, many of them are even good practice. Taken together they add up to something else: organized diffusion.
Diffusion works surprisingly well. It keeps operations calm, it protects individuals from blame, it satisfies audit requirements on paper. It has just one property that's rarely talked about: responsibility you diffuse doesn't disappear. It converts — into risk.
The difference doesn't show in normal operation. It shows in the incident. Insurance can pay, but it can't explain why the system decided the way it did. The vendor can point to its contract clauses, but it doesn't fix the incident. The process can prove that every sign-off was in place, but it tells no one what to do now. All of these mechanisms distribute the consequences of a problem. None of them create the ability to act.
And so, in a real emergency, something interesting happens — across every corporate culture, including the ones that explicitly commit to being blameless: the organization looks for the person who can explain the system. Not to hold them accountable — to become able to work again.
Understanding is a resource with a leak
Because while the body of the system grows, two things happen to the understanding of it. It grows much more slowly — understanding can't be parallelized, it forms at the pace at which people penetrate systems. And it leaks away: with every project change, every reorganization, every consultant whose contract ends. In an industry where teams reshuffle every twelve to eighteen months, that isn't a fringe phenomenon but the normal case.
As long as humans wrote the code themselves, this partly corrected itself. Whoever builds something inevitably understands it; the writing was the learning. That coupling is in the process of dissolving. A system today can grow, be extended and rebuilt over months without the growth in code having produced a corresponding growth in understanding — in anyone.
You could call this second-order technical debt. First-order debt everyone knows: the quick hack, the missing abstraction, the module no one wants to touch. Unpleasant, but treatable — debt on code can be refactored. Debt on understanding has to be re-earned, by people who never knew the system. That's possible, but it's slow, expensive work, and it almost always begins under the worst conceivable circumstances: mid-incident, under time pressure, with a system that is currently proving it wasn't understood.
The insidious thing about this debt is its invisibility. No linter finds it, no metric spikes, the system runs, after all. It just runs increasingly without witnesses.
In regulated environments the mechanism is already visible
Anyone who wants to see how this ends doesn't have to speculate. It's enough to look where traceability has long been not a virtue but a requirement: banks, insurers, critical infrastructure.
There, the scaffolding of authorship, sign-offs and history exists not because these institutions love bureaucracy, but because the question "who can explain this" is actually asked there on a regular basis — by auditors, by regulators, and in the event of damage, by courts. Diffusion hits its limit faster in these environments because the emergency is institutionalized. It doesn't maybe come someday; it comes in the audit cycle.
Machine-generated code doesn't bypass this scaffolding, it runs straight into it. And the regulation moving into its next stage in Europe this year at its core only formalizes what already holds true: systems whose decisions no one can explain are a risk — technically, commercially, legally. The requirement isn't new. What's new is that it now applies to the parts of the system that no person wrote.
The rest of the economy is far from this audit density, and much of it will never reach it. But the mechanism is the same, only the trigger is different: where the auditor is missing, the incident takes over the role. It comes unannounced, but it asks the same question.
More on that elsewhere. Here it's enough to observe that the regulated industries are currently demonstrating what happens when diffusion meets an emergency that arrives on schedule.
What the few will do
I'm deliberately not writing what companies should do. Most will take the path of diffusion, it's rational in the short term, and appeals change little about that in my experience. More interesting is what the few will do who have understood the mechanism — whether out of regulatory necessity, or after the first expensive incident.
They won't use less AI. The productivity level is real, and no one goes back behind it. Instead, they'll work differently in three places.
They'll cut responsibility to size rather than centralize it. One human "over everything" isn't a structure, it's a bottleneck. What holds up are smaller, clearly bounded areas in which someone actually knows a piece of the system — with the honest consequence that throughput per area is limited. The limit was always there; this only makes it visible instead of ignoring it.
They'll demand evidence rather than trust. When no one can check every line anymore, what gets checked shifts. An agent that only delivers results demands blind trust. An agent that delivers proof alongside them — tests that actually cover the business requirement, validation against defined criteria, a traceable rationale for non-trivial decisions — demands judgment. The human checks the evidence, not the diff. At this volume that's not a weaker review, but the only one that still deserves the name.
And they'll capture decisions, not just changes. The diff shows what changed; the why is the only thing anyone will still care about in two years — and the only thing that survives the leaking of understanding when people leave. That's why we work decision-driven rather than ticket-driven internally; anyone who wants the detail will find it documented under D³. The core is independent of the framework: a captured decision is transferable. Understanding that lives only in heads is not.
None of this is a tool, and none of it can be bought after the fact. It's architecture — not that of the system, but that of the responsibility for it. Whoever doesn't design it deliberately gets one anyway. Diffusion is one too, after all.
The new scarcity
I wrote in January that software will soon cost nothing — and that exactly this becomes expensive. The argument can be carried further.
When writing costs nothing, writing is no longer a competency anyone pays for. When even decisions are increasingly prepared, simulated and proposed, the space narrows further. What remains is what in principle can't be generated: knowing a system well enough to explain its decisions, place its errors, and name its limits — in normal operation, and above all when it ends.
This ability didn't scale along while output did. It leaks with every reshuffle and grows back only slowly. That's the definition of a scarce resource, and scarcity sets prices — regardless of whether organizations price it in today or only when the first incident adds up the bill.
For developers this means a shift, not a threat. The question is no longer how much someone produces; production is solved. The question is how much system someone can speak for. That can't be claimed, only proven — at the latest, the first real emergency separates the two reliably.
And for organizations it means: the agents aren't the risk. The risk is a body of system that grows faster than the understanding of it — with a running conversion of responsibility into diffusion and of diffusion into risk. This gap doesn't close on its own. Some will close it deliberately. Most will measure it when the time comes.
It's worth knowing the answer before the question is asked.