Critical path: the floor on how fast a plan can finish

The critical path is the longest chain of dependent tasks through a plan. It is the minimum time the plan can take even with unlimited parallelism — no number of agents shortens it, because each task on the chain waits for the one before.

How it is computed

DevPilot derives it with topological-sort-based dynamic programming: a forward pass computing each task's distance from the start, a backtrack from the furthest terminal node to recover the path, and a backward pass computing each task's distance to the end.

The third number falls out of the first two:

slack = (totalLength - 1) - (distFromRoot + distToEnd)

Slack, and why it decides where to spend effort

A task with zero slack is on the critical path. Delay it and the whole plan slips by the same amount.

A task with slack can start later — or run slower — at no cost to the finish time. Speeding it up buys nothing at all.

This is the mechanism behind the most common disappointment in multi-agent work: adding agents widens waves full of tasks that already had slack, while the chain that actually determines the finish time is untouched. The longer argument works through what to do instead.

Where it differs from waves

A wave plan is about coherence — a barrier producing a reviewable state between batches. The critical path is about the theoretical floor. A barrier can only make a plan slower than its critical path, never faster, so the two never compete; they answer different questions.

Not a schedule

The critical path tells you the floor, not the plan. It says nothing about whether the tasks are correct, whether the dependencies are real, or whether the decomposition was sensible. A dependency that exists only because somebody wrote it down is still on the path, and removing it is usually the largest available win — which requires judgement rather than computation.