Ask for Tests Alongside the Code

A habit of requesting unit tests in the same turn as the implementation — including edge cases — so you can verify the generated code instead of eyeballing it.

Generated code is confident and often subtly wrong on boundaries: empty inputs, nulls, off-by-one. Tests make those failures visible immediately rather than in production. Asking for tests also nudges the model to think about edge cases while writing the code, which improves the code itself.

Any function with real logic — parsing, calculations, state transitions, anything with edge cases. Especially when you can't manually trace every path.

Trivial glue code or one-line utilities where a test costs more than it's worth, and exploratory spikes you'll throw away.

Write <function> that <does X>. Include unit tests covering the normal case plus edge cases: empty input, boundary values, and invalid input. Use <test framework>. Show the tests so I can run them before trusting the code.

A date-range overlap function comes back with tests for touching ranges, contained ranges, and reversed inputs — one test fails, exposing a boundary bug you'd have shipped.

• Accepting code that 'looks right' without running anything against it.
• Asking only for happy-path tests, missing the boundaries where bugs live.
• Not actually running the tests, so they're decoration rather than verification.