Will Humans Become the Bottleneck?

The next constraint in project execution won't be the technology. It will be us.

Every process engineer knows how debottlenecking works. You find the constraint, you engineer it out, throughput rises — and the constraint moves somewhere else. It never disappears. There is always a next-slowest step, and the moment you remove one, you've appointed the next.

In my last article I argued that the biggest productivity opportunity in project execution isn't AI doing engineering — it's AI absorbing the repetitive, rule-based work that sits between the deliverables.

So let's assume we do exactly that, and it works. What breaks next?

The queue moves

Picture the Monday after your automation goes live.

You arrive at 7am. Overnight, the system has drafted fourteen technical notes, updated the registers, compiled the weekly report and prepared a transmittal batch. Work that used to take the team most of a week happened while everyone slept.

And all of it is now waiting for the same thing: you.

The AI executes at machine pace. The decisions still happen at human pace — one reviewer, one approval, one judgement call at a time. The work didn't disappear from the schedule. The waiting moved. It used to sit in front of execution; now it stacks up in front of review.

That's not a hypothetical failure of AI. That's AI working exactly as promised, inside a workflow designed for a world where execution was the slow part.

The ceiling has arithmetic

You don't need a study to see the ceiling — you can compute it on the back of an envelope.

Take a workflow where execution consumes, say, 70% of the elapsed time and review and approval the other 30%. Now make execution ten times faster and change nothing else. The 70 becomes 7. The 30 stays 30. Your cycle time drops from 100 to 37 — a 2.7× improvement, not 10×.

Push it to the limit: make execution instant. Free, perfect, zero time. You still can't do better than 3.3×, because the human step now is the workflow.

The proportions in your workflows will differ — run your own numbers. But the shape of the result won't change: once execution accelerates, the review-and-decision layer sets the ceiling, and no amount of additional AI spend can raise it. Only redesigning the human layer can.

Two wrong answers

The first wrong answer is the obvious one: take the human out of the loop.

No. AI still makes mistakes — confidently, fluently, and occasionally in ways that look exactly like correct work. In most industries a bad output costs an awkward email. In ours, an error that slips through review doesn't stay digital: it reaches procurement, fabrication, and site, where it converts into rework, standby and delay. And beyond the error rate sits something more fundamental: design responsibility. Accountability for engineering outcomes belongs to people, and no deployment architecture changes that.

The second wrong answer is quieter and far more common: keep the human in the loop exactly as before. Same line-by-line review, same approval chain, same "I check everything because I sign it" habit — just pointed at ten times the throughput. That's the ceiling from the arithmetic above. You've installed a faster pump into the same choked line, and the queue in front of the one reviewer grows until the schedule looks the way it always did.

Organisations that do this will conclude the technology didn't deliver. The technology delivered fine. The workflow around it never changed.

Didn't I just spend an article complaining about checking?

Fair challenge. Last time I argued that talented engineers burn out re-checking work that has already been checked somewhere else — and now I appear to be saying the human job of the future is oversight.

The resolution is that there are two kinds of checking, and we've been treating them as one.

The first kind is re-verification of rule-based output: did the number get transcribed correctly, does the register match the transmittal, is the revision code right. This is the checking that burns people out — and it's exactly the checking that should be engineered away. Rule-based steps executed deterministically, with a full audit trail, don't need a human re-doing them line by line. They need auditing, the way you audit any controlled process.

The second kind is judgement: is this design assumption sound, is this deviation acceptable, should this go to the client. That was never waste. That's the job. The whole point of automating the first kind is to buy back time for the second.

We already know how to do this

Here's the part I find genuinely encouraging: the playbook for supervising high-volume output without inspecting every piece of it already exists in our industry. We've run it for decades. We just haven't pointed it at our own workflows yet.

Criticality, not uniformity. We don't inspect every weld on a job to the same level — inspection effort follows criticality, through ITPs, hold points and witness points. AI output deserves the same logic: a hold point where judgement is genuinely required, surveillance-level review where it isn't. A calculation note that feeds a safety case and an internal meeting summary should not share a review process.

Review by exception. The system's job is not to hand you everything — it's to tell you what deviated: from the template, from the expected range, from the rule. Humans see the exceptions and the metrics; the conforming 90% flows through with an audit trail. Every experienced PM already manages this way. Their dashboards just haven't caught up.

Earned autonomy. We already adjust vendor surveillance based on track record — an NCR history buys you more inspection, a clean one buys you less. Treat the automation the same way. Track its error rate like you'd track a supplier's, publish it, and adjust the inspection level with evidence rather than vibes — in either direction.

Decisions in batches. An interrupt every eleven minutes for a single approval is the most expensive way to consume a senior engineer's attention. Aggregate the queue and decide in scheduled windows. The machine can wait. It's rather good at it.

None of this is exotic. It's QA/QC thinking, applied one level up — to the workflow itself instead of the weld.

Where the constraint should live

The goal was never to remove humans from the loop. It's to move the constraint to the one place it actually belongs — human judgement — and then give that judgement the best possible interface: exceptions instead of everything, metrics instead of raw output, hold points instead of hovering, audit trails instead of re-checks.

A plant doesn't get debottlenecked by accident. It gets debottlenecked by engineers who study where the flow chokes and redesign that section on purpose. Our workflows deserve the same discipline. Bolt AI onto an unchanged review process and you'll capture a fraction of what you paid for — and most likely blame the tool.

So the next time someone shows you an AI-powered workflow, don't ask how fast the AI is.

Ask where the queue forms.