Reproducible failureIllustrative
test_discount.py
def test_discount():
total = apply_discount(100, 20)
assert total == 80Expected 80 received 100
Private developer pilot
Your agent writes code.
arnx puts it
to the test.
Test your change. Keep the evidence.
Before you open or merge a PR, put your change to the test. arnx investigates suspected bugs, runs tests, and gives you evidence to inspect. You decide what matters and keep the useful tests.
Choose supported models. Use your API keys. Pay your providers directly.
A closer look at your change
Show me
the evidence.
the evidence.
A useful test stays with you.
WORKS WITH YOUR PROJECTPython / pytestJavaScript / TypeScriptRust / cargo-nextestMore languages to come
Open source. Your model. Your call.
Read the harness.
Choose the models.
Open source, MIT.
Inspect how arnx reviews your changes. The review package is MIT software, and accepted tests stay as ordinary files in your repository.
BYOM — Bring your own model.
Choose from supported models and providers, connect your own API keys, and pay providers directly. Selected code is sent to the providers you configure.
01 / Test it. Keep the evidence. Bring your own model.
See the failure.
Check the fix.
Keep the test.
Run arnx on your branch before opening a PR, or while reviewing a change before merge. Turn suspected bugs into executable checks, settle unclear intent, and keep accepted tests in your repository.
02 / How it works
Your judgment.
Your agent. A checked fix.
From a change you want to understand
to a test worth keeping.
-
01
Set up once
arnx proposes a Docker environment and runs your existing suite. Inspect the projects, services and exclusions before approval.
arnx setup -
02
Review a change
Inspect failing tests, the second-model assessment, open questions and what was left untested.
arnx review -
03
Decide what matters
Mark findings real, intended or noise. Answer questions about behavior only you can decide.
-
04
Accept useful tests
Keep selected tests before fixing the code. Answers that settle intent can become tests too.
arnx accept <id> -
05
Give your agent the fix
Print a handoff with accepted findings, answers and tests. You or your coding agent change the production code.
arnx prompt <id> -
06
Check. Then keep.
Run accepted tests in the approved sandbox. Inspect and commit the tests together with the fix.
arnx check
03 / Show me the evidence
Something you can run.
A decision you can make.
Illustrative examples.
Not captured arnx output.
A failure to inspect
Illustrative
test_discount.py
total = apply_discount(100, 20)
assert total == 80
Expected: 80
Received: 100The discount wasn't applied. Run the test and inspect the assumption behind it.
A question for you
Illustrative
What should happen when a promo code has expired?
- Reject it with a clear error.
- Continue without a discount.
The code alone can't settle the intended behavior. You decide.
A test to keep
Illustrative · after a fix
test_discount.py
total = apply_discount(100, 20)
assert total == 80
✓ 1 passedKeep the accepted test with the reviewed fix. It stays ordinary code in your repository.
The workflow / illustrative
# Inspect findings. Mark what matters. Answer questions.
$ arnx review
$ arnx accept <id>
$ arnx prompt <id>
# Give the prompt to your coding agent. Inspect its fix.
$ arnx check
Questions before
assumptions.
04 / A real run · October 14, 2026
From a real finding
to a checked fix.
On a Python data pipeline backed by Postgres, arnx reproduced problems including an inverted Gini calculation, lost callouts after a page limit, and prices drawn from the wrong point in time.
The owner marked 18 findings real and answered questions about intent. Their own coding agent received arnx's fix prompt and changed the product code.
The accepted test files stayed unchanged after acceptance and remained in the repository.
Read the pilot case studyFINAL ACCEPTED-TEST CHECK
54
passed
0failing
1skipped
One owner-run development case. Two known issues were missed. These results demonstrate the workflow, not a general accuracy rate.
05 / Fits your development workflow
Your repository.
Your tools. Your keys.
Single packages and repositories with multiple projects. We'll check fit during pilot onboarding.
Py
Python
pytest
JS
JavaScript / TypeScript
vitest, jest, node:test or bun
Rs
Rust
cargo-nextest
More languages to come. Tell us what you use when requesting a pilot invite.
Docker and your own model-provider API keys are required. Selected code is sent to configured providers. Accepted tests remain ordinary files in your repository.
Where does arnx fit in a PR workflow?
Run the CLI on your change before opening a PR or during review, before merge. arnx generates and runs tests for suspected bugs. You inspect the evidence, accept useful tests, and hand the fix prompt to your coding agent. Then arnx checks the fix with those tests. The current pilot is a developer-run CLI workflow; it does not post PR comments or provide a hosted GitHub check.
What does “bring your own model” mean?
Configure supported models for arnx's review workflow using your own provider API keys. You pay those providers directly. Model choice depends on the supported provider and role; BYOM does not mean every model or a local model can run in arnx. Selected code is sent to your configured providers.
Is arnx open source?
Yes. The arnx review package is MIT software. You can inspect the harness, and accepted tests remain ordinary, editable files in your repository. Open source does not make model-provider API calls free.
Does arnx fix my code?
You or your coding agent make the fix. arnx retains accepted tests, prepares the fix prompt and runs the tests to help you check the result.
Is a finding always a bug?
No. A repeated failure and a second-model assessment give you evidence to inspect. The test can still make a wrong assumption. You decide whether the behavior is a bug, intended, or noise.
Does a clean result mean the change is correct?
No. Read open questions and coverage gaps. A passing
arnx check means the accepted tests passed in that
environment. Questions alone can still leave a review with exit
code 0.
Where does my code go?
Tests run in local Docker containers. Selected code goes to
configured model providers. Recognized secrets are filtered;
inspect .arnxignore for repository data and sensitive
files. Read accepted tests before running them through your own
tooling.
What does it cost?
The arnx package is MIT. You pay your model providers directly. In
the documented Opus pilot, setup, review and acceptance totaled
$5.36 in reported model spend. The fixing agent's cost was
separate and unrecorded. Each
arnx check made no model calls. This is one example,
not a typical-price estimate. We'll agree a spend cap before your
first run.
How do I get it?
Request a pilot invitation below. Selected participants receive instructions for the chosen pre-release build. Docker and model API keys are needed; an existing coding-agent subscription should not be assumed to cover API calls.
Private developer pilot
Bring a change
you can judge.
We're preparing a pilot with 5–10 selected developers. Bring a repository and a change you understand. Help shape the first version by using it on work you would actually ship.
- Setup support for your repository
- An agreed model-spend cap before the first run
- Your feedback on findings, questions and tests worth keeping
LET'S PUT YOUR NEXT CHANGE TO THE TEST.
Request a pilot invite
Tell us where to reach you. We'll follow up about your project and pilot fit.
Prefer email? [email protected] ↗