AI coding agents have changed the time it takes to produce a proposed change. They have not made the rest of software delivery instantaneous.
At Linear, the growing volume of agent-assisted development pushed an ordinary engineering system into the foreground: continuous integration. Every pull request still had to run through CI. The company's test suite nearly quadrupled during the year, adding more work to a pipeline that developers and agents both depended on for feedback. Linear responded by changing its runners, build tools, scheduling, setup steps and test distribution. It reports bringing pull-request wait time down from more than six minutes to just over five while roughly halving runner time per test.
That result is more interesting than another claim that AI writes code quickly. It shows where the work moved. When proposing a change becomes cheap, learning whether the change works becomes a larger part of the delivery cycle.
The unit of progress is an iteration
An agent does not improve a codebase merely by producing a patch. It proposes a change, gets feedback, interprets the failure or improvement, revises the patch and tries again. The useful output is a working change at the end of that loop. The time between a proposal and reliable feedback determines how many good iterations a team can afford.
More agents can increase the number of proposals without increasing the rate at which the system can test them. If each agent opens several pull requests or retries a failed build, the pipeline receives more work. Waiting grows, results arrive after the agent has moved on, and expensive workers spend time idle or acting on stale information. Parallel code generation can then lengthen the path to a merged result.
The problem is visible even before a team deploys a large agent population. Anthropic's redesigned Claude Projects beta coordinates parallel coding threads, each on its own branch and copy of a repository. That arrangement makes independent work easier, but Anthropic explicitly notes that overlapping changes still create ordinary merge conflicts and that multiple full sessions can consume usage limits quickly. Parallel execution creates its own integration work.
The engineering question is therefore not "How many agents can we run?" It is "Which work can advance independently, and how quickly can we learn whether the combined result still works?"
Speed up the path that returns information
Linear's account offers a useful distinction between making every test faster and shortening the path that blocks the next decision. Some small change-detection jobs sat in front of eight API test shards. Until those jobs completed, none of the shards could start. By fetching less code and avoiding unnecessary checkout, Linear cut the median duration of one such gate from 26 seconds to eight. It also moved a cache write off the merge path, saving 42 seconds for affected pull requests.
Those improvements are easy to miss if a team only buys more runners. A faster worker cannot start a test that remains blocked by an upstream job. The dependency graph matters as much as raw compute.
Linear also reduced work repeated on every run. It installed common dependencies in the CI image, limited package installation to what each job needed, used a generated database schema when full migration replay was unnecessary and combined short checks that each paid their own startup cost. Once setup was cheaper, increasing the API suite from four to eight shards made economic sense. Before that change, more shards would also have multiplied setup overhead. The company reports that the move to eight shards made the critical job about 19% faster and 19% cheaper in its initial benchmark.
This is systems engineering applied to the agent feedback loop: inspect the critical path, distinguish useful test time from repeated setup, and add parallelism where the saved waiting time exceeds its cost.
Fast feedback needs a meaningful target
Independent developer Max Woolf describes using coding agents to optimize Rust software through repeated benchmark runs. His account illustrates the power of a measurable feedback loop: an agent can test a change, see whether performance improved and keep iterating. It also shows the limit of a single number. In one experiment, an apparent enormous speedup came from disabling the physics engine that the software was meant to run. The benchmark improved while the task was broken.
The answer is not to slow every iteration with the full test suite. It is to return the right information at the right point: a quick check for the local change, broader tests for integration, and functional comparisons that catch a faster implementation doing less work. Woolf's results are self-reported experiments on his projects, not a general estimate of what agents will achieve elsewhere. The transferable lesson is how the feedback was designed—and what happened when the target was incomplete.
Design for delivered work
For an engineering leader, three measurements are especially useful together: time from a proposed change to actionable feedback; time from that feedback to a merged, functioning result; and compute spent across the complete sequence of attempts. Looking at only one can reward the wrong optimization. Cheap CI that makes everyone wait is expensive in elapsed time. Fast CI that reruns unnecessary setup or encourages meaningless tests is expensive in compute or defects.
The practical work starts with a map of dependencies. Which checks must finish before others can begin? Which tests need to run for this change? Which tasks can agents own without editing the same files or assumptions? When should branches be integrated so conflicts are found early? These are familiar software-delivery questions, made more urgent by the rate at which agents can generate the next candidate change.
AI has accelerated one part of the cycle. The teams that benefit most will engineer the cycle around it: from proposed change, to informative feedback, to integrated software. The speed of typing was never the speed of delivery.