Tests that actually run
Point it at your code. It writes tests, runs them with the test runner Node already ships, and tells you what broke — without editing your code to turn a failure green.
How it works
Three steps, and none of them is “configure”.
- 01
Give it the code
A small checkout module is already open, or bring your own. It reads what the code is for before it writes a line.
- 02
It writes, runs, and reads the failure
An unrun test is a guess about what the code does. Every change is executed, and the output is what it reasons from next.
- 03
It says which of two things went wrong
Either the test expects the wrong thing, or the code has a bug. Those have opposite fixes, and guessing between them silently is the worst thing it could do to you.
What it can do
It will not make a suite green by editing your code
This is the rule the whole agent turns on. A failing test comes back with the failing case, what the code does and what it should do. The fix is offered; it is applied only when you ask.
Boundaries first
Exactly at a threshold, one either side, zero, empty, one item, the largest realistic value. That is where behaviour changes and therefore where mistakes live — the middle of a range almost never surprises anyone.
Nothing to install
Node 22 ships a test runner and an assertion module; Python ships unittest. The common cases need no network and no packages, which matters for an agent that iterates.
How it is set up
The mechanics, so you know what you are getting before you sign in.
- Environment
- A Linux container with Node 22 and Python 3. Tests run there, and the output appears in the terminal pane under the file.
- Tools
- Read, write and edit files, glob, grep, and a shell to run the suite with.
- Model
- Any chat model. This one runs a loop — write, run, read, decide — so it rewards a model that reads output carefully over one that writes quickly.
- Starting files
- A small checkout module with two real bugs in it, both boundary-shaped, so the first run reaches the fork the agent is built around rather than finding a clean pass.
- What persists
- Tests are written to a tests directory and stay there. Run any of them again yourself with the Run button on the file.
Things people ask it
- “Write tests for cart.js, run them, and tell me what you found.”
- “Test the free-shipping rule at exactly the threshold, and either side of it.”
- “What is untested in this file?”
- “These tests pass but I do not trust them — what are they not checking?”
What it will not do
Every one of these is a real constraint we have hit, not a roadmap item.
- It stops after the same failure twice and tells you what is stuck. A third attempt at an unchanged error is a loop, not progress.
- It will not weaken an assertion to get past a failure. Loosening an exact amount to an approximate one turns a found bug into a hidden one.
- It tests what you give it. It cannot reach your CI, your database, or a service that is running somewhere else.
Which model does this best
Coming soonWe are aggregating per-model results for this agent — how often a run finishes the job without you stepping in, what it costs, and how long it takes. The numbers go here once there are enough runs for them to mean anything, and all three are published together: a model that finishes fast by giving up is slow to complete, and one that completes everything by grinding is expensive.
Completion rate
Runs that finished the job without you having to step in.
Median cost
What a typical run costs, in credits.
Median time
Wall clock, from the first message to the answer.