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.
Exportable test 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 before you commit, and you can keep it if you leave. Exportable test code is where the conversation starts, but the code alone does not keep a suite working. The rest of this article covers what happens after the file is handed over.
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.
The exit strategy risk we accept
Every enterprise buyer asks about exit strategy, and an AI test automation exit strategy should be judged by how the platform performs, not by how hard it is to leave. We know the failure mode. If the model is not good enough, if the harness does not make failures obvious, or if healing does not hold up, then export means a customer leaves and we have built nothing durable. Lock-in would only hide that weakness, acting as insurance against our own product being mediocre. We would rather not carry that policy. Answering the exit question in the first meeting is cheaper than answering it in month four.
Questions to ask before you choose a test automation platform
Before you commit to any test automation platform, ask a few questions that expose vendor lock-in early. Can your team read the tests and run them without the vendor’s tool? What happens to your suite if you stop paying? Who diagnoses a failing test, and does the failure arrive with enough context to judge it quickly? What does each test and each run cost, and can you compare that number with the engineer hours your team spends maintaining tests by hand? The answers tell you far more about vendor lock-in than any contract clause.
Test your exit before you sign
Generate a suite, export it, and read the code before you sign anything. Run it on your own infrastructure and judge whether it is the code your own engineers would have written. If it is, you already know what the rest of the platform is worth, and you can check whether that value still holds a quarter later.
