Wave Planning: Parallelizing Software Projects with AI Agents
what running five parallel agent instances on the same wave feels like
Most software work still happens sequentially: one person, one task, one sprint at a time. Even when AI agents are involved, a lot of workflows still execute that way, task by task, in order.
I use a different structure for planning and building projects with AI agents. I call it wave planning.
The hierarchy
Wave planning is built on three levels:
- Step: the smallest unit of work, something that needs to get done.
- Phase: a group of steps that are interconnected or depend on each other.
- Wave: a group of phases that depend on each other.
Phase A and Phase B share no dependency, so they run at the same time. Wave 2 waits because it depends on both.
Once a project is fully scoped and the plan is locked in, wave planning is the process of grouping. Steps that are tightly linked get grouped into a phase. Phases that depend on each other get grouped into a wave.
Anything that does not depend on something else runs in parallel, inside the same wave.
What this depends on
None of this works without a plan. Wave planning is not a claim that an agent system can take a vague idea and run with it end to end. It depends entirely on the person initiating the project having full context: every workflow, every dependency, every edge case, thought through before execution starts.
That context gets written down, not kept in someone's head. A single plan
document, something like plan.md, lists every step and maps
out the dependency tree between them: what blocks what, what can run
independently, and what has to happen before something else can start.
Wave planning is the process of turning that dependency tree into phases
and waves. If the plan is wrong or incomplete, the grouping built on top
of it is wrong too.
This is also not a claim that the whole project runs itself. The person who owns the plan is still responsible for the parts that matter most: scoping the work correctly, catching what the dependency tree misses, and reviewing what comes out of each wave.
Validation gates
Each level has its own checkpoint.
A phase has a shallow validation gate: linting, type checks, the basics that confirm the code is structurally sound.
A wave has a deeper validation gate: does the business logic actually hold up across every phase in that wave.
Orchestration
A higher tier model, something like Opus, owns the orchestration layer. It plans the waves, sequences the phases inside each wave by dependency, then shells out each phase to a lower tier model running as a subagent.
Phases within the same wave run in parallel. The higher tier model is not writing the code itself. It is coordinating who writes what, when, and checking the result before the project moves to the next wave.
What this actually changes
This is not the same thing as one person writing code faster. Autocomplete and inline suggestions still leave the work sequential: one person moving through the same list of tasks a little quicker.
Wave planning changes the shape of the work itself. A project gets broken into independent units, and those units get executed at the same time by different agents, the same way you would add engineers to a team, except the coordination overhead that usually kills parallel work mostly disappears.
In practice, this has taken the execution phase of projects that would traditionally need around 600 hours of sequential, single person work, and brought it under 5 hours, given enough tokens and a plan that was already fully mapped out before execution started. The planning and review time is separate, and it is still where a person has to do the real thinking.
Not fewer people writing code. Fewer people needed just to plan, sequence, and validate work that used to require an entire team's calendar.
Where this fits
Sprints group work by time. Wave planning groups work by dependency, then executes everything without a dependency at the same time.
The traditional sprint model exists because a team has a fixed number of people and a fixed number of hours in a week. Once execution capacity stops being fixed that way, the planning structure has to change to actually take advantage of it. That is the problem wave planning is trying to solve.