Faster AI, unfinished work

An AI agent can finish a research summary before anyone reads it. Start several agents and the summaries arrive faster still.

But arriving is not the same as done.

Someone still has to check the sources. Someone has to notice the missing qualification. Someone has to decide whether the result is useful at all.

If that person already has a queue of unfinished reviews, faster generation adds to the queue. It does not shorten the task.

This is a hypothesis about how we use AI, not a benchmark result. And the clearest way to see it comes from an unlikely place: traffic lights.

Act 1: The green light with nowhere to go

Practical Engineering’s How Do Traffic Signals Work? describes a familiar failure. A queue at one intersection backs up into the intersection behind it. The upstream light turns green, but the cars have nowhere to move.

The lesson is that signals need coordination. Improving one intersection on its own can leave the whole journey unchanged. A longer green only helps when traffic can clear into the next stretch of road.

An agent workflow has the same shape. A model produces an answer. A tool fetches evidence. Another pass checks claims. A person decides whether to use the result. Each handoff is a place where work can wait.

Making the model faster helps most when generation is what everything else is waiting for. If the bottleneck is checking, a faster model mostly produces more unchecked answers.

One caveat before going further. This assumes the model is already good enough to be worth checking. If most outputs need rewriting rather than review, the queue isn’t the problem; the cars aren’t waiting, they’re broken down, and only a better model helps. Everything that follows applies above that floor.

Above it, the question becomes how to measure the task, not the model.

Act 2: Measure the task through the checking

Speed already splits into pieces before a human gets involved.

The MacStories review of local AI agents separates processing a prompt from generating a response. It also notes that running requests concurrently raises total throughput while making each individual request slower. Those are the reviewer’s reported observations, not numbers reproduced here.

The point is that a high output rate says nothing about how long a complete research task takes. Add checking and correction, and the gap between output speed and useful completion widens.

So measure something else: time to a result you can trust and use.

Start the clock when the task begins. Stop it when the output meets requirements set in advance, including whatever checks the task needs. For a research note, that means verifying the links and confirming the cited material supports the conclusion. For a code change, it means tests and review.

The requirements must stay fixed. Otherwise a faster result may just be a lower standard.

Record the human correction effort as well. A workflow that saves machine time by burning attention is a poor bargain, however instant its answer looks.

Once you can measure the whole task, you can see where to intervene. That is Act 3.

Act 3: Shrink the job, then run the test

If the bottleneck is checking, the fix is to make checking easier. Two ways to do that.

First, give the model a smaller job.

How To Write With An LLM argues for asking a model to diagnose weaknesses while the writer keeps the wording. Those are one author’s working rules, not requirements for everyone.

The useful part is the narrow assignment. “Write a better proposal” leaves the model to decide what better means. “Find claims without evidence and passages where the requested decision is unclear” produces feedback a writer can inspect and act on.

A personal knowledge wiki can play the same role. Before a draft grows, ask it for the strongest supporting source, a conflicting argument, or an assumption the reading doesn’t establish. That gives the writer something specific to resolve, not another polished draft to compare.

Second, run a small experiment before buying more speed.

Take a repeatable task. Handle it two ways. In one, let several outputs pile up. In the other, keep one item waiting for review and finish checking it before requesting more.

Track three things: time to an accepted result, how much correction it needed, and what was left unfinished.

The smaller queue might win. Or it might leave useful capacity idle. Either way, the tradeoff gets measured instead of assumed.

Faster inference is worth having. But before paying for more of it, look at where the work is waiting. The next improvement may be a clearer acceptance criterion, a better evidence trail, or fewer drafts arriving at once.