The slowest point in the factory
Imagine a factory floor.
A belt runs through the building. Parts move from one station to the next. One machine cuts. Another bends. Another drills. At the end, someone checks the finished pieces before they are packed into boxes.
Some stations are loud and fast. One machine can produce a part every few seconds. Another is slower. Maybe it needs more care. Maybe a person has to inspect each piece by hand before it can move on.
At first, the fast machine looks like progress. More movement. More output. More noise.
But then the parts begin to pile up. The fast machine keeps going, but the next station cannot keep up. The belt fills. The floor gets crowded.
The factory did not become faster.
It created a queue.
A factory is not as fast as its fastest machine. It is as fast as its slowest point.
I think about this a lot with software teams.
We like to talk about speed. How fast can we build? How fast can we ship? How fast can engineers turn ideas into code?
But software work also moves through stations. An idea becomes a decision. A decision becomes a design. A design becomes code. Code becomes a review. A review becomes a release. A release becomes something a customer can actually use.
Each step is a station.
For a long time, engineering was treated as the obvious bottleneck. Backlogs were full. Product and design had more ideas than engineering could build. So the natural thought was simple: if engineers could code faster, the company would ship faster.
Sometimes that is true.
But not always.
Recently, one station got much faster: coding.
AI tools are genuinely useful now. They help with boring parts, unfamiliar code, tests, refactors, debugging, and that blank-page feeling before starting something messy.
I feel this in my daily work. Some tasks are faster now. Some risky changes feel less scary because it is easier to explore the code around them. I can ask questions before touching anything. I can map the shape of a messy area first, instead of poking around in the dark and hoping I understand it well enough.
But I do not always feel like the company is moving faster.
If the work is not clearly defined, faster coding waits. If the design is not ready, faster coding waits. If review is slow, faster coding creates more pull requests. If QA is slow, faster coding creates more things waiting to be tested.
The machine got faster. The factory may not have.
When one part gets faster, the bottleneck moves somewhere else. Sometimes it moves closer to decisions. Sometimes it moves closer to release. Sometimes it was never in engineering at all.
That is what makes the current AI conversation feel incomplete to me. The outside promise is simple: developers are faster now, so companies should ship more.
But maybe that was never the right equation.
Maybe AI does not make software companies faster by itself. Maybe it reveals where they were already slow.
There is another side to this too. When coding gets faster, the extra time does not always turn into more visible product work. Sometimes it turns into fixing old bugs, cleaning up code nobody wanted to touch, improving tests, removing friction, helping another engineer, or deleting something.
These things do not always show up in a roadmap update. But they matter.
Maybe some of the productivity gain is real, but quieter than expected.
Not more features. More room. Room to fix the factory.
So maybe the better question is not: how do we make coding faster?
Maybe it is: where is the slowest point now?
The answer will be different in every company. But until you find it, making one station faster may only create a bigger pile in front of the next one.
Making the fastest station faster can look like progress.
It can feel like progress too.
But if the slowest point does not move, the factory does not move.
It only gets better at waiting.