A test automation strategy for teams using AI coding agents does three things. It gives the agent a test format it can read and write and a command it can run. It makes end-to-end (E2E) checks a required gate on every pull request. And it keeps people in charge of two decisions: which flows must be covered, and whether a change in behaviour is intended.
Agents write code, so they should write and run tests too
AI is now part of how most engineers work. In the DORA research, 90% of survey respondents report using AI at work [Google Cloud (DORA)]. 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].
When an agent writes a feature, the cheapest moment to add its test is the same session. The agent has the context. It knows which flow it touched. A strategy that leaves tests for a person to write later will fall behind, because the agents produce changes faster than people can cover them.
So treat the agent as a test author and a test runner. That only works if the tests are in a form the agent can produce reliably and a person can check quickly.
Choose a test format both agents and people can read
Test code written by an agent is hard to review. It mixes the intent of the test with selectors, waits and setup. A reviewer has to read the whole thing to learn what it checks.
A better choice is a format where the intent is the test: a list of steps and assertions in plain language, in a file that lives in the repository. The agent can write it from the feature description. A person can read it in seconds and say "yes, that is the flow" or "no, you missed the error case". Keep the test files next to the code, so every pull request that changes a flow also shows the test change.
Whatever format you choose, give the agent three things in its instructions: where tests live, how to run them, and where to read the result. Without those, the agent will invent its own conventions in each session.
Keep people in charge of what must be covered
Agents are good at writing a test for the change in front of them. They are not good at deciding which flows matter to the business. That list belongs to people: a quality assurance (QA) lead, an engineering manager or the product owner.
Write the list down. Review it when the product changes. When a bug escapes to production, add the flow to the list and add a test. This keeps the suite tied to risk rather than to whatever the agent happened to touch. For guidance on size, see how many E2E tests you need. For who should own the list, see who should write E2E tests.
Gate merges on required checks
A test that runs but does not block is a report. For an agent-first team, it needs to block. On GitHub, after enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch [GitHub]. On GitLab, you can configure your project to require a complete and successful pipeline before merge [GitLab].
Ask the agent to run the suite locally before it opens a pull request, then let continuous integration (CI) run it again on the branch. The agent fixes red checks itself. People review only green pull requests. The guide on running E2E tests on every pull request covers the setup.
Separate test upkeep from behaviour decisions
Agents change user interfaces often. Many test failures after an agent change are upkeep: a button was renamed, a field moved. Others are real: the flow now does something different. If both look the same in CI, people either rerun everything or stop reading failures.
Automate the upkeep and record it. Route behaviour changes to a person. Handle flaky tests with a system, not by hand: after replacing the manual approach of handling test failures with an automated flaky test suppression system, Slack dropped test job failures from 57% to less than 5% [Engineering at Slack].
How AI Testing Platform fits
AI Testing Platform is built for this loop. A coding agent sets it up from the docs at /for-agents/, llms.txt and a skill file, reads the existing specs in tests/, writes new ones in the same format, runs them and reads the report at .aitp/last-run.json:
npx aitp initnpx aitp runThe same run reports a check on the pull request, and finding coverage gaps against a map of your flows is in beta. See the agent-first teams page and the spec docs.