The Relationship Is Breaking Down

For most of software history, producing implementation was expensive enough that we treated it as a reasonable proxy for progress. If a team had written, tested and integrated a substantial amount of software, something expensive had happened. Time had been spent. Decisions had been made. Engineers had worked through enough of the problem to produce an artefact.

That relationship is starting to break down. Modern coding tools can produce working implementation at a rate that would have seemed extraordinary only a few years ago.

This is real productive capacity. A 2026 Management Science paper combined randomized field experiments involving 4,867 developers. Developers given access to an AI coding assistant completed about 26% more tasks.^¹

The interesting question is therefore no longer whether AI can make software developers produce more.

It can.

The more difficult question is:

What exactly are we producing more of?

Code Is an Intermediate Product

Software development contains implementation, but implementation is not the whole production system. Someone still has to decide what should be built. The software has to fit the surrounding system. Changes need review and verification. They have to reach production, work there and eventually change again.

Code moves through all of those activities. It is not the final economic output of them.

Suppose one activity inside a production process suddenly becomes dramatically cheaper. More of that activity can now be performed with the same resources. But making one input dramatically cheaper does not make every complementary input dramatically cheaper at the same time.

If implementation becomes faster while review remains unchanged, review becomes relatively more important. If implementation and review become faster while requirements remain unclear, deciding what should be built becomes relatively more important. If development becomes faster while release remains slow, completed work simply waits for release. And if those activities become cheaper too, the constraint can move again.

This helps explain an apparently contradictory pattern in the evidence. DORA's 2024 research associated increased AI adoption with improvements in individual productivity while simultaneously finding worse software-delivery throughput and stability.^²

A year later, the picture had changed. DORA's 2025 research associated higher AI adoption with increased delivery throughput, while increased instability remained. Its broader interpretation increasingly described AI as an amplifier of the surrounding engineering system.^³

That change is important. It suggests that the downstream problems observed earlier were not necessarily an inherent property of AI-assisted development. Organisations can adapt their processes to new levels of implementation capacity.

But it also makes a more fundamental point. There is no fixed multiplier between faster coding and faster software delivery.

The multiplier depends on the system.

When Code Becomes Cheap

There is another consequence. When something becomes dramatically cheaper, we rarely continue using exactly the same amount and simply pocket the saving. Cheap storage led us to store more data. Cheap computation led us to perform more computation. There is little reason to expect code to behave differently.

As implementation becomes cheaper, software becomes viable for problems where its previous development cost could never have been justified. Small internal tools become affordable. Minor annoyances can be automated. Features that previously sat permanently below the prioritisation line become possible.

This is one of the genuinely exciting consequences of AI-assisted development. We should expect to produce more software. But we should also expect to produce more code simply because code has become cheaper to produce.

Those are not necessarily the same thing.

Code is not usually what organisations claim to optimise anyway. Features are closer. Features appear on roadmaps. They can be counted. They can be demonstrated to customers and management.

But features are also intermediate outputs. A feature may solve a real problem. It may also introduce another concept users need to understand, another workflow, another integration, another operational dependency and another behaviour that future changes must preserve.

Even deployment is not always the final step. A feature can be working perfectly in production without yet becoming useful capability. People may need to learn it. Workflows may need to change. Other systems and processes may need to adapt around it.

More code is not necessarily more software.

More features are not necessarily more capability.

Software Acquires a Future

There is also something different about software once it reaches production.

It acquires a future.

Dependencies change. Requirements move. Systems interact with things nobody expected. Some code disappears quickly. Some survives for decades.

AI may make that future dramatically cheaper too. Coding agents already work on existing systems, not just new ones. Maintenance, debugging, migrations, refactoring and continued modification are increasingly part of AI-assisted development.

There is no reason to assume that implementation becomes cheap while every later part of the software lifecycle remains expensive forever. The productivity shock may travel much further.

But software still has a lifecycle. Whatever costs, risks and obligations remain belong to the organisation that owns the system.

The model that generated the code does not bear the consequence if an apparently sensible change breaks an assumption made ten years earlier.

The organisation does.

AI may reduce costs throughout the software lifecycle. Whatever remains still has to be owned.

More Code Is Not More Software

The answer is not to produce less code simply because code has become cheap. Cheap implementation creates possibilities that were previously uneconomic.

That should be welcomed.

But it changes what our old measures mean.

A hundred lines that remove a recurring manual process may create enormous value. Ten thousand lines implementing a feature nobody needs may create none. A refactoring can remove code while making a system more valuable because it becomes easier to change.

Code volume cannot distinguish between these outcomes. Neither can feature count.

The useful question is:

How much useful capability does the organisation or its customers actually gain?

AI is changing the economics of software production. The challenge is not to resist the resulting abundance. It is to build engineering systems capable of converting it into useful software.

The economics have changed.

The software still has to be owned.

Sources

Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng and Tobias Salz. “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers.” Management Science, 2026. DOI: 10.1287/mnsc.2025.00535. Randomized field experiments involving 4,867 developers; pooled estimate of 26.08% more completed tasks.
Google DORA. Accelerate State of DevOps Report 2024. 2024. The report found positive associations between increased AI adoption and individual productivity alongside negative associations with software-delivery throughput and stability.
Google DORA. State of AI-assisted Software Development 2025. 2025. Higher AI adoption was associated with both higher software-delivery throughput and higher delivery instability. DORA characterises AI principally as an amplifier of the surrounding organisational system.