AIToday

AI Latency as Thinking Time: The Case for Fewer, Better-Guided Agents

Hacker News12h agoSend on LINE
AI Latency as Thinking Time: The Case for Fewer, Better-Guided Agents

Key takeaway

A practitioner argues that AI agent latency—the wait while a coding agent works—should be treated as a feature, not a bug. Rather than scaling to dozens of concurrent agents or managing agent orchestration, the author caps foreground agents at one to three and uses the latency windows for deep thinking, spec writing, and architectural work. This approach aligns with cognitive science on "incubation" (background problem-solving) and addresses research showing that oversight of AI causes significant mental fatigue and errors; it also sidesteps the economics of high token bills and the review debt that compounds when fleets generate code faster than humans can read it.

Summaries like this, in your inbox every morning.

Sign up free →

3 Key Points

  • What happened

    A software engineer argues that the wait time (minutes to an hour) while AI coding agents work should be reframed not as a productivity problem to solve through agent orchestration, but as protected thinking time. Rather than scaling to 20–30 concurrent agents (as some practitioners do), the author caps foreground agents at one to three and uses latency windows for higher-level design work, spec writing, and architectural thinking.

  • Why it matters

    A BCG Henderson Institute study of 1,488 workers found that "oversight" of AI (watching it work) caused the most mental fatigue, with sufferers reporting 39% more major errors and 33% more decision fatigue. The author argues that latency-driven pauses enable the kind of deep thinking—what cognitive scientists call "incubation"—that produces better solutions than rapid multitasking or fleet management. For teams deploying coding agents at scale, this suggests that quality and maintainability may suffer if review debt and direction quality degrade faster than agents can generate code.

  • What to watch

    The economics of agent fleets. Microsoft's Experiences and Devices group canceled most Claude Code licenses in spring after per-engineer token bills reached $500–$2,000 per month. The author's core claim—that focused direction multiplies in value across every token generated—remains untested in a head-to-head study against orchestrated agent fleets, but cognitive science on incubation and attention residue supports the mechanism.

In Depth

The article opens with a practical scenario: the author has handed a coding agent a spec that took two mornings to write, and for the next ten to thirty minutes, the work is out of their hands. This idle time creates an itch to "do something, open another terminal." The author identifies two camps addressing this itch. Camp one scales up: orchestration of agents managing agents, with Steve Yegge's Gas Town setup running 20–30 Claude Code instances at once and envisioning "agent fleets" of a hundred-plus agents supervised by more agents. Camp two names the problem "brain fry"—a finding from a BCG Henderson Institute study of 1,488 workers showing that "the most mentally taxing form of AI engagement was oversight," not using AI but watching it. Sufferers reported 39% more major errors and 33% more decision fatigue. Camp two's prescription is guardrails: cap concurrent streams, batch check-ins, protect recovery time. The author proposes a middle path: keep the cap, but spend the reclaimed time on the thinking the job never used to leave room for. The latency window becomes an asset for incubation—the cognitive science term for the background mind doing heavy lifting on hard problems. The author cites Rich Hickey's "Hammock Driven Development" talk and cognitive science research showing that answers tend to surface during mildly engaging activity (walks, showers) after the problem has been deliberately loaded. The latency is the loading. The author's setup: one coding task at a time per project (so agents don't collide), one to three foreground agents total. When an agent is working, the author switches either across projects (rotating between repackaging a constraint-solver wrapper for open-source release, a computational geometry feature for kitchen layouts, and a front-end refactor from JavaScript to Datastar) or within the same project up a level of abstraction (thinking about the next feature, a deferred fix, or an upcoming refactor). The BCG study supports the one-to-three limit: productivity gains flattened at three concurrent AI streams and fell after that. During latency windows, the author writes specs, reads problematic code, scans the kanban for small "weed" tasks (renames, doc fixes), or feeds the hammock list—the few questions currently being loaded into the background mind. To address attention residue (Sophie Leroy's research on the fraction of mind that stays lodged in an unfinished task), the author emphasizes clean handoffs: delegation that ends in a written artifact is a finish, not an interruption. Completing your thought before attending a finished agent mirrors this symmetry. The author acknowledges the strongest objection: task-switching isn't free. The answer lies in clean handoffs from written specs, which end tasks rather than interrupting them, and symmetry—letting a finished agent wait while you complete your thought. The author also explores the steelman for orchestration: bulk migrations, mechanical sweeps, prompt tuning against eval suites, and ongoing maintenance may earn agent fleets their keep. But for feature work, two problems persist even with few foreground agents: review debt (fleets generate code faster than any human can honestly read, and unreviewed decisions become the foundation the next round builds on) and brute force (echoing The Mythical Man-Month, agents are headcount, and a fleet attached to a thin spec is a "Mythical Agent-Month"). Statistically, the fleet is running best-of-N sampling against a distribution centered on the quality of direction; a better spec moves the whole distribution, while more agents only search its tails. Microsoft's Experiences and Devices group canceled most Claude Code licenses in spring after per-engineer token bills reached $500–$2,000 a month. The author frames the trade: spend real money to replace deep engagement with rapid switching and surface-level review, at exactly the moment understanding of the code is lightest. The author acknowledges not having run a study comparing focused practice against orchestration and having stopped at "overkill" when experimenting with Gas Town and Conductor. The confession: "Greater throughput and higher quality" cannot be proven. What can be offered: review debt observably compounds, direction quality multiplies across every token generated downstream, and one randomized trial showed experienced developers estimated AI made them 20% faster when it had actually made them 19% slower (though the tooling in that study is dated). The author doubts latency will evaporate as models get faster; capability grows the scope of what is delegated, and tasks just become bigger. The practice, compressed: cap foreground agents at what you can honestly guide and review (one to three for the author); when the itch to spawn another agent arises, write the prompt for the next spec instead; finish your thought before attending a finished agent; keep a hammock list of problems currently feeding your background mind; let small stuff be gardening, with weeds sharing the same one-to-three slots.

Context & Analysis

The piece bridges two common responses to AI agent latency: scaling orchestration (20–30+ agents supervised by yet more agents) and defensive boundaries (batching check-ins, protecting recovery time). The author proposes a third path: cap agents at one to three, then spend the latency window on the kind of thinking the job rarely leaves room for—architectural reasoning, spec writing, problem incubation. This move is grounded in two bodies of evidence. The BCG Henderson Institute study quantifies the cost of oversight: workers watching AI reported 39% more major errors and 33% more decision fatigue, with "brain fry" as the named injury. Cognitive science on "incubation"—the mechanism by which background mind does heavy lifting on hard problems—explains why the latency window becomes an asset: answers surface during mildly engaging activity (a walk, a shower) after the problem has been deliberately loaded. The author's own practice rotates across three projects with radically different domains (constraint solvers, computational geometry, front-end architecture), using task-switching across levels of abstraction to refresh attention rather than switching between concurrent coding tasks. The economic argument is sharper: Microsoft's Experiences and Devices group canceled most Claude Code licenses after per-engineer token bills reached $500–$2,000 monthly, suggesting that fleet-based orchestration, while generating throughput, can extract a high cost. The author frames the central trade as direction quality versus supervision volume: statistically, a fleet is running best-of-N sampling against a distribution centered on the quality of your spec, so improving the spec moves the whole distribution, while adding agents only searches the distribution's tails. Review debt—unreviewed decisions becoming the foundation the next round of generation builds on—compounds fastest when fleets generate code faster than any human can honestly read it.

FAQ

How many agents should I run at once?
The author recommends one to three foreground agents. A BCG Henderson Institute study of 1,488 workers found that productivity gains from AI flattened at three concurrent streams and fell after that. Each agent should run a separate task to avoid collisions in the same working copy.
What should I do during the latency window while an agent works?
Write the next spec, read problematic code or interfaces, re-examine the workflow's design, or prompt small "weed" tasks (renames, doc fixes). Avoid spawning more agents; instead, point the urge toward direction-writing. Complete your current thought before attending to a finished agent, to minimize attention residue.
Why not use agent orchestration (agents managing agents)?
The author argues it creates two problems for feature work: review debt (fleets generate code faster than humans can honestly read) and brute force (echoing The Mythical Man-Month, agents are headcount, and a fleet attached to a thin spec is a "Mythical Agent-Month"). Better specs move the whole distribution of quality; more agents only search the distribution's tails. Additionally, token bills reached $500–$2,000 per engineer per month at Microsoft before most licenses were canceled.

Get the latest Large Language Models news every morning

AI-summarized, only the topics you pick — one digest a day via Email, Slack, or Discord.

Free · takes 30 seconds · unsubscribe anytime

Discussion

No comments yet. Be the first to share your thoughts!

Log in to join the discussion

Related Articles

Stay ahead with AI news

Get curated AI news from 200+ sources delivered daily to your inbox. Free to use.

Get Started Free

Free · takes 30 seconds · unsubscribe anytime