AI Agent for Testing & Test Triage

It is an agent for software testing: writing tests against stated behaviour rather than current implementation, ranking untested paths by the risk they carry, and classifying CI failures as flaky or genuine using historic run data.

A chatbot generates a plausible test for code you paste. This agent works in your repository, matches your existing test framework and fixtures, and tells a real regression from a flake using CI history.

Yes. Test suites and CI history expose your architecture, your failure modes and your release cadence, and the source itself never leaves your infrastructure.

Tests raised as a reviewable diff in your own framework, a risk-ranked coverage gap list, a per-failure flake-or-regression classification, and a suite health report.

It writes and triages; reviewers merge. Test code goes through the same review as any other change, and implementation work belongs to the coding agent.

It deliberately does not optimise for that, and will tell you when a gap is not worth closing. Coverage counts lines executed, so the cheapest way to move it is to write tests that call functions without asserting anything meaningful — which is what most generation tools do. Ranking gaps by the risk the path carries produces fewer tests that matter more, and the percentage moves less than it would otherwise.

Three signals together: whether the failure reproduces deterministically when re-run in isolation, what that specific test’s historic failure rate looks like across recent runs, and whether the failure correlates with the change that preceded it. A test that has failed intermittently for weeks with no change correlation is flaky; one failing consistently since a specific commit is not. Where the signals disagree it says so rather than guessing.

Review looks at a change and asks whether it is correct, safe and consistent. This agent asks whether the behaviour is verified, and writes the verification. They meet on a pull request — review will note that a change is untested, and this agent writes the test — but one produces comments and the other produces test code that goes through review itself.

Less often, because they assert against the specified behaviour rather than the current internals. That distinction is the whole point: a test coupled to implementation fails on every refactor, which trains teams to update tests mechanically until they no longer verify anything. Where the behaviour itself genuinely changes, the test should fail, and that is the signal working correctly.

No. Execution is sandboxed and uses fixtures and mocks, with no production or staging credentials. Tests that reach live systems are slow, flaky by nature and occasionally destructive, and an agent holding credentials to an environment with real data is a risk that no amount of test coverage justifies. Integration testing against real environments stays in your existing pipeline.