Jev and the Shift From AI That Talks to Software That Acts

1. Guest Background

This episode comes from a16z / The Ben & Marc Show, hosted by Marc Andreessen and Ben Horowitz. The episode is titled “How Jev Turns AI Into Software That Gets Things Done,” runs 2,544 seconds, and was uploaded by a16z on 2026-09-28. It is a compact but dense episode: the hosts are not merely asking for a product demo, but pressing on why powerful AI has not yet translated into broad, dependable automation.

The guest is Diogo, identified in the episode context as the founder and leader of TypeSafe. TypeSafe is described as making AI for software. Jev is presented as the company’s first model for making automation and building real software: a library-like or primitive-like capability that lets developers use natural language, state-machine structure, and confidence levels inside code. That role matters because the episode is about whether AI can become part of software’s operating logic, not just a conversational or code-generation layer around it.

Diogo’s relevant background, as he presents it in the conversation, combines computer science, systems instincts, and AI experience. He says he thinks of himself more as a computer scientist than as an AI researcher. He discusses math competitions, a Kaggle win driven by heavy automation, a startup with Jeremy Howard, work at Google Brain, and later joining OpenAI. He also describes being surprised by RLHF generalization in late 2021 and once believing a released model had a decent chance of being AGI before revising that view. In the episode, that background supports his main posture: he is impressed by model capability, but more interested in whether it can be made useful inside real software systems.

2. What the Episode Covers

The episode begins from Diogo’s blunt question: where is all the automation? His complaint is not that AI lacks impressive intelligence. It is that this intelligence often remains trapped in chatbots, coding assistants, and human-in-the-loop workflows. He says he likes chatbots and coding agents, but argues that they are still not solving the broader problem of making software itself more capable.

The hosts and Diogo repeatedly separate “automating software engineering” from “making software smarter.” Claude Code, Codex, Cursor, and similar tools can generate software on the fly and let people program with natural language. But the code they produce is still conventional code. It may be written faster, and it may be better or worse, but it does not by itself expand the expressive power of the resulting application. Jev is positioned differently: it is something a human developer or coding agent can include in code so the software has a new intelligent decision layer.

Diogo’s concrete description of Jev is deliberately engineering-oriented. He compares it to a library. A developer describes an intention in natural language, gives Jev something like a state machine, and Jev chooses what to do with confidence levels. Later, the hosts summarize the idea as a system that speaks natural language, can reason, and is married to a state machine. Diogo says that if people take that away, it would be a major compliment to what TypeSafe is building.

The episode therefore covers more than Jev’s feature surface. It uses Jev to analyze why AI has been hard to embed in software, what reliability means for stochastic systems, why classifiers and state machines may be practical rather than limiting, how AGI narratives can distract from productive-task automation, why SaaS may benefit from AI primitives, and how “do what I mean” interfaces might change applications. It also frames the old pattern as natural-language output being handed back to a person or another model loop rather than being cleanly mapped into software state. It is an episode analysis of a product idea, a systems argument, and an industry critique at once.

3. Core Views: Reasoning, Examples, and Limits

The central view of the episode is that the bottleneck in AI automation is not simply missing intelligence. It is the lack of a reliable way to embed intelligence into software. Diogo’s opening frustration only makes sense in that frame: models can appear extraordinarily smart, but much of that capability still exits as language for humans to read, code for humans to review, or agent loops that hand language back into another model. When AI output cannot be cleanly mapped into program state, permissions, actions, and failure modes, it remains adjacent to software rather than part of software.

That is why the contrast with coding agents matters. Coding agents can accelerate the production of traditional code. They can be extremely useful, and Diogo does not dismiss them. But the hosts argue that code written by Claude Code, Codex, or Cursor is still basically code as it looked before. Diogo’s answer is not to replace those tools, but to add a new primitive that either a human or a coding agent can use. In that view, the important capability is not “AI writes more files,” but “applications can contain an intelligent component that handles intent, classification, routing, or decision-making within a constrained structure.”

The classifier discussion is one of the episode’s clearest technical claims. When asked whether Jev is just a classifier, Diogo embraces the term. He argues that classifiers are useful precisely because they were designed by practical people trying to make systems work. This is not a retreat from ambition; it is the opposite of mystical AI language. A classifier-like interface, attached to a state machine and confidence levels, gives software something it can use. Natural language preserves expressive flexibility. State-machine output gives the application structure. Confidence gives the surrounding system a basis for escalation, fallback, or risk-aware action.

Reliability is the condition that keeps this from becoming another demo pattern. Diogo distinguishes uptime or SLA from determinism and from robustness. Uptime means the service is available. Determinism means the same input produces the same output. Robustness, in his framing, means similar intelligence each time. For stochastic systems, exact determinism may be less important than functional stability: if a request contains a new UUID but is otherwise functionally the same, the software should receive a similar judgment. He then gestures at a higher reliability target: Jev should be smart every time in a way developers can program around, eventually without writing example queries to check every case.

The episode’s critique of AI benchmarking follows from the same reasoning. Diogo says the industry has optimized for human judges of model quality rather than automation of real productive tasks. The hosts press on the mismatch between claims about solving hard benchmarks and the inability to automate ordinary tasks such as drive-through interactions or customer service. This should not be read as an independently measured industry statistic; it is a speaker-cited critique of the field’s priorities. Its force comes from the gap between visible intelligence and missing deployment: if the model can impress evaluators but cannot safely and repeatedly operate inside business workflows, the software problem remains unsolved.

Diogo’s view of AGI and recursive self-improvement is similarly restrained. He says he does not think the industry is on the path to RSI, while also saying that OpenAI’s definition of AGI as automating most economically valuable work sounds extremely doable. That combination is important. He is not arguing that automation is impossible or that models are weak. He is arguing that the useful path is more pragmatic: many tasks are rote, simple, and economically valuable, but they still need to be made automatable through software interfaces, reliability work, and product judgment.

The limitations are explicit. Diogo acknowledges that the real world has a long tail. He does not claim Jev solves every exception or every high-risk domain. When the hosts raise state consistency, durability, and serious systems-level guarantees, he does not present Jev as already sufficient for air traffic control or other strongly guaranteed systems. His philosophy is to automate easy work before hard work. He also warns against outlier and demo thinking: he wants systems that run in the background, can be composed by other builders, and have at least statistical guarantees when they carry resources or access. The uncertainty is not a footnote; it is part of the engineering thesis.

The SaaS discussion applies that thesis to companies. Diogo rejects the simple SaaS apocalypse story because software is not just surface code. He accepts that software may become cheaper in some ways, but does not accept that it is therefore easy to replicate. Workflows, user problems, distribution, system detail, and accumulated capital investment still matter. He argues that SaaS companies may be among the biggest capability winners because they know what workflows to automate and can distribute improvements to large user bases. He explicitly avoids making a financial-market forecast; his claim is about capabilities, not stock prices.

4. Learning and Application

The most useful lesson for builders is to stop treating AI integration as a chat surface by default. The episode suggests a different design question: where in the application does a decision already need to be made from messy, language-like input into a bounded software action? If the answer can be represented as a state transition, a label, a route, a command, or a confidence-bearing decision, then an AI primitive may be more valuable than a chatbot. The work is not merely prompt writing; it is designing the state, the available actions, the escalation path, and the permission boundary.

A practical adoption path should begin with tasks that are repetitive, valuable, bounded, and recoverable. Diogo’s ROI framing is a good filter: spending ten hours to automate a five-minute task only makes sense if that task recurs enough and the failure cost is tolerable. Support triage, email classification, log analysis, internal workflow routing, form replacement, lightweight intent detection, and UI assistance are more plausible early domains than irreversible financial actions, critical infrastructure, or systems requiring strong consistency guarantees. The point is not to avoid ambitious uses forever, but to earn trust in places where errors can be detected, contained, and improved.

Teams should also separate several kinds of reliability. Is the model available? Does it return functionally similar judgments under small irrelevant changes? Does it behave sensibly on edge cases? Does the surrounding software know what to do when confidence is low? Can a wrong action spend money, delete data, page an operator, or trigger an external workflow? Diogo’s distinction between determinism and robustness is particularly useful because many production teams over-index on repeatable text outputs. In an AI-native workflow, the more important question may be whether the same underlying situation leads to a comparable system decision.

The episode also gives a boundary for coding-agent use. Diogo says these tools are strong at syntax but weak at semantics and especially architecture. A team can use coding agents for boilerplate, tests, migration scaffolding, small edits, and glue code, while keeping humans responsible for architecture, risk boundaries, state modeling, and product judgment. Sometimes a project may knowingly accept a merely average architecture in exchange for speed. That can be a valid tradeoff, but it should be explicit. Otherwise the team may confuse faster code production with better software capability.

For SaaS companies, the most promising application is not simply adding an assistant panel. It is studying the product’s existing workflow and asking where users are forced to translate intent into rigid UI controls. Diogo’s speculation that multi-choice forms may disappear is useful as a product lens: many forms are just mappings from natural language intent into fixed output. A Jev-like primitive could, in principle, let software infer the intended action while still producing structured state for the application. His cited voice-control example makes the same point: the system continually decides whether speech is a command or inserted text, and where insertion should happen. But Diogo cautions that he cannot promise its reliability and says such systems may need to become cheaper and faster, so teams should not treat the example as proof that all interfaces are solved.

The broader application principle is “do what I mean,” but with engineering discipline. A system should shorten the distance between user intent and software action while preserving observability, fallback, and control. That means logging decisions, measuring real task completion, tracking false triggers, defining confidence thresholds, keeping humans in high-risk loops, and limiting resources until behavior is proven. It also means resisting demo-driven evaluation. A useful AI system is not the one that produces the most impressive one-off response; it is the one that can run quietly in the background, compose with other systems, and fail inside boundaries the product team actually understands.

Source

• Original episode: How Jev Turns AI Into Software That Gets Things Done