Jev coding agents: what they get wrong in your code

TypeSafe publishes a documentation page whose entire purpose is to stop coding agents doing the wrong thing with Jev. That is unusual enough to be worth reading on its own. The failure it heads off is specific: Jev coding agents tend to write LLM-shaped code — a prompt string, a request for JSON, a parser and a retry — against an API that takes a state and a set of typed questions and returns typed answers by construction.

This post covers what that failure actually looks like in generated code, what belongs in your agent instructions, which documentation index to point the agent at first, and the five things worth reviewing before you merge anything an agent wrote against this API. It reflects the Jev docs as of 23 September 2026 and jev-1.13.

Where Jev coding agents go wrong: prompts, not typed questions

The mistake is a category error, and it is an understandable one. An agent that has written a thousand LLM integrations has a reflex: build a prompt, ask for structured output, validate it, retry on failure. Jev has no prompt. A request carries a state — the text or JSON you are asking about — and a map of named questions, each one a Choice over labels you defined, a Score on a rubric you wrote, or a Noul returning the probability that a statement is true. The answer comes back typed. There is nothing to parse and no schema to re-ask for.

So the tell in generated code is any of the machinery that exists to survive free text: a system-prompt constant, an instruction to "respond only with JSON", a JSON.parse wrapped in a try/catch, a repair loop, or a regex reaching into a response string. All of it is dead weight against this API, and worse, it usually means the agent has invented a request or response shape to parse. TypeSafe names that symptom directly in the agent skill troubleshooting notes — "the agent invents request or response fields" — and attributes it to a stale skill.

Jev is not the model behind your coding agent

The second failure happens before any code is written. Developers arrive at TypeSafe looking for a faster, cheaper model to plug into the agent itself. TypeSafe's page on coding agents answers this without hedging: Jev is not a drop-in replacement for the LLM behind Claude Code, Cursor, opencode, Copilot, Muse Spark or Grok Bot, and there is no model: "jev-latest" setting that turns a coding agent into a Jev-powered agent. Jev does not generate text, write code or hold a conversation.

The relationship runs the other way. You keep using your LLM-based coding agent, and you use it to write code that calls Jev wherever your product needs a fast structured decision — routing, classification, scoring, guardrails. If you want the distinction at greater length, we wrote about when a decision model beats an LLM inside a product.

What should I tell my coding agent about Jev?

Start by not telling it anything in prose. TypeSafe ships an agent skill that carries the question types, the architectural patterns and structuring guidance, installable as a Claude Code plugin with claude plugin marketplace add typesafe-ai/skills followed by claude plugin install typesafe@typesafe-ai, or into other agents with npx skills add typesafe-ai/skills --skill typesafe-ai. Use one installation method; duplicate copies of a skill are their own problem. If the agent is not picking it up, name it in the prompt — "use the TypeSafe skill" works in any agent.

Then add the three instructions the skill does not enforce for you, because they are decisions about your codebase rather than facts about the API:

• Put every question and threshold in one module. TypeSafe's own guidance says the same thing and gives the reason: the questions and threshold constants are the part humans need to review, and they should be findable without spelunking. In our own work this is the difference between a reviewable change and a diff nobody can assess.
• Keep arithmetic in code. Say it explicitly, because an agent will happily ask Jev to count things or compare dates.
• Do not add a retry-and-reparse layer. Both SDKs already retry 408, 429 and 5xx with backoff and honour Retry-After. A second layer on top turns a brief rate limit into a stampede.

One more piece of advice from TypeSafe is worth quoting as written, because it sets the right expectation for a review:

Agents aren't great at writing questions, so expect to edit collaboratively with them.

Does Jev have an llms.txt?

Yes, at docs.typesafe.ai/llms.txt, and it is the single most useful thing to hand an agent that cannot use the skill. It lists 111 pages with a one-line description each, from the primitives and patterns through every cookbook to the per-class SDK reference. Every documentation page also has a Markdown twin at the same path with .md appended, which means an agent can fetch the exact page it needs rather than scraping rendered HTML.

The two pages we point agents at first are not the tutorials. They are the quick start, which contains a complete request and response body, and the jaggedness page for jev-1.13, which is TypeSafe's own list of what the model gets wrong. An agent that has read the second one stops proposing Jev for counting, date comparison and text generation, which removes most of the bad designs before any code exists.

What to review in generated Jev code

Five checks, in the order they catch things. None of them requires you to know the SDK well.

1. Is there a prompt in here? Search the diff for a triple-quoted string, "respond with JSON", a parser or a repair loop. If any of it is there, the agent built against the wrong mental model and the rest of the review is moot.

2. Are the questions and thresholds in one place? If question text is inlined at four call sites, the reviewable part of the change is scattered across four files, and the next edit will drift them apart.

3. Is confidence used where a probability belongs? TypeSafe flags over-use of confidence thresholds as a common issue: if all you need is the best option, take the highest-probability choice rather than gating on confidence, and if you have a statistical procedure in mind, you probably want the probabilities. Note also that a Noul answer has no confidence field at all — only the probability itself — so code that reads one is code the agent invented.

4. Has a threshold been carried from one question type to another? This is the subtle one, and TypeSafe documents it with numbers. Asked whether a customer is requesting a refund, the ticket "I'm not happy with the fit. What are my options here?" returns a Noul of 0.22, while the same question as a yes/no Choice returns yes at 0.01, no at 0.99 and a confidence of 0.97. And two Nouls that look like opposites do not sum to one: on a different ticket, a refund question returned 0.72 while its negation returned 0.47, a total of 1.19. A Choice is relative and settles which option wins; a Noul is absolute and can be low for every option. A threshold tuned on one is meaningless on the other.

5. Is the state bigger than the question needs? Agents pass whole records because whole records are easy to pass. Accuracy falls as the state fills with detail unrelated to the decision, and a large state makes a wrong answer much harder to attribute. Filter in code first.

Two lesser checks worth a glance: that the model is pinned where thresholds have been tuned, since jev-latest is an alias that moves when a release ships, and that nothing has enabled debug logging on a code path carrying customer data, because both SDKs log request and response bodies unredacted at that level.

Where we let the agent drive anyway

The obvious counter-argument is that a review list this long means you should write the integration yourself. We do not think so, and our own practice is the opposite. The plumbing — client construction, error classes, the route handler, tests around thresholds, wiring usage into logs — is exactly the mechanical work agents are good at, and it is documented tightly enough that a current skill produces it correctly. TypeSafe even suggests giving the agent an API key and letting it run cheap experiments to find the best question wording, which is a reasonable use of a model that charges for input tokens only.

What we do not delegate is the decision layer: which judgement is being asked, in what words, with what options, and at what threshold something happens automatically rather than reaching a human. That is product logic wearing an API's clothes. It is also the part that quietly encodes risk, which is why it belongs in the same review process as any other rule that acts on a customer without asking — the same reason we treat generated code as reviewable by default in our QA and automation practice, and the same instinct behind our note on what coding tools do with your repository.

If you are starting this week, do it in this order: install the skill, point the agent at the jaggedness page, have it write one Noul with one threshold in one file, and read that file yourself. If the question reads like something you would put to a careful colleague in a single sentence, the integration will be fine. If it reads like a prompt, send it back. That first question is the one everything else in the system will be modelled on, and it is the piece of AI engineering work no agent should finish on its own.