10x Productivity: What the Promise Leaves Unaccounted For

Developers I speak to seem to be increasingly proud to say they have maxed out their AI coding assistant usage. It comes up almost as a flex — I burned through my whole allocation by Wednesday — a way of signalling genuine engagement with the tool, evidence that the investment is finally paying off.

I find this an interesting reaction, because the underlying event is, financially and operationally, more ambiguous than the pride around it suggests — and the implications run considerably deeper than any single developer’s output.

A New Kind of Variation, Wearing a Financial Disguise

For years, the cost of developer tooling was close to negligible. IDEs were free or near-free. The economics of software development rested on one large, predictable line item: salary. As I explored in a previous piece on the Age of Tools, this is the third shift our industry has lived through — from process, to people, to tools — and the tools era has already changed how we budget once, with the move from free IDEs to paid per-seat licences. That was a manageable adjustment. A flat, known number.

What is happening now is a second, sharper shift, arriving close on the heels of the first. Per-seat licensing is giving way to usage-based, token-metered consumption. And the genuine productivity gains some teams report — the much-discussed 10x team, the promised land of AI-accelerated delivery — create a temptation that I think deserves more scrutiny than it currently receives: organisations begin to plan, commit, and re-baseline as though that elevated capacity were a stable, permanent feature of the system.

In short, this 10x capacity is not stable, and does not hold up under scrutiny. One of the reasons connects directly to the queueing theory argument I made earlier in this series.

Consider what actually happens when usage allocations are consumed. It is not one developer, on a predictable schedule, who reverts to baseline. Max-outs occur stochastically, across the whole team, at different points in the sprint, with reset windows that are themselves unpredictable — a token clock might reset in five hours, or considerably longer, depending on how the provider accounts for usage. At any given moment, you do not know how many of your developers are operating at the assumed elevated capacity and how many have silently reverted to unassisted work.

This means the high-capacity state that an organisation may have adapted itself to — adjusted sprint commitments, accelerated planning cadence, upstream requirements flow tuned to match a faster delivery rhythm — is not a stable state at all. It is a fluctuating one, and the fluctuation is, in most organisations I encounter, entirely unmodelled. The risk is not that one developer’s throughput dips. It is that the team’s effective capacity moves unpredictably between something close to the 10x promise and something closer to baseline, multiple times within a single sprint, with no visibility into which state the system is actually in at any given moment.

Every upstream process that re-baselined around the higher number now inherits that variance. Planning cycles built for accelerated throughput. Requirements pipelines tuned to keep pace with a faster team. Stakeholder review cadences adjusted to match. None of these processes were designed to absorb a team whose effective capacity oscillates stochastically — they were designed, at best, for a different and more forgiving kind of variation: the bounded, well-studied unevenness of human developers working at a roughly known rate, the subject of the opening article of this series.

Why the Risk Stays Invisible

There is a useful, if uncomfortable, parallel here with the work of Daniel Kahneman and Amos Tversky (1): people tend to weigh visible, immediate gains far more heavily than the less visible risks attached to them. I find something similar happening with token consumption at the team level: the gain — a genuinely faster sprint, a sense of organisational momentum — is salient and celebrated. The corresponding risk — an entire system re-baselined around a capacity figure that cannot actually be sustained continuously, because the mechanism producing it is itself intermittent and unpredictable — remains largely invisible, because nobody is tracking capacity and budget as a single, connected system.

None of this is an argument against usage-based tools, or against the genuine productivity gains some teams are experiencing. It is an argument that software engineering has not, in fact, been solved by AI-assisted development — and that improvement work remains as relevant in this era as in any other. The bottleneck was never in the coding; AI-assisted development does not remove that truth, it simply produces a new generation of bottlenecks, this time in the unpredictable interplay between budget, capacity, and delivery. Surfacing and resolving bottlenecks of any kind has always required time-tested improvement practice, not faster code. That work does not become unnecessary because the tools changed. If anything, it becomes more necessary, because the system producing the bottleneck is now harder to see.

(1) Kahneman, D. (2011). Thinking, Fast and Slow (Amazon UK link).

If you’re ready to go further, let’s explore how connecting your financial and delivery models can work for your team. Reach out today, and let’s make the invisible risk visible before it shows up in a missed sprint.