Why We Made Jev — Diogo Almeida, TypeSafe Co-founder & CEO

In this Latent Space interview, TypeSafe co-founder Diogo Almeida describes Jev as a machine-native model: its output is intended to be consumed by code. He uses “system one” and “large programmable model” to describe a direction, while saying the company is not committed to a final category name.

The distinction is about the task being optimized. A conversational response must work for a person reading it. A component inside software must supply something the surrounding program can use consistently. Almeida wants intelligence to become a dependency deep inside applications, rather than a chat window attached to otherwise unchanged software.

He describes Jev's commercial objective as intelligence per dollar. Low cost and speed matter because they make more calls feasible, but the thing being purchased is useful intelligence. His claims about a leading frontier are the founder's assessment, not an independently reproduced benchmark in this article.

Almeida argues that an unexpected refusal is more than an annoying conversational answer when it occurs inside a background dependency. Downstream users may not know that a model was involved, and software needs a defined response to the event.

He therefore prefers application-level policy to restrictions embedded in the cognitive component. The host pushes back with harmful uses, including warfare. Almeida says he would prefer beneficial uses and would support them, but does not want those preferences implemented at that technological layer.

This is a disagreement about where responsibility and control belong, not a demonstration that the safety question has been solved. A typed interface does not remove the downstream application's responsibility for permissions, consequences and failure handling. The interview's policy argument should not be silently converted into a technical guarantee.

Almeida is sharply critical of public benchmarks because a visible target can shape data collection and reward behavior that looks impressive without improving the intended task. He argues for evaluating a model inside the exact workflow where it will be used.

He later clarifies that the company has internal evaluations. He is not opposed to measurement; his concern is the incentive to fool oneself or optimize a proxy. Comparing models along an intelligence-and-cost frontier still requires measurements and discipline about what the test represents.

That also limits what a launch demonstration establishes. A compelling example can reveal a possibility, but it does not show failure rates across ordinary and unusual inputs. His desired outcome is a developer who can rely on a component without repeatedly wondering whether it will work. He acknowledges that achieving that level of reliability remains a long effort.

Almeida says the shape of data depends on the task: feedback for instruction following differs from an environment used for a verifiable-reward task. He describes RLCD in terms of a new task or north star for programmable intelligence, rather than presenting a published algorithm in the interview.

He argues that simply collecting current user requests would overemphasize common present-day uses. His data team instead tries to identify uneven capabilities and address them in a way that generalizes. That is his explanation of the company's approach; the conversation does not disclose enough implementation detail to reproduce the training system.

His criticism of conversational training and mode dropping belongs to the same thesis. He believes optimization for convincing strings can distort the probability information software needs. These are technical arguments from the guest, not a proof that all conversational models fail for one universal reason or that Jev has perfect calibration.

The host asks whether the same input always produces the same output. Almeida distinguishes determinism from robustness: identical inputs producing identical outputs is one property; semantically similar inputs producing similar judgments is another.

He gives a perturbation test such as adding an irrelevant identifier or nonce. If the underlying question has not changed, a large change in the result would be concerning. That tests whether incidental surface details move the decision, not merely whether a fixed seed repeats one answer.

He considers determinism potentially useful, including for tests, but says it can conflict with the company's cost objective. The host expects developers to request it anyway. The discussion leaves a trade-off and an open product question, rather than announcing that deterministic behavior is available or unnecessary in every use case.

The host also asks whether capacity pressure might lead the provider to change an existing model behind the same name. Almeida says deployed models will not be changed in that way, while explaining that the company expects to release new models quickly.

He separately declines to promise long-term support for every version. He considers support for a particular version and discusses future ideas, but does not commit to keeping all exact models indefinitely. Serving many versions would fragment capacity.

Those statements need to remain separate. An immutable version can support reproducibility while it is available; a support policy determines how long an application can depend on it. The interview is a historical account of the founder's commitments and uncertainties, not a substitute for checking a current service contract.

The API discussion centers on choice, nool and score. Almeida explains the unusual naming as an attempt to avoid misleading developers into treating them as ordinary language types. In particular, a score is not simply an integer obtained by asking a text model to print one.

Choice resembles selecting an enum branch that can feed a switch statement. Nool is described as a continuous, Bernoulli-like judgment associated with an if decision. A score can support ordering or thresholding. The shared idea is to expose information that code can use, including uncertainty, rather than hide the decision inside a prose answer.

The article describes those conceptual mappings without inventing a current SDK signature. The host and guest are discussing evolving documentation, and the important boundary is the meaning of the output and the decision the program makes with it.

60:00View full image

Almeida emphasizes that state, instructions and criteria can be structured objects. If a program already has nested data, turning all of it into a large text template can discard a useful boundary and make the code harder to inspect.

His analogy is an AI function: identify which subset of the available state is relevant, pass it explicitly and ask a defined question. A giant system message containing every instruction resembles a global variable carrying unrelated concerns.

He also acknowledges that reasoning over deeper nested structure is difficult and remains an area of work. Structured input makes the interface more explicit; it does not prove the model understands every level correctly.

Almeida recommends many small questions, each representing a semantic unit that can be evaluated. The application can then combine their outputs using explicit code rather than asking one large model to produce and police an entire policy.

The host supplies a necessary counterexample: in earlier systems, splitting one pipeline into a hundred calls was slower, more expensive and less accurate. Almeida agrees that repetition and orchestration can be inconvenient. The proposal depends on the properties and economics of the component, not on a law that more calls always improve a system.

The potential engineering benefit is observability. A developer can check which question was asked, which result crossed a threshold and which branch ran. Permissions such as access to a directory or release of a key should be enforced by the program around the model. A probabilistic judgment is not itself an access-control guarantee.

Asked how to decompose, Almeida recommends the smallest meaningful question, with precise references to the relevant object. He favors explicit structure and wording that makes it clear what is being judged.

His example is a refusal policy with several independently specified conditions. If one situation is missed, the team can add the relevant question, choose a threshold using real examples and retain the case as a regression test. That is easier to inspect than hoping an additional paragraph in a large prompt remains effective forever.

There are still cases where the model is not good enough. Almeida mentions uncertainty around a complicated customer situation as a reason to escalate to a person. A test can remain in the code permanently while the model's error rate on that test and related cases still needs to be measured.

The host challenges the available controls: what if the probability is locally wrong? Merely changing a threshold or rewriting a question may not address a model that is making the wrong judgment.

Almeida explicitly rejects the premise that he claimed perfect calibration. He says the model will get many things wrong, invites reports and acknowledges that “good enough” depends on the application. This admission is essential to interpreting the earlier reliability ambition.

Fine-tuning, cascades of models and dynamic selection appear as possibilities or desires. They are not launch commitments. A higher-level application still needs to decide when to accept a result, spend more, involve a human or avoid deployment for that task.

The later discussion asks which tasks fit the model. The host reports strong single-hop behavior but weakening results as multiple reasoning steps are required. Almeida treats the boundary as empirical: the company is trying to expose useful properties of existing model capabilities, and does not know every eventual limit.

He discusses reasoning, vision and longer context without promising a particular method or feature. Even a model that performs well on some tasks can degrade on others. The category label should not replace a test of the actual problem.

That preserves a tension in the interview. The vision is broad infrastructure, while the launch has narrower capabilities. The founder wants to expand what software can do, but a future direction should not be read as something a developer can already rely on.

Almeida groups opportunities into large stores of previously uneconomic-to-analyze data, real-time applications, verification of other model calls and more intrinsically intelligent software. He suggests labeling pieces of a shared state so that several questions can refer to particular items.

The economic idea is to make a previously impractical check or branch affordable. It is not necessarily to add calls indiscriminately: he says he would prefer a system that solves the problem while spending less, including reducing expensive reasoning calls where appropriate.

Computer-use and voice demonstrations excite him, but he also asks for weaknesses to be found and repaired. Launch traffic and striking demos are not substitutes for sustained workflow performance. His account of pre-launch validation includes many people not understanding the product and little revenue, which complicates any simple story of obvious demand from the outset.

Near the end, Almeida asks what agent design would look like without being organized primarily around an append-only context and its KV-cache economics. He imagines explicit subtasks, labeled state, retrieval of relevant history and better sharing between readers and writers.

A subtask might return the needed result rather than all of its history. Another process might inspect a relevant portion of state without reconstructing the entire conversation. These ideas connect the model interface to familiar software questions about abstraction, memory and coordination.

He is careful that these are research directions without a guarantee they will work. They are not evidence that distributed locking can safely be delegated to a probabilistic model or that a new multi-agent architecture is already solved.

Almeida traces the project to a question after instruction-following models: if AI becomes a general economic input through an API, will most calls be made by humans or by code? He concluded that software would be the dominant caller, while much optimization remained focused on the human-facing experience.

That founding story explains the emphasis on probabilities, control flow, structured state and developer control. It does not establish the interview's broader forecasts about economic growth, employment or the future competitive position of model providers.

The practical test of the vision is narrower and more demanding: can a defined workflow use the output, measure failures, preserve its boundaries and remain maintainable as the provider evolves? The interview supplies design questions and acknowledged limitations, rather than a reason to skip that work.