How to Stand Up a Work Class

27.1 The Sequence #

Step 1. Write the class definition. Name, scope boundary, the change shapes it covers, and the change shapes it explicitly does not. A class defined as “refactoring” is not a class. A class defined as “extract-method refactorings within a single module, no public interface change, no dependency change” is one you can build an oracle for.

Step 2. Demonstrate the oracle before anything else. Run Section 24 to completion, including the immutability test where you attempt a write from a test agent and confirm failure. A class without a demonstrated oracle cannot exceed A1, and this is the step organizations skip because the tooling works without it.

Step 3. Set entry conditions. What must be true of a work item before an agent may be dispatched against it. Typically: a complete specification per Section 26, a change-size bound, a path restriction, and a repository whose test suite passes at head. Entry conditions are enforced at dispatch, not documented in a wiki.

Step 4. Choose guards for the known failure mode. Every class has one, and it is usually published. Section 27.3 gives four worked examples. A guard is an automated check specific to the way this class goes wrong, and it runs in addition to the oracle.

Step 5. Model the review cost and fund it. Estimate reviewer hours per accepted change, multiply by projected volume, and compare against available senior engineering hours. If the answer exceeds capacity, the class does not launch at that volume. Every published deployment at scale independently discovered that review throughput rather than agent capability is the binding constraint, and one report measured 16.5 review comments per merged agent pull request against 12.4 for human ones.¹⁰⁵

Step 6. Define stop conditions that halt. Not alert. Halt. Typical set: merge rate below a floor, revert rate above a ceiling, review backlog beyond N days, oracle modification attempt detected, visible-to-held-out gap beyond threshold, cost per accepted change beyond budget.

Step 7. Pilot with a termination decision scheduled. Two to four weeks, one team, bounded repositories, full instrumentation, and a date on which someone decides to graduate, extend, or kill it. A pilot without a scheduled decision becomes production by default.

Step 8. Set the baseline before you compare. Measure human merge rate, revert rate, and review cost in the same repositories first. Agent performance is meaningless without it: one enterprise report puts agent merge rate at 67.9 percent against 87.1 percent for employees and 79.7 percent for community contributors in the same repository.¹⁰⁵ Without that denominator, 67.9 percent reads as either impressive or alarming depending on the reader’s priors.

Step 9. Graduate on evidence, at a named authority. Section 19.4 is the gate. Graduation raises the tier, widens scope, or both, and it requires operating evidence rather than absence of complaint.

27.2 Setting Expectations Before the Pilot #

Two variables explain more outcome variance than tool choice, and both are knowable in advance. Set expectations from them or the pilot will be read as a verdict on the tool.

Language. One enterprise test-generation system reports viable-test rates of roughly 80 percent for Python, 40 percent for Go, and 20 percent for Java, on the same tool in the same monorepo.¹²³ Security pass rates for generated code show the same shape at 62 percent for Python against 29 percent for Java.¹⁵

Codebase age. Greenfield beats brownfield measurably, at 77.3 percent against 67.9 percent in one organization, and an independent evaluation of an autonomous agent scored zero for four on modifying existing projects.^105,122

Write the expected range into the pilot plan before it runs. A Java brownfield pilot that lands at 45 percent is performing about as the evidence predicts; the same number in a Python greenfield repository is a problem.

27.3 Guards by Class #

27.4 Worked: Standing Up Flaky-Test Repair #

Definition. Repair of tests identified as flaky by the existing detection pipeline, in Go, within services/*, excluding tests touching payment paths.

Oracle. Reproduction of the flake under repeated execution, then repeated passes after repair, at a defined run count. Independent because the reproduction harness is platform-owned. Immutable because test files are outside agent write scope for everything except the target test, and the target test’s assertion count is checked separately.

Entry conditions. The flake is reproducible by the harness; the test is under fifty lines; the owning team has opted in.

Guards. Assertion count must not decrease. A semantic diff flags any change to assertion expressions for mandatory human review. The repaired test must still fail against a mutant that the original test killed.

Review cost. From the published deployment, plan against roughly 17.7 percent end-to-end yield: of 1,115 reported flaky tests, 71.6 percent reproduced, fixes were produced for 47.6 percent of those, and 51.8 percent of generated fixes were accepted and landed.¹⁶¹ Budget review against the fixes produced, not the fixes accepted. A team planning against 51.8 percent will under-provision review by roughly a factor of three.

Stop conditions. Acceptance below 35 percent over two weeks. Any assertion-removal guard trip. Reviewer backlog above five working days.

Pilot. Four weeks, one team, decision date on the calendar, baseline measured first.

27.5 Instrumentation #

• Merge, revert, and defect-escape rate by class, against the per-language and per-repository baseline from step 8
• Declared review cost against measured review hours
• Guard trip rate by guard, with every trip reviewed
• Cost per accepted change
• Classes throttled or tier-reduced on evidence in the trailing year, where zero indicates a register rather than a control

27.6 Failure Signatures #

• The class that has never been throttled. It will saturate review eventually. A register in which nothing has ever been reduced is a list.
• Acceptance rate quoted as yield. The single most common planning error in this literature. Plan the funnel.
• Pilot without a baseline. Produces a number nobody can interpret, and the interpretation defaults to whoever is most invested.
• Guards deferred to phase two. The failure mode each guard addresses is published in advance. Launching without them is choosing to discover a known problem in production.

27.7 What This Rests On #

The review-cost constraint, the language and codebase-age effects, the per-class failure modes, and the flaky-test funnel are all measured.^{105,123,15,122,170,161,64,163,164,167} The nine-step sequence and the pilot structure are this framework’s construction.