Before Adopting jcode, Run a 15-Minute Agent-Harness Exit Test
jcode is a new MIT-licensed coding-agent harness written in Rust. That is interesting to a small team because harnesses decide how an agent starts, calls tools, stores state, and leaves work behind. The wrong first test is “Can it solve my biggest issue?” The better first test is “Can I leave after fifteen minutes with portable evidence?”
Use a five-file fixture
Create a tiny repository:
README.mdsrc/add.jstest/add.test.jspackage.jsonEXIT.md
Put one deliberate bug in add.js, and make npm test fail. Ask the harness to repair it without changing the test.
Record four outputs
After the run, fill in EXIT.md:
- Initial commit:
<sha> - Final diff:
<path or git diff command > - Commands executed:
<ordered list > - Verification result:
<exit code and output > - Harness-only state needed to continue:
<none or list >
The task only passes if another developer can clone the resulting repository and verify it with ordinary Git and npm commands. A transcript that only the harness can decode is not an exit artifact.
Force one failure
Repeat the task after replacing npm test with a command that exits 17. The harness should not call the task complete. It should preserve the patch, report the failing command and exit code, and stop retrying after a bounded number of attempts.
This exposes more about the product than a happy-path demo:
| Check | Pass condition |
|---|---|
| Patch portability | Plain Git diff applies cleanly |
| Command evidence | Ordered commands are visible |
| Failure semantics | Exit 17 remains a failure |
| State portability | No proprietary state required to continue |
| Cleanup | No orphan process remains |
Why this matters
A fast runtime is useful. A clever model is useful. But a small builder needs the ability to stop, inspect, and move work elsewhere. That is the difference between adopting a tool and adopting a dependency you cannot unwind.
Limitations
I have not executed this fixture against jcode, so this is an evaluation protocol rather than a product verdict. The repository description calls it an agent harness for code; check its current README and release state before relying on any specific feature. If your test fails, keep the fixture. It becomes a reusable acceptance test for the next harness instead of a one-off opinion.
Comments
No comments yet. Start the discussion.