Test-driven development (TDD) gives an AI coding task a behavioral target: specify an expected result in a test, implement code that makes it pass, then improve the design while keeping the test green. This can make a prompt easier to review because the expected behavior exists outside the generated implementation. TDD does not guarantee quality, but it helps reveal when a change has no independent check.
Write the test from the requirement
Begin with a user or system outcome, not the implementation the tool is expected to produce. For a permission change, define who should be allowed and denied. For a calculation, use known inputs and expected outputs. For an API, describe valid, invalid, and unauthorized behavior. If the criterion is too vague to test, resolve the product decision before code is generated.
For example, if an issue says that only workspace members may export a record, write one test for an active member and one for a person outside the workspace. Use records from two different workspaces so the test can detect a query that accidentally returns both. The test states the permission contract without dictating whether the implementation uses a query filter, a policy helper, or another internal design.
Use a reviewable red-green cycle
- Add a focused test for one acceptance criterion.
- Run it and confirm it fails for the expected reason.
- Ask the tool for the smallest implementation that satisfies the test.
- Run the test and relevant existing checks; inspect both test and implementation diffs.
- Refactor only while the behavioral checks continue to pass.
Watch for tests that only confirm the implementation
A test is weak when its expected value comes from the code under test, when it mocks away the behavior it claims to check, or when it only asserts that a helper was called. Ask whether a faulty implementation could still pass. For important behavior, include boundary and failure cases. Keep test names tied to observable outcomes so a reviewer can understand what the suite protects.
Know what a green test means
A passing test is evidence about behavior it exercised in the environment where it ran. It does not prove that the test is complete, that production is configured the same way, or that the full feature meets every requirement. Pair tests with code review, integration checks, or operational validation when the risk calls for them. Preserve the command and result so another person can see which check ran.
For AI-assisted work, TDD is most useful when the person requesting the change defines expected behavior and reviews the test itself. That keeps the check independent enough to challenge generated code and gives the team a concrete place to discuss ambiguous requirements.