AI proved code was never the bottleneck

For as long as I have been in this industry, we have treated writing code as the hard part. Estimates, story points, sprint capacity, the whole ceremony of planning software is built on the assumption that the typing is what takes the time. Hire more engineers, ship more features. That was the deal.

Then agents turned up and quietly called our bluff.

I can now describe a change in a sentence and have a working, tested pull request a few minutes later. Multiply that across a team and the amount of code coming out the other end goes up sharply. Spotify recently talked about a 76% jump in pull requests after rolling agents out. That number is not the interesting part. The interesting part is what happened next in most places: nothing meaningful got faster to actually ship.

If code was the bottleneck, removing it should have made everything quick. It did not. It just moved the traffic jam somewhere we had been ignoring for years.

What actually changed when the code got cheap?

The thing we optimised was never the constraint for most teams. We got very good at generating the one artifact that was already the fastest to produce by hand, and we did nothing to the slow parts around it.

So the code piles up. Pull requests queue. Branches go stale waiting for an environment. The work is done, and it sits there, because everything downstream of the keyboard runs at the same speed it always did. AI did not create a new problem. It removed the cover story that was hiding the old one.

What is the change actually waiting on?

Think about the honest journey of a change from idea to production, and be specific about where the time goes. The obvious ones are the provisioning gates:

• A pull request that has to be approved by a platform team who did not write it, have no context on it, and are working through a backlog of their own.
• A ticket raised into a queue with a one-week SLO, which in practice means it gets looked at in a week and resolved in two.
• A database that takes days to provision because the request routes through three teams and a change advisory board.
• A firewall rule or a DNS record that needs a ticket, a review, and someone with the right access who happens to be on leave.

But provisioning is only one corridor of a much longer building. The same change also has to run a gauntlet that has nothing to do with the platform team at all:

• A change-management process, a CAB meeting on Thursday, a change record with the right boxes ticked and the right approvers attached.
• A security and compliance review, often the one nobody can start until someone works out who actually owns sign-off for this kind of change.
• The hunt itself: pinging around to find the one person who can approve the thing, who is in another timezone, or on leave, or three reorgs removed from the wiki page that still lists them.
• The production transition, the cutover, the deploy window, the sign-off that it is safe to actually turn it on.

None of that is code. All of it is coordination. A change does not wait on one gate, it runs a relay of manual human handoffs, and each one is somebody’s queue.

Why this will never scale

Here is the uncomfortable maths. Every step in that gauntlet is human-bound and most of them are serialised, one after another, each waiting on a person with context and authority who has their own backlog. That is not a process you measure in hours. It is one you measure in weeks, often months.

It was survivable when the build took weeks too, because the coordination hid inside the build time. Now the build takes an afternoon and the coordination is the whole story. You cannot hire your way out of it either, because you are adding people to a set of handoffs that gets slower, not faster, as you add people to it. Pour AI-driven code output on top and you have not fixed anything. You have just made the gauntlet the obvious, measurable thing standing between a team and production.

Why is the foundation underfunded?

Here is the part that worries me most. The budget is not going to the gauntlet.

The money is going to the next shiny AI tool. More seats, bigger models, another copilot, a new eval platform. All of it aimed at making the fast part faster, and almost none of it aimed at the foundation everything has to travel through once it is written. Investment in internal platforms was already a hard sell when the return was diffuse and long term. It is an even harder sell now that there is a demo-able tool with a logo competing for the same line in the budget.

So the gap widens. Code output climbs while the paved road underneath stays potholed, and the potholes are exactly where the months go.

Is platform work even being prioritised?

Step back from the budget and look at how the work gets chosen at all, because this is where I think the real rot is.

Platform work loses almost every prioritisation fight it enters. It competes against features a customer can see and a leader can demo, and it loses, because its return is a slope not a moment: nothing ships faster on the day you improve the paved road, it just quietly compounds. There is rarely a product manager whose job is to advocate for the platform, no roadmap slot with the platform’s name on it, no one carrying its business case into the room where the quarter gets decided.

So the foundation gets the scraps. It is maintained on the side, between the things that were actually prioritised, by people who believe in it enough to do it anyway.

Can platform teams even prioritise it themselves?

The harder question is whether the platform team has the leverage to fix that, and often the honest answer is no.

A lot of platform teams do not really own their roadmap. They are demand-driven, their backlog is other teams’ tickets, and every hour spent making the platform fundamentally better is an hour not spent clearing the queue that is already on fire. They are measured on keeping the lights on, so keeping the lights on is what they do. Nobody is asking the question that matters, which is not “can you service this request faster” but “can we stop this request needing you at all”.

That is the trap. The team best placed to see the bottleneck is the team with the least room to go and fix it, because they are too busy being the bottleneck.

The stakes: enabler or blocker

I have been on both sides of this, so I will say it plainly. When code was slow, a platform team that took a week was an annoyance you absorbed. When code is instant, that same week is the single biggest number on the board.

The developer sitting there with a finished, agent-written change and nowhere to deploy it does not see a careful steward of production. They see a gate. A shoulder tap. Another queue between them and done. That is how good platform teams accidentally become the villain, not by doing anything differently, but by standing still while everything around them sped up. The role was always meant to be an enabler, a force multiplier for every other team. Do nothing, and the exact same work now reads as gatekeeping.

What the way out actually looks like

I do not think the answer is to work the queue harder or to hire until the gauntlet is staffed. It is to take the human out of the path wherever the human is not adding judgement. Most approvals exist to catch a known, finite set of risks. Encode those as policy that runs automatically, build the guardrails into the paved road, and automate the provisioning and the checks so the safe path is also the fast path. The rare, genuinely risky exception still gets a human. The ordinary change stops needing one.

That is a shift from a platform you consume by asking a person, to a platform you consume by yourself, and it is a real journey with real stages rather than a switch you flip. I have written that part up separately: if you want the maturity model, from tickets all the way to a control plane, it is in Self-service is a journey, not a switch you flip.

Code was never the bottleneck

That is the real lesson in all of this. AI did not make our organisations fast. It made them honest. It took the one excuse we all leaned on, that the code was the hard part, and removed it, leaving the gauntlet we built around the code standing in the open with nowhere to hide.

The teams that win the next few years will not be the ones with the most agents. They will be the ones whose foundations let all that new code reach production without a ticket, a queue, or a shoulder tap. The constraint has moved. The only question is whether we move the investment with it, or keep polishing the part that was never slow to begin with.