AI Sources
First-handAIVideo··10 min read

Jev: the model built to be called by code, not by humans

Diogo Almeida, ex-OpenAI, explains why he created a new class of "system one" models — and why he rejects public benchmarks, refusals, and pre-training.

Source : Latent Space · YouTubeView original

In brief

In a two-hour-plus interview at the Latent Space studio, TypeSafe's founder details the thesis behind Jev: a model whose consumer is code, optimized for "intelligence per dollar," with no chain of thought or refusals. Along the way he dismantles RLHF, public benchmarks, and the debate over frontier "pacing," and recounts why he left OpenAI after pushing for InstructGPT.

🍺 Bar-stool version

For three years, everyone's been telling you AI will be your office colleague. He thinks that's a casting error: AI isn't an intern, it's a somewhat gifted database that gets called a million times a day from a loop. Hence a model that doesn't chat, refuses nothing, doesn't think out loud, and just returns three things: a fuzzy boolean, a score, a choice. If it works, the AI revolution won't arrive as a brilliant chatbot but as boring old software that suddenly, finally, starts making the right calls on its own.

Key takeaways

  1. 1

    Jev belongs to a class of models TypeSafe calls "system one," "machine native," or "large programmable": the consumer of the output is code, not a human.

  2. 2

    Only three primitives — nule (derived from Bernoulli), score, and choice — mapping to an if, a sort/threshold, and a switch on an enum.

  3. 3

    The model is optimized for "intelligence per dollar" (hence the name, a nod to Jevons' paradox), not for speed or leaderboard rankings.

  4. 4

    Almeida calls himself "extremely anti public benchmarks": too easily gamed, they should give way to internal evaluations by developers on their own workflows.

  5. 5

    No refusals in the API: "refusal is obviously a type error" — a random refusal in a dependency running in the background breaks the software.

  6. 6

    Data is entirely synthetic, and the company refuses to train on user data, to avoid overfitting to the present.

  7. 7

    Cited figures: over 1 trillion tokens per day, including overnight, 100,000 people on Discord, and almost no revenue before launch.

Chapters

0:00

Cold open: the automation puzzle

How can an AI capable of graduate-level math problems still fail to automate the most basic tasks? The automation engine exists, the plugs are missing.

1:32

Launch week: "never been worse"

The founder's state of mind after a launch that flooded the timeline, and his choice to prioritize Discord town halls over investor meetings.

4:27

What is Jev?

Definition of the new model class: system one, machine native, large programmable, with code as the consumer and intelligence per dollar as the metric.

7:23

RLHF, mode collapse, and LeCun's slide

RLHF's mode dropping explains why the error accumulation predicted by LeCun doesn't hold up empirically — at the cost of destroyed calibration.

12:57

Why Jev never refuses

Refusal as a type error in an API; the distinction between capability alignment and safety alignment; intelligence as a database rather than a coworker.

19:30

Anti public benchmarks

Why public benchmarks are unmanageable and gameable, and what should replace them: vibes, trust, then evaluation within the real workflow.

22:03

The "bitterest lesson": data first

Data matters more than compute, RLCD as the new north star, and the obsession with hiring "data people."

42:45

Determinism versus robustness

No seed for now: the right property would be robustness, tested by injecting UUIDs into prompts.

49:40

Model versioning and LTS

A commitment not to modify a deployed model, no promise of long-term support, and the hypothesis of an LTS on Jev 1.13.0.

55:29

API design: nule, score, choice

Origin of the names, rejection of existing types, and the mapping to if, threshold, and switch on enum.

1:00:39

How to structure your requests

Decompose down to the smallest semantic unit, pass structured JSON rather than templates, ask many questions in parallel.

1:16:00

System 1 versus system 2

Why pre-trained LLMs are fundamentally system one thinkers, and what RLVR added — along with its fractal fragility.

1:31:37

Before launch: more than half didn't get it

Looking back at a disappointing validation phase, the lack of revenue, and questioning the very notion of product-market fit.

1:36:13

Use-case families and coding agents

Dark data, real-time, verification, smart software — and criticism of the "tyranny of the KV cache" in coding agents.

1:43:16

The debate over slowing the frontier

The labs' joint statement, in his view, presupposes ever more RLVR is needed — an assumption he considers far from universal.

1:57:49

From InstructGPT to leaving OpenAI

The fight to deploy InstructGPT, the document sent to Sam Altman, and the founding of TypeSafe with Eric and then Sasha.

2:09:50

The projects he's leaving for others

Smart video games and rethinking coding agents freed from the KV cache: two directions he'd like to see others explore.

A new class of models: code as the client

The starting point is a contrast of tasks. Pre-training optimizes for autocompleting the internet, RLHF optimizes for responding to a human, RLVR optimizes for verifiable outputs. TypeSafe claims a fourth target, dubbed RLCD: producing outputs directly consumed by code. Hence the company's name, TypeSafe.

In practice, Jev doesn't write free-form text. It exposes three primitives: nule (derived from Bernoulli probability, a continuous boolean), score, and choice. Almeida describes them as deliberately new types, not to be confused with a bool, an int, or a function call.

The mapping to code is explicit: a nule feeds an if, a score a sort or threshold, a choice a switch on an enum. "There will be more types, and they'll correspond to programming primitives," he announces.

The name Jev comes from Jevons' paradox. The internal branding is clear: Jev denotes the family of models that stays on the frontier of intelligence per dollar. Not the smartest in absolute terms — the smartest at a given price.

The case against RLHF: mode collapse and calibration

This is the most technical part of the interview, and it comes from someone who worked on InstructGPT. According to Almeida, nobody looked at RLHF's side effects, particularly mode dropping: the model abandons minority modes of the distribution to only produce whatever is safest.

He uses this to explain a well-known paradox. Yann LeCun's famous slide about error accumulation with sequence length is, he says, "mathematically obvious but demonstrably false" empirically. His reasoning: to avoid derailing on long chains, RLHF models become ultra-conservative and lose their calibration.

This broken calibration is, in his view, "a poison" in the probability distributions over strings — and the reason we make bad decisions by overloading text models.

He considers LeCun one of the field's sharpest commentators, while refusing to take a firm stance on JEPA: "very nice early research," but not yet pragmatic in his eyes.

No refusals, no benchmarks: the platform doctrine

On safety, the stance is firm. Almeida isn't against safety as a principle, but considers safety alignment misaligned with API users. A refusal is "a type error": acceptable in a consumer product, nonsensical in a dependency running as a background task.

His analogy recurs several times: "intelligence will look more like a database than a coworker." And it's not the database engine's job to judge downstream usage. On military use, he concedes a personal preference, but refuses to bake it into the technology layer, arguing that every such overfit "fractures the intelligence."

Same logic for public benchmarks. He recalls that every lab used to have a dedicated team collecting data resembling MMLU. His conclusion: "in the long run, you need vibes and trust," then evaluation within the real workflow. Internally, evals exist — the discipline is not to game them.

The cost of this position was real: during the previous funding round, nobody believed them for lack of numbers to show. He says he stuck to it on principle. He also calls himself "anti-demos," even flattering ones from his own community.

Reliability, versioning, GPUs: the promises made to developers

No seed, no determinism for now. He finds determinism useful for unit tests, but believes the real desirable property is robustness: semantically identical inputs, similar outputs. Their in-house test involves injecting UUIDs into prompts and checking response stability.

On versioning, the commitment is clear: "we will not modify our models after deployment." However, there's no promise of long-term support — they intend to iterate much faster than typical providers, with the assumption of a temporary LTS on the heavily used version, Jev 1.13.0.

The context is a lasting GPU shortage. This is also the economic argument behind their positioning: less intelligence per dollar means more GPUs for the same result. The stated goal isn't onboarding big enterprise accounts but putting the tool into as many hands as possible.

Fine-tuning isn't ruled out, but not planned: he fears the shotgun effect and prefers to bet on calibration and cascades of models of different sizes.

How to use it, according to its creator

His main advice fits in one word: decompose. Ask many small, independent questions rather than one big one, down to the finest semantic unit. His example: don't ask "should I refuse here?", but query each possible refusal situation separately.

The benefit is one of software engineering. Each question becomes measurable, each bug gets fixed by adding a question or adjusting a threshold, and the case becomes a permanent test, immune to context rot. He sums it up: "it's machine learning without the machine learning."

Second piece of advice: stop putting everything into strings. State, instructions, and criteria can accept structured JSON. System messages are described as "horrible global variables" where you dump everything and hope each instruction gets through.

On the use-case side, he sorts things into four big families: dark data that companies didn't dare pass through an LLM for cost reasons, coding agents, real-time and assistants, and systematic verification of LLM calls. Computer use, meanwhile, arrived as a surprise.

OpenAI, an AI winter, and the debate over "pacing"

The biographical section sheds light on the rest. Almeida recounts fighting to deploy InstructGPT, including an unpublished algorithm he wrote himself, then realizing the result mostly served copywriting. Hence his question: what's missing between "very intelligent" and "creates value"?

His answer: in an AI-driven economic revolution, the vast majority of calls will come from code, not humans — and all the optimization was going toward humans. He says he wrote a document about it, talked to Sam Altman who told him to go for it, assumed Anthropic was already doing it, then eventually founded TypeSafe with Eric and then Sasha.

His stated driving force is the fear of an AI winter for which he'd feel personally responsible, both for pushing the RLHF direction and for not having fully committed to it. His target isn't a score but a macro figure: 3% total factor productivity growth over five years.

On the labs' joint statement in favor of slowing down, he calls it a sleight of hand: it presupposes everyone must do ever more RLVR while letting models act freely. For his model's form, "zero is the optimal amount." The host offers another, more cynical reading: political positioning ahead of 2028.

Refusal is just like obviously a type error.
I think intelligence will be more like a database than a coworker.
If you gave me a billion dollars I wouldn't pre-train.

Why it matters

For three years, the AI product consensus has boiled down to one word: the agent, or the digital coworker. Almeida proposes the exact opposite — a commoditized, invisible intelligence, called by programs, billed like a database query, and judged on reliability rather than raw intelligence. It's a coherent, technically argued thesis, and it has the merit of explaining an awkward fact: 2026 software still looks a lot like 2019 software, plus a chatbox on the side. One tension remains, though. Rejecting public benchmarks, demos, and determinism in the name of engineering purity also makes the company's claims unverifiable from the outside, right at the moment when "intelligence per dollar" becomes a sales pitch. The promise never to modify a deployed model, on the other hand, is a real commitment — that's the one to watch them keep.

#ai#llm#api#openai#startup#dev
Original source
Why We Made Jev — Diogo Almeida, TypeSafe Co-founder & CEO
Latent Space
Open the video

Read next