TypeSafe's Founder on Jev: What Is Jev, and If AI Is Absurdly Smart, Where Did All the Automation Go?

This interview is out to convince you of one thing: what AI has lacked these past two years isn't intelligence, it's the ability to actually live inside software and get work done. Jev, built by TypeSafe founder Diogo Almeida, is the missing part meant to close that gap.

This piece follows the a16z interview published on September 28, 2026, in which Ben Horowitz and Martin Casado talk with Diogo for 42 minutes. Where the interview is thin, I fill in from TypeSafe's official launch blog post and Latent Space's long interview with him. The outside criticism comes from a KDnuggets commentary and Hacker News discussions. Everything is attributed inline, and sources are listed at the bottom of the page.

What he thinks has gone wrong

Diogo opens with an expletive-laced question: where the hell is all the automation? His point is that AI is absurdly smart, yet outside of chat and coding it has barely helped with anything. He is careful to say he isn't knocking chatbots or coding Agents; he loves using both. To him, it's "sad" to be holding a pile of uncut gems that haven't been polished enough to do real work.

The conversation offers a few concrete pictures.

Inside the enterprise. One of the hosts says OpenAI has been trying to automate customer service since 2020, yet very little inside enterprises has actually been automated, and the projects haven't panned out. Coding is the one exception.

Customer service's "95%." Diogo recounts his work on customer service before the current wave of generative AI: one company claimed it answered 95% of its help desk calls. That seemed far too high to him, and when he looked at the data, nearly all of them were password resets. Measured by how distinct the problems were, only about 50% were really being resolved. His conclusion: whenever you're dealing with people and natural systems, there's always a very long tail of exceptions trailing behind.

Annoying chores. One host tells a small story: David George, who runs their growth fund, tried a new tool (it sounds like "Muse" in the transcript), and the first thing he used it for was finally canceling his New York Times subscription. The host says this is just the tip of the iceberg; all these "annoying to do" tasks need automating.

"Slow diffusion" is no excuse. When someone suggests that new technology simply takes time to spread, Diogo says he doesn't buy it at all: AI's potential is enormous, and so is the economic incentive to automate.

He goes further in the Latent Space interview: if models can really do most of the economically valuable work in the world, then someone has to answer why they can solve hard math problems yet complete almost no economically valuable work. His read is that every lab's models are still at roughly zero on this, and even if it has started, it's under 1%; when it really happens, it will show up in economic statistics.

His diagnosis: you get what you optimize for

His own turning point. In the interview, Diogo explains how he came to see this. In late 2021 he was amazed by how well RLHF (training models with human feedback) generalized. His team even ran experiments to try to prove it was "cheating," asking questions you couldn't look up online, like "why should you eat socks before meditating," to see whether it could make up a plausible answer. He says he was a "big capabilities guy" back then and genuinely thought that model had a shot at becoming AGI. Then he realized it wouldn't, and his worldview collapsed overnight. The official blog puts it more directly: at OpenAI he helped create the methods that taught language models to follow instructions and chat with people, which became the research behind ChatGPT. At the time he thought chat models might lead to AGI, but soon found there was "a very big piece missing." (Latent Space's intro notes he is a co-author of the InstructGPT paper.)

His verdict: the judge got optimized, not the task. His view of AGI is pragmatic. AGI as OpenAI defines it, automating most economically valuable work in the world, strikes him as very achievable, because a lot of work is mechanical and simple. Any job that can be outsourced already has to come with simple instructions an ordinary person can follow, and as far as he can tell, models have had that level of intelligence for a long time. What nags at him is why it still hasn't happened. His explanation: after RLHF, the industry split into "overpromising and underdelivering." Models are judged by people, so they look great; what got optimized was the judge, not automation itself. He treats "can we automate the things that obviously should be automated" as the canary in the coal mine: math has been "solved," GPQA, a Google-proof Q&A benchmark from two years ago, has been solved, yet drive-thru ordering at a fast-food restaurant still doesn't work.

In the Latent Space interview, he reduces this to a formula: whatever you use as the training objective is what the model becomes. The three mainstream training approaches each have a different objective (the table combines what he says in the official blog and the interview; the last row is the interview intro's summary):

RLVR means training with verifiable rewards. RLCD is TypeSafe's own training method, short for "reinforcement learning for calibrated decisions"; the interview intro says the technique hasn't been published yet. He says RLVR has produced astonishing results from a model's "System 2" (slow thinking), but that ability is brittle and "jagged," whereas a pretrained model is fundamentally a "System 1" (fast intuition) thinker.

Why chat training hurts reliability. In the interview he gives a technical explanation that's somewhat convoluted. The gist: there's a counterintuitive fact about string generation. The longer a piece of text, the more likely it is to contain an error. That seems mathematically obvious, but it doesn't hold in practice. The reason is that to avoid mistakes over very long text, the model has to become extremely conservative, and that conservatism breaks the model's probability "calibration" (whether how confident a model says it is matches how accurate it actually is). He calls this mode collapse, meaning the model only outputs a handful of the most common answers. His conclusion is that using string models to make decisions is "a terrible thing." This is his opinion; the interview gives no experimental data.

His view on "runaway" AI. He also says in the a16z interview that, for some subtle reasons, he didn't think then and doesn't think now that we're on the path to RSI (usually meaning recursive self-improvement of AI). In the early days of OpenAI, people described AGI as "Ilya plus every if statement," a deliberately vague phrase: a big tent that anyone could fit into.

One host pushes back: could it be that real-world data is heavy-tailed and full of exceptions, while AI is mostly trained in low-dimensional worlds like math and code? Diogo doesn't fully accept the "missing data" explanation. The long tail certainly exists, he says, but in the canary context you don't need to automate the entire tail. You have to be pragmatic about everything, and building reliable software has always been an investment.

What Jev actually is

Take the "analyzing emails" example mentioned in the interview. Software reads a customer email and has to decide which handling workflow it should go to. In the past you either wrote a pile of rules or had a machine learning team train a dedicated model. With Jev, the idea is that developers simply describe what each workflow is for in natural language, and let the model pick among them. Diogo says capabilities like this include analyzing logs, analyzing emails, providing interfaces, and talking with people.

The official blog's one-line definition: Jev is "a function call for frontier intelligence," meaning unstructured state goes in and typed, probabilistic decisions come out. It belongs to what TypeSafe calls "System One models" (named after "System 1" in Kahneman's Thinking, Fast and Slow, the fast, intuitive mode). Compared with ordinary language models, the company highlights three differences:

• It gives all its answers at once, in parallel, rather than writing them out one token at a time;
• Its output is a typed value: the developer defines the options and structure in advance, and the model can't output anything outside that structure;
• Every answer comes with a calibrated probability and confidence, and higher-confidence answers should be more accurate.

On the mechanism, one of the a16z hosts offers a summary: think of it as a library. You describe what you want in natural language, give it a state machine (a set of states, plus rules for moving between them), and it chooses what to do with a certain level of confidence. The host says this kind of "choice with confidence" is something software has never had before. Diogo doesn't object, and adds a few points:

• Technically, Jev "is absolutely a classifier." He doesn't see that as a put-down; classifiers were born to be useful.
• On new hires' first day, they draw a Venn diagram: on one side is what AI is good at, on the other is what's valuable in code, and Jev sits in the middle. That's why it doesn't output extrapolated floating-point numbers, since AI isn't good at that; but probabilities are nothing new.
• He suspects Jev might do better than a 2019 machine learning engineering team. Back then there weren't many good teams, and you had to pick one narrow use case, collect your own dataset, and build your own evals; now you can "program" on the spot in natural language.
• The interface calls the input "state," and he says that's deliberate.

The small demo below puts "state machine plus confidence" together: pick an email, see which state the software hands it to and how confident it is, then set your own threshold for "how confident before letting go." The emails and numbers in the demo are illustrative, not real Jev output.

A host follows up: is this a slider, with language-in, language-out at one end and traditional imperative programs at the other, or is it a single point in the design space? Diogo says it's a slider. His "north star" in designing it was intelligence per dollar, though he concedes that intelligence per second may be more valuable in the short term. The official blog lists response times of roughly 70 to 500 milliseconds, input at $0.042 per million tokens, and free output. The homepage claim of "193.6x faster and 444.6x cheaper" is labeled by the company itself as the high end of real-world cases; more on how those numbers were measured below.

As for the name, the official blog says Jev comes from economist William Stanley Jevons: when steam engines became more efficient, demand for coal went up rather than down. Likewise, every order-of-magnitude drop in the cost of intelligence will unlock orders of magnitude more use cases. In the interview, Diogo also mentions in passing that once these things become doable, people will create new jobs.

The reaction after launch surprised him too. He says every developer he knows called to say it was useful and fast, and every hour someone tells him, "I'm using Jev for a new use case I never expected." He thinks nobody could have predicted a "ChatGPT for developers," and even his non-developer friends are making memes about it on Twitter.

How it differs from Claude Code and Codex

This is what most people want to ask: we already have Claude Code and Codex, so why do we need this?

Diogo first acknowledges that both are great, and passes along someone else's term for them, "instant software" (the name in the transcript is Gary Tannenbaum, which may be wrong): they can build software on the spot, you program in natural language, and they're as expressive as software itself. But what he wants is "intelligent software": not automating software engineering, but expanding what software itself can do, so that things that should be automatable actually get automated.

One host puts the difference more bluntly: Claude Code, Codex, and Cursor produce code, and that code is not fundamentally different from what a human writes. It may be better or worse, but it's essentially the same kind of code as ten years ago. Jev, by contrast, is a new part available whether a human or a coding Agent is writing the code, something you can drop into code to extend what the software can do. So it's not about replacing engineers with a faster programmer; it's about letting existing engineers build better, more interesting things.

Later in the conversation, the same host offers a number to show why speed alone isn't enough: at big companies, the average PR (pull request) is only about ten lines. He says he worked at Google, and his team studied this. So even if AI writes those ten lines faster, what gets automated is a relatively minor part of software work, and those ten lines often come from some insight about the customer; the software itself doesn't gain new capabilities from it. He says that until Jev came along, he hadn't realized that no matter how many AI coding Agents you use, the software doesn't actually get better. It gets written faster, and arguably gets worse, because there's less oversight, and it's often less secure.

Another host asks an odd question: with a part like this, will coding Agents lose value? Diogo says that's more of a question for coding Agents. In his own experience, these tools are good at syntax but not semantics, and especially weak at architecture, sitting at around the 50th percentile. If you don't know architecture, that's good enough, and sometimes speed is the knob that matters.

In the Latent Space interview, he criticizes today's coding Agents from another angle: they're built on "a single model," locked into one model, with state that can only keep getting appended, so there's no way to use cheaper intelligence for subtasks. He has sketched out an alternative: give each subtask a cheap model, manage state with a labeled task tree, and have parallel sub-Agents share state, coordinated by intelligence rather than simple locks. He says there's a lot here worth rethinking.

How to use it reliably

First, why AI has never made it into software. This is one host's analysis. He says people don't understand how AI and software "missed each other": even if you want to embed AI in software, it won't cooperate, because software doesn't take natural language. You write in the prompt, "I want JSON output like this, here's the schema," and it often doesn't comply. So in the end there are only two paths: hand the output to a human, which is chat, or hand it to another large model, which is the Agent while loop, because the natural language has to be fed into the next step. He says he's watched this process play out like the five stages of grief: first denial, desperately trying to make it work, then anger, and finally acceptance: fine, just hand it to a human or another large model. He says this is the first time he's seen anyone say you can actually map AI onto a state machine, and have it really work.

Put the three paths side by side, and the difference is "who makes the final decision."

Next, the usage Diogo teaches: break it into many small questions. In the Latent Space interview he says Jev queries should be written as explicitly and structurally as a program, with questions kept as literal as possible, because programming is all about being executed exactly. His example is refusals: don't ask "should this be refused?" Instead, break it into many independent questions, each covering one specific situation with its own threshold, and let your code decide what to do in the end. The payoff: when you find something going wrong, you add a question and a threshold, record it as a test case, and that problem is solved for good. The software won't "rot" as the context grows the way instructions stuffed into a prompt do. He calls this "machine learning without machine learning."

The demo below uses refunds as an example (not his original example; it only borrows his three steps of adding a question, adding a threshold, and adding a test case) to show how "one big question" and "broken apart" differ when something goes wrong:

Finally, his bar for "reliable." A host asks whether reliability means the model's availability, or the same call returning the same result. Diogo breaks it into three layers:

• Availability: whether you can call it at all, which he refers to as uptime or SLA;
• Determinism: whether calling it twice returns word-for-word identical results;
• Robustness: roughly the same level of intelligence every time.

He says the third layer is closest to what he wants. In his view, determinism is useful for unit tests but isn't the right north star. The way they test robustness is to stuff an irrelevant random identifier into the prompt (he calls it a nonce in the Latent Space interview and a UUID in the a16z interview); semantically it's the same question, so the outputs should be similar. What he wants is not the same function every time, but something smart enough every time that people look at it and think "that's a reasonable response," so developers can confidently program around it. In the Latent Space interview he also says you can build deterministic models, but that means lower intelligence per dollar.

Try the same email under three scenarios and you can see how the three layers of reliability differ (again illustrative, not real output):

His "highest honor" for reliability: people can program directly against Jev without writing example queries anymore. He also says every additional nine of reliability is very valuable, even if it's not the part worth the most in market cap, because it spawns new applications.

His bar for "what counts as reliable" is also fairly demanding. Asked about his favorite use cases, he says he isn't sure they really work. What he wants is something that can run in the background, that people can trust, that won't wake anyone up in the middle of the night, and that others can build on: in other words, "composable." He says the AI world has fallen into an anti-pattern: fixating on extreme cases and demos. In the Latent Space interview he also floats an idea he admits he's unsure about: calibration plus model cascades, where you use a small model when it's very confident, escalate to a bigger model in the middle zone, and keep going up layer by layer.

The outside view: some sharp criticisms

None of these come from Diogo. They're outside views, included here because they directly affect how you should judge Jev.

"Zero hallucinations" means "zero out-of-bounds answers," not "zero errors." The official blog says "Jev doesn't hallucinate." Both the KDnuggets commentary and HN discussions point out that if your options are billing, technical, and sales, it can't suddenly answer "legal," because that answer isn't among the options; but it can still file a question that should be "technical" under "billing." The company's own wording is actually more restrained: type errors are mathematically impossible, and that figure isn't measured, it's guaranteed.

"Isn't this just a classifier?" The KDnuggets author, who has worked on classification and language models for years, says classification, zero-shot classification, calibrated probabilities, and using small specialized models to save money are all old ideas; what may really be new is the architecture, training, and product rebuilt around this kind of task. Diogo himself says in the interview that Jev "is absolutely a classifier," and doesn't dodge it. Some on HN also say they did similar things with BERT long ago.

The numbers come from in-house evals. The official "faster and cheaper" claims come from TypeSafe's own "workflow evals": the reference answers are an average of GPT-6 Astra and Fable 5.1, the questions were built by their own team, the company admits there may be bias, and says the multipliers represent the high end of real-world cases. KDnuggets also notes that the roughly 68% the company reports is "agreement with frontier model answers," not real accuracy; the independent tests so far, such as 96.3% on one fact-checking test and a classification test on 275 documents, are all small in scale. The company also says its speed figures were run from a laptop on the West Coast, and that it can't prove its pricing isn't subsidized; that will have to be proven over time.

Is there a moat? One HN thread argues OpenAI could easily follow: Jev has no other moat, it's just that nobody had packaged a model this way before. Others counter that what matters is that it got the interface right, not whether there's a moat. Both are just commenters' opinions, and I haven't verified them.

Diogo's stance on the skeptics: the official blog says "we love skeptics, we are skeptics too," and admits some claims can't be proven. In the interview he also says he doesn't know whether Jev can already deliver on every overhyped application, only that the team will work like crazy toward it.

Two controversial positions

No refusals. In the Latent Space interview, he explains why he opposes safety alignment at the API layer: to him, a refusal is a "type error." In chat, being refused is merely annoying. But if the model is buried in a software dependency, where nobody knows what's inside, and it randomly refuses because a user sent a weird message, the software randomly breaks. He says safety alignment makes sense for chat products, because there you're acting on someone else's instructions (OpenAI's, Anthropic's), but it's unacceptable at the API layer, because developers need to program around it. The host pushes back: what if it's used to kill people? He says of course he hopes it won't be used for things like that, and he'll push hard elsewhere, but he won't bake values into this technical layer, because every time you make a model cater to some odd objective, you "fracture" its intelligence. He thinks intelligence will look more like a database than a coworker, and a database shouldn't check what users do with it. This position is controversial; I'm only reporting it, not judging it.

Ignoring public benchmarks. In the Latent Space interview he says public benchmarks are easy to game; every lab used to have teams dedicated to collecting data that "looks like MMLU." In the long run, trust comes down to "vibes," plus testing it in your own workflows. The official blog does exactly this, using its own "workflow evals" rather than general leaderboards. The cost is that outsiders find it hard to verify independently, which is exactly where the criticisms above come from.

What it means for different people

For developers: a new part you can drop into your own code without training a model first. His hope is that people program directly against it instead of endlessly tweaking prompts. Early use cases from the company and outside users include Agent routing (one developer reported decisions taking between 145 and 271 milliseconds), model routing, and browser Agents.

For SaaS companies: One host says that when coding Agents came out, there was talk of a "SaaSpocalypse," and valuations plunged; after Jev came out, every SaaS company said it was the best thing ever. Diogo says the weakest part of the "SaaSpocalypse" argument is "software is cheap and easy to copy": he believes the first half but not the second, because software sits on top of a lot of legacy baggage. He actually thinks SaaS will be one of the biggest winners of this AI wave: the biggest, most boring companies that understand their users' problems best know exactly which workflows should be automated, and a large share of their capital investment already goes into reaching all their customers. Now they can make the software itself dramatically better, rather than just bolting a chatbot onto the product. He says he doesn't make predictions about financial markets and is speaking about capabilities, and calls this an "inverse SaaSpocalypse."

For everyday users: He has imagined that multiple-choice forms may disappear, since they're always mapping natural language that already exists in the software into something like Jev's output. He mentions something from the 1980s called 4GL, which also tried to let people write programs in something close to natural language. He thinks interfaces may change completely, but only once this gets cheaper and faster. He also says intelligence may fade into the background like regular expressions, no longer drawing attention.

For systems people: He says that once there's a lot of intelligence at different costs and speeds, the most "systems-minded" people will make their own trade-offs. For them, Jev will be "a thousand times too smart" to need; they just want an approximate guess to optimistically route requests everywhere. The good news, he says, is that this means we get another chance to rebuild systems: with new building blocks, just as in the internet and client-server eras, this happens periodically. One host adds that cybersecurity issues alone may require rebuilding almost every system, and certainly critical infrastructure.

For jobs: One host says his favorite TypeSafe line is "build prod, not God": heads of other big labs would hide it even if they were privately pleased, while TypeSafe's attitude is that we're going to build a much better world, and there won't be fewer jobs but more and better ones. Diogo agrees, saying he rejects the doom narrative, which he thinks comes from everyone buying into the "one brain to rule them all" single-model Kool-Aid.

What's still unanswered

Diogo draws his own boundary: automate the easy work first, then tackle the hard stuff. One host points out that how deep this can go is still a very open question, for instance state consistency, durability, or systems-level work that needs strong guarantees. Diogo agrees, and says what's certain is that analyzing logs, analyzing emails, providing interfaces, and talking with people will definitely change. Further out, he says, it could eventually become an intelligent database, or even an air traffic control system, which someone in the conversation calls "a little scary." He also says that if you're going to hook it up to resources and permissions, you need guarantees, at least statistical ones, which their models can't provide in the short term unless someone writes software to do it.

He also mentions a few points about direction: probabilistic programming has a long history and fell out of favor around the 1970s, and he thinks there will be ups and downs this time too; his own label is "extremely pragmatic," and he doesn't like biologically inspired approaches, saying they've never worked; and he says he's excited for the world rather than wanting to code this whole thing up himself, because it sounds too complicated.

Who he is

His path is a bit unusual. He came up through math competitions but says he never really liked math; he found computer science "like math, but cool, useful, and fun," and identifies more as a computer scientist than an AI researcher. He broke into the field by winning a Kaggle competition, not through advanced math but through relentless automation; afterward he had to give a talk at NeurIPS, which was supposed to be an honor but which he hated, since he just wanted to keep his head down and work. He went on to co-found a startup with Jeremy Howard, spent time at Google Brain, and then worked at OpenAI. The official blog says TypeSafe spent two years in stealth before launching Jev.

At the end of the interview, he sums up what he wants in four words: do what I mean. That, he says, is a frictionless world, where everything meshes like gears; imagining all technology doing what you mean isn't science fiction.