Test-driven development (TDD)
Write the failing test first, then just enough code to make it pass, then clean up. Red, green, refactor, repeat in tiny loops.
See it
What it is
TDD inverts the usual order: you write a test that fails, write the smallest amount of code that makes it pass, then clean up with the test holding you steady. That loop is red, green, refactor, popularized by Kent Beck as part of Extreme Programming. The cycles are meant to be tiny, minutes not hours, so at every moment you are either one test away from working or one undo away from working.
It pays off best where the answer is checkable in code: parsers, pricing and tax rules, date math, permission checks, state machines, anything with a pile of branches. Bug fixing is the easiest place to start, since writing the failing reproduction first proves you actually understand the bug and leaves a regression test behind for free. It pays off worst when you do not yet know what you want, which is most exploratory UI work: spike it first, throw the spike away, then TDD the logic you extracted.
The traps: a test that passes the first time you run it is not red, so you have proven nothing and may have tested nothing (always watch it fail, and check it fails for the reason you expect). Skipping the refactor step turns TDD into a machine for producing awkward code with great coverage. And mocking every collaborator gives you tests that verify your mocks agree with each other, which is the classic way for a green suite to sit on top of a broken app.
Ask AI for it
Build [FEATURE] using strict test-driven development. Run all the red-green-refactor cycles you need autonomously, and do not stop to ask between them. For each cycle: (1) write exactly one failing test for the next smallest behavior, using arrange-act-assert and a name that states the behavior; (2) run it and record the failure output, confirming it fails for the expected reason; (3) write the minimum code to make it pass, no extra features or speculative abstraction; (4) run the whole suite and record that it is green; (5) refactor only if there is real duplication, keeping the suite green. Finish when every stated acceptance criterion is covered by a test, then give me the cycle-by-cycle log: failing test, minimal implementation, passing suite. Do not write implementation code ahead of a failing test, and do not mock anything you own.