"Remove the bottleneck" has become one of those slogans that sounds self-evidently correct.

Find the person slowing the process down. Automate their work. Increase throughput.

With LLMs, this idea becomes even more seductive. A person performs a task, so you put an LLM API call in its place and move on.

The API is cheap. The API is fast. The person has become the bottleneck.

Except that this skips the hardest part.

What exactly was that person doing, and can the machine do it with the same or better quality?

That question is where real automation begins.

A person is rarely just doing the task

Consider something that looks relatively easy: writing advertising copy.

You might describe the human job as:

Write five advertisements for this product.

But the person doing it is probably doing much more.

They are deciding what information matters. They are judging the audience. They are selecting a tone. They are noticing when a claim sounds implausible. They are remembering which approaches worked previously. They are rejecting outputs that are technically correct but commercially weak.

Much of this knowledge is tacit.

It may exist only in habits, experience, pattern recognition, and thousands of tiny adjustments accumulated over years.

The written procedure therefore describes the visible task, not the full capability.

This is why "replace the person with an API call" is such a shallow model of automation.

You are not really replacing a person.

You are trying to reproduce a capability.

And reproducing a capability is an entirely different engineering problem.

Toyota understood this long before LLMs

The Toyota Production System provides a great example of what automation actually means.

Toyota describes one of its two central pillars as jidoka, often translated as "automation with a human touch." The idea is not merely to make a machine perform a human operation. The machine must also detect abnormalities, stop when something goes wrong, and prevent defective output from moving further through the process.

That distinction is profound.

Imagine a human worker producing ten good parts per hour and catching defects along the way.

Replacing that worker with a machine that produces twenty parts per hour sounds like impressive automation.

Now imagine that the machine produces defective parts and nobody notices until thousands of them have moved downstream.

You have increased the speed of production.

You have also destroyed the process.

For Toyota, that would defeat the point.

Toyota's own description of jidoka explicitly says that the purpose is to eliminate the need for people to watch machines while simultaneously preventing defective products from being produced and building quality into the process.

Removing the human is valuable. Removing the human while losing the quality is not.

That is the standard that makes automation difficult.

The machine comes after understanding the work

There is another part of Toyota's description that is especially relevant to today's AI automation.

Toyota says that, before automating work, you first need to be able to perform it smoothly and correctly by hand. You then improve the work, eliminate waste and inconsistency, determine what constitutes an abnormality, and only then build those capabilities into the machine.

In other words:

Understand the work → improve the work → understand failure → encode the capability → automate it.

That is almost the opposite of the modern instinct to start with:

Human → LLM API → done.

The API is frequently the easiest part.

The difficult part is figuring out what the human was actually doing well enough that you can reproduce it.

And then comes the painful part: iteration

Even after you understand the capability, you rarely get the automation right on the first attempt.

You build the first version.

It fails in ways you did not anticipate.

You discover that the human was making another judgement you had forgotten to model.

You change the instructions, add context, change the workflow, add a validation step, modify the evaluation criteria, or redesign the surrounding software.

Then you run it again.

It fails somewhere else.

So you fix that.

Then you discover that your fix improved one class of cases while damaging another.

So you change it again.

This process can involve an enormous number of iterations before the machine becomes genuinely reliable.

That is the part people underestimate most.

AI automation is often less about making the first API call and more about surviving the hundredth iteration.

You keep comparing the automated process against the human baseline.

You inspect failures.

You identify missing judgement.

You encode it.

You test again.

Eventually, the machine begins to approach the quality of the human process. Then you keep going until the machine is good enough that the human no longer needs to be involved in that part of the workflow.

That is automation.

Taiichi Ohno's career illustrates the timescale

Taiichi Ohno's work at Toyota also gives us some sense of how far removed this is from a one-shot automation project.

Ohno joined Toyoda Automatic Loom Works in 1932 and transferred to Toyota Motor Company in 1943. He began developing the ideas that became the Toyota Production System in the late 1940s, and continued developing, spreading, and teaching them through the 1950s, 1960s, and 1970s. He became Toyota's executive vice president in 1975 and retired in 1978.

So we are talking about decades.

Roughly three decades passed from the early development of TPS after World War II to its mature form in the 1970s. Ohno himself spent about four and a half decades inside the Toyota Group, from 1932 to 1978. Toyota's own history describes the early development of TPS as repeated trial and error, followed by decades of expansion and refinement.

When we look at a mature Toyota production line today, it is easy to see the automation and conclude that the difficult part was building the machine.

That gets the story backwards.

The difficult part was all the work that came before the machine could be trusted.

The experimentation.

The standardization.

The measurement.

The failure detection.

The process redesign.

The thousands of incremental improvements.

We see the automated factory.

We do not see the decades of engineering that made that automation possible.

Most "remove the bottleneck" thinking starts too late

The popular formulation starts at the wrong point.

It starts with:

This person is expensive or slow. How do I remove them?

The better question is:

What capability does this person provide, what makes their output good, and what would a machine need to reproduce that capability reliably?

Those are very different questions.

The first can lead to a five-line script and an API call.

The second can lead to months of experiments, evaluation infrastructure, edge-case handling, process redesign, and continuous refinement.

And there is an important economic consequence.

A five-minute API integration can look like spectacular automation in a demo.

A system that has gone through hundreds of iterations and quietly produces the same quality every day is far more meaningful automation.

The first replaces an activity.

The second replaces a capability.

The real meaning of "remove the bottleneck"

There is nothing wrong with removing people from processes.

That is precisely what automation is supposed to accomplish.

The mistake is treating the removal itself as the finish line.

A good automated process should absorb the useful judgement, handle the important failure modes, preserve the quality that mattered in the original process, and ideally improve the economics as a consequence.

Toyota's version of automation captures this beautifully: reduce human effort while building quality into the process itself.

That is a much higher bar than making a few API calls.

And perhaps this is the part of the "remove the bottleneck" slogan that gets lost most often:

The bottleneck is not removed when the human leaves.

It is removed when the system can perform the work without the human-and still produce the result.