01
test-driven development
also the outer loop of red-green-refactor
Write a failing test first, then make the implementation pass. The test is the spec. The code is fill.
What is test-driven development?
TDD is three beats: red (the test fails, so it is a real test), green (the smallest code that passes), refactor (clean up under a green bar). It is not “write more tests.” It is “the test arrives before the design.”
Why does test-driven development matter when vibe coding?
Models are completers. A prose brief gets you a neighbouring implementation. A failing test gives the model an objective function: turn red into green. Runnable, repeatable, hostile to hallucination.
How do you do test-driven development?
Write or dictate one example: input, output, failure message. Have the model write only the test. You run it and confirm red. New turn: “Production code only. Make this test green. Do not edit the test.” Refactor after green.
How do you ask a model for test-driven development?
Write one failing test for (example). No implementation. I will confirm red, then you may edit production code only. Do not edit the test to make it pass.
What goes wrong with test-driven development?
Asking the model to “write the tests too” in the same turn. It will write green tests that assert the code it just invented. That is a prize-giving, not a driver.