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. They can create components, tests, migrations, documentation and entire applications in minutes.

This is real productive capacity.

A 2026 Management Science paper combined randomized field experiments involving 4,867 developers at Microsoft, Accenture and a Fortune 100 company. Developers given access to an AI coding assistant completed about 26% more tasks. The individual experiments varied, but the combined effect was substantial.^¹

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 has to understand what should be built. The system needs architecture. Changes need implementation, review and verification. Software has to be released, deployed and operated. Eventually it will fail, require maintenance, interact with something unexpected or need to change again.

Code moves through all of those activities.

It is not the final economic output of them.

This distinction was easy to ignore when writing the code itself consumed so much of the effort. Increase implementation capacity and it was reasonable to expect a substantial improvement in delivery.

AI changes that balance.

Suppose one activity inside a production process suddenly becomes dramatically cheaper. The immediate effect is obvious: more of that activity can be performed with the same resources.

The less obvious effect is that everything around it changes in relative importance.

If implementation becomes faster while review remains unchanged, review eventually determines the pace of the system.

If implementation and review become faster while requirements remain unclear, deciding what should be built becomes the constraint.

If development becomes faster while release processes remain slow, more completed changes simply wait for release.

If all of those activities accelerate but the resulting system becomes increasingly difficult to operate and change, the cost appears later.

None of this is peculiar to software.

It is normal behaviour in a production system.

Making one input dramatically cheaper does not make every complementary input dramatically cheaper at the same time.

The Evidence Gets Messier Downstream

This helps explain why research on AI-assisted development can appear contradictory.

The closer we measure to implementation, the easier the productivity improvement is to see.

The further downstream we go, the more the surrounding engineering system matters.

DORA's 2024 research provided an unusually clear example. Increased AI adoption was associated with improvements in individual productivity, flow and job satisfaction. At the same time, a 25% increase in AI adoption was associated with a 1.5% reduction in software delivery throughput and a 7.2% reduction in delivery stability. DORA suggested that faster code generation could contribute to larger changes, which are harder to review and deliver safely.^²

That result was sometimes interpreted as evidence that AI made software organisations less productive.

The following year complicated the picture.

DORA's 2025 research found higher AI adoption associated with increased software delivery throughput while increased instability remained. Its broader interpretation was that AI acts as an amplifier: the returns depend heavily on the surrounding organisational and engineering system.^³

That change matters.

It suggests that the poor downstream associations seen earlier were not necessarily an inherent property of AI-assisted development. Organisations may already be adapting their processes to a new level 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.

Faster Is Contextual

Even developer productivity itself is not uniform.

In 2025, METR ran a randomized study with 16 experienced open-source developers completing 246 real tasks in mature repositories they already knew well.

The developers expected AI to make them faster.

Instead, the early-2025 tools made them take 19% longer. Even after the experiment, the developers believed AI had saved them time.^⁴

That result received considerable attention, but it should not be stretched beyond what the experiment measured.

These were experienced developers working in codebases they understood deeply. METR itself explicitly warned against treating the result as representative of software development generally.

By early 2026, METR was already finding the experiment harder to repeat. Developers increasingly declined to participate if they might have to work without AI, creating selection effects that made later estimates unreliable. The researchers believed developers were probably receiving greater benefit from newer tools, but could no longer confidently estimate the size using the same experimental design.^⁴

This is not an argument against AI productivity.

It is evidence that software development contains different kinds of work.

Generating a new implementation in an unfamiliar area is different from changing a mature system whose constraints an experienced maintainer already understands.

The cheaper implementation becomes, the more those distinctions matter.

When Something Becomes Cheap, We Use More of It

There is another consequence.

When an input becomes dramatically cheaper, organisations rarely continue using exactly the same amount and simply pocket the saving.

They reorganise around the new economics.

Cheap storage produced systems that store vastly more data.

Cheap computation produced applications that perform vastly more computation.

Cheap network capacity produced software that moves vastly more information.

There is little reason to expect code to behave differently.

If producing implementation becomes much cheaper, organisations will probably produce more implementation.

Some of that will be extremely valuable.

Software becomes viable for problems where the previous development cost could never have been justified. Small internal tools become affordable. Minor annoyances can be automated. Existing products can support features that previously sat permanently below the prioritisation line.

This is one of the genuinely exciting consequences of AI-assisted development.

But it also means that measuring the amount of software produced becomes increasingly misleading.

An organisation might generate twice as much code because it has become twice as effective.

It might also generate twice as much code because code has become cheap enough that nobody feels much pressure to avoid it.

Those are very different outcomes.

Feature Output Is Tempting

Code is not usually what organisations claim to optimise.

Features are closer.

Features are visible. They appear on roadmaps. They can be counted. They can be demonstrated to customers and management.

When implementation capacity rises, increasing feature throughput therefore feels like an obvious use of it.

Sometimes it is.

But features are still intermediate outputs.

A feature can solve a real customer problem. It can also introduce another concept that users need to understand, another path that needs testing, another permission model, another integration, another operational dependency and another behaviour that must be preserved during future change.

And deployment is not always the final conversion step.

Enterprise-systems research has long distinguished between deploying a technical system and making it part of how an organisation actually works. Even after successful deployment, organisations differ in how effectively a system becomes incorporated into their normal business practices.^⁵

ERP cost research makes the same distinction visible from another direction. Implementing a system can include far more than buying hardware and licences: customisation, installation, integration and changes to processes, coordination and ways of working all carry costs of their own. In some projects, those costs can exceed the cost of the underlying hardware and software.^⁶

A feature can therefore be working in production without yet being useful organisational capability.

People may need to learn it. Workflows may need to change. Responsibilities may move. Existing processes may need to adapt around it.

The technical system can be a surprisingly small part of the work required to create the resulting capability.

Feature count does not contain that information.

Neither does code volume.

A production system optimised around visible output can therefore become extremely successful at producing things whose costs, constraints and value appear somewhere else.

Software Engineering Has Seen This Before

Generative AI is new.

Code generation is not.

Software engineering has repeatedly experimented with raising the level of abstraction and generating more implementation automatically.

CASE tools, application generators, UML tooling and model-driven development all promised, in different forms, to reduce the amount of implementation developers had to produce manually.

The comparison should not be exaggerated. Earlier code generators and modern language models are very different technologies.

But one older result is striking.

A 1998 Management Science field study examined 29 software enhancement projects across 23 applications in a large IBM COBOL environment. The researchers found that use of a code generator was associated with increased software complexity and increased effort on later enhancement projects.^⁷

It would be unreasonable to generalise one historical study into a prediction about modern AI-generated software.

The interesting part is the mechanism.

The generator reduced the effort required to produce implementation.

It did not automatically remove the cost of owning what had been produced.

Generated code is still code.

The Generator Does Not Pay the Lifecycle Cost

Every piece of software that reaches production acquires a future.

Someone will eventually need to understand it.

Dependencies will change. Security problems will appear. Product requirements will move. An API will disappear. A customer will use the system in an unexpected way. Production will behave differently from the test environment.

Some code will be deleted.

Some will survive for twenty years.

Historically, maintenance and enhancement have often consumed a major share—and in many estimates the majority—of the resources devoted to long-lived software systems.^⁸

The exact percentage is less interesting than what that work actually contained.

Maintenance was not simply repairing defective software.

Much of it was adaptation and enhancement: changing systems as users, requirements and environments changed. In that sense, a large part of what software engineering historically called maintenance was simply the continuing engineering life of successful software.^⁸

AI may make that work dramatically cheaper too.

Coding agents already work on existing repositories rather than only generating greenfield code. Benchmarks such as SWE-bench consist of real issues from existing projects and require models to locate, understand and coordinate changes across functions, classes and files.^⁹ Bug investigation, migration, test generation, refactoring and repository-wide transformation are increasingly part of ordinary AI-assisted development.

There is therefore no good reason to assume that implementation becomes cheap while every later lifecycle activity remains at its old cost.

We do not yet know how far the productivity shock will travel.

But software still has a lifecycle.

Whatever costs, risks and obligations remain are carried by the organisation that owns the system.

The model that generated the code does not operate the business that depends on it. It does not bear the consequence if an apparently sensible modification breaks an assumption made ten years earlier.

The organisation does.

That means the economic cost of generated software cannot be measured only at the moment of implementation.

Its cost includes whatever remains necessary to understand it, verify it, operate it, maintain it and change it safely.

This does not make generated code undesirable.

Nor does current evidence justify treating AI-assisted code as inherently less maintainable.^¹⁰

The point is simpler.

Software survives the act of generation.

Before Production, Code Can Become Inventory

There is one useful analogy with physical production.

Code waiting for review, verification or integration behaves somewhat like work-in-progress inventory.

Producing more of it does not create value if the next stage cannot process it.

Instead, queues grow.

Reviews become larger. Context becomes harder to reconstruct. Changes collide. Work waits longer before reaching production. Defects are discovered further from the point at which they were introduced.

DORA's suggestion that increased AI adoption could lead to larger batch sizes fits this pattern.^²

But the analogy changes once software enters production.

A piece of unsold inventory can eventually leave a warehouse.

Production software becomes part of the organisation's operating environment.

At that point it is less like inventory and more like an asset carrying an obligation.

It may provide enormous value.

It still has to be owned.

Throughput Can Rise While Costs Rise With It

Recent industry telemetry suggests this may already be happening.

Faros AI's 2026 report analyses two years of telemetry from 22,000 developers across more than 4,000 teams. It reports higher engineering throughput alongside larger pull requests, substantially more code churn, longer review times, more bugs and more production incidents.^¹¹

Faros is a commercial engineering analytics company and the analysis is observational. Those results should therefore be treated differently from randomized experiments.

But they illustrate an important possibility.

There is nothing contradictory about an organisation:

shipping more,

completing more work,

and accumulating more downstream cost

at the same time.

Equally, there is nothing contradictory about shipping more and creating substantially more value.

Throughput tells us how much passes through the system.

It does not tell us whether every additional unit was worth producing.

The Wrong Debate

This is why the important argument is not whether AI-generated code is good or bad.

That question is much too broad.

Nor is the answer to deliberately produce less code simply because code has become cheap.

Cheap implementation creates possibilities that were previously uneconomic. That should be welcomed.

The useful question is:

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

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.

A generated migration can add thousands of lines while being entirely justified.

Code volume cannot distinguish between these cases.

Increasingly, neither can the apparent effort required to produce them.

More Code Is Not More Software

Software is not valuable because someone succeeded in producing source code.

It is valuable because it does something useful and remains usable in the environment in which it has to live.

That requires more than implementation.

It has to fit the problem.

It has to fit the surrounding technical system.

It has to reach production.

Where organisational behaviour is involved, it has to become something people can actually use.

And whatever remains afterwards has to be understood, operated and changed well enough for the organisation to continue relying on it.

AI can dramatically reduce the cost of several of those activities.

Implementation is simply where the productivity shock became obvious first. There is little reason to assume it will stop there.

That is encouraging.

It also leaves the central distinction intact.

Producing more intermediate output is not the same thing as producing more value.

Closing

AI-assisted development is sometimes discussed as though software engineering has acquired a faster implementation engine and the rest is merely a question of learning how hard to press the accelerator.

The change is more interesting than that.

One of the expensive inputs into software production has undergone a substantial productivity shock.

The expected response is not simply that the same organisations produce the same software with fewer keystrokes.

They will reorganise around the new abundance. They will attempt things that previously made no economic sense. They will produce more. Constraints will move. Activities that are expensive today may become cheap tomorrow. Other complementary capabilities will become relatively more important.

The challenge is not to resist that abundance.

It is to build engineering systems capable of converting it into software that is useful enough to justify whatever responsibility remains.

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 at Microsoft, Accenture and an anonymous Fortune 100 company; 4,867 developers; pooled estimate of 26.08% more completed tasks.
Google DORA. Accelerate State of DevOps Report 2024. 2024. The report estimates a 1.5% decrease in delivery throughput and 7.2% decrease in delivery stability for a 25% increase in AI adoption, while reporting positive associations with individual productivity, flow and job satisfaction. It presents increased batch size as a possible explanation rather than an established causal mechanism.
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. These are observational survey relationships, not randomized causal estimates.
Joel Becker, Nate Rush, Elizabeth Barnes and David Rein. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” METR / arXiv, 2025. DOI: 10.48550/arXiv.2507.09089. See also Joel Becker, Nate Rush, Tom Cunningham, David Rein and Khalid Mahamud, “We Are Changing our Developer Productivity Experiment Design,” METR, 2026, for the later selection-effects problem.
Enrique Mu, Laurie J. Kirsch and Brian S. Butler. “The Assimilation of Enterprise Information System: An Interpretation Systems Perspective.” Information & Management 52(3), 2015, 359–370. DOI: 10.1016/j.im.2015.01.004. The study distinguishes successful technical deployment from the subsequent incorporation of enterprise systems into organisational practice.
Maya Daneva and Roel Wieringa. “Cost Estimation for Cross-organizational ERP Projects: Research Perspectives.” Software Quality Journal 16, 2008, 459–481. DOI: 10.1007/s11219-008-9045-8. The review treats implementation cost as including customisation, installation and organisational/process change; reported magnitudes vary, and some underlying estimates come from practitioner studies.
Rajiv D. Banker, Gordon B. Davis and Sandra A. Slaughter. “Software Development Practices, Software Complexity, and Software Maintenance Performance: A Field Study.” Management Science 44(4), 1998, 433–450. DOI: 10.1287/mnsc.44.4.433. The study reports associations, not a randomized causal effect.
Barry W. Boehm. “Software Engineering.” IEEE Transactions on Computers C-25(12), 1976, 1226–1241. DOI: 10.1109/TC.1976.1674590. B. P. Lientz, E. B. Swanson and G. E. Tompkins. “Characteristics of Application Software Maintenance.” Communications of the ACM 21(6), 1978, 466–471. DOI: 10.1145/359511.359522. Historical estimates varied considerably; these sources are cited for the lifecycle pattern and for the distinction between repair, adaptation and enhancement, not for a timeless fixed percentage.
Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press and Karthik R. Narasimhan. “SWE-bench: Can Language Models Resolve Real-world GitHub Issues?” The Twelfth International Conference on Learning Representations, 2024. The benchmark contains 2,294 problems derived from real GitHub issues and pull requests across 12 Python repositories; tasks can require coordinated changes across multiple functions, classes and files.
Markus Borg, Dave Hewett, Nadim Hagatulah, Noric Couderc, Emma Söderberg, Donald Graham, Uttam Kini et al. “Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability.” Empirical Software Engineering 31, article 161, 2026. DOI: 10.1007/s10664-026-10889-1. The preregistered controlled study found no significant downstream difference in completion time or code quality in the studied tasks; its Phase 2 sample was underpowered for small-to-moderate effects.
Faros AI. The AI Engineering Report 2026: The Acceleration Whiplash. 2026. Commercial observational telemetry covering two years, 22,000 developers and more than 4,000 teams. The report describes increased task and epic throughput alongside larger pull requests, increased churn, longer review times, more bugs and more incidents. It is not a randomized study.