Four coding agents finish within the same hour and open four pull requests. One touches a billing retry path, one renames a test helper, one adds a migration, one fixes a README typo. The bottleneck is not the code or the tests. It is the question a person answers before reading a single diff: which of these do I look at first? We have argued that human review is the bottleneck once agents run in parallel. This post covers the mechanical part of that problem, ordering the queue, and how a decision model like Jev can take it off the reviewer’s plate without taking the review.
What Jev is
Jev is a System One Model from TypeSafe AI: you send it a piece of state and a set of typed questions, and it returns an answer for each question with a calibrated probability, never free text. To be clear about the name, this is Jev the TypeSafe model, not the YouTuber or the Japanese encephalitis vaccine. TypeSafe’s launch post describes it as “unstructured state in, typed probabilistic decisions out.” The API is one endpoint, POST https://api.typesafe.ai/v1/systemone, Bearer key, model jev-latest, three question types: noul (yes/no probability), choice (one pick from up to 255 options), and score (a position on a rubric of 2 to 10 levels). Text only, 64k tokens per request with 32k for the state, $0.042 per million input tokens, output not charged. Our sibling post on Jev as a decision layer for coding agents covers the model in general; here we use it for one job.
The three review questions
Every PR a coding agent opens raises the same three questions, and each maps to one primitive. The state is the same for all three: a diff summary, the test outcome, and the touched paths. Not the full diff. A summary keeps the call under budget and keeps the model answering the routing question instead of re-reviewing the code.
Does this need a person before merge? A noul. This is the filter. It decides whether a PR enters the human queue at all or waits in a low-priority lane.
Which reviewer or queue? A choice over the queues your team actually runs. The answer carries the pick plus the full distribution, so a 0.48 / 0.44 split between two queues tells you the PR straddles an ownership boundary, which is itself worth knowing.
How much risk does it carry? A score on an ordered rubric. The result is a probability-weighted position, so a change can land at 2.6 between “logic change covered by tests” and “touches auth, billing, or data.” That number is the sort key for the queue.
One request answers all three:
{
"model": "jev-latest",
"state": {
"task": "SH-418 Fix double charge on retried webhook",
"diff_summary": "billing/retry.ts adds an idempotency key check; new test covers the retry path",
"tests": "58 passed, 0 failed",
"touched_paths": ["billing/retry.ts", "billing/retry.test.ts"]
},
"questions": {
"needs_human": {
"type": "noul",
"instructions": "Does this change need a person to read it before merge?"
},
"queue": {
"type": "choice",
"instructions": "Which review queue owns this change?",
"criteria": {
"payments": "billing, invoicing, refunds, retries",
"infra": "deploy, migrations, config",
"frontend": "UI and client code",
"docs": "documentation and comments only"
}
},
"risk": {
"type": "score",
"instructions": "How much damage can this change do if it is wrong?",
"criteria": ["cosmetic", "logic change covered by tests", "touches auth, billing, or data"]
}
}
}
The response is three typed answers under the same keys. For SH-418 expect needs_human near 0.9, queue picking payments, and risk near the top of the rubric. A billing retry fix with green tests still goes to the front of the payments queue, because green tests do not answer “should a person read this.”
Thresholds and what each band does
A probability is only useful once code turns it into an action. The bands below are a starting point, not a recommendation for your repository; tune them after a week of runs.
needs_human |
Action |
|---|---|
| 0.85 and above | Front of the human queue, sorted by risk descending |
| 0.15 to 0.85 | Human queue, sorted by risk, after the band above |
| below 0.15 | Low-priority lane; a person still merges, on their own schedule |
Two rules keep this honest. First, risk at the top of the rubric always promotes a PR into the front band, whatever needs_human says. A model that is 0.12 confident a schema migration needs review has seen a tidy diff summary, not production. Second, a choice whose top two options sit within 0.1 of each other routes to both queues, not to neither. Ambiguity about ownership is a reason for two people to glance at a change, not for zero.
Notice what stays with the person in every band: the merge. The bands change reading order and reading depth. They never change who decides.
Use Jev for the queue, not for the verdict
Use Jev when the question has a fixed set of answers, the state is a faithful summary, and you want to spend a human’s attention in a better order: who reads this, how soon, in which queue. Those questions come up on every PR and are cheap enough at this price to ask on every run.
Use a person, or a language model that can show its reasoning, when the question is whether the change is correct. A probability that a change needs review is not a review. Jev has no compiler, no test runner, and no access to the file it is scoring, only the summary you sent. A 0.96 on “safe to merge” is a strong reason to put that PR at the top of someone’s list, never a reason to skip the someone. The approval gate sits after the model, and the model has no way to open it.
What the community built
Within days of launch, a developer published jev-review, which its README describes as “a small code-review workflow built with TypeSafe Jev.” It reviews either a Git diff or a whole codebase, screens for correctness, security, reliability, compatibility, and test coverage, selects code regions before scoring impact, applies thresholds and workflow policies in code, and shows the results in a local dashboard. The README is careful about scope: it calls the project “an experiment in composing fast typed judgments into a review workflow” and says it “does not yet integrate compiler diagnostics, static analyzers, repository indexing, or generated explanations.”
Two things in that design are worth copying: orchestration lives in code and Jev only answers bounded questions, and the work is staged, pick a region, then score it, instead of one giant question over the whole diff. Jev is also on Vercel AI Gateway as typesafe-ai/jev through experimental_evaluate in AI SDK 7; the Gateway docs note this is available through the AI SDK only.
Where this sits with Sharkly
Sharkly does not call Jev for you, and it is not a decision model. It is the shared task, Computer, context, and review layer around the coding agents your team already runs. What a ranked queue needs from that layer is a place to run and a place to land.
The place to run is an Automation: a Space-owned rule that starts an Agent with a set of instructions on a trigger, and one trigger is a task moving into a chosen status. Point it at the status your Agents reach when a PR is open, and the instructions become: read the Task’s diff summary, test result, and touched paths; call Jev with the three questions; write the answers and the band back as a comment on the Task; set a label for the queue. The docs are explicit that a completed run “is not a promise that every downstream business outcome was correct,” which is the same boundary the review bands draw.
The place to land is the Task itself. The band, the queue, and the risk score return to the Task where the reviewer already looks, next to the run’s change summary and verification results. A person opens the board sorted by risk and sees why each PR sits where it does. Agents open the pull request, run the tests, and report. People read in the order the queue suggests, and accept or reject. The order came from a probability; the decision did not.
If you are already running several agents and the review queue is what hurts, that is the workflow getting started with Sharkly sets up: one Computer, one Agent, one Task with the evidence a ranking needs.
FAQ
Can Jev read the whole diff instead of a summary?
It takes up to 32k tokens of state, so a small diff fits. Send a summary anyway: agent diffs blow past the budget, and a summary keeps the question at the routing level. The full diff is what the human reads, with task-level evidence beside it.
What if the agent wrote the diff summary itself?
Then the summary can be wrong in the agent’s favour, and the ranking inherits that. Prefer a summary produced from the diff by a separate step, and always let a top-level risk score override a low needs_human. The limits of AI code review apply here: the model can rank what it is shown, it cannot verify what it is not.
Does a low band mean the PR merges automatically?
No. A low band means a person merges it later, on their own schedule, without reading it first in the queue. Ownership of the merge, and of the work the agent produced, stays with a named person in every band.
Is Jev free through Sharkly?
Sharkly does not resell Jev or any model; you bring your own TypeSafe or Gateway key, the same way runs bill against the subscriptions attached to your Runtimes. Sharkly itself is currently free for organizations of up to 10 people.
