Speed is not direction
A true story about speeding up the wrong things
The video of my WeAreDevelopers talk "A True Story About Speeding Up the Wrong Things" runs for about 40 minutes and turned out to contain more than one article. So I split the argument into 3 parts. This first one is about the oldest mistake in the story: Confusing acceleration with progress.
Estimated reading time: 8 min
The original 40-minute talk is available on WeAreDevelopers.
Can we make this faster?
There is this one question
the technology industry has been asking with remarkable consistency for decades.
Most of the time, that is a perfectly reasonable question. Faster builds are better than slower builds, deployments that take minutes instead of hours are usually an improvement, and removing repetitive manual work is hardly something I am going to complain about. I have spent most of my professional life using technology precisely because it allows us to do things faster, more reliably, or with less unnecessary effort.
The trouble starts one step later, when a measurable increase in speed quietly becomes evidence that the system itself has improved.
Speed is attractive because it is easy to observe. A build takes twelve minutes instead of twenty, a release cycle shrinks from two weeks to two days, a team closes more tickets, a platform handles more traffic. These are real numbers, and they make excellent charts. Direction is less cooperative. It is much harder to measure whether the thing we are now producing faster should exist in the first place, whether it improves the larger system around it, or whether we have merely removed the friction that used to slow down a bad decision.
That distinction matters because local optimization is not the same thing as system improvement. A team can become genuinely faster while creating more work somewhere else. An automated process can remove one manual step and introduce dependencies nobody will remember six months later. An integration can solve a perfectly real problem and still leave the overall architecture harder to understand than before. None of these improvements has to be fake. They can all work exactly as intended and still move the larger system in the wrong direction.
Movement is easy to measure; direction is where the trouble starts.
We have seen this movie before
None of this began with artificial intelligence
AI merely makes the old pattern easier to see because it removes friction on a scale we have not had before.
The dot-com years provide the obvious example. The internet itself was not the failure, nor was the idea that reach and distribution would transform entire industries. Both were correct. The mistake was turning growth into a substitute for understanding the underlying system. Traffic became value, attention became proof, and the ability to scale quickly was treated as if it answered the much less comfortable question of what exactly was being scaled.
For a while, it worked. Money could buy attention, attention could produce another growth chart, and the chart could justify more money. The machinery was very good at accelerating the part everyone had decided to measure. The problem appeared when value eventually asked for a receipt.
Finance later produced a more complicated version of the same structural mistake. More abstraction, more leverage and more distance between the people creating risk and the people eventually absorbing it did not make the risk disappear; it made the system harder to read. If a problem travels through enough layers, there is a point at which it starts to look less like an unresolved problem and more like an implementation detail.
Software architects should find that uncomfortably familiar. We abstract, wrap, integrate and automate because doing so can reduce duplication and make complicated things manageable. But every abstraction also creates distance, and distance can hide the point where nobody understands the complete system anymore. Good engineering can reduce complexity. Bad engineering can hide it. From the outside, those two can look remarkably similar for quite a while.
The 2010 Flash Crash was a much more compressed demonstration. Automated trading systems reacted to market conditions and to one another at machine speed, liquidity collapsed, and the sequence had to be reconstructed afterward. The machines reacted; the humans explained it later.
That is not an argument against automation. Machines are supposed to react faster than people; otherwise there would be little point in automating many of these systems in the first place. The interesting distinction is not between machine speed and human speed, but between reaction and correction.
A system can react extremely quickly without having a correspondingly strong ability to recognize that its own reactions are making the situation worse. It can execute its current logic perfectly while being poor at detecting that the logic has become part of the problem. At that point, making the system faster does not increase control. It merely shortens the time between the original mistake and its consequences.
Ashby's Law
Only variety can absorb variety
Long before automated trading, cloud infrastructure or AI agents, the cyberneticist W. Ross Ashby was interested in the more general question behind all of this: What does a system need to remain in control when the environment around it becomes more complex?
A thermostat provides the pleasantly boring version of the answer. Its world is small. It measures temperature, compares the result with a target and turns the heat on or off. For that narrow task, a simple controller has enough possible responses to deal with the relevant states of its environment.
Now make the environment more complicated. Add more variables, possible states, dependencies and more interactions between them. At some point, the controller no longer has enough ways to distinguish what is happening or respond appropriately. Making it faster does not solve that problem. A thermostat capable of switching the heat on and off a thousand times per second is still just a thermostat.
Ashby's law of requisite variety gives us a useful way to think about this. A regulator needs enough variety in its possible responses to deal with the variety of disturbances it is expected to control. The mathematics behind that is more precise than we need here; the practical consequence is simple enough. If you increase the range of conditions a system can create or encounter, you also need sufficient ability to distinguish and respond to those conditions.
This is where technology companies repeatedly get themselves into trouble. We increase the number of possible states in a system and celebrate because the machinery processing those states has become faster. We add integrations, automation, services, dependencies and new paths through the architecture, then improve throughput and call the result progress.
But throughput and control are not the same capability. A faster system can execute an existing response more quickly. It does not automatically gain a better response, a better model of the situation, or a better way to detect that its assumptions are wrong.
The environment gets more complex, the controller does not.
The wrong thing
The problem was never speed
This is why so many technology waves eventually develop the same smell. Something becomes easier, so we do more of it. Shipping becomes easier, so we ship more. Integration becomes easier, so we connect more things. Automation becomes easier, so we automate more processes. None of this is irrational; most of it begins with real improvements and real benefits.
The trouble starts when the complexity produced by those improvements grows faster than the system's ability to understand and correct itself in the process.
A pipeline can become faster while decisions entering it remain poor. Infrastructure can become more scalable while the architecture gets increasingly difficult to reason about. Automation can remove manual work while creating a network of relationships for which nobody has a complete mental model anymore. The machinery improves, but there is no law saying that steering has to improve with it.
This sounds obvious when stated that way, yet much of the technology industry still behaves as if acceleration were evidence of maturity. A system that can execute a bad decision in one instead of ten minutes has not become ten times better. It has become ten times faster at executing a bad decision.
The problem becomes particularly difficult to see when the local optimizations are all genuine. Each team can demonstrate that its part works better than before, each individual change can be justified, each dashboard can be green. Yet the overall system can still become harder to change, harder to explain and harder to control because every improvement has increased the number of interactions somebody else has to understand.
That is the point where speed stops being merely a benefit and starts amplifying whatever the system gets wrong.
And then came AI
but it did not create this pattern
It arrived in an industry that had already spent decades learning how to accelerate individual parts of increasingly complicated systems while neglecting the ability to steer them.
What AI changes is the amount of friction left in areas that used to slow us down simply because human effort was expensive. We can generate text, code, analysis and plans much faster than before. Tasks that once required hours can sometimes be compressed into minutes, and work that was too expensive to automate at all has suddenly become a reasonable candidate.
The usefulness is real, which is precisely why treating this as just another productivity improvement would be a mistake. We are no longer only making execution faster. We are beginning to accelerate parts of cognition and coordination themselves.
That makes the old question more important, not less. If a system can act faster, can it also recognize when its actions are wrong? If it can produce dramatically more output, has its ability to judge that output increased at the same rate? If we remove the friction that previously limited how many changes could be attempted, what else was relying on that friction to keep the system understandable?
Those questions do not make AI a bad idea. Weak tools rarely create this class of problem because nobody gives them enough responsibility to matter; powerful tools do. The danger begins when increased capability is mistaken for increased control. That is why the interesting question was never whether we could make things faster. Of course we can. We have become extremely good at it. The harder question is whether the systems around that speed can still tell where they are going.
Speed is not direction. More speed does not solve the wrong system. It only makes the consequences arrive earlier.
AI makes that old mistake more interesting because it changes what is expensive. Code, text and other artifacts can now be produced at a speed that would have been absurd only a few years ago. Understanding them has not become equally cheap.
That is where the second part starts: The Bottleneck Moved.
Making a system faster does not automatically make it better. Speed is easy to measure, while direction, judgment and control are much harder to quantify. Over the last few decades, technology has repeatedly increased scale, automation and throughput faster than the surrounding systems could understand or correct what was happening. Ashby’s law of requisite variety gives that problem a useful frame: as a system becomes more complex, its ability to distinguish and respond to that complexity has to grow with it. AI does not create this pattern, but it accelerates it by removing friction from areas that used to depend heavily on human effort. The real question is no longer whether we can make things faster, but whether the systems around that speed can still tell when they are heading in the wrong direction.
© Copyright 2026 Cybercraft GmbH