Former OpenAI Researcher Launches Jev, Says Claude Code and Codex Are Still Assistive

On September 22, TypeSafe CEO and Jev founder Diogo Almeida appeared on the Latent Space podcast and summed up his dissatisfaction in blunt terms: in his view, the AI world before Jev was simply a tragedy. His judgment is that powerful intelligence engines already exist, but the interfaces to connect them into actual business processes are still lacking. In a talk at the AI Engineer conference a few months earlier, he already argued that the next era is not the Claude Code era, because Claude Code and Codex essentially still belong to the same stage—AI's primary role remains assisting around humans.

Jev is his answer. According to Almeida, the most accurate label right now is a System 1 model, with capabilities far beyond decision-making itself; internally, the company also uses terms like machine-native model and large programmable model to describe this new class of models. Its core goal is to make code the direct consumer of model outputs. He particularly emphasizes that the optimization target for such models is intelligence per dollar, and the name Jev comes from the Jevons paradox.

It is important to distinguish: Jev has been released, uses RLCD, and is positioned as a model callable by code—these are confirmed launch facts; whether it can truly deliver a leading position in intelligence per dollar currently rests only on the founder's own statements, with no third-party verification.

Almeida's core criticism of RLHF centers on mode collapse. He says almost no one notices this drawback: RLHF biases models toward generating safer, more common answers, at the expense of the true calibration of probability distributions. He uses pre-GAN image generation models as an analogy—those models often produced blurry images; GANs, by contrast, would directly discard very small categories and generate only the most common ones.

He connects this thread to a broader question: why can AI solve the Millennium Prize Problems in mathematics, yet fail to automate even the most basic tasks? His explanation is that to generate long text that is unlikely to contain obvious errors, the model must be extremely conservative, because once it makes a mistake, people easily notice; by contrast, an answer that looks fine but actually omits subtle points is very hard to detect. He believes this explains both why the intuitive inference of error accumulation has not materialized, and why text models are bad at decision-making.

The difference between RLCD and RLHF lies first in the optimization target: RLHF focuses on making models follow human instructions and give answers that gain approval, while RLCD aims to make the model a capability that software can reliably call. This is Almeida's own definition of the difference between the two methods, a personal claim rather than an independent evaluation conclusion.

Almeida explicitly states he is not opposed to safety itself, but opposes writing specific value judgments directly into the base capabilities of general models. His reasoning: for a model called by programs, suddenly returning a refusal is almost like a type error occurring. When a person interacts with a chatbot and encounters a refusal, at least they can see it and try another way; but if the model is a software dependency running in the background, and a call suddenly refuses, the user calling it may not even know there is such a model underneath.

He distinguishes capability alignment from safety alignment: capability alignment is making the system complete tasks as requested by the user as much as possible, which software engineers badly need, because the more predictable the behavior, the easier it is to integrate the model into programs; safety alignment, by contrast, often means the model must, in addition to following the current user's instructions, prioritize another set of rules set by the model provider, and the two sets of requirements sometimes conflict. He believes setting safety rules for directly human-facing products like ChatGPT and Claude is understandable, but APIs are different—developers need to write programs based on interface behavior.

He prefers to view intelligence as a database, not an AI colleague: one typically would not ask a database to judge on its own, when executing a query, whether the user will ultimately use the results for something bad. He also mentions that a developer asked on Slack whether Jev could be deployed this way, and his first reaction was—we provide an API, and how a specific application is designed should not require our approval for everything. He acknowledges that enterprises can restrict usage for practical considerations, but argues such preferences should not be baked into the model's base-level judgment.

On reliability, Almeida says he values robustness more: if the meaning of the question has not changed, the judgment should not change drastically just because irrelevant characters are added, rather than merely pursuing the same output for the same input. On version management, he says deployed models will not be silently modified, because the API is a dependency in other people's programs; but new versions will be released quickly, and currently he cannot promise permanent maintenance of every old version.

On evaluation, he explicitly dislikes public leaderboards, one reason being that they are easy to game. He says the team compares cost and capability through internal evaluations, pursuing stronger at the same cost and cheaper at the same capability, and what he opposes is optimizing around leaderboards, letting scores drift away from real value. He advises developers to put the model into their own workflows and measure actual performance, not just look at price, speed, or a single overall score.

On task organization, he suggests breaking complex tasks into the smallest, independently judgeable semantic units, providing necessary information through structured input, and then letting code control the final behavior: Choice corresponds to selection branches, Noul corresponds to conditional judgments, Score corresponds to scoring, ranking, and filtering; each step can be evaluated separately, thresholds adjusted, and when capability is insufficient, handed off to humans or not deployed for now. The four application directions he outlines are: analyzing dark data left idle because processing costs are too high, providing fast judgments for real-time processes, checking other models' calls and outputs, and embedding intelligent judgment into the core logic of software, with particular optimism about dark data analysis and coding agents.

Almeida describes the emotions of Jev's first launch week as terrible, himself like a exhausted walking corpse, because too many things were happening at once; but psychologically it was the complete opposite—he felt that this week he was actually more in tune with reality, as if everyone finally saw that AI can do far more than previously imagined. He mentions deciding to prioritize public community communication rather than spending time on VIPs and investors, hoping that engineers and developers truly get the most attention.

On the choice of route, he does not believe slowing down development speed is the only option. His statement is that related discussions often assume everyone must continue increasing investment along the existing RLVR route, but research goals and technical routes can both be re-chosen; how much action space to give the model in order to improve performance is itself a design decision, and should not be treated as an inevitable premise. As for whether researchers should leave frontier labs to start companies, his answer is to look at why they leave: if they just want the freedom to try topics, existing labs may still be most suitable; if they have found a new task worth long-term investment, he would support starting a company.

These statements outline a clear position, but a position is not a result. Whether Jev can make calling intelligence as natural as executing a database query—Almeida himself says it is still far from the ideal state, and he hopes to improve reliability by several more orders of magnitude. This is a promise not yet closed, and the part of the entire launch most in need of subsequent verification.