When I see how well AI agents already perform today—and since it is often better to define a task more loosely and let the agent propose its own solution—it makes me think about what this currently means for software testing. I would like to explore several points that follow from this observation and then introduce one project: a testing solution that could be put to interesting use today (in September 2026).
If they generate the code, let them test it too
It sounds simple and straightforward, but it probably is not quite that easy. The main factor entering the equation is that software is still used by people who come from different backgrounds, belong to different interest or professional groups, and have varying levels of technical skill. At the end of the day, they are primarily people, not AI agents. They have their own preferences, certain things bother them, they rely on intuition, and the way software “feels” matters too—not just its functionality.
Functionality, however, is one of the cornerstones of a good software product. Even a product with good UI/UX loses its value if it does not work properly and therefore fails to deliver the utility it promised.
That is why it is important to have a testing layer that verifies core functionality. This is precisely where AI agents can help. If we can describe in words and define empirically how something should work from A to Z, an agent can verify it as well. I believe that in a world where AI implements solutions based on detailed specifications, AI should also verify those specifications.
- Primarily through test automation (unit tests > integration tests > end-to-end tests).
- Today, also through a free-form agent that traverses the system on demand according to a test scenario.
And we do not have to stop at such a simple model.
Why not have more agents?
Original meme by @beginbot on X.
Why not have several agents? Imagine a web application with a technology stack such as Next.js, NestJS, Redis, and PostgreSQL, perhaps supplemented by an external API. In a TypeScript project, we could create a group of agents and instruct them to build their own test suites in parallel throughout development—while the developer is building the application—and verify everything that needs to be checked when the time is right.
We could have:
- a unit-testing agent that manages a suite of unit tests in a NestJS backend (using Jest, for example) and is instructed to run low-level module scenarios on demand,
- an integration-testing agent that manages a suite of integration tests, perhaps also using Jest in the backend, but works with a mock database, Redis, and an external API, while becoming an expert at running scenarios on demand in this environment,
- an end-to-end testing agent that manages a suite of Playwright tests and specializes in controlling the browser (probably the most important on-demand tester in our fictional project),
- a load-testing agent that manages k6 tests and knows how to modify and run them,
- a security-testing agent that also manages its own test suite and specializes in security testing.
Finally, we could have a lead testing manager that coordinates all of these agents. The entire system could use a shared database of results linked to individual versions of the application, giving it a view of the project's history as well. This would already be a somewhat more complex system, although, for example, the memory feature in Claude Code does a good job in this area on its own.
During development and as a standalone AI team
Since the code would be distributed across multiple repositories, it would be useful for this AI layer to operate across all of the project's repositories at once and share a common definition. It would also be helpful if AI development tools knew that these agents were available, so their implementers could “release them from the cave” whenever needed during development.
People responsible for testing on the project (still testers?) could also activate this testing team independently and assign tasks to it.