Jev: when the model's consumer is code

The idea in one sentence

A model whose consumer is not a person, but code.

That is the thesis behind Jev, which Diogo Almeida, CEO of TypeSafe AI, lays out to swyx in Jev: System One models for Prod, not God (Latent Space, 22 September 2026). Today’s models are built to autocomplete the internet (pre-training) or to answer people (RLHF). Jev, a “System 1” model or large programmable model, is designed to be called by software directly; hence the company’s name, TypeSafe.

The name comes from the Jevons paradox: when intelligence gets cheaper, far more of it gets used. That is why the stated goal is not the frontier of absolute intelligence, but that of intelligence per dollar.

Three north stars

According to Diogo, LLM training has chased three objectives, and two of them are the wrong ones:

• RLHF (human feedback): the model learns to please. Result: hallucinations, sycophancy and permanent dependence on humans. It makes the model less reliable, not more.
• RLVR (programmatically verifiable rewards): optimizes for benchmarks. It solves Navier-Stokes, but worsens jagged intelligence: brilliant at some things and clumsy at others. And it integrates poorly with other software.
• RLCD (Reinforcement Learning for Calibrated Decisions): TypeSafe’s bet. It aims for answers with epistemically honest probabilities on System 1 tasks. It is unpublished: no paper, no details.

The underlying argument is not about algorithms. He cites the bitterest lesson: the most important thing in machine learning is choosing the task and the data. That is why they call themselves a data lab, not a model lab.

When the consumer is code, the rules change

No refusals. In a chat, a refusal is an annoyance you can work around. Inside a dependency running in the background, the software breaks stochastically because a user typed something odd.

In a product, safety alignment makes sense. In an API it is a type error.

• The API should do what it is asked: the more predictable it is, the less whoever integrates it has to test it.
• His comparison: it is not a database’s job to decide what it is used for.
• No identity either: whoever builds a chatbot on the API does not want it claiming to be something else. Jev has no “I am Jev from TypeSafe” baked in.

The mechanism tying all this together: every bit of overfitting fractures intelligence. Optimizing for chat produces sycophancy, overconfidence, hallucinations and the LM Arena style (bold text, emojis, long answers and a follow-up question at the end).

Robustness, not determinism

The most useful distinction in the interview:

• Determinism: same inputs, same outputs. According to Diogo, it is the wrong goal; at most, useful for unit tests.
• Robustness: similar inputs, similar outputs. This is what is actually needed.

Concept: an irrelevant change in the input should not change the decision. LLMs are, he says, surprisingly bad at this.

Actions:

• To measure it, repeat every case in your evals with different UUIDs (or other irrelevant noise: field order, whitespace, names) and check that the answers are equivalent.
• Do not ask your provider for determinism if what you want is stability: TypeSafe does not rule out offering it, but warns that it costs intelligence per dollar.

New types: Choice, Score and Noulli

Jev’s API exposes three primitives that do not exist in programming languages, but translate directly into control flow:

• Noulli comes from Bernoulli: a continuous boolean, the probability that something is true. You pick the threshold.
• Inputs (state, instructions, criteria) can be structured JSON objects. If you turn everything into text and stuff it into a system message, you are thinking the old way.

System messages are global variables: you dump everything in at once and hope the model gets every instruction right.

Building by decomposing

Concept: break the problem into the smallest possible semantic units and ask many independent questions instead of one big one. Each small decision can be measured and verified on its own: machine learning without the machine learning.

Actions:

• Instead of asking “should I refuse here?”, ask separately about each concrete situation that would justify a refusal.
• If the model fails because you did not specify something, that is good news: you add the question or the threshold, turn it into a test case and it is fixed for good. It does not get forgotten through context rot.
• Pass state and criteria as structured data, not as prose in the prompt.

Use cases

1. Dark data: mountains of data that companies never analyzed because it was expensive. According to him, the biggest revenue driver.
2. Coding agents: the largest volume today.
3. Real time: any product that gets better by shaving off 10 ms, computer use included.
4. Verify everything: observability over LLM calls.
5. Composable software: even programming languages built on top of Jev.
6. Video games and NPCs, his personal favorite.

My take

Four things stick with me:

1. The three north stars. The cleanest explanation I have seen of why a model can solve incredibly hard problems and still fail at basic ones.
2. Robustness over determinism. I do not need the model to answer exactly the same way every time; I need an irrelevant detail not to change its mind. And that can be tested today: repeat every test case changing only the noise and check that the answer does not change.
3. A refusal in an API is a bug, not a safeguard. In a chat, product rules make sense. In a piece of infrastructure, an unexpected refusal breaks the program calling it. Those rules belong in the product, not in the model underneath.
4. Many small questions beat one big one. Each separate decision can be measured, has its own threshold and test, and when it fails you know exactly where. It works with any model, not just Jev.