Why I couldn't build Jev at OpenAI — Diogo Almeida, TypeSafe Co-founder & CEO

Summary

TypeSafe co-founder and CEO Diogo Almeida argues that AI’s difficulty automating routine work is not simply due to a shortage of intelligence or compute. In his view, today’s models are optimized mainly to produce text for people, while much valuable work requires dependable, machine-readable outputs that software can use directly. TypeSafe’s Jev is an early attempt to build for that different goal.

Jev and “System One” Models

Almeida describes Jev as a machine-native, programmable model—part of a category TypeSafe calls System One models. Rather than treating a chatbot response as the main product, the aim is to make model outputs useful inside software programs and workflows. He compares the ambition to a general-purpose “cognitive core” that developers can build on.

Jev is optimized around intelligence per dollar, with reliability and practical usefulness central to the company’s goals. Speed can matter too, especially for real-time applications, Almeida says, but cheaper or faster output is not valuable if it is not sufficiently intelligent and dependable.

He distinguishes this approach from:

• RLHF, which he frames as optimizing models to follow human instructions or preferences.
• RLVR, which he characterizes as emphasizing programmatically verifiable tasks and benchmarks, often involving reasoning.
• RLCD, which he presents as a different training objective or “north star”: making AI more suitable for programmable, software-mediated use. He does not give a detailed technical description of the method in the interview.

Calibration, Reliability, and Model Training

A major theme is calibration: whether a model’s confidence reflects how likely its answer is to be correct. Almeida argues that preference-based training can encourage mode dropping or mode collapse—favoring common, preferred-looking answers while losing less common possibilities. He says this can make models overconfident and poorly suited to decisions, especially when they must produce long strings where subtle errors are difficult to detect.

For software, he prioritizes robustness over strict determinism. Determinism means the same input always produces the same output; robustness means semantically similar inputs tend to produce similar results. Deterministic behavior may be useful for some applications, Almeida says, but could involve a trade-off with intelligence per dollar.

TypeSafe uses internal evaluations, Almeida says, but rejects public benchmarks as a primary measure because they can be gamed and may not reflect real workflows. His preferred standard is to test a model on the specific task that matters and keep improving its reliability there.

He also emphasizes data and task design over simply scaling compute. TypeSafe, he says, thinks of itself as highly data-focused: different objectives require different kinds of data, and data curation can substantially affect capability. The company does not want to train on users’ data, partly because common real-world queries could bias a model toward present-day usage rather than future software applications.

API Design and Practical Usage Guidance

The interview offers several concrete suggestions for developers using Jev:

• Use structured inputs rather than flattening everything into a prompt. Almeida recommends passing state, instructions, and criteria as structured data, such as nested JSON, instead of treating the system message as a large catch-all string.
• Break work into small semantic decisions. He advises decomposing a large task into focused questions that can be evaluated and tested independently. This may require more calls, but can make a workflow easier to inspect and maintain.
• Ask many questions about a shared state when appropriate. For long inputs, he suggests identifying individual items and asking separate questions about them, so a program can evaluate each item rather than relying on one broad response.
• Make instructions explicit and literal. He recommends clearly identifying the exact text or state a question concerns.
• Use model outputs as typed program primitives. Jev’s API concepts include:
  • Choices, which Almeida compares to an enum or switch/match statement.
  • “Nules” (the subtitle spelling; likely a named API type), which he compares to conditions or if statements.
  • Scores, which can be used for ranking or thresholding.

Almeida says these are intentionally not ordinary programming types: for example, a score is not simply an integer or float.

• Use thresholds and escalation for uncertain cases. Almeida suggests setting thresholds based on examples and sending ambiguous or high-risk cases to a larger model or a human. He gives automated trading as an example of a difficult task where deployment should be approached cautiously.
• Treat failures as testable bugs. If a system misses a particular case, developers can add a more specific question, threshold, or test case and measure it over time.

Almeida says fine-tuning may be considered in the future, but is cautious about it: specializing a model for one narrow task might reduce the generality that helps with edge cases. He also imagines a future cascade of different-sized models, with simpler cases handled cheaply and harder ones routed to more capable models. This is presented as a possibility, not a current feature.

Refusals, Safety, and Software Infrastructure

Almeida argues that refusal behavior appropriate for a consumer chatbot can be disruptive when embedded inside an API or software dependency. If a background component unpredictably refuses a request, a larger application may fail without its users understanding why. He therefore distinguishes product-level safety controls from the behavior of a general-purpose model used as infrastructure.

His position is that developers should have control over how a model is used within their applications, while acknowledging that there are legitimate concerns about harmful uses. He opposes imposing such constraints at the underlying general-purpose technology layer, arguing that repeated restrictions can fragment capability. These are Almeida’s views, not a technical consensus presented in the interview.

Product Plans, Infrastructure, and Launch

Almeida says Jev’s launch attracted substantial developer interest, including sustained API activity he describes as exceeding one trillion tokens per day. He emphasizes that signups and launch attention matter less than developers incorporating the model into ongoing workflows. He also praises TypeSafe’s infrastructure team and says the company is hiring data and platform staff.

He does not promise to keep a specific model version unchanged indefinitely. TypeSafe expects to iterate quickly; Almeida says the company may consider long-term support for a version, but has not committed to it. He says the company does not plan to change already-deployed models in place, while also warning that developers should not assume long-term support for every version.

Almeida repeatedly says TypeSafe is not optimizing for public benchmark rankings or splashy demos. The goal, he says, is to become a reliable developer platform and eventually offer more than one kind or size of machine-native model.

Use Cases and Coding Agents

Almeida identifies several promising application areas:

1. “Dark data”: Analyzing large stores of company data that have been too costly to process with models.
2. Coding agents: Using Jev within software-development workflows.
3. Real-time applications: Situations where reducing latency can improve a product or allow additional model calls.
4. Verification and observability: Checking outputs or individual parts of an LLM workflow.
5. “Smart software”: Applications with AI embedded in their logic rather than added as a chat box.
6. Computer use and games: Almeida reacts positively to a demo in which voice commands control a computer, but stresses that reliability still needs to be established.

A coding-agent idea Almeida highlights is loosening the dependence on a single model’s KV cache—the stored attention state used during generation. He argues that this dependence can constrain routing, subtasks, and state management, and make it harder to use multiple models or agents effectively. He imagines coding systems that explicitly track task state, retrieve only relevant context, coordinate parallel agents, and reuse historical context more intelligently. These are research directions he wants developers to explore, not features he says Jev already provides.

Review, Demo, and Guide Content

• Product demonstration: The host shows a voice-driven computer-use example involving note-taking, opening a browser, searching, and navigating to a website. Almeida calls it exciting but says he wants to see such systems tested for reliability.
• Developer guidance: The discussion includes practical advice on structured inputs, decomposing tasks, scoring and thresholds, and testing individual decisions. Almeida also recommends TypeSafe’s cookbooks, which he says were built around real customer problems and contain more advanced examples.
• Review: The episode is not a formal independent product review. The host shares positive early impressions and describes testing Jev on reasoning tasks, while Almeida cautions against treating demos or benchmarks as sufficient proof of reliability.

Main Speakers and Sources

• Diogo Almeida — TypeSafe co-founder and CEO; discusses Jev, System One models, training objectives, API design, and the company’s product philosophy.
• swyx — Host of Latent Space; asks technical and product questions, shares early testing impressions, and presents the computer-use demo.