Stanley Code

How we reviewed this: we built and tested it in Docker on three Node versions, read the workflow and delegation paths, and traced what happens to text supplied on standard input. We made no Jev calls and did not let a delegated agent run.

What it does

Stanley, by Dev Agrawal (renamed from jev-code to avoid confusion with TypeSafe’s own naming), runs bounded workflows for coding agents. Jev routes your request to a workflow with one Choice, then answers small fixed-option questions about evidence:

How does diff hunk ${hunk.id} relate to the stated task? · Does test hunk ${hunk.id} weaken what the test expects? · What security disposition best fits this changed hunk?

Code does the rest — chunking, file classification, exact signals like test.skip, every threshold, and a routing confidence gate. The model never writes prose and never draws the final conclusion.

The discipline is real and it is documented: every workflow declares budgets (requests, input tokens, wall clock) that are enforced centrally; redaction runs through the same path before sending and before writing to disk, and includes substituting the literal value of your API key; credential-shaped paths are dropped from evidence entirely; the SDK’s logging is switched off with a comment explaining that debug logs contain request bodies. There is an architecture decision log.

The delegation path is the weak point

Built-in workflows carefully mark untrusted evidence and even ask a probe question about whether the content contains instructions. The delegation path does not: text supplied on standard input is interpolated straight into the instructions given to a coding agent, with no policy wrapper and no probe.

That agent is launched with approvals disabled and your full environment, for up to ten minutes, able to write files and run commands.

The trigger is the project’s own documented usage — piping review comments from a pull request into the tool and asking it to implement the fixes. Whoever wrote those comments is writing part of the agent’s instructions. We verified the text arrives unmodified; we did not let the agent act on it.

Two related gaps: the guard that fingerprints workflow files doesn’t cover what those files import, so editing an ordinary repository file that a workflow imports gets top-level code executed on the next run with the guard reporting no changes; and the check that an improvement worker touched nothing outside its candidate directory uses a git status without --ignored, so writes to ignored paths — node_modules, dist, .env — are invisible to it.

It doesn’t run on its own minimum Node

Node	pass	fail
24	196	0
22.23	177	19
22.18 (the declared minimum)	177	19

The failures are a module-shape check that behaves differently across Node versions, and the effect is that every repository workflow is quarantined with a single warning line on stderr — which is the entire “repository workflows” feature, plus candidate promotion and the self-improvement loop. The project’s CI matrix includes those versions, so it must be failing there too.

Verdict

Read this one for its habits: the decision log, the redaction path, the budgets, and the way evidence is marked untrusted. Those are the parts other projects here are missing.

Then treat the delegation path as what it is — an agent with approvals off, taking instructions partly from whatever you piped in — and don’t point it at text strangers wrote until that’s fenced.

For the same job with a different posture, see Foreman and Abide.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.