“95% Einstein, 5% Mr. Bean”: Jev’s Creator on Why AI Can’t Automate Anything Reliably (Diogo Almeida)

Thank you. Thank you. Hey.

Where do I start? I will say that a lot of those stats don't really matter for what I feel like is the Jevolution. To me, I knew it would be happening when builders started playing with it and doing the weird stuff, and especially when people were starting to make apps that they maybe could have done before, but didn't bother with because AI was so expensive. We pushed the boundaries of intelligence per second, but I think the future is going to be intelligence per dollar primarily.

And I think really getting people to play with the idea that intelligence per dollar has dropped two orders of magnitude is what will make the Jevolution unstoppable, independent of enterprise adoption, users, stats, whatever. To me, it's about people playing around with things and starting to—I can't think of a non-corny way to say it—but build the future. That, to me, is the unstoppable energy. And no matter how big that initial snowball is, it will become gigantic.

So I've been celebrating this for something like two and a half weeks now. I've actually had to do soul-searching because I think one of my big life goals has been achieved. And yeah, the stats are obviously great. Growing fast is obviously great. I love that we are also getting a lot of the distribution that we knew we would get in two years, but much faster than we thought. These are all obviously phenomenal things. But the leading indicator of it all is builders being inspired to do new things.

No one's asked me that, so that's fun. I would say I think quite contrarianly. And I think that this whole AI has a gigantic overpromise, underdeliver issue. And I think people really saw that with our launch. Like, when we first launched the video, people were like, "Oh, that's fake. It's kind of interesting, but, like, there's no way it's true." The launch really picked up when people started playing with it and showing their results. And I think that underpromise, overdeliver of our launch is what really made it take off.

And it's been—I can't think of a launch in AI that has been underpromise, overdeliver since ChatGPT. So that might be why it took off. I'm not an expert in social dynamics, so I really, really, for better or for worse, ignore the noise in the field and really focus on what I think is most important. And I just did not buy the story at all that AI was solving all sorts of problems because if you actually look at all the evidence, it's—AI is incredible and also incredibly underwhelming.

And that allowed me to really ignore all of the noise in the market.

I don't think that I—maybe the last couple of weeks have changed me. I hope not. I don't think I get really motivated by being celebrated and all of that. I actually had to do a lot of therapy just to be okay with being in our launch video because I actually, before all of this, enjoyed being in obscurity. Like, I'm a technologist through and through, I think. And what really motivated me for this is that there was clearly a gigantic technological gap and it was clearly obvious no one was addressing it.

I never had any doubt. Even when I first had this idea, long before I started the company, I wrote a document at OpenAI: we could have had AGI last year. And I still believe that to be true because how OpenAI defines AGI is a very low bar, and the models are super fucking smart. We're not really putting those facts together. And I think a lot of the people who like to commentate on the field just say, "Oh, it's a distribution problem," where that's obviously not the case if you pay attention to any real-world stuff.

So I had very little doubt. I think that we managed to get a team. Our team obviously doesn't care about—maybe there's a spectrum—but our team is not driven by the hype cycles as well, because if they were, they wouldn't have joined us. I think they really believed in our mission, or if they didn't, we had non-technical people on the team. They really believed we had a bunch of super smart people. Maybe they don't understand what the model is for, but they're like, "Holy crap, these guys are cooking."

This is worth a bet. So I don't think the team is that affected by it.

So number one, I don't think we know shit about marketing. We still do not have a marketing team. And I would actually argue that it's not like we're geniuses at marketing. My argument is that it works because our product is awesome. So actually, I think our product is carrying the marketing, despite what people say. You could call what we're doing authenticity, perhaps. We are just trying to have a good time. Our blog post yesterday was a fundraising announcement.

Someone on our team gave me a draft, and I was like, "This is the most boring thing I've ever read. But if you want, you can ship it because I would never read a fundraising announcement anyway. So you can actually put whatever you want. I don't care." And they were just like, "It'd be nicer if it was in your voice." And I was just like, "I would never—I would, like, why does anyone care about this? The product is the thing."

The fundraising tends to be an ego game. And they're like, "Enterprises will see you as more trustworthy. Recruits will see you as a more legit thing." And I was like, "Why don't we just say that directly? Hey, recruits, we're a real company. We're here to stay. Hey, big companies, we are going to be building out this enterprise platform. We are also here to stay. Look at who is investing in us."

You should trust us. And I think that maybe my intolerance for bullshit is helpful there. But I truly believe that it is not a replicable strategy. I'll give a fun side story about the fundraise. Some investors said something like, "Holy shit, that was the greatest pitch we've ever heard." And I just told them, "I don't believe you, because I've been giving the exact same pitch for years and no one cared until we had absolutely world-topping product-market fit."

And then they forced themselves to understand it because I don't think they would've gotten the pitch otherwise. So I believe the product is carrying everything right now, and that's perfect for me because that's my style. We knew this would be technological shock and awe compared to what big AI does, and that is probably what we intend to keep doing strategically.

What I would actually like to talk about is machine-native AI rather than System 1. I actually think that System 1 is more of an implementation detail to machine-native AI. And I actually think most people today think of AI in a very particular way. Like, AI is always the chat box to the side that happens to be the main character in its own little show because it doesn't play nicely with software. And I think step one for people is like, this is not ChatGPT++.

This is like AI for a completely different use case, and it's how I would do it. And I would talk about even the analogy to classifiers. I think being called a classifier is a compliment. We are not limited to classifiers, but understanding the beauty of classifiers, I think, is a necessity to understanding why what we're doing is very valuable. All.

It is directionally correct. I would actually add the nuance that I think that models not trained with latent reasoning, like the reasoning that they keep hidden, tend to be System 1 models. And AI is very strong at System 1 in general, System 1 in the Kahneman sense. And it is the reasoning training that makes them capable of doing System 2 tasks, but they're always fragile at System 2 tasks. And my claim is that AI is just good at System 1, and that is extremely valuable on its own.

And as far as I can tell, we have not come even close to solving the jaggedness of System 2. And then it would be throwing out the baby with the bathwater to say it's System 2 or bust. Yeah.

Yes. Though I would go into a big aside about software as well, and machine nativeness, and a little bit on classifiers, if I could right now. Does that sound like an okay aside to jump into?

I would talk about not that in business there's specifically System 1 decisions that need to be made. Like, yes, I think that that's how it'll start. But I would talk about how much software can do with its basic logic gates. Software can do so many things in the world, so many things. Basically all of technology from, like, what, 1980 to 2020 was driven by software. Maybe that's an exaggeration, but it feels like that to me as a software engineer.

So maybe I'm biased. And you can do so many things with these simple logic gates that just do ANDs and ORs on bits. That's kind of crazy. And software becomes big and powerful not by saying, like, there's an AND here or an OR here in a business. It's by doing a unit of work so reliably that it can become a bigger thing and then composing it together. And my claim is where AI will get incredibly valuable is not people mapping out explicitly, like, here is work, here's a job, here's the System 1 decisions.

Let's do a workflow automation on that. I think that's how it'll start, but I think that AI will explode in usage once people start taking these workflows, putting them into a box, and then now people call the higher-level boxes. And that is what software is all about.

Exactly. And you need so many. That is what I describe as composability. And the beauty of software is, like, once you spend the effort upfront to make these boxes, you can infinitely replicate them, right? Like, software is so unbelievably cool. Imagine you have Lego sets where you can build up higher-level things, but you can copy-paste them as many times as you want. That is what software kind of is for automation. And that, I think, is how you get more and more powerful properties.

So System 2 tasks are not off the table for our models. We just believe that System 2 tasks should be composed from simpler building blocks that are so reliable that they can be trusted to be built on top of, which AI so far has been incredibly non-composable. Like, it plays nicely with nothing except other AI. And that's kind of tragic. Yeah.

Can I do an easier example? Because customer service is actually quite complicated. Let me do something that is very similar to customer service but is a lot easier to think about. Like, imagine an executive assistant for your email. It's kind of like customer service, but the amount of things you can do is way simpler. And as far as I can tell, I could be wrong, like, a scheduling assistant is still not solved. I have emailed a lot of people.

I don't see automated scheduling systems. And that's kind of weird because it really looks like LLMs should solve this, right? So people have been trying for years for this, and how you do it in an LLM is you would make a big system-message write-up of all of your preferences, blah, blah, blah. And they would be incredibly good at stylistically being accurate. Like, it'll never not look like a well-written thing, but it will often make subtle mistakes, not in the style, not in the sycophancy.

I don't know how to pronounce that word. Like, it'll always be people-pleasing because LLMs are so good at people-pleasing, but it may not make the right decisions. And what people will do is they will keep programming their system prompt, like, please do this. If it's an investor, do that. If it's inbound email, do this, blah, blah, blah. So what ends up happening is you're basically programming in natural language this giant system prompt.

And as the complexity rises, the error rates get higher and higher and higher because you're just praying, model, please don't make those mistakes. And what tends to happen is it's embarrassing when those mistakes are made, or it's costly. You may not have scheduled something with an important investor or something like that. And then you need to rip the system out and toss it away and just use a human because it's just obvious what to do there, and they can ask you when they're uncertain or whatever else.

So LLMs, to my understanding, still have not solved this problem. Though I don't know if anyone has solved this with a Jev-like system yet, but I can compare and contrast the differences a bit. So what you can imagine, instead of programming in natural language, like describing, like, if it's important, blah, blah, blah; if it's from this, blah, blah, blah; if it's inbound, blah, blah, blah, you can actually make individual classifiers for each of these things, like smart if statements. Like, you can now express things that you couldn't express in software before, because how can these bit comparisons figure out if it's inbound or not, right?

Like, that's an intention, and it requires natural language common understanding. And the idea is you can make classifiers for all of these things. And you have this legible system where not only can you measure if every if statement is accurate, you know that none of those if statements will be forgotten. And if ever a mistake is made, you can add it to an eval because the system is very legible. So it'll probably start out less good than the text-based system because the text-based system has a lot of sane defaults.

It looks very reasonable because that's what it's trained to do. It's just trained to look human-pleasing, but it actually doesn't have any of the actual behavior you truly care about. And you don't have the control over that. And that is a major problem for anyone who wants to truly have something run in the background. They want to not worry about it, and they want to have control, and they want to have some idea that it's not going to just go completely off the rails.

And that is what combining System 1 models with code will enable you to do. Because code is kind of like the roller coaster tracks. You don't go off the rails. Code prevents that from happening. And similar to that, type safety, that is the property that the System 1 models have. And these things also prevent going off the rails. And because they're very legible, it becomes way easier to build these systems and just trust that they can run in the background.

Yes, and also, there's interesting nuance here where you don't just ask Jev, "Should I escalate?" Because that's a very high-level decision. It requires experience and trust with working with someone to know if you should escalate or not. The idea is that you can keep on decomposing your questions into the lowest level. We have the ability to break it down. "Oh, I want to filter out all inbound sales from my inbox, and I want to maybe filter out recruiters emailing me," right?

Because we have a specific email list for that. That might make sense, but there might be a world like, "Oh, I filtered out the wrong email. Let me add new behavior." An example is if someone else is on an email, I probably shouldn't be on that email. But if they say, "Diogo, can you look at this?" maybe I should all of a sudden see that. And this is nuanced, smart behavior that requires a smart person to think about that behavior.

So either way, a system is getting programmed either by natural language or code, but if you do it by code, it's cheaper, faster, and guaranteed to run. And the idea is you can keep on drilling down into the behavior you want as you make it more and more great for your use case, rather than with LLMs, there's only so much control you have.

Yeah. Yes. And also, actually, your note on the probabilities is also really, really great. There's a reason why we do that, and we learned this the hard way. When we shipped the OpenAI models, they don't have fine-grained controls. And what ends up happening is—I'll use the simplest analogy, which is refusals, right? Like, how does it make sense that you have a response—

Yes. "I'm sorry, I can't do that." And it's kind of crazy that for some responses, you just refresh it, and sometimes it refuses, sometimes it doesn't. That's insane behavior. And also, if you're building on top of this, your threshold for refusals might be very different, right? If you are Disney, you probably have an extremely different threshold for refusals than if you are Character.AI, right? Character.AI likes to do roleplay and stuff. Disney is very protective of their characters and IP.

It doesn't make sense to just have a discrete decision. The most powerful way to empower developers is to give them back as much information as you can so they can then choose, for their application, what the threshold is. Oh, I accidentally misclassified an email from an extremely important investor. Let me tune that threshold lower because I'm okay with false positives. I really can't stand false negatives.

Thank you. You listen to me. Hell yeah. Hell yeah.

I actually can't talk about that without the intelligence. If I wanted a faster model, I could just chop half the network out, right? And then you have something twice as fast, right? Or twice as cheap, or whatever else. So it's very hard to talk about that without intelligence on its own. Obviously, we're in a new quantum of speed because we toss out the very slow, expensive part of text generation. So we've talked about that.

We are obviously not autoregressive. We much prefer this parallel, gradual discovery of what the right thing is. But what I think people don't really realize is not just the obvious engineering part, like chopping off parts that are slow, but the you-get-what-you-optimize-for part. And we want to extract intelligence in the best, richest, most dense way out of these beautiful cognitive cores that AI already is. So I think the tragedy before our launch was that AI is so clearly unbelievable, but so useless for most things.

And it's not just that we put a plug on it. It's not just like tossing out the bad part, but also smoothing out the intelligence and making it as robust as it can be to surface that intelligence. And it can't be talked about without the other stuff.

There's a bit of an implication. Oh man, I get into my nuance and I love it. I would actually argue that it is not narrow and specific. You could fine-tune small language models to be narrow and specific, but I would argue that classification is AI-complete. The field has talked about this for a long time. A general-purpose universal verifier or classifier is absolutely AI-complete because it's easy to turn this thing into—even if you wanted text out, which I think is somewhat rare for a system—you could turn it into that if it was perfect.

So I would argue that it's not narrow and specific, it's just a different shape of intelligence. And that is its own big general branch, and there's going to be so many beautiful sub-branches of this. We have three types right now, but we are going to have so many more, and we're going to show the world why we didn't call them decision models. To me, it's about, like, how do we use these incredible compressions of human intelligence as effectively as possible?

And yeah, it's beyond just removing the obvious slow parts. Okay.

I would describe RLHF as making models chat and making models pleasing for chat.

And lots of stylistic stuff. Actually, I think a lot of the optimization for RLHF, in hindsight, looks extremely stylistic rather than, is it about being better at tapping into its facts deep in its network?

So actually, there's many different parts of RLHF. I think I started working on it perhaps at the end of 2020, but there was predecessor work, to be clear, that I would want to call out. So I think that we built on top of the shoulders of giants, and many of those predecessor works could be called RLHF as well. I'm happy to cite them now, but I'm not going to do it right now. I've cited them in other spots. The thing that made RLHF RLHF, in my opinion, is about the task, the task about optimizing for human preference and the shape of it as being text in, text out.

That, I think, is kind of on arbitrary instructions. That, to me, is the root of what originally RLHF was. At the time, we were still trying to figure out this shape. I think it's very obvious in hindsight, but there was a lot of uncertainty. We were kind of like the black sheep of OpenAI. And no one likes putting expensive humans in the loop because it's very hard to iterate on it. And we were really trying to figure out, like, hey, will this work?

Because when we were playing whack-a-mole with the issues, things kept coming up, and we kept having to solve them until we made it really general and pleasing and good. I believe that the hardest part of creating a new direction in AI is even knowing the task. So if we knew in hindsight the task should be shaped this way, it's possible it would've been way, way, way faster at this. But because of that uncertainty, it was a little bit harder to figure out, like, yes, the way to do this is data, make this diverse data.

And also, even the specification for labelers, like, here is how to label these things because this is the thing we want out. These are things that we didn't know at the time, which everyone who copied us didn't have to figure out because we had done all of the hard work of that iteration and then published it in a paper. Not to have a stab at them, but I do want to call out that a lot of the hard part is the discovery here.

And I think that that's a lot of our hard part with TypeSafe. So we are, to our best proxy, optimizing for human preferences. And that is why you never get outputs that obviously look bad, even though they might be equivalently bad to one that is just wrong. Like, you never have outputs these days, even though the models are wrong all the time, where you can just look at it and be like, this is clearly crap. Because that's punished so hard, and this really warps the probability space for these models.

And also mode dropping. The RLHF models are very stylistically repetitive. They're all repetitive in different ways, but you can kind of get a sense if you use a model a lot, like, wow, it keeps saying this thing. And that is a side effect of RLHF because RLHF heavily encourages the models to stay in their stylistic lane because that's the safe path to not get punished. And this results in a lack of creativity that pre-trained models didn't have.

Pre-trained models were wild and creative and weird, and they have all of the styles on the internet inside of them, and they sometimes just go completely off the rails, which is beautiful. And they didn't have this particular problem that I think people, from what I've seen, kind of dislike in LLMs.

With all of that, though, I will emphasize that I do believe RLHF makes the models slightly dumber at decisions than the pre-trained models. The root of the problem to me is that RLHF actually greatly increased expectations. So if you imagine how good the models are from human perception versus reality, RLHF really warped that. Because all of a sudden people were like, holy smokes, these models are really, really smart. We can do all sorts of stuff with them. And that decoupling is, I think, quite harmful to the world.

And that, to me, was my biggest worry here. The expectations for pre-trained models were very different, but because RLHF models are so pleasing to humans and they seem so smart, it makes people think, like, holy smokes, a lot of stuff can be automated. And that empirically did not happen.

Ooh. So RLVR is short for reinforcement learning with verifiable rewards—or, I don't actually know that one—but the idea is for simply evaluatable test cases, kind of like a math problem or, like, a proof or something like that, where you know an answer or, like, you want to pass unit tests. Can you do a lot of stuff in between to write code to pass those unit tests or to write math to get that final answer? And a really key part of RLVR is not just the verifiable rewards, because people have been trying to do RL on verifiable rewards for many years before RLVR was created.

It just so happened that it didn't work. So the Codex team at OpenAI was trying for quite a while, and it just never really worked because you actually needed this reasoning chain in the middle to do all sorts of creative stuff in between so that you could get answers that pass the unit tests and the math and all of that stuff. So RLVR also means training for reasoning, with this stuff in between, in the middle, where you can do arbitrarily complicated stuff sometimes.

So RLVR is a lot about passing simply evaluatable checks, and RLHF caused a massive overpromise-underdeliver based on the human feel of AI, but RLHF actually started plateauing on benchmarks. But RLVR does not plateau on benchmarks at all. RLVR crushes every benchmark because, by construction, RLVR is kind of the shape of the task if you wanted to crush benchmarks. Benchmarks are, by construction, these simply evaluatable things that it just perfectly matches the shape of, and it causes a different type of overpromise-underdeliver.

RLVR is obviously very, very cool, though. I think actually RLHF is very cool too, but I just worry about the lack of automation. And empirically, RLVR hasn't really changed automation.

It's also stochastic. It's also unreliable, and I think people like the word jagged. It is sometimes incredibly smart. The way I like to describe it is 95% Einstein, 5% Mr. Bean. And if it doesn't tell you when it's the Mr. Bean, then how are you gonna automate anything? So its jaggedness and non-robustness, I think, is the real issue with it, because it's very good at answering simple classifications too.

But if it doesn't do it reliably, how do you automate anything in the first place? And that's kind of where calibration comes in, and the models are still not very good at that.

I don't know if I would call it a post-training method because when we made RLHF, the concept of post-training did not exist. And you could call RLHF a fine-tuning method, but that undersells how much change you did to the whole process. So no one would just call it fine-tuning, even though maybe there's some technically correct way where that's 80% accurate. So I wouldn't necessarily call what we're doing post-training. I think we do a lot of weird stuff. I think that RL tends to be, again, an implementation detail of the whole task.

For RLHF, the task was not just doing RL on PPO or whatever. It's about figuring out, here's what the inputs and outputs should look like, and here's how you instruct people to do that. And here's what our North Star is, and here's how we balance the datasets to get a really good model for this thing. And for RLVR, you have similar stuff. RLVR is nothing without—it's like latent reasoning, it's reasoning chains. And then this enables you to have a new mixture of datasets. How you construct the datasets, or even what difficulty of dataset you want, completely changes with your base models and shape and all of that.

So the RL tends to be like a small slice of the whole task pie. And we did have to make a new type of training that we do call RLCD, because no one has done anything to optimize for machine-native intelligence. But I don't want it to sound like if you found the right RL algorithm, it just magically gets solved, because so many things...

So I'm going to use the analogies in the past because I think that that's an effective way to answer this. Before we made instruction following a thing, the data for instruction following literally did not exist in the world. Like, no one had, like, here's a human answering simple strings. No one had preference data from, like, outputs of LLMs to see, like, which one is better. So this straight up did not exist in the world. And in creating the task, we had to create the shape of the data, iterate on it, and also collect that data.

Similarly, for RLVR, the data in RLVR tends to be environments, right? Like these RL environments to try stuff with, like sandboxes and tools and whatever else. And those environments kind of existed before RLVR was created, but they were not useful. And there was no market for all of those datasets because no one could train on them. So similarly for us, we needed to create a new type of data, a new shape of data, iterate on that, and then actually create the data itself.

So by construction, for all of these things, these always need to be made in-house, and they always start in-house because that is how you even iterate and think about the shape of it. So we have done all of it in-house. And that, as far as I can tell, is going to stay the case for quite a long while, because the world has no idea what it's doing right now. And all the world experts are our team. So we just make it ourselves.

We obviously don't need user data. None of those things do. It always requires a lot of care for the task and really understanding what the North Star is.

I would actually argue that all of the great methods of training fit in the exact same way, which is they are novel tasks. I'll walk you through it first, though. Sutton's Bitter Lesson, roughly paraphrased, is that compute and scaling matter more than algorithms. When people are Bitter Lesson-pilled, scaling law-pilled, et cetera, this often means: why does it matter what algorithms we do? Let's just scale it up and throw more compute at the problem. I would argue that this is an oversimplification, specifically for the kinds of RL environments that Sutton used to work on at the time.

RL is often done in games, and in games there's no question about task and data because these are all functions of compute. But in the real world, you can't really do anything with compute without data. You can't continue to scale pre-training on the internet because we've run out of internet data. And data is obviously the most important thing there. But in order to even know what the data should look like, you need the task. You need to know the shape of the task.

You need to understand it. This task needs to be linked to valuable things in the real world. And the simple way of explaining it is: you get what you optimize for. Everyone seems to intuitively understand this except for machine learning researchers because they don't like to think about that. But you get what you optimize for, and you need to know what you optimize for. And once you do know that, you can then make data, scale compute, and have fancier algorithms.

So RLHF is, to me, a task. Making models good at instruction following in chat is a task itself. It has its own shape of data, its own algorithms, its own compute, et cetera. But the biggest bang you get is always from even figuring out the task in the first place. ChatGPT, compared to pre-ChatGPT, was the largest jump in chatbot intelligence ever because it was kind of like an adult battling toddlers. RLVR too, Q* and o1 were in a league of their own.

They weren't really used for anything useful in the world, but they were truly in a league of their own in terms of benchmarks. That's incredible. It was like the equivalent of the adult to the toddlers. And similarly, because we are the only ones optimizing for machine-native intelligence, it is kind of like the adult-versus-toddler situation where we're in a league of our own, at least from a reliable machine-native intelligence perspective, because we're the only ones doing the whole thing.

We do use a combination of models. Pre-trained models have a lot of compressed intelligence in them. They're very text-shaped. So we need to do some disgusting things for it. That's why I don't say what we do is post-training per se, because, again, these disgusting things, I wouldn't call it post-training as someone who likes post-training. It's kind of a bastardization of post-training. I don't think post-training people would want to be associated with the terrible, terrible things we do.

But there's just a lot of intelligence in the variety of open-weight models that we can link up and MacGyver into this great intelligence. So we do use that. Yeah. But everyone knows that we raised less than $40 million until recently. So it's either we've had an absolutely tremendous breakthrough in pre-training, or we just are more resourceful than other people. I think it's the latter. But we did not do pre-training. And honestly, I think pre-training is a giant dumpster fire of wasting resources.

So I hope to never do so. But who knows what the future will bring.

ML people, especially researchers, really miss the value of Jev still. And that's really good for us because it's not fancy ML. And "it's just a classifier" is among the dumbest criticisms, in my opinion, because classifiers, again, classifiers are not a form of old-school machine learning. Certain types of classifiers are, but classifiers are an interface. They are the shape of putting intelligence into software systems that's useful, right? Like, how does Facebook work? Classifiers. How does TikTok work?

Classifiers. How does Google work? Classifiers. It's not like a bad thing at all, because in order to make software more powerful, software can do so much with its dumb little bit comparisons. You want to put your intelligence into branching in your code in order to do complex behaviors. And the way to do that is to influence the branching via intelligence, which is what classifiers literally are. So classifiers, what we're going to do is not only classifiers, but we've started with classifiers because they are super-duper useful.

It's an incredible compliment to say it's a classifier. And actually, this would not be a fair way to describe Jev, because it's too much of a compliment if we said that Jev was equivalent to anyone having, like, a 20-person machine learning engineering team from 2019 to build every single thing you think about on the fly, and it's instantly done. But actually, it's smarter than that because we have better models today than we did then. And, like, I don't know if we're there yet, but that's a hugely awesome compliment.

And machine learning people don't get that because they're too busy trying to do the least valuable part of The Bitter Lesson, which is algorithms. And they keep trying to build their god in a data center rather than solving real problems and seeing the real world and seeing how little automation truly is getting done.

We're building prod, not god. Absolutely.

Any task that the LLMs can do, right? And that's why we call them System 1 models, because they are good at System 1 tasks, or they're adjacent to that.

Yes. And with a decomposition, you might not even want a spam classifier because that will be the same for everyone. You might want your own thing where I want to say, emails from my chief of staff, even if she writes like AI, should be marked as not spam. So it's like the programmability, I think, just unlocks so many more use cases, even if you had the equivalent of every engineer having a team of MLEs, machine learning engineers, making classifiers for them.

So I think that there's a real, real beauty to the generality and programmability of it.

That is the dream. I hope for—oh man, I have grand hopes that I think are not even that unrealistic. I think that so much could change in software. Look at how much was done with bit comparisons. We have been building so much valuable, sick stuff. Just look at 2019, software has, I think, made the world a lot better. Sure, there were some misses, but we've automated so many things via these simple sticks-and-stones comparisons.

And imagine if we can just expand that more, more, more, more, more. I think that we'll be able to automate so many freaking awesome things. I think that the future will be unbelievably sci-fi, and we're going to do whatever we can to unearth the intelligence that is robust enough to make it even more sci-fi.

Absolutely. Across all levels of software too. And I think that with this stacking, as you make this valuable box and then replicate it, and if you make it fast and cheap enough, now some other box can call this thing 100 times, and now you can do higher and higher units of cognitive automation work. And who knows what those things are going to be, but I think that there can be a lot of insanely cool things.

Exactly. That's a great question. Cursor and Cognition focus more on writing the software itself faster and cheaper, presumably, while what we want to be—instead of being kind of like a software engineer—is more like a logic gate. We want to be inside of the software that expands the possibilities that software engineers can make rather than replacing the software engineers or anything like that.

The naysayers of us?

I think we will really see. I don't want to punch down too much, but I will describe my take on things. When I first started this project, I literally thought it would take a week. I ended up with something very similar to what people are doing. But the problem is, it was really, really clearly not robust. And that was something that has plagued me for years. And I get the sense that this is a thing that—and to be clear, I'm a machine learning researcher.

So all my self-deprecating comments, all those deprecating comments apply to me. I was an arrogant person who thought algorithms are the way to go. And like, oh yeah, I can just do these shape rotations myself and make this happen. So I was able to make things like this in the first week of this project as well. And the problem was, at least in my experience of it at the time, it was so unbelievably dumb that it was embarrassing.

Like, getting the shape of something and copying an existing interface is very, very easy. Similar to what Google did with FLAN back in the days of RLHF. We actually had an early alpha. They actually published before us. They made a version of it, and it was not just bad; it was worse than nothing. So things like this can happen all the time. And I'm curious about measuring how good they actually are from an intellectual perspective. As far as I can tell from the field, they probably are the equivalent of years behind us in terms of actual reliability.

But I want to measure this before I say that to anyone else.

Benchmarks are useless.

Lies and benchmarks, or something like that. Yeah. So benchmarks really, really hurt users, and they actually hurt most the users who they think they're meant to help, which is the users who do not have the time to play with things themselves, because they are the ones who are most misled by these. I get the sense that everyone else is really optimizing for benchmarks, and that is, I believe, probably a bad strategy. But again, we have better ways of measuring intelligence, so we plan to do this.

My guess is that they are dumb and non-robust, but maybe that will be sufficient for some people's work. And if they solve people's problems, I am super jazzed for that. Actually, I'm inspired by solving people's problems. My only fear from this and benchmark maxing is that it might convince people that this entire category of models doesn't work because they use one of the dumb models instead of our model. And my request for people is, you don't have to believe in us.

Just try our model too, at least, and stick with what works. Because there's a lot of nuance to making intelligence reliable that machine learning researcher types who really want credit and all of that truly do not understand. And that's why we don't hire those types.

Exactly.

Or to get it to be reliable. And if this solves people's problems, I am super-duper jazzed for that. And actually, I do want to shout out OpenAI's Decision API. For better or for worse, they did not include benchmarks, so they are a lot better than everyone else in my books. So in an ideal world, no one tries to mislead users, but some companies need the attention, and hopefully they don't create too much ill will. And at the very least, people try our models as well, so that they can figure out what actually works for them.

But if the intelligence and reliability that we have is not necessary, I think use the other models. That's great. I want problems solved, and I want automation to occur.

We are thinking about it. We've had this debate a lot. The issue is that, as far as we can tell, our model is by far the best. We think it's very far from where we think is totally ready for everything. And we think that having an API allows us to iterate much, much, much faster and serve people's needs way better. So we have talked about it, we have thought about it. We've not really committed to anything, but I think something like that could definitely be in the cards in the future, especially as we go into smaller and all on-device and all of those things.

I just want reliable intelligence everywhere. And I just think that open source—people love open weights. I love open weights too, but it's not the easiest to get everywhere versus an API is. And an API is way easier to give people the vitamins that they don't think they need. And as far as I can tell, open source, at least in the short term, will be a footgun for people. And I'm down to give some people footguns. Some software engineers love footguns.

We think a lot about how we would want a company to serve us as engineers, and given all that we know, that is just not in the cards right now. Yeah.

I see them as completely different markets, kind of. I think in the short term, maybe there is some overlap in market because there wasn't really a general classifier for workflow automation. So everyone was using LLMs for that. So a lot of our usage right now is people just switching over, but that really shouldn't have been LLMs' market in the first place. It is just tragic because that was the only tool available. So there's going to be an intrinsically System 1 model market that I think will continue to grow, doing awesome stuff, which will be completely separate from the LLM market.

So I think that LLMs will continue to be used for generating text, generating code, all of the above. Will it go up and down over time as new breakthroughs emerge? Absolutely. I hope there's lots of new breakthroughs, especially in the realm of token efficiency, but that is me from the outside and the sidelines just cheering on science's progress. So I hope that stuff occurs, but I just think that this whole make-software-really-powerful thing is a completely different market than LLMs because LLMs are just so bad at being inside software.

And I obviously think that that market will be huge because I think that the analogy to logic gates makes me feel like our particular flavor of intelligence will Jevons paradox. And I think it will Jevons paradox a lot more like semiconductors and silicon did, and continue to do, more than, for example, gas does. I think as we find more and more stable use cases to automate stuff and get successes and deploy it, people are like, holy crap, there's a gold mine here.

Let's do more and more and more. And as we make it cheaper and cheaper, people are like, holy smokes, now this old thing that was producing value, we can wrap it in another for loop, run it 10 to 100 times more, and create all sorts of value for the world in that way. So I'm so excited about that.

On the RSI comment, I think I've just been in the field long enough to see this dance happen many, many times. People see small percentage gains and then they extrapolate it to, like, the absolute moon, when the reality is Amdahl's Law occurs. People used to give the exact same story of RSI during the neural architecture search days. This is when you use neural networks to make better architectures, and they're like, holy crap, it's 10% more efficient. What if that more efficient thing then, like, discovers the next thing, and then we repeat it until we get unbelievably more efficient architectures?

And that entire field ended up thrown in the trash because it was never useful. People don't understand diminishing returns in the real world. And I think that it's going to be a similar thing for the models of today, as far as I can tell. Obviously, I have error bars in my predictions, but this keeps on happening despite people relatively young to the field getting jazzed about their first taste of self-improvement. So I don't think that that's really happening based on the evidence I've seen and based on my sense of where the field is going.

I do think that AI is an incredible technology, and we are underleveraging it to absolutely insane degrees. And I just think that this is a completely different branch. And I think that AI winter may still happen in the sense that the stock prices of the giant companies and the hyperscalers, whatever, might crash down. I don't think the hyperscalers will, just to be clear, but I think that there could be some market correction because everyone is pricing in some sort of God moment.

So that could be happening. I'm not an expert at this, but the AI winter I'm worried about is AI continuing to be so unbelievably useless at automation. And I just think that that's not going to happen anymore. And to be clear, I think that AI was still valuable, but just not at automation. Love ChatGPT, love Claude Code and Codex. And still, I don't think that that is enough, given how incredible AI is. And I think almost everyone deep down feels this way.

Chatbots kind of feel magical, and it's kind of weird how little they've changed the world. So you'd expect, if you bottled up this intelligence and made it super cheap, you could put it everywhere. Yet somehow, every single year you get a famous failure of a company failing to automate a drive-through because the chatbots are not reliable enough. That's kind of a wild state of affairs. And that is going to be addressed quite quickly, in my opinion.

I will say that I don't consider us a 996 company. It's just kind of a crazy time. I think that we are, as a company, quite adult and reasonable. And we have a very different North Star than that. And I just wouldn't—it's just a crazy time these days.

And thank you for being part of it. And thank you to all the people who are early believers. I will say this at the end of everything, because we just didn't realize there were so many people who had the same kinds of problems as us. And I think that still most of the people who've heard of Jev don't get it. And that's okay, because the people who really need to know about it know about it, because the people who do get it were screaming in joy on social media and to their friend groups and private chats and everything, that AI is finally a little bit more sensible.

So shout-outs to those people, and we at TypeSafe are eternally grateful to y'all.