Your engineers got twice as fast. Your lead time only moved 4%

Estimated reading time: 7 minutes

Key takeaways:

• Doubling coding speed won’t double delivery speed.
• Adoption metrics can fund the wrong fix so report lead time and where the work waited, alongside adoption rate and PRs merged.
• Find where your work waits by tracking wait time, active work, and rework time, and log a specific reason for every wait.

---

“My engineers are reported to have become twice as fast. The business is not sensing those gains in any meaningful way.” Most engineering leaders can perhaps relate to this statement. Let’s examine the gap between individual productivity and its journey towards business value.

Going back to the start of this year, one of the key metrics we were tracking was AI adoption. I was very excited with my close to perfect adoption numbers. I mentioned this to a fellow engineering leader. He asked me a question: “how have the business outcomes changed?” Unsurprisingly, the question was met by a stunned silence from me.

The question also led me to investigate this gap. I started with tracking the end-to-end flow of work for a new initiative. I compared the lead time of an initiative where most of the coding was AI-assisted with the lead time of a similar piece of work which was done without AI assistance.

The results surprised us. Without AI assistance, coding took up only about 10% of total lead time. So even large gains in coding speed from AI cut lead time by just 4%.

The claim here is not 4%. That is one comparison for one initiative in one organization. This number will likely be different, possibly very different for your organization. What it showed me is that a local speed-up doesn’t necessarily produce anything like an equivalent end-to-end improvement. The following industry studies also land on close numbers:

• A 2025 Microsoft research study surveyed 484 Microsoft developers about how they spend their week. Coding took up about 11% of a typical week, while developers said their ideal week would put it at 20%.

• Atlassian’s State of Developer Experience Report 2025 surveyed 3,500 developers across six countries and found they spend 16% of their time coding.
• Software.com’s Code Time Report tracked IDE activity from more than 250,000 developers in 201 countries. The median developer spent 52 minutes a day writing code.

Your engineers are faster with AI, and the business has seen almost no difference. Before you spend more on AI-coding tools, you need to know why, which adoption metrics are misleading you, and where your own constraints sit.

Why faster coding alone doesn’t mean faster delivery

This one example alone doesn’t explain why the lead time hardly moved. There are two different explanations to reconcile this:

1. The first one is that the coding time never held a big share in the overall end-to-end lead time. With nothing else changing, even a significant improvement in coding time barely moves the total lead time. Just like in the example earlier where the coding time was 10%, accelerating coding speed by close to 2x brings down the lead time by just 4%. The coding did get faster, it just never held a big part in the lead time.
2. The second one is where the coding genuinely held a big share in the lead time. The gains made in coding time were partly offset by the migrating constraint in the other parts of the system like code review or release. The overall gains might still come close to the same 4%.

Theory of constraints

Eliyahu Goldratt’s theory of constraints offers a useful perspective here. According to the theory, the throughput of a system is limited by its constraint: the step with the least capacity. Speeding up a step that isn’t the constraint doesn’t increase throughput. The time saved isn’t worthless. It can shorten one change’s journey or free people for other work, but it doesn’t materially improve how much the organization delivers.

The risk is always attached to the constraint. If the other parts of the system like code or security reviews are already running at capacity, speeding up upstream only increases pressure on downstream. It results in either the reduced quality checks or increase in backlog and hence longer wait time unless the new constraint receives additional capacity.

AI certainly speeds up teams, especially when coding is the constraint (until that constraint moves elsewhere). This can look very different for a startup where a decision from a founder could keep the team waiting for days. For an enterprise, it could be managing communication and alignment through a complicated org structure.

If coding is not a constraint for you, look where in the system your constraint has migrated. It could be anywhere downstream in reviews or upstream in the prioritization before a single line of code is written. 

How adoption metrics can keep funding the wrong fix

In my case, a peer asked the question. The way AI investments are measured can easily result in the question never coming up.

In my book, AI is the Easy Part, I classify software delivery across the following dimensions: creation, decision, coordination, governance, and learning. Coding assistants directly help only with creation. The most common failure point I have encountered is in learning – how does an organization learn from what it measures?

If AI success is measured using adoption metrics like adoption rate, PRs merged, or suggestion acceptance then the success definition is biased in favor of creation metrics. AI can improve all these metrics without a significant improvement in delivery velocity. The biggest risk with using these metrics is that you are funding improving part of the system that is not your biggest constraint while ignoring the actual one. 

The fix is simple. Use lead time with the break up of where the work actually waited next to the adoption numbers. Any decision using just the latter and without the former is incomplete at best and wrong at worst.

How to find where your work waits

Start with comparing similar pieces of work from before and after AI adoption. Focus on not just the shipped items but also the ones in transit. The aging and incomplete tickets generally have the longest wait time across different parts of the workflow.

The important metrics to measure are wait time, active work time, and rework time. Against every wait, record the reason for the wait as well. “Waited on X team for Y days because of Z reason” is a much more useful reason for analysis than “dependency on X”. The reliability metrics like number of rollbacks and incidents are equally important. You don’t want to buy speed at the cost of quality.

Here are some places to check where your work waits:

Code review

Your backlog will keep growing if the number of PRs keep exceeding your reviewer capacity. Here are some signals to monitor about your AI-assisted changes:

• AI-assisted changes are unusually large.
• Need more explanation from their authors.
• Take more review rounds.
• Need more fixes after merging.

Any of these increases the work per review.

Decisions

A team might finish a feature design and continue to wait for a decision from the architect forum, which has its own backlog.

Dependencies

A feature may need a change to another team’s API. That request joins the other team’s backlog and waits getting prioritized against that team’s priorities.

Governance

If an approval gate runs on a fixed schedule with fixed capacity, more changes arriving means a longer queue.

Once you find the queue, the next step is to understand it. For the biggest one, ask what changed. 

• Did more work arrive? 
• Did processing slow down? 
• Did work keep coming back for correction? 

If you see a pattern where the same team keeps appearing in your “reason it stopped” column, investigate the reason. This team might be short on capacity, working with unclear requirements, high degree of rework, or waiting on someone to decide. 

Once you determine the root cause, test one change aimed at it. Compare lead time, rework, and post-release stability before and after.

Measure delivery, not just adoption

The conclusion I drew from my own experience is that AI brings not just technological disruption but also a change in operating model for software delivery.

The organizational design determines whether faster coding multiplies into faster delivery or hits a ceiling. Before buying more AI tooling, find out where your work waits.

Customers don’t experience how fast engineers write code. They experience lead time, and lead time belongs to the organization, not the individual.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.