Your AI tools are speeding up the wrong things

What a 1984 manufacturing novel can teach you about AI adoption

My LinkedIn feed is full of it. Screenshots of AI-generated PRs. “Shipped 47 features this sprint.” A developer bragging they wrote 10,000 lines of code in an afternoon with Claude.

Lots of output numbers. Lots of celebration.

Nobody’s posting their cycle time. Nobody’s showing their deployment frequency or change failure rate. Nobody’s mentioning that half those AI-generated features are sitting in a review queue, or that production incidents quietly ticked up last quarter.

Output went up. Outcomes didn’t move.

This is what happens when you hand a powerful tool to someone who hasn’t asked the most basic question in operations: where is my bottleneck?

A 40-year-old idea that just became urgent

Eliyahu Goldratt published The Goal in 1984. The core insight is almost embarrassingly simple: every system has a constraint - one point that limits the throughput of the entire system. Improve anything that isn’t the constraint, and you’ve improved nothing. You’ve just built up inventory in front of the bottleneck.

Goldratt laid out five focusing steps:

1. identify the constraint,

2. exploit it (squeeze every drop of capacity from it),

3. subordinate everything else to it (don’t let non-bottlenecks overproduce),

4. elevate it (invest to expand it),

5. and then go find the next one.

For 40 years, this has been one of those ideas that everyone nods at and almost nobody actually applies. And now AI has made it urgent, because AI is the most powerful non-bottleneck accelerator ever invented, and most engineering teams are using it to build the most impressive pile-ups their constraints have ever seen.

The trap: automating what’s easy to automate

Here’s the pattern I keep seeing.

• A team gets access to AI coding tools.

• They look around and ask: “What can AI help us with?”

• The answer is obvious: writing code. It’s the most visible, most measurable part of the job. AI is pretty decent at it.

• So they point AI at code generation and watch the output numbers go vertical.

But writing code was almost never the bottleneck.

Or at least- not the only one, not for every org and not in every circumstance.

The bottleneck was understanding what to build. Or getting changes reviewed. Or having confidence that the thing is safe to ship. Or making the hard product decision that nobody wants to make. Those things are exactly as slow as they were before.

So now you have more code, sitting in longer review queues, being assessed by the same overloaded senior engineers, going through the same deployment pipeline that was already the chokepoint. You haven’t gotten faster. You’ve gotten busier. There’s a difference.

Plot twist - senior devs do it too

The code flood

Let’s be specific. If your team generates 3x more pull requests but has the same number of reviewers, you haven’t tripled your throughput. You’ve tripled the wait time in your review queue. Every one of those PRs represents context a reviewer has to load into their head, and AI-generated code often requires more careful review, not less, because the reviewer can’t rely on the author’s intent being obvious.

If your constraint was deployment confidence — the team’s collective ability to say “yes, this is safe to ship” — then more code without a proportionally better testing and observability harness is actively harmful. You’re feeding the machine faster than it can digest.

The documentation flood

Then there’s the PRD problem. Teams are using AI to produce product requirement documents, technical specs, architectural proposals. The volume of documentation goes up. The quality of decision-making stays flat.

Here’s why: the PRD was never really about the document. It was about the thinking you had to do to write it. When you sit with a problem long enough to articulate it clearly in writing, you discover the gaps in your understanding. You find the contradictions. You realize the thing you were about to build doesn’t actually solve the problem you thought it did.

When you generate a PRD with AI, you get a document that looks like thinking happened. It has the right headings. It uses the right vocabulary. But the thinking didn’t happen. The person who prompted it still doesn’t understand the problem, they just have a convincing artifact that says they do.

And you know what? Everyone else in the org can tell.

AI-generated documents have a particular smoothness to them, a distinct absence of struggle, that experienced people recognize immediately. It reads like a book report by someone who read the synopsis.

The bottleneck was never “produce more documents.” It was “make better decisions.” And you can’t automate your way to that.

The Slack flood

Same pattern, different medium. AI can summarize threads, generate status updates, draft messages, produce weekly roundups. So now there’s more communication. More updates. More words.

The bottleneck was never communication volume. It was attention. Your senior engineers already couldn’t keep up with their Slack notifications. Now there’s more to read, and paradoxically it’s harder to find the signal because the AI-generated messages are just coherent enough to seem worth reading, but just hollow enough to waste your time. The ratio of signal to noise probably just got worse.

The outsourced humanity

This one is my pet peeve, so let me be direct: if you’re using AI to write performance reviews, you have fundamentally misunderstood what performance reviews are for.

The point of writing someone’s review is the thinking. You sit with it. You struggle with how to phrase something difficult. You agonize over whether you’re being fair. You notice patterns you hadn’t articulated before. That struggle is you actually engaging with your teammate as a person: their growth, their potential, the hard thing they need to hear and the way you’re going to say it that shows you actually care.

When you hand that to AI, you didn’t save time on the review. You skipped the review. You produced a document that looks like a review. The person receiving it can tell the difference. They always can. And what they hear, loud and clear, is: “I couldn’t be bothered to actually think about you.”

The same applies to 360 feedback, to mentoring conversations, to anything where the slow, difficult process of articulating your thoughts is where the actual value is created.

These are not bottlenecks to be eliminated. They’re the work itself.

The distinction that matters: thinking work vs. toil

Here’s the framework I want to leave you with, because I think it’s the single most important filter for any AI adoption decision.

There are two kinds of slow work.

Toil is slow because it’s repetitive, mechanical, and draining. It has to happen, but nobody gets smarter or wiser by doing it.

• Formatting spreadsheets.

• Writing boilerplate tests for well-understood code.

• Parsing logs manually.

• Compiling release notes.

• Translating documentation.

Toil should be automated ruthlessly and without sentimentality.

Thinking work is slow because the slowness is the mechanism.

• Writing a strategy document forces you to clarify your strategy.

• Reviewing a teammate’s code forces you to understand their approach.

• Drafting a difficult message forces you to examine what you actually want to say.

The effort is the process by which understanding is produced. Remove the effort, and you remove the understanding.

AI pointed at toil is liberation. AI pointed at thinking work is lobotomy with a nice interface.

Most teams don’t make this distinction. They see “slow” and reach for AI, treating all slowness as waste. Goldratt would wince. Not all constraints should be eliminated. Some constraints are there because the work genuinely requires that time and attention. The question isn’t “can AI make this faster?” It’s “if I make this faster, do I still get the thing I actually needed?”

Now the good news: AI at the actual constraint

So, now that I’ve spent a lot of this article being critical, let me be clear — AI is extraordinarily powerful when you point it at the right problem. The key is to start with Goldratt’s first step: identify your actual constraint. Then ask whether AI can help you exploit it.

Here’s where I’ve seen it work.

When the bottleneck is understanding a legacy system

Almost every company of meaningful size has codebases that are poorly documented, written by people who left, and structured in ways that make sense only if you were there in 2013 when the original decisions were made.

The constraint is: nobody understands this well enough to change it safely.

AI is genuinely excellent here. Summarizing complex call graphs. Explaining unfamiliar code patterns. Mapping dependencies across services. Answering “what happens if I change this?” with actual context.

This is applying AI directly at the constraint by reducing the thing that was actually slowing you down.

When the bottleneck is incident response

It’s 3am. Something is broken. Your senior on-call engineer is staring at dashboards and logs, trying to piece together a causal chain from fragments of evidence scattered across twelve services, seven of which they are seeing for the first time. Every minute costs money and customer trust.

AI as a diagnostic accelerator, correlating signals, suggesting hypotheses, surfacing relevant past incidents, directly exploits the constraint. The bottleneck is a human trying to synthesize too much information under pressure. AI is made for that.

When the bottleneck is onboarding

New engineers taking months to become productive in a complex codebase is one of the most expensive constraints in engineering. The knowledge is tribal, the documentation is outdated, and the people who could explain things are the same senior engineers who are already the constraint elsewhere.

AI as a codebase guide, answering questions about architecture, explaining historical decisions, walking someone through unfamiliar patterns, directly attacks this constraint. It scales the knowledge without scaling the demand on the people who hold it.

When the bottleneck is your scarcest people

In most teams, the real constraint is the 2-3 senior engineers whose judgment and context make them the decision point for everything important.

They’re in every design review. They’re the ones who know which shortcuts are safe and which aren’t. They’re simultaneously the most valuable and most overloaded people on the team.

AI can’t replace their judgment as that’s thinking work, and we’ve covered why you don’t automate that. But AI can handle the mechanical parts of their day:

• triaging what actually needs their attention,

• pre-analyzing pull requests so they spend time on what matters,

• drafting the routine parts of technical documents so they can focus on the hard decisions.

The goal is to make sure the constraint spends 100% of its capacity on the work only it can do.

This is Goldratt’s “exploit” step, applied precisely. Don’t try to eliminate the bottleneck. Squeeze every drop of value from it by removing everything that isn’t bottleneck-level work from its plate.

The question to ask before adopting any AI tool

Before you add another AI tool to your workflow, before you generate another metric about how much output AI produced, ask this:

What is my actual bottleneck?

If you don’t know (and most teams don’t, because they’ve never looked) then you’re not ready for AI. You’ll just move faster in the wrong direction. You’ll generate impressive numbers that don’t connect to outcomes. You’ll build beautiful pile-ups in front of constraints you haven’t identified.

If you do know your bottleneck, then the next question is: does this AI tool address the bottleneck, or does it accelerate a non-bottleneck? If it’s the latter, it doesn’t matter how impressive the demo is. It doesn’t matter how much output it produces.

It won’t make your system faster.

Goldratt figured this out in 1984 with a manufacturing novel. Forty years later, we have the most powerful acceleration technology in human history, and the lesson hasn’t changed: faster only matters if you’re speeding up the right thing.

The teams that will actually benefit from AI aren’t the ones generating the most code or the most documents or the most messages. They’re the ones who took the time to understand where their system actually gets stuck and pointed AI there.

Everyone else? They’re just producing inventory.