How Developers Can Use Jev to Make AI Coding Smarter

A practical guide to better context selection, task routing, and review, with setup commands and a JavaScript example. Researched on September 27, 2026.
An AI coding session can go wrong before the model writes its first line of code. The agent opens the wrong files, misses a project convention, chooses an unsuitable tool, or starts implementing a requirement that nobody has actually defined. The resulting code may look convincing while solving the wrong problem.
Developers often respond by writing a longer prompt or switching to a more capable model. Another approach is to improve the decisions surrounding code generation: what evidence reaches the agent, which workflow handles the task, and when the system should collect more information.
Jev, from TypeSafe AI, provides a way to build those decisions into software. Its usefulness for AI coding comes from combining structured judgments with your existing coding model and development tools.
Understand Jev's role first. Jev evaluates supplied information and returns constrained decisions. It does not generate source code, edit your repository, or act as a replacement model inside Cursor or Claude Code. TypeSafe's documentation explicitly separates its decision API from the LLM that powers a coding agent. Source: Jev with coding agents.
There are two practical ways to use it. You can give your coding agent the official TypeSafe skill so it writes better Jev integrations. You can also build a helper or orchestration service that calls Jev during your development workflow. Installing the skill provides integration knowledge; the second approach requires you to implement and connect the decision logic.
The workflows below are proposed engineering patterns based on Jev's documented capabilities. They are not built-in Cursor features or claims of measured improvements on your repository.
Jev supports three kinds of questions:
Primitive Result Example in a coding workflow
Choice One supplied option, probabilities for the options, and confidence Classify a change as presentation, application behavior, or unclear.
Score A value on an ordered rubric, with probabilities and confidence Rate whether a retrieved code excerpt is irrelevant, contextual, or directly useful.
Noul The estimated probability that a yes/no statement is true Check whether a requirement specifies an observable outcome.

A Noul returns a number between zero and one, not a Boolean or a prose explanation. Score values can fall between rubric levels. These distinctions matter when you turn responses into application behavior. Source: question primitives.
Give your coding agent accurate integration knowledge. Start with the official TypeSafe skill. It supplies the API conventions and design patterns the agent needs, reducing the need to explain the integration from scratch.
For Claude Code, the documented installation commands are:
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai
For other supported agent environments, use:
npx skills add typesafe-ai/skills --skill typesafe-ai
Choose your agent when prompted. The documented default is installation within the project. Use one installation method, then explicitly ask the agent to use the TypeSafe skill. If you install manually, include the skill's reference files. Source: official agent skill.
A useful first request is:
Use the TypeSafe skill to inspect this repository. Find one repeated semantic decision in our AI development workflow that we can evaluate independently. Propose the input fields, answer options, fallback, and a small evaluation dataset before implementing it.

This gives the agent a bounded engineering task. You want a specific decision with a measurable outcome, such as selecting useful documentation passages. Asking it to add Jev everywhere makes the result much harder to evaluate.
Improve the context before asking the model to code. Consider a Laravel application where a developer asks an agent to fix duplicate webhook processing. A repository search may return the webhook controller, queue configuration, an old integration, payment documentation, and several unrelated event handlers.
Your retrieval code can collect candidate excerpts. Jev can then judge each excerpt against the task, using questions such as:

• Does this excerpt describe the handler involved in the reported behavior?
• Does it provide evidence about the application's existing duplicate-event handling?
• Does it contradict an assumption in the task description? Your application retains the useful evidence and gives the coding model a smaller, better organized input. Keep relevant contradictory information visible, because it may reveal that the proposed fix rests on a false assumption. TypeSafe documents a related workflow for classifying retrieved passages before they reach a generative model. Adapting that pattern to repository excerpts is an implementation choice you must evaluate; the published example does not establish a coding benchmark. Source: classifying RAG passages. Jev only evaluates the information supplied to it. Your integration still needs to search the repository, read candidate files, preserve file paths, and fetch further context when necessary. A relevance filter cannot recover a file the retrieval step never found. For that reason, measure how often the filter removes evidence the developer actually needed. Saving tokens is a poor trade if the agent loses the one function that explains the bug. Route work according to its requirements. A wording change, a database migration, and a concurrency bug deserve different workflows. You can apply Jev's documented intent-routing pattern to a development queue, with your own code mapping categories to handlers. Source: intent routing. For example, a presentation-only task might start with a less expensive coding model. A change to application behavior might use a stronger model with broader context. An ambiguous task might return to the developer for clarification. Define the categories in terms of observable properties. “Easy” and “hard” are difficult labels to evaluate consistently. “Only changes static wording or layout” and “changes runtime behavior or data handling” give reviewers a clearer basis for checking the classification. The routing policy belongs in your application. If a changed path is already known to contain an authorization policy, a deterministic rule can require the appropriate review directly. Jev is useful where interpreting the task requires semantic judgment. Also allow an unknown outcome. A classifier forced to choose between two unsuitable categories will still choose something. An explicit unclear option gives your workflow a practical fallback. Use a small integration to make the idea concrete. The following example recommends which coding workflow should receive a task. It performs no file edits and launches no coding model. Those actions would be connected separately in your orchestration code. The official JavaScript SDK requires Node.js 20 or newer. Install it, obtain an API key from the TypeSafe console, and make the key available to the server-side process through TYPESAFE_API_KEY. Source: JavaScript SDK. npm install @typesafe-ai/sdk Save this example as route-coding-task.mjs: import { TypeSafeClient, choice, noul } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

// Illustrative thresholds. Tune them against reviewed tasks.
const MIN_SCOPE_CONFIDENCE = 0.85;
const MIN_OUTCOME_PROBABILITY = 0.85;

const state = {
task: "Change the billing link label to 'Manage subscription'. " +
"Keep its destination and behavior unchanged.",
component_excerpt: 'Billing',
};

let nextStep = "manual_review";

try {
const result = await client.systemOne({
model: "jev-1.13.0",
state,
questions: {
scope: choice(
"Classify the requested change using task and component_excerpt.",
{
presentation: "Only static wording or visual layout changes.",
behavior: "Runtime behavior, data handling, or interfaces change.",
unclear: "The supplied evidence cannot establish the change category.",
},
),
outcome_stated: noul(
"Does task specify an observable outcome for the requested edit?",
),
},
});

const { scope, outcome_stated } = result.answers;

if (outcome_stated.noul < MIN_OUTCOME_PROBABILITY) {
nextStep = "clarify_requirement";
} else if (
scope.confidence >= MIN_SCOPE_CONFIDENCE &&
scope.choice !== "unclear"
) {
nextStep = scope.choice === "presentation"
? "lightweight_coding_workflow"
: "full_coding_workflow";
}

console.log({ model: result.model, scope, outcome_stated });
} catch {
console.error("Classification unavailable; keeping manual review.");
process.exitCode = 1;
}

console.log({ nextStep });
Run it with node route-coding-task.mjs after configuring the environment variable. The example follows the documented SDK interfaces, including the Noul helper; it has not been exercised against the live API for this article. No sample prediction is presented as an observed result.
Notice the separation between classification and execution. Jev supplies evidence for a routing decision. Ordinary code selects the next step, retains a fallback, and can apply additional project rules. An unavailable API does not silently become permission to continue automatically.
The model is pinned for reproducibility. TypeSafe currently documents jev-1.13.0; the jev-latest alias can move to another release. Re-evaluate a new version before carrying over thresholds tuned on an earlier one. Source: models and aliases.
Help agents select relevant skills. As a coding environment accumulates skills, selecting the right instructions becomes a problem of its own. A task involving a spreadsheet export, a browser interaction, and a database query may match several descriptions superficially.
A useful pattern is to shortlist candidate skills, inspect the strongest candidates in more detail, and allow the selector to conclude that none is useful. TypeSafe publishes a two-stage skill-selection example built around this approach.
In its reported experiment across 488 requests using the Hermes skill catalog, incorrect skill loads fell from 16.8% to 7.3% when the agent received a TypeSafe suggestion. Those are vendor-reported results for that setup, not proof that your coding agent will achieve the same improvement. Source: skill suggestion cookbook.
For your own project, evaluate the selected skill against what the developer actually needed. A correct suggestion can still be ignored or misapplied by the coding agent, so measure both selection and downstream behavior.
Add targeted review signals after code generation. You can also experiment with Jev after the coding model produces a patch. Supply a focused diff, relevant requirements, and existing code excerpts, then ask narrow questions about the change.
For a tenant-aware application, a useful question might be whether a modified query path includes the tenant restriction specified in the supplied requirement. For an API task, you might check whether a changed response contradicts the supplied contract. These are proposed uses that need repository-specific evaluation.
Avoid asking for a single universal “code quality” score. It hides unrelated judgments behind one number and makes mistakes difficult to diagnose. Separate contract consistency, relevant behavior changes, and missing evidence so that each result has an identifiable purpose.
Use these judgments to direct attention. Compilers, static analysis, executable tests, and human review provide different evidence. A confident semantic judgment cannot establish that a program handles every runtime condition correctly.
When several questions concern the same supplied evidence, send them together. TypeSafe supports independent questions against a shared state. If a later question requires data retrieved using an earlier answer, make that dependency explicit with a subsequent request. Source: question composition.
Make failed attempts easier to investigate. Another experiment is to classify a failed coding attempt using the test output, the task, and the latest patch. Candidate categories could include environment setup, a changed application contract, an assertion mismatch, or insufficient evidence.
The classification can recommend an investigation path. An environment failure might send the developer toward service configuration. A contract mismatch might trigger inspection of the relevant interface and its callers. Insufficient evidence might request the missing stack trace.
Apply parsers and ordinary rules first when an error is already identifiable. Use Jev for the remaining interpretation, and treat its category as a hypothesis. A failed test should never be rewritten merely because the classifier suggests that the test is wrong.
Track whether the recommendation actually reduces repeated attempts. If the same failing command keeps producing the same evidence, another model call is unlikely to provide a better basis for action. Your workflow needs a stop condition and a way to gather something new.
Interpret confidence carefully. Choice and Score include a confidence value derived from their probability distributions. Noul has its own yes/no probability and no separate confidence field. A Choice confidence of 0.9 should not be presented as a verified 90% chance that the selected action is correct for your application. Source: confidence.
Treat thresholds as settings to evaluate. Label real examples, inspect errors, and decide which mistakes are most expensive. For context selection, dropping essential evidence may matter more than retaining an extra excerpt. For task routing, sending a difficult task to a weaker workflow may matter more than occasionally spending extra tokens.
A single threshold copied across unrelated decisions hides these differences. Keep your questions, option descriptions, and thresholds easy to review together, and record which versions produced each decision.
Measure the whole workflow's economics. As of September 27, 2026, TypeSafe lists Jev 1.13 at $0.042 per million input tokens, with output tokens free. At that published direct-API rate, 1,000 evaluations averaging 2,000 total input tokens each would cost approximately $0.084 for Jev inference. This is an illustrative calculation, not measured usage. Source: model pricing.
Your actual workflow also pays for retrieval, generation, retries, infrastructure, and developer time. A low classification price is useful only if the added step improves the overall result enough to justify its latency and complexity.
Compare the same representative tasks with and without the Jev step. Measure task success, coding-model tokens, elapsed time, retries, and developer corrections. For a context filter, also measure evidence retention. For a router, record how often a task had to be escalated after an unsuitable initial assignment.
Begin in observation mode: record Jev's proposed decisions while the existing workflow continues to determine behavior. This creates a useful comparison without letting an untested classifier reshape the development process immediately.
Respect the model's documented limits. TypeSafe's Jev 1.13 limitations include unreliable counting and numeric precision, difficulty with indirect questions, distraction from irrelevant context, and susceptibility to adversarial input. Source: Jev 1.13 limitations.
In practice, compute exact quantities in code, keep questions direct, and retrieve a focused set of evidence. Treat repository comments, issue text, and external documents as data being evaluated. A model judgment should not control credentials, execution permissions, or deployment authority.
Jev 1.13's documented input is text, including structured text objects. Visual interface review therefore needs another component to inspect screenshots or produce suitable textual evidence. Source: supported inputs.
Start with one decision you can evaluate. A context filter is a reasonable first experiment when your agent repeatedly opens irrelevant files. A task router is useful to investigate when every request currently receives the same model and workflow. Choose the recurring problem you can actually observe.
Here is a prompt you can give your coding agent:
Use the official TypeSafe skill to build a small Jev experiment
for our AI coding workflow.

First inspect the repository and identify one repeated semantic
decision that ordinary parsing or deterministic rules do not handle well.
Recommend either context relevance filtering or coding-task routing,
and explain why it fits the evidence you found.

Define focused input fields, atomic questions, explicit answer options,
and an unknown or review fallback. Keep questions and thresholds together.
Use the current official SDK, read TYPESAFE_API_KEY from the environment,
and pin the model version used during evaluation.

Build an observation mode that records proposed decisions without
changing the existing workflow. Create a small, representative dataset
of reviewed examples, including ambiguous cases and previous failures.
Reserve some examples for evaluation after threshold tuning.

Compare the baseline with the proposed integration on task outcomes,
token usage, latency, and developer corrections. Report mistakes as
well as improvements. Handle API failures explicitly, and preserve
the project's existing checks and execution permissions.
Use the first round of results to make a concrete decision: keep the integration, revise its questions, or remove it. Jev earns a place in the workflow when its judgments help your coding agent work from better evidence and make fewer costly mistakes on tasks that matter to your team.