Patterns / Verification gates

Tests as the gate

Define the check first, then let the agent iterate until the check passes. Not until it feels done.

The problem

Code review alone does not tell you whether agent output works. Reading generated code is slow, and plausible-looking code is exactly what language models are good at producing, whether or not it is correct.

The pattern

Make an automated check the gate for "done". The usual form is test-first:

1. Have the agent (or yourself) write tests that capture the acceptance criteria.
2. Run them and confirm they fail for the right reason.
3. Review and, if needed, commit the tests on their own so they are fixed as the target.
4. Let the agent implement until the tests pass, without editing the tests.
5. Run the full suite to catch regressions.

The same idea works without unit tests: a script that diffs output against a known-good file, a type checker, a linter, a build that must succeed. What matters is that the gate is executable and the agent cannot quietly move the goalposts.

Template

Step 1 – tests only
Write tests for the behaviour below. Do not write any implementation yet.
Behaviour:
- <criterion 1>
- <criterion 2>
- <edge case>
Run the tests and show me the failing output. Stop there.

Step 2 – implementation (after I approve the tests)
Implement the change so that `<test command>` passes.
Rules:
- Do not modify, skip or delete any test files.
- If you believe a test is wrong, stop and explain instead of changing it.
- When done, run the full suite (`<full test command>`) and paste the summary line.

When not to use it

• UI look-and-feel, copywriting or design work where correctness is a judgement call. Use screenshots and human review instead.
• Exploratory spikes whose purpose is to find out what to build.
• When the test would just restate the implementation (testing that a constant equals itself adds noise, not safety).