Six numbers that tell you if a plan is any good

Validating a plan proves it can execute: no cycles, no empty task list, no two agents claiming the same file. That is a lower bar than it sounds, because a perfectly valid plan can still be a bad one — sequential where it could be parallel, or so wide that every wave is a merge conflict waiting to happen.

Quality is a separate question from validity, and it is also computable before anything runs. DevPilot's scorePlan produces six numbers:

parallelizationScore  Ratio of parallelizable work (0-1)
maxParallelism        Peak tasks in any wave
waveEfficiency        Average tasks per wave
dependencyDensity     How interconnected the DAG is
fileConflictScore     Ratio of conflict-free file references (0-1)
confidenceSignals     Quality indicators based on scores

What each one is actually telling you is more interesting than the definitions.

parallelizationScore — is this plan a queue in disguise

The ratio of work that can run in parallel. A score near zero means you have written a sequence and called it a plan; every task waits for the one before, and running it across ten agents will behave exactly like running it on one.

A low score is not automatically wrong — some work genuinely is sequential, and a database migration followed by a backfill followed by a cutover has a real order. But it should be a deliberate answer rather than a surprise. If you believed you were writing parallel work and this comes back at 0.2, the decomposition did not do what you thought.

maxParallelism and waveEfficiency — the shape, not just the size

maxParallelism is the peak: the widest wave. waveEfficiency is the average tasks per wave.

The gap between them is the diagnostic. Peak 8 with an average of 2 describes a plan with one enormous wave and a long thin tail — which means your concurrency limit has to be sized for a burst you experience once, and sits idle the rest of the run. Rebalancing to peak 4, average 3 finishes at a similar time with half the contention and half the review load per batch.

Peak and average close together is a smooth plan. That is usually the one you want, and it is invisible if you only look at the total task count.

dependencyDensity — how much the plan constrains itself

How interconnected the DAG is. High density means many edges relative to nodes: lots of "this needs that", which caps parallelism no matter how many agents you have, and lengthens the critical path.

High density often means the decomposition is too fine. Splitting a coherent piece of work into eight tasks that all depend on each other has produced overhead, not parallelism — you now have eight prompts, eight context loads and eight review surfaces to get one thing done.

fileConflictScore — the one that predicts painful merges

The ratio of file references that are conflict-free. Anything below 1.0 means two tasks in the same wave touch the same file.

This is the number to treat as near-binary. A conflict here is not a theoretical risk: it is two agents generating diffs against the same file, each individually plausible, which compose into something neither of them tested. And you find out at merge — the most expensive place, after both have spent their tokens.

The fix is declaring file ownership per task so the conflict is a plan-time error instead of a merge-time discovery.

confidenceSignals — the honest summary

Quality indicators derived from the other five. The value of a rolled-up signal is not that it is more accurate — it is strictly less information than the numbers underneath — but that it is the thing a human will actually read before approving a dispatch. Five numbers get skimmed. One flag gets noticed.

How to use these

The scores are most useful as a refusal threshold, not a report card.

Pick the two that map to your actual pain. If your problem is merge conflicts, gate on fileConflictScore at 1.0 and refuse to dispatch below it. If your problem is that parallelism never materialises, gate on parallelizationScore and send anything under a floor back for re-decomposition before it costs anything.

A score you look at after the fact is a metric. A score that blocks dispatch is a control, and only the second kind changes outcomes.

Reading them together

Individually each number is easy to over-react to. The combinations are what carry the diagnosis.

Low parallelization with low dependency density means the tasks are not actually connected — they just were not batched into waves that could run together. That is a scheduling fix and usually cheap.

Low parallelization with high dependency density is different: the work genuinely is a chain. No amount of wave rearrangement helps, and the only real lever is examining whether each dependency is as coarse as it looks. That is where the critical path earns its keep.

High parallelization with a file conflict below 1.0 is the dangerous one, because it looks like the best plan on the board. Wide waves and heavy overlap means many agents editing adjacent code simultaneously — maximum throughput on paper and maximum merge pain in practice.

Peak far above average, everything else healthy is a plan that will run fine and waste capacity. Worth rebalancing when convenient, not worth blocking.

What these numbers cannot tell you

They describe the shape of a plan, never its content. A plan can score perfectly — fully parallel, zero file conflicts, smooth waves — and be a decomposition of entirely the wrong work. Nothing here evaluates whether the tasks are the right tasks, whether the acceptance criteria are checkable, or whether the approach is sound.

That judgement is still human, and we have not found a way to make it otherwise. What these six numbers buy is that the human spends their attention on whether this is the right work rather than on manually tracing a dependency graph for cycles and collisions.