Scenario: The agents tested it. Nobody knows what.

This is a fictional but representative engineering organization. It is not a customer, nobody in it is a real person, and nothing in it is a quote. The numbers about the organization are arithmetic, with the inputs shown.

Nobody could say what the agents tested last week

The VP asked the head of QA a simple question: what did the agents test last week, and did any of it mean anything? There was no answer. Each agent ran its tests in its own sandbox, often against mocks. The results were in a chat transcript or gone. When a bug shipped the month before, nobody could trace which agent-written test should have caught it, or whether one existed.

Here's the math: 25 engineers, about four pull requests each per week, three to five agent-written tests per pull request. That is 300 to 500 new tests a week, 4,000 to 6,500 a quarter, with no record of what they cover or whether a pass meant anything. Nobody was going to read them all.

Three callers, three places tests run, three places results go. Nobody can say what was tested across all three.

This is the most common of the three setups we see. The guide has the industry numbers behind it.

What they did

They did not slow the agents down. They changed where the tests ran and where the results went.

1. A CI rule first. Within a week, every agent-written test had to run in CI with the result posted on the pull request. This was cheap and partial: it proved a test ran, not that it checked the right thing, and it said nothing about what the agent did in its sandbox.
2. One place for every run. Over the following quarter, every test run, whether an agent, the pipeline or a person triggered it, went through Testkube inside the team's own clusters. Agents call it over MCP. Results land in one execution history with logs, artifacts and the history of previous runs.
3. Agents read before they write. Through MCP, an agent sees which tests already exist for the area it is changing and runs those, rather than writing a new set from scratch each time.
4. Sampling instead of pretending. The head of QA reads a handful of agent-written tests each week, properly. Sampling is not coverage, but it is the review that is possible at this volume.

What changed

The VP's question has an answer: this is what ran last week, from which agent or person, against which environment, with what result. The "trust the agents" camp and the "we need quality control" camp are looking at the same screen, which turned out to be most of the argument.

If this is you

One place for every team's tests.

The same tests, the same way, whoever asks, inside your own clusters, with one record across teams.

Start free trial