For most of software engineering's history, writing the code was expensive.

A feature could spend days or weeks moving from an idea to an implementation. Engineers had to understand an unfamiliar codebase, remember APIs, search documentation, write boilerplate, debug syntax, construct tests, and gradually turn an incomplete mental model into working software.

That assumption shaped the engineering systems we built around developers. We optimized editors. We created reusable libraries. We standardized frameworks. We built internal platforms and code generators. We treated developer coding time as scarce because, for a long time, it was.

AI-assisted development is changing that constraint remarkably quickly.

An engineer can now ask a coding agent to inspect a repository, implement a change across several files, generate tests, repair failures, and prepare a pull request. The result is not always correct, and it certainly does not eliminate engineering judgment. But it changes the economics of producing a plausible software change.

And when one part of a system becomes dramatically faster, something predictable happens.

The bottleneck moves.

Software Organizations Do Not Deliver Code

This distinction matters more than it sounds.

A developer can produce code in minutes. The organization still has to understand it, review it, test it, secure it, integrate it, deploy it, observe it, support it, and eventually maintain it.

The actual product of an engineering organization is not source code. It is safe, useful change in a running system.

Once we look at the problem that way, faster code generation is only an improvement to one stage of a much larger value stream.

DORA's 2025 research offers an important signal. Its State of AI-assisted Software Development report found that AI adoption had become widespread and was associated with higher software delivery throughput, but also with increased delivery instability. DORA's broader conclusion is more useful than any single metric: AI behaves as an amplifier. Strong engineering systems can turn faster creation into better outcomes; weak systems can simply experience their existing problems at higher speed.

That is exactly what we should expect from systems thinking.

If a team doubles the rate at which changes enter a delivery process while code review capacity, test environments, security checks, release controls, and operational readiness remain unchanged, the organization has not doubled delivery capacity. It has increased pressure on everything downstream.

The Factory Line Analogy Is Suddenly Useful Again

Imagine a manufacturing line where one machine produces parts twice as fast as before.

If the inspection station immediately after it can process only the original volume, completed products do not leave the factory twice as fast. Parts accumulate in front of inspection. Work in progress increases. People rush. Defects become easier to miss. Eventually someone proposes adding more storage for the growing pile of unfinished parts.

That would be an absurd way to measure manufacturing productivity, yet software organizations can make the same mistake when they celebrate lines of code generated, AI acceptance rates, or developer time saved without examining what happens to the resulting change.

We may be making the first machine faster while leaving the rest of the factory untouched.

Review Becomes More Expensive When Creation Becomes Cheap

One of the first bottlenecks I expect many teams to feel is code review.

Generating a 700-line change with an agent can take surprisingly little time. Understanding a 700-line change still takes a human reviewer real attention.

There is an asymmetry here: the cost of producing code is falling faster than the cost of establishing confidence in it.

That changes the responsibility of the author. In an AI-assisted environment, producing more code is not necessarily helpful. Producing a smaller change that another engineer can understand quickly may be far more valuable.

This is why small batches become more important, not less important, as AI improves. DORA has repeatedly identified working in small batches as a foundation of high-performing software delivery, and its current AI capabilities guidance explicitly includes small-batch work among the practices that help organizations translate AI adoption into better outcomes.

A good coding agent should therefore not merely optimize for "complete the task." It should optimize for produce the smallest coherent, reviewable change that safely advances the task.

That is a very different objective function.

Testing Moves From a Developer Convenience to a Capacity Constraint

As change volume grows, testing infrastructure also becomes part of the bottleneck.

Consider a large enterprise where every pull request triggers unit tests, integration suites, security scanning, dependency analysis, container builds, environment deployment, and perhaps end-to-end tests. Those pipelines were often designed around a world where humans generated changes at human speed.

What happens when agents can open substantially more changes?

CI queues grow. Test environments become contested. Flaky tests consume more engineering time because they are encountered more frequently. Slow pipelines that were merely annoying become genuine throughput constraints.

This makes an old engineering investment newly strategic: fast, deterministic feedback.

A ten-minute test suite may have seemed acceptable when an engineer ran it a few times per day. In an agent-rich development environment, that same ten-minute feedback loop can become infrastructure debt.

The organizations that benefit most from AI-assisted engineering may not be the ones with the best model licenses. They may be the ones with the cleanest repositories, fastest tests, reliable environments, clear service ownership, strong observability, and APIs that machines can safely consume.

Architecture Becomes the Constraint on Parallelism

There is another bottleneck that is less visible than CI: architecture itself.

AI makes it easier to parallelize implementation. Several agents can work on several tasks simultaneously. But parallel implementation works well only when the system has boundaries that allow work to proceed independently.

A tightly coupled application with unclear ownership, shared databases, fragile integration points, and hidden dependencies does not suddenly become easy to change because agents can type faster.

In fact, faster change may expose the coupling more aggressively.

This is one reason architecture quality may become more valuable in an AI-assisted world. Good boundaries create concurrency. Clear contracts let teams — and eventually agents — change one part of a system without having to understand or coordinate with everything else.

Modularity has always reduced cognitive load. Now it may also determine how much machine-generated engineering work an organization can safely absorb in parallel.

The Scarce Resource Is Moving Toward Judgment

If code becomes abundant, what becomes scarce?

I think the answer is increasingly judgment.

Which problem is worth solving? Is this change consistent with the architecture? Is the abstraction necessary? Does the new dependency create more long-term cost than the feature is worth? Is the test proving the right behavior? Does this need to be a service at all? What failure mode have we overlooked? Should we delete code instead of adding it?

These were always important questions. They become more important when implementation friction no longer naturally slows us down.

Friction has an interesting property: some of it is waste, but some of it accidentally creates reflection time.

When implementing an idea takes three days, people occasionally discover during those three days that the idea is wrong. If an agent can implement it in twenty minutes, the organization needs another mechanism for ensuring that speed does not outrun judgment.

This does not mean adding bureaucracy around AI-generated code. It means being deliberate about where high-quality decisions happen.

Engineering Leadership Has to Measure the Whole System

This is where I think engineering leaders need to be careful with AI productivity programs.

It is tempting to ask:

  • How many developers are using the tool?
  • How much code is AI-generated?
  • How many hours did developers save?
  • How many pull requests are being opened?

Those numbers can tell us something about adoption. They tell us much less about whether the engineering system improved.

I would rather know:

  • Did lead time from idea to production improve?
  • Are pull requests getting smaller or larger?
  • Is review wait time increasing?
  • How much work is being sent back for rework?
  • Are CI queues and test duration becoming constraints?
  • Did change failure or rollback behavior change?
  • Are incidents becoming harder to diagnose?
  • Did product outcomes improve?

DORA's 2026 update to its software delivery measurement reflects the same systems view by adding deployment rework rate to its delivery performance metrics. That is a useful reminder: shipping more changes is not automatically progress if the organization must spend more capacity correcting them afterward.

The Developer Platform Becomes a Flow Platform

This also changes how I think about internal developer platforms.

The first generation of platform engineering concentrated heavily on developer self-service: create a service, request infrastructure, obtain credentials, deploy an application, view logs.

Those capabilities remain useful. But when code generation accelerates, the platform's larger job becomes maintaining flow across the entire delivery system.

Can it provide fast ephemeral environments? Can policy checks happen automatically and early? Can agents discover approved libraries and architecture standards? Can a developer see why a change is waiting? Can the platform identify the dependency or approval creating the delay? Can routine low-risk changes move without unnecessary human coordination while consequential changes receive the right scrutiny?

The platform is no longer just reducing the friction of starting work. It is managing the organization's ability to absorb change safely.

That is a much more interesting platform problem.

Do Not Automate the Bottleneck Blindly

Once review becomes slow, the obvious response will be AI review. When testing becomes slow, we will use AI to generate and select tests. When security analysis becomes a queue, AI will help triage findings.

Some of that will be valuable. But there is a danger in responding to every new bottleneck by simply adding another agent.

The purpose of a constraint is sometimes to tell us something about the design of the system.

If every change requires review from six teams, perhaps the answer is not six AI reviewers. Perhaps ownership is unclear. If integration testing takes two hours because every service depends on a shared environment, perhaps the architecture needs better isolation. If security approval is repeatedly required for the same class of safe change, perhaps policy should be encoded and automated rather than repeatedly interpreted.

Automation is most powerful after we understand why the work exists.

The Next Productivity Conversation Should Be About Flow

I am optimistic about AI-assisted software development. I use these tools, and the improvement in how quickly an engineer can explore a codebase, test an idea, or get through repetitive implementation work is difficult to ignore.

But faster coding is not the destination.

As the cost of producing code falls, the competitive advantage shifts toward organizations that can make good decisions, maintain architectural clarity, establish confidence quickly, and move change through production without creating downstream chaos.

The question for engineering leaders is therefore not simply:

How much faster can our developers write software?

It is:

How much more useful, safe change can our entire engineering system absorb?

Those sound like similar questions. They are not.

And as coding becomes faster, the difference between them will define which organizations actually become more productive.

Further Reading

DORA. State of AI-assisted Software Development 2025. Google Cloud / DORA.

DORA. DORA AI Capabilities Model. Google Cloud / DORA.

DORA. Quick Check updates, April 22, 2026. Introduces deployment rework rate as a software delivery performance metric.