In this post, I will talk about where engineering productivity actually gets stuck. Similar posts can be found here.

AI Made Coding Faster. That was never the Bottleneck.

Over the last year, I spent a fair amount of time thinking about how to measure AI adoption in engineering. Initially, the question seemed fairly obvious. Are engineers using AI? Then Are engineers who use AI shipping faster?

Both are reasonable questions but not the most useful ones. Because when coding gets faster everything else becomes more visible. An engineer can go from an idea to working code quickly now. Something that might have taken a couple of days can sometimes be prototyped in an afternoon.

Then it needs an environment. Then someone needs to make a decision. Then it needs to integrate with another system. Then security gets involved. Then deployment. Then somebody needs to figure out whether what we shipped actually produced the outcome we expected.

Suddenly the 40 minutes AI saved while writing the code doesn’t look like the interesting part of the story.

I started looking at the whole loop

One of the things I worked on was a fairly simple way of looking at engineering delivery. Not developer productivity. Not number of PRs. Not AI usage. The journey of work itself. I roughly separated it into three parts:

1. Phase 1: Time from when an idea (project or any meaningful work) originates to being committed to be worked upon.
2. Phase 2: Time from the beginning of the committed work to getting it done. (Dev cycle time)
3. Phase 3: Time from done to something actually running, deployed, validated and delivering value.

Most of the current AI tooling is concentrated around Phase 2. And AI absolutely helps there. But when I started looking across actual work, something else became obvious. A lot of the waiting wasn’t happening there. It was happening during Phase 1 and Phase 3.

Prioritisation. Decisions. Infrastructure. Security. Deployment. Validation.

In one case, completely different teams ran into essentially the same Phase 3 constraint from different directions. That was much more interesting to me than another chart showing increased AI adoption.

We might be optimising the easiest part to measure

There is a reason engineering organisations like measuring coding activity. It is visible. Commits exist. Pull requests exist. Cycle time exists. AI tools can tell you how many suggestions were accepted.

The rest of software delivery is messier.

• How long did an idea sit around before somebody decided it was important?
• How much time disappeared because ownership wasn’t obvious?
• How long did someone wait for an environment?
• How many conversations were needed before an architectural decision was made?
• How long between “done” and customers actually receiving value?

Those things are harder to put on a dashboard. They are also often where the time goes. All these questions are important if we want to talk about AI productivity.

If an engineer produces code twice as fast but the organisation around that engineer hasn’t changed, what exactly became twice as fast? Probably the engineer but not necessarily the business.

AI amplifies the system it lands in

Put AI into a good engineering system and it can create enormous leverage. Put it into a system with unclear ownership, slow decisions, fragile deployment paths and lots of manual coordination, and you may just create work faster than the organisation can absorb it.

This isn’t an argument against AI coding tools. It is almost the opposite. They are getting good enough that some of our old constraints are becoming impossible to ignore. When creating software was expensive, coding occupied a large part of the conversation. As the cost of creating software falls, the surrounding system matters more.

• Can we test an idea cheaply?
• Can we deploy it easily?
• Can teams make decisions without everything travelling up the organisation?
• Can we observe what happens after release?
• Can an experiment die without turning into a political event?
• Can something move from idea to customer without requiring five people who happen to know how the machinery works?

The useful metric

Measuring AI adoption is useful. The question should not be about Are we using AI more? But instead, Is value reaching customers faster?

If it isn’t, where is the constraint? Rarely, the answer will be coding. And that may be one of the more interesting consequences of AI for engineering leaders.

AI isn’t only making software development faster. It is showing us where our organisations are slow.