The scoring rule, printed from the code that runs it.

How much your opening brief reads as a spec — structured, sized like one, and complete enough that plans survive without a rewrite.

Questions read

• plans that survived without a rewrite
• structural signals present in your briefs
• median opening brief
• turns that instruct rather than patch

Bands

Bands are the grader’s instrument. The report shows the axis figure — the higher of the grade and the cohort rank — not the band.

• absent · 0–19

  The opening turn is a fragment: a phrase or a sentence, no structure, no statement of what done means. Plans built from these briefs come back for rewrite, or the session proceeds by watching the agent guess and patching it turn by turn.

• emerging · 20–44

  Briefs are prose that describes a goal without bounding it. Structure appears occasionally. The conditionals bite: unresolved referents produce objections, hedged asks get dropped, multi-part asks lose parts. This person discovers the requirement by watching the agent get it wrong.

• competent · 45–69

  The opening brief usually states what is wanted with enough context to act on it: the relevant area named, the outcome described, constraints mentioned where they exist. Structure appears in the briefs that need it. Plans mostly survive without a rewrite and most turns instruct rather than patch. A developer who writes a real request and then corrects the details — ordinary competent practice.

• strong · 70–89

  Briefs read as specifications: structured, sized like one, complete enough that the plans built from them come back essentially intact. The conditionals are quiet — few unresolved referents, hedges resolved rather than dropped, multi-part asks surviving whole. Work is specified up front rather than discovered.

• exceptional · 90–100

  Everything in strong, plus briefs that close an ambiguity before it opens: naming the alternative approach and rejecting it, defining done in testable terms, stating what is deliberately out of scope. The plans they produce need no clarifying round at all.

How often a session starts with a written plan, and how substantial and structured those plans are.

Questions read

• sessions that planned before building
• median plan length
• structural markers per 1,000 chars of plan
• edits made under an approved plan
• sessions that decomposed before building
• steps in the opening task list
• steps reaching completed

Bands

Bands are the grader’s instrument. The report shows the axis figure — the higher of the grade and the cohort rank — not the band.

• absent · 0–19

  Sessions open straight into edits. No plan artifact of any kind anywhere in the corpus — no plan mode, no plan document on disk, no task list — or exactly one in a corpus large enough that one reads as an accident.

• emerging · 20–44

  Plans appear in a minority of sessions and are thin when they do: a few lines restating the request, or a task list whose steps are the request's own phrasing chopped into pieces. What exists does not visibly govern the work — edits wander outside it, or the list is written once and never touched again. Planning is what this person does when a task feels frightening, not as a matter of course.

• competent · 45–69

  A meaningful share of sessions open with something written before the first edit, and those artifacts are navigable: headings or numbered steps, specific files and components named, enough substance that another person could work from them. The plan mostly governs what follows. This is the developer who plans the non-trivial work and dives into the trivial work — which is correct behaviour, not a shortfall.

• strong · 70–89

  Planning is habitual rather than situational: the spread across sessions is tight, not a few heavily-planned sessions carrying a mass of unplanned ones. Plans decompose the work into parts that map to real files and real decisions, and they hold — coverage is high, survival is high, rewrites are rare. They read as working documents rather than ceremony.

• exceptional · 90–100

  Everything in strong, plus plans doing work the counters cannot see: anticipating the failure that would otherwise have happened, naming what is deliberately out of scope, or settling a design question before the first edit rather than discovering it mid-run. A plan that names the alternative it rejected and why.

How you correct the agent mid-run — early, short, decisive corrections score higher than late rewrites.

Questions read

• corrections landing in the front half of a session
• words the median correction stays under
• corrections per turn you type
• plan objections per session

Bands

Bands are the grader’s instrument. The report shows the axis figure — the higher of the grade and the cohort rank — not the band.

• absent · 0–19

  The agent runs uncorrected, and not because it was right: the corpus shows the rework, churn and restarts that a correction would have prevented. Or corrections exist but land only at the very end, after the work they invalidate. No evidence this person watched the run.

• emerging · 20–44

  Corrections happen, but late and long. The typical one lands in the back half of a session and takes many words to say what went wrong, which usually means the person was reconstructing the problem rather than recognising it. Where objections are measurable, they are rare. The pattern is "let it finish, then fix," and it costs rewrites.

• competent · 45–69

  Corrections land through the session rather than piling up at the end, and the typical one is short enough to read as recognition rather than reconstruction. This person redirects when the run goes off course and lets it run when it does not. Ordinary attentive steering.

• strong · 70–89

  Corrections land early and stay short: the median sits in the front half and is brief and specific, naming the thing to change rather than reporting that something is wrong. Where measurable, objections against a plan before any file was written appear regularly — the cheapest correction available. Frequency is moderate rather than constant.

• exceptional · 90–100

  Everything in strong, plus corrections that read as design decisions rather than error reports: "do it as a migration instead" rather than "no that's wrong." The correction rate falls across the corpus as the briefs improve, which is the trajectory of someone learning what to specify up front.

How much you run in parallel — sub-agents launched and tool calls in flight at once, instead of one thing at a time.

Questions read

• peak tool calls in flight at once
• sub-agent runs per turn you type
• share of tool calls that were delegated

Bands

Bands are the grader’s instrument. The report shows the axis figure — the higher of the grade and the cohort rank — not the band.

• absent · 0–19

  Works strictly one thing at a time. Tool calls go out singly and finish before the next is issued; the peak in flight stays at one or two across the whole corpus, including sessions with heavy tool use. No sub-agent was ever launched, or exactly one was, in a corpus large enough that one reads as an accident. Where delegation is not measurable, this band requires the parallelism evidence to be flat on its own.

• emerging · 20–44

  Occasional bursts of parallel calls, usually reads and searches fired together while orienting, then back to serial for the work itself. Sub-agents appear in a minority of sessions and often on work that was not actually independent — the delegation calibration shows rework at or above the no-delegation rate. Fan-out is a reflex in one narrow situation rather than a habit.

• competent · 45–69

  Parallel calls are routine wherever the work allows it: batches of reads, searches and independent edits go out together instead of queueing. Sub-agents appear regularly and are pointed at genuinely separable work, with a delegation calibration that is neutral or mildly favourable. A developer who has internalised that independent work should not wait in line lands here.

• strong · 70–89

  Fan-out is the default posture, and the corpus shows judgment about when not to use it: serial stretches appear where the work was genuinely dependent rather than everywhere. Delegation is frequent and the calibration is clearly favourable — sessions that delegated show less rework, not more. Peak in-flight sits high across most sessions rather than spiking in a few.

• exceptional · 90–100

  Everything in strong, plus evidence that the orchestration was designed: the independent parts were identified before the fan-out, sub-agents got scoped briefs rather than open goals, and the tool error rate stayed low despite the volume. High parallelism paired with a high error or rework rate is not this band.

The care in what you ship, on two fronts: whether your plans and briefs show you thinking about the person who'll use it — users, flows, states, experience — and the technical craft of the diff: no long functions, thin wrappers, duplicated lines, oversized files, or churned code.

Questions read

• added functions staying under 10 lines
• added functions called more than once
• added lines that repeat nothing already there
• added lines that survived the session
• touched files left under 500 lines

Bands

Bands are the grader’s instrument. The report shows the axis figure — the higher of the grade and the cohort rank — not the band.

• absent · 0–19

  The diff shows no restraint: long functions, functions declared once and called once, added lines repeating lines added moments earlier, files sprawling past readability, and code added and removed inside the same session at high rates. The artifacts are purely mechanical — a file, a function, a library, and nothing about who any of it is for.

• emerging · 20–44

  Craft is inconsistent: tight code alongside long functions and thin wrappers, noticeable duplication and churn. A user or a flow surfaces occasionally, but as garnish — appended to justify a mechanism that was already settled, never as the thing the mechanism was derived from. The reasoning still starts at the code.

• competent · 45–69

  The diff holds up to ordinary review: functions mostly short, mostly reused, little duplication, most added code surviving the session, files staying readable. The artifacts name the user's situation where it is relevant — the flow being changed, the state someone would hit, what happens on error. The reasoning runs both directions: sometimes from the requirement down, sometimes from the mechanism up. The ordinary careful developer.

• strong · 70–89

  The diff is tight across sessions rather than in the good ones: reuse is habitual, duplication near-absent, churn low, files bounded. And the artifacts routinely start from the user — the brief opens with who needs this and what they are trying to do, the plan is sequenced by the flow rather than by the module list, and the technical decisions read as consequences of that rather than as decisions decorated with it afterwards.

• exceptional · 90–100

  Everything in strong, plus working backwards so consistently that the mechanism reads as a consequence: states and edge cases named as user situations before any code exists, requirements stated as what the person can now do, and a brief that catches the edge case before the code that would have missed it. A corpus that is technically immaculate and never works backwards from anyone is strong at most, never this band.

How much code you ship — the volume of change your sessions produce, measured per turn you type so it reflects throughput rather than task size.

Questions read

• lines changed per turn you type
• files touched per session

Bands

Bands are the grader’s instrument. The report shows the axis figure — the higher of the grade and the cohort rank — not the band.

• absent · 0–19

  Sessions produce almost no change: a handful of lines across many turns, one or two files. The corpus is reading and discussion rather than shipping.

• emerging · 20–44

  Real but light output. Each turn produces a small increment and sessions touch few files. Or volume exists and churn eats most of it, so the surviving change is small.

• competent · 45–69

  Sessions produce substantive, surviving change at a steady rate: meaningful diffs per turn typed, several files per session, churn low enough that the volume is work rather than rework. Ordinary productive development.

• strong · 70–89

  High output per turn sustained across sessions and across many files, with churn staying low. This person gets a lot done per thing they type and the change survives. Read the churn rate before granting this band — volume with high churn is rework and belongs in emerging.

• exceptional · 90–100

  Everything in strong at a level the corpus makes obvious, with the diff evidence showing authored work rather than generated, vendored or mechanical change. This is the axis most easily inflated by a large task rather than a fast developer; when in doubt, competent.