{"slug": "building-a-cheaper-review-loop-for-coding-agents-using-jev", "title": "Building a cheaper review loop for coding agents using Jev", "summary": "TypeSafe's hosted classifier Jev cleared 41 of 114 re-reviews (36%) in a coding-agent review loop built for the Parallix project, leaving 73 re-reviews to a general LLM reviewer, according to the author's account. The author reports using Jev 1.13, which cleared 24 of 43 approved historical repairs versus 12 for Jev 1.14, and notes Jev's 32k input-token limit per question. The routing mix, projected against Claude API prices, is presented as an order-of-magnitude faster and roughly two-orders-of-magnitude cheaper path for bounded re-review decisions such as whether a repair preserved a failed integration check.", "body_md": "# Building a cheaper review loop for coding agents using Jev\n\n            When tests find a regression in agent-written code, the agent repairs it and the change needs another review.\n            [Jev](https://docs.typesafe.ai/models), TypeSafe’s hosted classifier,\n            clears about a third of those re-reviews in my personal workflow, at a fraction of the\n            cost of a general LLM review.\n          \n\n          In [Parallix](https://github.com/oxtan-maker/parallix), one agent family implements\n          a change and another agent, using a different model, reviews it before I do. Human review and integration gates\n          decide when the work is done. I don't expect the first agent to get it right first time; it usually needs a couple of feedback cycles.[*](#agent-findings)\n\n          Each re-review used to mean another general LLM review. That needs the requirements and codebase context, more than Jev can fit in 32k input tokens per question. Many re-reviews are easier:\n          did this repair fix the failed check without weakening it?\n          And would it not be great if we can take decisions in those cases an order of magnitude\n          faster and a couple of orders of magnitude cheaper?[†](#comparison-note)\n\n## The result: 36% of re-reviews\n\n            Jev cleared\n            **41 of 114 re-reviews (36%)**<sup>[‡](#results-note)</sup>:\n            37 repairs to local\n            integration gates and four general re-reviews. That leaves 73 for the general reviewer.\n            A typical integration-gate repair fixes one failed test or a performance regression.\n          \n\nUsing Claude API prices as the baseline, that routing mix gives this projection:\n\nProduction uses several general reviewers; the estimate assumes the avoided reviews would resemble the Claude sample.\n\n## Integration gates\n\nEarly experiments asked whether a repair addressed an integration failure. Jev kept leaving the decision to the general reviewer. Some requests also exceeded its token budget. Better packing got the requests through, but the decisions still weren’t useful.\n\nThe test run already answers whether the test passes after the fix. A reviewer has a different job. An agent can make a test pass by fixing a code or test regression, or by deleting or weakening a test. Both can produce a green exit status; only one preserves what the test was meant to establish.\n\nThat gave Jev a bounded job: judge whether the repair preserves the check and the behaviour already approved. The question names concrete ways to weaken a check, including skipping a test, loosening assertions or raising a CPU or time budget.\n\n### Build the evidence around that judgment\n\nThe classifier needs to know what was approved and what the repair changed. Its packet identifies the approved and repair revisions, supplies their relevant diff, names the failed check and states omissions. It excludes files changed only by other work landed on main and identifies changes brought in by a rebase. Rebase changes in the same file can still appear in the diff.\n\nThe local repair loop reruns its gates before re-review. A later rebase does not by itself require repeating every local test; upstream CI provides the usual integration validation. Jev’s approval leaves both stages in place.\n\nThe model version matters. I use Jev 1.13: on the same 43 approved historical repairs, it cleared 24 against Jev 1.14’s 12.\n\n## General re-reviews\n\nA request for changes gives Jev a specific question: did the repair fix what the reviewer asked for? Parallix sends the earlier findings, repair diff, relevant source and implementer’s response. Three questions run in parallel over that evidence, covering the requested fixes and related regressions introduced by the repair.\n\nOne clear was a one-line TypeScript correction. A test helper accepted the wrong callback return type; the repair changed it to the type the test runner requires.\n\nThe panel can approve or send the patch back to the implementer. With uncertainty, conflicting votes or a failed call, the general reviewer takes over. This path cleared four re-reviews in the dataset.\n\n## An approval can miss a defect\n\n            Jev is a different model from general LLMs such as Claude and makes different decisions.\n            It can make mistakes, but the difference I found in this sample was small.<sup>[1](#matrix-detection-note)</sup>\n            For example, in a local integration repair, the implementer added an `admission`\n            property to a fixture that already had one. Jev cleared the change. The focused suite\n            passed, but the separate TypeScript check later in the process rejected the duplicate key.\n          \n\n## The Jev tradeoffs\n\nFor me, the main cost is the attention tied up in review: waiting, checking progress and switching back. The estimate saves about two hours of review work per month at 800 re-reviews. How much human attention that recovers depends on when the workflow needs me, and on how quickly I switch to the next task instead of waiting for the re-review to finish. Reviews that run unattended offer less direct benefit.\n\nParallix keeps a human in the loop on purpose; I cannot assume a single agent pass finishes a mission. A defect Jev misses can reach my review or fail a later gate.\n\nCost matters too. Re-review API spend also falls by about 35%: $74 a month at API prices, before extra repairs and upkeep. That can matter when reviews compete for a fixed token budget. Human approval and the required gates stay in place in both options:\n\n| Two options for 800 re-reviews per month |  |  | \n|---|---|---|\n| Criterion | General reviewer every time | Jev + general-reviewer fallback | \n|---|---|---|\n| Re-reviews requesting fixes | **32.1%**<sup>[1](#matrix-detection-note)</sup> | **~31.2%**<sup>[1](#matrix-detection-note)</sup> | \n| Review work | **7.5 hours**<sup>[2](#matrix-time-note)</sup> | **~5.3 hours** (29% less)<sup>[2](#matrix-time-note)</sup> | \n| Human attention | Ranges from waiting and checking during reviews to returning only for human approval. | Less waiting and checking if reviews interrupt me; little direct saving when they run unattended. A missed defect can add an interruption. | \n| API cost | **$208.79**<sup>[3](#matrix-cost-note)</sup> | **~$134.95** (35% less)<sup>[3](#matrix-cost-note)</sup> | \n| Upkeep | Existing reviewer setup and maintenance. | Adds Jev maintenance and a vendor dependency: code diffs go to TypeSafe via OpenRouter. Failures fall back to the general reviewer. | \n\nBoth options retain human review, local integration gates and upstream CI. Cost and review work use the Claude Sonnet baseline and exclude extra repairs and upkeep. The monthly workload is illustrative: four weeks at 200 re-reviews, not a measured rate. The effect on human attention depends on the workflow and has not been measured.\n\n<sup>1</sup> The small difference in the sample is one confirmed repair defect\n                Jev cleared among 114 re-reviews. The combined route requested fixes 18 times\n                (15.8%); counting that missed defect gives 19 known cases a general reviewer\n                would have returned (16.7%), a difference of 0.9 percentage points. Follow-up\n                review covered selected cases, so this is the known difference rather than a\n                complete count of misses. General reviewers requested changes in 252 of 786\n                historical re-reviews (32.1%), from 14 August through 21 October. The matrix\n                applies the sample's 0.9-point difference to that baseline: ~31.2%, or about\n                256 versus 249 requests for fixes per 800 re-reviews. That projection holds the\n                review mix fixed; the historical and current cohorts are not a matched comparison.\n                [Calculation details](#review-findings-rate).\n              \n\n<sup>2</sup> The 25 recovered Sonnet re-reviews averaged 33.84 seconds from\n                process launch to exit, including tool calls. Apply that mean to 800 reviews\n                without Jev, or 73/114 of them with Jev. Evidence preparation and classifier\n                calls add about 31 minutes per month, leaving about 2.2 hours saved (29%).\n                Untimed replay preparation uses the mean of four production panels. Shared\n                gates, general-reviewer prompt preparation, final workflow bookkeeping, extra\n                repairs and upkeep are excluded. [Calculation details](#accounting).\n              \n\n<sup>3</sup> The Sonnet sample averaged $0.261 per re-review at API prices.\n                Apply the same routing shares and add about $1.25 of classifier calls per 800\n                re-reviews, using recorded panel costs and historical integration-question\n                costs. Estimated monthly saving: $73.84. [Calculation details](#accounting).\n              \n\nWhat I’d carry to another team is the bounded question: give Jev a repair it can judge, leave uncertain cases with the general reviewer, and keep human approval and the downstream gates. Count the misses as well as the reviews avoided; the extra repair cycles determine whether the saving survives.", "url": "https://wpnews.pro/news/building-a-cheaper-review-loop-for-coding-agents-using-jev", "canonical_source": "https://oxtan-maker.github.io/parallix/articles/jev-review-evidence/", "published_at": "2026-10-23 07:41:33+00:00", "updated_at": "2026-10-23 08:12:58.659169+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "ai-products"], "entities": ["Jev", "TypeSafe", "Parallix", "Claude API", "Jev 1.13", "Jev 1.14"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/building-a-cheaper-review-loop-for-coding-agents-using-jev", "markdown": "https://wpnews.pro/news/building-a-cheaper-review-loop-for-coding-agents-using-jev.md", "text": "https://wpnews.pro/news/building-a-cheaper-review-loop-for-coding-agents-using-jev.txt", "jsonld": "https://wpnews.pro/news/building-a-cheaper-review-loop-for-coding-agents-using-jev.jsonld"}}