Kasuri

Chapter 14 · Part III — The platform

The compiler as reviewer

When machines write the code, human review cannot absorb the volume. The compiler becomes the reviewer of first resort — which changes what a diagnostic has to be.

Audience
Engineering leadership, technical assurance
Chapter
14 of 21

Eyes are the scarcest resource in an AI-authored pipeline. Chapter 3 argued that review cannot absorb machine-paced change and that automated monitors good enough to catch most problems produce more false alarms than any organisation can work through. If review is not the control, something else has to be — and the only candidate that scales is the checker.

Section 01The lever is measured, and it is large

The evidence that this works is better than most claims in language design. In one study, a frontier model working in a language it barely knew solved 22 of 56 exercises unaided, and 54 of 56 when it could iterate against compiler feedback.[12] That is the difference between an unusable tool and a usable one, produced not by a better model but by a better conversation with the compiler.

A second study isolated which part of the feedback did the work: a controlled ablation found that diagnostics carrying the location, the observed value, and the admissible alternatives improved repair success by 42 to 44 percentage points, while the serialisation format made no measurable difference.[13] Content, not packaging.

We treat the second result carefully: it was measured on non-code repair tasks with smaller models. We call it strong directional evidence and we intend to replicate it on code, on our own benchmark, before anything freezes. Saying so is cheaper than being corrected later.

Section 02A diagnostic is a protocol, not a sentence

If a diagnostic is the primary channel through which a machine author learns, then it is an interface and has to be designed as one. In this design a diagnostic carries:

  • A stable code, allocated once and never reused. Codes are append-only forever — a code that changed meaning between versions would poison every corpus that learned it.
  • An anchored location that survives reformatting, so a fix plan does not go stale because something above it moved.
  • The observed value — what the checker actually saw, not a restatement of the rule.
  • The admissible alternatives — a closed, enumerable set of what would have been accepted here. This is the field the ablation identified as doing the work, and it is the one that constrains the whole type system: you can only enumerate valid alternatives if the language's candidate sets are closed and queryable.
  • A machine-applicable fix plan, expressed as edits, in a closed operator set — so an agent can apply it without re-deriving intent, and a harness can verify the repaired program.

That last constraint deserves its own note: the program a fix plan describes must be one the checker accepts. We wrote that rule down because we broke it. A bridging diagnostic in an early design told the author to make two edits, and the result parsed as something else entirely and was silently accepted. A partial repair in a bridge is worse than no bridge, because it teaches the author a wrong thing that works.

Section 03The obligation this creates

Because the ledger in Chapter 12 prices a restriction at zero only when the toolchain can report it properly, the diagnostic scheme is not documentation — it is the thing that makes the design affordable. A rule without a real diagnostic forfeits its discount and becomes a cost we have no headroom for.

That converts a nice-to-have into an accounting obligation, which is the only reason we believe it will survive contact with a schedule. It is also why the diagnostic registry is one of the most heavily instrumented artifacts in the repository: it currently holds 101 rows, of which 63 carry a fully worked render, and the gap between those two numbers is tracked rather than rounded off.

Section 04Wider grammar, sharper rules

A design consequence worth stating because it is counter-intuitive: the grammar is deliberately wider than the rules.

If a mistake is a parse error, the author gets a message from the parser, which knows nothing about intent and cannot enumerate alternatives. If the grammar admits the wrong form and a rule rejects it, the author gets a diagnostic with an observed value, an admissible set, and a fix plan. So the language accepts more than it permits, on purpose, and the extra acceptance exists solely so that a good diagnostic has somewhere to fire.

The reverse is a real failure we have already hit twice in design: narrowing a production to make something impossible destroyed the diagnostic that made it explicable.

Section 05What the compiler cannot do

Boundaries

A checker cannot tell you the program is correct. It can tell you which classes of wrongness are absent. Nothing here removes the need to specify what the software should do, which is why the intent layer exists and why Chapter 17 reports that its measured benefit was much smaller than expected.

Enforcement status is not conformance status. A rule that is specified but not yet checked is still normative, and a rule that is checked is not thereby more true. We report those two numbers separately and refuse to conflate them, because conflating them is the easiest way to overstate a language's guarantees.

None of this has been measured on Kasuri. The 22-to-54 result is somebody else's language. Reproducing that lever on our own diagnostics, with an ablation that could show no effect, is the central experiment of the next phase — and it has not been run.