AI coding agents work in write-test-fix loops. That loop requires fast feedback. Deploying to a Salesforce org takes 5–10 minutes per iteration - longer than most agents are willing to wait. Nimbus runs tests in under a second.
Every modern language has a sub-second test loop. Python, TypeScript, Go, Rust - an AI agent can generate code, run tests, read the failure, fix the code, and rerun in under 30 seconds per iteration. That tight loop is what makes agentic coding work.
Apex didn't have that. Running tests meant authenticating to a Salesforce org, deploying code, waiting for the platform to execute, and downloading results. 5 to 10 minutes per iteration - if nothing goes wrong. An agent writing Apex either skipped testing entirely or burned through tool calls waiting for the org to respond.
Nimbus closes that gap. Tests run locally, in-process, against an embedded database. The same iteration that takes 10 minutes with an org takes under a second with Nimbus. Apex is now a first-class language for agentic workflows.
Nimbus is a CLI. If your AI tool can run a shell command, it can run Nimbus. No API key, no plugin, no configuration beyond pointing at your project.
Runs in your terminal, reads your codebase, writes and runs code autonomously. With Nimbus, it tests every change without leaving your machine or waiting for a deploy.
AI-native editor with inline code generation. Nimbus watch mode closes the loop - Cursor writes, the file saves, tests run, Cursor sees the result.
Generates Apex inline in VS Code. The Nimbus VS Code extension runs tests immediately after Copilot completes a suggestion - no manual trigger required.
Terminal-native agent from sst. Reads AGENTS.md verbatim and speaks MCP, so nimbus skills install drops the right bundle and nimbus mcp wires up the test loop.
Amazon’s agentic IDE. nimbus skills install writes per-skill steering files into .kiro/steering/, loaded on demand via #skill-name in the prompt.
Pair-programming CLI. The Aider bundle concatenates every nimbus skill into a single CONVENTIONS.md, loaded with aider --read CONVENTIONS.md.
If it can run a terminal command, it can run nimbus test. No credentials, no browser, no org. Just a binary and a project directory.
Claude Code operates as an autonomous agent in your terminal. Give it a task - "add a before-insert trigger that enforces uniqueness on Account.Name" - and it writes the trigger, writes the test, runs Nimbus, reads the failure, fixes the code, and reruns until tests pass.
Without Nimbus, that loop requires Claude Code to either skip testing or deploy to a Salesforce org - which requires credentials, authentication, and 5+ minutes of platform time per iteration. Most agentic Apex workflows just skipped the test step entirely.
With Nimbus in the project, Claude Code discovers it via the CLAUDE.md file and uses it automatically - the same way it uses Jest for JavaScript or pytest for Python.
Over MCP (nimbus mcp), a failing test comes back as a structured diagnostics object - exception type, the exact assert file and line, the real expected vs actual values, and the tail of SOQL and DML the test ran before it broke - so the agent can fix it in one shot. The full tool surface is below.
# CLAUDE.md
## Running tests
Use Nimbus to run Apex tests locally - no org required.
```bash
# Run all tests
nimbus test
# Run a specific class
nimbus test "MyTriggerTest.*"
# Run and watch for changes
nimbus test:watch
```
Tests run against an embedded local database.
Each test is isolated in its own transaction.
Results appear immediately - no deployment needed.CLAUDE.md to your project root and Claude Code will use Nimbus automatically for all Apex test runs.nimbus mcp speaks Model Context Protocol over stdio. Register it once and the agent calls the runtime directly - structured JSON in, structured JSON out - instead of scraping terminal text and guessing at what it means.
Eleven tools. The runner initialises once at startup, so every subsequent call reuses a warm database and a parsed project rather than paying setup cost per invocation.
explain_failure and triage_failures return exactly what nimbus explain and nimbus triage print - the same code path, not a parallel implementation. An agent and the human reviewing its work never get divergent accounts of the same failure. What that analysis does and does not claim is written up on the failure intelligence page.
Payloads are bounded on purpose. max_failures, max_tests_per_cluster, and survivors_only cap what comes back so a five-hundred-failure run cannot blow the context window. The true counts are always reported alongside the truncated lists - less listed, nothing hidden.
# Register the server with Claude Code
claude mcp add nimbus -- nimbus mcp
# Or start it directly - stdio JSON-RPC
nimbus mcp --parallel 4
# Coverage is collected by default, so get_coverage
# answers after every run without a second pass.
nimbus mcp --coverage=false # opt outThe loop itself. Run by pattern, then read per-class line coverage and per-test governor usage from that same run — limits that scale with record count are the signature of un-bulkified code.
One failure in structured form — exception, source location, the assertion’s expected and actual operands, the tail of SOQL and DML before it broke. Or a whole wall of failures grouped by the cause the engine recorded, not by matching message text.
Probe the local database without leaving the loop. Anonymous Apex runs in a fresh transaction that is rolled back afterwards; query is read-only by construction; describe_schema reads loaded metadata and runs nothing.
What a change to one class can reach, and whether the tests over it assert anything. query_graph is reachability for navigation — it returns its own limits, and it is never a set of tests that is safe to skip.
When you're working alongside an AI agent - reviewing its output, guiding its direction - watch mode keeps the feedback loop running without either of you having to trigger it manually.
The agent writes code, saves the file, and the test result appears immediately - in the terminal, in VS Code, or in the Dev UI in your browser. You see what passed, what failed, and what the agent should fix next, without switching context.
# Start watch mode before handing off to the agent
nimbus test:watch
# Agent writes AccountTrigger.cls, saves it.
# [14:23:01] AccountTrigger.cls changed
# Running AccountTriggerTest... ✗ 1/3 (44ms)
# testUniqueNameEnforcement: Expected exception, got none
# Agent reads the failure, fixes the trigger, saves again.
# [14:23:09] AccountTrigger.cls changed
# Running AccountTriggerTest... ✓ 3/3 (41ms)
# No commands needed between iterations.
# The loop runs itself.AI-generated code still needs a quality gate before it merges. Nimbus in CI gives you that gate without a connected org - the same test run the agent used locally, now enforced on every PR.
nimbus-solution/setup-nimbus@v1 puts the binary on the runner in one step, so the workflow that checks an agent’s pull request is the workflow the agent could have run itself.
JUnit XML output integrates with GitHub Actions PR annotations. Cobertura coverage integrates with Codecov. An agent that writes undertested code will fail the coverage gate, same as a human would.
# .github/workflows/apex.yml
- uses: actions/checkout@v4
- uses: nimbus-solution/setup-nimbus@v1
- name: Test agent-generated Apex
run: nimbus test --results-xml results.xml
- name: Upload test results
uses: actions/upload-artifact@v4
with:
name: test-results
path: results.xml
# PR annotations show exactly which tests failed
# and which lines the agent forgot to cover.MCP exposes the primitives. A skill is the short playbook that tells the agent when and how to reach for them - which is the part an agent would otherwise rediscover from scratch every session, at your expense, and get slightly wrong each time.
nimbus skills fetches the curated set from nimbus-skills and writes it where your agent will actually look. It detects the agent from the project itself - .claude/, .cursor/, .aider.conf.yml, AGENTS.md, .kiro/, opencode.json - and each target gets the right shape: per-skill directories for Claude Code, steering files under .kiro/steering/ for Kiro, one concatenated CONVENTIONS.md for Aider. Override with --agent.
Ten skills today, versioned in the open. They are maintained against the shipping CLI, so an agent following one is not working from a snapshot of last quarter’s flags.
# What exists, and what this project already has
nimbus skills list
# Install one, or the lot
nimbus skills install fix-failing-apex-test
nimbus skills install all
# Where did it land?
nimbus skills path
# Pin the target instead of detecting it
nimbus skills install apex-tdd --agent cursor
# Claude Code: install for every project, not just this one
nimbus skills install all --global
# Take it back out
nimbus skills remove fix-failing-apex-testThe inner loop. Run, read the failure, narrow to the suspect file, edit, re-run — until green. With hard rules against the usual escape hatches (deleting assertions, swallowing exceptions, weakening the test).
Set Nimbus up on a fresh SFDX project. Init, doctor, schema sync, stub gaps, the first green run, and a CI snippet — in that order, stopping only at decision points.
Raise coverage by writing targeted tests for uncovered branches, not theatre. Reads the per-line coverage Nimbus collects on every run and picks the highest-leverage gap first.
Documentation an agent has to parse out of rendered HTML is documentation it will quote back to you wrong. So every page here ships a Markdown twin: append .md to any URL and you get the same content as plain text. testnimbus.dev/explain for people, testnimbus.dev/explain.md for agents. Sending Accept: text/markdown to the clean URL returns the same file, so a well-behaved client needs no rewriting rule at all.
/llms.txt is the entry point: what Nimbus is, what it runs, and a linked index of every page - already in Markdown. One fetch gives an agent enough to answer questions about the tool without crawling the site or guessing from a model snapshot.
# The whole site, indexed, in one file
curl https://testnimbus.dev/llms.txt
# Any page as Markdown - append .md
curl https://testnimbus.dev/explain.md
curl https://testnimbus.dev/docs.md
# Or just ask for the content type
curl -H "Accept: text/markdown" https://testnimbus.dev/explain/.well-known/mcp/server-card.json - transport, install command, and the tool list above.One command. No org. No credentials. Your AI agent can test Apex the same way it tests every other language.