Why AI Isn't Making Your Team Faster

As software companies race to adopt AI coding tools like Claude Code, Codex, and Cursor, one thing is becoming clear: once an organisation reaches basic literacy, writing code stops being the bottleneck. The organisation becomes the bottleneck.

I've seen AI-enabled engineers build features in days that might have taken months a year ago. But that speedup doesn't matter if shipping the feature still takes months.

The winners will be the organisations that adapt to this new reality fastest.

The irony is that most of the friction slowing down AI-enabled teams today was added intentionally. Historically, writing software was expensive, and building the wrong thing carried a huge opportunity cost. So companies added process and guardrails to increase confidence before building.

That's how detailed specs, estimates, and step-by-step planning became common. When a feature could take months to build, organisations wanted high confidence before starting.

Design processes evolved for the same reason. Once something was built, redesigning it could take months and be hard to prioritise. So companies added rounds of reviews and sign-offs to get the design right before building.

This is also why planning processes feel heavy in established orgs. Companies invested heavily in roadmaps, capacity planning, and elaborate goal-setting processes.

All of these practices optimised for a world where implementation was slow, risky, and expensive. AI is changing that assumption.

For a long time, software development looked roughly like this:

Implementation Latency > Decision Latency

You could decide what to build relatively quickly. The slow part was building it.

AI-enabled teams are starting to reverse that relationship. We're entering a world where:

Decision Latency > Implementation Latency

Teams can prototype, build, and modify systems much faster than before. But in many organisations, decisions still move through the same pipeline of meetings, approvals, planning cycles, and alignment discussions.

So the constraint shifts. The bottleneck is no longer engineering throughput, but decision-making speed, organisational flexibility, and coordination overhead.

But many companies are still optimising the wrong problem. There's a lot of focus on making engineers faster. But faster code doesn't matter if decisions still take months.

The teams I've seen moving dramatically faster share a few characteristics.

First, they are small. Usually two or three engineers, sometimes with a designer who can also use AI coding tools. Coordination costs rise non-linearly with each additional teammate.

Second, they are highly product-minded. They talk to users. They understand the problem and the business goals. They aren't afraid to make good-enough design decisions instead of waiting for perfect alignment.

Most importantly, they own outcomes end-to-end.

Historically, product managers navigated ambiguity and owned failures. Engineers implemented the solution. But these teams operate differently. They have the autonomy to make decisions, but they also carry accountability for the results. They aren't handed detailed roadmaps or long specs. Instead, they get a direction or a problem to solve. Then they build, test with users, learn, and iterate.

I've seen teams like this accomplish more in weeks than a traditional six- to eight-person team achieves in months. Not because the individuals are more talented, but because the system they operate in allows them to move faster.

In many traditional product orgs, development looks something like this:

Idea -> Align -> Plan -> Build -> Hope you got it right

Each step adds coordination overhead. Each step increases the time between learning.

But the teams moving fastest today operate differently. Their loop looks more like this:

Idea -> Build -> Test -> Learn

AI accelerates the build step dramatically, but that acceleration only matters if the rest of the loop can keep up.

If alignment meetings, approvals, and planning cycles still dominate the timeline, AI only speeds up one part of the system. Iteration speed barely changes.

Most successful software companies started out this way: ultra-lean startups with small teams, high ownership, and fast decisions.

But as companies scale, they gradually build guardrails to reduce risk and increase predictability.

Those guardrails slowly move the organisation further away from the conditions that made the company successful in the first place. AI is now exposing that gap.

The companies that benefit most from AI won't be the ones with the best AI tooling. They'll be the ones that remove organisational overhead and minimise decision latency - empowering small teams to move quickly without waiting for permission from the rest of the organisation.

The biggest mistake companies will make is treating AI as a tooling problem. In reality, it's an organisational problem.

AI is shrinking implementation latency. But in many organisations, decision latency and organisational overhead are still what hold teams back.