Add "Red/Green TDD" to Your AI Coding Prompts

Ask a coding agent to build a function, and it writes the function, then writes tests that match whatever it just built. Every test passes. Your coverage number looks great. None of it tells you whether the code is actually correct, because the tests were shaped around the implementation instead of around the requirement.

The tip

Cole Medin, a builder who works with AI coding agents daily, posted this:

Cole Medin (@cole_medin), X, Feb 23, 2026

Four words, not two, but the point holds: "use red/green TDD" is a small enough addition that it costs you nothing to try, and it changes the order the agent is allowed to work in.

Why it works

Red-green-refactor is not new. It's the standard test-driven development cycle: write a test for behavior that doesn't exist yet (red, it fails), write the minimum code to make it pass (green), then clean up. Simon Willison's guide to agentic engineering patterns documents the same idea applied specifically to coding agents: use test-driven development, write the tests first, and confirm they fail before you implement the change that makes them pass.

The failing step is the part that actually matters here. If the agent writes the test first and runs it before writing any implementation, a passing result at that point means something is wrong; the test isn't actually testing anything. Confirming red first is what proves the test can fail. Skip that step, and you're back to tests that were fitted to the code instead of tests that check the requirement.

This is why it "catches unnecessary code" too, in Cole's words. When the agent has to write the test before it's allowed to write the implementation, it has to state the requirement in a form specific enough to run. Vague requirements produce vague tests that are obviously too weak, and that becomes visible before any implementation exists to hide behind.

How to actually use it

The instruction works as a one-line addition to whatever you're already asking for. Multiple independent write-ups on Claude Code, Cursor, and other agent setups converge on the same explicit phrasing, because agents left unconstrained default to writing implementation first:

Use red/green TDD for this: write a failing test for the requirement
first, run it and confirm it actually fails, then write the minimum
code to make it pass. Do not write the implementation before the test
exists and has been confirmed to fail.

If your agent setup supports a standing instructions file (a CLAUDE.md, a Cursor rules file, or similar), this is a good candidate for one line in there rather than retyping it every time you want it.

Where this helps, and where it doesn't

This is my own read on it, not something either source claims directly. It's a strong fit for anything with a checkable requirement before you start: a function with a clear input and output, a bug fix where you can state the correct behavior, an API endpoint with a defined contract. The test can exist before the code because you already know what "correct" looks like.

It's a weaker fit for genuinely exploratory work, where you don't know the right shape of the solution until you've tried a few. Writing a failing test for a requirement you can't state yet just produces a test for the wrong thing. Use it once the shape of the problem is clear, not while you're still finding it.

Final takeaway

A test written after the code only ever confirms the code. A test written before it has to state what "correct" means, and that's the part an agent can't fake its way past.