The problem with AI isn't AI—it's speed

AI speeds up individual tasks, but faster output doesn't mean value. Learn how to redesign your system to overcome organisational bottlenecks.

Key takeaways

Accelerating individual tasks creates bottlenecks elsewhere in the organisational system rather than increasing overall velocity.
Quality control and compliance processes risk becoming overwhelmed if adjacent workflows are not redesigned alongside AI adoption.
Organisations must determine how fast they should go rather than how fast they can go, as higher output volume does not guarantee greater value.
Rapid execution risks feature flood, which can confuse customers and erode trust if changes are not meaningful or digestible.

Everyone's asking how to get AI to do more. That's not actually the hard question anymore. The hard question is what happens to everything around it once it does. AI is very good at speeding up an individual or a single task in isolation. One person with the right tools and a bit of agentic setup can be many times more productive. That's not hype, but it's not the whole picture either. The question isn't how to do more—it's whether we've thought about what we're doing.

Your organisation isn't a collection of individuals doing isolated tasks. It's a system. Outcomes don't come from one person's output; they're the result of a chain of tasks and processes that hand off to each other. Speed up one link in that chain, and you haven't sped up the chain. You've just moved the constraint somewhere else.

The impact of acceleration on existing processes

Consider an engineering team working with pull requests. Normally, this quality control process works because everyone operates at roughly the same speed. Person A reviews requests from B and C, and so on, and there's a balanced workload. However, the moment one person is writing code—and generating pull requests—three times faster than everyone else, that balance breaks. The other two aren't working three times faster at reviewing, so they spend most of their time just reading and commenting on one person's output. Take it to its logical extreme—everyone on the team speeds up equally—and the whole team ends up spending its time peer-reviewing machine-assisted work.

The peer-review step is there for a reason. A team that's owned the same codebase for a year knows it; they can read a change and understand instantly whether it fits, because they've got the context and skin in the game. If it goes wrong, who's getting woken up at 1am? That kind of accumulated context and accountability is exactly what doesn't travel with an individual working at AI speed on their own.

Is the answer 'more people, reviewing faster' then? Not necessarily. There's a real and reasonable case that machines can already do much of that review more consistently than people—they don't get tired or have a bad Friday afternoon. But swapping the bottleneck from human review to machine review doesn't answer what this process is for, and does it still make sense now that one part of it moves three, five, or ten times faster than it used to?

It's not just engineering

You don't need a codebase for this pattern to show up. Take content writing and publishing, for example. Consider three or four people involved in producing a piece of content–someone writing, someone checking it against brand and messaging, and maybe someone with legal or compliance sign-off. If one of those people can now produce three times as much, the others don't magically have three times the capacity and will feel the stress.

Which raises a question I don't think many teams or organisations have considered: how fast do you want to go? Not how fast could you go, but how fast should you go? Publishing twice as much content, twice as fast, sounds like a win, but more content doesn't automatically mean more value. It might be, but what's the purpose of creating and publishing content? Is it served by publishing more?

The ripple effect of accelerating

This is why I think about using AI from a systems perspective rather than task-based. Speed up one part of it and the effect doesn't stop there; it ripples outward. It's worth mapping where it lands:

The immediate team

The people directly adjacent to the accelerated task. Perhaps many engineers are now doing nothing but reviewing other people's code, or some writers are just checking articles for compliance.

The next part of the chain

The part of the organisation that receives the output of the sped-up process may become a bottleneck. Can they ship X times more? If not, what do they prioritise?

Customers and partners

Who didn't necessarily ask for this much change this quickly, and don't always have the capacity to keep up even if it's technically an improvement.

Governance and compliance

In many organisations, this is a risk management system, not just a queue. If you're in a regulated industry or anywhere the cost of a wrong output is high, that bottleneck is often doing what it should. The fix is unlikely to be 'remove the friction'. You need to understand which friction is protecting you and which friction is just a habit.

Every one of these is a different part of the same system. Some may be able to speed up, too, but what are the costs and benefits of doing so?

Faster isn't the question

As with every innovation or technology shift before it, there are opportunities to increase efficiency with AI. However, we should be looking at the system of work, not just tasks. We need to ask questions like:

What's the impact if this specific task or process goes faster? On the people next to it, the people after it, the customer, on our compliance status and processes?
What's the risk (or impact) if its output is wrong? How much does that risk scale with increased speed?
Does accelerating this task change, or even remove, the need for something else downstream? Or are you assuming the rest of the system just keeps working the way it does today?

If deploying AI across your system has high potential gains and genuinely low risks, you should move fast. Systems where the downside is real – legal exposure, safety, customer trust, for example – need a different answer. It could be ‘go slower' and it certainly involves monitoring the veracity of outputs, as well as looking for bottlenecks and areas where productivity begins to slow.

When doing is easier than thinking about doing

There's a deeper version of this problem underneath the surface. AI hasn't just made execution faster–it's made doing dramatically easier than thinking about whether you should be doing it. In my experience, when doing is easy, doing is what happens, whether anyone's decided it's the right call.

The most obvious manifestation is likely to be ‘feature flood'. Just because you can ship far more features than before, it doesn't mean you should. Admittedly, more features created efficiently look like pure upside. But there is likely to be a cost, not for you, but your customer. They're still the same person, absorbing the same amount of change they always could, and now they're looking at a flood of new capabilities they didn't ask for and don't necessarily understand.

Does ‘more features, more often' build trust, or erode it? Does it empower customers, or does it confuse them? I don't think it's clear yet, but I don't think many teams are even asking the question. They're measuring output, not outcome. Shipped isn't the same as useful. Fast isn't the same as wanted. And a customer who can't tell what's changed, or why, doesn't experience your velocity as value, but noise.

Perhaps that's the real shift AI should be forcing. It's not really a technology problem, but a judgement problem. The organisations that will struggle aren't the ones that can't use AI—they're the ones that let individuals and tasks accelerate without ever stopping to redesign the system or to ask who must absorb the changes downstream.

Curious about other rapid AI changes?

Find out what the future of junior developers looks like in a vibe coding era.

Read this blog