Jev Review: Code Review Triage With Scored Dimensions
Scores, not prose: how two Jev Review tools, a GitHub Action and a flash-review engine turn code review into typed signals a coding agent can act on.
AI code review usually means a model reading your diff and writing comments. That is useful, but it is slow, expensive per pass, and hard to compare between rounds. Did the second draft actually improve, or did the reviewer just phrase things differently?
Several projects built on Jev, TypeSafe AI's decision model that returns typed scores and choices, take a different route. They score a change against a fixed set of dimensions and let a coding agent or CI job decide what to look at next. Jev does not explain a low score, and none of the tools claim otherwise. This article walks through five of them, all listed on the Awesome Jev radar, and is careful about what each does and does not establish.
Key Takeaways
- Scores are triage, not verdicts. Both leading tools state that findings are review prompts and that scores do not prove correctness.
- Two projects share a name. Two different repositories are both called jev-review, with different designs (an MCP tool and a triage dashboard).
- Deltas are the feature. One tool returns per-metric changes between review rounds, which is hard to get from prose.
- No compute-savings proof exists. Claims that triage lets you call a big model less often are not backed by a controlled comparison.
- Star counts vary widely: 241, 111, and then a long tail of 1 to 2 as of September 2026.
Two tools named jev-review
devagrawal09/jev-review (aiskill.market listing, 241 stars) is a triage engine with a staged workflow. Its README describes a sequence from a risk matrix, through file profiling, evidence selection and mechanism classification, to a severity score and an optional reviewer routing step. It supports two modes: change review of a Git diff, and a scan of all non-ignored source files. It screens five areas: correctness, security, reliability, compatibility and test coverage. Results appear in a local dashboard bound to 127.0.0.1:4317.
What it says it does not do is as informative. It does not yet integrate compiler diagnostics, static analyzers, repository indexing or generated explanations, and its README notes that "findings are review prompts, not proof of a defect." The site's own review adds that nothing establishes that a large model is called only for high-risk changes.
NiazMorshed2007/jev-review (listing, 111 stars) is an MCP tool named jev_review. It accepts a task description, a focused diff, optional complete files and repository context, and optionally a previous evaluation. It scores up to 19 dimensions: fifteen assessed always (including correctness, readability, coupling, security and testability) and four only when evidence exists (performance, scalability, compatibility, observability).
The distinctive part is the comparison. Supply the previous evaluation and you get per-metric deltas, unresolved weaknesses and a comparison to the baseline. An agent can loop: change code, re-score, see which metrics moved. The README is explicit that Jev returns scores rather than prose, so the coding agent must diagnose causes itself, and the API has a state ceiling of roughly 32,768 tokens, so large changes must be split into slices.
A review action without a text model
fatwang2/jev-review-action (listing) is a GitHub Action that classifies pull requests. You define the criteria in .github/jev-review.json as yes/no checks and categories, and Jev returns typed judgments. Comments come from a fixed template: "There is no text-generation model, autonomous agent, or hosted bot server."
Outcomes are recommended, needs-review, not-recommended, error or skipped. Limits from the README: up to ten catalog entries per PR, source files capped at 100 KB each, a 48,000-character maximum per review, no caching, and no power to merge or close. Ambiguous cases go to a human. It had 1 star as of September 2026, and its policy examples are oriented to reviewing submissions to awesome-style lists rather than general code.
Flash review and frontend QA
TheBous/jev-flash-review (listing) is local-first: the engine never reads your repository. The calling agent supplies the unified diff and business context, and gets structured verdicts back: a full results matrix, a separate list of confirmed violations, and per-rule answer, probability, confidence and severity. It ships three skills (review-pr, review-free, review-loop) and needs Node.js 24+, a TypeSafe key and the authenticated gh CLI. It had 1 star.
Nainish-Rai/jev-frontend-qa (listing) applies the pattern to browser QA. Its README reports that a live acceptance run passed for synthetic reference scenarios: healthy creation, lifecycle and validation passed, and all three deliberately broken variants failed their authored contracts. That is a test of its own fixtures, not evidence about your app. It had 2 stars.
What to do next
- Use scores to route attention, not to approve. Ship nothing solely because a dimension scored well.
- Try the delta loop with the 111-star MCP tool on a small refactor and see whether the per-metric changes match your own judgment.
- Set your own policy in the review action rather than trusting default questions.
- Compare with routing in Routing by Difficulty, and read How to Evaluate Jev Projects Honestly before adopting anything one or two stars deep.