Before Adopting jcode, Run a 15-Minute Agent-Harness Exit Test

A developer proposes a 15-minute exit test for evaluating coding-agent harnesses like jcode, a new MIT-licensed Rust tool. The test checks patch portability, command evidence, failure semantics, state portability, and cleanup by having the harness fix a deliberate bug and produce artifacts that another developer can verify with standard Git and npm commands.

jcode https://github.com/1jehuang/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?” Create a tiny repository: README.md src/add.js test/add.test.js package.json EXIT.md Put one deliberate bug in add.js , and make npm test fail. Ask the harness to repair it without changing the test. 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. 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 | 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. 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.