By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
Latent SpaceWhy I couldn't build Jev at OpenAI — Diogo Almeida, TypeSafe Co-founder & CEO
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
CHAPTERS
- 0:00 – 4:26
Jev launch week: exhaustion, community focus, and “AI economic revolution” energy
Diogo describes the emotional whiplash of launch week: physically burnt out but mentally energized by how strongly developers are responding. He frames Jev as opening a new direction for AI that feels like “early internet energy,” and emphasizes prioritizing engineers and community engagement over VIP access.
- •Diogo says he feels worse emotionally due to nonstop fires, but is excited by the moment
- •He describes the AI field as a “house of mirrors,” and says this week feels more grounded in reality
- •He says an AI-based economic revolution is “back on the table” and developers “get it”
- •He explains why he prioritized community town halls and developer attention over other meetings
- •The host highlights rapid growth and attention; Diogo downplays tracking stats
- 4:26 – 7:00
What Jev is: “System One Models” built for code to consume
Diogo defines Jev as part of a new model class optimized for machine-native, programmable outputs consumed by software rather than chat. He introduces Jev as the first “large programmable model,” designed around integration with programs and maximizing intelligence per dollar.
- •Diogo says the field needs a new class of models; his best name is “System One Models”
- •He contrasts Jev with pre-trained autocomplete-style LLMs and RLHF chatbot instruction-followers
- •He says the goal is for code to be the consumer, aligning with the company name TypeSafe
- •He frames Jev as optimized for intelligence per dollar (referencing Jevons Paradox)
- •He notes trade-offs among reliability, cost, calibration, and speed
- 7:00 – 13:10
RLHF’s downside: mode collapse, calibration loss, and why long strings don’t fail the way a slide predicts
Diogo argues RLHF pushes models toward mode dropping/collapse, harming calibration and decision usefulness. Using an example of a well-known claim about error probability growing with sequence length, he explains why it seems mathematically obvious but fails empirically—because models become conservative and “mode drop” to avoid visible errors.
- •Diogo says RLHF’s downsides (especially mode collapse/dropping) get overlooked
- •He references a famous argument about longer sequences increasing error probability, and calls it empirically wrong
- •He contrasts calibrated “mode covering” behavior with GAN-like “mode dropping” behavior
- •He claims string generation rewards conservative outputs because errors are easy to detect
- •He says overloading string models for decision-making is a bad time
- 13:10 – 18:40
Programmatic AI vs safety alignment: refusals as a “type error” for APIs
Diogo critiques refusal behavior and safety alignment when used at the infrastructure/API layer. He argues refusals are manageable in chat but unacceptable inside dependencies or background systems because they cause stochastic breakage, and he distinguishes “capability alignment” (doing what the user wants) from “safety alignment” (following a lab’s instructions).
- •Diogo says refusals are tolerable in chat but dangerous when embedded as a dependency in software
- •He calls refusals in APIs a “type error” that can unpredictably break downstream systems
- •He says safety alignment can make sense for consumer products but is anti-user in APIs
- •He frames capability alignment as predictability for engineers, while safety alignment follows a lab’s values
- •In response to the host’s concern about harmful use, Diogo says he won’t enforce this at the technological layer to avoid fracturing intelligence
- 18:40 – 22:12
Why TypeSafe rejects public benchmarks and prefers workflow-specific evaluation
Diogo explains his opposition to public benchmarks, calling them gameable and incentivizing “benchmarking with extra steps.” He argues intelligence has a hard-to-quantify “model smell,” so trust should come from real workflow evaluation and continued improvement in reliability (“moving the nines”).
- •Diogo says they’re not stopping private evaluation, but he is “extremely anti-public benchmarks”
- •He argues public benchmarks are gameable and create bad incentives
- •He claims labs historically collected benchmark-like data to inflate scores
- •He says the right evaluation is within the user’s workflow, with measurement tied to that workflow
- •He emphasizes the company’s focus on long-term reliability improvements
- 22:12 – 26:19
“Bitterest lesson” framing: tasks, data, and TypeSafe as a data lab
Diogo argues that choosing the right task (North Star) matters most, and that data drives capabilities. He positions RLHF, RLVR, and his team’s RLCD as task shifts, and says TypeSafe is fundamentally a data lab relying heavily on synthetic data shaped by the task.
- •Diogo says algorithms vs compute is less important than data and especially the “right task”
- •He names RLHF as shifting to instruction-following, RLVR as a smaller shift, and RLCD as a new task
- •He agrees with the host that they are a “data lab,” saying data is how you get reliability “nines”
- •He says their data is synthetic, but depends on the task’s shape and requires high taste and iteration
- •He says they don’t want to train on users’ data due to bias and overfitting to the present
- 26:19 – 30:11
RLCD explained: redefining RLHF as a North Star, not an algorithm
Diogo clarifies that “RLHF” is used inconsistently and often refers more to the objective than the specific PPO method. He frames RLCD similarly: a new North Star of “programs in the loop,” oriented toward programmable AI and removing the human as the primary consumer.
- •Diogo distinguishes multiple meanings of RLHF across historical uses
- •He says what matters is the task/objective (instruction-following), not the specific PPO algorithm
- •He positions RLCD as a new task definition rather than “jargon,” akin to how DPO still fits RLHF’s goal
- •The host summarizes RLCD as programmable AI and removing the human-in-the-loop as the default
- •Diogo adds the nuance that the North Star must stay practical given what models can do well
- 30:11 – 42:45
Why powerful AI hasn’t automated basic work: missing “plugs” into economically valuable workflows
Diogo argues current AI is impressive yet underutilized for real automation because it lacks the right interfaces and reliability for economically valuable work. He claims the “pre-Jev world” was a tragedy of wasted potential, and frames Jev as changing the trajectory by making software integration and new model types possible.
- •Diogo contrasts solving hard problems with failing to automate rote, valuable tasks
- •He says models are a “supercharged engine of automation” without the right plugs to connect to work
- •He predicts the field will explore this space broadly and that Jev creates a new possibility frontier
- •The host paraphrases: don’t treat Jev as the only new model type; explore many directions
- •Diogo emphasizes “early internet” creation energy returning for developers
- 42:45 – 48:49
Reliability as the core goal: robustness vs determinism, and why seeds aren’t the North Star
The discussion drills into reliability, including determinism and robustness. Diogo argues determinism (same input, same output) is less important than robustness (similar inputs, similar outputs), and says determinism can be offered but costs intelligence per dollar under GPU constraints.
- •Diogo calls reliability a catchall for why AI can’t automate: jaggedness, type safety, determinism, etc.
- •He says determinism is mainly useful for some testing, but robustness is the more important property
- •He describes a robustness test using UUID-like nonces to see if semantically identical prompts yield consistent outputs
- •He says deterministic models are possible but reduce intelligence per dollar
- •He emphasizes GPU constraints and prioritizing broad access and experimentation
- 48:49 – 55:27
Model stability promises: versioning, faster iteration, and the tension around long-term support
The host presses on whether models will change under the same name, referencing past API behavior elsewhere. Diogo says changing deployed models is unacceptable for APIs, but also says they plan to ship new versions quickly and aren’t promising long-term support yet, while exploring an LTS approach without fragmenting their fleet.
- •Diogo explicitly says they will not change models once deployed under a given version
- •He says they plan to launch new model versions faster than most providers
- •He cautions they can’t support too many versions due to fleet fragmentation
- •He floats a possible temporary LTS for the current version because developers hate broken dependencies
- •He discusses intelligence-per-dollar vs intelligence-per-second, and being guided by user needs
- 55:27 – 1:00:39
Inside Jev’s API primitives: choice, score, null—and mapping to programming constructs
Diogo explains the three API primitives and why they’re intentionally not standard programming types. He describes naming decisions (including “null” from Bernoulli) and argues these primitives map cleanly to core control-flow patterns like enums/switches, if-statements, and thresholding/sorting.
- •The host lists the primitives: choice, score, null; Diogo explains why “null” is named from Bernoulli probability
- •He says these are new concepts, not bool/int/float, to avoid confusion and foot guns
- •He describes choice as closest to a switch/match over an enum, not a “function call” abstraction
- •He frames nulls as mapping to if-statements and scores to thresholding/sorting comparisons
- •He says more types will come, each mapping to programming primitives
- 1:00:39 – 1:34:47
How to build with Jev: structure, decomposition, verifiability, and “smallest semantic unit” decisions
Diogo argues Jev is meant to live deep inside programs with structured inputs (JSON) rather than string templates. He recommends decomposing tasks into many small, independently evaluable decisions, using parallel cheap questions, and treating failures like software bugs—add the missing question, threshold, and tests to lock in behavior.
- •Diogo says inputs (state/instructions/criteria) can be structured JSON, avoiding string-template thinking
- •He recommends many small calls: decompose into the smallest semantic unit and keep prompts literal and explicit
- •He says decomposition makes behavior evaluable and verifiable compared to monolithic prompts and outputs
- •He gives refusals as an example: ask many independent safety/constraint questions rather than one global “refuse?”
- •He suggests ID-tagging messages and asking many questions over one shared state to save cost
- 1:34:47 – 1:42:18
Use cases: dark data, real-time loops, verification/observability, and computer/voice control
Diogo outlines major use case families they expected and what surprised them. He highlights “dark data” analysis in large companies, coding agents, real-time intelligence loops, and “verify everything” patterns; the host shows a voice-driven computer-use demo that excites Diogo but he emphasizes needing reliability over flashy demos.
- •Diogo defines “dark data” as piles of underused company data that was too expensive to analyze
- •He says coding agents and dark data are likely the biggest volume/money makers
- •He describes “verify everything” use cases like verifying other LLM calls and observability-style checks
- •The host demonstrates voice-driven computer use; Diogo calls it sick but reiterates he’s anti-demo without reliability
- •Diogo says parallel questioning over one state (with IDs) is a practical cost-saving pattern
- 1:42:18 – 1:57:46
Safety, frontier pacing, and RLVR limits: questioning the premise that more RLVR is inevitable
The host asks about researcher concerns around pacing. Diogo argues the debate often assumes everyone must push RLVR harder, which he calls a narrow premise, and says different North Stars exist; he also critiques the way allowing models to “do anything” in the middle can be framed as inevitable while creating risk narratives.
- •Diogo says pacing discussions often assume more RLVR is the path, but he doesn’t think that’s necessary for their models
- •He claims RLVR isn’t just “verifiable rewards” and involves shape/latent reasoning dynamics
- •He argues letting models do more unconstrained actions increases power, and labs may choose that knowingly
- •He calls out “dissolution of responsibility” when danger is treated as an inevitability of progress
- •He reiterates rare progress comes from picking new tasks/North Stars, not just pushing the same approach
- 1:57:46 – 2:03:12
Origins story: from OpenAI frustration to founding TypeSafe and betting on programmatic AI
Diogo recounts the path from working on instruction-following to realizing economic value would come from code calling AI, not humans chatting. He describes fighting to deploy early instruction-following work, then concluding the missing piece was machine-native programmability; he left to start TypeSafe with co-founders after deciding a startup would move faster.
- •Diogo says he pushed hard to deploy instruction-following early, seeing immediate market impact
- •He describes worrying instruction-following mostly turned into copywriting and “slop,” prompting a rethink
- •He says he worked backward from an AI economic revolution and concluded code would be the primary caller
- •He says Sam encouraged him to work on the idea; later he chose a startup after comparing speed to larger orgs
- •He describes recruiting co-founders and rapidly fundraising and building toward the “signs of life”
- 2:03:12 – 2:22:21
What’s next: skepticism of neo-labs, “$1B wouldn’t pre-train,” and coding agents beyond the KV cache
Diogo says he wouldn’t use a billion dollars to pre-train, preferring practical “Frankensteining” and task-driven progress. He criticizes many neo-labs as directionless, then proposes future work he wants others to explore—especially rethinking coding agents beyond KV-cache constraints, enabling better state management, sub-agents, and coordination patterns.
- •Diogo reiterates he wouldn’t pre-train even with $1B, preferring other training and practical methods
- •He says many neo-labs are “crap” because they redo work without a clear task direction
- •He encourages people who have a real North Star task to break the “hive mind” and explore alternatives
- •He proposes exploring coding agents “free from the tyranny of the KV cache,” with better state management and subtask trees
- •He imagines multi-agent coordination with shared readable state and smarter context lookup rather than endless prompt appends
