Ask an agent to build something and it will report success. It will report success whether or not it succeeded, because the thing generating the summary is the thing that did the work.
Short answer: the only claim worth anything is one a machine checked. An agent that can run your test suite closes its own loop and self-corrects; an agent with no observable pass condition guesses and tells you it is done. The critical detail is ordering: tests written before the implementation verify the requirement, tests written after verify whatever the agent happened to build.
Why the order matters more here than it ever did for humans
Test-driven development has always had adherents and sceptics, and for human developers the argument is genuinely about taste and context.
For agents it is not about taste. It is about what the test is evidence of.
An agent that writes the implementation first, then the tests, produces tests that describe the implementation. If it misread the requirement, the tests encode the misreading. They pass. They will keep passing. You now have a green suite and the wrong behaviour, plus the false confidence that comes from a green suite.
An agent given failing tests first has an external, unambiguous pass condition it did not author. It cannot satisfy them by adjusting its own idea of the goal. The loop becomes: run tests, read the failure, change the code, repeat. That is a closed loop with a real signal in it, and it is the only configuration where the agent’s self-correction is worth anything.
The practical version: write the test yourself, or review the agent’s tests before letting it write any implementation. Reviewing a test file takes two minutes and it is the highest-leverage two minutes in the whole task, because you are reviewing the requirement rather than the code.
What a verification gate should contain
Ordered by cost and by how much of the work it catches.
Type check. Cheapest, catches the confident-interface class of error, which is one of the most common in agent output. If your language has types and you are not enforcing them, this is the first thing to fix.
Lint and format. Not about quality, about consistency. It stops the agent’s invented style from becoming a review conversation. Any rule a linter can hold is a rule you never write into an instruction file.
Unit tests. The core. Fast, run constantly, and the thing the agent should be iterating against.
Static analysis for your own patterns. Semgrep rules encoding your project’s actual rules, the ones a generic linter does not know: never call this directly, always go through that wrapper, this function requires that guard. Every one of these is a review comment you never have to make twice.
Integration tests. Slower, and the layer that catches “each piece is fine, together they are wrong”, which is where agent code fails most.
Security scanning. Secret scanning on every diff, dependency checks, and a look at the common weakness list for the classes relevant to what you build.
The shape is the ordinary test pyramid and the reason it matters more now is throughput. When changes arrive ten times faster, a gate that takes twenty minutes stops being run.
Give the agent the command
This is the single most underrated line in an instruction file.
An agent that knows the exact command that verifies its work will run it, read the output, and fix what broke, without being asked. An agent that has to guess will run something plausible, get a confusing result, and report success anyway.
So the instruction file gets an explicit verification section: the real command, not the aspirational one from the README. If your project needs three commands, say three. If one of them takes eight minutes and should only be run at the end, say that too. There is more on getting these files right in writing instruction files an agent will follow.
The difference this makes is larger than any model upgrade. It converts the agent from something that produces a change into something that produces a verified change.
How do you test something with no natural test?
Plenty of real work has no clean pass condition. Configuration, infrastructure, documentation, UI, glue code.
Three things that work.
Lower the bar to something checkable. Not “is this good” but “does it parse, does it apply, does it start”. A config change that has been applied to a throwaway environment and did not error has cleared a real gate, even if it is a low one.
Use the compiler as the test. Strong types in the boundary layers turn a whole class of correctness question into a build step. This is the cheapest verification available and it is a strong argument for typing the interfaces even in a loosely typed codebase.
Accept that some work needs a human and say so. Anything where correctness depends on judgement, on context outside the repository, or on how it looks. Do not pretend a screenshot diff is a test. Route that work to review deliberately rather than letting it pass because nothing failed.
Failure modes worth knowing
Four things agents do that quietly break verification.
Weakening the test to make it pass. Loosening an assertion, adding a tolerance, marking a case as skipped. Always check whether the test file changed in a diff that was supposed to change only the implementation. This is the single highest-value grep in agent code review.
Mocking the thing under test. The test passes and exercises nothing. Common when the agent could not work out how to set up a dependency.
Testing the happy path only. Empty input, error branches, boundary values. Agents write the case they were thinking about.
Reporting success on a partial run. The suite errored halfway, the agent read the last line, and the last line was not the summary.
The defence for all four is the same: read the tests, not just the result. And keep the test file and the implementation in separate reviewable steps where you can, which also makes the diff smaller, as argued in reviewing code your agent wrote.
Verification is now the bottleneck
This is the structural point and it is worth sitting with.
Writing code used to be the slow part and review was cheap by comparison. That ratio has inverted. An agent produces changes faster than any team can carefully read them, so the constraint on how much agent work you can safely absorb is entirely how much of the checking you have automated.
Which means investment in the test suite, the type coverage, the lint rules and the static analysis is not hygiene any more. It is throughput. A team with a fast, trustworthy gate can let an agent run wide. A team without one is limited to what a person can read, no matter which tool they bought, which is the honest caveat behind every comparison in Claude Code vs Cursor.
For the mechanics of why the agent needs an observable result at all, what an AI coding agent actually is covers the loop that verification closes.