A Forty-Nine-Hour Run That Did Not Ship

The loop ran for just over 49 hours. It completed 124 iterations, registered 313 findings, applied 40 fixes with regression checks, and classified 224 findings as noise or non-actionable. Its final composite score was 78.85 against a release threshold of 80, with zero task-level failures also required. The system did not release.

Neither the score nor the iteration count is impressive by itself. Both measure activity. The result that matters is that the acceptance rule survived a large amount of apparently productive work. If the threshold had moved because the run was expensive, it would have stopped being a threshold and become a retrospective justification.

Work moved through planning, harness design, implementation, static drift checks, regression verification, triage, review, and final audit. The worker that changed the code could report success, but it could not advance itself. The orchestrator reran checks and compared evidence with gates defined before implementation.

That split exists because a fluent worker can describe an incomplete change as done. Moving acceptance to an independently executed harness does not make the worker more accurate. It keeps an unsupported claim from becoming a merge. A loop that cannot fail after a confident completion report is not autonomous delivery.

Of 313 findings, 224 were rejected. Some came from turn limits that were too low for multi-step flows. Others came from missing test preconditions, repeated pilot mistakes, or friction that did not justify a change. An autonomous loop that fixes every finding will spend much of its time editing the product to satisfy its own simulation artifacts.

Human triage remained necessary because the evidence does not contain its own product judgment. A failed task can indicate a product defect, a harness defect, a missing feature, a bad test setup, or an acceptable tradeoff. Classification is the point at which organizational intent enters the loop. Without it, the system optimizes for the harness rather than for the product.

One iteration created a route that already existed under another group, broke the build, and generated seven downstream findings against its own regression. Another process overwrote a manual triage decision because two writers persisted the same state file without a lock. Several apparent abandonment failures were a fifteen-turn cap applied to flows that needed more than twenty-five turns.

Each incident produced a modest control: search before creating a route, use locked atomic state transitions, bootstrap real preconditions, and treat a sudden cluster of failures as a possible harness regression. Those controls matter more than a claim about replacing a team. They turn one observed failure into a rule the next run can inherit.

Autonomous delivery can sustain routine execution, gather evidence, and apply bounded fixes at a scale that changes how engineering time is spent. It does not make engineering judgment disappear. It concentrates that judgment where it is worth more: before work begins, during triage, and at the acceptance boundary.

A useful autonomy metric is therefore not the percentage of code written without a person. It is the percentage of accepted changes backed by independently reproducible gate evidence. Without that denominator, a high autonomy number says little about software quality.