Harness? Mr Suricate .
One million new apps per week. That’s the pace claimed by Lovable, the Swedish AI-powered app-generation platform, whose CTO, Fabian Hedin, outlined the company’s strategy to JDN on July 16. The figure he cited illustrates the scale of the phenomenon:
"Projects built with Lovable generate a total of 720 million monthly visits—27 times more traffic than the Lovable website itself."
Most of these apps are created by non-developers, and many go live without any structured QA.
At the same time, Veracode ran 80 development tasks through more than 100 AI models: 45% of the generated code contained at least one vulnerability. For Java, the failure rate rose to 72%. Furthermore, according to GitClear, the average developer committed 75% more code in 2025 than in 2022.
These two curves tell the same story. It no longer costs anything to produce code. But proving that it works does. And that proof now has a name: the harness.
So, where does the word “harness” come from?
The harness in a nutshell: the software layer that surrounds an AI system or model to reliably execute it, monitor it, and verify its results—from orchestrating calls and controlling outputs to generating evidence.
In engineering, a test harness is a test bench: a device that surrounds a system to run it, observe it, and verify its results under controlled conditions. The term used to be a trade secret, reserved for automation teams. It is now becoming central to the field.
In the age of AI agents, the term “harness” refers to the entire layer built around models to ensure their results are reliable: it prepares the context, orchestrates calls, monitors outputs, and corrects errors. We now speak of “harness engineering,” the discipline in which automated verification, evaluation, and deployment controls become the operating system that governs the code produced by AI. The thesis can be summed up in a single phrase: the bottleneck has shifted to the post-code stage. Recent funding rounds in this post-code niche, totaling hundreds of millions of dollars, confirm that investors believe in it.
QA Financial drives the point home in the financial sector: QA is entering the age of evidence engineering. Indeed, teams can no longer simply prove that they have tested. They must show what they tested, why, using which controls, and whether those controls remain valid over time. Regulators and auditors are no longer satisfied with a mere execution report.
Fabian Hedin, at Lovable, confirms this from the other side of the river. When JDN asked him directly what portion of his platform’s quality comes from the models and what portion comes from the harness, the orchestration layer, and tool calls, his answer was clear:
"It's very difficult to achieve the results produced by Lovable simply by using a raw model. This illustrates the value we add on top of these foundational models."
Those who write the code and those who review it come to the same conclusion.
Why a raw model can't test
A language model generates plausible results. A test requires reliable results. The difference becomes apparent every day in UI regression suites.
The market’s number one pain point remains the fragility of test selectors. In fact, studies consistently show that 30 to 50% of QA time is spent on test maintenance. And teams find that 10 to 15% of their end-to-end tests fail after a major front-end deployment. Every cosmetic redesign triggers a wave of false positives, and every false positive erodes confidence in automation.
The market has made its choice: identifying interface elements using natural language, rather than screenshots and traditional selectors. The test targets “the details tab at the bottom of the screen” and remains valid even after redesigns, theme changes, and resolution changes. Even the test’s long-standing providers are adopting this approach, proving that the topic has become indispensable.
However, natural language identification only solves part of the problem. We still need to figure out what to test, how to distinguish a true regression from an intended change, how to run tests in production without corrupting the data, and how to vary test flows across dozens of environments. That’s what the test harness is all about.
The Harness Applied to QA, in Practice
At Mr Suricate, the framework encompasses everything that makes a test reliable—and that no raw model can do on its own: robust element identification, self-healing as the application evolves, false-positive prevention, variability, execution in production (not just in staging), and the accumulated knowledge of real user journeys from Boulanger, Fnac Darty, and Intersport. Years of hands-on experience with real applications, condensed into a single software layer. At B&B HOTELS, several hundred scenarios run continuously to ensure the quality of the booking flows, with product owners able to interpret the results independently.
Every IT department is aware of the financial stakes: a bug discovered in production costs 30 to 100 times more than a bug detected during development. And when automation is properly implemented, it eliminates 60 to 80% of the time spent on manual regression testing. The automation framework transforms these two figures—one into avoided risk, the other into recovered capacity.
That’s where our competitive advantage lies. Any competitor can call the same models we do. They can’t replicate this layer, because it isn’t trained on text—it’s built on millions of test runs against applications that are constantly changing.
The generator cannot be both judge and jury
One objection keeps coming up: if the developer writes the code, they’ll also write the tests. That’s already true, and it’s not enough. A generator that verifies its own output reproduces its own blind spots. At Veracode, CTO Jens Wessling points out the root cause:
“The rise of ‘vibe coding’—where developers rely on AI to generate code without explicitly defining security requirements—represents a fundamental shift in the way software is built” (translation).
The generated code passes the tests that the generator envisions, not the ones that reality demands.
On this point, our position is clear. Independent, black-box testing on real-world, production-environment code remains a distinct need in the industry. As the volume of generated code explodes, this independent verification increasingly becomes the bottleneck in the software development chain. This is good news for those who have been doing this as their profession from day one.
Continued
Mr Suricate invest in this area. Our next projects: exposing our harness to AI agents so they can run test scenarios and consume the results as a service, and making the platform proactive—capable of detecting changes on the client side and suggesting scenario updates before being asked to do so.
This isn't the end of the story—it's just the beginning. And if you want to see how a harness works on your own courses, a demo is all it takes.
Frequently Asked Questions
It is the software layer that surrounds an application or AI model to run tests, monitor results, and ensure reliability. It encompasses component identification, self-healing, false positive detection, and the generation of actionable evidence.
A framework such as Selenium, Playwright, or Appium provides the execution engine. The harness is everything built around it to ensure reliable results over time: robustness in the face of interface changes, the ability to distinguish between true regression and intended changes, and execution in production. Mr Suricate on these three engines and derives its value from the harness.
Because a generator that checks its own output reproduces its own blind spots. Veracode’s tests on more than 100 models show that 45% of the generated code contains a vulnerability that the generator failed to detect. The proof must come from a layer independent of the generation process.
