When your work is serial, agent latency becomes wall-clock latency. No amount of tooling eliminates the wait. The productive move is redirecting your energy, not fighting the constraint.
Author: James Phoenix | Date: April 2026
The Parallelism Ceiling
Most advice about agent-driven development assumes you can parallelise. Spin up three worktrees. Run five agents. Review while the next batch cooks. The throughput articles, including ones in this knowledge base, focus on maximising concurrent work streams.
That advice is correct when your tasks are independent. It falls apart when they’re not.
Some work is inherently serial. Feature B depends on the types Feature A introduces. The API layer can’t be built until the domain layer exists. The integration test needs the endpoint it’s testing. The migration must land before the seed data script runs.
When you hit a chain of dependent tasks, your throughput collapses to the speed of one agent completing one task at a time. You’re no longer bound by how many agents you can run. You’re bound by how fast each link in the chain resolves.
This is the critical path problem from project management, showing up in your afternoon.
Why Agent Latency Hurts Here
A single agent task in Claude Code or Codex might take 2 to 10 minutes depending on complexity. For independent work, that latency is invisible. You’re reviewing PR #1 while agent #2 builds the next thing. Your time is full.
For dependent work, that latency stacks. Five serial tasks at 5 minutes each is 25 minutes of wall clock time where you cannot meaningfully advance the project. You can watch. You can hover. But the train moves at the speed it moves.
The instinct is to feel unproductive. You finished speccing the work. The agent is executing. You’re waiting. Something feels wrong.
Nothing is wrong. You’ve hit the constraint. The question is what you do with the time the constraint creates.
Three Things You Can Do While the Critical Path Cooks
1. Spec More Work
The most valuable use of blocked time is getting ahead on planning. While the agent works through tasks 1 through 3 of your current chain, you can be writing the spec for the next feature, the next chain, the next project.
This is where plan mode shines. Not as a toggle you flip before execution, but as the thing you default to when execution is out of your hands. Open a new conversation. Think through the next piece of architecture. Write acceptance criteria. Identify edge cases. Draft the CLAUDE.md updates the next feature will need.
Planning is the highest-leverage activity you have. Doing it during blocked time means you’re not “waiting.” You’re pulling forward work that would otherwise delay the next cycle.
The compound effect: when the current chain finishes, you already have a fully formed spec for the next one. No ramp-up time. No “what should I build next?” The agent goes straight from completion to the next spec. Your throughput across chains improves even though throughput within each chain stays the same.
2. Review Completed Work
While the current chain executes, there’s almost certainly finished work from earlier that you haven’t reviewed deeply. PRs that merged with a quick glance. Features you shipped but didn’t test edge cases on. Code that works but might not be right.
This is validation time. Read the diffs carefully. Run the feature manually. Check the error handling paths. Look for the subtle issues that automated tests miss: wrong abstractions, leaky domain boundaries, performance traps, accessibility gaps.
Review during blocked time serves two purposes. First, it catches problems before they compound. A bad abstraction caught today saves a rewrite next week. Second, it builds your understanding of the codebase as it evolves. When agents are writing most of the code, your mental model can drift from the actual implementation. Review time keeps the model accurate.
3. Improve the Harness and Infrastructure
The third option is meta-work. While you can’t push the current feature forward, you can make every future feature faster.
This includes:
- Adding lint rules that catch patterns agents get wrong repeatedly
- Improving CI pipelines so feedback loops are tighter
- Writing better CLAUDE.md instructions based on mistakes you’ve seen
- Adding pre-commit hooks that prevent common errors
- Building custom MCP tools for project-specific operations
- Improving test infrastructure so agents can self-verify more reliably
- Updating skills and prompts based on what’s working and what isn’t
Harness work compounds aggressively. A lint rule you write today saves you from reviewing the same mistake across every future PR. A better CLAUDE.md section prevents a class of errors permanently. Ten minutes of infra work during one blocked period saves hours over the next month.
This is the “sharpen the saw” move, and blocked time is the perfect window for it because the opportunity cost is zero. You literally cannot do anything else on the critical path.
The Mindset Shift
The uncomfortable truth is that you cannot make the train go faster. If you have a five-step dependency chain and each step takes five minutes, you’re spending 25 minutes regardless of how good you are, how many tools you have, or how optimised your workflow is.
The productive response is not frustration. It is acceptance plus redirection.
Accept that the critical path has a speed limit. Then redirect your energy to the three activities above: spec more work, review completed work, improve the harness. All three are high-leverage. All three are available during every blocked period. None of them require the current chain to finish.
The engineers who struggle with agent-driven development are often the ones who can’t tolerate the gaps. They hover over the agent, watching it type. They interrupt it mid-task because the waiting feels wrong. They context-switch to something unrelated and lose their thread entirely.
The engineers who thrive treat blocked time as a feature. It’s protected time for the work that always gets deprioritised: planning, review, infrastructure. The dependency chain forces you to do the things you should have been doing anyway.
When It Gets Better
Two things reduce the pain over time.
Better specs reduce chain length. When your specs are precise, agents make fewer mistakes. Fewer mistakes mean fewer fix-then-retry loops within a chain. A five-step chain with zero rework is faster than a three-step chain where two steps need correction passes.
Better infra reduces step duration. Faster CI, better caching, tighter feedback loops, all of these shave time off each link. If you spend your blocked time improving infra (option 3 above), you’re directly reducing future blocked time. The compound loop closes.
You’ll never eliminate the constraint entirely. Serial dependencies are a structural property of software, not a tooling problem. But you can shrink the gaps and fill them with work that matters.
The One-Liner
You can’t push the train faster than the critical path allows. Spec the next train instead.
Related
- Highest Leverage: Plans & Validation – Why planning and validation are high-leverage during the plan/execute split
- Plan Mode Strategic Use – How to use plan mode for architecture decisions
- Throughput Inverts Merge Philosophy – What changes when agent throughput exceeds review capacity
- The Ladder of Coding Abstraction – Matching the right tool level to the task
- Building the Harness – The four-layer harness that compounds over time
- Git Worktrees for Parallel Dev – Parallelism for when tasks are independent
- 24/7 Development Strategy – Continuous development with agents
