TypeSafe Pushes In-Code Models as Agents Fail to Improve Software
Ben Horowitz, Martin Casado, Diogo Almeida
AI coding assistants accelerate text generation without improving software quality, positioning incumbent SaaS vendors to capture the largest automation gains by embedding probabilistic reasoning directly into execution logic.
TypeSafe AI argues that existing coding agents accelerate code production but fail to improve software quality, whereas embedding intelligent classifiers directly inside state machines expands software's functional capabilities. (0:00)
Despite widespread market fears of a 'SaaSpocalypse,' incumbent enterprise SaaS players are positioned to capture massive value by embedding probabilistic intelligence into their established, workflow-rich systems. (30:00)
The industry's persistent automation gap stems from post-RLHF optimization toward human-judged benchmarks and conversational polish rather than predictable, background task reliability. (20:00)
In the long-term architecture of computing, 'many nines' of AI model calls will operate machine-to-machine deep within system guts (like optimistic routing and heuristics) rather than generating surface-level text for humans. (36:10)
Detailed notes
## Background
Published on September 28, 2026, by a16z partners Ben Horowitz and Martin Casado alongside TypeSafe AI founder Diogo Almeida, this podcast episode addresses the paradox of why artificial intelligence is extraordinarily capable yet practical automation remains largely absent. According to the page description, Almeida discusses TypeSafe's model Jev, which embeds probabilistic intelligence directly into software logic rather than using AI merely to generate traditional code.
## TL;DR
Diogo Almeida argues that contemporary coding agents merely accelerate the production of identical, legacy software instead of genuinely expanding computing's capabilities. TypeSafe addresses this bottleneck with Jev, an in-program primitive that embeds natural language understanding and probabilistic classification directly into deterministic state machines. By rejecting the quasi-religious pursuit of god-like recursive self-improvement in favor of reliable, multi-nine production engineering, Almeida explains why incumbent SaaS platforms stand to gain the most by transforming rigid user workflows. Ultimately, the discussion reframes the future of computing away from brittle agent while loops and chat windows toward silent, machine-to-machine infrastructure that reliably executes human intent.
## Atmosphere & style
The conversation carries a punchy, irreverent, and intensely pragmatic energy, cutting through frontier lab mysticism with grounded systems-engineering grit. Horowitz and Casado act as enthusiastic sparring partners, playfully teasing Almeida about his competitive math background before pivoting into deep technical debates over state machines and reliability tiers. There is a palpable sense of shared relief in moving past overhyped AGI narratives to celebrate software that simply works, making the dialogue feel like an invigorating, behind-the-scenes whiteboard session among veteran builders.
## Bulletin
- `00:00` TypeSafe AI argues that existing coding agents accelerate code production but fail to improve software quality, whereas embedding intelligent classifiers directly inside state machines expands software's functional capabilities.
- `30:00` Despite widespread market fears of a 'SaaSpocalypse,' incumbent enterprise SaaS players are positioned to capture massive value by embedding probabilistic intelligence into their established, workflow-rich systems.
- `20:00` The industry's persistent automation gap stems from post-RLHF optimization toward human-judged benchmarks and conversational polish rather than predictable, background task reliability.
- `36:10` In the long-term architecture of computing, 'many nines' of AI model calls will operate machine-to-machine deep within system guts (like optimistic routing and heuristics) rather than generating surface-level text for humans.
## Key takeaways
- `00:00` Current coding assistants like Claude Code and Cursor accelerate software authoring without fundamentally altering the expressive limits or underlying quality of traditional software.
- `05:00` TypeSafe's model, Jev, operates as an embedded in-program classifier that evaluates state and natural language intent to return discrete, probabilistic decisions with confidence scores.
- `12:35` Diogo Almeida rejects the 'mono-model' ideology of an all-powerful, single AGI deity in favor of composable, production-grade systems encapsulated by the motto 'we build prod, not God.'
- `20:00` The post-RLHF shift led labs to optimize for subjective human evaluators and conversational fluency rather than the deterministic execution needed for end-to-end automation.
- `22:15` Software automation does not require solving 100% of heavy-tailed edge cases upfront; applying the Jevons paradox to software task efficiency creates entirely new categories of productive human labor.
- `22:15` Enterprise customer support metrics often mask severe limitations, automating predictable password resets while failing on the messy 50% long tail of real user issues.
- `27:01` Reliability in probabilistic computing divides into three distinct tiers: basic infrastructure uptime, strict bit-for-bit determinism, and robust, predictable semantic reasoning.
- `28:38` Coding agents handle code syntax adequately but yield mediocre (50th-percentile) architectural decisions, leaving system architecture as a uniquely human creative domain.
- `30:00` The anticipated 'SaaSpocalypse' is turning into a 'Sassapalooza' because established SaaS platforms have deep domain workflows and customer acquisition moats that become drastically more powerful with embedded intelligence.
- `33:30` Automating the typing of 10-line software pull requests does not make applications better and frequently increases bloat, bugs, and security risks when human review is bypassed.
- `36:10` The vast majority of future AI invocations will not generate text for human consumption, but will run silently as high-speed, machine-to-machine heuristics deep within software infrastructure.
- `40:00` The ubiquitous agent 'while loop' emerged as a crutch after early developers failed to force LLMs into strict JSON output schemas, retreating into endless prompt feedback cycles.
- `41:12` The ultimate destination of reliable AI is realizing the classic computing principle of DWIM ('Do What I Mean'), where technology accurately interprets intent without micromanaged prompt engineering.
## Detailed walkthrough
### `00:00` Where the Fuck Is All the Automation?
Ben Horowitz and Martin Casado introduce Diogo Almeida, founder of TypeSafe AI, calling him a hero who is driving not just an interesting product, but an important movement in computing. When prompted for an elevator pitch for TypeSafe and its model, Jev, Diogo cuts straight to the core frustration behind the entire company: “Where the fuck is all the automation?” Despite modern artificial intelligence being extraordinarily capable, it remains painfully useless across almost all practical workflows outside of conversational chatbots and coding assistants. As Diogo emphasizes, “OpenAI has been trying to automate customer service since 2020,” yet real end-to-end automation remains conspicuously absent across the tech landscape. TypeSafe's ethos deliberately pushes back against common big-lab grandstanding: “My favorite thing that you guys say is we build prod, not God.” Rather than chasing recursive self-improvement (RSI) or pretending a digital deity will magically solve human problems, TypeSafe aims to build reliable production systems.
```mermaid
flowchart LR
accTitle: Paradigm Shift in AI Software Development
accDescr: Contrasting code generation assistants with embedded AI primitives inside programs.
subgraph LLMApproach["Existing Coding Assistants (Claude Code, Codex, Cursor)"]
A["Natural Language Prompt"] --> B["Generates Standard Source Code"]
B --> C["Same Traditional Software (Unchanged in 10 Years)"]
end
subgraph JevApproach["TypeSafe AI / Jev Primitive"]
D["Natural Language Intent & State"] --> E["Embedded Jev Model / Classifier"]
E --> F["Probabilistic State Machine Decisions in Runtime"]
end
```
Diogo contrasts his philosophy with popular developer tools like Claude Code, Codex, and Cursor, which Garry Tan aptly termed "just-in-time software." Those systems allow people to generate standard imperative programs using natural language prompts, but the resulting output carries the exact same expressive boundaries that software has had for decades. Coding agents might help developers write code faster, but the software produced is fundamentally identical—and arguably worse in quality. Instead of merely automating software engineering tasks, Diogo wants to expand the functional vocabulary of software itself:
- Rather than replacing human software engineers with brittle code generators, TypeSafe provides a primitive that puts intelligence directly inside software systems.
- Programming at its best is “hyper-specifying valuable things and then infinitely replicating them,” a superpower that AI should enhance rather than flatten into standard code generation.
- Diogo does not believe current systems are on a credible path to recursive self-improvement (RSI), arguing that practical progress requires making software inherently smarter rather than chasing God-like entities.
---
`05:00` Jev as an In-Program Primitive and Diogo's Unorthodox Path
Martin Casado points out that coding assistants merely output what a human would have written ten years ago, whereas Jev acts as an embedded runtime primitive—similar to an intelligent library that accepts natural language intent alongside a state machine and outputs decisions with explicit confidence levels. Diogo embraces the comparison to classical machine learning, acknowledging that Jev is proudly a classifier: “Classifiers are sick. Classifiers were designed to be useful.” During onboarding, Diogo sketches a Venn diagram comparing what AI does well with what is genuinely valuable inside code. Jev intentionally avoids messy outputs like extrapolated floating-point numbers, delivering instead predictable, discrete outcomes. In Diogo's estimation, integrating Jev today is already far more effective and accessible than having an elite 2019 machine learning engineering (MLE) team manually gathering datasets and hand-tuning custom models.
When asked whether programming is drifting toward a slider between pure text prompts and traditional imperative logic, Diogo confirms that he views it as a slider, noting that Jev intentionally names its input `state` so developers treat it as internal program architecture rather than an external chat interface. Because millisecond latency constraints make real-time evaluation behave more like a fast database lookup than a lightweight standard library function, his current guiding optimization metric is “intelligence per dollar” rather than raw intelligence per second.
Turning to Diogo's background, Martin marvels at the rare alchemy of someone who simultaneously speaks like an AI researcher, a systems engineer, and a hardcore programmer. Diogo attributes his perspective to an unconventional path, jokingly describing how he started out as an award-winning mathlete: “I was good enough at math to get girls.” Ben and Martin tease him on the spot, demanding to know what kind of girls one attracts through competitive mathematics and begging him to share details to inspire the youth, to which Diogo jokingly pleads, “Don't do it. Don't do it.”
`10:00` From Mathlete Competitions to Systems Hacking and OpenAI
Diogo Almeida reflects on how he ended up in artificial intelligence despite not actually loving pure mathematics. Growing up as a self-described "mathlete," he admits it feels a bit cringe in retrospect because he was just a "big fish in Little Pond" who never really tried and hated that the discipline was solely about winning competitions. Computer science, by contrast, felt like math made useful, cool, and fun. He still loves administering algorithms interviews because it lets him suss out candidates effectively, viewing himself fundamentally as a computer scientist rather than an AI researcher. His breakthrough entry into the field came from winning a Kaggle competition—not via intricate mathematical theory, but by simply out-engineering the problem: “And what actually got me into it was I also won a Kaggle competition, not from sophisticated math, but from just automating the fuck out of it. You know, more nested loops. It solved a systems problem.”
That win led to a mandatory talk at NeurIPS, an honor he initially resented because he just wanted to be down "in the mines" coding. However, the competition host, Isabelle Guyon—co-inventor and first author of the Support Vector Machine (SVM)—recognized that he did not fit the traditional research mold, took him under her wing, and introduced him across the AI community. This propelled his career through a startup with Jeremy Howard, followed by a tenure at Google Brain, an early retirement stint, and ultimately joining OpenAI simply because he grew bored and realized building AI was immensely fun.
- **Career Path:** Math competitor $\to$ Kaggle winner $\to$ NeurIPS presentation $\to$ Mentored by Isabelle Guyon $\to$ Startup with Jeremy Howard $\to$ Google Brain $\to$ Retirement $\to$ OpenAI.
- **Philosophy on Interviewing:** Still enjoys conducting algorithms interviews as an effective diagnostic tool to evaluate how candidates think.
---
`12:35` "Prod, Not God": The Mono-Model Kool-Aid vs. Missing Automation
Ben Horowitz and Martin Casado contrast Diogo’s upbeat, practical demeanor with the prevailing, quasi-religious gloom of other frontier AI lab leaders. They highlight TypeSafe's motto, "we build prod, not God," pointing out how Diogo's worldview anticipates more and better jobs rather than mass displacement. Diogo agrees, emphasizing that outside observer complaints often sound like narrow machine learning grievances while developers are having an absolute party discovering what they can build with Jev. He traces the broader dread to what he calls the "mono model Kool-Aid"—the belief in "one big brain to rule them all."
Diogo expresses deep frustration at the discordance between AI’s perceived omnipotence and the utter absence of routine automation in everyday life. If models are supposedly brilliant and the economic incentives are enormous, he asks why so many basic, soul-crushing tasks remain manual:
> “And part of the pain is on the where the fuck is all the automation. How can we have AI be so freaking smart? And there's so much financial incentive to automate stuff.”
Horowitz chimes in with an anecdote from that morning involving David George, head of the a16z growth fund, who praised a new AI tool called Muse simply because it finally automated canceling his *New York Times* subscription—a tiny glimpse into the mountain of painful administrative friction that software should be handling automatically.
```mermaid
flowchart TD
accTitle: Mono-Model vs Composable Systems
accDescr: Contrasting the single all-powerful frontier model with modular, production-ready software systems.
subgraph FrontierDystopia["The 'Mono-Model' Anti-Pattern"]
A["'One Big Brain to Rule Them All'"] --> B["Focus on Demos & Outliers"]
B --> C["Ominous Cultural Narrative & Stalled Automation"]
end
subgraph TypeSafeApproach["TypeSafe / Jev Philosophy"]
D["'We Build Prod, Not God'"] --> E["Deterministic Guarantees & Background Execution"]
E --> F["Composable, Reliable Everyday Automation"]
end
```
---
`15:43` The Limits of RLHF and Disillusionment with AGI
Discussing what it takes to achieve real automation, Diogo argues against the industry's obsession with brittle demos and outlier capabilities. For software to run safely in production without paging an engineer at midnight, it must have statistical guarantees and run reliably in the background rather than demanding constant human oversight. Casado recalls a 2017 conversation where Diogo already maintained a systems-first view, including a talk titled something like *AI: Modular in Theory, Inflexible in Practice*.
Diogo explains that his perspective truly crystallized in late 2021 during the development of Reinforcement Learning from Human Feedback (RLHF) prior to the launch of ChatGPT. When testing whether RLHF was truly generalizing or merely cheating—a constant risk in machine learning—the OpenAI team tested counterfactual queries like *"why is it important to eat socks before meditating?"*, ensuring the prompt existed nowhere online. The models produced surprisingly plausible, structured rationalizations, convincing the team that RLHF had genuinely unlocked broad generalization. However, this high gave way to profound disillusionment when the release failed to bridge the gap to actual general intelligence:
> “I really thought that the model had a decent chance of being AGI. And when it didn't, that was when my whole world came crashing down.”
While RLHF generalized remarkably well, subsequent paradigms like RLVR (Reinforcement Learning with Verifiable Rewards) demonstrated far narrower generalization. Reflecting on early OpenAI internal culture around 2020, Diogo recalls how vaguely defined the mission was, with engineers half-jokingly defining AGI as "Ilya in every if statement"—an intentionally wide tent designed to encompass wildly differing technical visions under one banner.
`20:00` The Automation Disconnect: RLHF, Benchmarks, and the Drive-Through Test
Diogo Almeida reflects on the gap between current AI capabilities and real-world utility. While he remains skeptical that artificial intelligence is currently on the path to recursive self-improvement (RSI), he strongly believes that OpenAI’s stated benchmark for Artificial General Intelligence—automating the vast majority of economically valuable human work—is completely achievable right now. Much of human work by sheer volume is simple, repetitive, and easily outsourced using basic procedural instructions. From Diogo’s perspective, modern foundation models have possessed the baseline intelligence required to execute those tasks for a long time, leaving him frustrated by the industry's failure to deliver practical automation.
Instead of translating raw model capability into automated production, the post-RLHF (Reinforcement Learning from Human Feedback) era sent the industry down an unproductive path of overpromising and underdelivering. Whereas GPT-3 was relatively well-calibrated, RLHF shifted model development toward appeasing human judges rather than driving true task execution. Because benchmarks and human raters evaluate how convincing an answer feels, labs optimized for the subjective judge rather than the underlying automation, creating a stark paradox in what the technology can actually do.
Martin Casado pushes back with a counterargument: perhaps AI struggles with real-world tasks because the distribution of the real world is heavy-tailed and full of messy edge cases, unlike lower-dimensional, highly documented digital domains like code or mathematics. Diogo acknowledges the existence of the long tail but rejects data scarcity as an all-encompassing excuse, pointing to glaring contradictions in current frontier benchmarks versus everyday reality.
> “Are you really telling me that math is solved, or even two years ago, GPQA, that Google proof question answering is solved, but we still can't handle a drive-through, right?” — Diogo Almeida
- **Economic tasks vs. RSI:** Diogo distinguishes recursive self-improvement from automating routine economic labor, arguing that the intelligence required for the latter has been latent in models since earlier generations.
- **The RLHF effect:** Optimizing for human evaluators improved conversational polish and perceived quality while distracting from the harder engineering work of end-to-end task automation.
- **The real-world distribution debate:** Martin and Diogo debate whether failures in physical or operational tasks stem from lacking data on heavy-tailed distributions or a failure to engineer pragmatic reliability.
---
`22:15` Long Tails, Jevons Paradox, and the Reality of Enterprise Support
Diogo argues that software engineering has never required capturing 100% of the long tail to deliver massive economic value. Instead, developers should approach automation pragmatically through the lens of return on investment (ROI). He invokes the classic virtues of a programmer from the Perl days—specifically laziness, where an engineer willingly invests ten hours writing software to automate a five-minute task so they never have to perform it again. Automating core operational tasks does not eliminate work; rather, in accordance with the Jevons paradox (which inspired the naming of Jev), making automation efficient will spur demand and generate entirely new categories of human labor.
In the corporate world, however, meaningful automation remains surprisingly absent outside of software development. Despite OpenAI actively working to automate customer support since 2020, production deployments across enterprises have largely stalled. Martin shares an anecdote from analyzing customer support startups prior to the generative AI boom: companies would routinely boast about automating 95% of incoming help desk calls, but inspecting the data revealed that the overwhelming bulk of resolved tickets were nothing more than routine password resets. Once the analysis looked at unique user issues, resolution rates plummeted to roughly 50%, highlighting how quickly automated systems collapse when confronted with the natural variance of human problems.
> “And it was interesting, you'd meet a company, and the company would say, we answer 95% of all help desk calls.” — Martin Casado
- **The Programmer's Virtues:** Diogo cites Larry Wall’s classic programmer virtue of laziness as an economic justification: investing substantial engineering time upfront to eliminate repetitive work permanently.
- **The Jevons Paradox:** The product name "Jev" is directly derived from Jevons paradox—the principle that increasing the efficiency of a resource (like intelligence or task automation) drives higher overall consumption and creates new types of work.
- **Support resolution realities:** High-percentage automation metrics in enterprise support frequently mask low semantic coverage, resolving repetitive password resets while failing on the diverse 50% long tail of real user needs.
---
`25:00` Jev’s Surprise Reception and the Fight for "Nines of Reliability"
Turning to TypeSafe AI's release of Jev, Martin asks Diogo whether he anticipated the sheer breadth of use cases pouring in, noting that people seem to ping him hourly with novel implementations. Diogo confesses he was completely stunned by the reception. While ChatGPT achieved mainstream viral adoption among consumers, expecting a developer-oriented primitive to ignite that level of cultural momentum seemed impossible. The launch sparked an unexpected community dynamic on Twitter, drawing in developer memes and enthusiastic interest even from non-technical friends who simply wanted to join the celebration.
Beneath the viral excitement lies years of grinding engineering centered on a single obsession: reliability. Diogo stresses that while raw market capitalization often chases flashy benchmark spikes, chasing incremental "nines" of reliability is the single most valuable contribution to software development. Much like the introduction of the electric motor brought raw power directly into factories and workstations, delivering reliable machine intelligence into developer environments will unlock classes of applications that founders and platforms cannot yet anticipate.
> “The amount I care about reliability is... It's a lot. Like, reliability is what this thing is.” — Diogo Almeida
```mermaid
flowchart TD
accTitle: Tiers of Reliability in AI Software
accDescr: Diogo Almeida's framework separating basic availability from true robust machine intelligence.
subgraph Infrastructure["Level 1: System Availability"]
A["Uptime & SLAs<br/>(Is the service reachable?)"]
end
subgraph Determinism["Level 2: Strict Reproducibility"]
B["Input-Output Invariance<br/>(Good for unit tests, fragile with UUIDs/dynamic context)"]
end
subgraph Robustness["Level 3: Robust Intelligence (Jev Target)"]
C["Consistent Semantic Reasoning<br/>(Predictable, human-level intelligence on every execution)"]
end
- **Unexpected viral reach:** The launch of Jev triggered widespread meme culture and adoption across technical and non-technical circles alike, which Diogo admits would have seemed insane to predict prior to launch.
- **The "nines" of reliability:** Diogo views software reliability not merely as an enterprise checklist item, but as the foundational catalyst that makes probabilistic intelligence programmable.
- **The electric motor analogy:** Embedding reliable, decentralized intelligence into developer workstations mirrors the historical transition of mechanical power into distributed electric motors.
---
`27:01` Deconstructing Reliability: Determinism vs. Robust Intelligence
Martin asks for clarity on what reliability actually signifies when dealing with fundamentally stochastic foundation models—whether it means uptime availability, or getting the exact same answer each time a function is called. Diogo breaks the concept down into three distinct layers: uptime/SLAs, determinism, and robustness. Basic uptime is merely standard infrastructure engineering, while strict determinism—returning identical bit-for-bit outputs—is helpful for local unit testing but breaks down in real production environments. If a developer injects a unique session ID (UUID) or dynamic timestamp into a prompt, the text is technically non-deterministic, yet the software still requires identical functional behavior.
To Diogo, the critical frontier is what he terms "robustness" or consistent intelligence. The model does not need to execute the exact same token sequence on every run, but it must exhibit the same caliber of common-sense human reasoning every single time. If an anomalous input occurs, its reasoning should remain predictable enough that a human developer can reliably write software around it. He views the ultimate achievement for Jev as reaching a threshold where software engineers can program complex probabilistic logic directly against the system without having to hand-craft few-shot example queries to guide it.
> “And actually, to me, the highest honor of reliability will be to get to the point when people can program against Jev without making example queries.” — Diogo Almeida
- **Uptime vs. Determinism vs. Robustness:** Diogo distinguishes operational uptime from rigid input-output determinism and semantic robustness, highlighting that real systems require stability in reasoning rather than static text outputs.
- **The UUID problem:** Demonstrates why strict determinism is insufficient: changing incidental dynamic variables like UUIDs alters model generation, yet the programmatic intent must remain completely intact.
- **Zero-shot programmability:** The ultimate reliability target is allowing engineers to write deterministic control flow around probabilistic primitives without resorting to trial-and-error prompt engineering.
---
`28:38` Coding Agents, Architecture, and Pragmatic Trade-offs
Martin raises a structural question about the interplay between coding agents and primitives like Jev: if developers have access to a reliable, generalized reasoning primitive that makes writing software fundamentally easier, does the standalone value of coding agents diminish? Alternatively, will coding agents simply invoke Jev to write higher-level software on behalf of users?
Diogo analyzes the trade-off by separating software construction into syntax, semantics, and architecture. While coding agents excel at managing syntax and boilerplates, they remain clumsy with semantics and thoroughly inadequate when handling system architecture. In Diogo’s view, software architecture represents the core of human creative engineering. While coding agents will eventually incorporate primitives like Jev once they enter the models' training distributions, relying on an agent today yields roughly 50th-percentile architectural decisions. For startups and teams prioritizing raw speed, choosing a 50th-percentile architecture over a thoughtful 60th-percentile human design is an acceptable dial to turn, but human architectural intent remains indispensable.
> “So like to me, architecture is like the most human creative part of software.” — Diogo Almeida
- **Syntax versus Architecture:** Coding agents excel at syntactical mechanics but perform poorly at high-level system architecture and deep semantic reasoning.
- **Distribution lag:** Jev is sufficiently novel that contemporary coding agents have not yet trained on its user patterns or idioms, placing it outside their current training distribution.
- **The velocity trade-off:** Opting for autonomous coding agents is a conscious trade-off between architectural quality (accepting median 50th-percentile structures) and raw development velocity.
`30:00` From "SaaSpocalypse" to "Sassapalooza": Why Incumbent SaaS Wins
The conversation turns to market psychology and the shifting narrative around SaaS valuations. When AI coding agents first emerged, Wall Street panicking triggered what commentators called the "SaaSpocalypse," crashing valuations on the assumption that software was suddenly cheap and trivially easy to replicate. Yet when TypeSafe introduced Jev, established SaaS enterprises greeted it as a major breakthrough. Diogo Almeida explains why the replicate-everything thesis fell apart: while writing software may be getting cheaper, replicating mature software products is not easy because the real complexity lives beneath the hood. Rather than being destroyed by AI, boring, workflow-rich enterprise SaaS companies sit in the best position of all.
```mermaid
flowchart LR
accTitle: SaaSpocalypse vs Sassapalooza Dynamics
accDescr: Diagram contrasting why naive agent assumptions hurt SaaS valuations while Jev-style primitives enhance incumbent value.
subgraph Fear["The SaaSpocalypse Myth"]
A["Coding Agents"] -->|"Write code faster"| B["Assumption: Software is cheap & trivially cloned"]
B --> C["Market Panic / SaaS Valuation Drop"]
end
subgraph Reality["The Sassapalooza Reality"]
D["Incumbents with Deep Workflows & Capital"] -->|"Add Jev Reasoning Primitives"| E["True Process Automation"]
E --> F["Inverse SaaSpocalypse: Massive Capability Boost"]
end
```
Diogo emphasizes that incumbent SaaS players already possess deep domain knowledge of customer workflows and have absorbed the massive upfront CapEx needed to acquire and support millions of users. Instead of simply slapping a conversational chatbot over an existing interface, embedding actual intelligence inside their business logic will create what Diogo calls an "inverse SaaSpocalypse." Ben Horowitz jokes that they need a catchier term for the boom, coining "Sassapalooza."
As Ben points out, acquiring the customer is the lion's share of software capital investment; if those products suddenly leap forward in utility, incumbent moats expand dramatically. Diogo envisions the death of multi-choice input forms, noting that forms have always been clumsy stopgaps designed to turn natural human language into deterministic fields—a concept Ben compares to 1980s Fourth Generation Programming Languages (4GL). Diogo recalls seeing an experimental voice-controlled interface powered by Jev that dynamically decides on the fly whether an utterance is an operating system command or text to insert, capturing the classic computing ideal of DWIM ("do what I mean").
- “Maybe the markets don't agree, but I think SaaS is providing the same value it used to.” — Diogo Almeida
- “I think that SaaS will be one of the largest winners of the whole AI game.” — Diogo Almeida
- “I'm not going to forecast anything about the financial markets, but I think as far as capabilities games goes, it's going to be like an inverse SaaSpocalypse, and I am so jazzed about it.” — Diogo Almeida
- “Well, the SaaS applications are going to all of a sudden get dramatically more useful.” — Ben Horowitz
---
`33:30` Coding Agents vs. Making Software Actually Better
The group confronts a core illusion of the current AI boom: coding agents make writing software faster, but they do not make the resulting software any better. Martin Casado points out that the typical pull request at Google is only about ten lines of code, usually representing a hyper-specific learning or tweak derived from customer feedback. Automating the typing of those ten lines optimizes an incremental step, but it delivers zero novel capabilities to the end product. In fact, cutting human review out of the loop often results in buggier, more bloated, and more insecure applications.
True progress happens when software gains an entirely new primitive—marrying natural language understanding and probabilistic reasoning directly to a state machine. Diogo remarks that if the software industry recognizes Jev as adding an intelligent, decision-making "little brain" into traditional deterministic type logic, it would be the ultimate achievement for TypeSafe. While there are still unanswered questions about how deeply probabilistic logic can handle fundamental systems guarantees like state consistency and durability, automating easier software layers first opens the door to a brand-new era of software engineering.
- “Before Jev, it didn't even occur to me that it doesn't matter how much AI coding agents you use, the software actually isn't getting better.” — Martin Casado
- “I've been at Google. We actually did this study, so it's like 10 lines. So you're automating 10 lines.” — Martin Casado
- “I actually feel like it's almost too grand of a vision to expand beyond the three logic gates that we have into, like, you know... one that's like a little brain in there—like that would be the greatest compliment to, like, the TypeSafe legacy.” — Diogo Almeida
- “Automate the easy work before the hard work is always my philosophy.” — Diogo Almeida
---
`36:10` Probabilistic Systems and Building for the Deep "Guts"
Martin notes that probabilistic programming has a long history that largely stalled out in the 1970s. Diogo, while acknowledging his co-founder Eric's background in biological modeling, pushes back hard against biologically inspired computing dogmas. He argues that nature-inspired metaphors often function purely as romantic narratives to keep researchers working on a problem for decades until disciplined engineers discard the mythology and make it practical, just as occurred with neural nets and deep residual networks (ResNets).
Looking at the broader architecture of computing, Diogo predicts that hardcore systems engineers will eventually use miniature, high-speed, cost-effective models for low-level systems trade-offs—such as optimistic network routing or approximate heuristics deep inside infrastructural stacks. Martin observes that whenever a genuine new primitive arrives, the industry is forced to rebuild foundational systems from scratch, much like past architectural shifts from mainframes to client-server and the internet, or the modern imperative to re-architect infrastructure for cybersecurity.
```mermaid
flowchart TD
accTitle: Layering AI Calls in Software Architectures
accDescr: Visualizing the migration of AI invocations from the surface layer down into systems guts.
subgraph Guts["Deep Guts (Long-Term Reality)"]
G1["State & Database Reasoning"]
G2["Optimistic Packet Routing & Systems Heuristics"]
G3["'Many Nines' of Autonomous Machine-to-Machine Invocations"]
end
Surface -->|"Evolution towards massive scale"| Guts
```
Asked whether he views Jev primarily as an application, SaaS, analytics, or systems foundation, Diogo draws an analogy to the lower layers of networking protocols like TCP and UDP. Working backward from an AI-driven economic transformation, he calculates that the overwhelming majority of AI execution calls will not be surface-level text generation aimed at human eyes with stylistic polish. Instead, "many nines" of AI queries will run silently, machine-to-machine, deep inside software engines, making rapid programmatic decisions where human natural language and rigid system code previously failed to connect.
- “I'm not a fan of, like, biologically inspired stuff at all. It's never worked.” — Diogo Almeida
- “No, seriously, we have a new primitive. It's kind of a new way of thinking about doing software.” — Martin Casado
- “And I ask myself the question: what percentage of the calls to AI... are like for human consumption where you need, like, style? And it's going to be like many nines [in the guts].” — Diogo Almeida
- “If you don't aim for the guts, it's going to take you a while to get there.” — Diogo Almeida
`40:00` Escaping the Five Stages of Grief: From While Loops to State Machines
The conversation turns to the frustrating history of trying to force large language models into structured software workflows. In the early days of building on LLMs, developers would paste strict schemas into their prompts—specifying exact JSON formats and output constraints—only for the model to repeatedly ignore the rules. Out of sheer exasperation, developers would give up and route the unstructured text output either to an end user via a chat interface or back into another model. As the hosts observe, the pervasive "agent while loop" was born directly out of that failure: when probabilistic output cannot be trusted by traditional program logic, the only fallback is to pipe natural language back into another loop until a human or an LLM catches it.
Martin Casado likens this evolution to the classic five stages of grief. Developers started in denial, tried desperately to make fragile prompt hacks work, grew angry when schemas broke, and finally surrendered to acceptance by resigning themselves to chat interfaces and while loops. For years, software engineering and AI felt like ships passing in the night. TypeSafe’s approach with Jev marks a critical pivot: rather than papering over model drift with endless iterative re-prompting, it genuinely maps probabilistic reasoning directly into a state machine that software can deterministically execute. As Martin puts it: “I think this is the first time I have seen when someone’s like, actually, you can take an LLM, you can take AI and you can actually map it to like, like a state machine and you can do that productively.”
```mermaid
flowchart TD
accTitle: Evolution of LLM Application Architecture
accDescr: Comparison between fragile prompt engineering fallbacks and state machine integration.
subgraph Fragile["The Brittle Loop (Five Stages of Grief)"]
A["Developer Prompt + JSON Schema"] -->|"Model ignores schema"| B["Raw Natural Language Output"]
B -->|"To hell with it"| C{"Fallback Strategy"}
C -->|"Chat interface"| D["Human in the Loop"]
C -->|"Iterative re-prompting"| E["Agent While Loop"]
E -->|"Loop back"| A
end
subgraph StateMachine["The Deterministic Mapping (Jev)"]
F["Probabilistic Model Reasoning"] -->|"Mapped into"| G["Typed State Machine"]
G -->|"Reliable transitions"| H["Predictable Software Execution"]
end
```
- **The prompt schema breakdown:** Early AI implementations repeatedly failed because models simply refused to strictly adhere to requested output schemas like JSON, forcing developers to abandon programmatic handling.
- **The while loop crutch:** The popular agent "while loop" architecture exists largely because natural language output cannot be parsed cleanly by traditional software, necessitating an ongoing feedback loop of LLMs inspecting LLMs.
- **The five stages of grief:** Developer adoption shifted from denial (trying to force strict outputs), to anger at model inconsistencies, to passive acceptance (dumping text into human-facing chats or autonomous loops).
---
`41:12` The "Anti-Frustration Machine" and the "Do What I Mean" Utopia
Diogo Almeida responds with deliberate humility, stressing that he refuses to over-promise and under-deliver in an industry already awash in inflated claims. He acknowledges that while the technology may not yet solve every wildly hyped use case, his team is fiercely committed to engineering genuine reliability under the hood. TypeSafe intentionally withheld releasing their work far longer than typical AI startups because they refused to ship half-baked developer primitives. Diogo observes that the broader online discourse on platforms like Twitter may never fully appreciate the deep architectural engineering required to make models reliable, but end users will immediately recognize the difference in feel: software built on trust functions as an "anti-frustration machine."
Ultimately, Diogo anchors his engineering philosophy in the classic computing ethos of DWIM ("Do What I Mean"). He envisions an AI utopia defined by seamless real-world friction reduction, where computing systems interlock like well-machined gears rather than breaking across unpredictable interfaces. If an LLM possesses remarkable natural intelligence, software should harness that intelligence to infer human intent and execute it cleanly without forcing the user to micro-manage every prompt or edge case. As Diogo emphasizes: “Imagine if all technology just did what you mean. That is like, that's not sci-fi. Look how smart AI is, right?” Ben Horowitz and Martin Casado wholeheartedly agree that making computers reliably "do what I mean" is the definitive ambition to strive for, concluding the episode on that vision before closing out with standard fund disclaimers.
- **Holding back for reliability:** Diogo notes that TypeSafe could have launched significantly earlier, but delayed release to prioritize underlying stability over quick hype.
- **Twitter discourse vs. reality:** Almeida argues that social media debates often miss the hard infrastructure work required for reliability, but developers will feel the result when tools just work without frustrating errors.
- **The "Do What I Mean" standard:** Diogo's long-term product vision centers on software functioning like interlocking gears, translating high-level human intent into smooth, dependable computational action.
## Notable quotes
> `30:00` I think that SaaS will be one of the largest winners of the whole AI game. — Diogo Almeida
> `33:30` it doesn't matter how much AI coding agents you use, the software actually isn't getting better. — Martin Casado
> `33:30` Automate the easy work before the hard work is always my philosophy. — Diogo Almeida
> `36:10` I'm not a fan of, like, biologically inspired stuff at all. It's never worked. — Diogo Almeida
## Mentioned
Ben Horowitz, Martin Casado, Diogo Almeida, TypeSafe AI, Jev, Claude Code, Codex, Cursor, Garry Tan, Kaggle, NeurIPS, Isabelle Guyon, Jeremy Howard, Google Brain, OpenAI, David George, Muse, The New York Times, ChatGPT, Ilya Sutskever, Larry Wall, Google, Eric
## Video description
a16z’s Ben Horowitz and Martin Casado sit down with TypeSafe AI founder Diogo Almeida to ask a simple question: AI has become remarkably capable, so where is all the automation?
Diogo argues that coding agents may help us write software faster, but the software they produce still largely works the way software always has. TypeSafe is taking a different approach with Jev: putting intelligence inside software itself, so developers can build programs that reason about intent and make probabilistic decisions rather than simply generate text for a human to interpret.
They discuss why reliability is the key to making AI genuinely programmable, how this could open a new era of probabilistic software, and why established SaaS companies may be particularly well positioned to benefit. Ultimately, Diogo’s goal is straightforward: technology that can reliably “do what I mean.”
TypeSafe AI founder Diogo Almeida and a16z partners Ben Horowitz and Martin Casado argue that code-generating assistants only reproduce decade-old software patterns faster rather than making systems genuinely better. They contend that meaningful automation requires embedding probabilistic reasoning directly into software as reliable runtime primitives mapped to state machines.
Code Generation Versus Runtime Intelligence Primitives (0:00)
While coding assistants like Claude Code, Codex, and Cursor speed up the creation of conventional imperative code, Diogo Almeida argues that the resulting software retains identical expressive limits and risks accumulating bloat. Casado notes that because typical corporate code changes—such as standard pull requests at Google—average only about ten lines derived from customer feedback, merely automating code entry fails to deliver new functional capabilities. Instead of treating models as external code generators, TypeSafe's model, Jev, operates as an in-program classifier and runtime primitive that accepts natural language intent alongside program state to yield discrete, probabilistic decisions with explicit confidence levels.
The Disconnect Between Benchmarks and Everyday Automation (20:00)
Almeida questions why basic administrative friction and routine operations remain unautomated despite frontier models displaying high benchmark scores. He asserts that while current models are not clearly on a trajectory toward recursive self-improvement, foundation models have long held the baseline intelligence necessary to automate routine economic tasks. In his view, post-2021 Reinforcement Learning from Human Feedback (RLHF) shifted industry incentives toward pleasing human judges with conversational polish rather than achieving end-to-end task execution.
Defining Production Reliability Beyond Uptime and Strict Determinism (27:01)
To safely execute in the background without paging engineers, Almeida separates software reliability into three tiers: infrastructure uptime, bit-for-bit determinism, and semantic robustness. While strict determinism breaks down in production whenever dynamic variables such as session UUIDs or timestamps are introduced, robustness requires that the model deliver consistent human-level common sense across every run. Almeida aims for an engineering threshold where developers can program deterministic control flow against probabilistic models without hand-crafting few-shot example queries.
Replacing Fragile Agent Loops with Deterministic State Machines (40:00)
Casado and Almeida describe how early efforts to force large language models into structured JSON schemas frequently failed when models ignored formatting rules. In response, developers created brittle 'agent while loops' that repeatedly pipe unstructured natural language back into subsequent models or human-facing chats. TypeSafe replaces this pattern by mapping probabilistic model outputs directly into typed state machines, enabling programs to execute transitions deterministically rather than relying on endless re-prompting.
SaaS Moats and the Migration of AI Invocations (30:00)
Pushing back against market fears that coding agents will render enterprise SaaS obsolete, Almeida and Horowitz argue that established software providers hold major advantages. Incumbent vendors have already absorbed the capital expenditure needed to acquire customers and map domain-specific workflows. Re-architecting these platforms around intelligent primitives will boost their utility by replacing rigid multi-choice input forms with dynamic intent handling. Almeida forecasts that 'many nines' of future AI queries will operate machine-to-machine deep inside infrastructural systems—such as network routing and database heuristics—rather than generating surface-level text for human reading.
The discussion concludes on computing's long-standing ideal of 'Do What I Mean' (DWIM), where software reliably deduces user intent without micromanagement. However, Almeida and Casado acknowledge that open technical questions remain regarding how deeply probabilistic reasoning can support fundamental systems guarantees like state consistency and data durability.
## Background
该内容由 a16z 的 Ben Horowitz、Martin Casado 与 TypeSafe AI 创始人 Diogo Almeida 于 2026 年 9 月 28 日在播客平台发布。节目围绕“AI 已经足够强大，但真正的自动化为何迟迟没有到来”这一核心议题展开，深入探讨了 TypeSafe 旗下产品 Jev 如何通过将智能原语与有限状态机直接嵌入软件内部，推动软件工程迈向原生概率编程的新阶段。
## TL;DR
Diogo Almeida 指出，现有的 AI 编程 Agent 只是加快了传统死板代码的编写速度，并未从根本上提升软件质量或实现业务端到端的真正自动化。TypeSafe 的策略是打破单一巨型模型神话，将分类与概率决策作为基础原语直接嵌入代码内部与状态机中，让软件具备理解人类真实意图（Do What I Mean）的能力。这种模式不仅让深陷“悲伤五阶段”的开发者摆脱脆弱的 Prompt 重试循环，也将重塑软件基础设施的底层架构，使老牌 SaaS 企业成为真正的受惠者。
## Atmosphere & style
对话氛围既硬核务实又充满反思与幽默感，三位顶级投资人与系统工程师之间碰撞出极高的认知密度。Diogo 以其数学竞赛与前沿大模型研发的跨界背景，展现出毫不妥协的工程实用主义，从自嘲“造生产级系统而非造神”到直白拷问行业泡沫，语调犀利且富有感染力。整场访谈像是一次系统架构师之间的深夜复盘，既有戳破 Demo 幻象的冷峻，又洋溢着为现代软件打造全新计算原语的工程狂热与浪漫情怀。
## Bulletin
- `00:00` 现有 AI 编程代理（如 Cursor、Codex）只是加速生成传统确定性代码，软件本身的表达力和架构并未改变；真正的机遇在于将智能作为新原语直接嵌入软件内部。
- `05:00` TypeSafe 推出首个模型产品 Jev，将概率推理与有限状态机严格绑定，输出带有置信度水平的操作决策，将模型从外部生成器转变为程序内部的概率决策“微型大脑”。
- `30:00` 针对“SaaS 末日论”，访谈指出老牌 SaaS 拥有深厚的客户网络与深埋底层的复杂业务逻辑，结合可编程智能原语反而将迎来能力暴增的“SaaS 狂欢”。
- `38:30` 大模型与工程落地脱节的根源在于当前 Agent 架构过度依赖 while 循环重试与人工兜底，未来超过 99.999% 的 AI 调用将发生在系统底层的不可见管道中。
## Key takeaways
- `20:00` 现实世界自动化面临严重割裂：AI 宣称解决了前沿数学题和高难度基准测试，但在实际企业生产中连快餐店得来速点餐或客户服务都未能真正实现端到端自动化。
- `12:35` TypeSafe 提出核心口号“We build prod, not God”（构建生产级系统，而非造神），明确拒绝盲目崇拜单一巨型模型（mono-model）和自我递归改进（RSI）的宏大叙事。
- `33:00` 即时代码生成（JIT software）并未提升软件质量，大公司平均每个 PR 仅约 10 行代码修补，代码生成工具仅优化了微小环节，甚至可能引入缺乏审查的漏洞。
- `05:00` Jev 的本质是一个高度实用主义的强分类器，直接接受系统当前状态（state）与自然语言意图作为输入，规避了神经网络最易出错的外推浮点数计算。
- `10:00` 创始人 Diogo Almeida 从数学竞赛和 Kaggle 算法冠军走向系统级工程破局，曾因 RLHF“冥想前吃袜子”测试确信模型泛化性，后因其未能通向真实 AGI 而经历幻灭并转向极致工程实用主义。
- `15:23` 摒弃花哨的 Demo 幻象，真正的生产级工程系统必须在后台静默运行，并具备严格的统计学保障（statistical guarantees）与可组合性，杜绝越权或基础设施崩溃风险。
- `22:15` 以“杰文斯悖论”（Jevons Paradox）命名的 Jev 旨在大幅降低可靠自动化的成本，当自动化原本繁琐的任务变得极其便宜时，不仅不会消灭就业，反而会催生出全新的工种与软件形态。
- `24:45` AI 系统追求的最高可靠性并非仅是在线率（SLA）或输出严格一致的确定性，而是面对不同输入情境时始终保持同等水准的常识与智能鲁棒性。
- `27:30` 现有代码代理在处理代码语法时表现优异，但在理解语义方面较弱，在系统架构设计上更是平庸（仅达 50 百分位水平），架构设计依然是人类开发者最核心的创造力体现。
- `30:00` 多选题、表单控件等传统人机交互界面很快会过时，其本质是为人机沟通妥协的产物；新原语可直接理解自然意图，实现 80 年代第四代语言就追求的“按我所想去执行”（Do What I Mean）。
- `40:00` 传统 Agent 集成经历了类似“悲伤五阶段”的妥协，因无法约束自然语言而被迫在 while 循环中重复重试或引入人工兜底；TypeSafe 则将大模型严格映射进状态机中确保确定性。
- `38:30` 系统终局预测：未来绝大多数 AI 调用绝不是为了输出面向人类的自然语言排版或对话，而是深入系统底层“内脏”（guts）充当无形的概率决策管道。
## Detailed walkthrough
### `00:00` 真正的自动化到底去哪儿了？
访谈一开场便直击核心痛点：如今的人工智能展现出难以置信的聪明才智，但现实中除了聊天机器人和编码助手，整个产业的真实自动化水平却令人失望。Diogo Almeida 直截了当地指出，无论大家使用多少 AI 编程代理，编写软件的速度或许变快了，但软件本身的质量并没有变好，甚至在某种程度上变得更差。许多大模型实验室长期以来不断许诺愿景——例如 OpenAI 早在 2020 年就试图彻底自动化客户服务——但真正落地的端到端工业级自动化至今寥寥无几。面对行业对人工通用智能（AGI）乃至递归自我提升（RSI, Recursive Self-Improvement）的狂热崇拜，Diogo 提出了截然不同的务实哲学：“我们造的是生产环境可用的系统，而不是上帝”（"We build prod, not God."）。他明确表示，出于许多细微而严谨的技术原因，当前的 AI 发展路径并不在通往 RSI 的轨道上。
```mermaid
flowchart LR
accTitle: 传统编程代理模式与智能原生软件模式的对比
accDescr: 展示现有代码生成工具与以Jev为代表的智能原生软件在构建逻辑与最终形态上的本质区别。
subgraph CurrentApproach ["主流模式：代码生成代理"]
direction TB
A["人类 / 自然语言需求"] --> B["AI 编程代理 (Cursor/Codex)"]
B --> C["传统确定性代码 (10年未变)"]
C --> D["死板的执行逻辑"]
end
subgraph JevApproach ["TypeSafe 模式：智能软件原生"]
direction TB
E["开发者编写逻辑"] --> F["嵌入 Jev 智能原语"]
F --> G["意图理解与状态机转移"]
G --> H["动态自适应的自动化软件"]
end
```
在所谓的“SaaS 末日论”（Saspocalypse）叙事中，主流观点普遍认为 AI 将替代人类编写软件，甚至颠覆现有的所有 SaaS 工具。然而 Ben Horowitz、Martin Casado 与 Diogo 一致认为，更大的机遇并不在于让 AI 替代程序员去生成那些死板的代码，而在于**将智能直接嵌入软件内部**。TypeSafe 及其推出的首个模型产品 Jev，正是在这一背景下诞生。当被问及电梯游说（elevator pitch）时，Diogo Almeida 强调，与其给出一个冗长的公关套话，不如直接抛出那个困扰所有人的根本问题：“他妈的自动化到底去哪儿了？”（“Where the fuck is all the automation?”）。AI 目前就像一块未经雕琢的璞玉，虽有极高智力，却无法稳定承担真正的工业级工作；TypeSafe 的目标就是让 AI 不仅仅为处于流程中间的“人类操作员”（human in the loop）服务，而是作为底层基础原语，直接驱动软件完成真正的端到端自动化。
### `03:00` 及时代码生成 vs. 扩展软件本体的表达力
随着 Jev 在开发者社区迅速走红，Ben Horowitz 观察到身边的每一位核心工程师都在为之振奋，纷纷向他打电话称赞该系统速度极快、体验出色。但一个随之而来的技术疑问是：在已经拥有 Claude Code、OpenAI Codex 和 Cursor 等成熟工具的当下，Jev 的本质区别究竟在哪里？Diogo 引用了 Gary Tan 对现代编码代理的精辟定义——“即时软件”（just-in-time software）。这类工具虽然允许人类用自然语言即时生成代码，但产出的代码在表达力与底层原理上与过去没有任何不同，软件依旧是由确定性逻辑构成的脆性系统。
Diogo 解释称，自己的追求根本不是去自动化软件工程这一职业本身，而是去彻底拓展软件自身的能力边界：
- 传统的编程本质是“超高度具体化有价值的逻辑，然后进行无限复制”（hyper-specifying valuable things and then infinitely replicating them）。
- 现有的编程工具无法直接处理模糊的、人类层面的“意图”（intent）。
- 他希望通过引入新的语言与计算原语，让那些本该被自动化的复杂模糊事务，真正变得能够被软件原生处理。
正如 Ben Horowitz 所总结的那样，行业的普遍误区是将 AI 当作一个水平稍逊或速度更快的“程序员替代品”，而 TypeSafe 正在做的是超级赋能现有的人类软件工程师，使他们能够构建出维度完全不同、具备自主理解力的下一代智能软件。
### `05:00` 代码内部的全新原语与概率型软件
Martin Casado 深入剖析了这一技术本质的微妙之处：传统的代码生成工具即便写得再好，产出的依然是十年前形态的传统代码；但 Jev 提供的是一种前所未有的“代码内原语”（new primitive in code）。开发者不再仅仅是用自然语言换取静态逻辑，而是直接在代码中调用一个具备概率推理能力的智能层。这一原语接收自然语言与当前系统状态作为输入，内部结合有限状态机（state machine），并输出带有置信度水平（confidence levels）的操作决策。
```mermaid
flowchart TD
accTitle: Jev 智能决策流架构
accDescr: 描述程序状态与自然语言意图输入到 Jev 原语，并输出带置信度的状态决策过程。
subgraph Runtime ["软件运行内部"]
S["当前程序状态 (State)"]
I["自然语言意图 (Intent)"]
end
subgraph Primitive ["Jev 原语 (智能层)"]
M["概率分类与状态机评估"]
C{"置信度计算 (Confidence)"}
end
subgraph Actions ["程序执行路径"]
A1["高置信度操作 (Direct Action)"]
A2["降级 / 人机协同逻辑 (Fallback)"]
end
S --> M
I --> M
M --> C
C -->|满足阈值| A1
C -->|不确定| A2
```
Diogo 坦言，这确实要求程序员转变传统的心智模型。针对业内有人质疑“Jev 是否只是一个分类器”的声音，Diogo 毫不避讳地直接承认：“Jev 绝对就是一个分类器。分类器简直太酷了，分类器被设计出来就是为了真正派上用场的。”（“Jev is absolutely a classifier. Like classifiers are sick. Classifiers were designed to be useful.”）。他指出，分类器这种接口形式来自那些真正解决实际工程问题的实用主义机器学习专家。在过去，企业需要雇佣一支顶级机器学习工程（MLE）团队耗费数月去采集数据集、调优并监控一个极其狭窄的分类模型；而如今通过 Jev，开发者在几毫秒内就能通过即时编程获得超越 2019 年顶级 MLE 团队产出的精准分类与决策效果。
- **确定性与模糊性的平衡**：Jev 并不盲目追求全知全能，在产品设计之初就明确划定边界。例如系统不会直接输出外推浮点数（extrapolated floats），因为这恰恰是当前神经网络最不擅长且极易出错的地方。
- **软件智能的连续谱系**：关于未来的编程界面究竟是“自然语言输入/输出”，还是“传统命令式代码”，抑或是两者的滑动条，Diogo 认为这必然是一根动态滑动的频谱。
- **北极星指标**：在系统架构上，Diogo 目前将“单位美元智能”（intelligence per dollar）作为团队研发的核心北极星指标，尽管在短期内“单位时间智能”（intelligence per second）同样关键。
- **架构心智的映射**：Jev 的 API 设计极其严苛，其输入参数被直接命名为 `state`（状态）。Diogo Almeida 强调：“这就是为了表明，它原本就是为存活在程序内部而生的”（“It's meant to be the inside of programs.”），在当前硬件延迟下它类似于一个超高速的专用数据库，但其终极形态是成为现代编程语言的标准库（standard library）。
### `08:00` Diogo 的跨界背景：数学竞赛与炼金术
面对 Diogo 展现出的横跨顶级 AI 研究员、底层系统工程师与资深程序员三种迥异领域的独特视角，Martin Casado 感到十分惊奇，并追问究竟是怎样的成长经历孕育出了这种独特的认知融合。通常情况下，大模型理论研究人员往往沉迷于将 AI 塑造成一个有独立意识的“神性生命体”，而系统底层工程师则往往鄙视 AI 带来的不确定性。Diogo 却反其道而行之，坚定地将最前沿的模型能力降维转化为确定性世界里的精准生产力工具。
Diogo 幽默地开启了自嘲，回顾起自己略显另类的数学竞赛经历。他曾经是一名屡获殊荣的数学竞赛选手（mathlete），并开玩笑称自己当年的数学水平已经高到了“足以靠数学吸引女孩子”的荒唐地步。这一俏皮的调侃立刻引得 Ben Horowitz 和 Martin Casado 大笑，追问那种级别的数学天赋到底能吸引到什么样的女孩，Diogo 则大笑着劝告大家“千万别学我”，在轻松风趣的氛围中，拉开了他由纯粹数学思维走向计算机系统与 AI 理论融合之路的序幕。
### `10:00` 从数学竞赛、Kaggle 到 OpenAI：以工程系统思维破局 AI
Diogo Almeida 回忆起自己的早年经历，坦言自己曾是一名数学竞赛选手（mathlete），但他其实从没真正喜欢过纯数学，也没付出全力，只是“小池塘里的大鱼”。对他而言，竞赛数学是一条被预设好的道路，充满了为了赢而赢的功利感，令人厌烦。然而计算机科学彻底改变了他的看法——它本质上就像数学，但既酷炫、实用又充满乐趣。正因如此，Diogo 始终将自己定位为一名纯粹的“计算机科学家”，而不是传统意义上的 AI 研究员；直到今天，他依然热衷于用算法面试来精准考察技术人才。
Diogo 真正踏入 AI 领域的契机颇具传奇色彩：他赢得了一场 Kaggle 算法竞赛，但获胜靠的并不是多么高深的数学理论，而是纯粹靠工程系统手段将其自动化——用极度暴力的嵌套循环（nested loops）解决了一个底层系统问题。这场比赛的组织者正是支持向量机（SVM）的奠基人之一 Isabelle Guyon。Isabelle 敏锐地察觉到 Diogo 是一个与传统学术研究圈格格不入的异类，于是便将他招至麾下悉心指导，引荐他结识了众多顶尖 AI 学者，甚至“强迫”他在 NeurIPS 大会上发表演讲。Diogo 笑称，尽管在 NeurIPS 演讲通常被视为至高荣誉，但他当时内心其实很抗拒，因为他只想扎在底层系统里写代码。
自那之后，Diogo 的职业轨迹被彻底推向了机器学习前沿：他先是与 fast.ai 创始人 Jeremy Howard 一起创立初创公司，随后加入 Google Brain 工作了一段时间；在经历了一段枯燥且无所事事的短暂“退休”后，他重新意识到 AI 依然非常有趣，最终决定加入 OpenAI 并取得了巨大成功。Diogo 总结道：“It's basically like math, but cool and useful and fun and interesting.”（它本质上就像数学，但既酷炫、实用、好玩又有趣。）
- 计算机科学与数学：Diogo 认为纯数学竞赛容易沦为功利性的胜负之争，而计算机科学兼具严密逻辑与解决实际工程问题的能力。
- 职业履历线：Kaggle 冠军（靠系统级嵌套循环自动化） $\rightarrow$ 师从 Isabelle Guyon 并在 NeurIPS 演讲 $\rightarrow$ 与 Jeremy Howard 联合创业 $\rightarrow$ Google Brain $\rightarrow$ 退休调整 $\rightarrow$ OpenAI $\rightarrow$ 创立 TypeSafe AI。
```mermaid
flowchart LR
accTitle: Diogo Almeida Career Evolution
accDescr: Diagram tracing Diogo Almeida's transition from competitive mathematics to OpenAI and TypeSafe.
subgraph Early["早期探索"]
A["数学竞赛背景"] --> B["转入计算机科学"]
B --> C["暴力系统优化赢得 Kaggle"]
end
subgraph Research["科研与工业界实践"]
C --> D["Isabelle Guyon 引荐 / NeurIPS"]
D --> E["Jeremy Howard 创业公司"]
E --> F["Google Brain"]
end
subgraph Frontiers["前沿大模型与创业"]
F --> G["OpenAI 核心研发"]
G --> H["创立 TypeSafe (Jev)"]
end
```
---
### `12:35` “We Build Prod, Not God”：打破单一巨型模型的叙事与自动化困境
Ben Horowitz 指出，在当今充满严肃或神秘主义色彩的 AI 行业中，Diogo 与 TypeSafe AI 的气质与众不同。顶级实验室的领导者往往言必称 AGI 或试图掩饰技术探索的纯粹乐趣，而 TypeSafe 却提出了一句极具标志性的口号：“We build prod, not God”（我们构建生产级软件，而非造神）。Ben 称赞道：“And my favorite thing that you guys say is we build prod, not God.”（而我最喜欢你们的一句话就是：我们做的是生产环境的软件，而不是上帝。）他们坚信技术将创造一个更美好的世界，带来更多且更好的工作岗位，让所有人都能享受技术红利。
Diogo 对此深表赞同，并指出业内广泛蔓延的悲观与末日叙事，很大程度上源于所有人都在盲目迷信单一巨型模型（mono-model Kool-Aid）——即幻想用“一个终极超级大脑统治所有人”。但这种叙事与现实严重脱节：在现实世界中，大量极其基础、机械且令人痛苦的日常任务根本没有被自动化。在明明存在巨大经济回报、AI 又被宣传得如此聪明的背景下，现实世界却依然缺乏真正的自动化，这种断层让 Diogo 感到极其荒谬与痛心。
Diogo 感叹道：“And part of the pain is on the where the fuck is all the automation.”（最让我痛苦的事情之一就是：他妈的所有的自动化到底都去哪儿了？）他认为，行业内目前存在着两极分化的景象：一边是陷入虚无、神话和末日焦虑中的冷酷 AI 叙事者，另一边则是正在享受 Jev（TypeSafe 平台）带来的高确定性、切实解决工程难题的活跃开发者。
- 行业文化对比：主流大模型实验室倾向于构建全知全能的超级智能（God），TypeSafe 则专注于开发者能够掌控、可投产的生产系统（Prod）。
- 自动化的现实脱节：AI 具备极强的纸面推理能力且商业激励巨大，但人类最基础的低效重复劳动依然未能被软件系统接管。
---
### `15:23` 摒弃 Demo 幻象：可组合性、背景运行与真正的工程安全
为了佐证“现实生活缺乏自动化”这一痛点，Ben Horowitz 分享了一个身边的趣事：当天早上 a16z 成长基金负责人 David George 兴奋地告诉他，自己终于用上了最新的 AI 工具；当 Ben 追问他用 AI 解决了什么重大难题时，David 的回答竟是：“我终于把《纽约时报》的订阅给取消掉了。”这一微小却折磨人的繁琐琐事，正是海量尚未被自动化的现实痛点的冰山一角。
Diogo 随即指出，如果行业要真正实现自动化的“北极星”目标，就绝不能重蹈当前 AI 开发的反模式（anti-patterns）覆辙——即把所有注意力过度集中在博眼球的边缘案例（outliers）和花哨的 Demo 上。Diogo 直言：“I think that if we were going to be really intellectually honest and we are really aiming for the North star of automation, we cannot fall into the same anti-patterns that AI has fallen into, which is really, um, focusing on outliers and demos, right?”（我认为如果我们保持求真务实，并真正以自动化为最高目标，我们就绝不能陷入 AI 已经掉入的那些反模式中——也就是过度聚焦于边缘案例和展示 Demo，对吧？）
在 Diogo 眼中，真正有价值的系统必须能够在后台静默、可靠地稳定运行，让工程师不必随时担心被报警电话（paging）叫醒。要让 AI 系统能够安全地调用底层计算资源与接口权限，系统就必须具备严格的统计学保障（statistical guarantees）与高度的可组合性（composability）。Martin Casado 也补充强调，这种“安全”并非学术界泛指的宏观伦理安全，而是工程架构层面的可靠与受控——确保模型在执行操作时不会意外搞垮基础设施或越权崩溃。
- Demo 导向 vs. 生产导向：Demo 往往展示大模型最惊艳的特例表现，而生产环境需要系统在 99.9% 的场景下不发生灾难性偏离。
- 工程安全的真正含义：赋予智能体（Agents）底层资源与系统访问权限的同时，提供确定性的行为边界和统计置信度保证，杜绝非预期系统风险。
---
### `17:41` RLHF 的惊艳与幻灭：从“冥想前吃袜子”到 AGI 的破灭
Martin Casado 提起早在 2017 年与 Diogo 交流时，Diogo 就曾提出过一套前瞻性观点。Diogo 笑着回忆道，自己当年的演讲主题正是《理论上的模块化 AI 与实践中的僵化系统》（AI Modular in Theory, Inflexible in Practice），其核心内核与今天的软件系统思考一脉相承。不过，他真正对大模型泛化能力产生质的认知转变，是在 2021 年第四季度 OpenAI 研发强化学习人类反馈（RLHF）的那段时期。
Diogo 坦言，RLHF 的泛化表现超出了所有人的预期。当时的学术论文并不像传统论文那样竭力证明自己的假设，而是遵循科学方法竭尽全力去证伪——去证明模型到底有没有“作弊”（如记忆训练集）。团队设计的最经典的测试 Prompt 是：“为什么在冥想前吃袜子很重要？”（Why is it important to eat socks before meditating?）团队事先严密核查过互联网上绝无此类奇谈怪论，但模型却能给出逻辑自洽、极其逼真的人性化回答。正是这个测试让整个核心团队确信：模型并没有作弊，它的泛化能力是真实的。
然而，随后的发布却让 Diogo 经历了巨大的心理幻灭。作为推动该模型发布的核心技术主力，他当时一度坚信这个模型有相当大的概率直接通向 AGI；但当系统上线并接受现实检验后，其天花板与局限性迅速暴露。Diogo 坦陈：“I really thought that the model had a decent chance of being AGI. And when it didn't, that was when my whole world came crashing down.”（我当时真的以为这个模型很有希望成为通用人工智能。但当它最终没有达到时，我整个人生信仰都崩塌了。）
Martin 追问 Diogo 曾经历的那段“狂热列车”时光，并指出早期 ChatGPT 与 GPT 时代的初衷主要是构建一个能够与人类对话的聊天机器人，而非直接给程序员使用的精准系统工具。Diogo 进一步解构了当时 OpenAI 的组织文化：早在 2020 年，OpenAI 内部对 AGI 的非正式定义甚至被戏谑地表述为“在每一个 if 语句里都塞进一个 Ilya Sutskever”。这种故意保持模糊的“大帐篷”（big tent）文化虽然让所有人都能聚在一起为宏大愿景奋斗，却也在一定程度上掩盖了技术走向严谨软件工程的真实路径与落地障碍。
- RLHF 的证伪实验：“冥想前吃袜子”的经典测试排除了模型从互联网数据中记忆抄袭的可能，证实了基于反馈的泛化生成能力。
- 泛化机制差异：RLHF 在对话对齐上表现出优秀的泛化能力，但基于可验证奖励的强化学习（RLVR）在许多任务中的泛化边界依然狭窄。
- 早期 AGI 的文化迷思：OpenAI 内部用“每个 if 语句里都有一个 Ilya”（Ilya in every if statement）来模糊化描绘 AGI，既凝聚了团队共识，也折射出早期阶段对智能系统确定性落地的认知空白。
### `20:00` 真实世界自动化的鸿沟与“金丝雀”之问
对话开始时，Diogo Almeida 坦言自己过去不认为、现在也依然不认为人类正处于所谓自我递归改进（RSI, Recursive Self-Improvement）的轨道上。但他坚信 OpenAI 最初对 AGI（通用人工智能）的定义——即自动化世界上绝大多数具有经济价值的工作——是极其可行的。因为世界上大量的工作本质上都是机械且重复的，要将这些工作外包出去，通常只需要能让普通人理解的简单指令，而大语言模型早在很久之前就具备了理解此类指令的智能水平。然而，让 Diogo 深感不解与如鲠在喉的是，这种能力为何迟迟无法真正落地到实际业务中。
Diogo 直言，自引入基于人类反馈的强化学习（RLHF）以来，整个行业就陷入了一种“巨大吹嘘却交付不足（gigantic overpromise under deliver）”的严重分化之中。在 GPT-3 时代，模型的输出还相对校准合理；但后来因为完全依赖人类作为裁判去评估模型的好坏，行业便开始全力去讨好和优化这个“裁判”，反而忽视了真正核心的“自动化”本身。这就导致模型在评分表上看起来惊艳绝伦，在生产力上却止步不前。Martin Casado 随即提炼指出，评估 AI 的真正标尺应当是“它在多大程度上能够自动化实际的生产任务”。Diogo 深表认同，并将其视作检验科幻狂想的试金石：
> “Are you really telling me that math is solved, or even two years ago, GPQA, that Google proof question answering is solved, but we still can't handle a drive-through, right?” —— Diogo Almeida
这种强烈的割裂感令人难以自圆其说：AI 宣称解决了高难度前沿数学题甚至 GPQA（防搜索问答基准），却连快餐店得来速（drive-through）点餐这样基本的现实交互都搞不定。OpenAI 早在 2020 年就试图彻底自动化客户服务，但时至今日，在企业内部除了代码编写取得了令人惊叹的成果之外，几乎没有其他业务实现了真正的自动化落地，大量内部探索项目最终均以失败告终。
---
### `22:15` 长尾分布、程序员的美德与自动化的投资回报
针对为什么现实任务难以落地，Martin Casado 提出了一个技术假说：现实世界的数据分布与纯数字世界完全不同，它具有重尾（heavy-tailed）特征，充斥着无数的例外与缺失数据；AI 之所以尚未能进入物理生产领域，正是因为没有针对这种复杂分布的数据进行充分训练，导致其能力只能被困在数学或代码这种低维流形（lower dimensional manifolds）之中。Martin 拿早年分析客服支持系统的经历作证：许多企业声称自己能自动处理 95% 的服务台求助，但深入数据就会发现，那几乎全都是密码重置；如果按问题的唯一性（uniqueness）来统计，自动化率瞬间跌落到 50% 左右。一旦面对真实人类与自然系统，无穷无尽的边缘情况就会浮出水面。
然而 Diogo 并不完全认同“纯粹是数据不足”的说法。他承认长尾客观存在，但认为自动化现实任务并不需要盲目追求覆盖所有的长尾特例，而是需要极致的务实精神。构建可靠的软件自古以来就是一种商业投资，正如 Perl 语言之父 Larry Wall 提出的程序员三大美德（懒惰、急躁与傲慢）所揭示的那样，程序员愿意花费 10 个小时去编写自动化程序，就是为了将原本 5 分钟的机械任务彻底干掉，以后再也不用重复。这种决策本质上完全取决于投入产出比（ROI）。
```mermaid
flowchart TD
accTitle: 现实业务自动化的经济学逻辑
accDescr: 展示从基础重复任务到利用可靠软件降低长尾成本，进而触发杰文斯悖论的逻辑流。
subgraph Problem["现实世界的业务困境"]
A["高频重复任务<br/>（如密码重置、标准化指令）"]
B["真实人类与环境的<br/>长尾特例（Heavy-tailed Exceptions）"]
end
subgraph Solution["务实的工程取向"]
C["无需覆盖所有长尾<br/>优先解决 ROI 明确的核心节点"]
D["构建高可靠性软件原语<br/>（降低开发与维护门槛）"]
end
subgraph Outcome["经济学效应（Jevons）"]
E["既有任务低成本自动化"]
F["释放生产力并催生出<br/>全新的工种与软件形态"]
end
A --> C
B -.->|"避免过度沉溺低价值长尾"| C
C --> D
D --> E
E --> F
```
Diogo 解释道，这就是他们将产品命名为 Jev（取自经济学中的“杰文斯悖论”，Jevons paradox）的原因所在：一旦原本昂贵繁琐的技术变得极其便宜且切实可用，人们不仅不会无事可做，反而会在此基础上创造出前所未有的全新工作类型。因此，当务之急是把那些显而易见“AI 本该能够搞定”的基准任务切实落地，让自动化真正具有经济学意义。
---
### `24:45` Jev 的爆发与对“可靠性”的极致追求
当谈及 Jev 的发布反响时，Martin 提到现在几乎每隔一个小时就会收到别人的信息，说发现 Jev 又能应用在某个意想不到的新场景中。Diogo 坦言，这种狂热的接受度完全超出了他们团队最疯狂的预期，事先根本没有预料到会有如此广泛的使用场景。这并不像 ChatGPT 刚问世时那样直接面向普通大众；Jev 本质上面向的是开发者，但如今甚至连许多非技术背景的朋友也加入到了 Twitter 上的热梗狂欢之中。
面对外界的喧嚣，Diogo 强调，团队真正倾注了无数心血、流血流汗换来的核心基石只有三个字——可靠性（reliability）。他指出，如果竞争对手不理解可靠性的本质，就绝不可能仅仅通过刷榜（benchmark）复制出真正的 Jev：
> “I feel like every nine of reliability is going to be so valuable for everyone, even if it's not the most valuable thing market cap wise, because it will just enable new applications.” —— Diogo Almeida
关于在本质上具有随机性（stochastic）的模型中到底该如何界定“可靠性”，Martin 询问这究竟是指 SLA 服务可用性（uptime），还是指调用模型必须返回一模一样的输出。Diogo 对此给出了清晰的层次剖析：
```mermaid
flowchart LR
accTitle: AI 软件可靠性的三个层次
accDescr: 从基础的 SLA 在线率，到中间层的确定性，最终递进到 Jev 追求的高层鲁棒智能。
L1["服务可用性（SLA / Uptime）<br/>系统在线、接口可调"]
--> L2["确定性（Determinism）<br/>相同输入产生相同输出<br/>（仅对单元测试有用，非真实系统）"]
--> L3["鲁棒性与智能一致性（Robustness）<br/>每次调用表现出同等水平的理解力与常识<br/>输出合乎人类逻辑，可供程序稳定封装"]
```
- **第一层（在线率 / SLA）：** 这是最基础的系统可用性，确保服务不宕机。
- **第二层（确定性 / Determinism）：** 每次给出绝对一致的字节输出。Diogo 认为确定性在编写基础单元测试时有用，但在复杂的真实系统中并不适用。比如，向 prompt 中加入一个随机 UUID，从业务逻辑上看功能没有任何改变，但严格意义上它已经失去了确定性。
- **第三层（鲁棒性与智能一致性 / Robustness）：** 这是 Jev 最在乎的维度。它不要求模型每次返回分毫不差的固定答案，但要求模型在面对输入时**始终展现出相同水准的常识与智能**。即无论情境如何变化，模型的决策在人类看来都必须是通顺、可理解的。
Diogo 设想的最高境界是：未来软件开发者编写调用 Jev 的程序时，根本不需要事先精心编写一堆示例（few-shot examples），就可以直接充满信心地针对它进行编程，构建出前所未见的大胆软件架构。
---
### `27:30` 代码智能体与底层原语：语法、语义与系统架构的博弈
探讨进一步延伸到代码智能体（Coding Agents）与底层智能原语（如 Jev）之间的竞合关系。Ben Horowitz 或 Martin Casado 提出了一个尖锐的假设：如果开发者拥有了 Jev 这样功能高度通用的底层原语，编写软件本身变得更容易，那么像 Codex 这类代码生成智能体的价值会不会反而被削弱？未来究竟会是代码智能体调用 Jev，还是人类开发者直接借助 Jev 编写更宏大的软件？
Diogo 分析了当前代码生成技术的优劣势。他认为现有的代码智能体在处理代码“语法（syntax）”时表现极其出色，但在理解深层“语义（semantics）”方面却表现欠佳，而在处理系统“架构（architecture）”时更是极其糟糕。而对人类开发者来说，架构设计才是软件开发中最具创造力、最体现人类心智的核心部分。
> “Architecture is like the most human creative part of software.” —— Diogo Almeida
Diogo 并不排斥使用代码智能体，甚至非常喜欢用它们来加速开发。他调侃说，Jev 作为一个全新的事物，几乎肯定不在现有主流模型的预训练数据分布之内（除非竞争对手偷看了用户数据）。但未来当这种原语成为通用标准后，完全可以让智能体去处理繁重的语法细节。
他指出，软件开发始终充满了权衡取舍：
- 现阶段的代码智能体在架构设计上充其量只能达到“第 50 百分位数（中位数）”的平庸水平。
- 如果一个开发者本身对系统架构毫无概念，那么接受这种 50 分位的架构并无大碍。
- 对于许多初创公司或激进推进的项目来说，“速度”是他们最重要的调节旋钮；为了换取更快的迭代步伐，他们完全愿意妥协，接受一个只有 50 分位而非 60 分位的软件架构。这种在架构深度与落地速度之间的灰色博弈，构成了当下软件演进的真实图景。
### `30:00` 从“SaaS 末日”到“SaaS 狂欢”：为什么老牌 SaaS 才是真正赢家
当第一波 AI 编程 Agent（Coding Agents）问世时，资本市场曾一度陷入对“SaaS 末日”（SaaSpocalypse）的恐慌，认为既然 AI 能够廉价甚至全自动地编写代码，那么现有的 SaaS 软件就很容易被轻而易举地复制，导致各大 SaaS 公司的市值断崖式下跌。然而，当 TypeSafe 推出 Jev 后，老牌 SaaS 企业却纷纷将其视作前所未有的救星。Diogo Almeida 指出，关于 SaaS 会被轻松取代的论调完全经不起推敲：代码本身的生成或许变得便宜了，但支撑复杂业务的核心逻辑全都深埋在底层，绝非轻易可以复制。他直言：“我并不打算对金融市场做任何预测，但就能力增长而言，这将是一场反向的‘SaaS 末日’，我对此无比兴奋。”（“I'm not going to forecast anything about the financial markets, but I think as far as capabilities games goes, it's going to be like an inverse Saspocalypse, and I am so jazzed about it.”）
Martin Casado 随即打趣地将这种逆转称为“SaaS 狂欢节”（Sassapalooza）。老牌 SaaS 公司最沉重的资本支出（CapEx）往往花在触达与建立庞大的客户网络上。一旦拥有了海量用户群，AI 的真正价值绝非仅仅是在界面上挂一个肤浅的聊天机器人（Chatbot），而是彻底重构底层软件体验。Diogo 展望道，传统的“多选表单”或许很快会彻底退出历史舞台，因为表单的本质只是为了把人类自然语言映射为系统能处理的结构化数据，这正是 80 年代第四代编程语言（4GL）所追求但未完成的“按我所想去执行”（Do What I Mean）。他分享了一个近期看到且极为惊艳的 Jev 应用示例：用户通过语音实时控制电脑，系统后台在极短时间内持续做出概率决策——判断该输入到底是一个操作系统指令，还是需要插入某处的文本内容，以及具体应该插入到哪个光标位置。
- **SaaS 核心壁垒**：代码生成虽廉价，但 SaaS 公司的壁垒在于对用户工作流细节的长期认知以及沉淀在系统深处的领域逻辑。
- **界面交互范式转移**：多选题、表单控件等本质是为人机沟通妥协的产物，Jev 能够直接在底层理解意图，让自然人机交互（如语音动态流控）真正落地。
---
### `33:00` 代码生成只优化了 10 行代码，而 Jev 赋予了软件全新原语
Martin Casado 提出了一个深刻的技术洞察：当前绝大多数 AI 编程工具只是在“更快地写出和过去一样的代码”，并没有让软件本身的运作机制产生质的飞跃。他在 Google 时的调研数据显示，大公司内部代码库的平均每个代码合并请求（Pull Request，PR）其实只有大约 10 行代码；这些代码往往只是在修补客户反馈或微调边缘分支，因此当前的编程 Agent 充其量只是优化了一个极其微小的环节，软件质量甚至可能因缺乏人工严谨审查而引入更多漏洞。Martin Casado 强调：“在 Jev 出现之前，我甚至从未意识到，无论你用多少 AI 编程 Agent，软件本身其实并没有变得更好。”（“Before Jev, it didn't even occur to me that it doesn't matter how much AI coding agents you use, the software actually isn't getting better.”）
相比之下，Jev 为现代软件引入了一个全新的计算原语：它不仅能够解析自然语言并具备常识推理能力，同时还与状态机严格绑定。Diogo Almeida 认为，传统的计算机逻辑建立在与非门（NAND）、与门（AND）等基础逻辑门之上，而 Jev 就像是在这些类型化逻辑门中植入了一个负责概率抉择的“微型大脑”。如果外界能把 Jev 视作在逻辑门层面拓展了软件的表达能力，将是对 TypeSafe 最大的赞誉。尽管这带来了诸如状态一致性（State Consistency）、持久性（Durability）以及强保证机制等极其严峻的系统级工程挑战，但它为软件应用开辟了从底层彻底进化的可能。
```mermaid
flowchart TD
accTitle: 传统 AI 编程与 Jev 原语架构对比
accDescr: 对比传统 AI 仅辅助编写既有代码与 Jev 将概率决策直接内嵌至逻辑门状态机的差异
subgraph Legacy["传统 AI 编程路线"]
A["AI 辅助编写 / PR (约 10 行)"] --> B["传统确定性代码"]
B --> C["同质化软件体验 (外挂 Chatbot)"]
end
subgraph Primitive["Jev 深度嵌入路线"]
D["自然语言意图输入"] --> E["Jev 智能决策原语 (微型大脑)"]
E --> F["强类型约束与状态机 (State Machine)"]
F --> G["全新自适应应用功能"]
end
```
---
### `35:45` 概率式编程的复兴与极致实用主义
随着新原语的出现，软件工程正重新唤醒一种沉寂已久的研究方向——概率式编程（Probabilistic Programming）。Martin 指出该理论早有渊源，但在 20 世纪 70 年代由于算力和确定性保障不足而基本归于沉寂。Diogo 则强调，他的出发点并不是搞某种模仿生物神经学的浪漫狂想，而是极致的工程实用主义（Incredible Pragmatism）。他直言，历史上那些纯粹模仿生物大脑的 AI 叙事几乎从未成功过，其真正价值仅仅在于能激励一批“科学疯子”在冷板凳上钻研数十年；直到工程团队介入并将其实用化，才最终诞生了像残差网络（ResNets）这样基于应用分层特征的工程奇迹。
在极度硬核的系统级场景中，Jev 带来的概率机制将引发类似网络层优化的重大权衡。系统工程师需要的往往不是一个算力过剩的全知模型，而可能只是一个轻量级的“近似链接”或者能在极端延迟下做出的“推测性路由”（Optimistic Routing）决策。历史总在周期性重演：从大型机演进到客户端-服务器模式，再到互联网和云原生架构，每一次基础设施的剧变都会带来一轮系统的彻底重构。面对当前日益严峻的网络安全漏洞与全新的智能原语，重新构建底层的核心基础设施已成定局。
---
### `38:30` 深入系统内脏：AI 调用的 99.999% 将发生在底层
在探讨 Jev 究竟应该定位于前端应用、SaaS 分析平台还是底层系统基础时，Diogo Almeida 借用了网络协议栈中 UDP 与 TCP 的对比来阐述他的系统观。他主张从一个长远的终局视角反推当下：如果未来迎来一场由 AI 彻底驱动的全行业经济革命，AI 像科幻小说那样渗透进每一段软件逻辑，那么绝大部分的 AI 调用绝不是为了面向人类输出文字风格或格式排版。
Diogo 犀利地剖析道：“如果你不瞄准系统的最深处，那将是非常奇怪的；如果你不把目标放在底层内脏，你可能需要耗费极长时间才能抵达终点。”（“If you don't aim for the guts, that's weird. If you don't aim for the guts, it's going to take you a while to get there.”）他预测，尽管当前 AI 主要是从第一层（面向用户的交互界面）切入，但最终会有多达“好几个 9”（99.999% 以上）的 AI 调用发生在系统最幽深的“内脏”中，充当无形的决策管道。长期以来，AI 与传统软件之所以像在黑暗中强行拼凑在一起般别扭，根源就在于传统软件根本无法原生接纳自然语言，而行业至今都在用各种别扭的胶水代码勉强维持两者的衔接。
### `40:00` 突破“悲伤五阶段”：从循环重试到状态机
嘉宾们回顾了开发者在使用大语言模型时的典型挫败感：开发者在 Prompt 中明确写下“这是你需要的 JSON 输出格式，这是具体的 Schema”，但模型往往根本不听从指令。最终，开发者在绝望之下只能选择放弃，“管他呢，直接把原始输出扔给人类来兜底”。或者退而求其次，将输出扔给另一个 LLM 去处理——而这也正是目前 Agent 架构中 `while` 循环的本质。从第一性原理来看，这种设计意味着要么必须让“人类在回路中”（Human in the loop，即聊天交互模式），要么依赖由 `while` 循环驱动的 Agent，因为自然语言输出只能再次喂回给人类或另一个语言模型来进行校验与纠偏。
Martin Casado 形象地将软件行业接入大语言模型的过程比作心理学上的“悲伤五阶段”（Five stages of grief）。开发者最初处于否认期，拼命想让现有的软件架构兼容非确定性的输出；随后经历愤怒与挣扎；最后步入彻底接受现实的阶段，心灰意冷地承认：“算了，我还是把它丢给另一个 LLM 或者人类来处理吧。”过去这种软硬件与模型结合的尝试就像“夜航船般互不相通”（ships in the night）。Martin Casado 指出，Diogo Almeida 和 TypeSafe AI 正在展示一种全新的范式：“我认为这是我第一次看到有人证明：你确实可以将 LLM 和 AI 映射到像状态机一样的体系结构中，并且能卓有成效地运行。”
```mermaid
flowchart TD
accTitle: LLM 集成演进对比
accDescr: 对比传统 Prompt 重试循环与 TypeSafe 状态机架构的差异
subgraph Trap["传统 LLM 兜底陷阱"]
A["输入 Prompt 与 Schema"] --> B{"模型输出符合规范？"}
B -->|"不听指令/输出失真"| C["Agent while 循环反复重试"]
C --> D["被迫引入人工或下一级 LLM 纠错"]
end
subgraph Solution["TypeSafe 确定性状态机"]
E["输入意图与结构约束"] --> F["Jev / 概率推理内部化"]
F --> G["直接映射为可靠状态机转换"]
G --> H["确定性系统可执行状态"]
end
```
- 传统 Agent 循环的本质：由于无法从根本上约束自然语言的不确定性，系统必须不断将非结构化文本反复传给人类或另一层模型解析。
- 软件工程的妥协：现有的很多 AI 应用并非真正实现了自动化，而是将脆弱的 Prompt 输出藏在昂贵且易出错的重试循环之后。
- 状态机路径：TypeSafe 的核心思路是将 AI 的推理能力直接内嵌并约束在状态机内，使其输出直接具备程序级的可靠性。
---
### `41:20` 可靠性与“做我所想”的 AI 乌托邦愿景
面对赞誉，Diogo Almeida 保持了克制与严谨，强调自己绝不想“过度承诺却交付不足”（over-promise and under-deliver）。他承认并不确定当前这项技术是否已经能胜任外界被吹嘘过度的所有应用场景，但他和团队会为之全力以赴。Diogo 坦言，团队对“可靠性”（reliability）有着近乎偏执的追求：“我们本来可以更早发布产品的，但人们并不知道这一点。”根据他对社交网络（如 X/Twitter）上相关讨论的观察，很多开发者可能永远无法在底层原理层面理解团队所解决的工程复杂度，但用户最终会直观地感受到“这款产品值得信赖”的好口碑。
Diogo 将这种终极产品形态称为“反沮丧机器”（anti-frustration machine），其核心哲学正是“做我所想”（Do What I Mean）。在他的愿景中，真正的技术理想是让世界运转得更加平滑，像精密咬合的齿轮一样顺畅联动。Diogo Almeida 总结道：“想象一下，如果所有的技术都能真正‘做你所想’。那并不是科幻小说，看看现在的 AI 有多么聪明就知道了。”Ben Horowitz 和 Martin Casado 对此高度赞同，认为“Do what I mean”正是总结本场关于可编程 AI 与未来软件架构讨论最完美的注脚。
- 团队延期发布的背后考量：TypeSafe 本可更早推出方案吸引眼球，但宁可推迟发布也要确保底层确定性与生产级可靠性。
- 产品定位与体验：无需用户理解底层的状态机和数学逻辑，只需要交付无需反复 Prompt 调优的“信任感”。
- 终极目标：消除人与软件交互中的摩擦成本，让软件从机械执行特定字符转变为能够理解真实意图并可靠执行（Do What I Mean）。
## Notable quotes
> `33:00` Before Jev, it didn't even occur to me that it doesn't matter how much AI coding agents you use, the software actually isn't getting better. — Martin Casado
> `27:30` Architecture is like the most human creative part of software. — Diogo Almeida
> `24:45` I feel like every nine of reliability is going to be so valuable for everyone, even if it's not the most valuable thing market cap wise, because it will just enable new applications. — Diogo Almeida
> `17:41` I really thought that the model had a decent chance of being AGI. And when it didn't, that was when my whole world came crashing down. — Diogo Almeida
## Mentioned
Ben Horowitz, Martin Casado, Diogo Almeida, TypeSafe AI, Jev, a16z, OpenAI, Claude Code, OpenAI Codex, Cursor, Gary Tan, Isabelle Guyon, Jeremy Howard, Google Brain, David George, Ilya Sutskever, Larry Wall, The New York Times
## Video description
a16z’s Ben Horowitz and Martin Casado sit down with TypeSafe AI founder Diogo Almeida to ask a simple question: AI has become remarkably capable, so where is all the automation?
Diogo argues that coding agents may help us write software faster, but the software they produce still largely works the way software always has. TypeSafe is taking a different approach with Jev: putting intelligence inside software itself, so developers can build programs that reason about intent and make probabilistic decisions rather than simply generate text for a human to interpret.
They discuss why reliability is the key to making AI genuinely programmable, how this could open a new era of probabilistic software, and why established SaaS companies may be particularly well positioned to benefit. Ultimately, Diogo’s goal is straightforward: technology that can reliably “do what I mean.”
[Source](https://mgln.ai/e/1344/afp-848985-injected.calisto.simplecastaudio.com/3f86df7b-51c6-4101-88a2-550dba782de8/episodes/a874c8b0-6ca6-4359-9d91-084c2ed8cd29/audio/128/default.mp3?aid=rss_feed&awCollectionId=3f86df7b-51c6-4101-88a2-550dba782de8&awEpisodeId=a874c8b0-6ca6-4359-9d91-084c2ed8cd29&feed=JGE3yC0V)
Source quotes
[33:00] Martin Casado: Before Jev, it didn't even occur to me that it doesn't matter how much AI coding agents you use, the software actually isn't getting better.
[27:30] Diogo Almeida: Architecture is like the most human creative part of software.
[24:45] Diogo Almeida: I feel like every nine of reliability is going to be so valuable for everyone, even if it's not the most valuable thing market cap wise, because it will just enable new applications.
[17:41] Diogo Almeida: I really thought that the model had a decent chance of being AGI. And when it didn't, that was when my whole world came crashing down.
Source quotes
[30:00] Diogo Almeida: I think that SaaS will be one of the largest winners of the whole AI game.
[33:30] Martin Casado: it doesn't matter how much AI coding agents you use, the software actually isn't getting better.
[33:30] Diogo Almeida: Automate the easy work before the hard work is always my philosophy.
[36:10] Diogo Almeida: I'm not a fan of, like, biologically inspired stuff at all. It's never worked.
Original transcript
[0:00] Where the fuck is all the automation? AI is so unbelievably smart, and yet it's so useless at all other stuff. It doesn't matter how much AI coding agents you use, the software actually isn't getting better. Maybe you're riding it faster, it's like arguably getting worse. OpenAI has been trying to automate customer service since 2020. What I want instead is smart software. I want to expand what software itself can do, such that things that should be automatable can then be automatable. My favorite thing that you guys say is we build prod, not God. That's so good. Because if we had any other kind of like big lab leader, even if they had joy, they would cover that. And then your view is so different. You're like, no, we're going to create a way better world. For nuanced reasons, I don't think we are on the path of RSI. In the Saspocalypse story, AI can write software. But what if the bigger opportunity is putting intelligence inside the software itself? In this episode, Ben Horowitz and Martin Cassato sit down with TypeSafe AI founder Diogo Almeida to talk about JEV and a different vision for how AI changes computing. Diogo argues that coding agents make it faster to produce the same kind of software we already have JEV is aimed at expanding what software itself can do giving developers a new primitive for turning natural language intent into decisions that programs can actually use They get into why reliability matters more than impressive demos, what a new era of probabilistic programming could look like, and why AI might make existing software dramatically more useful rather than simply replacing it. And beneath all of this is the question that drove Diogo to build TypeSafe in the first place. If AI is already this smart, where is all the automation? Today, we have the founder and leader of TypeSafe, Diogo, with us, who is a bit of a hero to both Martin and me. He is not only building a really interesting product, but creating what we think is a very important movement. So we're super excited about today. Welcome, Diogo. Thank you. Maybe you can give us a brief on what is JEV, what is TypeSafe, why is it important? Is this a curse friendly or no? Yeah, yeah, yeah. Oh, okay, cool. What the fuck are you talking about? Okay, okay, okay, cool. So I was actually asked for an elevator pitch which I tend to ramble on and I don do well like I realized my favorite elevator pitch for Jeff is where the fuck is all the automation Like this is like so unbelievably tragic. Yes. So much intelligence. AI is so unbelievably smart. And yet so, not that I hate on chatbots or coding agents. I love them myself. But it's like so useless at all other stuff. And it's tragic. It's tragic that we have so much like diamond in the rough, but not polished for work. But TypeSafe is making AI for software. We want to make AI powerful, not just for humans in the loop, but to actually build real software. And Jiv, to us, is our first model in this whole space to make it way, way better to make automation. Yeah, and so it's been interesting because it's kind of caught fire in software world. So one of the things that made us go, what the hell is going on here, is every developer we know is calling us and going, going, oh, this is frickin' awesome. It's great. It's fast, it's great, everything's better. Then how does that, because everybody thinks of, well, we've got Cloud Code, we've got Codex, don't we already have that? Like, what's the difference? And then how does that lead to real automation? Ooh I wish I had like some slopped visuals because I have a favorite slopped visual for this So I like Cloud Code and Codex I love the description from Gary Tan on them It's just-in-time software. Incredible way to describe what they're doing. It makes software on the fly, and you can program software in natural language, but it has the same expressive power as software. What I want instead is smart software. Instead of automating software engineering, I want to expand what software itself can do such that things that should be automatable can then be automatable. And in a more flowery language, I want to express things like intent. I want to expand the vocabulary of what we can do. And I can talk about all sorts of weird sci-fi things I want. But programming is hyper-specifying valuable things and then infinitely replicating them. It's so freaking cool. And I want to just make that more. Interesting. So one way to think about it is instead of kind of a tool that somewhat replaces a software engineer with a faster, maybe not even as good software engineer, what you're saying is, no, no, no, we're going to super empower the software engineers we have to write way, way better, more interesting things. Yeah, yeah. So this is, by the way, I just think so many people miss.
[5:00] at this point, and it's such a subtle point, and it's so important to actually tease it out, which is, if you use something like Cloud Coder Codex, which is great, or Cursor, which is great, they write code. But that code is the same thing a human being would have write. Maybe it's better, maybe it's worse, but it's basically still code, just like code looked 10 years ago. And the thing with JEV is, whether or not you're a Cloud Coder or a human, you have this new primitive, this new thing that you stick in your code that actually expands the power of software. So instead of writing code, it is something that you include in your code. Which, by the way, is interesting because it's this very powerful primitive, which would be great if you explain, but it's also a little bit different than how programmers think. For example, it has this notion of probabilities or maybe... So an intelligent layer inside the software. Yeah, think of like a library that you can use natural language to describe what you want, give it kind of a state machine and then it will choose what to do with some confidence levels, which we kind of haven't really had before. Ooh, there's a lot of tricks there. I will jump into one thing first, which is I love the first thing you said in the direction of where the fuck is all the automation. I love software so much. I wish I could be writing it all day. It's amazing. Would not recommend being a CEO to people, but whatever. And also, it's, while that AI is so cool and software has been unchanged in 10 years. You know, like that to me, like no one can square this together. And the most we can do is add like a little chatbot in the side sometimes that can take actions, but not all actions, because some of the actions are not reliable. So I just want to give like that tiny aside. I love the point. I'm going to jump back to the point about like, this is a little bit of a different way to think about it. Yes, I think that machine native doesn't exactly match bits perfectly. are trying to do in our onboarding on day one, I draw like the Venn diagram of like what AI is good at, what is valuable in code, we're in the middle. So, you know, we don't output like extrapolated floats, for example, because like AI is just bad at that. But things like probabilities are not exactly novel. And it's similar to the is Jev just a classifier argument. Jev is absolutely a classifier. Like classifiers are sick. Classifiers were designed to be useful. Yeah, they're designed to be useful. And actually, it's the same interface as like some of those ML concepts. Because these came from like practical people who are trying to make systems work. And what I'm seeing is happening now is that Jev actually, my guess is that Jev probably is better than having an MLE team from 2019 making the stuff for you. And you can just program it on the fly. There were not that many good MLE teams in 2019 to build narrow things and to be able to collect data sets and measure it and all of that. And it is just the beginning. By the way, to this point, do you think there's a slider bar here where like on one end is like language in, language out like we have today. On the other end is like an existing imperative program. And then you can kind of move between the two. Or do you think like this is like the point in the design space, which is language in kind of state machine out, which is going to solidify as the general purpose thing for programmers? Ooh, that's a tricky one. So I will say the answer in my heart. The answer in my heart is that it is a slider. And actually, when I design... for the properties we have, I might have made mistakes due to my personal preferences, but like intelligence per dollar is my North Star right now. And it could be wrong, just to be clear. Intelligence per second might be more valuable in the short term. But even like our interface, like calling the input state, this is intentional. Like it's to say... Oh, that's great. I didn't catch that. It's meant to be the inside of programs. Oh, I love that. So in my heart, because like, so we are really optimizing, a lot of the work I do is for even more complicated arrangements Can you put intelligence in there? I think that this is going to be an ever-present battle to have. We're very intentional about our design. And also, pragmatically, I think certain things happen. Like, it's easier to make an AI at these milliseconds. So it'll be more like a database for a while than, like, a standard library thing. But I would love it to be a standard library thing, too. Can I just pull back a little bit? Like, what is the alchemy that creates a Diogo? I mean, like, you speak... When a man and a woman love each other. You speak like an AI researcher, you speak like a systems person, you speak like a programmer. And normally these things have been like not super overlapping. And you're taking AI, which we've been pushing towards being a being, and you're making it a programmer's tool. So maybe a little bit about your personal journey that... My history into AI is somewhat unorthodox. I was a mathlete. I was an award-winning mathlete. The way I describe it is I was good enough at... This is a cringe. I was good enough at math to get girls. So... I didn't know that was a thing. You have to get quite good. And what kind of girls do you get when you're that good at math? That's an excellent... Our audience needs to know. Oh, no. We have to inspire the youth here. Don't do it. Don't do it.
[10:00] do it. It's not worth it. Just be cool and chill and interesting and don't overcompensate. Wow, I can't believe I said that. So I was a mathlete, but I actually never, oh man, this also is a little cringe. I never really liked math. I never really tried. I was just like big fish in Little Pond. And to me, math was always the path I was set on, but I hated it because it is always about winning competitions. But then computer science is actually a lot like math. It's basically like math, but cool and useful and fun and interesting. And I still love giving algorithms interviews. Is it the best thing for me to do? I don't know. But do I love it? Yes. And does it allow me to suss people out really well? Yes, it does. So I love computer science. I consider myself to be a computer scientist much more before AI researcher, despite my history. And And what actually got me into it was I also won a Kaggle competition, not from sophisticated math, but from just automating the fuck out of it. You know, more nested loops. It solved a systems problem. So that eventually got me I was forced to speak at NeurIPS normally in honor but I hated it because I just wanted to be in the mines Was that from the Kaggle thing Yes Oh, wow. Yeah, actually, the Kaggle host of it was Isabel Guillon, who was the co-inventor of the SVM. Actually, I think the first author of SVM. I'm not 100% sure I'm the first author. And she just basically saw that I was like this person who really didn't fit into the research community and then adopted me and showed me. It got me to meet all the AI people and my career was just pushed into that direction. And from there, OpenAI? No, it was a startup with Jeremy Howard. No kidding! Yes. I love Jeremy. Fantastic. Cool. And then Google Brain for a while. Wow. And then Retire for a while. And then eventually I was just kind of tired of not doing anything. And I was like, you know what? Actually, AI is pretty damn fun. And I joined OpenAI because of that reason. And it worked out really well. Amazing. Really, really well. Yeah, incredible. So you said something there that is so unusual in today world which is AI is really really fun And then the company has such a different demeanor and view of AI than everybody else And my favorite thing that you guys say is we build prod, not God. Because if we had any other kind of like big lab leader, they'd be like trying to, even if they had joy, they would cover that. and then your view is so different. You're like, no, we're going to create a way better world, and it's going to be awesome, and there's going to be not only are there not going to be less jobs, there'll be more jobs, and there'll be way better jobs, and everybody's going to have a great time. And just being around you, you clearly believe that. So tell us about that. Because for us, TypeSafe, Jeff, it's more than a company. It's a whole movement towards a positive future. that most people in the AI world kind of don't like. Or they're not with it. I think they don't get it. It's just a classifier complaint. It's like an ML level concern while everyone else is having a Jeff party. Because it like holy shit we can do all the things that we wanted to do And I think if you don like get developers it be hard to understand what really going on So 100 I agree with that I do think that there's like a pretty negative world painted that I obviously disagree with. I think it really comes from this like, you know, mono model Kool-Aid that everyone believes. Right, right. One big brain to rule them all. that's why that's what sounds much more ominous yes that's what people hear for sure that's what people hear but you know like will that one is that one brain really on the path to rule us all like we have not automated really basic things that I don't think we want people to be doing you know like there's lots of really really basic stuff and I think that oh man it pains me when the world is discordant with the reality. And part of the pain is on the where the fuck is all the automation. How can we have AI be so freaking smart? And there's so much financial incentive to automate stuff. Like, yeah, you could make an excuse for diffusion. I don't buy it at all. I shouldn't name names, but that obviously is not true. Part of the problem is the discordance with the reality. And the fact that AI has so much
[15:00] is what made it really tragic for me that we had not released this. So now it's a little bit of a party for me, but I was afraid of AI. And all Jeff users are like, there's the happy AI, the people on Jeff, and then there's the morose AI, the people who are not. It's really, it's quite a kind of, It's a fascinating dichotomy. It is really – well, I'll give you – and to your automation point, I had a funny conversation this morning with David George who runs our growth fund because we're talking about the new tools. I was like, have you tried the Muse thing? He's like, oh, it's awesome. I was like, what did you do with it? He said, I finally canceled my New York Times subscription. the iceberg of the things that are horrible things to do that, that we need to automate. I think that if we were going to be really intellectually honest and we are really aiming for the North star of automation, we cannot fall into the same anti-patterns that AI has fallen into, which is really, um, focusing on outliers and demos, right? Like, a lot of people ask me, like, what are your favorite use cases? And I'm like, I'm not sure if they work. I want them to work in the background such that, like, someone would trust that to run and not page them. And, like, people can build on top of that, too. And, like, you know... Composable, composable. Composable, but, like, other things, like, you know, safe, right? Like, it's a different type of safety where, like, If you want it to actually run with resources associated with it, with access to things, you need guarantees for that, or at least statistical guarantees. So it doesn't go wrong, breaking the hugging face, that type of thing? Well, I don't think our models will be doing that anytime soon, unless someone does the software to do that, which would be very cool flex. Very cool flex. I should figure out how to give credits for that. But that's... in a way that we're not responsive. Right, right, right. I'm just curious, like, how long has this intuition been percolating? Because I remember talking to you, maybe in, was it 2017? We did talk about that. Yeah, and then, like, a lot of these ideas were in, you know, you were talking about data being important, you were talking about, like, you want to focus on the task, and, like, but, like, So I just like... Did you know that this was going to end up being a classifier? Or was this just an intuition that there was just another way to view this entire AI movement? Actually, a fun story about that chat in the talk from 2017. I think my talk was... actually on a very similar theme, I think it was called something like AI modular and theory inflexible in practice, which is very software system. So I'm a little bit consistent in that. I... I think that this really started right before ChatGPT. Like right when we released these things, I did not have intuition about this. And honestly, I was not even... I was very, very pleasantly surprised by the generalization capabilities of RLHF. When is this? Must be end of 2021, like a fourth quarter of 2021. It was really, really general. If you read the paper, it's unlike other papers that are trying to prove their point. It is us actually, you know, scientific method-ish, trying to disprove, like, is it cheating? And yeah. My favorite query was, why is it important to eat socks before meditating? We made sure that was not on the internet beforehand. And the models were able to make plausible human-looking answers for this. And that, to us in the team, was the thing that clicked, like, this is not cheating, which you should always be afraid of cheating in ML. Then... what really got me burnt was I, we released it. Um, you know, we did a, you know, I'm obviously a big capabilities guy. I did a lot to release that model. I... I really thought that the model had a decent chance of being AGI. And when it didn't, that was when my whole world came crashing down. Oh, interesting. And I was like, why? So you were kind of on the other train for a bit. Like the crazy train? Well, no. RL generalizes, like, maybe we have AGI. HF generalizes pretty well. RLVR is the thing that doesn't generalize as well, from what I've seen. And... AGI in... Well, I was just saying more. I mean, you were in chat GPT. You were behind these early GPTs. That was a very different goal, which is creating a chat bot that will talk to the human being which is not a programmer's tool, et cetera. So I'm just wondering... Oh, well, actually, early GPTs, early, like 2020, OpenAI, when we talked about AGI, people used to describe it as Ilya and every if statement. So it's not, it's kind of like, but like, is it like part, we were talking about OpenAI culture, part of it is that it's like intentionally vague. So it's a wide, like tent so that everyone can be inside of it. But like,
[20:00] I am not... For nuanced reasons, I don't think we are on the path of RSI, and I still don't think we're in the path of RSI, and I did then. I do think that what OpenAI defined as AGI is extremely doable. Automating most of the world's economically valuable work actually sounds... Yeah. Oh, man, I don't. Like, There's a lot of work out there. A lot of it is very rote and simple. And by volume, in order to be able to outsource work, you need simple instructions that basic people can do. And as far as I can tell, the intelligence of that has been available in the models for quite a while now. Like, my... Oh, man. chip on my shoulders, like, why is this not available? And And then since our LHF, the industry just like kind of bifurcated into gigantic overpromise under deliver. I think GPT-3 was actually quite calibrated back in that day. But because humans evaluate how good the models are, it looks really good because they are the judge. But we've been optimizing that judge instead of the automation part. And that has been the missing thing. So I would say there's really... really then that it hit me. You know, like, why is this thing not more useful? And so you think that the measure that we should have is to what extent can you automate actual productive tasks? Is that the... When you say over-promise and under-deliver, that's the dimension in particular you're talking to. The ability to automate tasks. I think in my heart, it's like cool sci-fi. And I think that that is the canary in the coal mine for cool sci-fi. Are you really telling me that math is solved, or even two years ago, GPQA, that Google proof question answering is solved, but we still can't handle a drive-through, right? It's a very hard thing to hold in your head at once. And I think a lot of people don't have good answers to that. Can I just test one thing? Which may not make sense, but I want to say, I mean, isn't there an argument though that like, The distribution of the real world is... is different than the digital world, right? It's heavy-tailed. There's a lot of exceptions. We don't have all the data. And I mean, couldn't it be the case that the reason we're not doing productive stuff in the real world is just like we're not We don't have the data for that distribution. We're not training on that distribution. And this is why it's just been basically relegated to these lower dimensional manifolds, like whatever math or code or... Thank you. Um, I don't entirely buy the... data argument, in my opinion. I do believe that there's a long tail, for sure. That would be kind of crazy to deny. And I don't think that in my canary in the coal mine situation, we need to automate that long tail. I think we need to be incredibly pragmatic on everything. And building reliable software is always an investment, right? What were the three great virtues of a programmer? There was a third one. Yeah, no, I remember. This is from the Pearl days. Yeah, there was a third one. Very well, yeah. I wish I could remember it. But it's about the laziness to spend 10 hours to do the five-minute task instantly and to never have to do it again. It should be an ROI decision for people who automate stuff. I would just like it to be automatable. And I think that people will just make new kinds of work, hence the Jev in Jevins. new kinds of work once that stuff is doable. But as a benchmark, I feel like it's useful to see, can we actually automate the stuff that it really, really looks like AI should be able to automate. OpenAI has been trying to automate customer service since 2020. You know, like, it's... It's not. Which is pretty amazing. It's wild, you know, it's wild. Well, I mean inside companies, There's very little that's automated right now. And the projects haven't worked. Okay. Other than programming has worked amazing. Can you maybe classify the types of problems you think that are easier to automate? It was kind of interesting. So we've actually looked at support before the current generative wave. And it was interesting, you'd meet a company, and the company would say, we answer 95% of all help desk calls. I'm like, that is so many. But then you actually look at the data, and you realize it's all password resets. But if you did it by uniqueness, it was only something like 50%. So it just feels like when you're dealing with humans and natural systems, there's just kind of this very kind of... you know, like a long tail of exceptions. And so to what extent did like, Probably every hour, I have somebody ping me. I'm like, I'm using Jeff for this new use case. I had no idea. To what extent did you even predict...
[25:00] the broad range of use cases for it. Did you assume that was going to happen? And have you been surprised by that? Extremely surprised. Did not assume it would happen. This launch was... like not something, like if anyone expected this, they are probably insane. Right? Like it is... I don't think someone could... expect a ChatGPT for developers, because ChatGPT was for, you know, like, you know, the normal users. And, It's weird. I actually don't even know what percentage of the people who are part of the JF party are developers themselves. I can't imagine non-developers using it. I don't know how they would use it. But even my non-developer friends are just like part of the party and Twitter and memeing and everything like that. So number one. Phenomenal. Number two, Um, This will... be hard to convey in this short message, because it's been like blood, sweat and tears for years now. The amount I care about reliability is... Um, It's a lot. Like, reliability is what this thing is. If you don't understand that, it'll be very hard to make, like, a copycat that's bench-maxed. Like, it's... I feel like... every nine of reliability is going to be so valuable for everyone, even if it's not the most valuable thing market cap wise, because it will just enable new applications. And like we are fighting for like all sorts of like weird nines of reliability that like we don't even fully understand because we are just like, you know, like really getting this like, electric motor of AI, of intelligence, into people's workstations, and they can figure out what to do with it. What does reliability mean in this context? Is this availability of the model, or is it like, I call the model and it returns the same thing? Or how do I think about reliability? Yeah. For something that's inherently kind of stuck out. Not so much the former thing. And the second thing is closer. I would describe the first thing as kind of like uptime or SLAs. The second thing I would maybe call closer to determinism. something thirdly, I would consider more like robustness. So robustness, I would kind of describe as similar intelligence every time. Oh, interesting. Yeah. So like not exactly determinism, because I think determinism, it's useful for unit tests, but not real systems. Think about like if you add a UUID to a prompt, it should be the same because it's the same functionally, but it's not exactly deterministic. I think that there's another layer of it that I called yet, like maybe this is what I would call like some form of intelligence, which is it doesn't have to be the similar function every time, but it needs to be smart every time. You know, like if you were in that situation, would this be an understandable thing for a human to think? Because a developer can program around that. And actually, to me, the highest honor of reliability will be to get to the point when people can program against Jeb without making example queries. just creating crazy software. And that's where a lot of software is today, right? I don't think it's totally unrealistic, but I'm going to be fine. By the way, this is kind of a weird question. So feel free. If it's too weird, just feel free. But it occurs to me that actually the value of things like coding agents goes down if you have a primitive like this in a way, which is like you could be like, you know, whatever. Codex builds all the software for me, but it doesn't actually use JEV. software itself creates it somewhat limited. Or you can be like, okay, I as a human being, I will write the software without using a coding agent, but I've got this very generalized primitive that makes writing software easier. So do you feel like... see a future where it's like the coding agents using JEV and then you're telling the coding agents and then do you have redundancy? Or do you feel it's like human symbolism? This is more of a coding agent question than it is a JEV question. Oh yeah, for sure. My vibe is that... I'm not in the coding mind as much as I'd like to be. So you two might be in there more than I am, which is sad. But my experience is that they are really good at syntax and really... They're bad at semantics. Yeah. I would say incredibly bad at architecture. Yeah. So like to me, architecture is like the most human creative part of software. So I love using coding agents. I think that Jeb is almost certainly not in distribution. That would be spooky if they trained on our user data. So it's probably not. But I think that when it is in distribution, I see no problem with like having it do the syntax. but maybe their 50th percentile architecture. And if you don't know anything about architecture, it would be fine. So these are all like, gray area trade-offs in order for you to navigate. And sometimes speed is the knob for your company or project to turn. Like you're willing to do a 50th percentile architecture instead of a 60th because you want to move faster. And
[30:00] have like codecs work overnight or something like that. Actually, kind of along those lines, one of the interesting things or phenomenons in the market already is that, you know, when the coding agents came out, it was the SaaSpocalypse, and all their values dropped through the floor. And then when Jeff came out, Every SaaS company is like, this is the greatest thing ever. So explain that. Mm-hmm. I don't know what else to say, right? I think it's quite natural. In the Saspocalypse story, the story that I feel like has panned out really poorly is that software is very cheap and perhaps easy to replicate, which I think I could believe the former. I could not believe the latter because a lot of the stuff happens beneath the hood. I'm maybe overly a software fanboy here. Yeah, all of us. Okay, okay. where you might be the coding agent. We have a lot of legacy around that. Yeah. So I don't think that really panned out. So SAS seems... Maybe the markets don't agree, but I think SaaS is providing the same value it used to. Maybe the markets are just scared. But I think that SaaS will be one of the largest winners of the whole AI game. And I want to work really, really well with all the biggest, most boring, most in-the-know-of-user problem SaaS players. companies, because I think that they are the best position to know what workflows to automate, what do people need, like that's what their bread and butter is, and to spend the big, like, you know, software is always a CapEx investment. And like, you spend it ahead of time in order to make this experience even better, that gets, you know, like distributed to all of that massive users, right? So I think that it's going to be I'm not going to forecast anything about the financial markets, but I think as far as capabilities games goes, it's going to be like an inverse Saspocalypse, and I am so jazzed about it. I should make a name. Yeah, I got that. You should have a name. Sassapalooza. Whoa! That was a little too fun. Well, the Sass applications are going to all of a sudden get dramatically more useful. much of a SaaS company's capital investment is actually getting to all the customers. And so if you've gotten to all the customers and then you make, you know, not just put a chat bot on your SaaS product, but actually make the software like way, way better, you That's a hell of a thing. I don't know if this is a realistic dream or not, but I think that there's a world where like the multi-choice forms just disappear. I feel like they are always something mapping natural language that usually the software already has into a JEV-like output. It's literally from the 80s. We used to call it 4G L. Fourth generation language. Actually, also, I think this is from the 80s. This might be an insult. I was born then. I think that do what I mean is going to be taken to the absolute next level. jf application i don't know if it's reliable so i can't promise anything but it was so freaking cool someone was using like a voice to control your computer and it was basically constantly making decisions on like is this a command or is it inserting text where's inserting text like like that sounds so unbelievably cool like like i feel like interfaces could just completely change and maybe we're gonna have to make it like cheaper faster you know yeah then you're at star trek There's just such a profound intuition here, which is if you use AI today to generate software, right? You're still creating the same software that you did before, but if you actually look at the average PR for a large company, it's like 10 lines, right? Seriously. I've been at Google. We actually did this study, so it's like 10 lines. So you're automating 10 lines. And by the way, those 10 lines are part of a learning from a customer or something. So you've kind of optimized something that's actually pretty minimal. But what it doesn't do is provide new capabilities to the software. It's kind of automating this thing which in the limit ends up being relatively minor. And now there's actually a new capability. And so it could just be the case that software just actually gets better. Before Jeff, it didn't even occur to me that it doesn't matter how much – AI coding agents you use, the software actually isn't getting better. Maybe you're writing it faster. It's arguably getting worse just because there's less oversight. And often more insecure. For sure, for sure. But you actually now can make an argument like... like apps will have new functionalities as a result of this, because there is this new primitive that you're providing. I mean, in a way, it speaks natural languages and it can reason, but it marries that to a state machine. I...
[35:00] people take that as a takeaway that would be like the greatest compliment ever to what we are doing like i actually feel like it's almost two grand of a vision to expand beyond the three logic gates that we have into like you know it our types are kind of like one of the same logic gate but like one that's like a little brain in there like that would be the greatest compliment to like the type safe legacy because like that is that's a very huge non-trivial huge thing for the world um I'm not going to over-promise, under-deliver that, but I will fight for that. Yeah, I mean, listen, I think there's pretty open questions to how deep can this get as far as really serious stuff, like state consistency or durability or real systems-level stuff where you actually need to provide strong guarantees. And so 100%, this will change things like whatever, analyzing logs, analyzing emails, providing a UI, talking to the human. That for sure, but you could argue that over time this becomes like a smart database. Air traffic control system, which we really need. A little scary. I think automate the easy work before the hard work is always my philosophy. But I also think there's going to be an entire era of probabilistic programming that's opened up. Like, my... By the way, you know there's a huge history of probabilistic programming. It basically died in the 70s. I'm familiar with it. I actually think it's going to be You could also call Jeff NeuroCycology. Your co-founder, Eric, came from that background, he was telling me. Oh, cool. Oh, yes, yes, yes. He did a lot of biology. It goes up and down. But what I mean is a more... I'm not a fan of... My brand is pragmatism. Incredible pragmatism. I'm not a fan of like biologically inspired stuff at all. It's never worked. Have you ever noticed that? I think it's never worked. It's useful to motivate crazy people to work on things for decades until it works. And then they refine it into like the engineering version. The story of AI. Neural nets for sure. Yes. But like, you know, a lot of the stories about how it worked were not accurate. Right. So like the hierarchical features of applications really did end up working. otherwise Resonets wouldn't have worked. Longer story. I do think that it opens up like, from a systems perspective, I'm not excited about this part because it's really, I'm excited for the world, not about me programming this because it sounds like really complicated. But I think that as we have like lots of intelligence at lots of cost and speed trade-offs, the super systems-y types will be making trade-offs at like, you know, like, Jeb's going to be like a thousand times too smart for them. They just want like an approximate link to have an approximate guess to like optimistically route here and there. It's going to be like, So crazy, this type of stuff that's available in the extreme systems. And the good news is we get to rebuild systems again, which is great. No, seriously, we have a new primitive. It's kind of a new way of thinking about doing software. I mean, we did this. We did this with the internet. We did this. being framed to client-server. I mean, we do this periodically. And By the way, just because of the... cybersecurity issues, we probably have to rebuild almost all the systems to just make them safe. I would think. I think it's pretty clear that there's not... Or at least the critical infrastructure, for sure. Do you think about this more in terms of apps, SaaS, analytics, or... More in terms of like systems, foundations, or all the above. For what I would think of? Yeah, just general application for this. When you think about like you're working on Jev and like, and you kind of envision that people are adapting it. Like, you know, like, do you, maybe do you even have an opinion? I have a little bit and it's, So the way I think of it is a little like... deep into the TCP guts. You know, like UDP, TCP. It's unreliable, too reliable. You're stinking my language. Exactly. When I think of AI, and this is why I care about intelligence per dollar, to be clear, and how I got to this conclusion, I work backwards from AI-based economic revolution. AI everywhere, sci-fi and everything, all the software has AI all over the place. And I ask myself the question, what percentage of the calls to AI, I imagine it's like a function, which, what percentage are like for human consumption, where you need like style. And it's going to be like many nines. And actually from that same question, how many will be at the first layer versus like deep in the guts? Right. And I think that it's going to be many nines in the guts, but it will start at the first layer. But like we need to, if you don't aim for the guts, that's weird. If you don't aim for the guts, it's going to take you a while to get there. Right. I think people don't understand to what extent, like AI was kind of shipped to the night with software. AI and software, it kind of like didn't behave, right? Because software doesn't really take natural languages. And you do all this weird stuff.
[40:00] You stick at the prompt like, Here's the JSON output that you want, and here's the schema, and it would never listen to it. And so what you ended up doing is just taking the output and giving it to a human. You're like, to hell with it, right? Or another LLM. That is what a while loop is, like the agent while loop, right? It's like from first principles, it needs to be human in the loop, which is the chat, or an agent, which is the while loop, because the natural language needs to be fed back into another. Yes, and I will say, I have watched this happen. There was almost like this kind of like five stages of grief. software, right? And then, you know, and then it would like go with like, you know, whatever denial, like try to make it work and like anger that they go to acceptance, which is like, okay, nevermind. I'm just going to give this to another LLM to a human being. So it's been very ships in the night. I think this is the first time I have seen when someone's like, actually, you can take an LLM, you can take AI and you can actually map it to like, like a state machine and you can do that productively. And... I hope so. I will not want to over-promise under-deliver as well. Like, I don't know if it's ready for all the applications that have been over-promised. I really, really want it to, and my team will fight for that, obviously. Like, we... really, really care about reliability. We could have released so much sooner. I don't think people realize that. And I don't think that, honestly, I don't think that they will. Based on what I see at the Twitter discussion, I think people will never get it. But like, it'll just have like that good vibe of like, oh, I can trust this. So it's the anti-frustration machine. It's a, I hope so. I hope, do what I mean, right? Like to me, that is about like, smoothness in the world, like having everything just move more smoothly together and interlink like gears. I actually have my whole like AI utopia on like different axes that I really, really want. And like, do what I mean is a huge part of this. You know, like, imagine if all technology just did what you mean. That is like, that's not sci-fi. Look how smart AI is, right? Yeah, no, it's amazing. And maybe that's the thought to close on. Do what I mean. Yeah, I love it. Thank you, Diogo. This has been a great conversation. I really enjoyed it. again for listening, and I'll see you in the next episode. As a reminder, the content here is for informational purposes only, should not be taken as legal business tax or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast. For more details, including a link to our investments, you
