We do not evaluate anyone by what they built.

Four dimensions, each scored 1 to 5 against written behavioural anchors so that two reviewers watching the same tape land on the same number. The Orchestration Index is the sum, normalised to 100. Nothing here rewards typing speed, and nothing here cares which model you used.

Only 1, 3 and 5 are anchored. Anchoring all five makes two reviewers agree less, not more, because it forces them to invent distinctions that are not there.

Equal weights until there is enough data to calibrate them. When that changes, the change and the reason will be published — a score whose formula moves quietly is worthless.

01 / 4

Spec

How the problem is decomposed before a line is written.

Minutes elapsed before the first prompt · whether acceptance criteria exist in writing · how many assumptions are named out loud.

1: No plan. First prompt inside two minutes. Acceptance criteria never written down anywhere.
2: In between
3: A plan exists but stays in their head. Assumptions surface only when something breaks.
4: In between
5: Acceptance criteria written before the first prompt. Assumptions named, and the riskiest one checked first.

02 / 4

Delegation

What goes to the model, and what deliberately does not.

Size of each change requested · whether the split follows risk or file boundaries · what they choose to write by hand.

1: One prompt for the entire feature — or the opposite, everything typed by hand while the model sits idle.
2: In between
3: Sensible batches, but the split follows file boundaries rather than where being wrong is expensive.
4: In between
5: Deliberate split: the model takes the mechanical and well-specified, the human keeps the decisions that are costly to get wrong.

03 / 4

Review

What gets rejected from the model output, and how early.

Outputs discarded before execution · errors caught by reading rather than by running · whether the rejection is explained.

1: Output accepted and run without reading it. Errors are found by the runtime.
2: In between
3: Reads the diff and catches the obvious. Plausible-looking wrong behaviour gets through.
4: In between
5: Rejects before running. Catches the plausible-but-wrong and says why — which is what makes it repeatable next time.

04 / 4

Recovery

Time from a wrong turn to a green test suite run.

Minutes between the first serious failure and green · whether the second attempt changes the input or only the wording.

1: Repeats the same prompt with different words. No new information enters the loop.
2: In between
3: Changes approach after several attempts. Recovers, but without isolating what actually went wrong.
4: In between
5: Stops on the second failure, isolates the cause, and changes what the model is given rather than how it is phrased. Back to green fast, and the fix explains itself.

What invalidates a session

A cut, a pause, or a gap in the recording. One person, full-screen capture, unbroken.
Cropping only the code editor instead of sharing full screen (reviewers need to observe your full AI agent & terminal interaction).
Making multiple trial-and-error git pushes (only ONE SINGLE git push is permitted when you consider the solution ready).
Work committed after the 45-minute clock expired — repository timestamps settle this.
A pull request whose acceptance run was made green by weakening or editing the test suite.

Ready to test your judgment?

Choose a weekly drill, record your full-screen session, and earn your Orchestration Index.

Put it to the test