To test AI-generated code, test what it does for a user, not how it reads. Write the expected behaviour down before the agent writes any code, run end-to-end (E2E) tests against a build of every pull request, and keep a person in charge of any change in behaviour. Line-by-line review still matters, but it cannot carry the load alone.
AI-generated code is now the normal input to review
Most developers now work with AI tools. In the Stack Overflow developer survey, 84% of respondents are using or planning to use AI tools in their development process, an increase over last year (76%) [Stack Overflow]. JetBrains reports that 85% of developers regularly use AI tools for coding and development, and 62% rely on at least one AI coding assistant, agent, or code editor [JetBrains].
The effect on a team is simple. More code reaches review, and the reviewer did not write it. The reviewer also did not see the reasoning behind it. A diff shows what changed. It does not show whether sign-up, checkout or search still work after the change. That question needs a test that runs the application.
Write the expected behaviour before the code
An agent is good at producing code that matches a description. So the description is where quality starts. Before you ask an agent for a feature, write the acceptance checks as short steps: what the user does, and what they should see. Keep each assertion to one outcome.
This gives you two things. The agent has a clear target. And you have a test that does not depend on the implementation the agent picked. If the agent later rewrites the component, the steps still describe the same user flow, and the test still means something.
A check for a password reset flow can be this small:
1name: Reset password from the login page2url: https://staging.example.com3tags: [auth, smoke]4env:5 EMAIL: ${TEST_EMAIL}6steps:7 - Click "Forgot password"8 - Enter EMAIL in the email field9 - Click "Send reset link"10 - assert: The page confirms that a reset link was sentAnyone on the team can read it and agree or disagree with it. That matters more than the syntax.
Test from outside the code the agent wrote
Unit tests written by the same agent that wrote the code tend to share its assumptions. If the agent misread the requirement, its unit tests can encode the same misreading and still pass. A test that drives the real application in a browser checks the result from outside. It does not care which functions were called. It only cares whether the user got the right outcome.
So the recommendation is to keep unit tests for logic, and let the agent write them, but not to treat them as proof that a feature works. Use a small set of E2E tests on the flows that matter as the independent check. For how small, see how many E2E tests you need. For where the line between test types sits, see E2E vs integration testing.
Run the checks on every pull request
A check that runs after merge finds problems late, when the change is mixed with others. Run the E2E suite in continuous integration (CI) against each pull request, and make it a required check. On GitHub, after enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch [GitHub]. That turns your acceptance steps into a gate.
Two practical notes. Run against a deployed preview of the branch, not a shared staging server that other changes also touch. And keep the suite fast enough that nobody is tempted to skip it. The guide on running E2E tests on every pull request covers the setup.
Keep people in charge of behaviour changes
When a test fails on AI-generated code, there are two very different causes. Sometimes the test is out of date: a button was renamed or a form moved, and the behaviour is the same. Sometimes the behaviour changed. Treat these differently.
Locator and layout changes can be updated automatically, as long as each update is recorded and can be reviewed. A changed outcome should fail and wait for a person, because only a person knows whether the new behaviour was intended. If you let a tool or an agent quietly rewrite the expected result, the test stops testing anything.
Also be clear about limits. Passing tests show that the flows you wrote still work. They do not prove the code has no bugs. Exploratory testing, accessibility review and security testing are still separate jobs. The what we cannot do page lists these limits for our own product.
How AI Testing Platform fits
AI Testing Platform runs tests written as plain-English steps in YAML (plain-text configuration) files, and one command runs the suite in CI and reports a pass, fail or healed status per test as a check on the pull request. When an element moved, was renamed or was restyled, the platform heals the step and records the change for review; a changed behaviour fails and gets a triage card with a proposed classification. See how it works and tests in plain English.