AutoTest
A one-line prompt becomes a self-healing browser test suite that monitors your application on its own schedule. Built and operated by us, end to end.
End-to-end test suites rot. Every UI change breaks selectors, every broken selector needs an engineer, and maintenance quietly becomes the biggest line item in QA — until the team stops trusting red builds. AutoTest removes the maintenance instead. We ran it against real applications at our own expense before writing a word about it here.
A natural-language brief — “test the login flow” — becomes a runnable Playwright test. No test DSL to learn, no selector spelunking.
Real browser, real application. Assertions are judged by cross-model consensus — two frontier models must agree before a state is called passing or failing.
When the DOM shifts, broken selectors are re-derived, the test is patched, and the verified selector is cached for every run after. Healing repairs the path to an assertion — never the assertion itself.
A background scheduler runs suites on their own cadence between releases, ranks tests by failure risk, and writes a plain-language summary of what changed overnight.
Every verified selector, anti-pattern, and confirmed step persists into project memory. The next test generated inherits everything the platform has already learned about your app.
Stack: TypeScript throughout — React + Vite front end, Express API, Postgres via a typed ORM, Playwright execution, Claude as the primary model with a secondary frontier model as assertion arbiter, Redis for the verified-selector cache.
One model judging “did the page reach the right state?” produced false positives no team would tolerate in CI. Every assertion now needs 2 independent verdicts: a second frontier model judges the same evidence, and a disagreement goes to arbitration — never straight to your build status.
So we drew a structural line: healing may repair how a test reaches an assertion (selectors, navigation), and exactly zero of what the assertion expects. A failed expectation files as a defect with full trace evidence, 100% of the time — which is why the diagram has two separate exits from a failed run.
Generation, and breakage. Every healthy run in between replays cached, verified selectors deterministically — 0 model calls, so the steady state is fast, reproducible, and effectively free. Model spend concentrates where judgment is needed; everything else is replay.
Our demo runs the full platform against a real open-source CRM: generated tests, run history with a live self-heal recovery, learned project memory, and autonomous monitoring cycles. Nothing is mocked — every number on screen comes out of the database.
Suites generate from one-line prompts, verified selectors persist across runs, and the platform monitors between releases instead of waiting for a human to press run. We operated it ourselves, on our own applications, at our own expense.
AutoTest lands in your cloud, wired into your CI and pointed at the application blocking your release train, with the consensus gate tuned to your team's false-positive tolerance. Your application and data never leave your environment.
The ticket that requests a feature, the doc that describes it, and the test that verifies it are three copies of the same intent, drifting apart from day one. Our next platform, now in the lab, collapses them into one object: prose that is at once the requirement, the documentation, and the executable test. AI proposes; humans keep final judgment.
If staging is where your releases slow down, ask about it in the briefing.