Test: give the session a feedback loop

The test stage gives every implementation session a fast, failing-closed feedback loop before a human reviews the change. The agent runs the real tests, build, and visual checks; a bug fix begins with a reproducing test that the implementation run may not weaken or silently replace.

Traditional: The signal that code works arrives late: CI minutes later, a tester days later, production weeks later. With an agent producing the code, a late signal means a person has to check all of its output.

AI-native: The session is given a way to check its own work before a person sees it. Run the tests, run the build, take the screenshot. The agent iterates until the check passes.

Do not confuse the feedback loop with a verifier subagent. The loop runs through the whole task. The verifier is one way to package a final check in a fresh context window once the session believes the work is done.

Before you begin

• A test suite and a build that run locally with one command each
• For UI work, a browser tool or screenshot utility (MCP) so the agent can see the result

Prerequisites: none to start the loop. CLAUDE.md / rules / AGENTS.md from Build makes the loop durable.

Set up the loop

1. Wrap today’s check in a single target that exits non-zero on failure (make test, npm test).

2. In the Commands section of CLAUDE.md, .cursor/rules, or AGENTS.md, list each command with an example of healthy output.

3. State a quantifiable target so the agent can check the work without asking you.

   Examples: “All tests in test_status.py pass”, “the screenshot matches the attached mock”, “the endpoint returns 200 with the new field”.

4. For bug fixes, write the failing test first.

   Ask the agent to reproduce the bug as a test, run it, and confirm it fails for the reason you expect. Commit that test. Only then ask the agent to make it pass without editing the test.

5. For UI work, close the loop with a visual check.

   Give the agent a browser or screenshot tool, give it the mock, and let it iterate: implement, screenshot, compare, adjust. Two or three rounds is normal.

6. Make verification part of “done.”

   Instruct the agent to run the tests before reporting a task complete, and to paste the output.

7. Protect the loop.

   An agent fixing code must not weaken the check on that code. A hook that blocks edits to test files during a fix does this. The alternative is to reject any review diff that touches a test during a fix task.

Verification block to add to the project instruction file:

## Verifying your work
- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

Continuous evals in CI

Evals are the AI-native equivalent of stage-gate QA: a suite that runs whenever the agent’s configuration changes. When you swap a model or rewrite a prompt, the suite says whether the agent still does the work to the same standard.

1. Collect 20 to 50 real tasks from recent work, each with an accepted outcome.

2. Write each task as an eval: the prompt plus the checks that define acceptable (tests pass, lint clean, behavior unchanged, policy followed).

3. Run the suite non-interactively in CI on a schedule and on any change to CLAUDE.md, .cursor/rules, AGENTS.md, skills, or hooks.

4. Gate configuration changes on the results. A skill change that drops the pass rate gets reviewed before it merges.

5. Each production incident becomes an eval, written by the team that owned the incident, and stays in the suite as a regression test.

Some teams run these evals offline on a cadence rather than on every change. Either way the suite is live: as models improve, cases that once discriminated stop doing so, and you add new ones from monitoring.

Claude Code can run evals with claude -p in GitHub Actions. Codex uses openai/codex-action@v1 (which runs codex exec). Cursor Cloud Agents can run the same checks from a workflow that checks out the repo.

Governance

Verification before a task is reported done, and the block on editing test files during a fix, are both implemented as hooks where the organization wants them guaranteed. The evidence is the literal output of make test, the build log, or the screenshot diff. The code owner reviewing the PR can concentrate on intent and risk because the mechanical evidence is already attached.

Evals give QA a gate that keeps up with agent output. The pass-rate threshold is a merge check on harness changes.

Verify

• The agent pasted test or build output before it claimed the task was done.
• A bug-fix PR does not rewrite the failing test that proved the bug.
• A change to CLAUDE.md / rules / skills triggers the eval suite (or you have a documented cadence).

Leading indicator: first-pass CI success rate for agent-written changes; eval pass rate over time.

Lagging indicator: review time per PR, change failure rate, and regressions caught in CI versus production.

Apply the play in your tool

Claude Code adapter Run in-session checks and bounded headless review with claude -p.

Cursor adapter Use terminal, browser tools, screenshots, checkpoints, and Agent feedback.

Codex adapter Use the active loop or codex exec with an explicit sandbox and output contract.

Send verified work to review

Send the already-checked diff through Deploy.