Step 1 of 4
Verify at the write boundary
The cheapest catch-point is the moment of the edit.
Implement write-time verification. On every file write or edit: run the appropriate fast check for the file type (python: compile/ruff; js/ts: esbuild parse or tsc; json/yaml: parse) within a second-scale budget; on failure, revert the write (or never apply it - validate a staged copy) and return the exact error with line numbers to the model as the tool result; on success, return a confirmation including the check that ran. Wire this into the edit tool itself so no write path skips it. Test with a deliberately broken edit and confirm the revert-and-teach cycle produces a corrected second attempt.
Expected after this step
Every write checked, failures reverted with teaching errors.
Should not happen
- ✕Trusting 'I have fixed the issue' without a single command being run
- ✕Lint-only verification that misses behavioral breakage
- ✕Verification output hidden from the model, so it cannot self-correct
- ✕Tests skipped 'for speed' exactly on the changes that needed them
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Trusting 'I have fixed the issue' without a single command being run
- !Lint-only verification that misses behavioral breakage
- !Verification output hidden from the model, so it cannot self-correct
- !Tests skipped 'for speed' exactly on the changes that needed them
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
Broken files still land on disk. Move validation before the apply: write to a temp copy, check it, then atomically swap - the working tree must never hold a state the model was told failed.