What Goldratt knew about the AI bottleneck

One of the most useful theories about AI and bottlenecks was written in 1984. It never mentions software once.

The paint factory and the Boy Scouts

An Israeli physicist named Eliyahu Goldratt published The Goal that year, a business book written as a novel. The plot follows Alex Rogo, a plant manager about to lose his factory to a corporate review. Rogo's old mentor walks him through a framework Goldratt had spent the previous decade building, originally as the scheduling logic inside a manufacturing software product called OPT.

He called it the Theory of Constraints. The premise is one sentence: every system has one bottleneck, and that bottleneck sets the pace for everything else. Speed up anything that isn't the bottleneck and you don't ship faster. You just stack more half-finished work in front of the part you didn't fix.

The book's most quoted scene isn't on the factory floor. It's on a Boy Scout hike. Rogo is leading a troop through the woods and notices the line stretching out behind him. The fastest scouts pull ahead. The slowest, a kid named Herbie, falls behind. The troop's real speed is Herbie's, not the leader's. Move Herbie to the front, redistribute his pack, and the troop tightens up. Leave him at the back and the gap grows all day.

Goldratt wraps the lesson in five focusing steps: find the constraint, get the most out of it, subordinate everything else to it, expand its capacity, then go find the next one. The book sold over five million copies and showed up on operations syllabi for the next forty years.

Forty years later, the bottleneck was writing code

For most of the time I've been an engineer, the slow kid in line has been the same one: writing the actual code. Specs got argued faster than they got built. Reviews were faster than the changes that triggered them. QA waited on shipped features. Deploys were fast unless something broke.

In Goldratt's framing, AI hit that step harder than anything we'd tried before. Generation is cheap now. The thing that used to take a week takes an afternoon, and at the bottom end of complexity it takes a chat session.

By the book, the next move is to look for the new constraint and elevate that one. Code review. Requirements. QA. Design. Pick one, work on it, repeat. That's the tidy version.

Where the analogy breaks

Reality isn't tidy. Goldratt's plants were physical. The slow step didn't move week to week. Herbie was Herbie for the whole hike.

The constraint in an AI-accelerated team doesn't move slowly. It darts.

One sprint it's code review. The next, the team is waiting on someone to write the requirements. The week after that, QA is drowning. The gains are real, but they don't land evenly. They depend on the role, the task, and which tool you're using. You can't pick the next bottleneck and stick with it if the constraint jumped while you were planning.

What this leaves you with

If you run a small business or a small team and you're trying to figure out where AI fits, the Goldratt lesson mostly holds. Pay attention to the bottleneck, not the parts that are already fast. But the playbook needs translation. The slow part this month probably won't be the slow part next month. Picking the next move once a quarter is going to leave you optimizing the wrong thing for ten weeks at a time.

I don't have the rest of this worked out. I think the lean and manufacturing world has a lot more to say about variable-rate bottlenecks than software has bothered to translate yet, and that's the corner I'll be researching over the next few months. More to come.

Sources

• Eliyahu Goldratt, The Goal: A Process of Ongoing Improvement (1984).
• Goldratt Institute — Theory of Constraints overview.
• Lean Enterprise Institute — writing on multi-constraint systems and policy constraints.