Testing in Agentic Coding: From Safety Net to Steering Wheel

Claude Craft August 27, 2026 0 comments

We have been shipping a lot of apps with agents lately: Claude Code on some projects, our developers on Kilocode and Codex on others. The developers adapted fast. The question that kept bothering me was our test engineers, and whether twenty years of testing discipline just became obsolete overnight. This post is my answer: it did not. It became more important, and it moved to a different place in the process. Along the way I will also answer the question that follows immediately after: if agents write the code, who reviews it, and does agent-reviewing-agent even make sense?

The safety net became the steering wheel

For twenty years, tests sat downstream of code. You wrote the feature, then you wrote tests to prove it worked, and everyone quietly accepted that half the time the tests came late or not at all. Tests were insurance. Skipping them was a debt, not a disaster.

Agentic coding flipped the direction of that arrow. When Claude Code, Cursor, or any autonomous agent writes and modifies code in a loop, the test suite is the only channel through which reality reaches the agent. The agent cannot see your product spec. It cannot sit in your standup. What it can do, thousands of times an hour, is run a test and read the result. That makes tests the primary steering mechanism, not the final checkpoint. Anthropic’s own Claude Code best practices put test-driven workflows at the center for exactly this reason: a red-to-green cycle gives the agent unambiguous feedback it can iterate against without a human in the loop.

Here is the position I will defend: in an agentic team, writing tests after the code is not a smaller version of testing. It is theater.

What happens when an agent codes without tests

The failure modes are predictable, and if you manage a web team using AI agents, you have already seen at least one of them.

• Hallucinated correctness. The agent reports “done, all working” for code it never executed against a real assertion. It is not lying. It has no ground truth to check against, so its confidence is a language pattern, not a verdict.
• Fix one, break three. Ask an agent to patch a Laravel endpoint and it will happily rewrite a shared helper, silently changing behavior in two other controllers. Without a regression suite, nobody notices until a client does.
• Spec drift. Over a long session, the agent’s idea of the feature slowly diverges from yours. Each individual change looks reasonable. The sum is a checkout flow that does something you never asked for.

There is a fourth failure mode that surprises people: unlike a human developer, an agent almost never says no. A senior developer will push back on a bad requirement. An agent builds whatever you describe, including the unwise version, and builds it convincingly. Tests are the mechanism that replaces the pushback you lost.

Test-driven prompting: write the contract, not the code

The practical shift for developers is that you stop typing assertions by hand and start defining behavior up front, in plain language or minimal test skeletons, then instruct the agent to write code that makes those tests pass. Kent Beck, who literally wrote the book on TDD, calls this discipline the difference between vibe coding and augmented coding: in one you only care that the behavior looks right, in the other you own the tests and the design while the agent does the typing.

The working sequence looks like this:

 

Step 3 is not optional. Agents will sometimes edit a test to make it pass instead of fixing the implementation. Committing the failing tests first means any tampering shows up in the diff, and you can revert it in seconds. That one git commit is doing the supervision work a human reviewer used to do line by line.

For web teams, the same pattern applies at every layer: Pest or PHPUnit for the API, Vitest for React components, and Playwright for the end-to-end flows that actually pay the bills, like login, cart, and checkout. The agent can write and run all of them. Your job is deciding what they must assert.

Fix bugs backwards: regression test first, patch second

When a bug surfaces, the old reflex is to dive into the implementation. The agentic reflex should be different: prompt the agent to write a test that reproduces the bug, watch it fail, and only then allow the agent to generate the fix.

This ordering matters for two reasons. First, a reproducing test proves the agent understood the bug; a patch without one proves nothing. Second, that test stays in the suite forever, so the same agent (or the next one, or the junior developer six months from now) cannot reintroduce the bug without the pipeline going red. Every incident becomes a permanent constraint. Over a year, this is how a codebase touched by agents gets more stable instead of less. This is the same discipline we described in controlled AI coding, applied to defects instead of features.

Can an agent review agent code?

This is the question that sounds like a trap: if the agent wrote the code, having an agent review it feels like a developer testing his own work. Sometimes it is exactly that, and sometimes it is not. The difference is context, and it is worth being precise about.

An agent reviewing code inside the same session that wrote it is worthless. It carries the full memory of its own reasoning, so it re-approves its own assumptions, the same way you cannot proofread your own email five seconds after sending it. But a fresh agent session with no memory of the implementation is a genuinely different reviewer. It reads the diff cold, with no attachment to the decisions behind it, which is closer to a new team member reviewing a PR than to a developer grading himself. Anthropic recommends this writer/reviewer split as a standard pattern for the same reason.

So agent review is real, but it is narrow. A fresh agent catches logic errors, missed edge cases, and deviations from the test contract. What it cannot do is be accountable. Both agents still share the same training, the same blind spots, and the same inability to know your client, your compliance obligations, or your business. That is where the human stays, and not as a formality:

• Owning the behavior contract. A human decides what the tests must assert. Agents can propose edge cases; a person approves them.
• Reviewing the tests, not the volume. Nobody honestly reads 800 generated lines. A human reads the 60 lines of tests that govern them, plus a spot-check of anything touching money, auth, or data deletion.
• Architectural and product judgment. Whether this feature should exist, whether this dependency is acceptable, whether this shortcut will hurt in a year. No test suite encodes that.
• The merge. A human presses the button, and that name in the git history means something a bot’s cannot.

Put plainly: shipping unreviewed code was never acceptable, and agents do not change that. They change what review looks like. Test contract reviewed by a human, implementation reviewed by a fresh agent, judgment calls and the merge held by a human. That is not weaker than traditional code review. Done honestly, it is stricter, because the contract is explicit instead of living in a reviewer’s head.

What changes for the team lead

If you run a web team, the shift is bigger for you than for your developers. The summary:

Dimension	Traditional workflow	Agentic workflow
Role of tests	Validate finished code	Specify and constrain the agent
When tests are written	After implementation, if time allows	Before the agent writes code
Debugging	Manual analysis, then refactor	Regression test first, then prompted fix
What reviewers read	The implementation diff	The tests, then the diff
QA position	End of the cycle	Start of the cycle, encoded as tests

The review change deserves emphasis. An agent can generate 800 lines of plausible React in a minute; no human reviews that honestly. What a human can review is the 60 lines of tests that define what those 800 lines must do. Review the contract, spot-check the implementation. Where the web development life cycle used to place QA as a phase, agentic teams place it as a gate: CI runs the full suite on every agent-generated commit, and the agent is simply not allowed to ship red. Budget-wise, the hours you used to spend on post-build QA move upstream into behavior definition. The total testing effort does not shrink. It moves to the front, where it is cheap.

A policy checklist worth adopting before your team’s next sprint:

• Every agent-built feature starts from tests the agent was given or asked to generate first, committed while still failing
• Agents are instructed never to modify existing tests; any test change requires a human commit
• No agent-generated PR merges with a red pipeline, no exceptions for “it works locally”
• Every production bug gets a reproducing regression test before its fix is accepted
• Critical user flows (auth, cart, checkout, payments) have end-to-end coverage the agent must keep green
• Reviewers read tests first and sign off on behavior, not line-by-line implementation

Your testers just got promoted

The uncomfortable conclusion for managers: the people on your team who are good at defining expected behavior, edge cases, and failure conditions just became your highest-leverage engineers. That skill used to be undervalued as “QA work.” It is now the interface through which your team controls its fastest developer, the agent. The developers who thrive in this model are the ones who can hold the whole behavior of a feature in their head and write it down precisely, which is also the skill we argued matters most in vibe coding for web developers and in writing clean code with AI.

So no, test cases did not die in the age of agentic coding. They stopped being paperwork and became the steering wheel. The teams that treat them that way will let agents run fast safely. The teams that skip them will discover that an agent with no constraints is just a very fast way to write next quarter’s incident report.