Wallaby for coding agents

Coding agents can write passing tests that miss bugs through weak assertions, overlooked edge cases, or checks that mirror the implementation. Wallaby helps your agent strengthen assertions and verify that tests catch regressions.

Wallaby gives your agent live test results, coverage, execution paths, and runtime values to check what the code actually does and build tests that catch regressions.

You can target a file, a directory, or the changes in your branch. For setup options and more example prompts, see the skills documentation.

Free during beta.

How the skills check their work

A test needs an expectation that comes from the intended behavior. When writing a test, the agent predicts its result and the code paths it should exercise, then checks what actually happened. When improving existing tests, it checks whether their assertions would catch plausible defects and identifies missing cases.

Wallaby supplies the evidence for those checks. It runs your existing JavaScript, TypeScript, and Python tests in the background and keeps results current as files change. The agent can see which branches a test reached and what values the code produced, then compare them with its expectations.

Wallaby lets an agent move from a line of code to the tests that cover it, the path they took, and the values produced at runtime.

Beyond pass/fail

Wallaby works with your existing test framework, including Jest and Vitest. The difference is in how the agent investigates a result.

A conventional test runner is built to report the result of a completed run. The agent gets a block of terminal output and then has to search it, run another command, or add temporary logs whenever it needs more detail. The answer may be buried in thousands of lines or missing from the output entirely.

Wallaby keeps the current test state ready and lets the agent open the failure, coverage, trace, or runtime value it needs next.

With Wallaby, the agent starts with a concise summary and requests more detail as needed. It can open one failure, find the tests that cover a source line, or inspect a value from a specific test. Each answer stays focused on the question, using fewer tokens than loading full test-runner output into context.

One test session for the whole task

Wallaby keeps a test session running throughout the task and reruns affected tests as files change. The agent can capture the initial results before editing, check each change, and verify the finished work without starting a new process for each check.

The agent can begin in exclusive mode with tests from selected files. As the task grows, it can add related files or switch the same Wallaby instance to project mode for full-project verification. The test engine keeps running while the scope changes.

The agent can distinguish pre-existing failures from new ones and check for coverage regressions. Assertion details, logs, and stack traces help it investigate failures before the final full-project check.

The agent starts with selected tests, widens the scope as needed, and verifies the full project without restarting Wallaby.

What the tests reveal about the code

A project summary tells the agent whether tests pass. To decide what to change or test next, it needs to know how those tests relate to the code.

Find the tests that cover the code

Before changing a source file, the agent can inspect the whole file or focus on one line or expression. Covering Tests shows which tests reach that code, along with their status, location, and timing.

The agent can read those tests to understand which expectations a change must preserve and where another test is needed. For a test file, Wallaby shows the source files each test exercises.

Before the agent edits discount.ts, Wallaby shows the tests that cover the selected line, an existing failure, and the files those tests also exercise.

Wallaby’s .wcov format puts coverage markers alongside the source. It marks each coverable line as fully, partially, or not covered. On a partially covered line, Wallaby also points to the expression that did not run.

Filter the view to one test and the markers show only what that test covered. The agent can see which path it took and which path it missed before looking at the test setup, assertions, or implementation. This is useful when planning a change and when a test or coverage result is surprising.

Filtered to one test, WCOV keeps the source visible and marks exactly which lines and expressions ran.

Follow one test end to end

When a test behaves unexpectedly, especially in unfamiliar code, the agent needs to see how execution reached the result. The agent selects a test, and Wallaby shows the exact execution path for that test. The status, execution time, errors, logs, and covered files appear alongside the trace.

Wallaby calls this a Test Execution Trace, an agent-readable version of its Test Story. It lists the source lines in the order they ran, even when execution crosses files. The trace separates imports and setup from the start of the selected test, then follows each call into production code and back again. Coverage tells the agent what ran. The trace shows the execution order.

This failing test moves through setup, the test body, discount code, a clock helper, and coupon logic before returning to the failed assertion.

The trace replaces a stack trace and repeated file reads with one ordered path. The agent can find where execution first departs from the expected flow and catch setup or helper code that would be easy to overlook.

Together with test-specific coverage, the trace helps the agent keep the fix small, correct a misleading test, or add the missing case.

What file metrics can suggest

For a broader review, Wallaby reports coverage, test counts and timings, file size, complexity, and change risk. These metrics can help the agent prioritize complex files with weak coverage, investigate slow tests, or decide where a change needs more tests. The agent considers these metrics alongside the task and the surrounding code.

Wallaby uses file metrics to suggest three possible next steps for discount.ts. The agent decides which, if any, fit the task.

For improve, these metrics help identify where to add or revise tests. A higher coverage percentage alone does not show that the assertions are strong enough to catch defects.

Inspect runtime values without changing the code

Tests and coverage can show where a problem occurs, but not always why. The agent may need the value of an expression or variable at one source location. Without runtime inspection, the agent has to form a hypothesis, add temporary logging, and run the test again.

Wallaby lets the agent inspect that expression or variable at the source location without editing the code. It evaluates the selection in every test context that reaches the line and keeps each value tied to its test. If the line runs several times, the agent can narrow the result to one test.

The agent can inspect expressions and variables at several source locations in one request, then compare the values to check its hypothesis.

Wallaby shows the value of order in every test that reaches line 42, then lets the agent focus on the failing test without adding a log.

In our evaluations, the same agent workflows used fewer tokens with Wallaby’s runtime inspection than with temporary logging and conventional test-runner CLI output.

Wherever the coding agent runs

Wallaby is not tied to an editor. Any coding agent that supports skills can use it from a CLI or graphical app, including Claude Code, Codex, GitHub Copilot, Cursor, Windsurf, OpenCode, and Pi.

You can use it in developer-guided sessions or autonomous tasks. Wallaby can run:

• in a supported editor through the Wallaby extension
• alongside any editor in Standalone Mode
• directly in a local project through the Wallaby skills
• inside a container, including a DevContainer
• in the cloud or another remote environment, with agents such as GitHub Copilot Cloud Agent

If Wallaby is already running in your editor, the agent connects to that instance. Otherwise, it starts one in the background. You can open the Wallaby UI to inspect the same test results, coverage, and execution data the agent is using.

Free during the beta

If you are new to Wallaby, activate free local CLI access by running this command in your terminal:

Enter your email and follow the activation link. Then return to your agent and try the skills on your tests.

If you already have a licensed Wallaby editor extension on this machine, you can use the skills without extra activation.

For containers and cloud agents, you need a WALLABY_CLI_TOKEN even with an existing license. This access is also in beta and may require separate paid access afterward. See the cloud and container setup instructions.

CLI activation does not start an editor trial. If you want to try Wallaby in your editor too, you can do that separately:

Once you have tried it, tell us what worked and what did not at hello@wallabyjs.com.