Where the Saved Time Goes

Here is a calculation worth doing before any AI rollout.

A team writes proposals for clients. Writing the first draft takes about 30 percent of the total time. The rest goes to gathering information, pricing, internal review, legal checks and waiting for approvals. A new AI tool makes drafting ten times faster.

The answer is about 1.4 times. Even if drafting became instantaneous, proposals would get out the door only 1.43 times faster. The 70 percent of the work that nobody touched sets the ceiling.

That small number carries the whole argument, so here it is in one sentence: speeding up one step rarely speeds up the job, because the time piles up at the next bottleneck, usually checking and deciding, and the only way to get the gain is to redesign the flow around the tool.

If you guessed higher, you're in good company, and the reason is in how AI pilots get reported. The pilot measures the step: drafting went from three hours to eighteen minutes. The organization lives the job, and the job barely moved. A lot of the disappointment with AI at work has this shape, and the model has nothing to do with it.

The part you didn't speed up

Computer architects hit this wall in the 1960s. In 1967 Gene Amdahl argued that adding processors to a computer couldn't speed up the part of a program that had to run one step at a time, and that this part would end up dominating. The rule carries his name, and it applies to any job made of steps.

In plain words: the part of the work you didn't speed up is a floor. If drafting is 30 percent of a proposal and the other 70 percent stays as it was, the best you can ever do is finish in 70 percent of the old time. That's the 1.43. Make drafting ten times faster and you're already at 1.37. Every further improvement in the drafting tool fights over the last few hundredths.

Scroll sideways to see the whole figure

The ceiling depends only on how big a share of the job you sped up. A step that's half the job caps you at 2 times. A step that's 80 percent caps you at 5. That gives you the first question to ask before automating anything: what share of the whole job is this step? Its share of the time from request to result, waiting included.

Most teams can't answer it, because nobody writes the waiting down. Take one real piece of work, follow it from the moment the request arrives to the moment the result is used, and time every stage. The waiting is often the biggest stage on the map.

Where the time actually goes

Amdahl's rule is the optimistic version. It assumes the rest of the job stays the same size. In real organizations the rest usually grows, for two reasons.

The fast step feeds the slow ones. When drafting gets cheap, people draft more: more versions, more memos, more slide decks, more code. Every one of them still has to pass through the steps that didn't get faster. Someone has to read it, check it, decide.

Software teams have the best data on this because their work leaves a trail. In 2025 telemetry from more than 10,000 developers, collected by Faros AI, a company that sells engineering analytics, developers on high-adoption teams merged 98 percent more pull requests, and the time spent reviewing them rose 91 percent. At the level of the whole company, Faros found no significant link between AI adoption and improvement (What Changes When Code Gets Cheap). Google's DORA research reached a compatible conclusion and described AI as an amplifier of whatever a team already does well or badly.

Outside software, researchers gave one version of this cost a name, workslop: AI-generated work that looks finished but lacks the substance to move anything forward, so whoever receives it has to fix or redo it. In their survey, 40 percent of US desk workers said they'd received some in the previous month, at about two hours each. The time the sender saved landed on someone else's desk.

Queues don't grow in a straight line. This is the part that surprises almost everyone, and it explains how a team can go from "fine" to "permanently behind" with a modest increase in volume.

Go back to the proposal team. Say it has one reviewer, busy 60 percent of the time, with drafts arriving at irregular moments the way real work does. In the simplest model of a queue, a draft waits on average one and a half times as long as a review takes. Now AI lets the team produce 30 percent more drafts. The reviewer goes from 60 to 78 percent busy, which sounds like a small change. The average wait more than doubles, to about three and a half reviews. At 90 percent busy it's nine. At 100 percent the queue keeps growing and the wait has no limit.

Scroll sideways to see the whole figure

Why so steep? Because the reviewer's idle time is what absorbs the bad days. When several drafts happen to land on the same morning, a reviewer with slack clears them by the end of the week. A reviewer without slack is still working through them when the next cluster arrives. Every point of utilization you add eats into the slack that was quietly keeping the line short.

Thirty percent more drafts can more than double the wait for review. That's where the saved time goes.

That's also why the people at the slow step are often the first to say AI made their work worse. From where they sit, it did.

And people feel faster than they are. In a 2025 randomized trial by METR, experienced open-source developers took 19 percent longer on their own projects with AI tools, and afterwards still believed the tools had made them about 20 percent faster. A 2026 follow-up with newer tools estimated a speedup instead, with wide uncertainty, and METR itself called that result an unreliable signal. The lesson that holds is about measurement: if you ask people whether AI helped, you measure the step and the feeling. Neither one is the job.

The bottleneck moves to checking and deciding

When generating gets cheap, the constraint moves to whatever turns output into a result. In most organizations that means checking first and deciding second, with context, permissions and handoffs close behind.

Checking is the big one. Someone has to know whether the output is right before it gets used. And a useful sorting rule falls out of that: AI speeds up work fastest where checking is cheap. Code with good tests, data that has to reconcile, a calculation with a known answer, a translation read by someone fluent in both languages. There, a person can verify much faster than they could produce, so cheap generation turns into real throughput. Where checking costs nearly as much as doing the work yourself (a legal opinion, a strategy memo, unfamiliar code with no tests), the reviewer has to rebuild the reasoning before trusting it, and the gain mostly evaporates. The same property helps explain which skills models improve at fastest during training (Why Progress Arrives Unevenly).

Deciding is the quieter bottleneck. A proposal that waits for the weekly pricing meeting caps the whole flow at one cycle a week, however fast it was drafted. AI can prepare a decision well. It rarely holds the authority to make it, and often it shouldn't. Some approvals carry real judgment; others are habit that nobody has questioned in years (Why the Process Exists).

The rest follow the same logic. Getting the right context to the model, such as the latest contract or the reason a decision was made last year, is cheap where someone wrote it down and expensive everywhere else. Access to systems and data is granted by people whose job is to say no carefully. And every handoff between people is one more queue.

Redesign the flow, or keep the queue

So far this sounds pessimistic. Here is where I part ways with people who conclude that AI doesn't deliver.

The ceiling applies to a job whose steps stay the same. Change the steps and the ceiling moves. That's where the large gains are, and there are four ways to reach them.

Collapse steps. If a model drafts the proposal, prices it and checks it against the standard terms in one pass, three steps become one and the waits between them disappear. This works only if the combined result is as cheap to check as before; otherwise the review comes back as its own step.

Run steps in parallel. Research, pricing and legal review often happen one after another simply because one person or one team does them. Agents can do several at once, provided the results don't all land on the same reviewer the same afternoon.

Spend the speed on quality. A proposal team that tailors every proposal instead of reusing a template, or a support team that resolves more on first contact, gets value a stopwatch can't see.

Take on new demand. If proposals get cheap to produce, the team can bid on work it used to skip. That shows up as revenue, which is why "hours saved" is often the wrong unit entirely (Measuring AI Impact Without Fooling Yourself).

All four change the shape of the work. That is organizational work, the kind no tool does for you, and it's why so many successful pilots turn into disappointing rollouts (Designing an AI Program That Ships).

What I'd do

My advice for a team or a company is short, and most of it runs against how AI programs are usually planned.

Map before you automate. Follow one real piece of work end to end and time every stage, waiting included. Find where work waits longest. It's rarely the step the vendor demo shows.

Put AI at the bottleneck, or widen the bottleneck. Speeding up a step that isn't the constraint produces inventory: drafts sitting in a queue. If the constraint is review, the best place to spend may be review itself.

Make the work cheap to check. Tests, reference cases with known answers, outputs in a structure a machine can validate, a second check by someone (or something) that didn't produce the work. Each of these widens the bottleneck. A better generator doesn't.

The best AI investment is often making the work cheaper to check.

Budget for review before you add volume. If AI doubles the drafts reaching a reviewer, review has to change too: more people, cheaper review, or fewer and better drafts. A plan that adds generation and leaves review alone is a plan to build a queue. Keep the people at the slow step well short of fully busy; that slack is what keeps the line moving.

Measure the job. Lead time from request to result, how long things wait for review, how much gets redone, cost per finished piece of work. Drafts produced and time to first draft will look wonderful and tell you very little. And don't rely on asking people whether it helped.

Then redesign the flow. Collapse steps, run them in parallel, move decisions closer to the work, and decide whether the speed should become time, quality or new business. That's where the gain is, and it's the part nobody can buy.

The tool will keep getting faster. If next year's model drafts in six minutes instead of eighteen, the proposal team goes from 1.37 times faster to about 1.41, and nobody will notice. What changes the job is the work around the tool: who checks, who decides, and how long things wait in between.

Check yourself

Why doesn't a tenfold faster drafting step make proposals come out tenfold faster?

The untouched 70 percent of the work is a floor. Only the drafting share speeds up, so the whole job gains far less than the step does.

Why can 30 percent more drafts more than double the wait for review?

A reviewer's idle time absorbs the bad days. As utilization rises that slack disappears, so queues grow much faster than volume.

Where should AI go first, and why?

At the bottleneck, often checking. Making work cheaper to check widens the constraint, while a better generator only adds drafts to the queue.