The TWIML AI Podcast (formerly This Week in Machine Learning & Artificial Intelligence) - Why Jev Is Changing How We Build With AI with Diogo Almeida - #779

0:01Security teams don't need another list of alerts. They need to know which vulnerabilities are actually reachable, exposed, and safe to fix. That's what hyperscale remediation from Blitzi does. Blitzi understands your entire software state, then finds known and previously undiscovered vulnerabilities in your codebase. It traces each one through the execution paths, checks the dependencies, and validates the fix. Your engineers approve the plan, and Blitzy delivers batches of tested pull requests ready to review. Less alert noise, faster remediation, and confidence that fixes are validated as safe before you review them. Visit Blitzy.com to see it in action. That's B-L-I-T-Z-Y dot com. Three weeks ago, Typesafe came out of stealth with Jev, and it quickly became one of the most talked about new models in AI.

0:57When it was released, developers split into two camps. Some shrugged and said it was just a classifier. Others saw something fast and cheap and easy to build with. Within days, open source lookalikes were showing up, and even OpenAI has since announced its own response. But according to the person who built it, most of this discussion misses the point. Jev's real advance isn't speed or cost. It's a different idea of what AI should be optimized for. Diogo Almeida is co-founder and CEO of Typesafe.

1:24Before that, he spent four and a half years at OpenAI, where he was part of the team behind InstructGPT and the RLHF work that helped turn language models into the assistants we use today. With Jev, he's now pursuing what he calls machine-native intelligence. Models optimize not for generating strings that people consume, but for making reliable decisions that software can act on. Here's Diogo on the gap he's trying to close.

1:54so unbelievably smart, yet so unbelievably useless at the kinds of things you'd really expect it to be useful for. And most people, as far as I can tell, don't really have an answer on why there's like this entire bucket of stuff where AI is not just good, it's like super humanly good, like chat to GPT, deep research, cloud code. But and on the other bucket of stuff where it not just it's not just bad, it's like so bad that it can't even be used at all, despite having enormous financial incentive. I'm Sam Scharrington, and this is the Twimble AI Podcast. For over a decade, I've been exploring the ideas and innovation shaping the future of AI through conversations like this one that help you understand what's real, what's next, and what matters. Let's jump in. Why can't people use agents for basic data entry and insurance underwriting? And actually, you know, if you go to, oh man, I don't want to be taking stabs at people.

2:57But if you go even to Anthropics website and you try to use their customer support agent to do anything, it's really great at throwing the FAQ at you. But it is not useful if you want to do something even easier, like changing a credit card. And that, I think, is a thing that everyone who is AI adjacent, at least, should have an answer to why that's the case. Kind of curious if you have an answer why there's such a big divide between you know, super smart stuff and like super, you know, useless stuff. I mean, I think part of it comes down to we've got this one tool in modern AI, right? It's this kind of token predicting transformer at the core with a bunch of machinery around it that makes it, you know, better at better at producing, you know, producing content, producing words, producing texts. And we're trying to

3:54kind of jam that into every place we can, but that's not always the best thing for every problem. And I suspect that that's probably not too far from your viewpoint on this. A little bit though, there's so much nuance into it, right? Like, for example, how can this token spewing transformer solve millennium price problems in math, but cannot automate accounting?

4:18There's a lot of nuance into that where it really begs some questions that I don't think people in the field are really ready to answer and are very incentivized. At least the AI labs are very incentivized to not answer that truthfully. Is the implication there that you are ready to answer that question? Yeah, I could if you want. First of all, everything is just an opinion. I wouldn't say I have proof of that. I would say I have a lot of conviction and I have a lot of evidence.

4:48But the way to prove this would be to actually just automate to that job. And I'm hoping that Jev is like the first step in that direction. So my take on the answer and like the nuance of it is that you get what you optimize for, which is just true of all things ML, kind of all true of all things in the world. All things things. All things. Yeah, like actually, I think ML people get it the least and people who interact with humans a lot get it the most. So you get what you optimize for.

5:17And basically all the string LMS have been optimized for strings and strings are meant to be consumed by humans or other LMS. But if you want something like accounting, that's meant to be consumed by a computer, right? Like you have like specific fields and forms and discrete decisions. And it's very different to optimize for strings versus like these discrete decisions. And that I believe is the largest explainer of this gap. You know, when you kind of juxtapose.

5:45Navier stokes and accounting that is like kind of a contrived example that kind of plays directly into the positioning that you've kind of built up around Jeff and like what that's really good at But I don't think that like AI being good at some things and bad at other things is like this one-dimensional You know text versus decisions like it's a jagged edge and there will be a there there will need to be I think a lot of different things or something fundamentally different to smooth out that jagged edge and kind of push that frontier forward. And I'm wondering if you have any thoughts on what that looks like. Can I actually test the hypothesis about the jagged edge for real quick? Absolutely. Because I feel like that's a fun one to talk about. As an aside, a lot of what we do is really focus on making the model like this robust, like cognitive core that can be plugged into any software. And a lot of what we do is really focus on how can we

6:43Smooth out the jaggedness that is put in via all sorts of like weird processes So but like to test the hypothesis about the jagged edge existing Have you ever seen chat to GPT respond to you rudely or like insulting you for no reason Not if I didn't tell it to do that exactly so there's actually so the models are actually reliable at some stuff Right? They're not just, they're like super duper reliable at some stuff. I would say that jaggedness is not intrinsic to LLMS or AI. You're saying jaggedness is relative to our application of them towards specific problem. Yes. And to our optimization process, right? Like if you optimize super hard in a particular direction, you get certain types of reliability that you lose others because you focused all of your optimization pressure on those things that really matter. Like,

7:39If you are optimizing for decisions, for example, in a customer service chat, saying to give someone a refund when you shouldn't is, from an accuracy perspective, exactly the same as like mashing your face on the keyboard. You know, it's the same zero percent accuracy, but you never get the mashing your face on the keyboard because of the asymmetry in the optimization. This is what RLHF does, right? Like you use a reward model and the easier it is to punish something.

8:08the easier it will be to make sure that doesn't happen at inference time. And you just never get those types of things anymore, even though the pre-trained models could actually get word salad, right? So post-training can make certain types of things reliable. And I don't think people realize how much of an agency that AI practitioners have in setting their menu of desiderata into the model. It's super interesting to hear you say that. And you said that a few minutes ago as well that Everybody gets that you get what you optimize for, but ML people. But ML is all about optimization inherently. And all of our gains with language models are RLHF. And we talk about cost functions all the time. How is it that you think that ML people don't get that? I love this. Have you seen my blog post on The Bittarest Lesson? No, tell me about it. I can just explain it.

9:05There's Sutton's bitter lesson. I'm paraphrasing to be useful for me, so this is not exact. But roughly, I'm simplifying. It's hard to simplify actually good writing, right? So I'm simplifying a bit to be beneficial to my narrative. Everybody else simplifies the bitter lesson, so you might as well too. Yeah, I might as well too, but I just want to emphasize that there's actually nuance to it. But here it is. So it's roughly speaking that compute and scaling matters more than algorithms.

9:33This is bitter because ML people love algorithms. It's always the sexy thing to work on. It's fun. It's cool. This is what they've studied. And it's bitter because who wants to do that systems-y stuff and getting GPUs is hard. And especially in the back in the academia days, you didn't have that much compute. And this birthed an entire era of scaling-pilled ML practitioners for mixed reasons. I actually think that there's pros and cons to being scaling-pilled.

10:03I believe that data matters a lot more than compute. So you actually need data to put the compute on. And more important than data is you need the right task. So this is the most important thing in all of the ML that we do. And the right task is kind of the North Star that you get what you optimize for, something like pre-training loss. Pre-training loss is maybe obvious in hindsight. It was quite a big leap of faith that pre-training loss would lead to such awesome AI stuff and was by no means guaranteed. So it's actually a rare few that I think can actually make a new task, and that is that you get what you optimize for part of it. And if I could add like slight nuance to sudden stake, in the case of games, there's no question what the right task is because that's constrained by the rules. And there's no data for games because you're doing on policy RL such that you get data from compute by like doing rollouts.

11:00So I would say that in the case of RL games, a certain spitter lesson is the equivalent one of what I'm describing. But by extension, in real world application, data is the constrained resource more so than compute. Figure out the direction of the data as well. So I won't talk necessarily about Java and RLCD right now, because it won't be fun. We can, but let's talk about RLHF.

11:30made, there's many definitions of RLHF. There was the original RLHF that Paul Cristiano did to teach robots to backflip. No LLMs involved. There was another RLHF learning to summarize where some people in the open AI team, I think Paul also was pivotal for that, taught the models to summarize like a GPT two size model to summarize text better than humans did. I'm not sure about that part. And then there's RLHF, which is what everyone refers to now.

12:00which is creating the task of instruction following, like teaching the models to chat and follow instructions. So when I refer to RLHF, this is the task that is being done. And before RLHF existed, there was literally no human feedback data on the internet of the shape that we were looking for, because we had to create it, right? Like why would anyone have like preferences between two completions from language models that were somewhat on policy, because that's such a weird thing to have. So it actually took some genius from the team to realize that this is a direction to go down. And once you have that direction, first off, when you're in the early days of the direction, you are not sure it's the right direction by definition, right? Like it's not yet working. You need like a lot of data compute and algorithms to make it work. And you just have a strong conviction that it's the way to go. But eventually you get the data and all the other stuff, but like the data needs to be gotten from scratch. And that eventually becomes something phenomenal in the world.

12:59And that tends to be how you get the gigantic jumps in ML. Chat to GPT was a gigantic jump. 01 was a gigantic jump. And Jeff, at least, I don't want to toot my own horn too much, but at least from an excitement perspective, was also a gigantic jump. Let's maybe take a step back, because you mentioned RLHF. We spoke the last time 10 years ago, just a month under 10 years ago. It was October 2016.

13:28And we were talking about kind of deep learning broadly way before any of this gen AI stuff Yeah, give us a brief summary of what you've been up to since then you were at open AI for some period of time I was at Google and then I left I was retired for a while just trying to like chill out and be happy did a lot of weird stuff like like very competitive video gaming and improv and stuff and eventually I realized that actually AI is way more fun than that let me join this weird-ass company that has weird-ass goals, and that was OpenAI. This is before language models were really a thing, so I got the honor to actually work on a lot of OpenAI's greatest hits. I was there for about four and a half years and worked on a whole bunch of stuff, but really even when I was working on other things, I've been obsessed with this question that has led to Typesafe and Jeff.

14:27Like, why is the AI so unbelievably good yet so useless for the easy work? And that's been, you know, it's still an obsession if I'm like totally frank and it will not be done until we see massive, massive transformative automation and software doing absolute sci-fi stuff.

14:48There's so much so many things in there that I want to pick at like software is doing sci-fi stuff like clearly you're talking to your phone while you're a great example on Twitter Guy is talking to Grock in his Tesla Asking an agent to build a video like that's pretty sci-fi Right software is doing sci-fi stuff and also The other thing to pick at in there is like the easy stuff like the easy stuff isn't necessarily easy which is why we haven't done it yet. You can take whichever of those you want to take first. I don't believe in running from questions, so I will try to get them both. Actually, I'll just do the first one. I'll ramble, so I want to focus up on that one. I think a lot of what AI does is super fricking sick. I use coding agents. I don't even code that much anymore, but I use coding agents every day. I use chat bots every day.

15:44Holy smokes, would it be a lot harder to run a company without chatbots? But they are and in case it was it in case it wasn't obvious with the Tesla example I didn't say the punchline, which was the car was driving itself at the time. Oh, right? Stuff driving actually, I think it's a little bit different and we can talk about the distinction between self-driving was only so sci-fi like oh cool I my My argument with sci-fi with is especially related to LLMs, which I think tends to be what people mean by AI these days because it seems to be like the greatest compression of intelligence while having like the least utility so and also it's quite I wouldn't say it's like universally hated but there's a lot of dislike for AI which is tragic and I think that we would be remiss as a field to not own up to why that is the case so there's like a lot of like dark sides to AI too and I could like name a subset of them but

16:41I think that that's worth talking about. So number one, I think self-driving is super duper cool. And also, I see self-driving as a ginormous engineering win, not necessarily an AI win. I use Waymo as like the gold standard here, no offense to Tesla fans, but like they seem to be safer. And also the way they do it is by building like a la software and engineering like reliable systems.

17:07that they understand the pieces of that have their own like decomposed abstracted parts and make sure those are like unbelievably good while programming in the behavior of the policies you want such that this can generalize outside of distribution. So this is super freaking cool. But none of this is happening in AI right now. When in AI what you tend to get is a lot more, let's just make a demo and you know, the my cynical loop here is make a demo, raise a seed or series A, say that you're going to make it reliable, never end up making that reliable, pivot into a human in the loop version of this thing instead of actually automating the task. And it's not, I don't hate on them to be clear, that is actually the right move to do, given the current AI climate, because the models are not reliable enough. So even, you know, I try to be as unbiased as I possibly can, I obviously can't be perfect, but

18:04I would like to have the same type of critical lens to LLM demos as Jev demos. And I think that a lot of them are super cool, especially when they have sick ideas. And also, I can't really vouch for them because they solve work when they actually reliably can be run in the background. And LLMs are extremely not there. I actually don't know of anyone who actually runs an LLM as a separate dependency because you can't get abstraction with an LM, right? It can just break arbitrarily and you need to have the abstraction needs to leak in order to see like, oh, why did you talk about biology? Oh, I'm sorry, my cloud can't talk about biology. It fell back to another model or something like that. And that is extremely sensible for a first-party app, but super nonsensical in my opinion for something developers are meant to build on top of. So I think that there's that lack of usefulness I still think is

19:01present there despite demos looking like sci-fi because demos will always be significantly ahead of the curve. Opening I have seen has been showing like customer service demos since 2020. I believe that is now roughly six years ago and customer service is still not solved. Maybe because the work is hard, as you say, but it really looks a lot easier than millennium price problems in math because I don't know anyone who could solve a Millennium Prize problem in math, I feel like I know everyone, but I don't know everyone who could solve customer service, but everyone I know probably could do that job better than an LLM can. Or even drive-thrus, people keep trying and failing to automate drive-thrus and like there's no like good answer for that other than maybe drive-thrus are harder than unsolved math. It's interesting to me that you you call out Waymo versus Tesla in part because

19:59in the context of this conversation about, like, bitter lesson-pilled, right? Because in one sense, like, what differentiates Waymo is that they're not taking a bitter lesson-pilled, you know, approach to it, whereas Tesla's is more bitter lesson-pilled, like, we're gonna, you know, characterizing their approach at a 30,000-foot view, but, like, we're gonna collect a lot of data and throw that into a big model and let it do end-to-end, whereas Tesla's, we're gonna, like, classically engineer this thing, break this thing into a lot of different modules, use all the sensors we can to get as much data as we can. I've had conversations with Drago on the podcast about how they approach it and how it's so fundamentally not like we're aiming for this end-to-end single model to rule the entire driving experience. I want to emphasize that that is just the ML part of it, but I don't think that's the limit of what we should be building.

20:55extremely pro software and software engineering. And I actually think that I hope that I want to do everything I can that Jeff will offer in another golden era of software engineering, kind of like with the early internet creative energy of like building crazy things. And for ML, you need data, you need to focus on the right task, you need compute, you need algorithms. But ML is meant to be one part of a larger system, in my opinion, in general. And ML should be scoped.

21:23to the part of the system that it can really do well. And in general, the way to get higher reliability is to zoom in. It would way more be as successful in San Francisco if they tried to do the whole thing end to end. Honestly, I would wager not. Maybe this is going to be better in five years, but in order to actually ship something now that is useful and reliable and safe, I think you need engineering to study all of these things.

21:52Study the properties of every single ML component and when things break feel to like debug which part caused it and fix that and that's very hard to do in a one model rules them all typesetting So where did the idea for? Jeff come from like was this like hey where I'm gonna set up type safe and I'm running towards this thing that I already knew about Did it evolve did you pivot into it like how did how did it happen? Oh, I'll give you a fun story about this some investors we've been fundraising. And some investors have said, wow, that's the greatest pitch we've ever heard. And I told them that is I'm going to avoid cursing bull bull. That's bull. Because I gave the exact same pitch last year. And you guys didn't get it. What you guys are reacting to is the product market fit. So I've been saying the same thing for years, which is

22:51what I'm now calling machine native intelligence, like optimizing for automation, which is optimizing for machines instead of strings and humans is exactly the same thing I've been talking about. I did not know it would be in the shape of Jev, like we've had to get our own multiple breakthroughs to even get as far as we've had. But the North Star has always been what does AI look like if it's really, really optimized for being useful for software. And Jev is our initial foray into that and our best guess of the 80-20 of maximum usefulness. When Jev first came out, it seemed like there was two disparate reactions to Jev and what it represented. One camp of people was like, oh wow, we've created classifiers. We've created logistic regression. Why is everyone excited about this?

23:49And there's another camp of people that was, hey, this thing is amazing. I could do things that I've been trying to do with LLMs for much, much, much cheaper, much, much, much faster. Part of my question is, what do you make of that? But more specifically, I'd love for you to talk about a technical level and with more nuance. How is Jeff different from a classifier? How is it different from an embedded model plus a classifier?

24:20Open AI just came out with their decisioning model, which is like a small model post-train for decisions. How is it different from that? What makes it and your approach unique? Man, I don't know where to start there because you've left so many breadcrumbs. I'm just going to jam. Eat them all. I don't eat them all. I'm going to eat the most tasty ones. Let me start with the tastiest one of them.

24:46And I've had this rant a couple of times. I don't know if I can do this rant without cursing, so I'll try to control myself. So classifiers, there's nothing wrong with classifiers. Classifiers are an interface. Creating classifiers is not an ML innovation. And no one in 2010 to 2020 was inventing new shapes of classifiers. They were just making classifiers for useful stuff. And classifiers are not meant to be cool in ML.

25:15They are literally the shape of usefulness. Yeah, you know, like that sounds like an arrogant thing to say, but that is how you get... Yeah, well, yes, that is how you put intelligence into software to make the software smart. How is metapowered classifiers? Maybe some regressors, but probably mostly classifiers. How is Google powered? Probably mostly gas fires. So classic, there's nothing wrong with classifiers. I actually think it like if someone told us that we were a zero shot.

25:41general classifier for anything, that would be the greatest compliment I've ever been given for Jeff. We have other things too, but like for Jeff, that would be an incredible description of it. If someone could say that I can give you, and you know, random developer, the equivalent of an MLE team of a dozen people from 2019 to work on any task that you think up on the fly while coding, and it's instantly done, And not only that, it's going to be better than the quality in 2019 because the AI models have gotten a lot better. It's going to be way, way, way smarter. That sounds insane for development. So I think that the classifying thing is like grumpy ML people who kind of don't get it. And that is totally fine because the Jamf party is a developer party. Oh man, I should have said developer. So yes.

26:37And I actually think that there's another class of people who is not just like we can run the same stuff with LMS so much cheaper. I actually think that they are the second wave of people. I think the first wave of people who got really excited were the kind of people who felt like this is how AI should have been shaped all along. This is like obviously the way to make stuff useful. And I'm talking about like the people who like live and breathe structured outputs, like the DSPy. I am not sure how it's pronounced.

27:07DSP but like I always say DSP why but I think DSP is the most popular cool way of saying it but like these people have been kind of You know trying to push this vision of this is how you actually make useful systems And I believe that they're intellectually quite correct But they've been hobbled by the models being optimized for strings instead of them being optimized for the thing that they want which is programmatic use so I think those people not necessarily DSPy but like there's a lot of developers who intuitively think in this way and part of what made us so popular is kind of on Twitter them screaming like a phantom lib was returned and I didn't expect this because I'm like this you know I was designing for like where's my missing phantom limb and it turns out there's tons of other people with this and that was so so freaking cool

28:02That was only one crumb like I don't even remember what the other Yeah embedding model plus classifier Small models like the thing is if you do you put a small model or an embedding model plus a classifier a lot of people miss this and My team has been telling me to stop telling this to people because it makes it more likely we have competition and right now I think everyone is missing this I want to educate the world, even if it's not in my financial best interest. And the thing I really want to emphasize is that it is not about the interface. The interface is cool. It is not even about the speed and the cost. Speed and cost are bad things. Ideal speed is instant. Ideal cost is zero. No one like spins up a library and says like, I feel like putting cost and latency into this like line of code thing you want, right? I think people just don't get that they're paying for intelligence.

28:57And if you use a logistic regression on top of embeddings or a small model, you get the intelligence of logistic regression on top of embeddings or a small model, right? Yeah, but everyone misses that you get what you optimize for. Of course, you can get a gigantic jump in this thing if you're literally the only person doing that. And we are literally the only person doing that, despite me trying to shout out like, hey, everyone, please do this.

29:25This is really valuable for the world. This is what's going to make AI really useful. There's been lots of copycats. I still don't think people get it. I was just going to say, you say no one's doing this, but within the space of a week, I think there are half a dozen or more open source projects. A bunch of other, like I mentioned at Dev Days yesterday, OpenAI announced their decision models, which is, I think, terror or a smaller model. That's about the interface and the cost and the speed.

29:55not about the intelligence, right? So no one's taking the same approach that you're taking to get there? They don't even need to have the same approach. They just need to care about intelligence. If you're taking an open source model, doing something to make it have the same interface and same characteristics, and you just benchmark on NLP tasks or something like that, you don't think I thought of that? This was literally day one into this project. I thought this project could take a week.

30:23um it it's been for you know i i only feel okay admitting it now totally honestly because it's been so successful like i it becomes feels way safer to admit my failings at the time we started this i was probably at worst tied at best at post training in the world when we started and i thought it would have taken a week because i've post trained so many models for so many different things and models are They seem to be very very general at a lot of stuff, but apparently not decision-making which I've learned the hard way so I I Think it's very cool that people are playing around with stuff I worry that if people play with bad versions of the model they might actually get burned by the whole subgenre and say like hey like Like this kind of stuff is crap. I hope that's not a big deal as people are saying that kind of exactly because the thing they want is intelligence

31:19If the models were perfectly intelligent, which our models are not and no one else's are, then you could literally solve everything. Classification is AI complete, right? Like any task could be boiled down into classification questions and you could just solve everything. So truly intelligence matters in what you can and can't automate and what kind of sci-fi you can build. And it's really important. It's so important. I try so hard, you know, like we could have released so much earlier if we didn't care about this and even now it's a debate for shipping new stuff. How do we continue to ship stuff when we have such a high bar for reliability? Because we want to be trustworthy. We want to be trustworthy to developers, not ML researchers who are snooty about which benchmark things are better at. We just want people to not have to worry about their intelligence, because that is what developers want in order to build stuff. So I get worked up about this basically every day. It's such a...

32:15It's such a frustration and you know people in the street recognize me. They're like, oh, you're the Jeff Beye. I love how smart and cheap it is. And I'm like, no, what does my reputation become? You know, like I want to be a paragon of making AI so reliable that it's boring like sequel. You know, like I want AI to be so predictable that you can like write queries without having to even run them against like eval sets.

32:42because you know this is what common sense intelligence would do there and to just do it every single time. And that is when software engineers get super duper powers. And yeah, I obviously love Jeff. I love that we're fast and cheap. We're going to keep pushing that just you wait. And also, I cannot emphasize enough reliability is what people are paying for. Reliability is what people want. And if you want to put intelligence to applications, you need the intelligence.

33:10So let's let's dig into how you get that intelligence. You know, I think maybe let's like start at the end state, like what it is, how it works. You know, we can from there maybe touch on RLCD, which is a big part of your process. But along the way, I'd love to hear like, you thought it would take a week, it took a lot longer, how much longer and maybe what some of those some of those milestones and turning points were. Oh, man.

33:39On that note, if you want a fun, embarrassing thing about me is at the time I had this idea and the aha hit me, I wrote a document in OpenAI entitled, maybe not entitled, titled, we could have had AGI last year. And it was meant to be very spicy where it's like, and actually I did believe it at the time.

34:07I still believe the sentiment to it, but like the sentiment inside of it was like one year's worth of time of like the equivalent of an RLHF effort would be sufficient to make this new class of models that are made to be machine native. And RLHF could have been done in less than a year for sure. In hindsight, we've learned. But in hindsight, I think RLCD could not have been done in a year. It was just much, much harder. I think that making like LLMs are much more suited to, to making things like human pleasing, then AI is to be making calibrated robust decisions. And there's so much jaggedness when you remove the psychophantic elements of AI, that it's there. It's been a lot of work is what I would say. And I see the North Star and as and of how we do things is really, really, really.

35:06trying to find what are the ways, like if you imagine the cognitive core that has like these jagged cracks, what is the most efficient way to like heal that to get smooth, robust performance at whatever level of intelligence is truly capable within the cognitive core. So it's a lot of like understanding the capabilities of LMS. It's a lot about like seeing their weaknesses. It's a lot about like figuring out how can what weaknesses are addressable and how do we address those? Our model cannot count ours in strawberry.

35:34Luckily, that is not what real world work looks like, but it can do a whole bunch of other stuff because a lot of work is in the shape of semantic judgments, which luckily... You can't decompose that into a classification problem. Oh, yeah, you can decompose it, but you can't just ask it vanilla. And at some point, like, it's a little bit cheating. I'm just teasing. Yeah. But suppose it's cheating, right? Like, if you, like, break it into, like, a list, then it works. So that the tokens don't get merged. But, like, if you... You want, like, a...

36:04same level of decomposition that makes sense for your engineering system that's ideally at the right level of abstraction, that it's understandable by an engineer and it's maintainable versus like overfit to any one question. So even if our model could solve every single task if decomposed perfectly, that may not be sufficient because we want to keep moving up the abstraction hierarchy so people can program at the semantic layer that matches the way they think about it, right?

36:33If you could break down, does this person want to refund into 100 different refund scenarios? Maybe then that will work, but that's still kind of a pain in the ass where some businesses will still do it, but I wouldn't consider our job done for that. We've talked broadly about Jeff, and it may be that everyone who's listening to this has already seen it, played with it, knows a bit about it, but in case not, I asked you a bunch of questions before. Let's kind of break those down. The first is, From the perspective of a developer your target user like what is this thing look and feel like like I think if it broadly is like you could or you could call it an intelligence API you give it a bunch of possible decisions and some input and It like makes one of those decisions or tells you which I think it is and it gives you some probabilities How would you tune that? I love it a lot of people describe it in many different ways and I take all of them if as long as they're accurate

37:31I also like the description of SQL for intelligence, you know, or like it's a combination, right? Like system that there's the interface, which then the model, and we are kind of made both. So it's a little bit confusing. But to me, I see the interface as like the building blocks for making intelligence applications, kind of like adding a fourth logic gate or something like that. So I really want intelligence to be standardized into a common set of primitives.

38:01And ideally, everyone makes these things as smart as possible, not just us. I also like the kind of positioning as like, hey, we have this thing called language models. Here's this new thing called decision models that kind of says a bit about what it.

38:16aims to do, not necessarily Jeff, but like some broader new emerging class of, yeah, tell me. I will give a tiny warning about this, where we consider decision models as a name. I'm not opposed to the name. I think that the best categories are named by the community. So, but I will give a disclaimer that there's a reason we didn't pick that. And I think that there's a lot more that fits this class of models beyond the decisions. So I would say that like, People's public interface to Jev could be called decision models, but I personally wouldn't call the category. What's an example of something that Jev would be good for that's not a decision? Ooh, I will not tell you, but I will give you a hint if you'd like. So I've said that decisions and classification is how you make intelligence useful to software.

39:13And we are all about making intelligence useful to software. And I'm also saying that there's more than just decisions available, which sounds like a little bit of a paradox, but I will say it will one day be obvious. And I can't reveal that yet because these are like things like a little bit more distant in the roadmap. But it's a fun one to think about if your readers want a noodle on this. So that's kind of the shape and kind of functional surface of it.

39:43Let's talk a little bit more about the making of at the core. There's a model that we won't call a decision model, we'll just call it JEV. It was created through a process called RLCD, post-training. Is it a post-train of something else? Is it a ground-up thing? What can you tell us about this thing? I will answer this in a way that is overly precise.

40:11Back before RLHF existed, post-training as a concept did not exist. We, as a team, we didn't name post-training, but we created the concept of post-training. At the time, fine-tuning existed, and people were like, are you just fine-tuning the model on strings? And by some definitions, we were fine-tuning the model, but we did a whole lot more.

40:40such that at some point it becomes misleading. I would say that calling it post-training is probably going to be seen as inaccurate in hindsight, but the field doesn't have a terminology yet for what we are doing. That will probably be revealed more in the future. If you were to invent one right now, what would you call it? No one likes my ideas in the team.

41:10So I've said this elsewhere, so I'm okay saying this, but back to Bitter's lesson, because this is ML, we care a lot about the North Star, and we are willing to do everything for it. And I try to be as upfront about the trade-offs as possible, and part of that trade-off is being a lot worse at string generation, and even the Jev can chat stuff. It's very cute, but it's obviously dumb. These are trade-offs we intentionally make. So when designing, the entire pipeline. Post-training was a lot easier on top of LLMs because the shape was very similar. Like its strings here, it's basically strings there. Technically there's some structure with like the chat ML format, but it's mostly just strings. You know, so there's a lot of similarity in the stack. What we're doing is we're actually like ripping out a lot of fundamental pieces and like rejiggering them and using pieces from other stuff. So I have described it as a Frankenstein's monster of models.

42:09which I haven't read the book, but I've been told is at least innocent if not the good guy. Just to be clear, because people are like, don't call the model a monster. And I'm like, it's a good analogy, though. What's the foundational thing that you're applying this unnamed thing to? Is it like an off-the-shelf Quen model or something? A lot of different open source models, because they all have different trade-offs to them. So we are actually Frankensteining all over.

42:36But the important bit, if we want to be like maximally precise and useful is figure out the North Star, figure out what you're willing to trade off and remove all the stuff that is useless for that trade off or that is needed for the thing you're giving up and hyper focus on the thing that matters. And a lot of it will follow a la first principles with months of research. Sure. But that's that's broad in general. And to be concrete and specific, it is interesting that like You didn't start from nothing like you started from LLMs and like transformers and like you're building on these building blocks that have established themselves with LLMs. I did say transformers just to be clear. I have talked about- You said you did or did not? I did not say transformers. I did say open weight models, slight distinction, which I would just want to be precise. So I think that, oh man, something I want to invent.

43:36Number one, it's very obvious we haven't done pre-training. If we could pre-train better than the rest of the world with the budget we've had, then the rest of the world is totally cooked. I think pre-training is not the most efficient thing in the world, and it's exponentially more resources for debatably linear gains, seems very sub-linear.

44:06a bad deal, in my opinion, unless it's necessary. Meaning we've kind of already boiled the ocean of content down into things that are kind of consumable by some downstream process. Why keep doing it unless you're doing something fundamentally different? Exactly. So we are trying to focus more on like the 10x or more jumps that can be made. And we think that that can be very much done in a budget. Well, we obviously think that because we did. But I think that all AI companies should be held to that same bar personally. Part of the reason why I'm trying to really drill down on this point is not necessarily for you to say, oh, we use, you know, Quinn 3.6 or whatever it was, is that it took a while for me to wrap my head around the fact that there was an LLM at the core of this thing, and that is the source of intelligence, and that is the source of zero shot. And like, if you think about it as like...

45:05Like if all you've seen is Twitter and like, oh, it's like this cool new classifier thing. And you're like, oh, okay, well, that could be like, I don't know, XGBoost or like some other, it could be anything. And like they've done some like really training thing. But then you are like, oh, well then I have to like post-train it or I have to like give it some information about my domain or something like that. How am I just gonna give it a bunch of decisions and ask it to decide?

45:36Where is that intelligence coming from, to your point about intelligence? But then you can start to see how that could work if you realize there's an LLM down there somewhere. I could see that analogy. I'm trying not to avoid the LLM terminology because it's technically not a language model. It doesn't model language, despite people wanting to force it into that.

46:04I kind of see this as like this more broad like this recent wave of AI has been creating these incredibly awesome condensed bits of intelligence, of which, you know, like with a scaffolding around it that turns it into an LLM. So imagine like this mega battery with like stuff on top that like turns into a language model. And really meant it in a sense of like a compressed version of the Internet. Exactly.

46:29Exactly. I would use that. You've got a compressed version of the internet that some large effort created and you're using that. Exactly. I think that's the only way to get what I'm calling general intelligence. That's the only way I've seen to get to general intelligence so far. It's debatable if you want to call it general intelligence, but I think it's general. Not to oversimplify. You've done a lot of things like you've Frankenstein. It sounds like several different models.

46:59You have an involved process that we won't call post-training, but there is this thing called RLCD. What is that? So back to the topic of RLHF. RLHF is not about PPO on reward model, on doing first SFT, and then reward model training, and then on policy training of that.

47:21Okay, RLHF is about human decisions, and your thing is about decisions, calibrated decisions. Yeah, exactly. A human preference. It's never about human decisions. Human preference. It's about like placing humans. Human feedback. So like when I talk about RLCD, I talk about like the general class of algorithms that optimize specifically for calibrated decisions because that is what's useful for software. So we do have many algorithms in here that we have been playing around with. We actually have talked about publishing something here.

47:50though I will not promise anytime soon because the team is super duper swamped. But I think that, you can imagine, but I think that publishing RLHF was probably really good for the world. It allowed a lot of people to understand stuff. It took us a couple of months to publish it, but we had instructed GPT for a while. And I think that eventually publishing something here would be really good for the world too. So I think that that could be in the cards. That's the algorithm versus the task. Just to be clear, other people will probably make other algorithms within the same umbrella of the task. Is it useful to talk more about the task or do you mean the task broadly in the way we've been talking about it thus far? In an academic context, I'd ask about the setting. What is the setting?

48:45it for RLCD, like how have you defined that? That is very complicated, but I can give a simplified version of it. Have you ever used like function calling in the, did the chat completions API? So function calling is kind of like decision making because it is decision making really, but it's done on a layer above the string stuff. So all the knobs available are the stringy knobs.

49:15that are still available from the string models. And one example of a stringy knob is a logic bias. A logic bias allows you to nudge in the direction of sampling a particular token, so you can do that to make certain tokens less or more likely, if that makes sense. And one of my claims is that no function calling API should exist without a logic bias for the function itself.

49:41Why would you not provide that knob to a user? Because if you are, for example, doing a customer service thing, and you need to figure out if you're escalating to a human, your policy is probably extremely different if you're Walmart versus Costco. I know nothing about these policies, but I'm just making some up. But the only alternative now, then, is to program again into the language, like, please give refunds, or please don't give refunds, or something insane.

50:10instead of giving the controls of the system to the programmer implementing the downstream behavior. So to me, RLCD is about exposing the right interface to builders so that they can get the properties they want without just praying to the system message. And like these types of basic things are table stakes. Like this hasn't happened recently, but this happened back in the older days when OpenAI had issues with over refusals.

50:39they had to like roll back the model because they refused too much. And I would argue that that was actually bad decision-making. What was happening is the model within its weights was making a decision, refuse or no refuse. And then the system is just going with what the language model thinks because it blends the decision with the text and then just does that. So there does exist queries by construction that if you refresh it several times, it will sometimes refuse and sometimes not refuse.

51:09That is insane behavior from an engineering point of view. Why wouldn't you have a threshold? Why wouldn't you have a tunable threshold? Why would you not have a tunable threshold that responded at least somewhat indirectly to how people are complaining? Or if you were doing customer service, why can't your threshold on whether to escalate or not be dependent on really basic things like how much is this customer worth to us and how busy are human workers right now? Because maybe that changes things.

51:39And we just don't have any of those controls today. So ICRLCD is really exposing the most native to engineering controls. And that is the shape of the task. And a lot of stuff comes from that shape. Like in order to have meaningful knobs to tune and thresholds to chop, you need to be calibrated. You need your probabilities to be smart and accurate. You care about the long tail of probabilities, not just the accuracy. And there's a lot to the task itself.

52:08on studying this, seeing trade-offs, figuring out what the right behavior is. There's a lot to the product of an ML API that most people don't realize because they mindlessly follow the gradient of things like monthly active users. You talked about the RLCD setting being one of, you've got some set of inputs and You know, there are the inputs that the user provides, but there's also these knobs that kind of control internal bias in the system. Does the current JEV product expose those to the user, or are those knobs that the JEV engineering team has access to to create this thing that, you know, this decision API that you've published to the world? As far as I can tell, the internal API and the external API are basically the same. So we want, but how would we know?

53:08what users should set this to if we don't have their application. Right? Like what is the right, so confidence is part of this. Probabilities are part of this. Most people don't use the probabilities, but I would guess when things get into hardcore engineering, you would definitely use the probabilities every time over just picking what the model thought was best. Because even if all of the choice, even if you had like the perfect probabilities for each of the actions you can take as a company or a business, deploying this or even a software engineer like trusting it with your own home system. Each of these actions have different costs and benefits. Well, I guess I want to come back to the probabilities as outputs. I'm more thinking about like input knobs that when I've, you know, my cursory look into the Genve API, it's like a very simple API shape, but

54:01I've not dug into the docs and looked at all the possible knobs that you give me access to beyond just the decisions that I send in. Like, what are some of those knobs? The knobs are via outputting the probabilities. We are basically trusting the user to make those decisions. This would be equivalent to imagine speed wasn't an issue. It would be the equivalent to the OpenAI API outputting logits for every token.

54:27And then the software developers can choose how they want to chain the sampling algorithm instead of letting OpenAI just handle everything. So we give those knobs by giving people a raw access to the models, then other people have access to the string models. And that way they can tune their behavior to what it actually is needed in their system instead of what an OpenAI PM thinks is a globally OK behavior for everyone using the API or first-party product.

54:56which brings me to a question I had about how you do that. And I guess I imagine this is circling back on RLCD. But like historically, uncertainty estimation has been like very difficult. And, you know, particularly when we are talking about these, you know, large compressed versions of the internet that historically generate text and like, and large complex models generally. So how do you do that? Hard work, blood, sweat, and tears. And also, hard work. We were in stealth for a long time. Being two years in stealth is kind of insane in AI terms. I'm not asking you to divulge the family jewels. It's more like, is it?

55:51Is it grounding on something? What's the guiding star, the principle that kind of helps us understand why we should trust these probabilities, as opposed to, well, they've just got some token generator that's been trained to generate numbers between zero and one. We're going to give you one more bone in the last thing, which is we did work in stealth for a long time.

56:17missed so many fads, even though we thought Jev would have been great for a lot of those fads. Like, holy shit, would have been cool to launch Jev the same time as Open Claw. It would have been awesome, because everyone has a lot of reliability issues with Open Claw. And also, these compressed things of the internet are, as far as we can measure, decently calibrated. They're not perfectly calibrated, but they are way, way more calibrated than RLHF models are. Actually, RLHF and RLVR destroy the calibration of the models immensely, because in order to output strings well, you actually need extreme overconfidence. It requires like a mode dropping loss in order to make that work, which just completely warps the probabilities. And I think that the GPT-4 paper started talking about this, because that's when models started not shipping their pre-trained versions and only started shipping post-trained versions. So I think the GPT-4 paper went into it a bit.

57:12models used to be decently calibrated. Look at a lot of opening Anthropics early publishing, you know, measuring with what they called PI know the probability it knows facts like these are all like pretty decent. And it's definitely not good enough. I would guess Jev would crush all of those like super easily. The thing is that there's ways to bootstrap calibration and reliability and intelligence from all of that the same way that RLVR bootstraps reasoning.

57:42right? Like in an ideal world, the reasoning of RLVR doesn't come from humans writing the reasoning because it does it differently. But if you have the right RL objective of calibrated decisions, there are ways to get that working from that seed data into becoming more and more and more calibrated over like the training that I don't really know what it's called epochs training stages, whatever. So there are there's like hand wavy ways.

58:11that makes sense that you can get calibrated stuff out of not quite nothing, but out of like the beautiful raw material that AI has today because AI has like a like, I feel like AI is still a diamond in the rough. You know, there's so much stuff to do there. And if I wasn't doing Jeff, I would probably be ideally not starting a company, but doing other cool stuff on top of the AI models. Like, how do you get to generalization? Like, you know, presumably, you've got, you know, your You're grounding on some corpus of decisions so you can teach this thing like what decisions are like and how to map to these probabilities and all this kind of stuff. But like that, as with all these training efforts, you have to be asking things that are in distribution in order for the results of the model to be representative. And how should we think about

59:10If you're trying to enable zero-shot classification, like zero-shot decision-making, how do I know that my particular problem is in distribution versus out? And maybe more broadly, I would think that general relation would be a harder problem for...

59:37workflows and decisions and like software interactions and all these things that like we're trying to automate then Then like just generating text, but like I could be way off on this. So you tell me it's an interesting question Which maybe would be more fun as a dialogue than a lecture You know maybe like why do you think AI lacks generalization I have my own answers that I could say later too, but like What makes you think that generalization is not native to AI? It sounds like you're asking a philosophical question. I can ask a practical version. How general did chat GPT feel? I think the perspective that the question came from was one of, as a general principle, the reliability of responses is governed by

1:00:36kind of mapping the training data and like you know the degree to which the thing you're asking is familiar to the model you know using these terms very broadly and like very broadly right and so like I think why the take that you know decisions would be harder to generalize than Then text is because like Presumably I get enough texts in the world if I'm asking a model to generate texts like it starts to understand like how to put words together and If I'm not asking it for precise facts then You know it can like put words together that are plausible Whereas like in the case of you know, I've got an accounting workflow

1:01:36And I needed to do a very precise thing. Like if that workflow is very different from the standard way of doing that workflow, like I would think the model would be very confident and wrong. So fun, fun stuff. So, you know, like it was chat to GPT general is what one one way I would like to start the conversation to feel general to you. I mean, I think it I think it is general like and.

1:02:06I mean, this is maybe going in, you know, a different philosophical direction, but like, you know, I was very, very strongly against AGI as like a broad term for like what we've achieved, but like in the past three months, maybe like I'm getting closer to being able to say that like we've achieved this, like in the sense of, you know, I can talk to an agent that, you know, you know.

1:02:34conversationally and have it do things in my business like an employee might like it is like AGI and generalization are different concepts, but like I'm accepting of the idea of chat GPT being general. Yes. I don't know that that like negates the indistribution out of distribution line of questioning. I mean, there's a bit of it because In and out of distribution is also a function of like how long and hard you've worked on that because you start mining the long tail of examples. So in the grand scheme of things, chat GPT of today is a lot, even if you do use instant mode. So turn off reasoning is a lot more refined than chat GPT of four years ago. Well, three years and 10 months. Well, sure, but not necessarily because the model is more general, but because

1:03:32Now we've built these harnesses that know how to go out and find information to fill in context. I mean, if you talk about just chat GPT, I would imagine that there actually was generalization gains, but chat GPT already was quite general. And it did a lot of simple stuff quite well, I would argue. And I do think that there's some amount of generality native to things. I actually have a separate blog post I've called, I believe it's called lies, damn lies and benchmarks.

1:04:00where I talk about how a lot of the fragility and jaggedness we see of LMS today come from RLVR, because if you are being non-generous to RLVR, it is kind of by definition optimizing for benchmarks. Like by definition, a verifiable reward is a benchmarkable one. And by adding latent reasoning before the answers, you give the models all the power in the world.

1:04:29to do really well on those benchmarks. So it's very unsurprising. It does very well on benchmarks. And I think a lot of the jaggedness has come from this. And then you get to this whole challenge of adding more and more and more and more and more data in distribution to get more and more diminishing returns to make the jagged frontier even more fractal and spiky, such that it can do some things really reliably, but not super duper.

1:04:58And I think it's gonna be really interesting to see how this plays out because they're spending like a lot of money on this. And it seems like it's not yet super general is what I would get the sense of. And I think that our path to generality is going to be a lot easier from what I've seen. But by far, the easiest for generality was RLHF. RLHF was ridiculously easy to make it general because it was very, very good at writing human pleasing stuff because that is subjective. So I think that This is one of those, you get what you optimize for, but you need to be aware of the real world. And the real world is how good are like these compressed versions of the internet at surfacing intelligence. And I think that they're incredibly good at writing text to please people. They are quite good at system one tasks, but they are, it's quite a battle to get them good at the system two tasks. Hence the extreme jaggedness that we're seeing right now. It'll be really interesting to see where it goes though.

1:05:59very excited to see the models evolve. I'm not sure that that answers why a dev model like well a do you agree that uh that in this that this domain of business decision making like is generalization is harder in this domain than in text or do you think that that's that premise is incorrect? I would disagree.

1:06:25I would, or depending on what you mean by text, if you mean like, is what's harder follow a simple business workflow or solve a millennium price problem in math, I would bet quite a lot that the math problem is a lot harder. People might disagree and bet otherwise, but that that violates too much common sense for me to say anything else. Okay, so let's peel this back like part of I think the question is like, or part of where I'm coming from is like I'm trying to compare model to model, not like harness to Jev. And now here's where you can like correct me. I'm thinking of Jev as more akin to a model and less akin to a harness. And I see the distinction. Actually, what I think I was talking about was imagine that there's like a like a grand graph of

1:07:25a grand plot of how much generality there is. I believe I was talking about the slope of the curve for different objectives. And my claim is that absent where models are today, my claim is that RLHFs is by far the easiest, then RLCDs, then RLVRs. So I'm making a claim about the general space of the task. As far as models goes, Jev is like extremely early down its curve, right? Like it is literally our first public release. It should be treated like an early chat GPT. And I would guess that in terms of like overall robustness, the RLHF models are very bad at decision making. So I would guess that our models would be less good at decision making than the biggest RLVR models, but a lot better than like the non reasoning RLHF models. And that's kind of where I would guess

1:08:26we are at today, and as we really scale up our efforts, I would expect us to greatly overtake everything, at least for business workflows. But again, first model, early research preview, and yeah, please, if there's like dumbness in the model, we love to hear about it and fix it. There's a lot for us to keep on doing, and I believe it's going to be a lifelong journey.

1:08:54to add every single nine of reliability into the model and every single nine will unlock all sorts of crazy use cases. So be understanding and also I think it's already hella useful and smart and also I think it can get a lot better too and it is not in the extreme plateau of diminishing returns like other models are. So that last comment of mine prompted another thought which is like this relationship between model and harness and I think in the case of LLMs, like LLMs were, you know, useful. But then we added harnesses to LLMs and they became a lot more useful. You can tell me whether you agree or disagree. But with regards to Jev, like, is Jev like mostly model a little bit of harness and...

1:09:52A lot of innovation can come by expanding that harness. Is it mostly harness, a little bit of model? Is there a similar, does it even make sense to think about that same relationship between model and harness? What would the harness do in the case of Jeff? Perfect. I will actually rename into my terminology real quick. That harness is code.

1:10:20debate that simply adding a while loop on the LMS and tool calls is what made them good, because I don't actually want to discount all the efforts that ML people put into that. I was not inside the labs at the time, but I'm fairly certain the gigantic jump that happened with Cloud Code around November 2025. Cloud Code was released months beforehand, and it was not that popular, and then there was a giant jump later.

1:10:48My guess is this is what happened when they finally put it in distribution? Because you get what you optimize for and I think that is what's made cloud code very good being put what you said put it into distribution you mean the code the code distribution literally yes cloud code or things like cloud code I don't have access to their data obviously, but I would wager that there was a gigantic Data jump in between where they decided to make a big bet to put that in distribution So and I believe that is why Agents started working. Are you saying that like I think you know broadly You know, there's this narrative that like Claude was great But Claude code was this harness that you know use the clause Claude models and made them a lot more useful to people And what I hear you saying is that maybe something like that was Coincidental and the harness wasn't really

1:11:48you know, the step function, but there was some model innovation that allowed the harness to be useful, a data innovation. Yep. That is what fits my timeline of it. But again, I'm talking about it from the outside. When cloud code was released, technically the shape of cloud code is very powerful, just like the shape of classifiers is very powerful, but it's only as powerful as the intelligence behind it. And as far as I can recall of that time period, Cod code was like a very niche weird thing that people didn't use very much. And people eventually feel the pain of unreliability and stop using it. A similar thing happened with Open Claw. Open Claw obviously has a very powerful shape. People are continuing to innovate in that direction right now. And the problem was not the shape or the harness. The problem was the intelligence behind it. Maybe the right harness can harness the intelligence better. But like...

1:12:47in, thank you. But in that case, it's like it would be remiss to blame the open claw harness, because the intelligence can evolve too. And you need to be aware of reality and making these things. So it wouldn't surprise me if the, I don't know what the general term for this is like cloud assistance, whatever everyone is doing right now. It wouldn't surprise me if these start getting way better because they are put in distribution. And it is it is not a stab at Open Claw. Open Claw did a really awesome interface jump, just like Clawed Codes interface jump was very cool, even if they didn't make the model very good at it. I want to say that I don't think it's purely the harness that gave it its capabilities. The thing we're calling harness needs to map the capabilities in the model in order to be useful. I would actually not call it harness per se, I would call it code.

1:13:44And I would call the thing wrapping our model code as well. Our model is much lower level than an LLM is. And that thing, is that thing a type safe thing or are you talking about the user's code that has access to the model? The user's code. The user's code. Yeah. Yeah. It's actually, it's weird for the logic to be running on someone else's server if your system message has like your whole business algorithm on it. That's very unusual for an API.

1:14:13Normally you outsource that to an API the work that you own only the API can do and you actually not rather give it all of your business secrets or anything like that. So this is just like more like a normal API. And I like to think of it as like one day intelligence will be like databases where you just call it when you need it when you need intelligence within your code. So I think that type safe requires code. I cannot imagine I find it a little bit fun to play with the models.

1:14:43but it's not useful to look at probabilities. The probabilities are only meaningful if they go into an application that then does something that ideally eventually delights a user or provides value. So it's like a type safe cannot be used without code. If you are a non-coder, it's really cool that you're interested in our model. I'm kind of confused. I would love to ask you why you're interested and also like it's made for coding. Sorry, it's not made for writing code. It's made.

1:15:10for enhancing the power of code itself. Exactly, which is very different from where LMS are because they are mostly used for writing the code, which has the same expressive power as it's had for the last decade or so. So just kind of to pull that back, what I'm hearing is that iJev is at its core model and you don't right now see like a roll for quote unquote harness.

1:15:39between you and the user that you control that's like the while loop thingy or that's fetching external contacts, but rather every user is going to embed that Jev model into their code and they're essentially providing the harness that makes sense for them. Yeah. And actually, I just reject the notion of harness entirely. I think that higher level abstractions could exist for Jev like models, but like a harness itself is just, it's a very, Horseless carriage type thing of trying to turn the intelligence into something that looks like a human Which is cool if it works to have no doubt like if it worked I would have tons of them, but as far as I can tell it doesn't yet so I don't And if that's just not necessary for like the massive amount of automation that I think needs to get done so we think that And yet like you know like we don't need like the same hardness everywhere what we need is for the users to be able to like

1:16:38put to their logic in there, which is what software engineers do. They like hyper literally specify the logic of automation in order to create value. And we want to expand the vocabulary of logic that they can put in. And I'd like to think of it more like any 10 nodes, you know, or any kind of like, I don't know if there's a general name for that, like WYSIWYG style, no code editors. Like we are just like one of the nodes that maybe you put a lot of the place. Exactly.

1:17:08But the rest of the logic is all you. And the data is all you too, right? Like that is how you make stuff do valuable things. All right. So you've brought up open claw a few times. You know, one interesting potential opportunity for Jeff is inside of all of these agenda carnices or frameworks or whatever we want to call them. Because those things make a lot of orchestration decisions.

1:17:37that right now are being driven by text-based models and maybe there's a better way to do that. Like, what's your take on Java plus agents? Ooh, ooh, ooh, ooh. There's so many, that is surprisingly high number of breadcrumbs you've added in there. So, I'll answer it in a couple of levels. Number one, we obviously want to make it work, but number two, we are definitely not experts at this.

1:18:05And it seems like the experts at this are playing around and trying to figure out the killer use cases and everything. So we want to really help those people crush it and create lots of value and ideally make agents a lot more either reliable or efficient or ideally both. That would be ideal. Fast would be cool too, but it feels like I would prefer reliability and a lot of businesses would prefer cost.

1:18:32So given all of that, like Jeff is meant to be this like general technology that understands like common sense and can be helpful all over the place. I did actually share a write-up I had. I actually have a blog post related to this called KV Cash Rules Everything Around Me, like CACHE. Somehow no one on the internet has said cash rules everything around me beforehand.

1:18:59with a CACHG, and I can't believe I was the first one to say this. So number one, I have a blog post about why agents are extremely beholden to their KV caches, and why a lot of the design of an agent very obviously comes from the constraint of knowing that the KV cache is extremely expensive and very sensitive, like you don't want to pollute it. So things like why don't people use more sub-agents? Why does routing tend to not work? All of this I go into like my my blog post. I've also released a Google Doc, which I kind of regret because I keep getting share requests for it of people who want to like edit my Google Doc or something. But I had this internal design of how could Jeff be used for coding agents, because once upon a time, we thought that we would be a bit more stealthy. And we thought we would be building products ourselves. And that cat is now totally out of a bag because we decided not to do that. But

1:19:58Yeah, I think that there's so many cool things that can happen if you just assume that You don't need a append only kvcash like a kvcash is a great for saving money, right? But also very constraining it prevents a lot of like cool programming patterns like fanning out and filtering and reordering and stuff like that and It's I love the interview question. How would you design a coding agent if?

1:20:28KV caching didn't exist. It really makes you rethink how agents could work. And I think it's a really useful intellectual direction for figuring out how to design agents. If, for example, you had like extremely cheap, but reliable intelligence on the fly. And I think there's so many cool things that can be done. You know, the KV cache is a little bit similar to like having global variables everywhere. But what if you could be smart about your state? Why do you need the full view?

1:20:56of like every past decision you've ever made for all the future decisions too because presumably when you're in a moment there's extra information you might want that you could like insert get the decisions out pop it off the stack and like really curate this KVcast or even do super sick things like like log of n lookups within your context nothing stops you from doing like hierarchical searches within your context and that way you don't need to have the same thing over and over and over again Another gigantic use case is actually tool calls. Tool calls, number one, result in context rock, because they require tons of context up front. Number two, you don't always need them. And number three, because the models have been overfitted to their native harnesses, they tend to call the native tools a lot more than the ones you plug in so the models don't end up calling them that much. What if you could provide logit biases to your tool calls to fine-grainly control when things are inserted or not without poisoning your context?

1:21:54There's so many cool things that could be done. If I wish I could work on it. Ah, this would be so cool. It would have been so cool. So the agent architecture is potentially very different in a kind of Jev Greenfield world, and you're leaving it as an exercise to the listener or for the listener. Well, I think there's an interesting intellectual direction to look there. Pragmatically, we need to care about what actually works in the real world.

1:22:21And there might even be limitations of Jev, such that this is currently Jev 1.13. Maybe you need Jev 1.16 to actually get all of this working. Who knows? It's going to be like a wide open, really fun world. My guess is the future is going to be hybrids that slowly add more and more logic, because it's very hard to add additional hardness logic into the cloud codes and codexes, because their core loop is just a while loop.

1:22:48in general, adding logic is expensive, so it takes a while to like really tune. But once you have software that works, it's really lovely when it works. So my guess is people will be building up more and more and more software that latches into these harnesses until they switch over into being a lot more software and a lot less magic while loop. Very early on, I mentioned I wanted to come back to a particular point and fundamentally around like You know, when you think about architecting around decision models or whatever we want to call the broader category that Jeff says in, that would require like more traditional kind of workflow orientation versus like where we've kind of arrived at with agents and agent software is like...

1:23:44Okay, well, let's generate some context and give it to an LLM and let it spit back some answers and call some tools, which are essentially the next steps. And like, I guess I want to poke at like, you know, in some ways it feels like, you know, if you set aside the fact that this world that we move to doesn't really work all that well reliably, right? Which is kind of important. It's kind of important, yes. But like, let's set that aside, like, There's a certain agility to being able to hand off all your decisions to this one thing and let it run in a loop and let it call, call, you know, next actions and like return to this loop. Whereas like decomposing everything into these much more like static or rigid workflows, like creates a lot of debt over time, creates a lot of complexity. And like, you know, does Jeff require us to move back there or?

1:24:42How do you think about that? Like, I've kind of set this up. Okay. Yeah. You set it up very unfairly because you put aside the reliability issue. I'm recognized. I'm recognized. But I'm open to that. And actually, I think that this is a fun hypothetical question because I never not think about reliability. But I actually think that it's actually a feature to many actual uses. Like, obviously, there's a long tail and there's going to be a lot of uses.

1:25:11that is not worth automating. This is the tragic problem of just doing work as a software engineer. Do I write a bash script for this that will take me four hours, or do I just do it in five minutes? And I'm the kind of guy who would probably write the bash script more often than not. But there's a dilemma here. So I would guess for a lot of work, it's probably worth it to just give it to the unreliable LM and hope that it works right. And then you can just check its work if it's not. But if you're actually trying to scale something, Like if it's a workflow that is so valuable that you'd want tons of people to do this, or you'd want to run it a lot in the background, or, and this is the part that I think no one really gets in LLM land, if you want it to be like closed away in the box and run in the background and have it be a dependency that you just call forever, that's the kind of thing where it makes sense to really engineer that system upfront. And it actually makes sense to maintain it over time, because that provides value forever versus like having to rediscover the logic every single time.

1:26:11So I think that people just don't think of LLMs as composable and layerable and something that can be the foundation of greater and greater cognitive abstractions, because LLMs are so unbelievably bad at this, and it is a feature to be on the rails. You don't want to go an amusement park that doesn't have its rails, or at least you can't do the most fun stuff without the rails and the seat belts and all of that. So I think it's going to be a very similar thing.

1:26:40for the most valuable parts of AI software. You're saying that the automating with this, you know, unreliable-ish thing is kind of a, it's an oasis and you're not going to fully get there. And the fact that we force you to, that Jeff like would force you to like more traditional code and like workflows and all that isn't necessarily is a feature.

1:27:08I think is the positioning that you it's a feature for automation. It is not a feature for just in time stuff So like if you're doing stuff on the fly, that's a one-off like of course It's not worth it to write a big old automation for that and there's lots of in between like actually if you've seen quad codes dynamic workflows dynamic workflows are super cool and Nothing stops you from actually having an LLM right, you know understand your task write a workflow for map producing across your documents in your company brain or whatever is hot these days. But actually it could call dev models in it because there's a lot of documents and you don't actually want opus 5.5 to reason over the whole thing. So there's a lot of middle grounds over there and the world is going to be our oyster for creativity. We've talked a lot about kind of broadly what's next but like if you had to like

1:28:02directly answer what's next, like what comes to mind. It's hard for me to say without shit talking other people. We'll start shit talking then. Our advisors have told me that I've been much too nice online. I think that I'd rather just genuinely be me and like I have spite obviously against like AI misinformation but I actually don't want to be spiteful at any particular release or product. So I don't actually want to go down that direction really. We have a lot of stuff that we want to be shipping. And it's, oh man, I'm so excited to tell people, and not to tell people, to show people why we call them System 1 models. That's going to be cool. We have a lot of stuff we have in the tank as well of, hey, it's going to be really complicated to launch with multiple models.

1:29:00Let's keep it simple for now. So I'm so excited for that, too. I'm excited to have an early access program of some sort. I want people to be able to play with the earlier models we have that don't necessarily have our stamp of reliability, but we think is better than anything else out there. Man, I'm just excited for stuff. Technologically, I also have a lot of company building to do, which I really don't like.

1:29:29So if anyone wants to be working for someone, I would love to hire a Jillian people and hopefully that'll make my life a little bit easier. Well, Diogo, it's been wonderful catching up, way overdue. You've been doing some interesting things over the years, but we should do this more. We should definitely do this more in great moment in time for Typesafe. Congrats on the recent success and traction with Jeff.

1:29:58Thank you, and I do believe that this is just the first of many. So, just you wait. You might have me on here sooner than you think. Alrighty. We'll keep in touch. Thank you. Heck yeah. Have a good one.