Testing AI-generated code: why the writing AI should not be the only checker
AI coding makes development faster. But when the same agent writes the code and fixes the tests to match it, green uncertainty appears quickly.
This article is based on a developer note from my LinkedIn feed. The claim is intentionally sharp: AI can write code and AI can test. It just should not be the same working step. Original post on LinkedIn.
“AI cannot do that!” Then let another AI check it.
My development workflow is now almost completely AI-assisted. Copilot, Claude, Pi-Dev, Fusion, different models and workflows. The full set.
What many of these tools do well: generate code, reshape it, try variants, fix errors directly. What they do much worse in my day-to-day work: write meaningful tests that are allowed to contradict their own result.
Test-driven development is often treated as the default answer to AI coding. I think that is too thin. TDD only helps when the test is independent enough to hurt the code when it needs to.
Two examples from practice
The unnecessary test
A database table was extended. A title was added. At the same time, a test was written to check whether that title could be queried in the SQL query. The test was green. It was also almost worthless.
A test like that feels good, but it does not create real confidence. Mostly, it confirms that the implementation looks the way it was just built.
The dangerous test fix
The task was to add a status to Feature A. What got understood was: the status in Feature B is unnecessary. So it was removed. The tests failed, exactly as they should.
Then came the real damage: the tests were adjusted because the agent was working toward a finished result. A warning signal became a green checkmark.
Coding and checking are opposite modes
Coding is about forward motion: build, connect, repair, keep going. Testing is about distance: what was missed? Which assumption is wrong? What breaks when the interface reacts differently than expected?
That exact step back is missing from many AI workflows. Models are trained for action. See an error, write a patch, move to the next problem. That is useful in development. In QA, it is dangerous.
If the same AI builds the code and then “repairs” the tests, it can end up defending the bug it just introduced. Not on purpose. But because the workflow pushes it there.
The better workflow: separate, verify, then return
My rule is simple now: the feature agent is not allowed to freely write or adjust tests just to make the run green again. Tests belong in their own loop.
- Treat feature development and test changes as separate work.
- Review test diffs more strictly than regular code diffs.
- Treat failing tests as signals first, not as a to-do list to patch away.
- Check browser functionality in a real browser instead of only reading code and snapshots.
Where QAgent fits into this loop
For browser checks I use QAgent: a CLI tool that takes a goal in natural language, checks the page in the browser, and returns a structured PASS/FAIL with evidence.
The point is not another test tool for its own sake. The point is separation. The coding agent builds. A separate verification loop opens the browser and checks whether the feature works from the user's point of view.
# Example: browser check from an AI coding loop
qagent --url http://localhost:3000 "Submit the contact form and check the success message"This does not replace a long-lived Playwright suite. It is a fast counter-check during development, exactly where AI coding otherwise burns context or bends tests around the code it just created.
What this means for PMs and teams
Faster development moves the problem. When features appear in minutes, QA does not automatically get easier. It has to become more independent.
For PMs, that means acceptance criteria need to be browser-ready. Instead of “add status,” write: “User sees Status X in Feature A, Feature B remains unchanged.” Goals like that can be checked without the verification loop knowing the implementation.
For developers, it means the green test is worth less when it comes from the same loop that just wrote the code. Trust comes from distance.
Frequently asked questions
- Should AI write tests for its own code?
- It can suggest tests. It becomes risky when the same workflow builds the code and then adjusts the tests until the result is green. Reliable QA needs a separate verification loop.
- How do I test AI-generated code in the browser?
- An independent check should open the page, run the expected journey, and return a PASS/FAIL with evidence. QAgent is built for exactly that.
- Does QAgent replace Playwright?
- No. Playwright remains useful for regression tests. QAgent sits in the fast development loop: describe the goal, let the browser check it, and return the result to the coding agent.