Method

The loop

specify → implement → inspect → challenge → test against evidence → ship

The system, its constraints, and its failure conditions are specified before anything is implemented. Nothing ships on the strength of implementation alone — it has to clear “test against evidence” first, and that stage is specific to what the system is: a backtest for a model, a browser check for a fallback path, a hardware run for anything touching physical equipment.

I use coding agents for implementation and adversarial review. I define the system, constraints, and failure conditions; inspect the resulting changes; and verify behavior with the appropriate evidence — tests, backtests, browser audits, source checks, or real hardware. A second model is useful because disagreement produces things to test. Agreement is not evidence. Every technical claim published here is one I have checked and can defend.

Where this shows up

• golfcoach

  Simulator directories are treated as read-only. That invariant is covered by tests rather than left to discipline, and it has been checked twice against the actual hardware.

  → read the case

• Megatron

  Reported accuracy comes from walk-forward evaluation on held-out seasons the model never trained on, not from a favorable training run.

  → read the case

• all:Lo

  Audio behavior, navigation persistence across routes, reduced motion, and the absence of WebGL are four separate acceptance conditions, each checked directly rather than inferred from reading the fallback code.

  → read the case

Implementation currently runs through a coding agent — a Claude model, at present. That detail is replaceable: the loop above does not depend on which model does the typing, and none of the verification steps it describes are optional because of who or what wrote the code.