Using Jev as a pre-commit code review CLI

Hybrid 🏃🏾 @markfennerOriginally posted 2026.09.20

Open original on X

I’ve been digging into Jev from @typesafe_ai today. I wanted to understand what it’s useful for, so I built a small CLI experiment around reviewing code changes before a commit. Jev makes focused decisions over text. You provide context and specific questions, and it returns choices, scores or probabilities your application can use. Think routing support tickets, filtering messages by intent, or flagging code changes for closer inspection. Your software handles what happens next. For this test, I used eight constructed code changes. The request: add a dark theme and a debug message while leaving pricing and access rules alone. I included a token leak, a removed access check, an unrelated price increase and a change with missing context. Jev returned all eight classifications in 359 milliseconds through its hosted API, including the network round trip. All eight matched the expectations defined before the run. Repeating the request produced the same labels. One useful distinction: a harmless log message containing the word “token” versus logging the actual session token. My simple keyword rule flagged both. Jev distinguished them. When I removed the original request in a separate check, it returned “needs context.” There was uncertainty too: the accessibility change received a 58% probability for its selected label. That’s worth inspecting, even though the label matched the expected answer. These were constructed examples, not a broad security benchmark. Jev didn’t write the changes, execute the code or approve a commit. I haven’t compared it with another model, so this isn’t a head-to-head speed claim. The workflow I’m exploring is an extra review pass on agent generated changes flagging potential scope changes or security issues alongside existing tests and checks.