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.md src/add.js test/add.test.js package.json EXIT.md Enter fullscreen mode Exit fullscreen mode 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: - Final diff: - Commands executed: - Verification result: - Harness-only state needed to continue: Enter fullscreen mode Exit fullscreen mode 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.