AI is making coding faster. Why isn’t software shipping faster?

Cursor recently released an iPad version of its coding product. The application allows developers to launch agents, monitor their work, review pull requests, inspect checks and comments, and merge changes from the tablet. At first glance, it looks like precisely the kind of application that Cursor should have been able to vibe code in a weekend, but alas they did not otherwise this app would have been available months ago.

Or maybe they did?

We do not know how long the application itself took to implement, or why Cursor chose to release it when it did. But the question is still worth asking: if coding agents can now build functional applications in days, why do apparently straightforward products continue to take months or years to reach users?

The answer is not simply quality. Quality is part of it, and it introduces many gates: code review, automated testing, security checks, performance validation, usability testing, and release approvals. But even perfectly generated code would not eliminate most of the software delivery cycle. A feature still has to fit into an existing architecture, work with years of accumulated behavior, satisfy product and design requirements, coordinate with other teams, clear privacy or security constraints, survive deployment, scale, and prove itself under real production conditions.

Some delays have almost nothing to do with whether the code is correct. The product may not yet be well defined. The underlying infrastructure may not be ready. A new platform may create a permanent maintenance obligation that the company is not yet willing to take on. Another team may own a dependency. A release may need to wait for a broader migration, an operating-system capability, a policy decision, or simply a place on the roadmap. And even after all of that, certain questions can only be answered by putting software in front of real users and observing what happens.

This is why accelerating coding does not automatically accelerate shipping. Implementation is only one segment of a much larger cycle. AI is collapsing the time required to produce a plausible implementation, but the surrounding system—product definition, architecture, integration, validation, coordination, deployment, and production learning—has not compressed at the same rate.

AI has dramatically accelerated implementation. It has not accelerated the entire software delivery cycle at the same rate.

A brief history of waiting

We’ve seen this before, actually we’ve seen this since the dawn of software. Software development has always been constrained by feedback.

During the era of batch computing, programmers submitted programs on punched cards and waited for an operator to run them. The results might not return for hours or even days. A program could fail immediately because of a trivial syntax error, but the programmer would not know that until the job had moved through the queue and the printout came back.

Interactive computing changed this by allowing programmers to run code directly. Personal computers, IDEs, debuggers and incremental compilation shortened the loop further. Continuous integration automated builds and tests, while distributed build systems and cloud infrastructure made it possible to execute more validation in parallel.

Across each generation, the important improvement was not that programmers learned to type faster. It was that they learned whether their change worked sooner.

The innermost feedback loop has improved enormously. A mistake that once took a day to discover can now appear as a red underline in less than a second, an improvement of almost five orders of magnitude. The outer loop has not improved nearly as much. If a modern CI run takes fifteen minutes, the improvement from a full day is closer to two orders of magnitude.

That difference matters. An engineer can receive instant feedback about syntax while still waiting for the build, the test suite, a reviewer, an integration environment or a release window. Software development is composed of many nested feedback loops, and the fastest one does not determine the speed of the overall system.

Modern hardware has delivered vastly more computational capacity, but software has expanded to consume it. Applications became larger, dependencies multiplied and architectures became more distributed. We also used the additional compute to perform work that earlier generations did not: type checking, static analysis, security scanning, integration testing, container construction, policy evaluation, artifact signing and production verification.

All of this produces better and safer software (maybe?). It also means that faster computers have not translated directly into proportionally shorter delivery cycles. Much of the computational dividend was spent increasing the scope of software and the rigor with which we validate it.

AI accelerates one stage of the cycle

Most measurements of AI coding focus on implementation. Can an agent build a feature, repair a bug or navigate an unfamiliar repository? How much more code can an engineer produce? How many pull requests can a team complete?

These are useful measures, but they describe only the front of the delivery pipeline.

A developer who previously completed a handful of meaningful changes each week can now initiate many agent runs in parallel. Those agents can explore different approaches, modify multiple services, generate tests and open pull requests without waiting for the engineer to finish one task before beginning another.

Every one of those changes then enters the same downstream system. It still has to build, integrate with the existing product, pass the relevant tests, be reviewed, deployed and observed. If implementation throughput increases faster than the capacity of those stages, the organization does not necessarily ship faster. It creates larger queues.

More code waits for CI. More pull requests compete for attention. More changes create integration conflicts. More deployments need to be monitored, and more generated software becomes part of the long-term maintenance burden.

The implementation is becoming autonomous. The control surface is increasingly about validation and waiting…

More code will make the problem worse

Coding agents will continue to get faster and more capable. The likely result is not that organizations will produce the same amount of software in less time. They will attempt more work.

They will run more experiments, create more features, explore more architectural alternatives and generate more candidate changes. Code becomes cheaper, and therefore more code enters the delivery system. Unless the rest of that system changes, the downstream queues will grow alongside it.

This is the same pattern we saw with compute. Faster machines did not merely make existing software run faster. They enabled us to build much larger and more complicated systems. AI will not simply help us implement today’s roadmap sooner. It will expand the roadmap and add many more roadmaps!

That makes cycle time more important, not less. When implementation was expensive, the delivery system only had to absorb the output of human programmers. When implementation becomes abundant, every weakness in integration, validation and release becomes more visible.

I wrote previously that agents write at GPU speed while software still ships at human speed. The historical view sharpens the point. We have spent decades accelerating the inner loop of software development while the outer loop improved much more slowly. AI is now increasing the gap by making implementation dramatically faster without yet changing the system around it.

The next software bottleneck is not coding. It (still) is the time required to move from generated code to justified confidence that the code should be running in production.