Place checks by feedback cost
Keep fast feedback near edits and place expensive checks at explicit later gates.
These examples and illustrative results are independently authored teaching materials, not measured model results.
Use case
A UI change needs types, interaction/accessibility and slower mutation checks, with different evidence/cost. Arrange fast feedback plus final gates rather than running everything per keystroke and switching off slow checks.
Mechanism
Identify target, actual cost and lifecycle placement per check. Use affected fast checks near edits, relevant behavior tests at task completion and agreed expensive checks at preview/CI. Reuse revision/scope-matched evidence; recheck related changes/new failures. Deferred checks retain explicit gates and outcomes.
Bad example
Run every repository check after each text edit, then disable slow browser/mutation checks while still claiming all gates passed.
Good example
Measure/check teaching costs and targets. Run affected type/static checks after edits, interactions at task end and accessibility/slower mutation at explicit preview/CI gates. Report results, reuse valid matching evidence and recheck affected changes/failures. Deferred checks remain pending rather than passed.
Why the change matters
Nearby feedback localizes failures, while expensive repetitive gates invite bypass. Cost-aware placement with final acceptance improves iteration without silently reducing requirements.
Observable expectation
An illustrative table records check, coverage, phase, measured/estimated cost and state. Fast passes cover fast checks only; completion still requires agreed slow results.
Inspect retained gates, honest costs and matched reuse evidence. Type success does not imply browser success.
Limits
Source five-second/90-second budgets and commands are workflow choices, not universal guarantees. Costs vary; critical checks may need earlier execution. Slowness alone cannot justify omission.