The Orchestration Tax is You

AddyOsmani.com · rss · 2026-05-25 Reader 🖥️

practical · mixed — Argumentative-with-narratives in service of practical advice. Osmani builds a structural diagnosis (you are a single-threaded resource in a concurrent system) and then issues prescriptions for how to architect attention. The framing is engineering-pragmatic: borrow concurrent-systems vocabulary (GIL, Amdahl, backpressure, context-switch cost) and apply it to the operator's cognition.

Structure

Key terms

• Orchestration tax Orchestration Tax / Human Review Bottleneck
  The structural gap between what AI agents can produce and what the human can actually review, merge, and integrate. The price paid for treating spawning as the skill while ignoring that review is the constraint. Attributed to Richard Seroter on the panel; Osmani adopts and develops it.
• You are the GIL Orchestration Tax / Human Review Bottleneck
  The developer is the Global Interpreter Lock of their agent fleet: agents can all run concurrently, but any work requiring genuine architectural understanding, conflict resolution, or judgement must acquire the one lock — which only the developer holds.
• Serial fraction (in agent workflows) Orchestration Tax / Human Review Bottleneck
  The portion of the development pipeline that cannot be parallelized — specifically the judgement step: code review, architectural reconciliation, merge decisions. Per Amdahl's Law, this fraction caps overall throughput no matter how many agents are added.
• Backpressure (applied to agent fleets) Orchestration Tax / Human Review Bottleneck
  The principle that the producer (agent count) should slow down to match the consumer (your review rate). The right number of parallel agents is how many you can code-review properly, not how many the UI lets you spawn.
• Cognitive surrender Cognitive Surrender
  (Linked from an earlier Osmani post.) The state in which you accept an agent's code because forming your own opinion costs attention you no longer have. The reviewer continues to perform the ritual but has stopped performing the function.
• Context switch cost (developer edition) Orchestration Tax / Human Review Bottleneck
  The minutes (not microseconds) of brain-flush-and-reload required every time you turn from one agent's output to another's. You never reload perfectly, so multiple agents are not 1x workload done N times but N cold reloads plus background anxiety.
• Cognitive debt Cognitive Debt
  Via Margaret-Anne Storey: the mental-model decay accumulated when you merge code you didn't read carefully. Pairs with technical debt and is the long-tail cost of unpaid orchestration tax.
• Comprehension debt Cognitive Debt
  (Linked from an earlier Osmani post.) The accumulating gap between what is in the codebase and what you understand about it. Spawning more agents without review accelerates accrual.
• Busy vs productive Orchestration Tax / Human Review Bottleneck
  The dashboard-full feeling of 20 running agents is decoupled from actually shipping good code to main. From inside the feeling is identical, which is why the failure mode is invisible.

Propositions

• explicitStarting an agent is cheap; closing the loop on an agent is expensive.conf: high
• explicitestablishedThere is exactly one of you, and your judgement throughput is the binding constraint on agent-assisted development.conf: high
  supportsThe AI paradox: More automation, more humans, more work | Dan Shipper · p18 — Osmani's judgement-throughput-as-binding-constraint is the same claim as Shipper's implicit premise that human attention is the non-relaxing bottleneck on agentic productivity.
  supports ←Agentic Code Review · p1 — Osmani's earlier claim that the developer's judgement throughput is the binding constraint on agent-assisted development is here restated as review being the whole pipeline's bottleneck, now grounded in 2026 telemetry rather than argument.
  extends ←What OpenAI and Anthropic Think Happens Next With AI · p6 — Generalizes Osmani's individual judgement-throughput constraint to the organizational level: capacity to pursue ideas, not idea generation, binds AI-accelerated organizations.
  supports ←Radar Trends to Watch: July 2026 · p6 — The PR-flood leadership-skills framing (Huston, Lawson, Currie) is a direct, independently-sourced instance of the claim that human judgement throughput, not agent output, is the binding constraint.
  extends ←Loop Engineering · p10 — Explicitly credits his own orchestration-tax essay: worktrees remove the mechanical file-collision failure mode of parallel agents but leave the human's judgement throughput as the binding constraint untouched.
• explicitCognitive bandwidth does not parallelize; running more agents does not create more of you.conf: high
• explicitcontestedBy Amdahl's Law, parallelizing agent production cannot exceed the throughput of the serial judgement step.conf: high
  contradicts ←Harness engineering: leveraging Codex in an agent-first world · p2 — Osmani's structural claim (by Amdahl's Law, parallelizing agent production cannot exceed the throughput of the serial human-judgment step) is in tension with this piece's reported empirical result — per-engineer PR throughput rising, not falling, as the team grew from three to seven — a genuine corpus tension rather than a resolved disagreement, since this piece never isolates whether human judgment time per PR fell or whether PR size/risk fell instead.
• explicitOptimizing the non-bottleneck part of a pipeline does not increase throughput; it only grows the queue in front of the bottleneck.conf: high
• explicitestablishedThe orchestration tax is the structural gap between agent production capacity and what the developer can actually merge.conf: high
  extends ←GitLab 19.2 Puts AI Agents to Work on the Security Backlog · p5 — GitLab's mandatory human-approval checkpoint on every agent-authored change is a product-level acknowledgment of the orchestration tax — the structural gap between what agents can produce and what a human can actually merge.
  supports ←Loop Engineering · p11 — Restates that the orchestration tax — the gap between what agents produce and what a human can actually verify/merge — persists inside a fully designed loop; a verifier sub-agent doesn't eliminate the tax, it's the mechanism by which the human decides whether to trust the loop's 'done' claim at all.
  extends ←#ai #programming #softwareengineering | Addy Osmani | 11 comments · p8 — The personal anecdote (prompting and orchestrating more than reviewing line-by-line) is a concrete first-person instance of the structural 'orchestration tax' gap the later piece formalizes between agent production capacity and what one developer can actually merge.
  supports ←Own the Outer Loop · p14 — Recaps the author's own prior orchestration-tax diagnosis as the third named hidden cost of ceding the outer loop.
• explicitThe tax will be paid one way or another: either deliberately, through architecting attention, or quietly, through shallow reviews and cognitive surrender.conf: high
• explicitFeeling productive (full dashboard, many running agents) is decoupled from actually shipping good code; from the inside the two feel identical.conf: high
• explicit⚡ disputed & corroboratedThe correct number of parallel agents equals the number you can code-review properly — typically a low single digit.conf: high
  supports ←The AI-Native SDLC playbook · p14 — Both converge on the identical rule for bounding parallel agent sessions: cap at what one person can actually review properly, not at what the tooling permits.
  extends ←AI Development Patterns · p7 — Osmani's rule ('the correct number of parallel agents equals the number you can code-review properly') names the review-capacity ceiling; Duvall's pattern supplies the missing mechanics underneath that ceiling — isolation, shared memory, and automated conflict resolution — needed to run even that bounded number of agents without them colliding.
  extends ←10 Things Developers Want from their Agentic IDEs in 2025 · p6 — This piece names the accessibility gap in parallel-agent orchestration (only senior+ engineers succeed at it); the other extraction supplies the underlying mechanism — the ceiling is set by how many agents one person can code-review properly.
  contradicts ←The Conductor Developer · p5 — Laycock reports engineers sustainably running 8-12 parallel agents before the human becomes the bottleneck; Osmani puts the 'correct number of parallel agents' at a low single digit, tied specifically to code-review throughput. The two numbers conflict unless the underlying activities (general orchestration attention vs. reviewable code output) are actually different things being measured with the same unit.
• explicitWork splits into two categories — isolated tasks suitable for background agents, and complex tasks where judgement IS the work — and parallelizing the second category degrades all outputs.conf: high
• explicitBatching reviews is cheaper than interleaving them, because human context-switch cost is paid in minutes, not microseconds, and reload is never perfect.conf: high
• explicitVerification work that a machine can perform (passing tests, screenshots) should be offloaded so the developer's scarce attention is reserved for the irreducibly human portion (~20%) that needs judgement.conf: high
• explicitSometimes the highest-leverage move is to stop orchestrating, close the agent laptop, and think hard about one problem with the lock held the entire time.conf: high
• explicitcorroboratedUnpaid orchestration tax accumulates as both technical debt (merged-without-reading code) and cognitive debt (stale mental model of the codebase).conf: high
  supports ←Guillaume Barrois' Post · p4 — Both treat a deliberate review checkpoint (pull requests here, closing the orchestration loop there) as the mechanism that prevents agent-driven speed from compounding into unpaid cognitive debt.
• explicitdevelopedSpawning agents is not the skill; designing the surrounding system around the single non-cloneable serial resource (your attention) is.conf: high
  extends ←The Orchestrator's Tax · p8 — Both conclude that spawning/running more agents is not itself the skill; the real discipline is designing the system around a single, non-cloneable, serial resource. Osmani names that resource as the human's attention/review capacity; this piece applies the identical structural insight one level down, to the AI orchestrator's own context.
• explicitThe bottleneck is structural, not motivational; effort, discipline, and grinding cannot move it.conf: high
• implicitAI tool UIs that let you spawn 20 agents are exposing a UI capability that exceeds any sustainable workflow; the affordance is misleading.conf: high
• implicitcontestedThe orchestration tax is primarily an individual-developer problem to solve through personal workflow design.conf: high
  contradicts9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team · p8 — Osmani frames agent-workflow discipline as an individual problem solved by personal workflow design; Brede Moe's evidence says teams that treat AI practice as joint team work outperform individual practice.
  contradicts ←The AI-Native SDLC playbook · p7 — Osmani frames the orchestration tax as an individual-developer problem to solve through personal workflow design; Claxton locates the same tax-paying activity (maintaining shared context, catching repeated mistakes) in team-owned, version-controlled infrastructure (CLAUDE.md, skills) a platform team maintains — an organizational-capability framing, not a personal-discipline one.
  contradicts ←The Conductor Developer · p8 — Osmani frames the orchestration tax as 'primarily an individual-developer problem to solve through personal workflow design'; Laycock explicitly argues the missing piece is organizational/career redesign (coaching, job redesign, career ladders) analogous to how organizations already develop executives — a systemic rather than individual-workflow intervention.
• explicitArchitecture skill — knowing what belongs inside one agent and what is too much for it — is the urgent skill of the current moment.conf: high
• explicitcorroboratedIf a system is not designed around the human attention bottleneck, it will route around it by silently lowering standards.conf: high
  extends ←Addy Osmani's Post · p6 — Osmani's earlier essay warned that a system not designed around the human review bottleneck will silently lower its standards; this post supplies the deliberate design (constraints as back-pressure) that is meant to prevent exactly that silent erosion.
  supports ←Agentic Code Review · p6 — The prior post's prediction — that a system not designed around the human-attention bottleneck will route around it by silently lowering standards — is empirically confirmed here: nobody chose to stop reviewing, yet Faros shows zero-review merges up 31.3% and code merging unread became normal.
• explicitBackground anxiety about which agent should be checked next is itself a load on the serial processor — not just the explicit reviews.conf: high
• explicitestablishedThroughput in concurrent systems equals the throughput of the slowest stage; in agent-assisted development that stage is human review.conf: high
  supports ←AWS Expands DevOps Agent with AI-Powered Release Management to Validate Code Before Production · p2 — Corroborates that human review is the bottleneck/slowest stage that AI-inflated volume made binding — AWS's motivation for this release.
  supports ←We don't write code anymore · p5 — Both identify human review as the slowest stage that caps overall throughput regardless of how fast agents generate code.
• implicitMental model freshness is itself a stock that depletes silently when you merge unread code; the depletion is invisible until production breaks.conf: high

Arguments

Narratives

• Google I/O panel exchange: Richard Seroter says 'you talked about the orchestration tax — you can't manage twenty agents successfully in your own brain', and Osmani agrees, framing it as an architecture problem not a discipline problem.
  → Earns the framing through attribution and provides the central name. Also establishes the panel as the social context that produced the post's vocabulary.
• Osmani saying on the panel: 'I never felt more productive with my tools but I am also more tired than I ever been.'
  → Embodies the diagnosis — both halves are real and have the same cause (running a serial processor at 100%). Converts a personal admission into evidence for the structural claim.
• Python's GIL: many threads, one lock, serial execution of bytecode.
  → Provides the central analogy. The developer is the GIL of their agent fleet; everything that needs the lock queues behind everything else needing the lock.
• CPU context switches happen in microseconds and architects still work hard to avoid them; the developer's context switch happens in minutes and is never reloaded perfectly.
  → Quantifies the cost of interleaved review and justifies batch processing as the right tactic.
• Aja Hammerly's panel claim that architecture is the urgent skill — knowing what belongs inside one agent and what is too much.
  → Co-signs and extends the central argument: the same architectural reasoning that applies to agent boundaries applies to the developer's own attention as a system component.
• Ciera Jaspan citing Margaret-Anne Storey's work on cognitive debt; the panel discussion of technical debt and cognitive debt accumulating together.
  → Links the personal-attention framing to a research literature on the long-tail organizational cost; raises the stakes from tiredness to system-understanding loss.
• The dashboard-full-of-running-agents feeling that is indistinguishable from real productivity.
  → Phenomenological grounding of the busy-vs-productive distinction; explains why the failure mode is self-concealing.
• Cross-reference to Osmani's earlier posts: 'Your parallel agent limit' (ambient anxiety about which thread is quietly failing), 'Cognitive surrender' (accepting agent code because forming an opinion costs too much), and 'Comprehension debt' (the gap between code and your understanding of it).
  → Positions this post as the structural diagnosis underneath three earlier phenomenological observations. Implicitly, those earlier posts were symptoms; this one is the disease.

Questions addressed

• ✅ Why does running more AI agents not produce proportionally more output?
  Because the developer is a single serial resource (the GIL) that all judgement-bearing work must pass through; Amdahl's Law bounds throughput at that step.
• ✅ Why does running many agents feel productive but exhausting at the same time?
  Both effects have the same cause: running a serial processor at 100% with cold context reloads between checks; the fullness of the dashboard masks the depletion of the only resource that actually ships code.
• ✅ What concrete tactics actually relieve the orchestration tax?
  Five: backpressure on agent count, sort work by judgement-content, batch reviews, offload verification to the machine, protect serial time for deep judgement.
• ⭕ Who should solve this problem — individual developers, tool vendors, or organizations?
  Osmani addresses the individual-developer level exclusively. He notes in passing that the UI 'will happily let you spawn 20', flagging a vendor problem, but does not develop it. He does not address the organizational-incentives layer at all (e.g., what happens when management measures spawn count, or pressures developers to fill the agent capacity).
• ⭕ How does the orchestration tax interact with organizational incentives that capture efficiency gains as throughput pressure?
  Unaddressed. Osmani assumes the developer can choose to protect their serial time. He does not engage what happens when an organization will not allow that protection.
• ⭕ How does the orchestration tax differ across seniority levels and team contexts?
  Unaddressed. The post assumes a senior developer with full code-review authority; the dynamics for junior developers (who may have less authority to push back on agent output) or for teams (where review can be distributed) are not considered.
• ✅ Where exactly is the bottleneck — context-switching, attention residue, queuing, or pure cognitive throughput?
  Osmani frames it as a multi-component bottleneck: (a) pure cognitive throughput (Amdahl serial fraction), (b) context-switch cost paid in minutes per swap, (c) background-process load from ambient anxiety about which agent to check next. He treats these as additive components of one structural tax rather than picking one as primary.

Gaps

• incompleteOsmani frames the orchestration tax as a personal-workflow problem to be solved by individual architectural discipline. He never explicitly considers the alternative diagnoses: that this is a tooling/UX problem (the 'spawn 20 agents' UI is itself the bug; vendors should ship review-rate-aware fleet limits and attention-cost-aware dashboards), or an org-design problem (incentive structures that reward visible agent activity over merged-and-understood code create the tax independent of any individual's discipline). The 'low single digit' is presented as a constant of human cognition rather than as a number that tooling and org design could move. This matters because the individual-discipline framing puts the entire fix-burden on the developer and treats organizational and vendor pressure as background.
  Read next: Paul Reed's 'Ironies of A^2 I^2' (already in this repo) for the parallel argument that organizations capture AI efficiency as throughput pressure rather than thoroughness time. Birgitta Bockeler on harness engineering for the tooling-as-leverage angle. Donella Meadows on leverage points and feedback loops for the system-design layer. John Cutler on institutional overload for how orgs metabolize new capabilities.
  closed byGitHub Brings Stacked Pull Requests to Public Preview — Only partially: Osmani's piece names an unconsidered alternative diagnosis of the orchestration/review tax — that it's a tooling/UX problem vendors should address, not just a matter of individual developer discipline. GitHub's native stacked-PR launch is a concrete, real-world instance of exactly that vendor-tooling response (restructuring how review scope is packaged at the platform level). It doesn't fully close the gap — it doesn't ship 'review-rate-aware fleet limits' or attention-cost-aware dashboards, only PR-structuring — but it is direct evidence that vendors are moving in the diagnosed direction.
• incompleteThe piece does not distinguish between agent types or task types when sizing the fleet. 'Background agents in the Cloud' versus 'foreground agents you steer interactively' have very different review-cost profiles; isolated refactors versus exploratory feature work have very different judgement-content. A more developed version would offer a cost function for fleet sizing rather than 'a low single digit'. The lock-thrashing claim for complex tasks is asserted but not modeled — at what point does adding one more in-flight complex task degrade ALL outputs, and how do you tell you're past it?
  Read next: Queuing-theory treatments of knowledge work (e.g., Reinertsen 'The Principles of Product Development Flow'); empirical studies of attention residue (Sophie Leroy).
• incompleteOsmani assumes the developer can accurately measure their own sustainable review rate and choose to stop at it. Stolen-Focus / Bailey-style attention research suggests this self-measurement is precisely what gets degraded first when attention is depleted. The prescription 'scale fleet to your review rate' presupposes a calibrated self-monitor that the diagnosis itself implies has been compromised. The post does not address this circularity.
  Read next: Chris Bailey on attention as a managed resource; Johann Hari 'Stolen Focus'; cognitive-load research on metacognitive accuracy under load.
• incompleteThe post treats 'judgement' as a unitary thing — the indivisible serial work the developer must do. But judgement decomposes (architectural fit, security/safety review, performance reasoning, business-logic correctness, code style and idiom, merge-conflict resolution). Some of these are plausibly delegable to specialized AI reviewers or to teammates; others are not. The post's 'one lock' framing forecloses an analysis of which kinds of judgement could be horizontally distributed and which cannot.
  Read next: Code-review research; Greg Wilson on what code review actually does; team-distributed-cognition literature (Hutchins 'Cognition in the Wild').
  closed byAgentic Code Review — Decomposes the previously-unitary 'judgement' the prior post treated as one indivisible lock: this doc separates the part that transfers to a model (line-by-line bug-catching, the boring 90%, first and second pass, heterogeneous AI reviewers) from the part that cannot (accountability, whether this is the right change to build, high-blast-radius gates, the behavior nobody specified) — exactly the horizontal-distribution analysis g4 said the 'one lock' framing foreclosed.
• incompleteOsmani gestures at 'cognitive debt' via Storey but does not develop the stock-and-flow model implied by his own diagnosis. If mental model is a stock that depletes with unreviewed merges and replenishes with deep code reading, the orchestration tax is a flow-rate problem with a leverage point in the replenishment rate, not just in the merge rate. He prescribes throttling merges (backpressure) but does not prescribe deliberately re-reading old code to rebuild stale model — a complementary tactic.
  Read next: Donella Meadows on stocks-and-flows and leverage points; Naur 'Programming as Theory Building' on the theory developers carry of their code; recent empirical work on mental-model decay in long-lived codebases.
• incompleteThe asymmetric-risk frame from Paul Reed's 'Ironies of A^2 I^2' (catastrophic downside when AI is misleading, modest upside when AI is correct, and operators cannot detect in real time which regime they are in) is precisely the empirical mechanism that would make 'shallow reviews' so dangerous. Osmani names shallow reviews as the failure mode but does not connect it to the Woods et al. nurses-study finding that explains WHY shallow review of AI output is uniquely catastrophic compared with shallow review of human output. The two posts are talking about the same dynamic from different angles and would strengthen each other.
  Read next: Paul Reed 'The Ironies of A^2 I^2' (already extracted in this repo); Woods et al. July 2025 nurses study; the METR developer study.
• illogicalThe GIL analogy is rhetorically powerful but slightly misleading. A GIL serializes execution but does NOT serialize knowledge of state — Python threads share memory cheaply once the lock is held. The developer's situation is worse: not only is execution serial, but knowledge-of-state must be reconstructed (the 'cold reload') every time the lock is acquired. Osmani notes the cold-reload cost separately but does not see that this means the GIL analogy understates the asymmetry. A better analogy would be 'GIL plus no shared memory plus expensive page fault on every acquire' — i.e., closer to distributed-systems coordination than to threaded execution.
  Read next: Distributed-systems literature on shared-nothing coordination; Hutchins on distributed cognition; the multi-agent-systems literature on shared mental models.

Closes gaps elsewhere

• Henrik Kniberg's Post · g1 — Supplies the failure modes and guardrails Kniberg's success narrative omits: shallow reviews, cognitive surrender, technical and cognitive debt, and sizing the agent fleet to human review capacity (p6-p9, p14).
• Presentation: Leadership in AI-Assisted Engineering · g3 — Answers how AI changes the nature of engineering work: architecture/system-design around the attention bottleneck becomes the urgent skill, and review practices must adapt via batching, offloading machine-verifiable checks, and fleet sizing (p9, p11, p12, p19).

Related documents

• Agentic Code Review
  Code Was Never the Bottleneck Cognitive Debt Cognitive Surrender Orchestration Tax / Human Review Bottleneck
• Finding Comfort in the Uncertainty
  Code Was Never the Bottleneck Cognitive Debt Human as Orchestrator of Agents Orchestration Tax / Human Review Bottleneck
• Five studies that are changing how I think about AI in software engineering
  Code Was Never the Bottleneck Cognitive Debt Orchestration Tax / Human Review Bottleneck
• Fragments: February 13
  Cognitive Debt Human as Orchestrator of Agents Orchestration Tax / Human Review Bottleneck
• The Conductor Developer
  Code Was Never the Bottleneck Human as Orchestrator of Agents Orchestration Tax / Human Review Bottleneck
• The 8 software engineering metrics AI broke
  Code Was Never the Bottleneck Cognitive Debt
• Software Factories, Light and Dark
  Cognitive Debt Human as Orchestrator of Agents
• Podcast: Will Agentic AI Bring Fantasia's Sorcerer's Apprentice to Life?: A Conversation with Tracy Bannon
  Cognitive Surrender Orchestration Tax / Human Review Bottleneck
• Research: Why You Shouldn't Treat AI Agents Like Employees
  Human as Orchestrator of Agents Orchestration Tax / Human Review Bottleneck
• AI coding creates two kinds of debt. You're only measuring one
  Cognitive Debt Cognitive Surrender