The bottleneck moves

Every advance in model capability relocates the hard part rather than removing it. When drafting was expensive, output was the constraint.

Now that drafting is close to free, the constraint has moved to either side of it: what context you can assemble beforehand, and what you can actually verify afterwards. Tools built for the old constraint are optimising a problem that has already moved on.

The pattern is older than language models. It was worked out on factory floors long before anyone asked a machine for a paragraph, and the lesson carries over almost intact: speeding up the wrong step makes a system look busier without making it deliver more.

A lesson from the factory

In 1984 Eliyahu Goldratt and Jeff Cox published The Goal, a novel about a plant manager trying to save a failing factory. Its argument, which became known as the theory of constraints, is simple to state. Every system has a step that limits how much it can produce, and the output of the whole is set by that step. Speed up any other step and the system produces no more; in the book’s own image, an hour saved at a non-bottleneck is a mirage.

In one respect it is worse than a mirage. A step that runs faster than the constraint sends it more work than it can handle, and the surplus piles up in front of it as inventory. The factory looks more productive and ships no more. The book’s remedy is to judge every step by what the whole system delivers, not by how busy the step appears.

The method that grew out of the book ends with a warning. Once a constraint has been broken, go back to the beginning, because something else is now the constraint — and do not let habits built around the old one become the new one. Relieving a bottleneck does not end the work. It moves it.

Drafting with a model is a relieved constraint. A summary, a first version of a report, a design note or an overview of a field used to take hours and now takes moments. By Goldratt’s logic, the useful question is no longer how to make drafting faster still, but where the constraint went. The answer is to either side of the draft: before it, deciding what the model should see; after it, deciding what to believe.

Before the draft

Consider a policy analyst asked for a two-page briefing on whether a city should extend its bus lanes. A model will produce two fluent pages on the first request. Whether they are any use depends on choices the analyst makes before asking: which evaluations of earlier schemes to include, which local traffic counts, whether the question is ‘should we extend them’ or ‘what happened in cities that did’. A model cannot weigh a report it was never shown.

This is the first half of the new constraint: context assembly — choosing sources, framing the question and deciding what the model should not see. The last part matters more than it seems. Pasting everything and letting the model sort it out is tempting, but long, uncurated inputs have costs of their own: Liu and colleagues (2024) found that models often made better use of material near the start or end of a long input than of material buried in the middle. The argument is set out in Lost in the middle; the short version is that more input is not the same as better context.

Context assembly is slow and hard to delegate, because it depends on knowing what matters. That is precisely why it has become binding. Drafting got faster; this step did not.

After the draft

The other half is verification. A student writing a literature review asks a model to summarise what six papers say about sleep and memory. The result reads well, and most of it is right. One sentence credits a finding to the wrong paper; another turns a cautious ‘under some conditions’ into a general rule. Finding either error means returning to the papers — which is, uncomfortably, much of the work the summary was meant to save.

Fluency is what makes this hard. In a human draft, rough prose often signalled rough thinking, and a reviewer could use one as a cue for the other. Generated text is evenly polished, so that cue is gone. Plausible-but-wrong output is expensive because it looks exactly like correct output; the only dependable test is to check each claim against its source.

Lisanne Bainbridge saw a version of this in 1983, writing about industrial process control. In Ironies of automation she argued that automation may expand rather than eliminate the problems of the human operator, who is left with whatever the designer could not automate — including monitoring a system installed because it does the job better than the operator can. Monitoring well, she noted, requires knowing what correct behaviour looks like. Checking a summary of six papers requires knowing the six papers.

That is why provenance matters. If each claim in a draft points to the passage it rests on, verification is a lookup: open the source, find the sentence, compare. If the draft arrives as free-standing prose, verification becomes a search, and searches are what people skip when they are busy.

Why checking gets harder

People are also not neutral judges of machine output. Raja Parasuraman and Dietrich Manzey (2010) reviewed research on automation bias: letting an automated aid’s output stand in for careful information seeking. It produces omission errors, where people miss a problem because the aid did not flag it, and commission errors, where they follow advice that is wrong. The review found it in novices and experts alike, and found that training or instructions did not prevent it.

Those studies concern cockpit alerts, diagnostic aids and similar systems, not language models, so the transfer should be made with care. But the shape is recognisable. An engineer reviewing a generated design note for a new caching layer will check what the note says — the diagram, the configuration — and may never ask what it leaves out, such as what happens when the cache and the database disagree. The same review describes a related effect, complacency, which appears when several tasks compete for attention: the normal condition of anyone reviewing between meetings.

Cheap drafts add volume to the problem. When a draft took a day, a team produced a few and read each one properly. When a draft takes a minute, there are more of them — more options, more versions, more notes — and each still needs someone to decide whether it is right. It is the factory’s inventory in a new form: work piling up in front of the one step that has not become faster.

Measuring the whole workflow

The practical consequence is to measure the right thing. Time to first draft is easy to measure and increasingly beside the point. What matters is the time from a question to an answer you would act on, and how often that answer later proves wrong. A draft produced in a minute that needs two hours of checking has not beaten one built on an hour of careful source selection that needs twenty minutes.

Review should also follow the stakes rather than habit. A design note for an internal dashboard can be skimmed; one for a data migration deserves a line-by-line reading against the documentation it cites. Treating every draft alike either wastes attention on trivial work or spends too little where an error would be expensive.

Tools matter here mostly through what they keep visible. In PlansFlow, for instance, you choose which blocks on the canvas inform a generated draft, and web search answers arrive as blocks with their sources attached. What went in and what each answer rests on stay in view, which is what lets checking be a lookup rather than a search.

In practice

1. 01

   Spend your first effort on context rather than wording: choose the few sources the question needs, and be able to say why each one is there.

2. 02

   Keep every claim attached to the passage it came from, so that checking a draft means opening a source rather than hunting for one.

3. 03

   Scale review to the stakes. Skim what is cheap to get wrong; read anything that will inform a decision line by line, against its sources.

4. 04

   Ask what a draft leaves out as well as whether what it says is right — an omission gives a reviewer nothing to object to.

5. 05

   Measure the time from a question to an answer you would act on, not the time to a first draft.