The Cure Is Cheap Because the Cause Is Close

Ron Reynolds · 2026-09-02 · 11 min read

Third in the QC series. Why fine-grained testing makes self-healing sustainable at scale.

Debugging is expensive because most of debugging is search.

Something is wrong. The symptom surfaces — a 500 in production, an off-by-one in a report, a silent corruption in a feed. The cause is somewhere in the substrate. Could be the function you just wrote. Could be a config that changed last week. Could be a library version that updated quietly. Could be the migration from two months ago that landed without anyone noticing the implicit assumption it broke.

The cost of finding the cause dwarfs the cost of fixing it. Most engineers spend most of their debugging time on root-cause analysis, and the fix, once located, is usually small. Locating it is the expensive part.

This is the structural reason coarse-grained testing fails at scale. Coarse tests tell you the system is broken. They do not tell you where or why or what to do. They surface the symptom and hand you a magnifying glass.

Fine-grained testing inverts this. The inversion is what makes self-healing sustainable across a codebase that runs at production scale, written by a mixed flock of human and machine contributors, sustained for years. The eight questions, as eight trim-tabs

QC — the two-station inspection regime we run across every ComOS repo — closes with an eight-question final inspection that fires whenever an agent claims a task is done. Each question runs against one specific channel of failure: Q1: Does my count match my list? (Recount from ground truth.) Q2: Did I test what I asserted, or did I assert it? (Match assertion strength to evidence strength.) Q3: Are my magic numbers justified at the call site? (Comment with rationale or link to decision.) Q4: Are my string-encoded keys schemaed? (One encoder, one decoder, never N callers composing inline.) Q5: What does my work NOT solve? (Write the limitations before the deliverables.) Q6: Does my verification floor match my claim? (Downgrade the claim if the test doesn't support it.) Q7: Is my framing honest about what I did? (Re-read the opening sentence. Sell what you built.) Q8: Did the verification's inputs come from reality, or from me? (Capture a real input; an invented fixture only agrees with you.)

Each question is fine-grained on purpose. None of them tests the system generically. Each tests one specific channel where the failure mode is well-defined and the cure is named.

That last property carries the whole design. Each question detects the flaw and prescribes the cure in the same motion. Q1 fails? Recount. The cure is in the question. Q3 fails? Justify the constant. The cure is in the question. Q4 fails? Write the encoder. The cure is in the question. Q8 fails? Capture a real input. The cure is in the question.

There is no separate root-cause analysis step. The test that failed is the root cause, named. There is no separate cure-design step. The question that detected the flaw also prescribes the action.

This is Fuller's trim-tab principle applied to debugging. A trim-tab is the small tab on the ship's rudder that steers the rudder that steers the ship — a tiny input at the right leverage point reorganizes the whole pattern. The eight questions are eight trim-tabs, each placed at the leverage point of one channel of failure. Small input, fast response, low cost. The cost difference: O(n) vs O(1) per flaw

Coarse-grained testing makes flaw-cure cost scale with the size of the substrate. Something in the system is wrong; where? The search is O(n) on the size of the codebase, the dependency tree, the team's mental model of what changed recently. As the substrate grows, the cost per flaw grows. Past a certain size, the rate of flaw-introduction exceeds the rate of flaw-cure, and the system rots under the weight of detected-but-uncured bugs.

Fine-grained QC testing collapses the cure cost to O(1) per flaw. Q4 failing localizes the flaw to one line in one file. The cure is named. The round-trip from detection to cure closes within the prompt that detected it.

That collapse is what allows continuous self-healing. If cure cost were O(n), the system would have to batch flaws, prioritize them, defer them — and deferred flaws compound. Because cure cost is O(1), healing can keep pace with flaw-introduction, paid in tiny increments as part of ordinary work.

And here is the part that surprises engineers who picture "healing" as a separate maintenance verb: there is no separate apply-the-cure step either. When an agent reads existing code to build on it, running the eight questions against what it reads is the same motion as understanding it well enough to use it. Observation and healing are one act. The agent isn't pausing production to audit; the audit is how the agent sees. Every read is a hunt, and the hunt is free because it's fused into the looking the agent had to do anyway.

Whether your corpus is actually getting cleaner with use is a measurable question, and the measurement is cheap: sweep an older sample and a newer sample for the same eight anti-patterns and compare the counts. The gate's design goal is that the newer sample wins. Run the sweep in your own repo before believing it about anyone's. Why fine grain is the precondition

You cannot get cheap cures without fine grain. The two properties are coupled.

If the gate were a single coarse question — is this work done correctly? — the cure cost would explode. A "no" answer would surface the symptom (not done correctly) without locating the cause or naming the action. The agent would then have to perform root-cause analysis as a separate cognitive step. RCA against a production-scale corpus is the expensive operation that coarse testing forces and fine testing avoids.

The eight questions work because they pre-decompose the failure space. Each question is fine enough that its failure mode is structurally unambiguous. Count drift is a category of failure with a known cure (recount). Magic numbers without rationale is a category of failure with a known cure (justify). Each question owns one cell of the failure space, and the cell is small enough that the cure is implied by the cell's identity.

The eight questions are a fine-grained decomposition of the failure space: every failure mode maps to exactly one question, and every question's failure prescribes its own cure. Build the decomposition right and the cure cost stays cheap forever.

This is also why adding a question to the gate has a high bar. A candidate has to demonstrate three things: it catches a failure mode that leaks through every existing question; it is geometrically distinct from every existing question; and its failure prescribes a cure as clean as the others do. Anything less is overlap with existing grain — it slows the gate without adding coverage. Q8 is the worked example of a question clearing that bar. The first seven test whether the work was executed correctly; every one can be answered honestly and still pass an artifact built on a wrong premise, because a verifier that shares its author's premise confirms itself. That failure mode leaks through all seven. It is geometrically distinct — premises, where the others test execution. And its cure is as clean as any: capture a real input before trusting the suite. What this means in practice

Three operational consequences of running the gate this way:

1. Maintenance is fused into production. There is no separate audit team, no separate QA pass, no separate code-review-as-quality-gate. The eight questions fire on every "done" event, which means quality is paid for at the per-prompt grain by the agent doing the work. The cost is small. The cost adds up to a corpus that holds shape at production scale.

2. Healing keeps pace with accumulation by construction. Every flaw surfaced is cured on the spot, because the cure is named the moment the flaw is found. Deferral — the mechanism by which codebases rot — has nothing to feed on.

3. New participants pay onboarding cost out of their own production cycle. When a new agent joins (human or machine), the artifacts they produce contain flaws — they have not yet absorbed the surrounding voice or convention. Those flaws are caught by the next agent who reads the work as part of normal production. The corrected artifact teaches the new participant by example. Onboarding is self-paid by the self-healing.

A lean operation running an AI flock can hold a corpus at production scale because the cost of maintaining quality is paid in tiny continuous increments by every participant rather than in large lumps by a dedicated maintenance team. That cost structure only works if the cure is cheap. The cure is cheap because the cause is close. The cause is close because the testing is fine-grained. Fine-grained testing is structurally what QC is.

The same cost structure is what lets the corpus grow without losing its grip. A maintenance model that scales with team headcount buckles as surface area grows — every new repo is new ground for an audit team that doesn't exist. This model scales the opposite way: each new repo is born inside the gate, and its flaws get cured at O(1) by the same continuous increments as everything else. You don't take on maintenance debt when you add a repo, because the cure was never deferred in the first place. The artifact, installable

The skill is open source. The canonical SKILL.md, the eight questions, the anti-pattern table, and installation guidance for any AI-assisted codebase live here:

https://github.com/ronrey/proof-before-done

If you want to test the claim, install the skill in a repo you already maintain. Run it on the next "done" event. Watch what the eight questions surface — what they catch, where the cure is named the moment the flaw is found, how the round-trip closes within the prompt. The cure being cheap is a property the artifact exhibits in your codebase the day you install it.

The article describes the pattern. The repo is the pattern. The conversion from one to the other is one git clone. The stealable line

When the test is fine-grained, the cure is named the moment the flaw is found.

Coarse tests detect; fine tests prescribe. The cost of cure tracks the grain of test. There is an old rule that names the consequence better than any cost analysis: you never borrow something without bringing it back better — sharpened, washed, fuel full. A shared substrate where every participant leaves it better than they found it appreciates without bound; one without that rule depreciates without bound. Every unverified "done" quietly erodes the work that came before it, and every gated one sharpens it. Same structure as the borrowed saw, different substrate. Next in the series: self-healing is search. Closing test

This article's central claim is that fine-grained per-channel testing collapses cure cost from O(n) (search for the cause) to O(1) (the failing question is the cause, named, with the cure implied) — and that this O(1) cure cost is the precondition for healing that keeps pace with flaw-introduction. [ ] Each of the eight questions prescribes its own cure, verifiable by reading the open-source SKILL: Q1→recount, Q3→justify-the-constant, Q4→write-the-encoder, Q5→write-the-boundary, Q8→capture-a-real-input. A question whose failure does not name an action would falsify the "cure is in the question" claim. [ ] The O(1) locality is demonstrable: install the skill, induce a Q4 failure (an inline-composed string key), and confirm the gate localizes the flaw to the specific call sites and names the cure (one encoder) without a separate root-cause-analysis step. [ ] The "cleaner with use" measurement is described honestly as a procedure the reader runs (older sample vs newer sample, same eight anti-patterns), never asserted as an accomplished fact. If this article ever states the comparison as a result without a recorded sweep, it has drifted from its claim.