"Why hasn't the delivery date changed even though we're using AI?" The question comes from clients and from inside development teams alike. Implementation really has gotten faster, which makes it a hard question to answer.
One possible answer is that the bottleneck has moved. As writing code gets faster, changes pile up at the step that validates them, and the time spent waiting in line grows. On September 21, 2026, the project management tool Linear also published an engineering post about cutting the time PRs wait to clear validation, along with running costs, by rethinking CI as a single system, from the infrastructure it runs on to how jobs are scheduled and tests are parallelized.
The bottleneck moves from writing code to validation
When AI speeds up writing, more changes come out in the same amount of time. Tests are added to check the generated code, so each validation run also takes longer. Meanwhile, if the system that runs validation stays as it was, changes end up waiting in line at the entrance to validation.
In this setup, making implementation even faster won't shorten delivery. What needs shortening is either the waiting time or the validation run time. Which one matters differs from team to team, and the proportions are not the same everywhere. That is why you measure your own breakdown first.
Measure your own waiting time
Before borrowing other companies' numbers, you need to look at your own breakdown. There are three things to measure.
| What to measure | How to read it |
|---|---|
| Time to finish a change | From starting work to submitting it for validation |
| Waiting time before validation starts | The length of the queue, determined by how many runs can go at once |
| Validation run time itself | Total of tests, builds and type checks |
The three tiers in the diagram map directly onto your options. If the top is long, validation is not the cause; if the middle is long, it is a question of concurrency; if the bottom is long, it is a question of trimming individual tests. Keep a week of records and first determine which tier is the longest.
You don't have to keep these records by hand. In GitHub Actions, for example, you can pull the start and completion times of each job from the REST API. Waiting time is captured as the difference between when a change was submitted for validation and when validation started.
If you just say "CI is slow" without breaking it down, the usual result is raising parallelism and only increasing cost. Shortening the run time itself is covered in shortening build times.
Cost is traded against waiting time
Running more jobs at once reduces waiting time, but the cost of the execution environment rises by the same measure. If you use a usage-based service, the increase shows up as a bill at the end of the month.
This is an area that easily gets vague in maintenance contracts. Parallelism was raised to speed up development, and operating costs went up as a result. If it is not settled who bears that increase, disputes become more likely later. We set out what to treat as ongoing payments in how to show usage-based CI/CD costs in a maintenance contract.
From the client side, you can read this the other way. Against the expectation that "if AI makes it faster, it should be cheaper," ask where the time saved is being absorbed, and you will see whether that partner measures their own process. A partner who does not measure will likely struggle to explain why things got faster or why they are slow.
Adding tests lengthens the wait
What is easy to overlook is that the decision to add tests feeds directly into waiting time.
Strengthening validation of generated code is a sound direction. But whatever you add applies to every single change. Even tests that take a few seconds each add up to real run time once there are thousands of them, and that lengthens the queue.
A realistic compromise is to stop running everything every time. Run what is relevant to the changed area first, and run the time-consuming full validation less often. In teams that have not made this split, things get reversed: the more tests you add, the slower development gets.
What to check first in estimates
Both those commissioning development and those taking it on have things to confirm before work starts. How many minutes does it take for one change to clear validation? Is that value actually being recorded? And has that value grown compared with three months ago?
If you have answers to these three, the discussion about delivery dates becomes concrete. If not, start by taking a week of actual measurements. To talk about speed, you first need to pin down where things are slow.
On September 24, 2026, we checked the summary of the article listed on Linear's official site and the relevant GitHub Docs page through web search results. Because we could not open the body of Linear's article, we do not cite specific figures published by the company. No measurement or reproduction was carried out in our own environment. This article organizes what to measure and what to base decisions on.
For help making the time spent in your development process visible or restructuring your validation, please consult GleamHub.
