When Implementation Stops Being the Bottleneck

Most large organizations are already past the point of asking whether developers should use AI.

They are experimenting with different tools and workflows, trying to establish common practices, and management is naturally asking what the organization actually gained from it.

Did development become faster?

Did quality improve?

Did costs go down?

Those are reasonable questions, but software productivity was difficult to measure even before AI. Frameworks such as Microsoft’s SPACE framework exist precisely because productivity cannot be reduced to lines of code, pull requests or a single delivery metric.

AI makes that discussion even noisier. Different studies report different effects depending on the developers, tasks and workflows being measured. For example, METR found experienced open-source developers taking longer on a particular set of tasks with early-2025 AI tools, while other studies and industry reports show substantial gains elsewhere.

So I am less interested in assigning one universal percentage to "AI productivity."

I am more interested in a simpler systems question:

A simplified traditional software delivery process looks like this:

Historically, implementation capacity was expensive.

In many organizations there were always more requested features, ideas and changes than technical teams could deliver. The backlog grew because the limiting resource was often the capacity to turn requirements into working software.

AI attacks exactly that stage.

Coding agents can already inspect repositories, modify several files, write tests, refactor code and iterate on feedback. The implementation step does not disappear, but its human cost can fall dramatically.

Accelerating one stage of a pipeline, however, does not accelerate the whole pipeline indefinitely.

Eventually another stage becomes limiting.

From what I see, two bottlenecks are becoming increasingly visible:

Before AI can implement anything useful, someone still has to know what should exist.

What is the actual business objective?

What behavior is expected?

What are the edge cases?

Which rules take precedence?

What happens to existing data?

What does "done" mean?

AI can help turn rough ideas into structured specifications. It can inspect an existing system, ask questions and identify contradictions.

But it cannot manufacture authoritative business intent when nobody has supplied it.

When implementation took weeks, the organization had time to clarify requirements while the technical team worked through the backlog.

When a new implementation can appear in hours, specification can become the slower activity.

You can generate version two immediately.

Then version three.

But if nobody knows precisely what version three is supposed to do, implementation speed has stopped being useful.

This is one reason spec-driven development is such a natural companion to AI coding agents. The better the implementation machinery becomes, the more valuable precise intent becomes.

The same problem appears on the other side.

Suppose AI produces the feature quickly.

It compiles.

The tests pass.

The application runs.

Are we done?

Only if those checks fully represent what the product was supposed to become.

Someone still has to answer:

That validation has at least two layers.

At the product level, we can treat the implementation as a black box:

Then there is technical validation:

AI can help with these checks too, but eventually every validation chain reaches the same question:

And that answer comes from domain intent.

DORA’s recent discussion of AI across the software lifecycle describes a closely related effect: time saved during initial code generation can reappear as auditing and verification work.

That is exactly what a bottleneck shift looks like.

The effect depends heavily on how roles are organized.

For highly technical products, the same person may already own almost the entire vertical.

A developer building developer tooling may identify the need, define the requirement, implement the change, use the result and decide whether it works.

There is little organizational distance between:

and:

AI fits naturally into that model because the person directing the AI already possesses the domain knowledge required at both ends of the loop.

Consumer software sometimes has another advantage: validation can be pushed toward real users through staged rollouts, telemetry, experimentation and A/B testing.

But large enterprise environments can be very different.

In banking, insurance, healthcare, government and other regulated domains, responsibilities are often deliberately separated:

The developer may not own the business rule.

The developer may not have authority to approve the result.

Requirements may need traceability and validation may require formal evidence or independent sign-off.

AI can accelerate the middle box enormously while leaving the two surrounding boxes mostly unchanged.

In those organizations the new bottleneck becomes especially visible.

If specification and validation become scarce capacities, an organization has only a few ways to respond.

It can add more people around those stages.

It can automate parts of them.

Or it can distribute the work across people who previously concentrated mainly on implementation.

That third option is the interesting one.

If AI reduces the amount of human effort required to translate a specification into code, developers have more reason to participate in creating the specification itself and validating the business result afterwards.

But doing that requires something traditional role separation often allowed technical people to avoid:

domain knowledge.

A developer working on a banking system becomes more valuable if the conversation moves beyond:

toward:

GitHub’s recent research on the changing identity of developers using AI points in the same direction. Advanced AI users described spending less effort on direct code production and more on defining intent, resolving ambiguity, directing agents and verifying outcomes. GitHub explicitly highlights product understanding alongside technical fundamentals as an increasingly important developer skill.

That makes sense.

For decades, organizations needed a large human translation layer:

If AI increasingly performs the last translation, the valuable human work naturally moves closer to the intent.

I do not mean that every developer will become a business analyst or that regulated organizations should remove independent business approval.

Some separations exist for good reasons.

The shift is subtler.

Technical roles will increasingly need enough domain knowledge to participate directly in:

Developers will not necessarily become the business owner.

But many will become much closer to business users with engineering capabilities.

At the same time, business specialists using AI will move in the opposite direction. A product manager who can generate and iterate on a working prototype moves closer to implementation.

So the boundary becomes thinner from both sides.

AI can make code abundant.

That does not make useful software abundant.

A useful product still requires someone to know what should be built and someone capable of recognizing whether what was built is actually right.

That is the real consequence of the bottleneck shift.

The future question is not only:

It is increasingly:

My expectation is not simply "fewer developers."

It is a change in what the role optimizes for.

Less time translating an already-defined requirement into code.

More time understanding the domain, shaping the requirement, directing implementation and validating the outcome.

In other words, as AI compresses the implementation layer, developers move closer to the business on both sides of it.