I keep the diagnosis deflationary on purpose

Everyone is naming the new bottleneck — coordination, specs, verification, taste. I'd rather claim less. The old one is loosening, and in a moment of genuine flux, claiming less is more stable than claiming more.

I've been writing about this for a while, and the temptation to name a replacement is enormous. Every editor wants it. Every conference panel wants it. Every LinkedIn algorithm rewards it. But I keep coming back to the same instinct: when the ground is moving, the honest thing is to describe how it's moving, not to plant a flag on where it'll stop.

The Inflationary Reflex

Open LinkedIn on any given Tuesday and someone has identified the new bottleneck. Last week it was coordination. The week before, spec writing. The week before that, taste. Next week it will be evaluation, or context engineering, or something nobody has named yet.

The list grows because each item is a directional bet placed under uncertainty, dressed up as analysis. Most of what looks like sharp diagnosis is really pattern-completion: the human mind doesn't tolerate an unresolved "what's the new constraint?" question, so it fills the gap with whatever metaphor is closest to hand. The candidate sounds confident. The post performs well. And in three months a different candidate replaces it, and nobody goes back to mark the first one wrong.

I've done this. A few times. It's not a moral failing — it's what pundit-shaped pressure does to people who are otherwise careful. But I want to name it, because I think there's a sturdier move available.

What a Deflationary Claim Actually Is

A deflationary claim has three components. It's negative: the old constraint is loosening — the capacity to produce correct code is ceasing to be the dominant problem in software-producing organizations (paper §1). It's directional: this is a trajectory, not an event with a date — we are inside the loosening, not after it. And it's reorganizational: every structure calibrated to the old constraint — roles, rituals, hiring criteria, the very shape of standups — now has to recalibrate.

Notice what's missing. There's no replacement named. That absence isn't timidity. It's discipline. The claim is meant to survive whether the replacement turns out to be coordination, or specs, or verification, or some category we haven't articulated yet. The diagnosis stays useful across many possible futures.

That's the whole point. An argument that asserts less, when the moment is one of genuine empirical flux, is more stable than one that asserts more.

Why the Asymmetry Matters

Think about what it takes to refute each kind of claim.

The inflationary one — "coordination is the new bottleneck" — collapses the moment its candidate turns out wrong. If in two years it's clearly verification, the coordination thesis dies, and everyone who built decks around it has to scramble. The collapse is total, because the claim's load-bearing element was the specific candidate.

The deflationary one only falls if the old constraint isn't actually loosening. That's a sharper, cleaner refutation surface. To kill it you'd have to show that the production of correct code is still the dominant problem — that agents, copilots, and the rest haven't really shifted the rate-limiting step. That's a much narrower target, and the evidence cuts cleanly one way or the other.

It's the same logic as an honest architecture decision record. You don't propose the solution while you're still describing the problem. You describe the problem as precisely as you can, and you leave the solution space open long enough for the right one to surface.

What You Gain by Asserting Less

Three things, and they matter operationally.

First, you can make organizational decisions without tying them to a forecast you'll have to defend. "Our hiring profile needs to stop optimizing for single-channel excellence" is downstream of the deflationary claim alone. You don't need to know what the new bottleneck is. You only need to know the old one is loosening, and that the structures calibrated to it are now misfit.

Second, you keep reading evidence honestly. Once you've publicly bet on a specific replacement, every new data point becomes either confirmation or threat. The deflationary posture lets you stay curious — including curious about your own framework's edges.

Third, and this is the one I care about most: you give the reader the agency to propose their own replacement. If you announce the answer, the reader's job is to agree or disagree. If you describe the loosening, the reader's job is to think — and the conversations that come back are dramatically better. I've seen this in the responses to the paper and to the long-form on Medium: the comments that taught me the most came from people who were doing their own diagnosis, not nodding at mine.

Quick Test for Your Next Public Take

Before you post, ask yourself two questions.

Are you describing what's loosening, or are you naming what comes next? Both are legitimate things to do, but they ask different things of you and of the reader. The first is diagnosis. The second is prediction.

If you're naming what comes next — what evidence would make you retract? Write it down before you publish. If you can't answer, you're probably inflating. That's not a verdict against you; it's a flag that your claim is doing more work than it should, and the next few months will test it harder than you've tested yourself.

What's the most useful deflationary claim you've heard this year about AI and software? Send me a DM or reach out via the contact channels at rlabs.cl — I'll share mine, drop yours.