Why Faster AI Drafting Doesn't Ship Faster Work?
Faster AI drafting fails to ship faster work because overall throughput is governed by the downstream human review bottleneck rather than production speed. Dr. Jonah Tebaa applies Theory of Constraints thinking to show that tripling drafting capacity without expanding fixed review capacity merely creates a backlog, increasing shipped output by only ten percent. To convert drafting gains into finished output, organizations must restructure pipelines by tiering reviews by risk, batching review windows, and tracking shipped output rather than drafts produced.
When a sales or delivery team bolts an AI drafting tool onto its workflow, the instinct is to expect output to climb in rough proportion to how much faster drafts get produced. Dr. Jonah Tebaa's argument, developed in his recent writing on AI-augmented production, is that this instinct is almost always wrong — and that the gap between drafting speed and shipped output is not a glitch to be tuned away but a structural signal pointing at exactly where the real constraint sits.
A Familiar Mistake, Freshly Exposed
Tebaa's central observation is not really about AI. It is about what happens when one stage of a two-stage process gets faster while the other does not. Drafting and reviewing are different kinds of work — one is production, the other is judgment — and judgment work rarely compresses just because the material arriving in front of it arrived faster. A proposal that took twenty minutes to draft instead of two hours still needs the same forty minutes of a senior reviewer's attention to check whether the pricing holds up, the scope matches what was promised, and the technical claims are defensible.
What makes this miscalculation so persistent, in Tebaa's account, is that it is invisible until it is tested. Before any AI assistance, drafting and review capacity in a typical team sit close enough together that neither function feels like a constraint. Nobody budgets extra review time because nobody has needed to. The system looks balanced because it has never been pushed hard enough to reveal which side would give first. AI drafting tools do exactly that kind of pushing — and because they push on the visible, easily measured side of the process, teams tend to celebrate the wrong number.
The Composite Case Tebaa Uses to Make It Concrete
To illustrate the mechanism, Tebaa reaches for a composite scenario — an invented but representative construct, not an account of an actual client engagement — built around a mid-market sales-engineering function. Five solutions engineers draft technical proposals; one principal architect holds sole sign-off before any proposal reaches a client. Before AI assistance, the team drafts roughly ten proposals a week and the architect reviews about nine, a near-even balance that never registers as a bottleneck.
Once the team adopts AI-assisted drafting, weekly drafting capacity roughly triples to thirty. Review capacity, tied to a fixed number of hours and a fixed amount of judgment per item, stays at nine. In Tebaa's telling, the backlog does not creep — it accumulates fast, passing sixty unreviewed proposals within three weeks, with sales staff working around the process by chasing the architect directly and fragmenting the very calendar the review step depends on. Net shipped output moves from roughly ten a week to about eleven: a ten percent gain riding on top of a three-hundred percent increase in drafting speed. Framed that way, the return on the AI investment looks disappointing. Framed correctly — as a constraint-location problem rather than a tool-performance problem — it looks like exactly what should have been predicted.
The Older Idea Doing the Work
Tebaa's argument is, in effect, an applied case of Theory of Constraints thinking: a system's total throughput is governed by whichever single step has the least capacity, and adding capacity anywhere else produces little more than a longer queue in front of the real constraint. That principle is decades old in manufacturing and operations circles, but it is rarely applied deliberately to knowledge-work pipelines, where "capacity" is harder to see because it lives in calendars and judgment rather than machines on a factory floor. That is arguably what gives the argument its current relevance — AI tools are, for the first time in many white-collar workflows, cheap and fast enough to genuinely triple one stage's throughput, which means the previously invisible constraint gets exposed at a speed and scale most operators have not had to reckon with before.
It is also, notably, an argument that cuts against the prevailing sales pitch for AI adoption, which tends to promise output gains proportional to the tool's raw speed. Tebaa's framing suggests the opposite discipline is required: before scaling a drafting tool, an organization should map its downstream checkpoint and stress-test it against three or four times the current volume, rather than assuming the checkpoint will simply absorb whatever arrives.
Where the gap has been measured directly, it has run wider than the pitch allows. In a randomised controlled trial using data from February to June 2025, the research group METR found the use of AI tools caused a 20% slowdown in completing tasks among experienced open-source developers — practitioners who expected the tools to speed them up. METR has since cautioned that developers are likely more sped up in early 2026 than that number implies, which is the honest caveat to attach to it. What survives the caveat is the shape of Tebaa's point: tool speed and delivered output are two different quantities, and only one of them is what a vendor demonstrates.
What the Restructuring Step Adds
The more useful half of Tebaa's argument, for operators, is not the diagnosis but the fix he proposes for the composite case — one that does not involve hiring a second reviewer as a first move. The restructuring rests on a handful of moves:
- Tier review by risk and value. Standard, low-risk items move to a lighter peer-review track; only high-value or custom cases reach the senior reviewer.
- Set acceptance criteria upfront. Structural checks — pricing math, required clauses, scope alignment — are validated before an item ever enters a human queue, so the reviewer spends time on judgment, not arithmetic.
- Batch review into protected blocks. Concentrated review windows remove the context-switching cost that ad hoc, interrupt-driven review quietly imposes.
- Track shipped output, not drafts produced. A metric that rewards drafting volume will keep generating volume that never clears the checkpoint.
- Add reviewer capacity last, and only at the actual constraint. Not more drafters — more judgment capacity, sized to where the system is actually binding.
In the composite case, that sequence lifts shipped output to roughly twenty-four a week — most of the theoretical thirty-a-week ceiling — without adding headcount. The broader claim Tebaa is making to operators is a modest one: an AI tool that accelerates one stage of a pipeline is only as useful as the redesign that follows it. Skip the redesign, and the gain shows up as a queue instead of a result.