Most test automation platforms rest on a quiet assumption: once your suite lives inside the tool, you’re not going anywhere. The tests are yours the way a photo album in someone else’s house is yours. You can look at it. You can’t take it home.
We went the other way. At Klarent you can export your test code and run it on standard runners, not a lossy dump, not a proprietary format with a converter bolted on. Actual code, in the framework you already use, running where you already run things.
On paper that looks like giving away the reason to pay us. Here’s why we don’t think it is.
The code is the easy part to hand over
There’s a lazy version of this argument that says test generation is commoditizing, so the value has moved elsewhere. We don’t believe that. Anyone who has read what a general-purpose model produces when asked for an end-to-end test knows the difference between code that passes and code you’d want to own. Brittle selectors. Sleeps instead of waits. Assertions that check the wrong thing in a way that surfaces three weeks later as a false green.
We fine-tuned our models to write test code the way a good engineer on your team would write it, and the exported file is the evidence. You can read it. That’s the point.
But the model is only half of it.
What happens when the test stops working
This is the question that decides whether an AI testing tool saves engineering time or quietly consumes it.
A model hands you code. Then the code fails, and you’re on your own: is this a real bug in the application, a badly written test, or flake? Which step broke? What did the page actually look like at that moment? You open the CI log, find nothing useful, run it locally, can’t reproduce it, and burn an afternoon. Multiply that across a suite and the tool that was supposed to remove work has just moved it, from writing tests to debugging tests, which is worse, because debugging someone else’s generated code is the least pleasant work in software.
The harness is what we built around the model so that doesn’t happen. Tests are generated against a live application and verified before they reach you, so what lands in your repo has actually run. When something does break, the failure comes with the context needed to judge it in a minute rather than an afternoon: the failing step, the state of the page, a reproducible run rather than a stack trace and a shrug. And the triage is explicit: real regression, bad test, or environment.
That loop is the product. It doesn’t export, because it isn’t a file.
Healing is the same loop, running continuously
A test breaks because the application moved. Fixing it means understanding what the test was trying to verify, working out what changed underneath, and rewriting the affected parts without quietly weakening the assertion.
That needs both halves. The model, because repair is generation with more context. The harness, because you can’t repair what you can’t diagnose: a healing layer with no visibility into why a test failed will happily “fix” a test into passing while testing nothing.
Creation is a delivery. Healing is a relationship. We’re betting the relationship is what you actually want, and that a quarter of UI churn will make the case better than we can.
One vendor, and a number you can actually check
Exported tests run on standard runners. You could run it on standard runners from GitHub or similar providers. We also run them for you, and generation, execution, triage and maintenance arrive as one thing rather than four tools you integrate yourself.
The part that matters more than convenience: there are humans on the loop. When the model and the harness can’t resolve something on their own, a person picks it up. That’s not an escape hatch we’re embarrassed about, it’s the difference between a suite that’s maintained and a suite that’s mostly maintained, and “mostly” is where teams quietly go back to fixing things by hand.
Which makes the arithmetic legible. You pay per test and per run. Those are units you can put in a spreadsheet: cost per maintained test against engineer-hours per maintained test, cost per run against what a broken pipeline costs you on a release day. You can decide whether the number is worth it before you sign, and check whether it stayed worth it a quarter later.
That’s unusual, and worth being blunt about. Doing this in-house isn’t free, it’s just uninvoiced. The hours go into someone’s sprint instead of a line item, which is exactly why they never get counted. We’d rather be a number you can argue with.
What we’re risking
We know the failure mode. If the model isn’t good enough, or the harness doesn’t make failures obvious, or the healing doesn’t hold up, then export means you leave and we’ve built nothing durable. Lock-in is insurance against your own product being mediocre. We’d rather not carry the policy.
Every enterprise buyer asks about exit strategy anyway. Answering it in the first meeting is cheaper than answering it in month four.
Try to leave
Generate a suite. Export it. Read the code, run it on your own infrastructure. If it’s the code you’d have written, you already know what the rest is worth.
