Jev-Code-Reviewer

egma-ai's MIT-licensed tool for reviewing a coding agent's own pull requests: a local CLI, an agent skill, and an unpacked Chrome extension, built around one design choice — show a reviewer a behavior change, not a diff, and rank changes so most of them never need reading closely. 81 stars, 1 fork, 10 commits, last updated 2026-09-25.

What it replaces

The stated problem is the one this spoke already tracks from the cost side (stop-burning-tokens-on-code-review): an agent that produces a 230-file PR gets "YOLO merged" because nobody can hold that much diff in their head. Jev's answer keeps a model in the loop on every PR, unlike deterministic-review-gate, which removes the model from the hot path entirely. What it changes is what the reviewer sees, and how much of it demands attention.

How it works

Two model providers split the job, and the tool's own name comes from one of them. TypeSafe (covered independently in ../llm-providers-wiki as typesafe-ai) scores each change unit through its Jev model — the "typed decision" function-call model this spoke's sibling wiki documents in system-one-models-and-jev as "unstructured state in, typed probabilistic decisions out." jev-code-reviewer and its jev-reviewer CLI are named after that model, not the other way round. OpenAI, over the Responses API with Structured Outputs and store: false, writes the prose a reviewer reads — old logic, new logic, what changed, why it might need attention. A local policy file (config/policy.json, a repo's own .jev-reviewer.json, or --policy) turns that evidence into one of three priorities, and the policy's hash is recorded in every report:

P0 — human review required (shown expanded, and by default the only tier shown at all)
P1 — human review recommended (starts collapsed)
P2 — mechanical or well-supported (starts collapsed)

There is no hosted backend and no GitHub App in v1. The CLI (jev-reviewer analyze --pr <url> --repo <path>) reads a local clone and the PR's diff via gh, so it never requests its own GitHub token; an optional context tool, Graphify (installed as the graphifyy package via uv tool install graphifyy), adds related symbols and dependencies when it can find them, and the tool falls back to diff-only context when it can't. Output is a cached report served by a local process (jev-reviewer serve, 127.0.0.1:4731 only) that the Chrome extension reads over a paired bearer token — it swaps GitHub's own diff tables for a P0/P1/P2 badge and an old/new logic view, with the original diff one toggle away, and it works only on the classic /files page, not /changes. Posts nothing to GitHub: nothing here writes a PR comment, so it does not add a second queue to the one stop-burning-tokens-on-code-review found reviewers were already drowning in — the report exists only for whoever opens the extension or the local server.

An agent skill (install/README.md) lets a coding agent call analyze itself right after opening a PR; the docs are explicit that this is best-effort — "not a daemon, webhook, Git hook, or guaranteed listener."

What it does not claim

The architecture doc is unusually direct about its own limits: summaries are "an interface over the code, not an authoritative replacement for it," Graphify's static neighbors "do not prove runtime impact," and analysis "must not imply whole-repository understanding." Only the first 12 diff hunks are analyzed by default (--max-units raises this to 100). Stale reports are never shown once a PR gets new commits — analyze has to be rerun and the report refreshed by hand. And because the tool is not offline, changed code and its nearby context go to TypeSafe and OpenAI; API keys sit unencrypted, owner-only, in ~/.config/jev-reviewer/credentials.json, a choice the README defends because an agent's own shell often can't see environment variables its human's shell can.

Why it's here over llm-providers-wiki

The router's runner-up was ../llm-providers-wiki, which already holds CodeRabbit as a per-model review vendor evaluated on its own terms, and, it turns out, TypeSafe's Jev model itself (typesafe-ai, system-one-models-and-jev). Neither angle fits here: nobody has benchmarked what TypeSafe or OpenAI catch that the other misses, the source makes no such claim, and this page is about the harness built around the model, not the model's own accuracy (that question, and TypeSafe's self-reported 67.8% aggregate figure, stay on system-one-models-and-jev). What Jev contributes to this spoke is the harness shape: a CLI, agent skill and browser extension wired around a local server, aimed specifically at a coding agent's own output. That sits next to claude-security-plugin and deterministic-review-gate as a third answer to where a model belongs in the review loop. It is not removed, the way deterministic-review-gate removes it; it does not post its own PR comments, the way the GitHub Actions setup stop-burning-tokens-on-code-review measured did; instead it triages, so only a fraction of the output (P0) demands a human's first look.

Tier

T1. Everything load-bearing here (commands, architecture, the P0/P1/P2 policy mechanism, the provider split, the stated limitations) is the project describing its own design, checkable against the repository. The tagline ("prioritizes human attention") is marketing framing, not a measured effectiveness claim, and nothing in the source reports how often the priority split is right or how much reviewer time it actually saves; that absence is recorded above rather than folded into the tier.

stop-burning-tokens-on-code-review · deterministic-review-gate · claude-security-plugin · agent-skills · agentic-coding-harness · shipping-without-human-verification · agent-loops-verification · egma-ai · typesafe-ai · system-one-models-and-jev · synthesis