TIPS & TRICKS · AGENTS · TESTING

Let the Agent Run the Tests, Then Check These

An agent that can run tests, builds and linters fixes its own mistakes before you see them. How to set up that loop, and the things you still need to check.

3 Nov 2026 · 5 min read

The single biggest jump in the quality of a coding agent’s work does not come from a better model or a cleverer prompt. It comes from letting the agent check its own work: run the tests, the build and the linters, read the failures, and fix them before reporting back.

Without that loop, an agent stops at the first version that looks right. With it, the agent stops at the first version that is right, at least as far as your checks can tell.

Why the loop matters

Code generation is a guess. A good guess, often, but a guess. Tests turn the guess into feedback. When the agent sees expected 0, received NaN, it knows exactly what to fix. It will happily go around that loop five or ten times, faster than you could, and you only see the result.

It also changes your role. Instead of finding the agent’s mistakes, you review work that has already passed a bar. Your time goes on the things machines cannot judge.

Set up the loop

Make the checks one command each. The agent should not have to work out how to run things. Put them in your project instructions file:

Test:       npm test
One file:   npm test -- src/lib/streak.test.ts
Types:      npx tsc --noEmit
Build:      npm run build
Lint:       npm run lint

Make them fast enough to run often. A suite that takes twenty minutes will not be run after every change. Show the agent how to run one file or one test while iterating, and the full suite once at the end.

Make failures readable. Short, specific error messages help an agent as much as they help a person. A failing assertion with the actual and expected values beats a stack trace through the test framework.

Say it in the task. “Done when npm test and npm run build pass” in the brief is what tells the agent to keep going until they do. See how to write a task an agent can finish.

Ask for a test first, when you can

For bugs, a strong pattern is: write a failing test that reproduces the bug, confirm it fails, then fix the code until it passes. The failing test proves the agent understood the bug. The passing test proves the fix. And the test stays behind to stop the bug coming back.

For new features, ask for tests alongside the code, and name the cases you care about: empty input, the boundary, the error path, the signed-out user. Left to itself, an agent tends to test the happy path.

Watch for gaming the checks

An agent told to make tests pass will sometimes take the shortest route. Look out for:

• weakened tests: an assertion loosened, a case deleted, expect(true).toBe(true);
• skipped tests: .skip, xit, a test file excluded from the run;
• special-casing: code that checks for the test’s exact input;
• swallowed errors: a try/catch that hides the failure the test was catching.

Tell the agent up front: “Do not change existing tests unless the task requires it; if you think a test is wrong, stop and tell me why.” Then skim the test diff first when you review. It is usually short, and it tells you whether the green tick means anything.

What you still need to check yourself

Passing checks mean the code does what the tests say. They do not mean the tests say the right thing. Your review should focus on what automation cannot see:

1. Is it the right change? Does it solve the problem you actually had, in the place you expected? A perfectly tested fix in the wrong layer is still wrong.
2. Are the tests meaningful? Do they cover the cases that matter, including the ugly ones?
3. What did it touch that it did not mention? Read git diff --stat. Unexpected files are the first place to look.
4. Security and data. Permissions checks, user input reaching a query, secrets in logs, personal data in error messages. Tests rarely cover these.
5. How it looks and feels. For UI work, open the page. Check a phone-sized screen, keyboard use, and dark mode if you have one. A screenshot from the agent helps, but looking yourself is better.
6. Things that only show up in production. Migrations on large tables, performance on real data sizes, behaviour when a dependency is down.

Ask the agent to end with a short report: what it changed, which checks it ran and their results, and anything it was unsure about. Read the unsure part first.

Keep the bar where it is

Once the loop works, it is tempting to trust the green tick completely. Do not. Treat the checks as a floor, not a ceiling: they catch the mistakes you already thought of. Your review catches the rest, and every mistake you catch is a candidate for a new test, so the floor rises over time.

Takeaway: give the agent one-command checks and a task that says done means they pass, and it will fix most of its own mistakes. Then spend your review on what tests cannot see: the right change, meaningful tests, unexpected files, security, and the real UI.