Tests are the only fixed point left when the implementation is disposable

In the age of disposable implementations, tests have emerged as the single constant point. When working with AI coding tools, the same feature is rewritten repeatedly throughout the day. The spec, which dictates correctness, is not replaced by the rewritten code; instead, it is the tests, types, and checks in hooks that serve as the guiding force.

The guidelines for CLAUDE.md, sourced from the Claude Code documentation, emphasize that what will be learned is the importance of not treating instructions as a fixed point. Instructions cannot be relied upon as a constant reference point. The line between advisory and failing the build is clear when tests, types, or hooks in the form of hooks become the fixed point.

Instructions may shape what Claude tries to do, but they do not alter what Claude Code allows. A fixed point is anything that can fail, and it is the per-event hook behavior that makes this line explicit. When a machine can fail, that becomes the fixed point. Hooks such as Stop can be used to prevent Claude from stopping the conversation, allowing a test suite to run and exit with an exit code of 2 if the tests fail.

This turns the request "don't report done while tests fail" into a mechanism. The importance of creating verification targets cannot be overstated. By including test cases, screenshots, or defining expected output in the prompt, Claude can verify its own work and catch issues before they become a problem. This is not an endorsement for test-first development, but rather a way to avoid wasting tokens.

The demand is the same: fix the expected value first. This reasoning aligns with the case for plan mode, which aims to prevent expensive re-work when the initial direction is incorrect. The structure of the site itself enforces this principle, with every article requiring lint and build scripts to pass before publication. The promise you want kept must be shaped so it can fail.

Reviewing a pull request diff no longer holds the same weight, as each rewrite replaces the diff wholesale. Turning review output into something that fails becomes an essential part of the review process. However, the claim does have its limitations. When AI writes the tests themselves, the fixed point is limited to the human-decided part of the implementation.

Tests generated afterwards only serve as a regression net, not the spec of record. Certain domains, such as visual appearance, perceived performance, accessibility, and security posture, cannot be expressed through tests. Building a different fixed point, such as screenshot comparisons, benchmark thresholds, or an audit checklist, is necessary in these cases.

Lastly, the cost of implementing a fixed point must be considered. Tests in legacy codebases with no test infrastructure are expensive, and a throwaway prototype may never recover that investment. Making the decision to build one must be made deliberately and not overlooked.