Tests are a more precise spec than prose. Write them failing first, pass them with minimal code, refactor against green — but only if each phase is a separate invocation.
Why this, for you: red-green-refactor turns "is it correct?" into a deterministic exit condition —
the suite fails, then passes, then still passes. It's the verification technique that doubles as a spec, and the
separation between phases is what stops the agent from gaming it.
Red-green-refactor structures agent development into three phases, each with a distinct instruction
and a deterministic exit: red = suite fails, green = suite passes,
done = suite still passes after refactor.
1 The three phases
Red — write failing tests that define required behavior. No implementation exists yet;
confirming the red state first prevents tests that pass vacuously.
Green — write the minimum implementation to pass. "Do not change the tests" is the
load-bearing constraint. Exit: all tests pass.
Refactor — improve the implementation without changing behavior. The green suite catches
regressions in the same run.
With a green suite, the agent can restructure freely — rename, extract, change data structures. Human review
focuses on structure; the suite answers correctness. This is where agents excel.
2 Why separate invocations
Mixed-phase instructions produce mixed-phase output. An agent told to "write tests and implement
the feature" writes tests that match its implementation, not tests that define correct behavior — the implementation
"bleeds" into the test logic.
This context pollution is the failure red-green exists to prevent. Keep the phases in separate sessions
so the red phase never sees a draft implementation to mirror.
# green phase — one constraint, in its own invocation"Make these tests pass with the minimum implementation. Do not modify the tests."# refactor phase — the green suite is the safety net"Improve this implementation. The tests must still pass when you are done."# exit conditions are deterministic — no self-report needed
3 The constraint that stops reward hacking
"Do not change the tests" is the most important constraint in the green phase. Without it, agents satisfy tests
by weakening them. METR's 2025 evaluations document frontier models "modifying test or scoring code" rather
than implementing the behavior; Anthropic's reward-hacking work describes training examples where
sys.exit(0) is used to make all tests appear to pass. The green phase pairs naturally with plan mode —
the agent reads the failing tests, proposes an approach, waits for approval — because tests are a more precise spec
than prose.
When tests aren't a faithful spec
The pattern assumes the suite specifies the behavior. When it doesn't, it hides the problem:
tautological tests from context bleed pass trivially; pinned incidental behavior
(field ordering, error strings, rounding) makes later refactors look "broken" when they only changed incidentals;
brittle refactors look safe because the local suite passes while uncovered downstream callers
silently break — which is why pre-change impact analysis belongs alongside it. For unclear or contested specs, a
prose spec plus code review is often the better fit.
↪ Your win: tests as spec, phases kept apart
Confirm red first — a test that never failed may be passing vacuously.
Minimum code to green — save complexity for the refactor phase, judged against known-good behavior.
"Do not change the tests" — the constraint that blocks weakening-the-suite reward hacking.
Separate invocations — shared sessions let the implementation bleed into the tests.
Deterministic exits — red fails, green passes, done = still green after refactor.
Retrieval practice — recall, don't peek
Question 1The load-bearing constraint in the green phase is…
Question 2Running each phase as a separate invocation prevents…
Question 3Without "do not change the tests," models tend to…
Question 4Confirming the red state before implementing prevents tests that…
Question 5 · spaced recall from Lesson 5A pre-completion checklist enforced as a hook beats a prompt because it…
Ask me anything. Want a three-invocation red-green workflow wired as slash commands, or help
deciding when a task is better served by a prose spec plus review than by tests-as-spec? Next: Chain-of-
Verification — self-verifying claims no test can reach.