TypeSafe Debuts Jev to Embed Probabilistic Logic in Software State

How Jev Turns AI Into Software That Gets Things Done — a16z

a16z

True workflow automation has stalled because coding agents merely accelerate standard code generation rather than embedding reliable probabilistic decision-making directly into application runtimes.

AI-assisted summary of How Jev Turns AI Into Software That Gets Things Done — original source. Check the original for full context.

Source published:

Key ideas

  • TypeSafe AI introduced Jev, a production-grade intelligence primitive designed to embed probabilistic classification and intent-aware decision-making directly inside software runtimes rather than simply using coding agents to generate conventional code. (0:50)
  • Diogo Almeida argues that the forecasted 'SaaS apocalypse' is reversing into 'SaaSPalooza' because entrenched enterprise platforms possess the critical domain knowledge, distribution, and nuanced workflows needed to monetize embedded AI. (30:00)
  • Rather than relying on fragile prompt engineering or ad-hoc agentic while-loops to parse unstructured text, future software stacks will run 'many nines' of AI function calls invisibly within deep low-level infrastructure and state machines. (38:05)
  • The development of RLHF and RLVR revealed critical limits: while models show broad open-domain generalization, they struggle with reliable real-world task execution, making engineering reliability the primary bottleneck to end-to-end automation. (16:58)

Detailed notes

## Background Published on YouTube by a16z on September 28, 2026, this episode features Ben Horowitz and Martin Casado interviewing TypeSafe AI founder Diogo Almeida. According to the show description, the discussion explores why real-world automation remains scarce despite soaring model capabilities, presenting TypeSafe's Jev as a new paradigm that embeds intelligence directly inside software so programs can reason about intent and make reliable probabilistic decisions.

## TL;DR TypeSafe AI founder Diogo Almeida challenges the conventional AI paradigm, arguing that coding assistants merely accelerate the creation of traditional, brittle software instead of expanding what software can fundamentally accomplish. To solve the persistent absence of real-world automation, TypeSafe created Jev, a primitive that embeds probabilistic intelligence directly into program execution using reliable abstractions like classifiers and finite-state machines. Rejecting the messianic gloom of frontier labs under the banner 'we build prod, not god,' Almeida and the hosts explain how reliable, intent-driven primitives will revolutionize deep systems infrastructure, turn the feared SaaS apocalypse into an incumbent boom, and realize true 'do what I mean' computing.

## Atmosphere & style The conversation is refreshingly candid, fast-paced, and irreverent, cutting through widespread AI industry dread with sharp wit and an unapologetic builder ethos. Horowitz and Casado engage in an effortless, high-rapport dialogue with Almeida, seamlessly pivoting between self-deprecating banter about competitive math contests and rigorous systems-level analysis. Listening feels like sitting in on an exhilarating, behind-closed-doors engineering debrief where seasoned practitioners celebrate the pragmatic thrill of making software actually work in production.

## Bulletin - [00:50](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=50s) TypeSafe AI introduced Jev, a production-grade intelligence primitive designed to embed probabilistic classification and intent-aware decision-making directly inside software runtimes rather than simply using coding agents to generate conventional code. - [30:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1800s) Diogo Almeida argues that the forecasted 'SaaS apocalypse' is reversing into 'SaaSPalooza' because entrenched enterprise platforms possess the critical domain knowledge, distribution, and nuanced workflows needed to monetize embedded AI. - [38:05](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2285s) Rather than relying on fragile prompt engineering or ad-hoc agentic while-loops to parse unstructured text, future software stacks will run 'many nines' of AI function calls invisibly within deep low-level infrastructure and state machines. - [16:58](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1018s) The development of RLHF and RLVR revealed critical limits: while models show broad open-domain generalization, they struggle with reliable real-world task execution, making engineering reliability the primary bottleneck to end-to-end automation.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=0s) Modern coding assistants generate conventional code faster, but they fail to make software fundamentally more capable or automatable. - [12:18](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=738s) TypeSafe AI operates under the philosophy 'we build prod, not god,' rejecting the mono-model narrative of existential doom in favor of practical software engineering. - [06:19](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=379s) Jev embeds intelligence natively into program execution loops as a primitive, labeling core inputs as state rather than handling conversational chat prompts. - [14:43](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=883s) Flashy AI demos that rely on cherry-picked outliers fail in production; real automation requires statistical guarantees and silent, unattended background execution. - [19:28](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1168s) Despite models achieving high benchmarks in mathematics and Google-proof question answering, basic real-world economic tasks like drive-thru ordering and helpdesk workflows remain unautomated. - [25:47](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1547s) Software reliability in probabilistic models requires moving past raw uptime and fragile literal determinism toward robust, consistently sensible intelligence that developers can trust without trial runs. - [29:01](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1741s) AI coding assistants excel at syntax generation but operate at roughly median 50th-percentile capability when designing software architecture. - [30:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1800s) Enterprise SaaS companies hold enduring moats through established customer distribution and proprietary domain workflows that code generators cannot easily clone. - [32:04](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1924s) Embedding intent-driven probabilistic reasoning eliminates legacy interface artifacts like multi-choice forms in favor of dynamic multimodal systems that decipher user intent. - [33:39](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2019s) Automating enterprise pull requests—which average only about 10 lines of code—optimizes a negligible phase of development without enhancing software capabilities. - [35:30](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2130s) Probabilistic programming is returning to low-level architecture, beginning with log analysis and optimistic routing before expanding toward durable storage and safety-critical systems. - [38:05](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2285s) Current autonomous agents and while-loops represent an engineering fallback forced by brittle prompt schemas and parsing errors rather than clean systems architecture. - [41:08](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2468s) The defining ambition of modern computing is realizing the 'do what I mean' (DWIM) anti-frustration ideal, enabling frictionless, reliable interoperability across software systems.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=0s) Teaser: "Where the F*** Is All the Automation?"

The discussion opens abruptly on the central paradox haunting modern artificial intelligence: for all of AI's staggering raw intelligence, real-world automated systems remain shockingly absent. As the speakers point out, it does not matter how many AI coding agents an engineering organization deploys—the software produced is not actually getting better; it is merely being written faster, and in many respects, it is arguably getting worse. OpenAI has attempted to automate customer support since 2020, yet genuine end-to-end automation remains elusive. Rather than aiming to replace humans with chatbots or chase grandiose artificial general intelligence, the mission should be building "smart software"—broadening what software itself is fundamentally capable of executing so that processes that ought to be automatable finally become automatable. As the hosts highlight, TypeSafe stands out against traditional frontier AI labs with an uncompromising builder's philosophy: *"we build prod, not god."*

[00:50](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=50s) Meet Diogo Almeida and TypeSafe AI

Ben Horowitz and Martin Casado introduce Diogo Almeida, founder and leader of TypeSafe AI, whom both hosts describe as a hero of theirs. Horowitz emphasizes that Almeida is not merely launching a compelling product with Jev, but catalyzing an essential philosophical movement across software engineering. When Almeida checks whether the room is "curse-friendly," Horowitz fires back with dry humor, and Almeida offers his blunt, favorite elevator pitch: *"Where the [f***] is all the automation?"*

Almeida reflects on the tragedy of having immense latent intelligence trapped in AI models that remain unpolished for production work. While he uses and appreciates chatbots and coding assistants, he finds it absurd how useless models remain outside those narrow niches. TypeSafe is designed specifically to make AI native to software itself—moving beyond human-in-the-loop chat interfaces to build reliable software primitives. Jev represents TypeSafe's first production model engineered specifically to unlock dependable, programmatic automation. Horowitz notes that Jev has already caught fire among software developers, prompting inbound calls from engineers raving about its speed, reliability, and utility.

```mermaid flowchart TD accTitle: Contrasting AI Code Generation with Native AI Software Primitives accDescr: Diagram contrasting how typical coding agents generate conventional code versus how Jev embeds intelligence directly into program state.

subgraph Traditional["Traditional AI Coding Agents"] direction TB A["Natural Language Prompt"] --> B["LLM Agent (Claude Code / Codex / Cursor)"] B --> C["Conventional Imperative Code"] C --> D["Runs standard static logic unchanged from 10 years ago"] end

subgraph TypeSafe["TypeSafe AI & Jev Approach"] direction TB E["Program State & Context"] --> F["Jev Intelligence Primitive"] F --> G["Probabilistic Classification & State Machine Decisions"] G --> H["Dynamic, Intent-Aware Autonomous Execution"] end ```

[04:07](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=247s) Smart Software vs. Just Faster Code

Casado and Horowitz challenge Almeida to contrast Jev with popular developer tools like Claude Code, Codex, or Cursor. Almeida references Garry Tan’s formulation of these tools as "just-in-time software"—systems capable of generating programs on the fly from natural language descriptions, yet fundamentally constrained by the exact same expressive boundaries that traditional software has had for decades. Almeida's objective is fundamentally different: rather than using AI to automate the typing of conventional code, he wants to build *smart software* by expanding software's internal vocabulary so that it can evaluate intent, navigate probabilities, and make autonomous decisions.

Casado underscores how profound this distinction is: coding assistants simply generate the exact same code a human engineer would have written ten years ago, whereas Jev acts as an entirely new primitive embedded *inside* the application's runtime. Instead of replacing software engineers with a marginally faster synthetic typist, Jev equips engineers with an intelligent component—similar to an integrated library or state machine—that accepts natural language specifications, inspects program state, and reliably executes actions with explicit confidence levels.

[06:19](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=379s) Classifiers, State Machines, and Intelligence per Dollar

Almeida laments that despite a decade of massive advancements in artificial intelligence, production software architectures have remained virtually unchanged, rarely amounting to more than static workflows with an unreliable chatbot awkwardly bolted onto the side. Translating probabilistic machine intelligence into the rigid world of deterministic bits requires disciplined compromise. On day one of onboarding, Almeida draws a Venn diagram of what AI does well versus what is actually valuable inside production code, focusing strictly on the intersection. Jev avoids outputs where neural networks stumble (such as extrapolating naked floating-point numbers) and instead leans into battle-tested computer science abstractions like classifiers and finite-state machines.

Almeida embraces the characterization of Jev as a classifier, noting that classifiers were historically engineered by pragmatic engineers to deliver reliable utility. He observes that Jev gives developers the equivalent of a dedicated 2019-era machine learning engineering team on demand, programmable on the fly without the overhead of manual data collection or bespoke training pipelines.

- **Internal design nomenclature:** Jev deliberately labels its core inputs as `state` to signal that it is built to operate directly inside program execution loops rather than processing external conversational prompts. - **North Star optimization metric:** Almeida prioritizes "intelligence per dollar" as his primary architectural benchmark, while acknowledging that "intelligence per second" (low latency) remains crucial for real-time systems. - **Architectural evolution:** While Almeida envisions intelligence eventually behaving like an in-memory standard library construct, current latency constraints place Jev closer to the performance profile of an ultra-fast operational database. - **Almeida’s background:** Prompted by Casado on the rare "alchemy" of thinking simultaneously like an AI researcher, a systems engineer, and a software programmer, Almeida jokes about how babies are made before revealing his roots as an award-winning competitive mathlete.

[09:36](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=576s) From Competitive Math to OpenAI: The Systems Engineer in the AI Mines

Diogo Almeida reflects with self-deprecating humor on his entry into technology, admitting with a laugh, "I was good enough at math to get girls. So, that's quite good." When Ben Horowitz and Martin Casado banter about what kind of girls one actually attracts with high-level math and suggest inspiring the youth, Diogo deadpans: "Don't do it. Youth, don't do it. It's not worth it. Just be cool and chill and interesting and don't overcompensate." He explains that while he was a competitive mathlete, he never truly loved pure mathematics; he was merely a "big fish in a little pond" who grew frustrated by the obsession with winning contests. Everything changed when he discovered computer science, which felt like "math but cool and useful and fun and interesting." To this day, he considers himself a computer scientist rather than an AI researcher, noting that he still loves conducting technical algorithms interviews because it lets him "sus people out really well."

His unconventional path into machine learning came through a Kaggle competition. Rather than relying on sophisticated theoretical math, Diogo won by approaching it strictly as a systems problem—"automating like the [fuck] out of it" through nested loops and raw compute orchestration. That victory caught the attention of the competition's organizer, pioneering researcher Isabelle Guyon (co-inventor and first author of the Support Vector Machine). Guyon recognized that Diogo was an outsider who did not fit the traditional academic research mold, took him under her wing, and pushed him onto the main stage at NeurIPS to present—an honor Diogo initially dreaded because he simply "wanted to be in the mines." Guyon introduced him to the broader AI research network, launching his career:

```mermaid flowchart TD accTitle: Diogo Almeida Career Progression accDescr: Flowchart tracing Diogo Almeida's journey from competitive math to Kaggle, Isabelle Guyon's mentorship, and OpenAI.

subgraph Phase1["Systems & Kaggle"] A["Competitive Mathlete<br/>('Math but cool & useful')"] --> B["Kaggle Victory<br/>(Nested loops & systems brute force)"] B --> C["Mentored by Isabelle Guyon<br/>(Forced to present at NeurIPS)"] end

subgraph Phase2["Industry Experience"] C --> D["Startup with Jeremy Howard"] D --> E["Google Brain"] E --> F["Temporary Retirement<br/>(Burnout & boredom)"] F --> G["OpenAI<br/>(Joined because 'AI is pretty damn fun')"] end ```

- **Early industry stops:** Following his introduction by Isabelle Guyon, Diogo co-founded a startup alongside fast.ai creator Jeremy Howard. - **Google Brain to OpenAI:** After working at Google Brain, Diogo briefly stepped away from the industry to retire. Growing restless and realizing that working in AI was "pretty damn fun," he joined OpenAI to work directly on frontier models.

---

[12:18](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=738s) "Build Prod, Not God": Rejecting the Mono-Model Kool-Aid

Ben observes that Diogo and TypeSafe AI hold a radically different demeanor from the prevailing gloom of the AI industry. While major lab leaders often appear burdened by existential dread and messianic visions, Diogo’s team operates under a distinct, grounded motto: "We build prod, not god." Instead of predicting mass unemployment or the replacement of humanity, Diogo champions an optimistic vision where software improvements create vastly more and better jobs. Ben remarks that while the rest of the industry seems somber, TypeSafe and its Jev developer community treat AI like an exhilarating movement where people are simply having a blast.

Diogo agrees with the characterization, explaining that traditional machine learning researchers often fixate on narrow classifier complaints while practical software developers are having a "Jev party" because they can finally build the capabilities they have dreamed of for years. The widespread pessimism in the field stems from what Diogo calls the "mono-model Kool-Aid"—the dogmatic belief that the future belongs to "one big brain to rule them all." He rejects this ominous monolith narrative, emphasizing that despite claims of impending superintelligence, the technology has yet to automate the most mundane, repetitive tasks that humans should not have to do in the first place. For Diogo, the tragic disconnect in AI has been the massive gap between high-level capability claims and actual real-world utility.

---

[14:43](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=883s) Where Is All the Automation? Reliability Over Demos

To illustrate how poorly basic tasks are automated despite billions of dollars of investment, Ben shares a conversation he had earlier that morning with David George, head of the a16z growth fund. When Ben asked him if he had tried a new autonomous agent tool called Muse, David enthusiastically reported his biggest breakthrough: "I finally canceled my New York Times subscription." While navigating dark patterns to cancel subscriptions is notoriously frustrating, Diogo points out that such tasks are merely the tip of the iceberg of horrible, manual chores that software should easily handle.

```mermaid flowchart LR accTitle: Demo Traps vs Production Automation accDescr: A comparison between demo-focused AI and production-grade programmable AI systems.

subgraph Demos["The AI Anti-Pattern (Fragile)"] D1["Cherry-Picked Outliers"] --> D2["Twitter/X Video Demos"] D2 --> D3["Pages on-call engineers / Breaks in prod"] end

subgraph Prod["The Jev Approach (Reliable)"] P1["Statistical Guarantees"] --> P2["Silent Background Execution"] P2 --> P3["Composable, Trusted Infrastructure"] end ```

Diogo argues that the AI field has repeatedly fallen into dangerous anti-patterns by optimizing for cherry-picked outliers and flashy social media demos rather than production software. When people ask him about his favorite AI use cases, he emphasizes that demos are meaningless if they cannot run reliably in the background: - **Trust without intervention:** A genuine automation tool must run unattended without paging on-call engineers when unexpected edge cases occur. - **Composability:** Software engineers must be able to treat model behaviors as composable building blocks that connect cleanly into existing system architectures. - **Statistical guarantees:** True agentic safety is not about theoretical alignment concerns; it is about providing engineering guarantees so that an autonomous program granted access to computing resources and API keys will not run rogue, exhaust budgets, or break production databases.

---

[16:58](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1018s) The Limits of RLHF and the Realization of What Comes Next

Martin recalls discussing these ideas with Diogo as early as 2017, when Diogo gave a presentation titled something like "AI: Modular in Theory and Flexible in Practice," demonstrating his long-standing software-first intuition. Diogo clarifies that while his architectural bias has always favored modularity, his core realization about the limitations of pure frontier models occurred in late 2021 during the development of RLHF (Reinforcement Learning from Human Feedback) leading up to ChatGPT.

When the OpenAI team was testing early RLHF models, Diogo was initially stunned by the model's unexpected generalization capabilities. Rather than writing a paper to hype their results, the team operated under rigorous scientific skepticism to prove the system was not simply cheating or regurgitating training corpora: - **The "Eat Socks" test:** To verify that the model was genuinely reasoning rather than memorizing internet text, the team tested obscure prompts that had zero previous web footprint, such as: *"Why is it important to eat socks before meditating?"* - **Plausible synthesis:** When the model successfully generated completely coherent, human-sounding justifications for an absurd, novel premise, the team realized RLHF had unlocked genuine generalization.

However, that initial breakthrough also caused Diogo’s greatest disillusionment. As an unabashed "capabilities guy" who helped push the model out, Diogo admits he genuinely believed RLHF scaling had a realistic chance of producing Artificial General Intelligence (AGI). When the paradigm hit clear walls and failed to turn into an all-capable autonomous system, his world came crashing down. He began critically re-evaluating the mechanics of learning systems, recognizing that while RLHF generalises surprisingly well across open domains, methods like RLVR (Reinforcement Learning with Verifiable Rewards) struggle with broad generalization, cementing his conviction that intelligence must be architected as reliable, deterministic software rather than relying entirely on a monolithic black-box brain.

[19:28](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1168s) Overpromising, Underdelivering, and the AGI Paradox

Diogo Almeida reflects on the culture at early OpenAI around 2020, where the definition of AGI was often colloquially summarized as "Ilya in every if statement." In Almeida's view, OpenAI kept the definition intentionally broad and vague so it could serve as a big tent for everyone. While he remains skeptical of recursive self-improvement (RSI), he believes OpenAI's core stated goal—automating the majority of economically valuable tasks—should be completely feasible. Much of human labor consists of simple, rote, volume-driven instructions that can be outsourced to everyday workers, and the raw baseline intelligence needed to do that has existed in language models for years.

Almeida notes a nagging frustration: since the widespread adoption of RLHF (reinforcement learning from human feedback), the AI industry has bifurcated into massive overpromising and underdelivering. Back in the era of GPT-3, models felt more calibrated. But because human evaluators judge outputs, models have been optimized to impress the human judge rather than perform actual end-to-end task automation. For Almeida, the inability of modern systems to perform real-world tasks is the canary in the coal mine:

> "Are you really telling me that we... math is solved or like even like 2 years ago GPQA, that Google-proof question answering is solved, but we still can't handle a drive-thru, 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."

[21:52](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1312s) The Real-World Data Distribution vs. Engineering Pragmatism

Martin Casado pushes back with a counter-hypothesis: the physical and human world might simply belong to a different distribution than digital domains like math and code. It is heavy-tailed, messy, full of edge cases, and lacks sufficient training data, which could explain why AI has succeeded on lower-dimensional manifolds while struggling with real-world execution. Almeida concedes the long tail exists, but rejects lack of data as an excuse for failing to automate basic tasks. Reliable software is fundamentally an ROI decision, harkening back to Larry Wall’s classic three virtues of a programmer (laziness, impatience, and hubris)—spending 10 hours engineering a tool just to handle a 5-minute task instantly without ever repeating it.

Casado notes that prior to generative AI, help desk automation startups would boast about answering 95% of incoming tickets, only for closer inspection to reveal that virtually all of those tickets were simple password resets, while unique problems saw resolution rates closer to 50%. The long tail of human exceptions repeatedly derailed projects. Inside modern enterprises, virtually nothing has actually been automated by AI yet—with the notable exception of programming itself.

The conversation turns to the release of Jev, whose name nods to the Jevons paradox (that increased efficiency breeds entirely new demand and kinds of work). Almeida admits he was stunned by the explosive reception. Neither he nor anyone else could have predicted a developer tool sparking a viral consumer-style frenzy, where even non-engineers join the "Jev party" on Twitter to share memes.

```mermaid flowchart TD accTitle: The Reliability Spectrum in Software Intelligence accDescr: Progression from basic network availability to true programmatic intelligence in Jev.

subgraph Infrastructure["Infrastructure Layer"] A["Availability / Uptime"] --> B["Basic SLAs"] end

subgraph DeterminismLayer["Traditional Execution"] B --> C["Strict Determinism<br/>(Unit Tests Only)"] C --> D["Robustness<br/>(Similar intelligence under variable inputs)"] end

subgraph CognitiveLayer["Jev Programmability"] D --> E["Reasonable Intelligence<br/>(Every execution step is sensible)"] E --> F["Zero-Shot Developer Trust<br/>(Coding without trial runs)"] end ```

[25:47](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1547s) Defining Reliability: Chasing the "Nines"

For Almeida, the core technical breakthrough of Jev is an obsessive focus on reliability rather than leaderboard benchmarks. When Casado asks whether reliability in stochastic models means uptime, availability, or output determinism, Almeida delineates three distinct tiers:

- **Availability / Uptime (SLAs):** Simple infrastructure readiness—necessary, but not what makes software work. - **Determinism vs. Robustness:** Exact determinism is helpful for unit tests, but fragile in real-world systems. For example, injecting a unique UUID into a prompt should not break functional behavior even if the literal tokens change. Robustness means delivering an equivalent caliber of intelligence regardless of minor perturbations. - **Consistent Intelligence:** The system must act intelligibly and smartly every time, producing output that an engineer can anticipate and handle predictably.

Almeida states that the ultimate measure of reliability will be when developers write code against Jev without having to test example queries first:

> "To me the highest honor of reliability will be to get to the point where people can program against Jev without making example queries. Like when you just trust it, you'll be in like pure flow state."

Casado then asks whether a primitive as powerful as Jev reduces the value of external coding agents. If human programmers can use a generalized intelligence primitive to write software directly, will coding agents orchestrate Jev under the hood, or will humans stay firmly at the wheel? Almeida chuckles that he spends less time in the coding trenches than he would like, deferring on agent mechanics while focusing firmly on the primitive itself.

[29:01](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1741s) Syntax, Semantics, and 50th-Percentile Architecture

The conversation turns to the real-world utility and limitations of current AI coding assistants. Diogo Almeida highlights a sharp divide in their capabilities: while modern models excel at syntax, they struggle with semantics and remain "incredibly bad at architecture." To Diogo, architecture represents the most distinctly human and creative dimension of software engineering. He uses coding agents regularly, but notes that TypeSafe's product Jev is almost certainly out-of-distribution for current models—joking that it would be "spooky if they trained on our user data." When a codebase falls squarely within training distributions, offloading syntax generation to an agent is straightforward.

When it comes to architectural design, Diogo offers a nuanced defense of where agents currently land. Rather than being utterly useless, models might realistically operate at roughly the "50th percentile" of architectural capability. For teams without senior architectural expertise, a median-grade architecture is often entirely acceptable. Engineering leadership constantly navigates these trade-offs: sometimes sheer development velocity is the primary dial to turn. A startup may deliberately accept a 50th-percentile architectural scaffold over a meticulously crafted 60th-percentile one if it means letting an agent like Codex work overnight to ship features faster.

[30:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1800s) The SaaS Apocalypse Inverted: "SaaSPalooza"

Ben Horowitz contrasts early market hysteria with the industry's actual response to Jev. When coding agents first surfaced, public markets anticipated a devastating "SaaS apocalypse," crashing software multiples under the assumption that software was suddenly trivial and cheap to clone. Yet when Jev arrived, established enterprise SaaS vendors embraced it as a massive breakthrough. Diogo explains that the thesis of software being effortlessly replicated fell apart because it overlooked the immense complexity running beneath the hood. While generating code has become cheap, replicating the intricate business logic and domain knowledge embedded in existing systems remains extremely difficult.

```mermaid flowchart TD accTitle: The SaaS Evolution from Apocalypse to Capability Expansion accDescr: Diagram illustrating how SaaS companies shift from the fear of code commoditization to capturing value through embedded probabilistic capabilities.

subgraph FalseNarrative["The 'SaaS Apocalypse' Fallacy"] A["Coding Agents Emerge"] --> B["Cheap Syntax & Code Generation"] B --> C["Assumption: Software is Easily Cloned"] end

subgraph RealAdvantage["The Inverted Apocalypse (SaaSPalooza)"] D["Entrenched SaaS Platforms"] --> E["Proprietary Domain Workflows & Distribution"] E --> F["Embedded Intelligence Primitives (Jev)"] F --> G["High-Value Workflow Automation & Superior UX"] end ```

Diogo argues that far from being dismantled, established SaaS platforms will be among the greatest beneficiaries of the AI wave. The biggest, most dependable, and seemingly "boring" SaaS companies are uniquely positioned because they already understand customer pain points and control the workflows people rely on daily. Software has always required upfront capital expenditure, but incumbent vendors can leverage their existing distribution to deploy upgraded, intelligent capabilities instantly to massive customer bases. Diogo terms this dynamic an "inverse apocalypse," prompting Ben Horowitz to jokingly dub the upcoming boom "SaaSPalooza."

- **The SaaS Moat:** The primary capital cost of enterprise SaaS is acquiring customers and mapping their nuanced operational workflows, a barrier code generators do not diminish. - **Workflow Knowledge:** Incumbents already possess the domain context required to determine which business actions are worth automating.

[32:04](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1924s) Eliminating Forms and Voice-Controlled Interfaces

Ben Horowitz points out that the true leverage for SaaS companies lies in making their core product fundamentally more capable rather than merely tacking on superficial chat interfaces. Diogo shares his vision of doing away with static user-interface artifacts entirely—specifically predicting the death of multi-choice selection forms. In Diogo's view, form fields are merely primitive translation mechanisms designed to force natural human context into structured data. Martin Casado observes that this form-driven paradigm dates back to the 1980s Fourth-Generation Languages (4GLs).

Removing these rigid legacy inputs opens up dynamic, multimodal interactions that execute true "do what I mean" computing. Diogo highlights a compelling community project built on Jev: a voice-controlled operating system interface. Rather than relying on rigid command syntaxes or manual switching, the software continuously listens to spoken input and probablistically determines whether the user is issuing a desktop command or dictating text into an active application, figuring out the target context on the fly. Martin remarks that once software can arbitrate intent at that fidelity, "Then you're at Star Trek."

[33:39](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2019s) Beyond the 10-Line PR: Adding New Capabilities to Software

Martin Casado reflects on an internal study examining software development inside large technology enterprises. The study revealed that the average pull request (PR) across large organizations is only about 10 lines of code, usually representing a minor adjustment derived from customer feedback. Coding agents only automate the typing of those 10 lines—optimizing an already minor portion of the engineering lifecycle while often producing less-vetted or more insecure code. Crucially, faster code generation does not make the underlying software product any better or grant it new capabilities.

Jev introduces a completely different paradigm by giving software a new foundational primitive: embedding natural language understanding and probabilistic reasoning directly alongside deterministic state machines. Diogo explains that if the industry comes to see Jev as expanding computing beyond traditional Boolean logic gates (AND, OR, NOT) into a logic gate that incorporates "a little brain in there," it would be the ultimate compliment to TypeSafe’s mission. While acknowledging that comparing their work to fundamental hardware gates sounds remarkably bold, Diogo emphasizes that this shift from external code generation to internal probabilistic decision-making is precisely the vision TypeSafe is fighting to deliver.

[35:30](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2130s) Probabilistic Programming and Rebuilding Systems

The conversation turns to how deeply probabilistic logic can reach into low-level systems architecture. Martin questions whether non-deterministic primitives can eventually support mission-critical guarantees around state consistency, durability, and core storage engines, transforming databases and even safety-critical domains like air traffic control. Diogo advocates a pragmatic rollout—automating low-stakes, operational workflows like log processing and email routing before touching brittle, safety-critical infrastructure.

```mermaid flowchart LR accTitle: Spectrum of Probabilistic Integration in Systems Architecture accDescr: Flowchart illustrating the evolution of AI integration from peripheral applications down into core systems and optimistic routing.

subgraph Phase1["Near-Term: Interface & Log Layers"] UI["UI Mediation & Forms"] Logs["Log & Email Analysis"] end

subgraph Phase2["Mid-Term: Adaptive Infrastructure"] Route["Optimistic Systems Routing"] SmartDB["Probabilistic Data Management"] end

subgraph Phase3["Far Horizon: Safety-Critical Systems"] Core["Durability & State Guarantees"] ATC["Air Traffic & Life-Critical Systems"] end

Phase1 --> Phase2 Phase2 --> Phase3 ```

This evolution marks the rebirth of probabilistic programming, a discipline that Martin notes largely languished after its early development in the 1970s. Diogo emphasizes that his core design philosophy is "incredible pragmatism," expressing skepticism toward biologically inspired computing concepts. While biological analogies historically motivated researchers to persist for decades until breakthroughs occurred—such as the hierarchical feature representations that made deep convolutional networks and ResNets viable—engineering ultimately requires deterministic utility. Martin concludes that the software industry is entering an era akin to the migration from mainframes to client-server or the dawn of the commercial Internet: an inflection point where introducing a fundamentally new primitive compels engineers to redesign systems from the ground up.

- **Historical Parallels:** The transition to probabilistic system design mirrors past architectural shifts, including mainframe-to-client-server migrations and Internet-native architectures. - **Extreme Systems Trade-offs:** Future low-level infrastructure may employ small, high-speed models purely for optimistic routing and heuristic guesses, leaving comprehensive reasoning engines like Jev for complex application layers.

[38:05](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2285s) Apps vs. The Guts of Systems: Moving Past "Ships in the Night"

Addressing whether the modern software stack needs to be fundamentally rebuilt to be safe for AI, Martin Casado asks Diogo Almeida how he envisions the ultimate footprint of Jev: will it manifest primarily in user-facing SaaS applications and analytics, or deep down in the foundational systems plumbing? Almeida immediately points toward the lowest levels of infrastructure, drawing an analogy to foundational networking protocols like TCP and UDP—a comparison that immediately resonates with Casado ("speaking my language"). Almeida explains that he developed his product conviction by working backward from the sci-fi vision of an AI-driven economic revolution where intelligence permeates all software. When breaking that future down into sheer function calls, he concluded that only a minuscule fraction of AI interactions will ever be meant for direct human consumption requiring prose, style, and tone. Instead, "many nines" of all AI calls will occur deep in the internal guts of computing systems. While adoption inevitably begins at the outer user layer, Almeida argues that if engineers do not deliberately design for the deep plumbing from day one, reaching genuine automation will take an excruciatingly long time.

Historically, AI and core software systems have behaved like "ships in the night." Traditional software operates deterministically and cannot naturally digest conversational, unstructured text. When developers attempted to force large language models into software pipelines, the integration broke down: engineers would cram strict schema requirements into system prompts, demanding JSON outputs, only for the models to ignore formatting constraints. Out of sheer exhaustion, developers surrendered to the unreliability ("the hell with it") and routed outputs either directly to a human reviewer or into an ad-hoc agentic while-loop that fed natural language back into another LLM. Casado notes that watching developers grapple with AI has looked like the "five stages of grief"—cycling from initial excitement to denial, anger, and finally resigned acceptance, abandoning programmatic integration in favor of chat interfaces or fragile agent loops. Jev represents the first paradigm shift Casado has seen where an LLM is cleanly mapped to a reliable state machine, enabling productive, deterministic software execution.

```mermaid flowchart TD accTitle: Evolution of AI Integration in Software accDescr: Comparison between fragile prompt-and-while-loop architectures and deep state machine integration.

subgraph Fragile["Fragile 'Ships in the Night' Pattern"] A["LLM Prompt"] -->|"Schema Drift / Parse Failure"| B{"Broken Output"} B -->|"Fallback 1"| C["Human in the Loop (Chat UI)"] B -->|"Fallback 2"| D["Agent While-Loop (LLM to LLM)"] end

subgraph DeepGuts["Jev State Machine Architecture"] E["Deep Systems Guts"] --> F["Jev Probabilistic Engine"] F -->|"High-Reliability Decisions"| G["Deterministic State Transitions"] end ```

- **The Deep Guts Ratio:** Almeida anticipates that mathematically, "many nines" (99.999%+) of future AI calls will execute invisibly inside foundational systems rather than in human-facing user interfaces. - **The Agentic While-Loop:** The prevailing concept of autonomous agents is diagnosed as an admission of failure—a while-loop necessity born because software cannot reliably ingest natural language without recursive re-prompting. - **The Five Stages of Grief:** Casado categorizes the tech industry's attempts to incorporate AI into standard codebases as moving through denial and anger before settling on human-in-the-loop chat as a reluctant compromise.

---

[41:08](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2468s) Reliability and the "Do What I Mean" Anti-Frustration Machine

Conscious of the pervasive hype surrounding artificial intelligence, Almeida emphasizes that he refuses to overpromise and underdeliver. While he cannot guarantee that current models can immediately satisfy every exaggerated claim circulating in the tech ecosystem, his team at TypeSafe AI has prioritized mathematical and operational reliability above all else. TypeSafe deliberately delayed releasing Jev, choosing to iterate in private to guarantee bedrock dependability rather than rushing an unready framework out the door. Almeida suspects that the broader developer public, particularly the loud discourse on Twitter, may not fully appreciate the underlying theoretical mechanics that make Jev work; instead, developers will simply register the practical sensation of trust: "it'll just have like that good vibe of like, oh, I can trust this."

The hosts characterize this breakthrough as the ultimate "anti-frustration machine," a description Almeida enthusiastically embraces. For him, the entire endeavor centers on achieving the classic computing holy grail: technology that can reliably "do what I mean" (DWIM). He envisions an AI utopia defined by global smoothness, where diverse software tools, platforms, and workflows interlink seamlessly like precision gears without friction or brittle glue code. With models already possessing extraordinary baseline intelligence, having computing systems that accurately interpret human intent and execute it flawlessly should no longer be relegated to science fiction. Ben Horowitz and Martin Casado agree, concluding that turning "do what I mean" into a tangible software reality is the defining ambition of the current computing era.

- **Delayed Launch for Reliability:** TypeSafe AI intentionally withheld Jev from early public release to solve the underlying reliability problem, avoiding the common trap of shipping brittle, prompt-engineered prototypes. - **The "Anti-Frustration" Philosophy:** Rather than forcing developers to debug hallucinated schemas or manage non-deterministic edge cases, Jev is architected to eliminate the friction between programmatic intent and machine execution. - **The "Do What I Mean" (DWIM) Utopia:** Almeida views genuine intelligence inside software as an engine for world smoothness, where disparate digital systems finally interact fluidly without brittle middle layers.

## Notable quotes > [00:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=0s) Where the f*** is all the automation? — Diogo Almeida

> [00:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=0s) we build prod, not god. — Diogo Almeida

> [09:36](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=576s) Don't do it. Youth, don't do it. It's not worth it. Just be cool and chill and interesting and don't overcompensate. — Diogo Almeida

> [16:58](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1018s) Why is it important to eat socks before meditating? — Diogo Almeida

> [19:28](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1168s) Are you really telling me that we... math is solved or like even like 2 years ago GPQA, that Google-proof question answering is solved, but we still can't handle a drive-thru, 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. — Diogo Almeida

> [14:43](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=883s) I finally canceled my New York Times subscription. — David George

> [25:47](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1547s) To me the highest honor of reliability will be to get to the point where people can program against Jev without making example queries. Like when you just trust it, you'll be in like pure flow state. — Diogo Almeida

> [32:04](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1924s) Then you're at Star Trek. — Martin Casado

> [41:08](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2468s) it'll just have like that good vibe of like, oh, I can trust this. — Diogo Almeida

## Mentioned Ben Horowitz, Martin Casado, Diogo Almeida, TypeSafe AI, Jev, OpenAI, Claude Code, Codex, Cursor, Garry Tan, Isabelle Guyon, Jeremy Howard, Google Brain, NeurIPS, David George, Muse, The New York Times, Larry Wall, ChatGPT, GPQA

## 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.”

Timestamps: 00:00 - Intro 00:50 - Meet Diogo and Type Safe 04:07 - Smart software, not just faster code 15:46 - Where's all the automation? 22:00 - Is it just a data problem? 30:21 - SaaS apocalypse, reversed 34:58 - New capabilities, not more code 38:27 - Apps vs the guts of systems 41:08 - Reliability and "do what I mean"

Resources: Follow Diogo Almeida: https://x.com/CompleteSkeptic Learn more about TypeSafe AI: https://typesafe.ai/ Follow TypeSafe AI: https://x.com/typesafeai Follow Ben Horowitz on X: https://x.com/bhorowitz Follow Martin Casado on X: https://x.com/martin_casado

Stay Updated: If you enjoyed this episode, be sure to like, subscribe, and share with your friends!

Find a16z on X: https://twitter.com/a16z

Find a16z on LinkedIn: https://www.linkedin.com/company/a16z

Listen to the a16z Show on Spotify: https://open.spotify.com/show/5bC65RDvs3oxnLyqqvkUYX

Listen to the a16z Show on Apple Podcasts: https://podcasts.apple.com/us/podcast/a16z-podcast/id842818711

Follow our host: https://x.com/eriktorenberg

Please note that 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. a16z and its affiliates may maintain investments in the companies discussed. For more details please see http://a16z.com/disclosures.

[Source](https://www.youtube.com/watch?v=Ut3LOjKNJaE)

中文简报

TypeSafe推出Jev,将概率逻辑嵌入软件状态 真正的工作流自动化陷入停滞,因为编程智能体仅加速了标准代码的生成,而未能将可靠的概率决策直接嵌入到应用程序运行时中。 TypeSafe AI创始人Diogo Almeida对传统的AI范式提出质疑,认为编程助手只是加速了传统脆弱软件的构建,而未能从根本上拓展软件的能力边界。为了解决现实世界中自动化长期缺失的问题,TypeSafe开发了Jev——这是一种利用分类器和有限状态机等可靠抽象将概率智能直接嵌入程序执行的原语。在“我们构建生产系统,而非造神”(we build prod, not god)的旗帜下,Almeida与主持人摒弃了前沿实验室弥赛亚式的悲观论调,阐释了可靠且意图驱动的原语将如何革新深层系统基础设施,将令人担忧的“SaaS末日”转变为老牌巨头的狂欢机遇,并实现真正“按我意图行事”(do what I mean)的计算模式。 TypeSafe AI推出了Jev,这是一种生产级智能原语,旨在将概率分类和意图感知决策直接嵌入软件运行时内部,而非单纯依靠编程智能体生成传统代码。 (0:50) Diogo Almeida认为,此前预期的“SaaS末日”正在逆转为“SaaS狂欢”(SaaSPalooza),因为根基深厚的老牌企业平台掌握着将嵌入式AI商业化所需的核心领域知识、分发渠道和精细工作流。 (30:00) 未来的软件栈不会依赖脆弱的提示词工程或临时搭建的智能体while循环来解析非结构化文本,而是在底层深层基础设施和状态机内部无形运行具备“多个9”高可用性的AI函数调用。 (38:05) RLHF和RLVR的发展揭示了关键的局限性:尽管模型表现出广泛的开放领域泛化能力,但在可靠执行现实世界任务方面依然吃力,使得工程可靠性成为实现端到端自动化的主要瓶颈。 (16:58)

Reading summary

TypeSafe AI founder Diogo Almeida and a16z partners Ben Horowitz and Martin Casado argue that artificial intelligence has failed to produce widespread automation because the industry treats models as conversational chatbots or code generators rather than native software primitives. They contend that real-world automation requires embedding reliable probabilistic classifiers and state machines directly into the execution loops of production systems. Smart Software Over Faster Code Generation (4:07) Almeida distinguishes developer tools like Cursor, Codex, and Claude Code—which Garry Tan termed 'just-in-time software'—from genuine smart software. While coding assistants generate conventional code faster, Casado notes that enterprise pull requests average only about ten lines of code; automating those keystrokes merely reproduces decade-old static architectures without expanding software's intrinsic capabilities. Almeida argues this dynamic can even degrade codebases by encouraging unvetted code generation. Instead of deploying AI as an external synthetic typist, TypeSafe's model, Jev, functions as an internal runtime primitive. Framing intelligence as a classifier or state machine allows the system to inspect internal program state and execute decisions based on explicit confidence thresholds. Almeida optimizes for 'intelligence per dollar' and low latency, forecasting that intelligence primitives will evolve from the performance profile of fast operational databases into standard in-memory programming libraries. The Limits of RLHF and Monolithic AGI (16:58) Almeida rejects the prevailing industry assumption that a single monolithic model will soon solve all economic tasks, terming this belief the 'mono-model Kool-Aid.' He points out that despite frontier models mastering benchmarks like GPQA, AI systems still struggle to automate mundane physical workflows such as fast-food drive-thrus. Reflecting on his work at OpenAI during the early development of Reinforcement Learning from Human Feedback (RLHF) in 2021, Almeida notes that while the team proved genuine generalization using novel prompts like eating socks before meditation, RLHF ultimately optimized models to impress human judges rather than execute reliable background automation. Furthermore, Almeida observes that while RLHF generalizes across open domains, methods like Reinforcement Learning with Verifiable Rewards (RLVR) struggle with broad generalization. This limitation led him to abandon expectations of near-term artificial general intelligence in favor of engineering composable, dependable software, encapsulated by TypeSafe's motto: 'we build prod, not god.' Replacing Fragile Agent Loops with Concrete Reliability (25:47) Almeida and Casado criticize modern autonomous agents, characterizing recursive 'agentic while-loops' as an admission of architectural failure. In typical pipelines, developers attempt to enforce strict JSON schemas on large language models; when the models inevitably produce formatting errors, engineers either fall back to human review or route outputs into fragile loops. Almeida warns that optimizing for cherry-picked video demos fosters fragile prototypes that fail unpredictably and page on-call engineers. True agentic reliability requires statistical guarantees that prevent autonomous code from exhausting API budgets or corrupting production databases. Almeida delineates reliability into three tiers: baseline uptime availability, robustness against superficial input changes (such as injected UUIDs), and predictable cognitive execution. He defines the ultimate benchmark of developer trust as a 'flow state' where software engineers program against an intelligence primitive without having to run exploratory trial queries. Enterprise Workflows and Deep Systems Plumbing (30:00) Horowitz and Almeida challenge public market assumptions of a 'SaaS apocalypse,' which presumed coding agents would make enterprise software trivial to clone. Almeida argues the opposite: incumbent SaaS vendors hold powerful moats rooted in complex domain logic and customer distribution. By integrating primitives like Jev, software providers can eliminate rigid 1980s-era interface artifacts like multi-choice selection forms in favor of dynamic, intent-driven interactions, such as voice systems that automatically distinguish between desktop commands and transcribed dictation. Architecturally, Almeida forecasts that 'many nines' of all future AI calls will execute invisibly deep within computing plumbing—akin to networking protocols like TCP and UDP—rather than in conversational user interfaces. While Casado views this transition as an architectural reset comparable to the shift from mainframes to client-server systems, Almeida urges pragmatism: developers should deploy probabilistic reasoning in lower-stakes operations like log processing and email routing before attempting to re-architect safety-critical database or transport layers. The source concludes that realizing computing's long-standing 'do what I mean' ideal requires transitioning from conversational AI interfaces to disciplined, probabilistic systems engineering. However, Almeida emphasizes that this transformation remains constrained by latency and reliability boundaries, noting that extending non-deterministic logic into mission-critical or life-safety infrastructure remains an unresolved frontier that depends on proving out lower-stakes operational systems first.

精炼阅读摘要

TypeSafe AI 创始人 Diogo Almeida 与 a16z 合伙人认为,当前人工智能领域充斥着过度炒作与演示陷阱,真正的自动化应当摆脱单纯的代码补全或聊天机器人,将确定性状态机与概率分类能力嵌入软件深层架构之中。 自动化停滞与代码生成的局限 (0:00) 尽管大型语言模型展现出惊人的原始推理能力,但现实世界中的真正自动化依然普遍缺失。Ben Horowitz 与 Diogo Almeida 指出,虽然 Cursor、Claude Code 等辅助编程工具大幅提升了代码编写速度,但软件本身并未变得更好,只是在以更快的速度生成与十年前结构无异的传统命令式逻辑。早在 2020 年 OpenAI 就尝试端到端自动化客服,但至今即便像取消订阅这类日常繁琐流程仍难以全自动处理。大模型开发者普遍通过强化学习(RLHF)迎合人类裁判的偏好,导致宣传承诺与实际落地效能之间出现严重断层。 状态机与原生智能原语 (4:07) Almeida 认为,打破僵局的关键不在于追逐虚无的通用人工智能(AGI),而在于践行“做生产级软件,而非造神”(we build prod, not god)的工程哲学。TypeSafe AI 推出的模型 Jev 放弃了让神经网络直接外推浮点数等脆弱设计,转向计算机科学中成熟的分类器与有限状态机。Jev 将输入明确定义为“状态”(state),使其能直接嵌入程序的执行主循环,作为类似内置库或数据库的基础原语运行。与传统 LLM 因格式漂移迫使工程师采用“智能体循环”(agentic while-loop)递归重试不同,Jev 为状态转移提供确定性的工程保障与置信度,让开发者无需先行测试样例文本就能建立调用信任。 SaaS的反向繁荣与界面重构 (30:00) 公开市场曾因编程智能体的兴起而担忧出现软件贬值的“SaaS 末日”,但 Horowitz 与 Almeida 均指出实际情况演变成了“SaaS 狂欢”(SaaSPalooza)。成熟的 SaaS 企业拥有深厚的业务工作流和客户护城河,这些深层逻辑无法被代码生成器轻易复刻。借助 Jev 这样的概率原语,SaaS 厂商能够消灭自 1980 年代第四代编程语言(4GL)延续至今的多选表单,转向真正理解意图的交互系统。例如社区基于 Jev 构建的语音控制系统,能实时以概率方式判断用户是在输入系统指令还是在应用中听写文本,实现了即时意图仲裁。 底层基础架构的重构路径 (35:30) 面向未来架构,Martin Casado 与 Almeida 预测绝大多数(“多个 9”以上)的 AI 调用绝非面向人类的自然语言生成,而是静默发生于类似 TCP/IP 协议栈的系统底层管道中。Almeida 主张采取极其务实的工程路线,首先在日志分析、邮件分拣等容错率较高的运维层落地,随后演进至轻量模型驱动的系统乐观路由,最终审慎迈向空中交通管制或数据库持久化等严苛的安全关键型系统。这标志着沉寂数十年的概率编程重新复兴,促使软件工程从单纯的布尔逻辑(与、或、非)向内嵌推理单元的混合系统演进。 TypeSafe AI 试图通过高可靠性的分类与状态机原语解决 AI 落地中的工程信任问题,但该方案最终能否从上层界面与运维自动化顺利下沉至安全关键型底层系统,仍取决于概率逻辑对极端状态一致性的工程保障能力。

Detailed notes — zh

## Background 该内容由知名风投机构 a16z 于 2026 年 9 月 28 日在 YouTube 平台发布。页面简介显示,a16z 合伙人 Ben Horowitz 与 Martin Casado 邀请 TypeSafe AI 创始人 Diogo Almeida 展开对谈,探讨当今 AI 虽然极度强大但自动化却迟迟未落地的核心痛点,并深入解析 TypeSafe 如何通过其新模型 Jev 将推理与概率决策直接注入软件底层,开启全新的概率性软件时代。 ## TL;DR 对话直击当今 AI 行业的荒谬现状:写代码的 Agent 大行其道,现实业务的自动化却依然举步维艰,原因在于行业过度执迷于用 AI 生成传统死板代码或打造拟人化的单体神明。TypeSafe 创始人 Diogo Almeida 提出“为软件本身打造 AI”(AI for software)和“做生产工具,不负责造神”的理念,推出直接面向软件内部状态机的全新计算原语 Jev。他指出未来 99.999% 以上的 AI 调用都将深埋在系统的底层“内脏”中,而非停留在表层聊天窗口;AI 不仅不会引发所谓的 SaaS 灭顶之灾,反而会通过注入确定性的概率推理让既有软件实现质的跃迁。团队通过死磕工业级可靠性,终结传统 LLM 与软件管线之间的摩擦,最终实现让机器与系统精准“做我所想”(Do What I Mean)的深层自动化。 ## Atmosphere & style 整场对谈兼具硬核工程极客的清醒犀利与老友重聚般的幽默松弛,充斥着快节奏的妙语连珠、爆笑调侃与直言不讳的行业解毒剂。两位资深投资人与经历过 OpenAI 早期研发的 Diogo 意气相投,从数学竞赛的自嘲、退订报纸的荒唐现实一路切入到 TCP 协议和状态机等系统底层。不同于时下 AI 峰会上普遍弥漫的沉重宿命论或浮夸宣传,现场洋溢着一种脚踏实地、专注把事情做成的工程乐观主义,听众能深刻感受到那种剥除概念泡沫后、直击真实软件生产一线的畅快与踏实。 ## Bulletin - [00:52](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=52s) TypeSafe 推出首款基础模型 Jev,主打将推理与概率决策直接植入软件内核,提出“做生产工具而非造神(We build prod, not god)”,推动传统代码向具备意图理解能力的智能软件转型。 - [30:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1800s) 针对“SaaS 灭顶之灾”论调,Diogo 指出软件核心壁垒在于底层系统、状态维护与客户分发,具备高可靠推理的智能原语不仅不会颠覆现有 SaaS,反而将带来以存量厂商为主导的“SaaS Palooza”能力大爆发。 - [38:05](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2285s) 访谈直击当下 AI 强大但实际自动化缺位的行业痛点,指出未来 99.999% 以上的 AI 调用都将深埋于系统的底层“内脏”中负责机器级决断,而非浅层的 Chatbot 或仅会写语法的编码 Agent。 - [39:47](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2387s) Jev 将大模型严密映射至确定性状态机,消除工程师在非结构化输出中打补丁的挫败感,通过追求高稳健性与类人一致逻辑,实现“做我所想”(Do What I Mean)的可靠工程体验。 ## Key takeaways - [02:28](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=148s) 突破“即时软件”局限:代码生成助手虽然能实时编写代码,但生成的软件在表达力上限上与十年前无异,真正的变革在于将“人类意图”与概率决策纳入软件自身的基础词表。 - [04:25](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=265s) Jev 作为全新软件原语:传统编程受限于确定性布尔逻辑,Jev 允许开发者通过自然语言定义目标,为程序提供状态机并在运行时依据置信度自主做出概率决策。 - [06:19](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=379s) 务实的分类器胜过复杂的黑盒:Jev 专注于结构化概率判断,开发者如今仅凭数行配置即可调用超越 2019 年整支专业机器学习团队耗费数月交付的决策能力。 - [07:41](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=461s) 以“每美元智能”为北极星指标:Jev 将接口明确命名为“状态”,旨在与系统深层状态管理无缝咬合,目前架构定位接近高吞吐的智能数据库,长远目标是成为像标准库一样的通用基构。 - [11:44](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=704s) “做生产工具,不负责造神”:TypeSafe 摒弃单一大脑统治一切的 AGI 宏大叙事,聚焦于真实生产环境中能稳定在后台静默运行、具备可组合性与统计级保证的工程基石。 - [14:14](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=854s) 真实世界自动化落地的巨大落差:当前 AI 模型在纯数字基准中表现惊艳,但在退订报纸、汽车餐厅点单等现实基础劳动上仍屡屡受挫,行业过度陷入由 Demo 驱动的展示陷阱。 - [16:58](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1018s) RLHF 带来的泛化启示与 AGI 幻灭:Diogo 在 OpenAI 期间通过“冥想前吃袜子”等反常识用例确证了 RLHF 的真实泛化能力,但也深刻意识到单纯扩大模型规模无法直接解决系统可靠性与自主自动化问题。 - [24:49](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1489s) 重审大模型时代的可靠性:可靠性不仅是 SLA 或绝对幂等输出,核心在于模型无论具体措辞如何,都能在逻辑深度上维持“同等水准的聪明”,让开发者进入免于试探的心流状态。 - [29:01](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1741s) 编码智能体擅长语法而不懂架构:当前代码生成模型仅在分布内的语法实现上表现优异,但在系统语义与最需独创性的顶层架构上依然极其薄弱,大公司 PR 平均仅改动 10 行代码的现实证明仅靠生成代码无法改变软件本质。 - [30:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1800s) 逆转 SaaS 灭绝论与迈向 SaaS Palooza:软件生产成本降低不会消灭 SaaS,老牌厂商凭借客户分发渠道和深水区业务工作流,结合 Jev 类内核智能可彻底淘汰传统多选表单,迎来价值跃迁。 - [35:30](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2130s) 概率性编程的系统级重构机遇:从客户端-服务器到分布式架构,具备推理能力的全新逻辑门将推动整个计算机栈从表层 UI、日志分析逐步向具备强持久性与一致性的底层系统深度重写。 - [38:05](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2285s) AI 调用的大多数终将深埋在系统“内脏”:面向终端用户的对话与文本生成仅占不足 0.001%,未来 99.999% 以上的 AI 交互都将发生在机器对机器的系统核心逻辑与状态流转之中。 - [39:47](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2387s) 终结接入 AI 的“悲伤五阶段”与践行 DWIM:传统工程师在 Prompt 打补丁与 Agent 死循环纠错间妥协;通过将模型与确定性状态机咬合,Jev 成为消除挫败感、实现“做我所想”(Do What I Mean)的工程解法。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=0s) 开场探讨:AI 如此强大,真正的自动化究竟在哪? 节目一开场便抛出了一个直击当下 AI 热潮痛点的尖锐质问:“自动化到底都去哪儿了?”("Where the fuck is all the automation?")。如今的 AI 展现出了令人难以置信的智力水平,然而在解决聊天与写代码之外的绝大多数实际问题时,却显得异常无能为力。无论是投入多少 AI 编程助手(Coding Agents),软件本身的本质并没有真正变好——开发者或许写代码的速度变快了,但写出来的软件质量甚至可能正在变差。以 OpenAI 为例,他们早在 2020 年就试图彻底实现客户服务的自动化,但至今这项工作依然困难重重。 问题的核心在于行业走偏了方向。与其不断追求用 AI 替代人类去更快地写出传统形态的代码,不如去追求“智能软件”(Smart software)——扩展软件自身的能力边界,让那些原本就应该被自动化的任务真正具备自动化的可能。对谈中特别提到了 TypeSafe 的核心口号:“我们做生产工具,不负责造神”("We build prod, not god")。主流的大模型实验室往往抱持着“全知全能覆盖一切”的宏大叙事,而 TypeSafe 却站在了完全不同的现实视角,认为行业目前并没有走在真正的递归自我改进(RSI)或所谓的“SaaS 大灾难”路径上,而是需要构建切实可靠的工程基石。 ### [00:52](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=52s) 结识 Diogo Almeida:TypeSafe AI 的电梯游说与“做生产工具而非造神” a16z 的合伙人 Ben Horowitz 与 Martin Casado 共同引出了本期嘉宾——TypeSafe AI 的创始人 Diogo Almeida。在两人眼中,Diogo 不仅是打造前沿产品的创业者,更是他们心目中的行业英雄,正在引领一场极其重要的新软件范式运动。当被问及能否为 TypeSafe 以及旗下产品 Jev 做一个简短的电梯游说(Elevator pitch)时,Diogo 直率地询问现场是否允许爆粗口,随后给出了自己最核心的表述:当下的 AI 现状有一种令人心碎的悲剧感——模型蕴含着如此惊人的智慧,却宛如未经雕琢的璞玉,在聊天机器人和编程之外的广阔现实场景中无从施展。 Diogo 强调,自己绝非否定 Chatbot 或编程 Agent 的价值,他本人也是这些工具的重度爱好者,但 TypeSafe 的愿景是“为软件本身打造 AI”(AI for software)。AI 不应仅仅以“人在回路”(Human-in-the-loop)的辅助者形态存在,而应当作为软件系统的内部核心组件直接参与构建真实运行的程序。Jev 正是 TypeSafe 在该领域推出的第一款基础模型,其目标就是打通自动化落地的关键卡点,让软件直接具备理解与推理能力。 ### [02:28](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=148s) 代码生成 vs 智能软件:突破“即时软件”的局限 Jev 一经推出便在开发者圈子内迅速引发轰动。Ben Horowitz 提到,几乎身边的每一个开发者都在给他们打电话赞叹 Jev 的惊人表现:“这太不可思议了,它极快且处处出色。”但外界不可避免地会产生疑问:既然行业里已经有了 Claude Code、Codex 以及各种代码生成工具,Jev 究竟有何不同?它又如何导向真正的自动化? ```mermaid flowchart TD accTitle: 代码生成与智能软件架构对比 accDescr: 对比传统代码生成工具与以 Jev 为内核的智能软件在软件运行和表达能力上的区别 subgraph CodeGeneration["代码生成模式 (Claude Code / Codex)"] A["自然语言指令"] --> B["代码生成模型"] B --> C["传统确定性代码"] C --> D["传统软件表达边界"] end subgraph SmartSoftware["智能软件模式 (TypeSafe Jev)"] E["开发者 / 生成工具"] --> F["内嵌 Jev 原语的软件"] F --> G["程序内部状态机与概率判断"] G --> H["具备意图推理能力的智能软件"] end ``` Diogo 引用了 Garry Tan 对 Claude Code 和 Codex 的经典评价——“即时软件”(Just-in-time software)。这类工具能够通过自然语言实时编写代码,但生成的软件在表达力上限上与传统软件别无二致。Diogo 追求的则是彻底拓宽软件自身的表达范畴: - **表达意图而非死板逻辑**:编程的本质是高度精确地定义某种有价值的逻辑,并将其进行无限复制;智能软件则需要将“人类意图”纳入程序词表。 - **扩展软件能力边界**:不是单纯自动化“软件工程这门工作”,而是让软件自身能够消化原本无法处理的模糊现实任务。 - **赋能开发者构建全新系统**:与其用一个速度更快、但写出的代码甚至不如人类高明的 AI 替代软件工程师,不如赋予现有工程师前所未有的超能力,去写出格局完全不同、复杂度更高的软件。 ### [04:25](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=265s) Jev 作为全新软件原语:将概率与状态决策植入代码核心 Martin Casado 敏锐地指出,许多人忽略了一个关键的微妙区别:无论是使用 Cursor、Claude Code 还是人类程序员手写,传统工具生成的代码结构与十年前的代码毫无二致。而 Jev 的本质是一个全新的软件原语(Primitive),开发者或代码生成工具可以直接将它作为模块引入到系统内部,从而根本性地改变软件的运行机理。 这个全新的内嵌智能层在思维方式上对传统程序员带来了认知刷新。传统编程基于确定性的布尔逻辑和确切分支,而 Jev 允许开发者使用自然语言定义目标,为程序提供一个状态机(State machine),让其根据置信度水平(Confidence levels)在运行时自主做出概率性决策。Diogo 感叹道,过去十年计算机软件的底层形态几乎静止未变,行业应对 AI 的极限操作往往只是在软件侧边栏挂一个小聊天窗,尝试执行几项不可靠的操作。Jev 则是要把智能真正灌注到软件血肉中,成为随处可调用的标准构件。 ### [06:19](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=379s) 分类器的威力:超越 2019 年机器学习工程团队的开箱即用体验 在谈及这种全新的编程范式时,Diogo 坦言机器原生(Machine-native)逻辑与传统二进制比特之间并不完全等价,而调和这两者正是 TypeSafe 的技术艺术所在。他在团队第一天入职培训时,就会在白板上画出韦恩图:一边是“AI 擅长的事”,另一边是“代码中有价值的事”,TypeSafe 的定位正处于两者交集的核心。因此,Jev 不会去强行输出模型并不擅长的外推浮点数,而是深耕于结构化的概率判断。 面对“Jev 是不是本质上只是个分类器(Classifier)”的质疑,Diogo 毫不避讳地热情赞同:“Jev 绝对就是一个分类器,而分类器太棒了!分类器从诞生的第一天起就是为了实用而设计的。”Martin 也补充道,这套接口正是脱胎于务实的机器学习工程落地经验。在 Diogo 看来,Jev 如今为普通开发者带来的能力,已经全面超越了 2019 年一整支专业机器学习工程师(MLE)团队耗时费力采集数据集、搭建测量体系后所能交付的效果;如今开发者只需几行配置,即可在程序中实时调用同等甚至更强的智能决策能力。 ### [07:41](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=461s) 设计权衡:“每美元智能”与将 AI 嵌入程序状态内部 针对程序接口的演进路线,Martin 提出了一个深刻的设计哲学问题:未来的编程界面是一个连续的光谱滑块(一端是纯粹的“自然语言进、自然语言出”,另一端是传统的命令式代码),还是说“自然语言输入、状态机输出”本身就是一个会长期稳固的通用编程设计范式? Diogo 坦陈内心倾向于认为这是一个演进的光谱,但在工程落地上,他必须做极具针对性的取舍: - **核心指标:每美元智能(Intelligence per dollar)**:尽管短期内“每秒智能”(执行速度/延迟)极具吸引力,但 Diogo 目前的北极星指标依然是每单位成本能释放的最大智能密度。 - **状态机命名背后的深意**:Jev 将其输入接口明确命名为“状态”(State),其设计初衷就是为了无缝嵌入到程序内部最深层的状态管理之中,让内部复杂的状态排布直接与智能相结合。 - **演进阶段定位**:在当前阶段受限于几十到上百毫秒的延迟,Jev 在架构定位上更接近于一个高吞吐的智能数据库,但长远愿景是让它进一步轻量化、极速化,最终成为像标准库(Standard library)一样无处不在的基础构件。 ### [09:01](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=541s) 跨界思维的雏形:从数学竞赛获奖者到系统与 AI 的结合 对话进行到这里,主持人不禁退后一步发出由衷赞叹:能够把 AI 前沿研究者、系统底层架构师以及资深程序员的视角融会贯通,在当今科技界极其罕见。AI 圈往往执着于将模型推向拟人化的“神性”造物,而 Diogo 却始终清醒地将其塑造为程序员手中的硬核工程工具。当被问及是什么样的人生经历淬炼出了这种独特的思维方式时,Diogo 幽默地调侃了一句“当一个男人和一个女人相爱……”随后回顾起自己非同寻常的技术起点:他曾是一名多次斩获大奖的数学竞赛选手(Mathlete),从纯粹数学思维起步,最终踏上了一条别具一格的 AI 与系统工程探索之旅。 ### [09:36](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=576s) 从数学竞赛生到计算机科学:靠工程化击败纯数学 Diogo Almeida 以一段幽默的自嘲开启了对自己早年经历的回顾。他打趣道,自己当年“数学好到了能靠它吸引女生的程度”,引得 Ben Horowitz 和 Martin Casado 哄堂大笑并追问到底是怎样的女孩。面对打趣,Diogo 笑着告诫年轻一代千万别学他:“年轻人千万别这么干,不值得,做个酷一点、随和有趣的人就好,别用力过猛去过度补偿。”尽管曾是一名数学竞赛生(mathlete),Diogo 坦言自己其实从未真正热爱过数学,当时不过是“小池塘里的大鱼”,厌倦了纯粹为了竞赛输赢而刷题。直到接触计算机科学,他才找到了真正的归宿——计算机科学就像是“变酷、变实用、变有趣了的数学”。直到今天,他依然极其热爱给求职者做算法面试,认为那是摸清一个人底细的最佳方式。他强调,尽管后来在 AI 领域深耕多年,但他从心底里始终认为自己首先是一名计算机科学家,其次才是一名 AI 研究员。 Diogo 真正踏入 AI 圈子的契机十分戏剧化。他参加了一场 Kaggle 算法竞赛并夺得冠军,但他取胜靠的根本不是高深精妙的数学理论,而是纯粹的工程自动化和系统思维——“写更多的嵌套循环,把它当成一个系统工程问题来彻底暴力自动化”。这一战绩让他赢得了在顶级学术会议 NeurIPS 上发表演讲的机会。虽然对绝大多数学者而言这是莫大的荣誉,但当时的 Diogo 却满心不情愿,因为他更想“留在矿坑里默默写代码”。那场 Kaggle 比赛的主办者正是支持向量机(SVM)的联合发明人 Isabelle Guyon。Isabelle 敏锐地察觉到眼前这个年轻人与学术圈格格不入却天赋异禀,便主动提携他,将他引荐给主流 AI 圈的核心人物,自此彻底将他的职业生涯推向了人工智能的最前沿。 ```mermaid flowchart TD accTitle: Diogo 从数学竞赛到 AI 研究的核心转折 accDescr: 展示 Diogo 从竞赛生走向计算机系统,并通过 Kaggle 自动化进入 AI 圈的路径 subgraph Background["早年背景与转变"] A["数学竞赛生 (Mathlete)<br/>厌倦纯竞赛与枯燥理论"] --> B["转向计算机科学<br/>实用、系统化、富有乐趣"] end subgraph Breakthrough["工程化破局"] B --> C["Kaggle 竞赛夺冠<br/>靠系统工程与循环自动化而非玄学数学"] C --> D["Isabelle Guyon 伯乐引荐<br/>受邀在 NeurIPS 演讲并进入学术视野"] end Background --> Breakthrough ``` --- ### [11:44](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=704s) “做生产产品,不做上帝”:打破单一大脑的 AGI 迷思 在踏入 AI 领域后,Diogo 先是与 Jeremy Howard 一起做初创公司,随后加入 Google Brain 工作了一段时间。在那之后,他曾短暂“退休”隐退,但很快便耐不住无所事事的寂寞,意识到 AI 依然是一件“极其好玩的事情”,于是选择复出加入 OpenAI,并在那里取得了耀眼的成果。Ben Horowitz 特别指出,Diogo 与他创立的 TypeSafe AI(及其核心产品 Jev)展现出了一种在当今 AI 行业极其罕见的精气神。当前的 AI 头部实验室领导者往往带着一种近乎宗教的沉重甚至恐惧感,而 TypeSafe 却提出了一句响亮的口号:“我们做生产产品,不做上帝”(We build prod, not God)。在 Ben 看来,Jev 代表的不仅是一家公司,更是一场充满乐观主义的运动——坚信 AI 不仅不会消灭工作,反而会创造更多、更优质的岗位,让每个人都能享受技术带来的红利。 Diogo 解释称,很多人由于不理解一线开发者的真实需求,很容易喝下“单一模型迷魂汤”(mono-model Kool-Aid),幻想由一个全知全能的超级大模型(One big brain to rule them all)统治一切。学术界和模型厂商往往陷入一种“这不过是个分类器”的纯算法层面的偏狭争论,而真正上手使用 Jev 的开发者却在开狂欢派对,因为他们终于能把想做的事情做成了。整个社区由此形成了鲜明的分野:一边是沉迷于宏大叙事却愁容满面的 AI 宿命论者,另一边则是用 Jev 实实在在解决工程问题、充满欢笑的开发者。 - **早年履历节点**:与 Jeremy Howard 共事创业 $\rightarrow$ 进入 Google Brain $\rightarrow$ 短暂休息隐退 $\rightarrow$ 加入 OpenAI 核心团队 $\rightarrow$ 创立 TypeSafe AI。 - **核心研发理念**:“做生产产品,不做上帝”(We build prod, not God),摒弃不可控的通用巨型神坛,聚焦于在真实生产环境中稳定运行的软件架构。 - **认知分歧**:反驳将所有希望寄托于单一庞大模型的“Mono-model Kool-Aid”,主张将智能模块化、工程化地融入软件基础设施。 --- ### [14:14](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=854s) 自动化的巨大落差:从退订报纸到真正的系统可靠性 面对外界对超级 AI 的炒作,Diogo 和主持人探讨了一个极为尖锐的现实矛盾:AI 已经展现出令人惊叹的智商,而且全球有着巨大的商业利益去推动自动化,但现实中的真正自动化究竟去哪儿了("Where the f*** is all the automation?")?大量极其繁琐、机械的基础人类劳动至今根本没有被自动化替代。现实世界的停滞不前与 AI 理论潜能之间的巨大落差,让 Diogo 深感痛心。Ben Horowitz 随即分享了当天早上与 a16z 成长基金负责人 David George 的趣事:David 兴奋地向 Ben 炫耀一款最新的自动化代理工具极其好用,当 Ben 问他到底用它干成了什么惊天动地的大事时,David 的回答竟是:“我终于用它退订了《纽约时报》的订阅。” 这个引人发笑的例子恰恰揭示了当下的荒诞现状——连退订报纸这种流程恶心的基本杂务,都成了当今 AI 自动化的“高光时刻”。Diogo 强调,如果行业想要真正奔向全自动化的“北极星”,就绝不能再陷入 AI 领域长期以来的反模式(anti-patterns)——即过度沉迷于在精心调优的 Demo 中展示极端特异用例(outliers and demos)。真正有价值的软件不是 Demo 里的杂耍,而是能够在后台安静、稳定地长期运行,永远不需要在凌晨三点把工程师从床上叫醒去处理报警。 - **行业反模式**:依赖精心设计的演示(Demo-driven)和孤立的成功个案,忽视了真实生产系统对连续性与确定性的要求。 - **自动化底线要求**: 1. **后台静默运行**:达到高度信任阈值,无需人类时刻在回路中兜底或被报警(paging)打扰。 2. **可组合性(Composable)**:不同智能模块可以像标准软件组件一样灵活拼接、互相调用。 3. **统计级保证(Statistical Guarantees)**:在赋予模型资源调用与系统操作权限时,必须具备明确的安全与行为边界,杜绝“擅自出轨”(go rogue)毁坏系统。 --- ### [16:58](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1018s) OpenAI 早期与 RLHF 突破:“吃袜子冥想”与对 AGI 的幻灭 Martin Casado 回忆起早在 2017 年与 Diogo 交流时的情景,当时 Diogo 就做过一场名为《理论上的模块化与实践中的灵活性 AI》(AI modular in theory and flexible in practice)的演讲,其关注数据与系统架构的工程化视角一以贯之。但 Diogo 指出,自己对当前技术路线真正形成顿悟,始于 2021 年第四季度在 OpenAI 研发早期 InstructGPT / ChatGPT 的关键节点。当时他们团队利用人类反馈强化学习(RLHF)训练模型,其展现出的泛化能力让所有人大吃一惊。 为了严格验证模型是否真的具备泛化理解能力、而非仅仅在训练集上“作弊”(在机器学习领域,作弊往往是虚假繁荣的元凶),团队采用严格的科学证伪法设计了许多离奇的问题。Diogo 最喜欢的测试用例是:“为什么在冥想前吃袜子很重要?”("Why is it important to eat socks before meditating?")。团队在测试前反复确认全网绝对没有任何类似语料,但模型居然能够有条不紊地给出一套看起来煞有介事、极具人类逻辑美感的荒诞论证。这一刻让整个团队彻底意识到:RLHF 真的掌握了泛化推理能力,它没有作弊。 然而,这背后的巨大成功却成为了 Diogo 个人世界观崩塌的开端。作为当时全力推动该模型发布的核心能力开发者,他曾一度真诚地坚信:这个掌握了强大泛化能力的模型有相当大的概率就是通往通用人工智能(AGI)的终极答案。但随着模型的真正落地,现实很快无情地证明它依然无法解决深层的可靠软件逻辑与自主自动化问题。这种期待的落空让他陷入了深深的幻灭与反思:“既然 RLHF 泛化得如此漂亮,那为什么它依然成不了 AGI?”这也促使他跳出单纯扩大模型规模的“狂热列车”,开始重新思考智能系统与概率性软件的真正形态。 - **关键历史节点**:2021 年第四季度(Q4 2021),OpenAI 内部验证 RLHF 泛化能力的转折期。 - **经典证伪用例**:“冥想前吃袜子”测试,用于验证模型在遭遇互联网从未出现过的概念组合时,能否展现出真正的自发逻辑生成而非检索作弊。 - **泛化机制观察**:Diogo 指出基于人类反馈的强化学习(RLHF)在语言理解上泛化得极佳,但基于可验证奖励的强化学习(RLVR)在很多场景下的泛化表现却远不如预期。 - **信念崩塌与重构**:从早先认为“扩大单模强化学习即可实现 AGI”的狂热中清醒,认识到单凭大模型无法直接带来可靠的自动化,催生了后续构建 Jev 与 TypeSafe AI 的系统级软件思路。 ### [19:28](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1168s) AGI 的定义与自动化的缺失:为什么强大模型没能落地? 在探讨技术演进时,话题转向了早期 OpenAI 内部对 AGI 的探讨与当前 AI 落地现状的反差。Diogo Almeida 回忆起 2020 年初在 OpenAI 的日子,当时大家私下常把 AGI 戏称为“在每一个 if 语句里都塞进一个 Ilya(Ilya Sutskever)”。他指出,OpenAI 的文化中有一部分是故意将 AGI 的概念维持得模糊且包容,就像一个“巨大的帐篷”,让所有人都能找到归属感。从技术细节上看,Diogo 直言自己当时和现在都不认为行业正走在递归自我改进(RSI, Recursive Self-Improvement)的道路上;但就 OpenAI 最初给出的 AGI 经济学定义——“将世界上绝大多数具有经济价值的工作自动化”而言,他认为这在技术上是完全可行的。 现实世界中存在海量重复且死板的工作。如果要将这些工作外包,原本只需要给出基础员工就能执行的简单指令;而就模型本身展现出的通用智能水平而言,处理这类指令的能力早在多年前就已具备。Diogo 感到如鲠在喉的困惑在于:“既然这种智能早已就位,为什么自动化迟迟没有真正普及?”他将矛头指向了 RLHF(基于人类反馈的强化学习)普及之后整个行业的走偏:行业逐渐分化为“巨大的过度承诺与实际交付不足(gigantic overpromise, underdeliver)”。早期的 GPT-3 在校准上其实相当准确,但因为是由人类评审来打分,模型看起来极为惊艳,研发重心却变成了“讨好人类裁判”,而非攻克坚固的自动化工程。 在 Diogo 眼中,衡量 AI 进展真正的“煤矿金丝雀”(敏锐的警示指标)并不是科幻般的测试集。他说,现在大家四处宣称高难度数学题被攻克了,甚至两年前 GPQA(Google-proof 科学问答基准)就被刷通了,然而现实中“AI 连汽车餐厅(Drive-thru)的点单系统都做不好”。这种“顶尖逻辑似乎已解,底层现实任务依然崩溃”的巨大落差,是当前很多人无法正面给出合理解释的盲区。 --- ### [21:52](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1312s) 现实世界的长尾挑战与程序员的怠惰美德 面对这一质疑,Martin Casado 提出了另一种解释假说:现实世界的数据分布与纯数字或数学世界截然不同。现实场景具备极端重尾(heavy-tailed)特征,充满了海量未被数字化的异常值和边缘案例;AI 之所以在真实世界中难以发挥生产力,是否只是因为模型根本没有在这类真实分布上训练过,从而被迫退缩在数学、编程这种低维流形(lower dimensional manifolds)中? Diogo 并不完全认同“单纯是数据问题”的说法。他承认长尾分布客观存在,但认为自动化并不需要一开始就解决所有长尾极端情况。工程落地需要极度的务实精神与 ROI(投资回报率)考量。他借用了 Perl 社区著名的“程序员三大美德”典故——“怠惰(Laziness)、狂妄(Hubris)与急躁(Impatience)”——强调程序员之所以愿意花 10 个小时编写工具,就是为了能一劳永逸地将一个 5 分钟的重复任务彻底自动化。他创办 TypeSafe 并将核心产品命名为 Jev(取自杰文斯悖论 Jevons Paradox),正是坚信一旦基础任务被真正自动化,人类就会创造出全新形态的工作。 作为反思现实难度的例子,大家谈到企业内部的自动化进程往往远落后于预期。OpenAI 早从 2020 年就开始尝试用模型做客户服务,但即便到了今天,绝大多数企业内部的 AI 落地项目仍以失败告终(除了辅助编程本身成效显著)。企业常常宣称自己的客服系统“解决了 95% 的工单”,但只要深入审计数据,就会发现那 95% 几乎全是找回密码之类的机械重复;若按问题的独立性与独特性(uniqueness)来看,真实解决率其实只有 50% 左右。一旦触及真实世界中错综复杂的人性与系统边缘情况,传统方案便会立刻溃败。 --- ### [24:49](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1489s) Jev 的爆发与多维度的“可靠性”哲学 谈及 Jev 的发布,Ben Horowitz 和 Martin Casado 提到几乎每小时都有人发来信息,兴奋地分享自己用 Jev 解锁的全新场景。Diogo 坦言这次发布的火爆程度完全超出了他的预期:“任何预料到这一幕的人大概都疯了。”这就像是开发者生态里的一次“ChatGPT 时刻”,不仅开发者沉浸其中,甚至大量非程序员朋友也在社交网络上发表情包和推文加入狂欢。 在这场狂欢背后,Diogo 强调外界最难体会、也是团队历经多年“血、汗与泪水”打磨的核心,只有一个词——**可靠性(Reliability)**。在资本市场眼中,追求小数点后的每一个“9”(如 99.9% 到 99.99% 的可靠度)或许不如包装宏大叙事能拉抬估值,但它却是解锁全新工程应用的唯一钥匙。当被问及在具有概率性和随机性(stochastic)的大模型体系下究竟如何定义“可靠性”时,Diogo 梳理了三个层次的演进: ```mermaid flowchart TD accTitle: Reliability Spectrum accDescr: Comparison of different layers of reliability in software and AI systems subgraph Infra["基础架构层"] A["高可用性 / SLA<br/>(System Uptime)"] end subgraph Logic["传统软件层"] B["确定性<br/>(Determinism: 绝对幂等输出)"] end subgraph Intelligence["Jev 追求的智能软件层"] C["稳健性<br/>(Robustness: 每次表现出同等水平的智能)"] D["可编程信任态<br/>(无需预先试探 Query, 进入纯粹的心流状态)"] end A --> B B --> C C --> D ``` - **第一层:可用性(Uptime / SLAs)**:最基础的系统不宕机、网络服务连通。 - **第二层:确定性(Determinism)**:给相同输入返回完全相同的输出。Diogo 指出这适合做单元测试,但在现实工程中意义有限——例如给 Prompt 增加一个随机生成的 UUID,语义未变,但确定性被打破了。 - **第三层:稳健性(Robustness)与类人智能(Consistent Intelligence)**:每次调用模型时,即便生成的具体文字不同,它必须在逻辑深度上表现出“同等水准的聪明”。它的思考路径必须能被人类程序员所理解,从而允许开发者围绕它的逻辑边界进行防御性或架构性编程。 Diogo 总结道,他对 Jev 能够达到的可靠性最高赞誉是:**开发者在调用 Jev 编写程序时,甚至不需要先在操场里做样本查询(example queries)去试探它会不会抽风,而是能够直接把信任交付给它,彻底进入编程的心流状态(flow state)。** --- ### [28:10](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1690s) 编码智能体(Coding Agents)与智能原语(Jev)的未来形态 在探讨软件工程范式转移时,Martin 提出了一个尖锐的推论:如果开发者拥有了 Jev 这样可靠的“底层智能决策原语”,编码智能体(Coding Agents)本身的价值会不会反而被稀释? 逻辑在于: 1. **纯代码生成路线**:类似 Codex 或各类 Coding Agent 生成了数以万行的臃肿代码,但底层的代码依然是死板、缺乏弹性的传统软件逻辑; 2. **新型智能软件路线**:人类开发者亲自写代码,甚至不依赖生成式 Agent,但在核心逻辑中直接嵌入 Jev 作为具备推理决策能力的原语,从而让软件本身变得更简短、更聪明。 面对“未来究竟是 Agent 操控 Jev,还是人类驾驭 Jev,抑或二者存在冗余”的设问,Diogo 笑着表示这更偏向于对 Coding Agent 发展轨迹的预测。他谦虚地表示,自己近期为了攻克底层系统,待在编码一线矿坑的时间并不如两位投资人所接触的广泛,但这个问题的核心在于软件究竟是需要“生成更多静态代码”,还是需要“在系统内核中注入真正的智能”。 ### [29:01](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1741s) 编程智能体的短板:擅长语法,不懂架构 谈及当前代码生成模型与编程智能体(Coding Agents)的现状,Diogo Almeida 指出模型目前最擅长的是“语法”(Syntax),但在“语义”(Semantics)上表现较弱,在“软件架构”(Architecture)层面更是极其糟糕。在他看来,架构设计是整个软件工程中最具人类独创性与创造力的部分。尽管如此,Diogo 依然非常热衷于使用编程智能体辅助工作;只要任务属于训练数据的分布范围内(In-distribution),让模型去处理琐碎的语法层工作没有任何问题。 对于那些缺乏架构设计经验的人或团队而言,模型展现出的架构能力可能已经达到“中位数水平”(50th percentile),这在许多场景下已经足够应对。软件工程本身就是权衡的艺术,开发速度往往是初创团队最需要调节的旋钮——为了加快上线迭代节奏、让 Codex 或智能体通宵写代码,团队完全愿意接受一个 50 分位的平庸架构而非耗费心力追求 60 分位的严谨设计。 - 模型在代码语法上表现优异,但在顶层架构与系统语义设计上严重依赖人工把控。 - 架构水平在模型中虽然不高,但对于没有架构设计能力的用户来说,中位数水平已具实用价值。 - 速度与架构完整性之间的权衡,决定了团队如何选择利用代码生成工具。 --- ### [30:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1800s) 逆转“SaaS 灭顶之灾”:SaaS Palooza 与护城河 面对市场上早前流传的“AI 编程智能体将引发 SaaS 灭绝”(SaaS Apocalypse,认为软件构建成本骤降导致所有 SaaS 产品都会被轻易复制、估值崩盘)的论调,Ben Horowitz 提问为什么当 Jev 出现后,SaaS 公司反而纷纷认为这是天大的利好。Diogo 剖析了灭绝论的逻辑漏洞:软件固然可能变得更便宜,但绝非轻易就能被复制,因为 SaaS 的核心壁垒深深植根于“引擎盖之下”复杂的底层工程、状态维护以及对客户实际工作流的深刻洞察。 Diogo 认为不仅不会发生 SaaS 灭绝,反而会迎来一场由老牌 SaaS 主导的“能力大爆发”(Inverse Apocalypse,被戏称为 "SaaS Palooza")。SaaS 公司的前期资本支出(CapEx)大部分花在获客、理解客户痛点与分发渠道上。与其给现有产品硬塞一个敷衍的 Chatbot,不如利用 Jev 类的技术将底层智能注入工作流之中,使既有的大规模用户体验发生质的跃迁。未来,甚至可能彻底淘汰自 1980 年代第四代编程语言(4GL)沿袭至今的呆板多选表单,实现直接理解用户意图并调度系统的“做我所想”(Do What I Mean)交互界面。 ```mermaid flowchart TD accTitle: SaaS 价值模型演进 accDescr: 对比传统 SaaS 灭绝论与 Jev 赋能下的 SaaS 升级路径 subgraph Fallacy["市场恐慌误区:SaaS Apocalypse"] A["代码生成变极便宜"] --> B["表面功能被轻易复刻"] B --> C["SaaS 估值暴跌、走向消亡"] end subgraph Reality["真实演进路径:SaaS Palooza"] D["老牌 SaaS 拥有客户分发与核心工作流认知"] --> E["引入 Jev:把智能注入软件内部而非仅加 Chatbot"] E --> F["淘汰传统表单与机械 UI,实现高可靠意向操作"] F --> G["软件能力产生质的跃迁,巩固竞争壁垒"] end ``` - **市场假说破裂**:SaaS 并非单纯的代码堆叠,其核心价值在于深水区系统逻辑与实际业务闭环。 - **资本与分发优势**:SaaS 最大的前期沉没成本在于触达客户,AI 能够让现存的分发渠道直接承载体验更好的高阶能力。 - **颠覆式交互案例**:社区出现利用 Jev 将纯语音输入实时解析为“操作系统指令”还是“普通文本插入”的实验,人机交互形态正向科幻般的 Star Trek 级体验演化。 --- ### [33:39](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2019s) 赋予软件全新能力,而非单纯生成更多代码 Martin Casado 深入分析了当前利用 AI 写软件的认知局限:大公司软件仓库中平均每个 PR(Pull Request)往往只有区区 10 行代码,而这些微小的修改本就是根据客户反馈进行针对性调整。如果仅仅把视角局限在“用 AI 自动写这 10 行代码”,本质上只是对极为局部的环节做自动化优化,最终生成的软件本身与以往毫无二致,甚至由于缺乏人工严格把关,往往伴随更多的安全漏洞和更差的可靠性。 Jev 带来的范式转变在于**赋予软件全新的能力基语(Primitive)**。它将大语言模型的自然语言理解与推理能力,同工业级确定性的“状态机”融为一体。Diogo 坦言,如果大家能将 Jev 理解为在传统三种逻辑门(Logic Gates)之外拓展出带有推理能力的全新逻辑门,那就是对团队最大的赞赏。未来软件不再只是被动执行固定规则,而是具备概率判断与意向对齐能力的自适应系统。 - **PR 数据事实**:大型企业的平均代码修改量仅约 10 行,聚焦于代码生成的效率提升对软件本质能力的拉动微乎其微。 - **安全性与代码量**:自动生成大量未经验证的代码反而会引入系统脆弱性与安全隐患。 - **全新计算基语**:Jev 并非单纯的模型外挂,而是试图构建一种能无缝内嵌在程序内部、连接推理与状态机的基础逻辑单元。 --- ### [35:30](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2130s) 概率性编程复兴与深层系统级重构 对话进一步探讨了这种智能基语能下潜到系统多深的位置。Martin 指出,虽然当前 Jev 类能力在日志分析、邮件处理、人机界面等表层场景能够立竿见影,但随着向底层推进,系统必须要面对一致性(Consistency)、持久性(Durability)以及严苛的系统级保证。长远来看,这可能会演进为全新的“智能数据库”甚至类似严密可靠的“空中交通管制系统”。Diogo 对此持务实态度,主张“先自动化简单工作,再啃硬骨头”,并预言一个崭新的“概率性编程”(Probabilistic Programming)时代即将被开启。 尽管历史上(如 20 世纪 70 年代及后续的贝叶斯学派)概率性编程几经沉浮,生物受启发模型也经常在工程落地前走弯路,但 Diogo 与 Martin 一致认为,眼下的契机为整个计算机系统提供了彻底“重新造一遍系统”的可能。如同历史上从大型机到客户端-服务器(Client-Server)架构、再到互联网时代的系统重写,伴随着成本与延迟各异的各级模型智能的出现,极客系统工程师将利用这些粗粒度预测、推测执行与乐观路由重构整个软件底层。 - **由浅入深的落地路径**:现阶段从 UI 交互、文本及日志解析切入,未来逐步向强保证、持久化的底层系统状态延伸。 - **务实工程 vs. 生物学概念**:Diogo 强调自身品牌是“极度务实主义”,技术成立需要经历漫长工程化提炼,而非迷信神经生物学噱头。 - **基础设施代际更迭**:全新的智能基语为开发者带来了类似大型机向分布式系统迁移的历史机遇,推动整个计算机软件栈自底向上全面重构。 ### [38:05](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2285s) 深入底层:AI 调用的大多数终将发生在系统“内脏”中 讨论从关键基础设施的安全重构切入。当被问及 TypeSafe 的核心产品 Jev 究竟是偏向于上层应用(Apps)、SaaS、数据分析,还是立足于底层系统与基础设施时,Diogo Almeida 毫不犹豫地将视角拉到了最底层的系统架构。他打了一个网络协议的生动比方:这就像是深入到 TCP 的核心腹地去解决根本问题——现有的 AI 交互更像不可靠的 UDP,而他们正在构建具有强保证的 TCP。这番话立刻引来了网络技术出身的 Martin Casado 意气相投的笑声,直呼“你这可说到我的专业老本行了(speaking my language)”。 Diogo 解释,自己极其看重“单位美元所能购买的智能水平”(intelligence per dollar),这是他通过对未来进行“终局倒推”得出的结论:设想一个科幻级别的 AI 经济革命已经到来,所有软件系统处处都内嵌着 AI 能力。在那个世界里,如果把每一次 AI 交互都看作一次函数调用,究竟有多大比例是面向人类终端用户、需要字斟句酌地调节行文风格的?答案显然是极其微小的零头,99.999% 以上(many nines)的 AI 调用都将深埋在系统的“内脏”(guts)之中,负责在机器与机器之间做精确的决断。尽管技术普及通常会先从第一层(界面应用)浮现,但如果工程团队一开始不将准星对准系统底层,整个行业可能需要兜巨大的圈子才能抵达那个未来。 ```mermaid flowchart TD accTitle: AI 调用层级与目标分布 accDescr: 对比浅层的人机交互与深埋在底层系统内脏中的 AI 调用比例 subgraph Layer1["浅层应用(First Layer)"] A["人类交互与界面呈现<br/>(注重语气、风格、Chat UI)"] B["比例极低:不足 0.001%"] end subgraph Layer2["系统底层(The Guts / 核心基础设施)"] C["系统状态转移与逻辑决断<br/>(高频、自动化、精准严谨)"] D["比例极高:占据 99.999%+ 的调用量"] end Layer1 -.->|技术演进方向:由表及里| Layer2 ``` - Diogo 强调必须直接“瞄准内脏”(aim for the guts),否则技术落地将经历漫长的延迟。 - 绝大多数 AI 调用从长期看都不是为了生成给人看的自然语言,而是系统内部逻辑运转的无形齿轮。 --- ### [39:47](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2387s) 像黑夜中的交错船只:软件与 AI 的磨合与“悲伤五阶段” 在过去很长一段时间里,传统软件与大语言模型就像是“黑夜中交错而过的两艘船”(ships in the night),彼此根本无法顺畅对话。传统软件依赖于严丝合缝的数据结构与确定性输入,根本无法真正消化模糊的自然语言。开发者们为了让模型配合,使尽浑身解数在 Prompt 里打补丁,甚至反复叮嘱“请输出符合此 Schema 的严格 JSON 格式”,但大模型却总是偶尔出轨报错。万般无奈之下,工程师们往往只能把心一横放弃挣扎("the hell with it"),最终演变出两种妥协方案:要么引入人工复核(Human-in-the-loop,即把非结构化输出丢给人类兜底的聊天窗口),要么把输出丢给另一个模型去循环修正(Agent while loop,本质上是在用概率修正概率)。 Martin Casado 风趣地指出,这一过程完美对应了软件工程师接入 AI 时的“悲伤五阶段”:从一开始坚信模型能乖乖听话的“否认期”,到遇到不可控输出时的“愤怒期”,再到最终不得不妥协的“接受期”——默默把不可靠的结果打包甩给人工或死循环代理。正因如此,Martin 评价 Jev 的突破在于,它第一次真正意义上把 LLM 严密地映射到了确定性的状态机(state machine)之中,让模型能在工业级软件管线里富有成效且安全地运作,终结了这种无奈的循环妥协。 - **传统调优死结**:通过 Prompt 注入 JSON Schema 经常遭到模型无视,导致解析直接崩溃。 - **现存妥协路线**:人类直接介入的 Chat 模式,以及依靠 `while` 循环相互纠错的 Agent 架构。 - **核心工程跨越**:将 LLM 转化为具备确定行为边界、可生产化运行的状态机,使软件真正具备确定性。 --- ### [41:08](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2468s) 可靠性与“做我所想”:终结挫败感的确定性革命 谈到技术的交付与商业落地,Diogo 表现得异常克制,坦言自己绝对不想“夸大其词却交付不足”(overpromise and underdeliver)。他深知业界充斥着过度的虚假承诺,Jev 或许尚不能立刻解决所有被过度吹捧的场景,但团队始终在为极高的可靠性拼尽全力。事实上,为了死磕系统的可靠性指标,团队推迟了发布时间;尽管在社交媒体当下的浮躁舆论场上,大众可能很难第一时间理解底层可靠性工程的艰辛,但用户终究会在使用中获得一种踏实的直觉:“这个东西我可以真正信赖。” Martin 将这种体验形象地概括为一台“反挫败感机器”(the anti-frustration machine)。Diogo 对此深表认同,并将其提炼为自己技术乌托邦的核心原则——“做我所想”(Do What I Mean,DWIM)。他向往一个运转更加平滑的世界,技术之间不再是层层摩擦与容错补丁,而是能够像机械齿轮般精准咬合、顺畅联锁。既然如今的 AI 已经具备了如此惊人的底层智能,那么让所有软件与机器都能真正、可靠地“理解并执行人类的真实意图”,便不再是一句虚幻的科幻口号,而是正在被构建的当下现实。访谈在对这一技术愿景的由衷赞叹中圆满收尾。 - **推迟发布的代价**:团队为了追求系统可靠性宁愿推迟上线,坚信底层工程的信任感会自然传递给开发者。 - **终极理念“DWIM”**:“做我所想”消除技术与人类意图之间的摩擦,让自动化像齿轮咬合般顺畅协同。 ## Notable quotes > [00:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=0s) Where the fuck is all the automation? — Diogo Almeida > [00:00](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=0s) We build prod, not god — Diogo Almeida > [06:19](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=379s) Jev 绝对就是一个分类器,而分类器太棒了!分类器从诞生的第一天起就是为了实用而设计的。 — Diogo Almeida > [09:36](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=576s) 年轻人千万别这么干,不值得,做个酷一点、随和有趣的人就好,别用力过猛去过度补偿。 — Diogo Almeida > [19:28](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1168s) 在每一个 if 语句里都塞进一个 Ilya — Diogo Almeida > [19:28](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1168s) AI 连汽车餐厅(Drive-thru)的点单系统都做不好 — Diogo Almeida > [24:49](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=1489s) 开发者在调用 Jev 编写程序时,甚至不需要先在操场里做样本查询去试探它会不会抽风,而是能够直接把信任交付给它,彻底进入编程的心流状态。 — Diogo Almeida > [38:05](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2285s) 99.999% 以上的 AI 调用都将深埋在系统的“内脏”(guts)之中,负责在机器与机器之间做精确的决断。 — Diogo Almeida > [41:08](https://www.youtube.com/watch?v=Ut3LOjKNJaE&t=2468s) 做我所想(Do What I Mean) — Diogo Almeida ## Mentioned Diogo Almeida, Ben Horowitz, Martin Casado, TypeSafe AI, Jev, a16z, OpenAI, Claude Code, Codex, Cursor, Garry Tan, Jeremy Howard, Google Brain, David George, The New York Times, Isabelle Guyon, NeurIPS, Kaggle, Ilya Sutskever, Perl, Jevons Paradox ## 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.” Timestamps: 00:00 - Intro 00:50 - Meet Diogo and Type Safe 04:07 - Smart software, not just faster code 15:46 - Where's all the automation? 22:00 - Is it just a data problem? 30:21 - SaaS apocalypse, reversed 34:58 - New capabilities, not more code 38:27 - Apps vs the guts of systems 41:08 - Reliability and "do what I mean" Resources: Follow Diogo Almeida: https://x.com/CompleteSkeptic Learn more about TypeSafe AI: https://typesafe.ai/ Follow TypeSafe AI: https://x.com/typesafeai Follow Ben Horowitz on X: https://x.com/bhorowitz Follow Martin Casado on X: https://x.com/martin_casado Stay Updated: If you enjoyed this episode, be sure to like, subscribe, and share with your friends! Find a16z on X: https://twitter.com/a16z Find a16z on LinkedIn: https://www.linkedin.com/company/a16z Listen to the a16z Show on Spotify: https://open.spotify.com/show/5bC65RDvs3oxnLyqqvkUYX Listen to the a16z Show on Apple Podcasts: https://podcasts.apple.com/us/podcast/a16z-podcast/id842818711 Follow our host: https://x.com/eriktorenberg Please note that 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. a16z and its affiliates may maintain investments in the companies discussed. For more details please see http://a16z.com/disclosures. [Source](https://www.youtube.com/watch?v=Ut3LOjKNJaE)

Source quotes

[0:00] Diogo Almeida: Where the fuck is all the automation? [0:00] Diogo Almeida: We build prod, not god [6:19] Diogo Almeida: Jev 绝对就是一个分类器,而分类器太棒了!分类器从诞生的第一天起就是为了实用而设计的。 [9:36] Diogo Almeida: 年轻人千万别这么干,不值得,做个酷一点、随和有趣的人就好,别用力过猛去过度补偿。 [19:28] Diogo Almeida: 在每一个 if 语句里都塞进一个 Ilya [19:28] Diogo Almeida: AI 连汽车餐厅(Drive-thru)的点单系统都做不好 [24:49] Diogo Almeida: 开发者在调用 Jev 编写程序时,甚至不需要先在操场里做样本查询去试探它会不会抽风,而是能够直接把信任交付给它,彻底进入编程的心流状态。 [38:05] Diogo Almeida: 99.999% 以上的 AI 调用都将深埋在系统的“内脏”(guts)之中,负责在机器与机器之间做精确的决断。 [41:08] Diogo Almeida: 做我所想(Do What I Mean)

Source quotes

[0:00] Diogo Almeida: Where the f*** is all the automation? [0:00] Diogo Almeida: we build prod, not god. [9:36] Diogo Almeida: Don't do it. Youth, don't do it. It's not worth it. Just be cool and chill and interesting and don't overcompensate. [16:58] Diogo Almeida: Why is it important to eat socks before meditating? [19:28] Diogo Almeida: Are you really telling me that we... math is solved or like even like 2 years ago GPQA, that Google-proof question answering is solved, but we still can't handle a drive-thru, 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. [14:43] David George: I finally canceled my New York Times subscription. [25:47] Diogo Almeida: To me the highest honor of reliability will be to get to the point where people can program against Jev without making example queries. Like when you just trust it, you'll be in like pure flow state. [32:04] Martin Casado: Then you're at Star Trek. [41:08] Diogo Almeida: it'll just have like that good vibe of like, oh, I can trust this.

Original transcript

[0:00] Where the [ __ ] is all the automation? AI [0:01] is so unbelievably smart and yet it's so [0:04] useless at all other stuff. [0:06] >> It doesn't matter how much AI coding [0:08] agents you use, the software actually [0:09] isn't getting better. Maybe you're [0:11] writing it faster. It's like arguably [0:13] getting worse. [0:13] >> OpenAI has been trying to automate [0:14] customer service since 2020. What I want [0:17] instead is smart software. I want to [0:20] expand what software itself can do such [0:22] that things that should be automatable [0:25] can then be automatable. My favorite [0:27] thing that you guys say is we build prod [0:29] not god. So good [0:31] >> because if we had any other kind of like [0:32] big lab leader even if they had joy they [0:35] would cover everything [0:37] >> and then your view is so different. [0:40] You're like no we're going to create a [0:42] way better world [0:43] >> for nuanced reasons. I don't think we [0:45] are on the path of RSI in the SAS [0:48] apocalypse story. Um [0:52] today we have the founder and leader of [0:56] Typesafe, Diego with us. Um who uh is a [1:02] bit of a hero to both Martine and me. [1:04] Yes. [1:05] >> Um he is not only building like a really [1:08] interesting product uh but creating what [1:11] we think is a very important movement. [1:13] So we're super excited about today. [1:15] >> Welcome. Thank you for coming. Yeah. [1:16] >> Thank you. [1:17] >> Yeah. And uh maybe you can give us kind [1:20] of a a brief on um just you know what is [1:24] Jev? What is type safe? Why is it [1:27] important? [1:29] >> Is this a curse friendly or no? [1:32] >> Okay. [ __ ] are you talking about? [1:34] >> Okay. Okay. Okay. Cool. So I was [1:36] actually asked for like a elevator pitch [1:39] which I tend to ramble on and I don't do [1:41] well but like I realized my favorite [1:43] elevator pitch for Jev is where the [ __ ] [1:45] is all the automation? Like this is like [1:48] so unbelievably tragic, you know, so [1:51] much intelligence. AI is so unbelievably [1:53] smart and yet so not that I hate on chat [1:56] bots or coding agents. I love them [1:58] myself, but it's like it's so useless at [2:01] all other stuff and it's it's tragic. [2:05] It's tragic that, you know, we have so [2:06] much like diamond in the rough but not [2:08] polished for work. That's that's a but [2:12] type safe is making AI for software. You [2:15] know, we want to make AI powerful not [2:17] just for humans in the loop, but to [2:19] actually build real software and JIE to [2:21] us is our first model in this whole [2:24] space to make it way way better to like [2:26] make automation. [2:28] >> Yeah. And so it's been interesting [2:29] because it's kind of caught fire in [2:32] software world. So, you know, one of the [2:35] things that made us go, "What the hell's [2:36] going on here?" is like every developer [2:40] we know is calling us and going, "Oh, [2:41] this is freaking awesome. It's great. [2:43] It's fast. It's it's great. Everything's [2:45] better. Um, and h then how does that uh [2:50] cuz because everybody thinks of well [2:52] we've got cloud code you know we've got [2:54] codecs don't we already have that? Like [2:57] what's the difference? And then how does [2:58] that lead to real automation? [3:00] >> Oo I wish I had like a some slopp [3:04] visuals because I have like a favorite [3:06] sloped visual for this. So I like cloud [3:08] code and codeex. Um I love the [3:12] description from Gary Tan on them. It's [3:13] just in time software, you know, [3:15] incredible way to describe what they're [3:17] doing. It like it makes software on the [3:18] fly and you can like program software in [3:20] natural language, but it has the same [3:22] expressive power as software. [3:24] >> Um, what I want instead is smart [3:27] software. Like instead of like [3:28] automating software engineering, I want [3:30] to expand what software itself can do [3:33] such that things that could should be [3:35] automatable can then be automatable. and [3:37] like in a more um flowery language like [3:40] I want to express things like intent. I [3:43] want to like expand the vocabulary of [3:45] what we can do and I can talk about like [3:47] all sorts of like weird sci-fi things I [3:49] want but like programming is like hyper [3:51] specifying like valuable things and then [3:54] infinitely replicating them. It's so [3:56] freaking cool and I want to just make [3:58] that more, you know? [4:00] >> Oh, interesting. So, so one way to think [4:02] about it is instead of kind of a tool [4:06] that uh [4:09] somewhat replaces a software engineer [4:11] with a faster, maybe not even as good [4:13] software engineer. What you're saying is [4:16] no, no, no. We're going to supermpower [4:18] the software engineers we have to write [4:22] way, way better, more interesting [4:23] things. [4:25] >> Yeah. I I actually I mean Yeah. Yeah. So [4:28] this is by the way I just think so many [4:30] people miss this point and it's such a [4:31] subtle point and it's so important to [4:33] actually tease it out which is um if you [4:35] use something like cloud code or codex [4:36] which is great or cursor which is great [4:39] >> they write code but that code is the [4:41] same thing a human being would have [4:42] write maybe it's better maybe it's worse [4:43] but it's basically still code just like [4:45] code looked 10 years ago. [4:46] >> Yeah. And and the thing with Jev is [4:49] whether or not you're cloud code or a [4:51] human, you have this new primitive, this [4:53] new thing that you stick in your code [4:55] that actually expands like the power of [4:57] software. So instead of like writing [4:59] code, it is something that you include [5:00] in your code [5:01] >> which go ahead. Well, which which by the [5:04] way is interesting because it's this [5:07] very powerful primitive which would be [5:08] great if you explain but it's also a [5:10] little bit different than like you know [5:12] how programmers think. for example like [5:14] it has this notion of like you know [5:16] probabilities or you know and like so [5:18] you know so [5:19] >> so an intelligent layer inside the [5:22] software. [5:22] >> Yeah. Think of like like a li yeah like [5:24] a library that you can like use natural [5:28] language to describe what you want and [5:29] you give it kind of a state machine and [5:31] then it will will choose what to do with [5:33] some confidence levels which we kind of [5:34] haven't really had before like so [5:36] ubiquitous. So maybe [5:39] >> ooh there's a lot of tricks there. I [5:41] will jump into one thing first which is [5:43] I love the first thing you said like [5:46] >> you know in the direction of where the [5:47] [ __ ] is all the all automation. I love [5:50] software so much. I wish I could be [5:52] writing it all day. It's [5:54] >> would not recommend being a CEO to [5:56] people but whatever. Um, and also like [5:59] it's wild that AI is so cool and [6:02] software has been unchanged in 10 years, [6:04] you know, like like like that to me like [6:06] no one can like square this together and [6:08] the most we can do is add like a little [6:09] chatbot in the side sometimes that can [6:11] take actions but not all actions cuz [6:14] some of the actions are not reliable [6:15] now. So I just want to give like that [6:17] tiny aside. Um, [6:19] >> I love the point I'm gonna jump back to [6:20] the point about like this is a little [6:22] bit of a different way to think about [6:23] it. Um yes I think that machine native [6:28] doesn't exactly match bits perfectly and [6:31] like that's actually the art form that [6:33] we are trying to do like I in our [6:35] onboarding on day one I draw like the [6:37] vin diagram of like what AI is good at [6:40] what is valuable in code we are in the [6:42] middle so you know we don't output like [6:44] you know extrapolated floats for example [6:47] cuz like AI is just bad at that you know [6:49] but things like probabilities are not [6:52] exactly novel And it's similar to the is [6:55] Jev just a classifier argument. [6:57] >> Jev is absolutely a classifier. You [7:00] know, like classifiers are sick. [7:01] Classifiers were designed to be useful. [7:04] >> Yeah, they're designed to be useful. And [7:05] actually, it's the same interface as [7:07] like some of those ML concepts because [7:09] these came from like practical people [7:12] who are trying to make systems work. And [7:14] what I'm seeing is happening now is that [7:16] Jev actually I my guess is that Jev [7:20] probably is better than having like an [7:23] MLE team from 2019 making the stuff for [7:26] you and you can just program it on the [7:27] fly. Who knows what could be built cuz [7:29] like there were not that many good ML [7:31] team MLE teams in 2019 to build like [7:33] narrow things and to be able to like [7:35] collect data sets and measure it and all [7:36] of that. And it is just the beginning. [7:39] There's I feel like there's way like [7:41] like by the way to this point do you [7:42] think there's a slider bar here where [7:43] like on one end is like language in [7:45] language out like we have today on the [7:47] other end is like a like an existing [7:48] imperative program and then you can kind [7:50] of move between the two or do you think [7:52] like this is like the point in the [7:53] design space which is language in kind [7:55] of state machine out which is going to [7:57] like solidify as a general purpose thing [7:59] for programmers. [8:00] >> Ooh that's a tricky one. So I will say [8:03] the answer in my heart yeah the answer [8:05] in my heart is that it is a slider. So [8:07] in and actually when I design for our [8:10] the properties we have I might have made [8:13] mistakes due to my personal preferences [8:15] but like intelligence per dollar is my [8:17] northstar right now and it could be [8:18] wrong just to be clear intelligence per [8:20] second might be more valuable in the [8:21] short term but like even like our [8:23] interface like calling the input state [8:26] this is intentional like it's to say [8:28] >> oh that's great I didn't catch that [8:29] >> it's meant to be the insides of programs [8:32] so [8:32] >> so in my heart because like so we are [8:35] really optimizing a lot of the work I do [8:37] is for even more complicated [8:38] arrangements of the internals of program [8:40] state. Can you put intelligence in [8:42] there? I think this is going to be an [8:43] everpresent battle to have I, you know, [8:46] we're very intentional about our design [8:48] and also pragmatically I think certain [8:51] things happen like it's easier to make [8:53] an AI at these milliseconds. So it'll be [8:55] more like a database for a while than [8:57] like a standard library thing. But I [8:59] would love it to be a standard library [9:01] thing too. [9:01] >> Can I can I just pull back like what is [9:03] the alchemy that creates a do yogo? I [9:05] mean like you speak when a man and a [9:08] woman love each other [9:10] but like listen you speak like an AI [9:12] researcher you speak speak like a [9:14] systems person you speak like a [9:15] programmer and normally these things [9:17] have been like not super overlapping and [9:19] like you're you're taking you know AI [9:21] which we've been pushing towards you [9:22] know being a being and you're making it [9:24] a programmer's tool. So maybe a little [9:26] bit about your personal journey that [9:28] >> my history into AI is somewhat [9:30] unorthodox. Um, I was a mathlete. Um, I [9:34] was a award-winning mathlete. Um, the [9:36] way I describe it is I was good enough [9:38] at This is cringe. I was good enough at [9:40] math to get girls. So, that's quite [9:42] good. [9:43] >> No, that was a thing. [9:44] >> YEAH, YOU HAVE TO get you have to get [9:45] quite good. Um, [9:47] >> and what kind of girls do you get when [9:48] you're that good at math? That's an [9:50] >> Oh, that's our audience needs to know. [9:53] >> Oh, no. [9:55] >> We have to inspire the youth here. [9:57] >> Don't do it. Youth, don't do it. It's [9:59] not worth it. Just be cool and chill and [10:02] interesting and [10:04] >> don't overcompensate. [10:05] >> Wow, I can't believe I said that. Um, [10:08] >> so I was a math athlete, [10:10] >> but I actually never Oh man, this also [10:12] is a little cringe. I never really liked [10:13] math. I never really tried. I was just [10:16] like big fish in little pond. And to me, [10:19] math was act I math was always the path [10:21] I was set on, but I hated it because it [10:24] was always about like winning [10:25] competitions. But then computer science [10:27] is actually a lot like math. It's [10:28] basically like math but cool and useful [10:31] and fun and interesting and I still love [10:35] giving algorithms interviews. It's the [10:37] best thing for me to do. I don't know. [10:38] But do I love it? Yes. And does it like [10:40] allow me to like sus people out really [10:42] well? Yes, it does. So I love computer [10:44] science. I consider myself to be [10:46] computer scientist much more before AI [10:48] researcher despite my history. And um [10:52] like what actually got me into it was I [10:54] also won a kegle competition not from [10:56] sophisticated math but from like just [10:58] automating like the [ __ ] out of it. Um [11:02] >> you know like just like more nested [11:04] loops more you know like I solved it [11:06] like a systems problem you know. So that [11:08] eventually got me um like I was forced [11:12] to speak at Nurups normally an honor but [11:14] I hated it cuz I just wanted to be in [11:15] the mines. [11:16] >> Was that from the Kaggle team? [11:17] >> Yes. [11:18] >> Oh wow. Yeah, actually the Kaggle host [11:21] of it was Isabel Guong who was the [11:23] co-inventor of the SVM. Actually, I [11:25] think the first author of SVM. I'm not [11:27] 100% sure first author. Um, and she just [11:31] basically saw that I was like this [11:33] person who really didn't fit into the [11:34] research community and then adopted me [11:36] and showed me like like it got me to [11:39] meet all the AI people and that you know [11:41] my career was just pushed into that [11:44] direction. [11:44] >> And from there open AI? No, it was like [11:48] a startup with Jeremy Howard. Um, [11:52] >> no kidding. Yes, I love Jeremy. [11:54] Fantastic. [11:55] >> Cool. [11:55] >> Um, and then Google Brain for a while. [11:58] >> Wow. [11:59] >> And then, uh, retire for a while. [12:02] >> And then eventually I was like just kind [12:05] of tired of not doing anything. I was [12:08] like, you know what? Actually, AI is [12:10] pretty damn fun. And I joined OpenAI [12:12] because of that reason. Uh, and it [12:14] worked out really well. [12:16] >> Amazing. [12:17] >> Really, really well. [12:18] >> Yeah. Incredible. So, you you said [12:20] something there that is so um unusual in [12:26] today's world, which is AI is really, [12:28] really fun. And then the company has [12:32] such a different demeanor and view of AI [12:35] than every everybody else. And my [12:38] favorite thing that you guys say is we [12:39] build prod not god. So good. Because if [12:43] we had any other kind of like big lab [12:45] leader, they'd be like trying to even if [12:48] they had joy, they would cover [12:51] and then your view is so different. [12:54] You're like, "No, we're going to create [12:56] a way better world and it's going to be [12:58] awesome and there's going to be not only [13:00] are there not going to be less jobs, [13:02] there'll be more jobs and there'll be [13:03] way better jobs and everybody's going to [13:04] have a great time and like just be being [13:07] around you like you clearly believe [13:10] that." So, so tell us about that and [13:12] like what this because for us, you know, [13:14] type safe Jev, it's it's more than a [13:16] company. It's a it's a whole movement [13:18] towards a positive future that most [13:21] people in the AI world kind of don't [13:24] like. [13:24] >> Yes. [13:25] >> Or or or or they're not with it. [13:28] >> I think they don't get it. Yes. You [13:29] know, like the it's just a classifier [13:31] complaint. It's like an ML level concern [13:33] while everyone else is having like a [13:35] Jeff party [13:37] >> because it's like holy [ __ ] like we can [13:39] do all the things that we wanted to do [13:41] and I don't I think if you don't like [13:43] get developers it'll be hard to [13:44] understand what's really going on. So [13:47] 100% I agree with that. I do think that [13:49] there's like a pretty negative world [13:51] painted that I obviously disagree with. [13:54] I think it's really comes from this like [13:57] um you know mono model Kool-Aid that [13:59] everyone believes. I think [14:01] >> right one big brain to rule them all. [14:05] That's one that's one way to the It [14:07] sounds much more ominous. [14:10] >> That's what people hear. [14:12] >> Yeah, for sure. That's what people [14:13] That's what people hear. Yeah. [14:14] >> But you know, like will that one is that [14:16] one brain really on the path to rule us [14:18] all? Like we have not automated really [14:20] basic things that I don't think we want [14:22] people to be doing, you know, like it [14:24] there's lots of really really basic [14:26] stuff. And I think that [14:29] oh man it it it pains me when the world [14:32] is discordant with the reality and like [14:35] part of the pain is you know on the [14:36] where the [ __ ] is all the automation [14:38] like how can we have AI be so freaking [14:41] smart and [14:43] >> like there's so much so much financial [14:45] incentive to automate stuff like yeah [14:46] you could make an excuse for diffusion I [14:48] don't buy it at all I shouldn't name [14:50] names but like that obviously is not [14:52] true part of the problem is like the [14:54] discordance with the reality and the [14:56] fact that AI has like so much potential [14:58] is what made it really tragic for me [15:00] that we had not released this. So now [15:03] it's a now it's like a little bit of a [15:04] party for me. But like I was afraid of [15:07] >> all dev users are like [15:10] >> there's the happy AI the people on Jev [15:12] and then there's the morose AI the [15:15] people who are not. It's it's really uh [15:18] it's quite a kind of fascinating [15:21] dichotomy. It's it is really well I give [15:25] you and and to your automation point. I [15:26] had a funny conversation this morning [15:28] with David George who runs our growth [15:30] fund because we're talking about the new [15:32] tools. I was like have you tried the [15:33] Muse thing? He's like oh it's awesome. I [15:35] was like what'd you do with it? He said, [15:36] "I finally canceled my New York Times [15:38] subscription." [15:40] And I was like, [15:42] "That that is hard to do." [15:46] >> But yeah, you know, it's a kind of a [15:49] it's a very tip of the iceberg of the [15:51] things that are horrible things to do [15:54] that that we need to automate. I think [15:56] that if we were going to be really [15:58] intellectually honest and we really [15:59] aiming for the north star of automation, [16:01] we cannot fall into the same [16:03] anti-atterns that AI has fallen into [16:05] which is really um focusing on outliers [16:08] and demos, right? Like a lot of people [16:10] ask me like what are your favorite use [16:12] cases and I'm like I'm not sure if they [16:13] work. I want them to work in the [16:15] background such that like someone would [16:17] trust that to run and not page them and [16:19] like people can build on top of that too [16:21] and like [16:22] >> composable composable [16:23] >> composable but like other things like [16:25] safe right like it's a different type of [16:26] safety where like if you want it to [16:29] actually like run with resources [16:31] associated with it with access to things [16:33] you need guarantees for that or like at [16:34] least statistical guarantees and um [16:37] >> so it doesn't go rogue breaking face [16:40] that type of thing [16:41] >> well I I don't think our models will be [16:43] doing anytime soon unless somebody like [16:46] does the software to do that which would [16:47] be very cool flex very cool flex I [16:51] should figure out how to give credits [16:52] for that but um but not in a way that [16:56] we're not responsible [16:57] >> right right [16:58] >> I'm just curious like how long has this [17:00] intuation been percolating cuz I [17:02] remember talking to you maybe in was it [17:04] 2017 [17:07] >> we did talk about that yeah [17:08] >> yeah and like and then like a lot of [17:09] these ideas were in your you know you [17:11] were talking about data being important [17:13] and you're talking about like you want [17:14] to focus on the task and like but like [17:16] so I I just like you know was this like [17:19] did you know that this was going to end [17:20] up being a classifier or was this just [17:22] an intuition that like there was just [17:24] kind of another way to view this entire [17:26] kind of AI movement [17:27] >> you know so actually a fun story about [17:31] that chat in the talk from 2017 I think [17:34] my talk was [17:35] >> actually in a very similar theme I think [17:37] it was called something like AI modular [17:39] in theory and flexible in practice which [17:41] is very software. So, I'm a little bit [17:44] consistent in that. I [17:46] >> I think that this really started right [17:48] before chat GBT. [17:50] >> Um like right when we released these [17:52] things, I did not have intuition about [17:54] this and honestly I was not even [17:56] >> I was very very pleasantly surprised by [17:59] the generalization capabilities of RHF. [18:01] >> When is this? [18:02] >> Must be end of 2021 like a [18:05] >> fourth quarter of 2021. um like we were [18:08] it was really really general like if you [18:10] read the paper it's unlike other papers [18:13] that are like trying to prove their [18:14] point. It was us actually you know [18:17] scientific methodish trying to disprove [18:19] like is it cheating and uh [18:22] >> you know my favorite query was why is it [18:24] important to eat socks before [18:26] meditating? We made sure that was not on [18:28] the internet beforehand and like the [18:30] models were able to like make plausible [18:32] humanl looking answers for this and that [18:34] to us in the team was the thing that [18:36] clicked like this is not cheating which [18:38] you should always be afraid of cheating [18:39] in ML and [18:41] >> then what really got me burnt was I we [18:43] released it um you know we did a [18:46] >> you know I'm obviously a big [18:48] capabilities guy I did a lot to release [18:51] that model I I really thought that that [18:54] model had like a decent chance of being [18:56] AGI and when it didn't that was like [18:59] when my whole world came crashing down [19:01] and I was like why? [19:02] >> Oh so you were kind of on the other [19:04] train for a bit which like the crazy [19:06] train or [19:07] >> well no I'm just like under RL [19:09] generalizes like maybe we have AGI like [19:12] >> RHF generalizes pretty well. RLVR is the [19:15] thing that doesn't generalize as well [19:16] from what I've seen. Um and [19:20] AGI in to [19:22] >> well I I was just saying more I mean [19:24] like you know you were beh in chat GPT [19:26] you were behind like these early GPTs [19:28] that was a very different goal which is [19:30] like creating a chatbot that will talk [19:31] to the human being was not a [19:33] programmer's tool etc. So I'm just [19:34] wondering like [19:34] >> oh well actually early early like 2020 [19:39] um openai when we talked about AGI [19:41] people used to describe it as Ilia and [19:43] every if statement. Um, so it's not it's [19:46] kind of like but like is that like part [19:49] we were talking about open AAI culture [19:51] part of it is that it's like [19:52] intentionally vague so it's a wide like [19:55] tent so that everyone can be inside of [19:57] it but like I am not [19:59] >> for nuanced reasons I don't think we are [20:02] on the path of RSI and I still don't [20:04] think we're in the path of RSI and I did [20:06] then I do think that what OpenAI defined [20:08] as AGI is extremely doable automating [20:11] most of the world's economically [20:13] valuable [20:14] actually sounds [20:15] >> like uh [20:17] >> oh man I don't like there's a there's a [20:19] lot of work out there a lot of it is [20:21] very wrote and simple and like by volume [20:24] in order to be able to like outsource [20:26] work you need like simple instructions [20:28] that like basic people can do and as far [20:31] as I can tell the intelligence of that [20:33] has been available in the models for [20:34] like quite a while now and [20:36] >> like my oh man you know chip on my [20:40] shoulder is like why is this not [20:42] available and and then the the and then [20:45] since RHF the AI industry just like kind [20:47] of bifurcated into gigantic overpromise [20:50] underdeliver I think GPT3 was actually [20:51] quite calibrated back in that day but [20:54] because humans evaluate how good the [20:56] models are it looks really good cuz they [20:58] are the judge but we've been optimizing [21:00] that judge instead of the automation [21:01] part and that has been the missing thing [21:03] so I would say it was really really then [21:06] that it like hit me you know like why is [21:09] this thing not more useful [21:10] >> and so you think that the measure that [21:11] we should have is to what extent Can you [21:13] automate actual productive tasks? Is [21:15] that the [21:16] >> the over when you say overpromise and [21:19] underdel? That's the dimension in [21:20] particular you're talking to. The [21:22] ability to automate tasks. [21:25] >> I like I think in my heart it's like [21:27] cool sci-fi. Um you know and I think [21:29] that I think that that is the canary in [21:31] the coal mine for cool sci-fi. Like, are [21:34] you really telling me that we like math [21:35] is solved or like even like 2 years ago [21:37] GPQA that Google proof question [21:40] answering is solved, but we still can't [21:42] handle a drive-thru, right? Like it's [21:45] it's it's it's a very hard thing to hold [21:47] in your head at once and I think a lot [21:50] of people don't have good answers to [21:51] that. [21:52] >> Yeah. Can I can I just test one thing [21:53] which which may which may not make sense [21:55] but I want I mean I mean isn't there an [21:57] argument though that like [22:00] >> the the the real the distribution of the [22:02] real world is is is different than the [22:05] digital world right it's heavy tailed [22:07] there's a lot of exceptions we don't [22:08] have all the data and I mean it couldn't [22:10] it be the case that the reason we're not [22:13] doing productive stuff in the real world [22:14] is just like we're not we don't have the [22:16] data for that distribution we're not [22:18] training on that distribution and this [22:19] is why it's just been basically [22:20] relegated to like these is lower [22:22] dimensional manifolds like whatever math [22:24] or code or [22:26] >> um I don't entirely buy the data [22:31] argument in my opinion. Um I do believe [22:34] that there's a a long tail for sure like [22:36] that that would be kind of crazy to deny [22:39] and I don't think that in my like canary [22:42] in the coal mine situation we need to [22:43] automate that long tail. Like I think [22:45] that I think we need to be incredibly [22:47] pragmatic on everything and like [22:50] building reliable software is always an [22:52] investment, right? Like it like you know [22:54] what were the three great virtues of a [22:56] programmer? Laziness to not to do it [22:58] again, hubris. And [23:01] >> there was a third one. [23:02] >> Yeah. Yeah. No, I remember this is from [23:03] the Pearl days. Yeah. Yeah. [23:05] >> Yeah. There there was a third one. [23:06] >> Very well. Yeah. I I wish I wish I could [23:08] remember it, but like it's about like [23:10] the laziness to like spend, you know, [23:12] like 10 hours to do like the five minute [23:14] task instantly and to never have to do [23:16] it again. Like it only make like it [23:19] should be an ROI decision for people who [23:21] like automate stuff. Like I would just [23:23] like it to be automatable and I think [23:25] that people will just make like new [23:28] kinds of work, hence the Jev in jeans, [23:30] new kinds of work once that stuff is [23:32] doable. But uh like as like a a [23:35] benchmark, I feel like it's useful to [23:37] see can we actually automate the stuff [23:39] that it really really looks like AI [23:42] should be able to automate. Open AAI has [23:43] been trying to automate customer service [23:44] since 2020, you know, like and it it [23:48] it's you know like it's not [23:51] >> which is pretty amazing. [23:54] >> It's it's wild, you know. It's wild. [23:56] Well, and then inside I mean inside [23:58] companies um [24:00] >> there's very little that's automated [24:02] right now like and the projects haven't [24:04] worked [24:06] >> other than programming has worked [24:07] amazing. [24:08] >> Can you can you maybe classify the types [24:10] of problems you think that are easier to [24:12] automate now because it it was kind of [24:14] interesting. So we've actually looked at [24:16] support before the current generative [24:17] wave and it was interesting. you'd meet [24:19] a company and the company would say um [24:21] we uh we answer 95% of all like you know [24:25] like help desk calls and like that is so [24:27] many [24:28] >> but then you actually look at the data [24:30] >> and you realize it's all password resets [24:33] >> and then like but if you did it by like [24:35] the uniqueness it was only something [24:36] like 50% or so so it just feels like [24:39] when you're dealing with humans and [24:40] natural systems like there's just kind [24:41] of this very kind of [24:43] >> you know like long tale of exceptions [24:46] and so to what extent did like I every [24:49] but probably every hour I have somebody [24:51] ping me and like I'm using Jeb for this [24:52] new use case. I'm like I had no idea you [24:54] know like you know and so like to what [24:56] extent did you even predict like the [24:58] broad range of use case for it like did [25:00] you assume that was going to happen and [25:01] have you been surprised by that or [25:03] >> extremely surprised did not assume it [25:05] would happen. Uh this launch was [25:08] >> like not something like if anyone [25:10] expected this they are probably insane. [25:13] Um right like it is I I don't think [25:17] someone could expect a chat GPT for [25:20] developers cuz chat GPT was for you know [25:23] like you know the normal users and [25:26] >> it's weird. I actually don't even know [25:28] what percentage of the people who are [25:30] part of the JF party are developers [25:31] themselves. I can't imagine [25:32] non-developers using it. I don't know [25:34] how they would use it. Um but even my [25:36] non-developer friends are just like part [25:38] of the party and Twitter and memeing and [25:40] everything like that. So, number one, [25:43] phenomenal. Number two, um this will be [25:47] hard to convey in this short message [25:51] because like it's been like blood, [25:52] sweat, and tears for years now. Like the [25:55] amount I care about reliability is um [25:59] it's it's a lot. Like reliability is [26:01] what this thing is. If you don't [26:03] understand that, it'll be very hard to [26:05] make like a copycat that's benchmaxed. [26:08] Like it's [26:09] >> I feel like every nine of reliability is [26:12] going to be so valuable for everyone [26:14] even if it's not the most valuable thing [26:16] market capwise because it will just [26:18] enable new applications and like we are [26:20] fighting for like all sorts of like [26:23] weird nines of reliability that like we [26:25] don't even fully understand because we [26:27] are just like you know like really [26:29] getting this like electric motor of AI [26:31] of intelligence like into people's like [26:34] workstations and they can figure out [26:35] what to do with it. What does [26:36] reliability mean in this context? Is [26:37] this is this like availability of the [26:40] model or is it like I call the model and [26:42] it returns the same thing or like how do [26:45] I think about reliability? [26:46] >> Yeah. So [26:47] >> for something that's inherently kind of [26:48] stoastic. [26:49] >> So uh not so much the former thing and [26:52] the second thing is closer like I would [26:54] describe the first thing as kind of like [26:55] uptime or SLAs's. The second thing I [26:58] would maybe call closer to determinism. [27:00] The something thirdly I would consider [27:03] more like robustness. So robustness I [27:06] would kind of describe as um similar [27:08] intelligence every time. [27:09] >> Oh, interesting. [27:10] >> Yeah. So like not exactly determinism [27:12] because I think determinism it's useful [27:13] for unit tests but not real systems. [27:15] Think about like if you add a UU ID to a [27:17] prompt, it should be the same cuz it's [27:18] the same functionally but it's not [27:20] exactly deterministic. I think that [27:22] there's a another layer of it that I [27:25] don't really know what it's called yet. [27:28] Like maybe this is what I would call [27:29] like some form of intelligence which is [27:31] it doesn't have to be the similar [27:33] function every time but it needs to be [27:35] smart every time you know like if you [27:37] were in that situation would this be an [27:39] understandable thing for a human to [27:41] think because a developer can program [27:43] around that and actually to me the [27:45] highest honor of reliability will be to [27:48] get to the point where people can [27:50] program against Jev without making [27:52] example queries like when you just trust [27:55] it you'll be in like peraflow state [27:59] And that's where [28:04] I think it's unrealist [28:10] feel free like if if it's too weird just [28:11] feel free but um it occurs to me that [28:14] actually the value of things like coding [28:17] agents goes down if you have a primitive [28:18] like this in a way which is like you [28:20] could be like you know whatever some you [28:23] know codeex builds all the software for [28:25] me but it doesn't actually use Jev and [28:26] so like the software itself it creates [28:28] is somewhat limited or you can be like [28:29] okay I as a human being I will write the [28:31] software without using a coding agent [28:33] but I've got this very generalized [28:34] primitive that makes writing software [28:36] easier. So like do you feel like see a [28:39] future where it's like the coding agents [28:40] using Jev and then you're telling the [28:42] coding agents and then do you have like [28:43] redundancy or do you feel it's like [28:45] humans hip? [28:46] >> This is more of like a coding agent [28:48] question than it is a Jev question. Oh [28:49] yeah. So my vibe is that um I'm not in [28:53] the coding minds as much as I'd like to [28:55] be. So you are you two might be in there [28:58] more than I am which is sad but my [29:01] experience is that they are really good [29:04] at syntax and really [29:06] >> they're bad at semantics. [29:08] >> Um [29:09] I would say incredibly bad at [29:11] architecture. [29:12] >> Yeah. [29:12] >> Um and so like to me architecture is [29:14] like the most human creative part of [29:16] software. So I love using coding agents. [29:19] I think that uh Jev is almost certainly [29:21] not in distribution. that would be [29:23] spooky if they trained on our user data. [29:25] Um, so it's probably not. Um, but uh I [29:29] think that when it is in distribution, I [29:30] I see no problem with like having it do [29:32] the syntax. And the thing with [29:34] architecture is that maybe the models [29:36] are actually like not just crap at [29:38] architecture, but maybe they're 50th [29:40] percentile architecture. And if you [29:42] don't know anything about architecture, [29:43] it would be fine. So these are all like [29:45] gray area tradeoffs in order for you to [29:47] navigate. And sometimes speed is the the [29:49] knob for your company or project to turn [29:52] like you're willing to do a 50th like a [29:54] 50th percentile architecture instead of [29:56] a 60th because you want to move faster [29:57] and have like codeex work overnight or [29:59] something like that. Right. [30:00] >> Yeah. Actually kind of along those lines [30:02] one of the interesting things or [30:04] phenomenons in the market already is [30:06] that you know when the coding agents [30:08] came out it was the SAS apocalypse and [30:11] all their values dropped through the [30:12] floor and then when Jev came out every [30:15] SAS company is like this is the greatest [30:17] thing ever. So explain that. [30:21] >> I I don't know what else to say, right? [30:24] Like I I think it's like quite natural. [30:26] Like in the SAS apocalypse story, um the [30:30] the story that I feel like has panned [30:32] out really poorly is that software is [30:35] very cheap and perhaps easy to [30:37] replicate, which I think I could I could [30:40] believe the former. I could not believe [30:41] the latter because a lot of the stuff [30:43] happens beneath the hood. Um I'm maybe [30:46] overly a software fanboy here. All of [30:48] us. [30:49] >> Okay. Okay. Okay. Um I didn't know where [30:52] might be the coding. [30:53] >> We have a lot of legacy around that [30:55] 100%. [30:56] >> Yeah. So I don't think that really [30:58] panned out. So SAS seems like maybe the [31:01] markets don't agree, but like I think [31:03] SAS is providing the same value it used [31:05] to. Maybe the markets are just scared. [31:07] Um but I think that SAS will be one of [31:10] the largest winners of like the whole AI [31:13] game. And I want to like work really [31:15] really well with like all the biggest [31:17] most boring most like in the know of [31:19] user problem SAS companies because I [31:23] think that they are the best positioned [31:24] to know what workflows to automate what [31:27] do people need like that's what their [31:28] bread and butter is and to spend the big [31:31] like you know software is always a capex [31:32] investment and but like you spend it [31:34] ahead of time in order to make this [31:36] experience even better that gets you [31:38] know like distributed to all of that [31:40] mass of users. So, I think that it's [31:42] going to be I'm I I'm not going to [31:44] forecast anything about the financial [31:45] markets, but I think for as far as like [31:47] a capabilities games goes, it's going to [31:50] be like an inverse apocalypse. And I am [31:52] so jazzed about it. We I should make a [31:54] name. [31:55] >> Yeah. Yeah. That Yeah, that that should [31:57] have a name. [31:58] >> SAS Palooa. [31:59] >> Oh, [32:01] that sounds a little too fun. [32:04] >> Well, all the SAS applications are going [32:06] to all of a sudden get like dramatically [32:07] more useful. And by the way, you know, [32:09] the the the kind of uh capital [32:12] investment like so much of a of a SAS [32:14] company's capital investment is like [32:16] actually getting to all the customers. [32:18] And so if you've gotten to all the [32:19] customers and then you make, you know, [32:22] not just put a chatbot on your SAS [32:24] product, but actually make the software [32:26] like way way better, um that's a hell of [32:29] a thing. I don't know if this is a [32:31] realistic dream or not, but I think that [32:33] there's a world where like the [32:36] multi-choice choice forms just [32:38] disappear, you know, like I I feel like [32:40] they are like they are always like [32:43] something mapping natural language that [32:44] usually the software already has into [32:47] like a Jeike output and I think [32:49] >> it's literally it's literally from the [32:51] 80s. It's like it's called we used to [32:53] call it 4GS. Do you remember [32:55] >> fourth generation language? Actually, [32:58] also I think this is from the 80s. This [33:00] might be an insult. I was more than um [33:02] the like I think that do what I mean is [33:05] going to like be taken to the absolute [33:07] next level. If I could shout out one Jev [33:09] application, I don't know if it's [33:10] reliable, so I can't promise anything, [33:12] but it was so freaking cool. Someone was [33:15] using like a voice to control your [33:18] computer and it was basically constantly [33:19] making decisions on like is this a [33:21] command or is it inserting text? Where's [33:23] inserting text? Like like that sounds so [33:26] unbelievably cool. Like like I feel like [33:29] interfaces could like just completely [33:31] change and maybe we're going to have to [33:32] make it like cheaper and faster, you [33:34] know? [33:34] >> Yeah. Then you're at Star Trek. [33:37] >> Well, [33:39] you know, there's there's just such a [33:40] profound intuition here, which is um um [33:43] you know, if if you use AI today to [33:46] generate software, right? you're still [33:48] creating the the same software that you [33:50] did before, but if you actually look at [33:51] like the average PR for a large company, [33:53] it's like 10 lines, right? Seriously. [33:56] Nove. [33:58] We actually did the study. So, it's like [33:59] 10 lines. So, like you're automating 10 [34:00] lines. And by the way, those 10 lines [34:02] are are like, you know, part of a [34:04] learning from a customer or something. [34:05] So, like you're you've kind of optimized [34:07] something that's actually pretty [34:08] minimal. Um, but what it doesn't do is [34:10] provide new capabilities to the [34:12] software, right? It's kind of automating [34:13] this thing which in the limit ends up [34:15] being relatively minor. And now like [34:17] there's actually a new capability and so [34:19] like it could just be the case that just [34:20] software just actually gets better. [34:22] Yeah. And and by the way it didn't even [34:24] before Jeff like just it didn't even [34:25] occur to me that like it doesn't matter [34:27] how much you know AI coding agents you [34:30] use the software actually isn't getting [34:31] better. Maybe you're writing it faster. [34:33] It's like arguably getting worse just [34:35] because like there's less oversight. So [34:36] I think this is [34:37] >> well and and often more insecure. [34:39] >> Yeah. For sure. For sure. But you're but [34:42] you're actually now can make an argument [34:43] like like like apps will have new [34:46] functionalities as a result of this [34:47] because there is this new primitive that [34:49] you're providing that I mean like in in [34:51] a way like it speaks natural languages [34:52] and it can reason but it marries that to [34:55] a state machine. [34:57] I if people take that as a takeaway that [35:00] would be like the greatest compliment [35:02] ever to what we are doing like I [35:04] actually feel like it's almost too grand [35:06] of a vision to expand beyond the three [35:09] logic gates that we have into like you [35:12] know it our types are kind of like one [35:14] of the same logic gate but like one [35:16] that's like a little brain in there like [35:17] that would be the greatest compliment to [35:19] like the the type safe legacy cuz like [35:21] that is that's a very non-trivial huge [35:24] thing for the world. Um, I'm not going [35:27] to like overpromise underdel that, but I [35:29] will fight for that. [35:30] >> Yeah. I mean, listen, I mean, there's I [35:32] think pretty open questions to what like [35:34] how deep can this get as far as like [35:36] like really serious stuff like state [35:37] consistency or durability or like real [35:40] systems level stuff where you actually [35:42] need to like provide strong guarantees. [35:44] And so 100% this will change things like [35:46] whatever analyzing logs, analyzing [35:48] emails, providing a UI, talking to the [35:50] human like that for sure. But like you [35:52] know you could argue that over time this [35:54] becomes like a smart database like you [35:56] know and so [35:57] >> and also [35:57] >> air traffic control system [35:59] >> which we really need. [36:01] >> True true [36:02] >> a little scary like I think automate the [36:04] easy work before the hard work is always [36:06] my philosophy but I also think there's [36:08] going to be like an entire era of [36:11] probabilistic programming that's opened [36:12] up like my [36:14] >> by the way you know there's a huge [36:15] history of proistic program that [36:17] basically died in like the 70s or I'm [36:19] familiar with it. I I I actually think [36:21] it's going to be like with the same like [36:24] you could also call Jeb like neuros. [36:26] >> So your co your co-founder Eric came [36:28] from that background. He was telling me [36:30] kind of basian. [36:31] >> Oh yes yes yes. He did a lot of biology [36:33] stuff that goes up and down but like [36:36] what I mean is a more [36:39] >> I'm not a fan my brand is pragmatism. [36:42] Incredible pragmatism. I'm not a fan of [36:44] like biologically inspired stuff um at [36:47] all. [36:48] >> This never worked. Have you ever noticed [36:49] that? I mean I I think it's never [36:51] worked. It's useful to motivate crazy [36:54] people to work on things for decades [36:56] until it works and then they refine it [36:57] into like the engineering [36:58] >> the story of AI neural nets for sure. [37:01] >> Yes. But like you know a lot of the [37:03] stories about how it worked were not [37:04] accurate right so like the hierarchical [37:07] features of applications really did end [37:08] up working cuz like otherwise resets [37:10] wouldn't have worked. longer story. Um, [37:13] I I do think that it opens up like like [37:15] from a systems perspective. I'm not [37:17] excited about this part cuz it's really [37:19] I'm excited for the world, not about me [37:21] programming this cuz it sounds like [37:22] really complicated. But I think that as [37:24] we have like lots of intelligence at [37:26] lots of uh like different cost and speed [37:29] trade-offs, the super systemsy types [37:32] will be be making trade-offs at like you [37:34] know like dev is going to be like a [37:35] thousand times too smart for them. They [37:36] just want like an approximate link to [37:38] have an approximate guess to like [37:40] optimistically route here and there. [37:41] It's gonna be like so crazy the the type [37:44] of stuff that's available in the extreme [37:46] systems [37:46] >> and the and the good news is we get to [37:48] like rebuild systems again which is [37:49] great right we have a new no seriously [37:51] we have a new primitive it's kind of a [37:52] new way think about doing software like [37:54] I mean we did listen we did this with [37:55] the internet you we did this main frame [37:57] to client server I mean we do this [37:59] periodically and and by the way just [38:02] because of the um cyber security issues [38:05] we probably have to rebuild almost all [38:08] the systems uh to to just make them [38:10] safe. I I would think [38:13] >> I think it's pretty clear that there [38:14] like there's not no [38:15] >> or at least the critical the the [38:17] critical infrastructure for sure. [38:19] >> Yeah. [38:19] >> Yeah. Yeah. Do you do you think about [38:21] this more in terms of like apps, SAS, [38:25] analytics or [38:27] more in terms of like systems [38:30] foundations or all the above [38:31] >> for what I would think of or how [38:34] >> just general application for this when [38:35] you think about like like you're working [38:36] on Jev and like and you kind of envision [38:39] that people are adapting it like how you [38:41] know like do maybe do you even have an [38:44] opinion? I have a little bit and it's [38:48] so the way I think of it is a little [38:51] like uh like deep into like the TCP [38:53] guts, you know, like UDP TCP, you know, [38:56] like it's unreliable, too reliable, [38:58] >> speaking my language. [38:59] >> Exactly. And like I I so like when I [39:01] think of AI no I mean like when I think [39:03] of AI and this is why I care about [39:04] intelligence per dollar to be clear when [39:06] I think and how I got to this conclusion [39:08] I work backwards from AI based economic [39:11] revolution AI everywhere know sci-fi and [39:14] everything like all the software has AI [39:15] all over the place and I asked myself [39:16] the question what percentage of the [39:19] calls to AI imagine it's like a function [39:22] which what percentage are like for human [39:24] consumption where you need style and [39:26] everything and yeah and it's going to be [39:27] like many nines and actually from that [39:29] same question, how many will be at the [39:32] first layer versus like deep in the [39:33] guts, right? And I think that it's going [39:35] to be many nines in the guts, but it [39:36] will start at the first layer. But like [39:38] we need to if you don't aim for the [39:39] guts, right? That sounds weird. If you [39:42] don't aim for the guts, you it's it's [39:44] going to take you a while to get there, [39:46] right? I think people don't understand [39:47] to what extent like AI was kind of [39:49] shipped in the night with software. Like [39:50] even if you try to embed AI in software, [39:53] it kind of like didn't behave, right? [39:54] because software doesn't really take [39:56] natural languages and you like do all [39:57] this weird stuff like you stick in the [39:59] prompt like here's the JSON output that [40:01] you want and here's the schema and it [40:02] would never listen to it and so and so [40:05] what you ended up doing is just taking [40:06] the output and giving it to a human [40:07] you're like the hell with it right or [40:08] another LM that is what a while loop is [40:10] like the agent while loop right so it's [40:12] like it's like from first principles it [40:13] needs to be human in the loop which is [40:15] chat [40:16] >> or an agent which is the while loop [40:18] because like the natural language needs [40:19] to be fed back into another [40:20] >> and I will say I I have watched this h [40:22] there was almost like this kind of like [40:24] five stages of grief that like you know [40:27] people would pick up AI and like I'm [40:28] going to use this you know within my [40:30] software right and then you know and [40:31] then it would like go with like you know [40:33] whatever denial like try to make it work [40:35] and like anger then they go to [40:37] acceptance which is like okay never mind [40:39] I'm just going to give this to another [40:40] LM to a human being so it's been very [40:42] ships in the night I think this is the [40:43] first time I have seen it's almost like [40:45] actually you can take an LLM you can [40:47] take AI and you can actually map it to [40:49] like like a state machine and you can do [40:51] that productively [40:53] And I hope so. I will not want to [40:56] overpromise underdeliver as well. Like I [40:58] don't know if it's ready for all the [41:00] applications that have been [41:01] overpromised. I really really want it to [41:04] and my team will fight for that [41:05] obviously. Like we [41:08] >> really really care about reliability. We [41:11] could have released so much sooner. I [41:13] don't think people realize that and I [41:16] don't think that honestly I don't think [41:17] that they will based on what I see off [41:19] the Twitter discussion. I think it's [41:20] people will never get it, but like it'll [41:22] just have like that good vibe of like, [41:24] oh, I can trust this. So, [41:26] >> it's the anti- frustration machine. [41:30] >> It's it's a I hope so. I hope do what I [41:33] mean, right? Like to me that is about [41:36] like smoothness in the world, like [41:38] having everything like just move more [41:40] smoothly together and interlink like a [41:42] gears. I actually have my whole like AI [41:45] utopia on like different axes that I [41:47] really really want and like do what I [41:49] mean is a huge part of this, you know, [41:50] like imagine if all technology just did [41:53] what you mean. [41:54] >> That is like that's not sci-fi. Look how [41:56] smart AI is, right? [41:57] >> Yeah. No, it's a it's amazing. And and [42:00] maybe that's the thought to close on. [42:03] Oh, [42:03] >> do what I mean. [42:04] >> Yeah. I love it. [42:05] >> Thank you, Dio. This has been a great [42:07] conversation. Really enjoyed it.