You're slower with AI. You just feel faster.

Watching AI agents work feels like productivity. Tabs multiplying, drafts appearing, the machine humming while you handle something else. Then the clock checks in. In METR's 2025 study, experienced developers using AI coding tools were measured 19% slower, while believing they were 20% faster. METR now calls that early-tooling history, but the mechanism hasn't changed. Feeling fast is not being fast.

What it means I call it the review bottleneck. The agent makes an error. You review harder. You start checking everything. The agent runs at machine speed and you review at human speed, so your freedom to delegate drains to zero. You end up slower than doing the work yourself, with an AI subscription on top. Three forces drive it.

1. Identity: checking feels like diligence, and diligence feels like the job.
2. Loss aversion: a miss stings about twice as much as a win feels good, so you over-insure.
3. The illusion of control: watching every step feels safer than designing the system, even though the system is what scales and the watching doesn't. Every force in the bottleneck feels like diligence and measures like delay.

For civil engineers these lands differently than for software teams. Our review isn't a pull request, it's a stamp. At every stage, the engineer stays in responsible charge. That part is non-negotiable. But there is a difference between reviewing the system and reviewing every keystroke. The bottleneck is doing the second and calling it the first. A submittal reviewer who rechecks every line the AI drafted is in the bottleneck. A reviewer who checks the checklist the drafter worked against, then spot-checks the high-consequence items, is running a system. What I'm doing I run a lot of agent sessions in parallel, for example, for my content operation: research agents, draft agents, a Monday selection run. The first week, I checked everything. By Friday I was the bottleneck in a system I had built to remove bottlenecks. What fixed it: I stopped reviewing output and started reviewing the brief. Every agent gets a written brief before it runs (outcome, constraints, what good looks like) and a fixed-shape report when it finishes (what it did, how it verified, what's open). I review the brief once and the report once. The middle runs without me.

What it looks like on a real job

Take a submittal log on a live project, about 40 open items. The brief never changes: the current register, due dates checked against the schedule, and a clear definition of what counts as a flag.

The agent reads every row, ranks what is late, and drafts the follow-up emails. You do not read 40 rows. You read the report.

Say the report carries two flags that matter. Structural steel shop drawings, 12 days overdue, with fabrication "not started". That is a schedule problem, not a paperwork problem. And a substitution request buried inside a product data package, the kind that gets approved by accident when someone skims. Those two items get your morning. The other 38 get filed.

That is the system on real work: your judgment at the brief and at the report, machine speed in the middle.

That is the whole fix. Design the review before the work starts, then let the system run. I test it with a vacation: if my AI work piles up while I'm gone for a week, I have a tool. If the system runs and flags only the true exceptions, I have a system. I'm building toward the second one. The rule I run now: trust the clock, not the feeling. Where is your review bottleneck? Hit reply and tell me the one review step you can't let go of. Recommended reading: The Human-Agent Orchestrator (Bornet, Wirtz et al., 2026). I am optimizing my workflow based on that book and the ideas in it. If you want to dive deeper into these concepts and learn how to run a team of agents efficiently, start there.

Joseph Dib, PE, PMP
Infrastructure Catalyst