Heal · Pierre Oucif · October 29, 2026

Give your coding agent a verification harness to check its code

Verification is the bottleneck. Give the agent somewhere to run the code.

Addy Osmani's Agentic Verification makes the case in one line: "I would always prefer a much better feedback loop to a slightly better model." A coding agent that can only read the code guesses. One that can run the product and use its interfaces and APIs can check and iterate. This is what a CI pipeline is, but placed inside the agent's session, and running in shorter cycles. We call that a verification harness.

At Heal the harness did not start as a product. It started as a question our engineers put to Claude Code in most sessions: what do you need to test your code?

Five weeks of answers became a Docker mode in the backend, a replay mode in the agent, integration specs that combine both, and a bench that drives a real Vercel sandbox. This article is about building that harness: what it is, how we designed it, what it caught, what changes when the same model runs with and without one, and why Heal now automatically builds one for every codebase.

TL;DR

A verification harness is three things, made available to a coding agent, so it can verify its code. Verification tools: a linter, a test framework with tests, a live browser, the app running on seeded data, a stand-in for every vendor. Context: what the tools are and how to drive them, what was already verified and how, the heuristics on where to look. Rules: a grader the agent does not control and cannot cheat: end-to-end, integration, and script-based checks.
Heal's own harness came from one question we ask Claude in most Claude Code sessions: what do you need to test your code? Five weeks of answers became an early version of the harness that catches the bugs that used to reach staging or production.
A verification harness is cheap to build now that code is cheap with AI. Our assumption is that most engineers do not build one the right way, or deeply enough, for lack of time or of expertise on the topic.
Most repositories have no harness, so Heal built an agent that builds one. The Heal Sandbox is one implementation. The end game is a harness tailored to each codebase, in the local workflow first, and in Heal's cloud for convenience and scalability.

1. What a verification harness is

A verification harness is three things, made available to a coding agent, so it can verify its code.

2. How Heal's harness was built

Heal's agent runs long tasks over LLMs and reports them to a backend, so many of its bugs showed up only on staging or in production. The stack already had broad test coverage, and it was not enough.

Over five weeks the engineers answered that with one habit: ask Claude Code what it needs to test its code, or say how to test it locally, and let it build a first harness version.

Figure 1. Heal's stack before the harness: thousands of unit tests and integration tests on real stores in the backend and the agent, none in the frontend, and still 29 escapes in 90 days. That is why the question kept being asked.

Figure 2. Ten asks and what each built, out of fifteen between 28 September and 23 October. The replay mode, the Docker box and the first recording were asked and merged in one morning.

Part of the harness lives inside the production code

The harness is kept decoupled from the production code as much as possible. In our specific case, two parts of the harness could not be completely decoupled:

Calling Anthropic is hard to mock, because HTTP calls have complex responses with tool definitions, cache, etc. We deemed this low value because this essentially checks that the Claude SDK is well configured.
Replaying a large set of different call options to mock agent behavior takes investing in a mechanism to record and replay calls (e.g. recording with a mock server).

So we used two patterns to deal with this part of the system: dependency injection, and ports and adapters. This was applied to:

the call site where the app is wired to the Claude SDK: the Claude SDK is stubbed with a static local replay from production;
production sandbox runtimes, replaced by a Docker container.

This is controlled by an env var, so the same binary runs in production and in a test, and a verification harness reaches into the production code without a fork of it. Locally, we can also toggle between the stubs and the real dependencies.

Figure 3. The port-and-adapter pattern on Heal. An env var controls what gets called.

3. What the verification harness caught

Let's take a look at six examples the harness caught before merge that used to reach staging or production, and what it would have cost if shipped.

After a fix, the agent's re-check verdicts never reached the customer's dashboard

Caught by: a real run replayed against the real backend, on the test's first run

Impact: customers never told which bugs their fix closed; hours of re-checking by hand

1 / 6

Figure 4. Examples: six bugs caught before merge. They were not caught by unit tests because they sit between the agent and the backend.

4. A little data on harness performance

Public bugfix benchmarks indicate that allowing the agent to run the product dramatically improves performance, together with naming the bug to fix.

Our evaluation on more complex harnesses points in the same direction.

Public benchmark

Benchmarks indicate running and naming bugs dramatically improves performance.

Setting	What the agent gets	Public benchmark	Best public score
Source only	the repository, hidden tests, no hints	SWE-sweep, 4,100 real bugs in 100 repositories	9.5 %
The product running	the app, a browser, an area named	SWEeper-Bench, one obvious bug per task, LLM judge	59 %
The bug described	the above, plus the bug's description	SWEeper-Bench	96 %

Ours (small sample)

We reproduce it on complex products with the sandbox.

Setting	What the agent gets	Ours, Claude Opus 5.5
Source only	the repository, hidden tests, no hints	8 % on Cal.com, 10 % on Infisical, the feature named
The product running	the app, a browser, an area named	28 % and 20 %, 5 to 9 bugs per feature, hidden tests

From the source alone a frontier model fixes under a tenth of real bugs. With the product running, several times more. With the bug described, nearly all. A verification harness is what moves an agent up that ladder. Our approach automatically builds one, regardless of system complexity.

5. The Heal agent: from a hand-built harness to an agent that builds one

Most repositories don't have a verification harness. The idea behind Heal's agent came from there: if an agent builds the missing piece when asked, one at a time, an agent can be asked to build all of them on a repository it has never seen, and then use them.

Figure 5. A run of the Heal agent produces a verification harness.

Heal's agent has built a verification harness on hundreds of products and filed tens of thousands of high-impact defects. We analyzed what the agent had to build to create the verification harness on a small subset (21 products):

Figure 6. The most common additions the agent makes to build a verification harness.

6. Where Heal fits

Verification harnesses can be built manually, over time. Heal's agent does it automatically in order to run its bug and vulnerability hunter.

On a new repository Heal scores what is already there against its requirements, and builds the parts that are missing. A big part of that is the Heal application sandbox, the part of the harness that allows running the app in a way that closely mimics production. That application sandbox is a verification harness designed for identifying bugs and vulnerabilities, but can also be used by coding agents.

The end game is not one sandbox shape for every repository. It is a harness that fits each codebase: the tests it has, the ports its code already exposes, the vendors it calls, the way it boots. That harness belongs in the local workflow first, where the agent that wrote the change can run it before the push, and the same harness runs in Heal's cloud when a team wants the hunt and the referee on every commit. Try it on your repo, or read how it compares with code review bots in our benchmark.