The plumbing tax of AI coding

Every agentic coding workflow carries hidden overhead: the setup and coordination work that surrounds the actual coding. It does not appear in task estimates. It does not earn velocity points. But it compounds as you run more agents, and it is often the reason a session that should take two hours takes five.

Here is what the tax costs in practice, and how to reduce it.

Context initialization

Each new agent session starts cold. The model has no memory of what was decided in the last session, why the architecture is the way it is, which patterns the codebase uses, or what is off limits. Getting it back to a useful starting point requires setup: CLAUDE.md files, project context, constraints, and a summary of what the prior sessions decided.

For a single agent working on a focused task, this is manageable. For parallel agents, it multiplies. Three agents mean three separate context initialization passes, and each one needs enough information to make consistent decisions without stepping on the others. If one agent makes an assumption the others do not know about, you find the inconsistency at review time, not at design time.

The tax: five to twenty minutes of context setup per agent session, depending on project complexity and how much context management tooling you have in place.

Branch and worktree overhead

Parallel agents need isolation so they do not conflict on shared files. The standard approach is git worktrees: each agent gets its own working tree with its own branch. This is the right architecture, but it carries setup overhead for each task: create a branch, spin up a worktree, verify the starting state is clean, then after the agent finishes, review the diff, sort out merge sequencing, and clean up the worktree.

Merge sequencing matters more than it looks. Which branch lands first affects what the others need to rebase against. For five parallel tasks, the coordination is real. There is also the shared-state problem: a database migration, a central type definition, a shared utility. If two agents touch the same file, you have a conflict. Managing which agents are allowed to touch what is its own coordination layer.

Task tracking

Running multiple agents in parallel creates a second coordination layer: knowing what is in flight. Which agent is working on what? What decisions did the implementation agent make that the review agent needs to know? What did the agent flag as a follow-up? What changed in the last session that affects the next session's starting state?

Without explicit tracking, this lives in your head or in the chat history of each agent session. Chat history is not portable. Your head is not persistent across sessions. The common failure mode is spending fifteen minutes at the start of a new session reconstructing context so you can brief the next agent accurately. That reconstruction is not value-adding work - it is overhead.

Review coordination

When the agent finishes, the work is not done. Review is the step that determines whether what shipped was what you wanted. For agentic output, review has two layers: did the agent do what the task said (correctness against the spec), and did it do what you actually wanted (intent fidelity, which requires you to have made the intent explicit earlier).

Coordinating review across multiple agents means context-switching between several branches, each in a different state. The cognitive cost of context-switching is not zero. If you are reviewing five agent sessions in a single sitting, the review itself becomes a meaningful time investment - separate from the time it takes each agent to run.

The compound effect

Each of these costs exists for a single agent. For n parallel agents, the costs do not simply add - they interact.

Context setup for parallel agents needs to be consistent: if three agents each initialize context differently, their decisions diverge. Branch coordination across multiple agents means the merge sequencing problem grows faster than linearly with the number of parallel tasks. Task tracking becomes harder as more threads run simultaneously. Review coordination across many parallel branches is its own cognitive load.

The result: past a certain number of parallel agents, the overhead of managing them can consume the time savings from running them in parallel. The 3-4 agent ceiling in raw parallel workflows is often a coordination overhead limit, not a compute limit. Add a fifth or sixth agent and the coordination work starts to outpace the productivity gain.

What reduces the tax

The overhead is not inherent to agentic development. It is a property of how the workflow is structured.

Automated context injection. CLAUDE.md files are the standard mechanism, but the real gain is having the conventions file generated from the project rather than maintained by hand, and having each agent session load the current conventions without manual effort. Keeping that file consistent across parallel sessions is what context coordination across parallel agents is about.

Worktree automation. Creating and cleaning up worktrees per task is automatable. The setup that takes five minutes manually takes near-zero time when scripted. Git worktrees for parallel agents covers the mechanics.

Persistent task memory. Each task should carry its own record: what the spec said, what the agent decided, what it flagged, what the review found. The record outlives the chat session. The next agent session starts from the record, not from scratch. When the AI agent proposes the next task covers how backlog capture reduces this overhead in practice.

A design step before implementation. A lot of review overhead comes from reviewing code that implements the wrong thing. The design step catches the mismatch before implementation starts, at the cheapest point in the cycle. Design-first agentic development covers the mechanics and why the gate keeps getting skipped.

Hard stage gates. Agents that skip stages or produce output for the wrong stage add review overhead. Enforced gates that prevent implementation from starting until design is approved, and that prevent release until review is done, remove a whole class of overhead that would otherwise land in human review. Why AI coding agents need hard stage boundaries covers the failure modes that gates prevent.

How lifecycle tooling changes the math

defract reduces the plumbing tax at the architecture level. The lifecycle handles worktree creation and cleanup per task, context injection from CLAUDE.md extraction (not a hand-maintained file), a persistent task record that survives session boundaries, and hard gates at the design-to-implementation and review-to-release transitions. Each of those eliminates one of the tax items above, so the overhead does not compound across parallel tasks the way it does in a raw agentic workflow.

For a wider look at which agentic patterns hold up as you scale from one agent to many, which agentic coding patterns actually scale grades five approaches against codebase size, task complexity, agent count, and session duration.