Jev and TypeSafe: Making AI Reliably Execute Software Intent

"Where Is All the Automation?"

This conversation between an investor and TypeSafe founder Diogo opens with a slightly exasperated question that sets the tone for everything that follows: "Where did all the automation go?" AI has become breathtakingly capable, yet it remains nearly useless in real work environments. Diogo doesn't dismiss tools like ChatGPT, Claude Code, or Codex — he's a heavy user himself — but he sharply identifies a truth most people overlook: AI intelligence and software automation have long been "ships in the night."

OpenAI started experimenting with automated customer service as far back as 2020. The financial incentives were enormous and the technology was already there, yet the amount of work actually automated inside enterprises today remains shockingly small — with almost no success stories outside of coding. Diogo describes this gap between ideal and reality as "tragic" — we're sitting on a pile of unpolished gems, yet all we can do is bolt a chat widget onto the side of our software that sometimes works and sometimes we're too scared to let run.

Jev Is Not a Faster Programmer — It's "Smarter Software"

Understanding what makes Jev different comes down to distinguishing between two fundamentally different approaches. Diogo references Gary Tan's description of Claude Code and Codex as "just-in-time software" — tools that can generate code on the fly in natural language, but the code they produce is essentially no different from what was written ten years ago. "No matter how many AI coding assistants you use, the software itself doesn't get better — you're just writing it faster," he says. "It might even get worse, because there's less oversight and it's often less secure."

Jev takes a different path: rather than replacing engineers with a faster (but not necessarily better) programmer, it expands what the software itself can do, turning tasks that "should have been automatable" into tasks that actually are. Diogo describes it as an entirely new programming primitive — like a library where you describe your intent in natural language, hand it a state machine, and it makes confidence-weighted decisions inside the software. Whether it's called by Claude Code or by a human, this primitive injects a layer of intelligence into code that simply didn't exist before.

He points out an interesting design detail: Jev deliberately calls its input "state" rather than "input" — a conscious choice meant to convey that it handles the intelligent orchestration of program-internal state, not just a "language in, language out" transformation.

A State Machine is a classic computer science abstraction that describes how a system transitions between a finite set of states according to defined rules — for example, an order system might move through discrete states like "pending payment → paid → shipped → completed." Traditional state machines use hard-coded, deterministic transition logic. Jev's innovation is to delegate the transition decision itself to a language model, allowing the system to intelligently choose its next state based on a natural language description of the "current state," rather than requiring the programmer to pre-write every branch. This design turns what would otherwise require extensive if-else chains or rule engines to handle ambiguous business logic into a dynamic process driven by intent descriptions. Diogo deliberately uses "state" instead of "input" to emphasize that Jev operates on the semantic meaning of business state inside a program, not merely performing text transformations.

"Jev Is Just a Classifier" — And That's Exactly the Point

When confronted with the challenge that "Jev is just a classifier," Diogo doesn't flinch: "Jev is absolutely a classifier, and classifiers are awesome." On a new hire's first day, he draws a Venn diagram: what AI is good at, and what's valuable inside code — Jev sits at the intersection. So it won't output extrapolated floating-point numbers that AI isn't suited for, but it will handle concepts like probability, which are "not new but extremely useful."

He makes a bold claim: Jev is likely more useful than a custom system a machine learning engineering (MLE) team would have built for you back in 2019 — back then, building such a system required collecting datasets, running evaluations, and tuning models, with extremely high barriers and scarce talent. Now you can achieve the same capability in what amounts to "programming in flight." Behind this is his north star metric: intelligence per dollar, rather than the more flashy "intelligence per second."

On where Jev sits in the design space, Diogo admits his mental model is a "slider": one end is today's "language in, language out"; the other end is traditional imperative programming; and Jev is "language in, state machine out" — an attempt to find a solid footing on this spectrum for general-purpose programming.

The Intelligence per Dollar metric represents a pragmatic reframing of the economics of AI deployment. MLE teams around 2019 were an extremely scarce resource: building a production-grade classification system often required months of data labeling, model training, A/B evaluation, and infrastructure maintenance, with total costs easily exceeding seven figures and heavy dependence on hard-to-hire specialists. Large language models made zero-shot classification possible, but API call costs and inference latency remain core bottlenecks for scaled deployment. By using "intelligence per dollar" rather than "intelligence per second" as his north star, Diogo is saying: what truly matters to enterprises isn't how fast the model runs, but how many previously unautomatable business decisions a given budget can unlock — which directly shapes Jev's trade-offs in pricing and architecture.

Reliability Is Jev's True Moat

Throughout the conversation, Diogo repeatedly returns to one word: reliability. He says the product could have shipped much earlier, but extreme attention to reliability is exactly why it was held back for years. He breaks reliability down into several layers: the first is close to "uptime/SLA"; the second is closer to "determinism" (same input returns same output — suitable for unit tests but not fully applicable to real systems); the third he calls "robustness" — not requiring the function to be perfectly consistent every time, but requiring it to be smart enough every single time.

He offers a precise example: if you add a UUID to a prompt, functionally you should get the same result. Real systems don't need mechanical determinism — they need stable, "intelligent every time" performance. The highest honor for reliability is getting developers to trust it enough to program directly against it without writing sample queries first, entering a "permanent flow state" of software creation.

Diogo believes that every additional "9" of reliability unlocks entirely new application scenarios. He gives a striking example: someone using voice control for their computer, with Jev continuously determining "is this a command, or text to be inserted" — exactly the kind of application that transforms interaction paradigms, made possible only by reliability. He's also candid enough to admit he can't guarantee every demo is actually reliable, which reflects his refusal to "over-promise and under-deliver."

Software engineering commonly measures system availability in "nines": 99% (two nines) means roughly 87 hours of downtime per year, 99.9% (three nines) about 8.7 hours, 99.99% (four nines) about 52 minutes. For traditional deterministic code, testing and debugging are relatively straightforward. But "reliability" for AI components is far more complex — the same prompt can produce different outputs in different contexts, and this inconsistency gets amplified into cascading failures inside automated pipelines. Diogo's distinction between "determinism" and "robustness" confronts this challenge head-on: pure determinism is neither realistic nor necessarily desirable for LLMs. What's truly needed is a quality floor where every call reaches a "good enough" decision threshold, allowing developers to trust it like a standard library function and build systems around it without adding defensive checks at every call site.

From "SaaSocalypse" to "SaaS Celebration"

The market has sent a telling signal. When coding agents first emerged, the industry cried "SaaSocalypse" and SaaS company valuations collectively tumbled. Yet when Jev appeared, SaaS companies responded by calling it "the greatest thing ever." Diogo's read on this: the SaaSocalypse thesis was built on the premise that "software is cheap and easy to replicate" — the first part may be true, but the second is dead wrong. Enormous value is buried under the hood and is extraordinarily hard to replicate.

He believes SaaS will actually be one of the biggest winners of the entire AI wave. SaaS companies understand their users' real workflows best, know better than anyone what should be automated, and have already made the massive capital investments to reach huge customer bases. When they stop just bolting a chat widget onto their product and instead use Jev to make the software itself "dramatically more useful," they'll experience a "reverse SaaSocalypse." He even envisions that things like multi-select forms might disappear entirely — they're fundamentally just a way of forcing capabilities the software already has into an artificial human-facing language.

A Pragmatist Who Treats AI as a Tool for Programmers

Diogo's background is distinctly unconventional. He describes himself as a former award-winning math competition student who "never really liked math," only finding his passion after turning to computer science — "computer science is like math, but cooler, more useful, and more interesting." What truly pulled him into AI was winning a Kaggle competition — not through elegant mathematics but through "insane automation, nested loops to solve systems problems." He later worked alongside Jeremy Howard, spent time at Google Brain, briefly retired, and ultimately joined OpenAI because "AI was just too much fun."

His attitude toward AI stands in sharp contrast to most big-tech leaders. He champions TypeSafe's motto — "we build prod, not God" — and openly states that "for many nuanced reasons, I don't think we're on the path to RSI (recursive self-improvement)." In his view, the industry's pessimistic narratives stem from a "single-big-model spell" — a belief in building one brain to rule them all. What he actually believes in is making all technology "do what I mean" — making the world run more smoothly, like interlocking gears.

On coding agents, he offers a pragmatic assessment: they're good at syntax and know some semantics, but they're "absolutely terrible" at architecture — and architecture is precisely where the most distinctly human creativity in software lives. Perhaps models are only at the "50th percentile" on architecture, which is already good enough for people who don't know architecture themselves, making it a grey trade-off between speed and quality. Ultimately he positions Jev as a new primitive worth "rebuilding systems around" — the kind of periodic reconstruction that the internet and client-server architecture once triggered — with "do what I mean" as the core vision driving all of it.