Test-first with AI coding agents

A test is a specification the agent can check

Prose instructions leave room for interpretation, and agents fill that room confidently. A failing test does not: it states exactly what should happen, in your code's own terms, and tells the agent whether it got there. Test-driven development, written long before coding agents, turns out to suit them very well.

The loop

1. Red. Write, or have the agent write, a test for one behaviour, and run it to see it fail for the right reason.
2. Green. Ask for the smallest change that makes it pass.
3. Refactor. Tidy the code with the tests still passing.
4. Commit. Keep the test commit and the change visible in the history, so a reviewer can see the test came first.

Keeping the agent honest

Agents are rewarded for green builds, so watch for these:

• Editing the test to match the code. Make it a rule that a test may only change, in its own commit, if it was wrong against the specification, and that the change is called out.
• Tests that can't fail. An assertion on something always true, or a mock that returns whatever is expected. Run the test against the old code: it should fail.
• Skipping the slow tests. Have continuous integration run the full suite before merge, whatever the agent ran locally.
• Endless retries. Set a limit, say five attempts at the same failure, after which the agent stops and explains instead of guessing.

Write the rules down

Put these expectations in the instructions file your agents read, next to your domain glossary and conventions. On our own projects, a short section saying "test first, one behaviour at a time, never weaken a test to pass it" changed the quality of agent pull requests more than any prompt technique.

Next: reviewing code an AI agent wrote, or back to the AI Engineering Academy.