#447 – Cursor Team: Future of Programming with AI

Aman Sanger, Arvid Lunnemark, Michael Truell, and Sualeh Asif are creators of Cursor, a popular code editor that specializes in AI-assisted programming. Thank you for listening ❤ Check out our sponsors: https://lexfridman.com/sponsors/ep447-sc See below for timestamps, transcript, and to give feedback, submit questions, contact Lex, etc. Transcript: https://lexfridman.com/cursor-team-transcript CONTACT LEX: Feedback – give feedback to Lex: https://lexfridman.com/survey AMA – submit questions, videos or call-in: https://lexfridman.com/ama Hiring – join our team: https://lexfridman.com/hiring Other – other ways to get in touch: https://lexfridman.com/contact EPISODE LINKS: Cursor Website: https://cursor.com Cursor on X: https://x.com/cursor_ai Anysphere Website: https://anysphere.inc/ Aman’s X: https://x.com/amanrsanger Aman’s Website: https://amansanger.com/ Arvid’s X: https://x.com/ArVID220u Arvid’s Website: https://arvid.xyz/ Michael’s Website: https://mntruell.com/ Michael’s LinkedIn: https://bit.ly/3zIDkPN Sualeh’s X: https://x.com/sualehasif996 Sualeh’s Website: https://sualehasif.me/ SPONSORS: To support this podcast, check out our sponsors & get discounts: Encord: AI tooling for annotation & data management. Go to https://encord.com/lex https://lexfridman.com/s/encord-ep447-sc MasterClass: Online classes from world-class experts. Go to https://masterclass.com/lexpod https://lexfridman.com/s/masterclass-ep447-sc Shopify: Sell stuff online. Go to https://shopify.com/lex https://lexfridman.com/s/shopify-ep447-sc NetSuite: Business management software. Go to http://netsuite.com/lex https://lexfridman.com/s/netsuite-ep447-sc AG1: All-in-one daily nutrition drinks. Go to https://drinkag1.com/lex https://lexfridman.com/s/ag1-ep447-sc OUTLINE: (00:00) – Introduction (09:25) – Code editor basics (11:35) – GitHub Copilot (18:53) – Cursor (25:20) – Cursor Tab (31:35) – Code diff (39:46) – ML details (45:20) – GPT vs Claude (51:54) – Prompt engineering (59:20) – AI agents (1:13:18) – Running code in background (1:17:57) – Debugging (1:23:25) – Dangerous code (1:34:35) – Branching file systems (1:37:47) – Scaling challenges (1:51:58) – Context (1:57:05) – OpenAI o1 (2:08:27) – Synthetic data (2:12:14) – RLHF vs RLAIF (2:14:01) – Fields Medal for AI (2:16:43) – Scaling laws (2:25:32) – The future of programming PODCAST LINKS: – Podcast Website: https://lexfridman.com/podcast – Apple Podcasts: https://apple.co/2lwqZIr – Spotify: https://spoti.fi/2nEwCF8 – RSS: https://lexfridman.com/feed/podcast/ – Podcast Playlist: https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4 – Clips Channel: https://www.youtube.com/lexclips

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Lex Fridman?

  The following is a conversation with the founding members of the Cursor team. Michael Truul, Swaley Asif, Arvid Lundmark, and Aman Sanger. Cursor is a code editor based on VS Code that adds a lot of powerful features for AI-assisted coding. It has captivated the attention and excitement of the programming and AI communities. So I thought this is an excellent opportunity to dive deep into the role of AI in programming. This is a super technical conversation that is bigger than just about one code editor. It's about the future of programming and in general, the future of human AI collaboration

• 0:42Lex Fridman?

  in designing and engineering complicated and powerful systems. And now, a quick few second mention of each sponsor. Check them out in the description. It's the best way to support this podcast. We've got Encore for unifying your machine learning stack, MasterClass for learning, Shopify for selling stuff online, NetSuite for your business, and AG1 for your health. Choose wisely, my friends. Also, if you want to get in touch with me for whatever reason, or take a survey, or submit questions for an AMA, all of that would be great. Go to lexreaming.com/contact. And now, onto the full ad reads. I try to make them interesting, but if you skip them, please still check out our sponsors. I enjoy their stuff. Maybe you will too.

• 1:28Lex Fridman?

  This episode is brought to you by Encore, a platform that provides data-focused AI tooling for data annotation, curation, management, and for model evaluation. One of the things I love about these guys is they have a great blog that describes cleanly, I mean, it's technical, but it's not too technical, but it's sufficiently technical to where it's actually describing the ideas, not BS, blog posts on the sort of the state of the art, like the OpenAI O1 model that was just released. So sometimes they integrate it into why this is a part of Encore, why this makes sense, and sometimes not. And so I love that. I recommend their blog just in general. That said, you know, when they are looking at state-of-the-art models,

• 2:12Lex Fridman?

  they are always looking for ways to integrate it into their platform. Basically, it's a place to organize your data, and data is everything. This was true before the popularity and the explosion of attention methods of transformers.

• 2:26Lex Fridman?

  And it is still very much true now. Sort of the non-synthetic, the human-generated data is extremely important. How you generate that data, how you organize that data, how you leverage it, how you train on it, how you fine-tune on it, the pre-training, the post-training, all of it, the whole thing. Data is extremely, extremely important. And so Encore takes data very seriously. Anyway, go try out Encore to create, annotate, and manage your AI data at encord.com/lex. That's encord.com/lex.

• 2:58Lex Fridman?

  This episode is also brought to you by MasterClass, where you can watch over 200 classes from the best people in the world in their respective disciplines. Carlos Santana on guitar, for example. I loved that one. There's a few guitar ones, Tom Morello, too. Great, great, great stuff. But Carlos Santana, his instrumental Europa, I haven't quite tried to play that, but it's on my to-do list. It's sort of one of those things, you know for sure, this is a thing I will play, because it's too beautiful. It's too soulful. It feels like, once you play, you understand something about the guitar that you didn't before. It's not blues, it's not, I don't know what it is.

• 3:41Lex Fridman?

  It's some kind of dreamlike teleportation into a psychedelic world, where the tone is warmer than anything else I've ever heard. And still, the guitar can cry. I don't know. I love it. He's a genius. So it's such a gift that you can get a genius like that to teach us about his secrets. Get unlimited access to every MasterClass and get an additional 15% off an annual membership at masterclass.com/lexpod. That's masterclass.com/lexpod.

• 4:21Lex Fridman?

  This episode is also brought to you by Shopify, a platform designed for anyone to sell anywhere with a great looking online store, or a simple looking online store, like the one I put together at lexfridman.com/store. I have a few shirts on there, in case you're interested. And speaking of shirts, I'm reminded of thrift stores, which I very much loved for a long time. I still love thrift stores, or a nice place to get stuff, like, I don't know, kitchen stuff and clothing. And the kind of clothing you get at thrift stores is actually pretty interesting, because there's shirts there, they're just unlike anything else you would get anywhere else.

• 5:03Lex Fridman?

  So if you're selective and creative minded, there's a lot of interesting fashion that's there. And in terms of t-shirts, there's just hilarious t-shirts. T-shirts that are very far away from the kind of trajectories you have taken in life, or are not, but you just haven't thought about it. Like a band that you love, but you've never would have thought to wear their t-shirt. Anyway, a little bit, I think of Shopify as the internet's thrift store. Of course, you can do super classy, you can do super fancy, or you can do super thrift. All of it is possible. Sign up for a $1 per month trial period at Shopify.com/lex.

• 5:42Lex Fridman?

  That's all lowercase. Go to Shopify.com/lex to take your business to the next level today. This episode is also brought to you by NetSuite, an all-in-one cloud business management system. Sometimes I think that NetSuite is supporting this podcast because they're trolling me. They're saying, "Hey Lex, aren't you doing a little too much talking? Maybe you should be building more." I agree with you, NetSuite. I agree with you. And so every time I do an ad read for NetSuite, it is a chance for me to confront My Jungian shadow, some of the demons emerge from the subconscious and ask questions that I don't have answers to.

• 6:26Lex Fridman?

  Questions about one's mortality and that life is short. And that one of the most fulfilling things in life is to have a family and kids and all of these things I would very much like to have. And also the reality that I love programming and I love building. I love creating cool things that people can use and share and that would make their life better. All of that. Of course, I also love listening to podcasts and I kind of think of this podcast as me listening to a podcast where I can also maybe participate by asking questions. So all these things that you love, but you ask the hard question of like, okay, while life is slipping away, it's short. It really, really is short.

• 7:08Lex Fridman?

  What do you want to do with the rest of the minutes and the hours that make up your life? Yeah. So, thank you for the existential crisis, NetSuite. I appreciate it. If you're running a business, if you have taken the leap into the unknown and started a company, then you should be using the right tools to manage that company. In fact, over 37,000 companies have upgraded to NetSuite. Take advantage of NetSuite's flexible financing plan at netsuite.com/lex. That's netsuite.com/lex. This episode is also brought to you by the delicious, the delicious AG1. It's an all-in-one daily drink to support better health and peak performance. It's basically a super awesome multivitamin that makes me feel like I have my life together.

• 7:53Lex Fridman?

  Even when everything else feels like it's falling apart, at least I have AG1. At least I have that nutritional foundation to my life. So the fasting I'm doing, all the carnivore diets, all the physical endurance events and the mental madness of staying up all night or just the stress of certain things I'm going through, all of that, AG1 is there.

• 8:17Lex Fridman?

  At least they have the vitamins. Also, I sometimes wonder, they used to be called Athletic Greens, and now they're called AG1. I always wonder, is AG2 coming? Like, why is it just one? It's an interesting branding decision, like AG1. Me, as an OCD kind of programmer type, it's like, okay, is this a versioning thing? Okay, is this like AG 0.1 Alpha? When's the final release?

• 8:46Lex Fridman?

  Anyway, the thing I like to say and to consume is AG1. They'll give you one month's supply of fish oil when you sign up at drinkag1.com/lex. This is the Lex Fridman Podcast. To support it, please check out our sponsors in the description. And now, dear friends, here's Michael, Swale, Arvid, and Aman.

• 9:25Lex Fridman?

  All right, this is awesome. We have Michael, Aman, Swale, Arvid here from the Cursor Team. First up, big ridiculous question. What's the point of a code editor?

• 9:36Speaker 01

  So the code editor is largely the place where you build software. And today, or for a long time, that's meant the place where you text edit a formal programming language. And for people who aren't programmers, the way to think of a code editor is like a really souped up word processor for programmers, where the reason it's souped up is code has a lot of structure. And so the quote unquote word processor, the code editor, can actually do a lot for you that word processors, you know, sort of in the writing space, haven't been able to do for people editing text there. And so, you know, that's everything from giving you visual differentiation of like the actual tokens in the code, so you can like scan it quickly, to letting you navigate around, the codebase, sort of like you're navigating around the internet with like hyperlinks,

• 10:19Speaker 01

  you're going to sort of definitions of things you're using, to error checking, to, you know, to catch rudimentary bugs.

• 10:28Speaker 02

  And so traditionally, that's what a code editor has meant. And I think that what a code editor is, is going to change a lot over the next 10 years as what it means to build software maybe starts to look a bit different.

• 10:43Lex Fridman?

  I think also a code editor should just be fun.

• 10:45Speaker 03

  Yes, that is very important. That is very important. And it's actually sort of an underrated aspect of how we decide what to build. Like, a lot of the things that we build and then we try them out, we do an experiment, and then we actually throw them out because they're not fun. And so a big part of being fun is like being fast a lot of the time. Fast is fun.

• 11:09Lex Fridman?

  Yeah, fast is...

• 11:11Lex Fridman?

  Yeah, that should be a T-shirt.

• 11:14Speaker 02

  Like fundamentally, I think one of the things that draws a lot of people to building stuff on computers is this like insane iteration speed where, you know, in other disciplines, you might be sort of gate capped by resources or the ability, even the ability, you know, to get a large group together and coding is this like amazing thing where it's you and the computer and that alone, you can, you can build really cool stuff really quickly.

• 11:36Lex Fridman?

  So for people who don't know, Cursor is this super cool new editor that's a fork of VS Code. It would be interesting to get your kind of explanation of your own journey of editors. How did you, I think all of you are, were big fans of VS Code with Copilot. How did you arrive to VS Code and how did that lead to your journey with Cursor?

• 11:59Speaker 02

  Yeah, so I think a lot of us, well, all of us originally were VIM users.

• 12:06Speaker 03

  Pure, pure VIM.

• 12:07Speaker 02

  Pure VIM, yeah. No Neo VIM, just pure VIM and a terminal. And at least for myself, it was around the time that Copilot came out, so 2021, that I really wanted to try it. So I went into VS Code, the only platform, the only code editor in which it was available. And even though I, you know, really enjoyed using VIM, just the experience of Copilot with, with VS Code was more than good enough to convince me to switch. And so that kind of was the default until we started working on Cursor.

• 12:40Lex Fridman?

  And maybe we should explain what Copilot does. It's like a really nice autocomplete. It suggests, as you start writing a thing, it suggests one or two or three lines, how to complete the thing. And there's a fun experience in that. You know, like when you have a close friendship and your friend completes your sentences? Like, when it's done well, there's an intimate feeling. There's probably a better word than intimate, but there's a, there's a cool feeling of like, holy shit, it gets me. Now, and then there's an unpleasant feeling when it doesn't get you. And so there's that, that kind of friction. But I would say for a lot of people, the feeling that it gets me overpowers that it doesn't.

• 13:21Speaker 03

  And I think actually, one of the underrated aspects of GitHub Copilot is that even when it's wrong, it's, it's like a little bit annoying, but it's not that bad because you just type another character and then maybe then it gets you, or you type another character and then, then it gets you. So even when it's wrong, it's not that bad.

• 13:35Speaker 04

  Yeah, you, you can sort of iterate, iterate and fix it. I mean, the other underrated part of Copilot for me sort of was just the first real, real AI product. So the first language model consumer product.

• 13:47Lex Fridman?

  So Copilot was kind of like the first killer app for LLMs.

• 13:52Speaker 01

  Yeah. And like the beta was out in 2021.

• 13:55Lex Fridman?

  Right. Okay. So what's the, the origin story of Cursor?

• 14:00Speaker 01

  So around 2020, the scaling loss papers came out from, from OpenAI. And that was a moment where this looked like clear predictable progress for the field, where even if we didn't have any more ideas, it looks like you could make these models a lot better if you had more compute and more data.

• 14:16Lex Fridman?

  By the way, we'll probably talk for three to four hours on, on the topic of scaling loss. But just, just to summarize, it's a paper and a set of papers and set of ideas that say bigger might be better for model size and data size in the, in the realm of machine learning.

• 14:31Speaker 04

  It's bigger and better, but predictably better.

• 14:35Lex Fridman?

  Okay, that's another topic of conversation.

• 14:36Speaker 01

  Yeah. So around that time, for some of us, there were like a lot of conceptual conversations about what's this going to look like? What's the, the story going to be for all these different knowledge worker fields about how they're going to be made better by this technology getting better? And then I think there were a couple of moments where like the theoretical gains predicted in that paper started to feel really concrete and it started to feel like a moment where you could actually go and not do a PhD if you wanted to work on, do useful work in AI. It actually felt like now there was this, this whole set of systems one could build that were really useful. And I think that the first moment, we already talked about a little bit, which was playing with the early bit of Copilot, like that was awesome and magical. I think that the next big moment where everything kind of

• 15:20Speaker 01

  clicked together was actually getting early access to GPT-4. So it was sort of end of 2022 was when we were tinkering with that model and the step up in capabilities felt enormous. And previous to that, we had been working on a couple of different projects. We had been, because of Copilot, because of scaling laws, because of our prior interest in the technology, we had been tinkering around with tools for programmers, but things that are like very specific. So, you know, we were building tools for financial professionals who have to work within a Jupyter Notebook, or like, you know, playing around with can you do static analysis with these models? And then the step up in GPT-4 felt like, look, that really made concrete the theoretical gains that we had predicted before. Felt

• 16:03Speaker 01

  like you could build a lot more just immediately at that point in time. And also, if we were being consistent, it really felt like this wasn't just going to be a point solution thing. This was going to be all of programming was going to flow through these models. It felt like that demanded a different type of programming environment, a different type of programming. And so we set off to build that, that sort of larger vision around that.

• 16:26Speaker 04

  There's one that I distinctly remember. So my roommate is an IML Gold winner and there's a competition in the US called the Putnam, which is sort of the IMO for college people. And it's this math competition. He's exceptionally good. So Shengtong and Aman, I remember it's sort of June, June of 2022, had this bet on whether the mod, like 2024 June or July, you were going to win a gold medal in the IMO with, with like models.

• 16:57Lex Fridman?

  IMO is the International Math Olympiad.

• 16:59Speaker 04

  Yeah, IMO is International Math Olympiad. And so Arvind and I are both, you know, also competed in it. So it was sort of personal. And I remember thinking, Matt, this is not going to happen. This was like, it was like, even though I sort of believed in progress, I thought. You know, I'm a girl, just like Aman is just delusional.

• 17:22Speaker 02

  Yeah.

• 17:22Speaker 04

  That was the, that was the, and to be honest, I mean, I, I was, to be clear, very wrong. But that was maybe the most prescient bet in the group.

• 17:31Lex Fridman?

  So the, the new results in DeepMind, it turned out that you were correct. That's what the.

• 17:36Speaker 02

  Well, it was technically not.

• 17:38Speaker 01

  Technically incorrect, but one point away. Aman was very enthusiastic about this stuff. Yeah. And before, Aman had this like scaling laws T-shirt that he would walk around with. It had the like charts and like the formulas on it.

• 17:51Lex Fridman?

  So you like felt the AGI or you felt the scaling laws?

• 17:55Speaker 02

  Yeah, I distinctly remember there is this one conversation I had with, with Michael where before I hadn't thought super deeply and critically about scaling laws. And he kind of posed the question, why isn't scaling all you need? Or why isn't scaling going to result in massive gains in progress? And I think I went through like the, like the stages of grief. There is anger, denial, and then finally at the end, just thinking about it, acceptance. And I think I've been quite hopeful and optimistic about progress since. I think one thing I'll caveat is I think it also depends on like which domains you're going to see progress.

• 18:34Speaker 02

  Like math is a great domain because especially like formal theorem proving, because you get this fantastic signal of actually verifying if the thing was correct. And so this means something like RL can work really, really well. And I think like you could have systems that are perhaps very superhuman to math and still not technically have AGI.

• 18:53Lex Fridman?

  Okay, so can we take it all the way to Cursor?

• 18:56Speaker 02

  Mm hmm.

• 18:57Lex Fridman?

  And what is Cursor? It's a fork of VS Code and VS Code is one of the most popular editors for a long time. Like everybody fell in love with it. Everybody loved Vim. I left Emacs for it. Sorry.

• 19:13Lex Fridman?

  So unified in some fundamental way, the, the developer community. And then you look at the space of things, you look at the scaling laws, AI is becoming amazing. And you decided, okay, it's not enough to just write an extension for VS Code.

• 19:30Lex Fridman?

  Because there's a lot of limitations to that. We need, if AI is going to keep getting better, better, better, we need to really rethink how the AI is going to be part of the editing process. And so you decided to fork VS Code and start to build a lot of the amazing features we'll be able to talk about. But what was that decision like? Because there's a lot of extensions, including Copilot, of VS Code that are doing sort of AI type stuff. What was the decision like to just fork VS Code?

• 19:59Speaker 02

  So the decision to do an editor seemed kind of self-evident to us for at least what we wanted to do and achieve. Because when we started working on the editor, the idea was these models are going to get much better. Their capabilities are going to improve and it's going to entirely change how you build software. Both in a you will have big productivity gains, but also radical and now like the act of building software is going to change a lot. And so you're very limited in the control you have over a code editor. If you're a plugin to an existing coding environment. And we didn't want to get locked in by those limitations. We wanted to be able to just build the most useful stuff.

• 20:34Lex Fridman?

  Okay, well, then the natural question is, you know, VS Code is kind of with Copilot a competitor. So how do you win? Is it basically just the speed and the quality of the features?

• 20:46Speaker 02

  Yeah, I mean, I think this is a space that is quite interesting, perhaps quite unique. Where if you look at previous tech waves, maybe there's kind of one major thing that happened and unlocked a new wave of companies. But every single year, every single model capability or jump you get model capabilities. You now unlock this new wave of features, things that are possible, especially in programming. And so I think in AI programming, being even just a few months ahead, let alone a year ahead, makes your product much, much, much more useful. I think the cursor a year from now will need to make the cursor of today look obsolete.

• 21:28Speaker 02

  And I think, you know, Microsoft, they've done a number of like fantastic things, but I don't think they're in a great place to really keep innovating and pushing on this in the way that a startup can.

• 21:39Lex Fridman?

  Just rapidly implementing features.

• 21:42Speaker 02

  And push, yeah, like, and, and kind of doing the research experimentation necessary to really push the ceiling.

• 21:50Speaker 04

  I don't, I don't know if I think of it in terms of features as I think of it in terms of like capabilities for, for programmers. It's that like, you know, as.

• 21:59Speaker 04

  You know, the new one model came out and I'm sure there are going to be more, more models of different types, like longer context and maybe faster. Like, there's all these crazy ideas that you can try and hopefully 10% of the crazy ideas will make it into something kind of cool and useful. And we want people to have that sooner. To rephrase, it's like, an underrated fact is we're making it for ourselves. When we started Cursor, you really felt this frustration that, you know, models, you could see models getting better. But the Copilot experience had not changed. It was like, man, these guys, like, the ceiling is getting higher. Like, why is they not making new things? Like, they should be making

• 22:41Speaker 04

  new things. They should be like, you're like, like, where's, where's, where's all the alpha features? There, there were no alpha features. It was like, I'm sure it was selling well. I'm sure it was a great business, but it didn't feel, I'm, I'm one of these people that really want to try and use new things. And we say, just, there's no new thing for, like, a very long while.

• 23:01Lex Fridman?

  Yeah, it's interesting. I don't know how you put that into words, but when you compare Cursor with Copilot, Copilot pretty quickly became, started to feel stale for some reason.

• 23:12Speaker 03

  Yeah, I think one thing that I think helps us is that we're sort of doing it all in one, where we're developing the UX and the way you interact with a model. And at the same time as we're developing, like, how we actually make the model give better answers. So we're like, how you build up the prompt or, or like, how do you find the context and for a cursor tab, like, how do you train the model? So I think that helps us to have all of it, like, sort of like the same people working on the entire experience end to end.

• 23:43Speaker 04

  Yeah, it's like the, the person making the UI and the person training the model, like, sit to like 18 feet away. So

• 23:50Speaker 02

  Often they're the same person, even.

• 23:52Speaker 04

  Yeah, often, often even the same person. So you, you can, you can create things that are, that are sort of not possible if you're not, you're not talking, you're not experimenting.

• 24:00Lex Fridman?

  And you're using, like you said, Cursor to write Cursor.

• 24:03Speaker 03

  Of course. Oh, yeah.

• 24:04Speaker 04

  Yeah.

• 24:05Lex Fridman?

  Well, let's talk about some of these features. Let's talk about the all-knowing, the all-powerful, praise be to the tab, you know, autocomplete on steroids.

• 24:16Lex Fridman?

  Basically. So what, how does Tab work? What is Tab?

• 24:19Speaker 01

  To highlight and summarize at a high level, I'd say that there are two things that Cursor is pretty good at right now. There are, there are other things that it does. But two things that it helps programmers with. One is this idea of looking over your shoulder and being like a really fast colleague who can kind of jump ahead of you and type and figure out what you're, what you're going to do next. And that was the original idea behind, that was kind of the kernel, the idea behind a good autocomplete was predicting what you're going to do next. But you can make that concept even more ambitious by not just predicting the characters after your cursor, but actually predicting the next entire change you're going to make, the next diff, the next place you're going to jump to.

• 25:01Speaker 01

  And the second thing Cursor is, is pretty good at right now, too, is helping you sometimes jump ahead of the AI and tell it what to do and go from instructions to code. And on both of those, we've done a lot of work on making the editing experience for those things ergonomic and also making those things smart and fast.

• 25:20Speaker 04

  One of the things we really wanted was we wanted the model to be able to edit code for us. That was kind of a wish and we had multiple attempts at it before, before we had a sort of a good model that could edit code for you.

• 25:34Speaker 04

  Then after, after we had a good model, I think there, there have been a lot of effort to, you know, make the inference fast for, you know, having, having a good, good experience. And we've been starting to incorporate, I mean, Michael sort of mentioned this like ability to jump to different places. And that jump to different places, I think, came from a feeling of, you know, once you, once you accept an edit,

• 26:00Speaker 04

  it's like, man, it should be just really obvious where to go next. It's like, it's like I'd made this change, the model should just know that like the next place to go to is like 18 lines down. Like if you're, if you're a WIM user, you could press 18JJ or whatever. But like, why even, why am I doing this? Like, the model, the model should just know it. And then, so, so the idea was, yo, you just press Tab, it would go 18 lines down and then make, it show you, show you the next edit and you would press Tab. So it was just you, as long as you could keep pressing Tab. And so the internal competition was, how many Tabs can we make someone press? Once you have like, the idea, more, more, sort of abstractly, the thing to think about is sort of like, once, how many, how, how are the edits sort of zero, zero entropy?

• 26:45Speaker 04

  So once you've sort of expressed your intent and the edit is, there's no like, new bits of information to finish your thought, but you still have to type some characters to like, make the computer understand what you're actually thinking, then maybe the model should just sort of read your mind and, and all the zero entropy bits should just be like, tabbed away.

• 27:06Speaker 02

  Yeah.

• 27:07Speaker 04

  That was, that was sort of the abstract.

• 27:08Speaker 02

  There's this interesting thing where if you look at language model loss on, on different domains, I believe the bits per byte, which is a kind of character normalized loss for code, is lower than language, which means in general, there are a lot of tokens in code that are super predictable, a lot of characters that are super predictable. And this is, I think, even magnified when you're not just trying to autocomplete code, but predicting what the user's going to do next in their editing of existing code. And so, you know, the goal of cursor tabs, let's eliminate all the low entropy actions you take inside of the editor. When the intent is effectively determined, let's just jump you forward in time, skip you forward.

• 27:48Lex Fridman?

  Well, well, what's the intuition and what's the technical details of how to do next cursor prediction? That, that jump, that's not, that's not so intuitive, I think, to people.

• 27:57Speaker 02

  Yeah. I think I can speak to a few of the details on how, how to make these things work. They're incredibly low latency, so you need to train small models on this, on this task. In particular, They're incredibly pre-fill token hungry. What that means is they have these really, really long prompts where they see a lot of your code and they're not actually generating that many tokens. And so the perfect fit for that is using a sparse model, meaning an MOE model. So that was kind of one breakthrough we made that substantially improved its performance at longer context. The other being a variant of speculative decoding that we kind of built out called speculative edits.

• 28:39Speaker 02

  These are two, I think, important pieces of what make it quite high quality and very fast.

• 28:46Lex Fridman?

  Okay, so MOE mixture of experts. The input is huge, the output is small.

• 28:51Speaker 02

  Yeah.

• 28:51Lex Fridman?

  Okay, so like, what else can you say about how to make it? Does caching play a role?

• 28:56Speaker 02

  Oh, caching plays a huge role. Because you're dealing with this many input tokens, if every single keystroke that you're typing in a given line, you had to rerun the model on all of those tokens passed in, you're just going to, one, significantly degrade latency, two, you're going to kill your GPUs with load. So you need to design the actual prompts you use for the model such that they're caching aware. And then, yeah, you need to reuse the KV cache across requests, just so that you're spending less work, less compute.

• 29:29Lex Fridman?

  Again, what are the things that TAB is supposed to be able to do kind of in the near term? Just to like sort of linger on that. Generate code? Like fill empty space? Also edit code across multiple lines?

• 29:47Speaker 02

  Yeah.

• 29:47Lex Fridman?

  And then jump to different locations inside the same file?

• 29:50Speaker 02

  Yeah.

• 29:50Lex Fridman?

  And then like launch?

• 29:51Speaker 04

  Hopefully jump to different files also. So if you make an edit in one file and maybe you have to go to another file to finish your thought, it should go to the second file also.

• 30:01Speaker 02

  And then the full generalization is like next action prediction. Like sometimes you need to run a command in the terminal and it should be able to suggest the command based on the code that you wrote too. Or sometimes you actually need to

• 30:19Speaker 03

  Like it suggests something, but you, you, it's hard for you to know if it's correct. Because you actually need some more information to learn, like you need to know the type to be able to verify that it's correct. And so maybe it should actually take you to a place that's like the definition of something and then take you back. So that you have all the requisite knowledge to be able to accept the next completion.

• 30:39Lex Fridman?

  So providing the human the knowledge.

• 30:41Speaker 03

  Yes.

• 30:43Lex Fridman?

  Right.

• 30:44Speaker 03

  Yeah.

• 30:44Lex Fridman?

  Can you integrate like, I just gone to know a guy named Prime Gen, who I believe has an SS, you can order coffee via SSH?

• 30:54Speaker 01

  Oh, yeah.

• 30:55Speaker 04

  Oh, we did that.

• 30:56Speaker 03

  We did that.

• 30:57Lex Fridman?

  So can that also the model do that, like feed you and like, and provide you with caffeine? Okay. So that's the general framework.

• 31:05Speaker 01

  Yeah. Yeah. And the, the magic moment would be if it is, programming is this weird discipline where sometimes the next five minutes, not always, but sometimes the next five minutes, what you're going to do is actually predictable from the stuff you've done recently. And so can you get to a world where that next five minutes either happens by you disengaging and it taking you through? Or maybe a little bit more of just you seeing next step, what it's going to do. And you're like, okay, that's good. That's good. That's good. That's good. And you can just sort of tap, tap, tap through these big changes.

• 31:35Lex Fridman?

  As we're talking about this, as you mentioned, like one of the really cool and noticeable things about Cursor is that there's this whole diff interface situation going on. So like the model suggests with, with the red and the green of like, here's how we're going to modify the code. And in the chat window, you can apply and it shows you the diff and you can accept the diff. So maybe can you speak to whatever direction of that?

• 31:58Speaker 04

  We'll probably have like four or five different kinds of diffs. We, we have optimized the diff for, for the autocomplete. So that has a different diff interface than. Then when you're reviewing larger blocks of code. And then we're trying to optimize another diff thing for when you're doing multiple different files. And and sort of at a high level, the difference is for when you're doing autocomplete, it should be really, really fast to read. Actually, it should be really fast to read in all situations. But in autocomplete, it's sort of you're really like your eyes focused in one area. You can't be in too many, you can't, like, humans can't look in too many different places.

• 32:41Lex Fridman?

  So you're talking about on the interface side?

• 32:43Speaker 04

  On the interface side. So it currently has this box on the side. So we have the current box. And if you try to delete code in some place and tries to add other code, it tries to show you a box on the side.

• 32:55Speaker 02

  You can maybe show it if we pull it up and cursor.com. This is what we're talking about.

• 32:58Speaker 04

  Go on. So that that box, it was like three or four different attempts at trying to make this this thing work. Where first the attempt was like these blue crossed out lines. So before it was a box on the side. It used to show you the code to delete by showing you like like Google Docs style, you would see like a line through it. Then you would see the the new code. And that was super distracting. And then we tried many different, you know, there was there was sort of deletions. There was trying to red highlight. Then the next iteration of it, which is sort of funny, would you would hold the on Mac, the option button.

• 33:40Speaker 04

  So it would it would sort of highlight a region of code to show you that there might be something coming. So maybe in this example, like the input and the value would get would all get blue. And the blue would to highlight that the AI had a suggestion for you. So instead of directly showing you the thing, it would show you that the AI, it would just hint that the AI had a suggestion. And if you really wanted to see it, you would hold the option button. And then you would see the new suggestion. And if you release the option button, you would then see your original code.

• 34:13Lex Fridman?

  So that's, by the way, that's pretty nice, but you have to know to hold the option button.

• 34:17Speaker 02

  Yeah.

• 34:18Lex Fridman?

  By the way, I'm not a Mac user, but I got it.

• 34:21Speaker 04

  It was, it was.

• 34:22Lex Fridman?

  It's a button, I guess. You people have.

• 34:25Speaker 04

  It's, you know, it's again, it's just, it's just non intuitive. I think that's the, that's the key thing.

• 34:30Speaker 02

  And there's a chance this this is also not the final version of it.

• 34:33Speaker 03

  I am personally very excited for.

• 34:37Speaker 03

  Making a lot of improvements in this area. Like, we often talk about it as the verification problem, where these diffs are great for small edits. For large edits, or like when it's multiple files or something, it's actually a little bit prohibitive to review these diffs. And so there are like a couple of different ideas here. Like, one idea that we have is, okay, you know, like, parts of the diffs are important. They have a lot of information. And then parts of the diff are just very low entropy. They're like, the same thing over and over again. And so maybe you can highlight the important pieces and then gray out the not so important pieces.

• 35:21Speaker 03

  Or maybe you can have a model that looks at the diff and sees, oh, there is a likely bug here. I will like mark this with a little red squiggly and say like, you should probably like review this part of the diff. And ideas in that vein, I think, are exciting.

• 35:37Lex Fridman?

  Yeah, that's a really fascinating space of UX design engineering. So you're basically trying to guide the human programmer through all the things they need to read and nothing more.

• 35:50Speaker 03

  Yeah.

• 35:50Lex Fridman?

  Like, optimally.

• 35:51Speaker 03

  Yeah, and you want an intelligent model to do it. Like, currently, diffs algorithms are, they're like, like, they're just like normal algorithms. There is no intelligence. There's like intelligence that went into designing the algorithm, but then there is no, like, you don't care if it's about this thing or this thing, as you want a model to do this.

• 36:13Speaker 04

  So I think the general question is like, Matt, these models are going to get much smarter. As the models get much smarter, the changes they will be able to propose are much bigger. So as the changes gets bigger and bigger and bigger, the humans have to do more and more and more verification work. It gets more and more and more hard, like, it's just, you need to help them out. It's sort of, I don't want to spend all my time reviewing code.

• 36:40Lex Fridman?

  Can you say a little more across multiple files, Div?

• 36:46Speaker 02

  Yeah, I mean, so GitHub tries to solve this, right? With code review. When you're doing code review, you're reviewing multiple diffs across multiple files. But like Arvid had said earlier, I think you can do much better than code review. You know, code review kind of sucks. Like, you spend a lot of time trying to grok this code that's often quite unfamiliar to you. And it often like, doesn't even actually catch that many bugs. And I think you can significantly improve that review experience using language models. For example, using the kinds of tricks that Arvid had described of maybe pointing you towards the regions that actually matter.

• 37:27Speaker 02

  I think also, if the code is produced by these language models and it's not produced by someone else, like, the code review experience is designed for both the reviewer and the person that produced the code. In the case where the person that produced the code is a language model, you don't have to care that much about their experience. And you can design the entire thing around the reviewers such that the reviewer's job is as fun, as easy, as productive as possible.

• 37:59Speaker 02

  And I think that that feels like the issue with just kind of naively trying to make these things look like code review. I think you can be a lot more creative and push the boundary on what's possible.

• 38:09Speaker 03

  Just one idea there is, I think, ordering matters. Generally, when you review a PR, you have this list of files and you're reviewing them from top to bottom. But actually, like, you actually want to understand this part first because that came like logically first, and then you want to understand the next part. And you don't want to have to figure out that yourself. You want a model to guide you through the thing.

• 38:32Lex Fridman?

  And is the step of creation going to be more and more in natural language is the goal versus with actual AI?

• 38:38Speaker 03

  I think sometimes I don't think it's going to be the case that all of programming will be natural language. And the reason for that is, you know, if I'm programming with Swala and Swala is at the computer and the keyboard. And sometimes if I'm like driving, I want to say to Swala, hey, like implement this function and that that works. And then sometimes it's just so annoying to explain to Swala what I want him to do. And so I actually take over the keyboard and I show him, I write like part of the example and then it makes sense. And that's the easiest way to communicate. And so I think that's also the case for AI. Like sometimes the easiest way to communicate with AI will be to show an example and then it goes and does the thing everywhere else.

• 39:21Speaker 03

  Or sometimes if you're making a website, for example, the easiest way to show to the AI what you want is not to tell it what to do, but you know, drag things around or draw things. And yeah, and like maybe eventually we will get to like brain machine interfaces or whatever and it can like understand what you're thinking. And so I think natural language will have a place. I think it will not definitely not be the way most people program most of the time.

• 39:46Lex Fridman?

  I'm really feeling the AGI with this editor. It feels like there's a lot of machine learning going on underneath. Tell me about some of the ML stuff that makes it all work.

• 39:56Speaker 02

  Recursor really works via this ensemble of custom models that we trained alongside, you know, the frontier models that are fantastic at the reasoning intense things. And so Cursor Tab, for example, is a great example of where you can specialize this model to be even better than even frontier models if you look at evals on the task we set it at. The other domain, which it's kind of surprising that it requires custom models, but it's kind of necessary and works quite well is in Apply.

• 40:27Speaker 02

  I think these models are like the frontier models are quite good at sketching out plans for code and generating like rough sketches of like the change. But actually, creating diffs is quite hard for frontier models, for your training models. Like, you try to do this with Sonnet, with O1, any frontier model, and it really messes up stupid things like counting line numbers, especially in super, super large files. And so what we've done to alleviate this is we let the model kind of sketch out this rough code block that indicates what the change will be, and we train a model to then apply that change to the file.

• 41:08Lex Fridman?

  And we should say that apply is the model looks at your code, it gives you a really damn good suggestion of what new things to do, and the seemingly for humans trivial step of combining the two, you're saying is not so trivial.

• 41:25Speaker 04

  Contrary to popular perception, it is not a deterministic algorithm.

• 41:29Speaker 02

  Yeah, I think like you see shallow copies of apply elsewhere, and it just breaks like most of the time because you think you can kind of try to do some deterministic matching, and then it fails, you know, at least 40% of the time, and that just results in a terrible product experience. I think in general, this regime of you are going to get smarter and smarter models. And like, so one other thing that apply lets you do is it lets you use fewer tokens with the most intelligent models. This is both expensive in terms of latency for generating all these tokens and cost.

• 42:10Speaker 02

  So you can give this very, very rough sketch and then have your smaller models go and implement it because it's a much easier task to implement this very, very sketched out code. And I think that this regime will continue where you can use smarter and smarter models to do the planning, and then maybe the implementation details can be handled by the less intelligent ones. Perhaps you'll have, you know, maybe O1, maybe it'll be even more capable models, given an even higher level plan that is kind of recursively.

• 42:40Speaker 02

  Applied by Sonnet and then the apply model.

• 42:42Speaker 04

  Maybe we should, we should talk about how to, how to make it fast.

• 42:45Speaker 02

  Yeah.

• 42:45Speaker 04

  If you like, fast is always an interesting detail.

• 42:47Speaker 02

  Fast is good. Yeah. How do you make it fast? Yeah. So one big component of making it fast is speculative edits. So speculative edits are a variant of speculative decoding. And maybe it'd be helpful to briefly describe speculative decoding.

• 43:04Speaker 02

  With speculative decoding, what you do is you, you can kind of take advantage of the fact that, you know, most of the time, and I'll add the caveat that it would be when you're memory bound in, in language model generation.

• 43:18Speaker 02

  If you process multiple tokens at once, it is faster than generating one token at a time. So this is like the same reason why if you look at tokens per second with prompt tokens versus generated tokens, it's much, much faster for prompt tokens.

• 43:35Speaker 02

  So what we do is instead of using what speculative decoding normally does, which is using a really small model to predict these draft tokens that your larger model will then go in and, and verify.

• 43:48Speaker 02

  With code edits, we have a very strong prior of what the existing code will look like. And that prior is literally the same exact code. So what you can do is you could just feed chunks of the original code back into the, into the model.

• 44:01Speaker 02

  And then the model will just pretty much agree most of the time that, okay, I'm just going to spit this code back out. And so you can process all of those lines in parallel. And you just do this with sufficiently many chunks. And then eventually you'll reach a point of disagreement where the model will now predict text that is different from the ground truth original code. It'll generate those tokens and then we kind of will decide after enough tokens match the original code to restart speculating in chunks of code. What this actually ends up looking like is just a much faster version of normal editing code. So it's just like, it looks like a much faster version of the model rewriting all the code. So just, we, we can use the same exact interface that we use for, for diffs,

• 44:45Speaker 02

  but it will just stream down a lot faster.

• 44:48Speaker 04

  And then, and then the advantage is that while, while it's streaming, you can just also be reviewing, start reviewing the code.

• 44:53Speaker 02

  Exactly.

• 44:54Speaker 04

  Before, before it's done. So there's no, no big loading screen. So maybe that, that is part of the, part of the advantage.

• 45:02Lex Fridman?

  So the human can start reading before the thing is done.

• 45:05Speaker 04

  I think the interesting riff here is something like, like speculation is a fairly common idea nowadays. It's like, not only in language models, I mean, there's obviously speculation in CPUs and there's like speculation for databases and speculation all over the place.

• 45:20Lex Fridman?

  Let me ask the sort of the ridiculous question of which LLM is better at coding? GPT, Claude, who wins in the context of programming? And I'm sure the answer is much more nuanced because it sounds like every single part of this involves a different model.

• 45:38Speaker 02

  Yeah, I think there, there's no model that Pareto dominates others, meaning it is better in all categories that we think matter. The categories being speed, ability to edit code, ability to process lots of code, long context, you know, a couple of other things and kind of coding capabilities. The one that I'd say right now is just kind of net best is Sonnet. I think this is a consensus opinion. R1 is really interesting and it's really good at reasoning. So if you give it really hard programming interview style problems or lead code problems, it can do quite, quite well on them. But it doesn't feel like it kind of understands

• 46:23Speaker 02

  your rough intent as well as Sonnet does. Like, if you look at a lot of the other frontier models, one quorum I have is it feels like they're not necessarily over, I'm not saying they, they train on benchmarks, but they perform really well on benchmarks relative to kind of everything that's kind of in the middle. So if you tried on all these benchmarks and things that are in the distribution of the benchmarks they're evaluated on, you know, they'll do really well. But when you push them a little bit outside of that, Sonnet's, I think, the one that, that kind of does best at, at kind of maintaining that same capability. Like you kind of have the same capability in the benchmark as when you try to instruct it to do anything with coding.

• 47:03Lex Fridman?

  What, another ridiculous question, is the difference between the normal programming experience versus what benchmarks represent? Like, where do benchmarks fall short, do you think, when we're evaluating these models?

• 47:15Speaker 04

  By the way, that's like a really, really hard, it's like, like critically important detail, like how, how different like benchmarks are versus, versus like real coding. Where real coding

• 47:27Speaker 04

  It's not interview style coding. It's you're you're doing these. You know, humans are saying like half broken English sometimes. And sometimes you're saying like, oh, do what I did before. Sometimes you're saying, uh, you know, go add this thing and then do this other thing for me and then make this UI element. And then, you know, it's it's just like a lot of things are sort of context dependent. You really want to like, understand the human and then do do what the human wants as opposed to sort of this, maybe the the way to put it is sort of abstractly is the interview problems are very well specified.

• 48:08Speaker 04

  They lean a lot on specification while the human stuff is less specified.

• 48:16Speaker 01

  Yeah, I think that this this benchmark question is both complicated by what Svoli just mentioned. And then also to what Aman was getting into is that even if you like, you know, there's this problem of like the skew between what can you actually model in a benchmark versus real programming. And that can be sometimes hard to encapsulate because it's like real programming is like very messy and sometimes things aren't super well specified, what's correct or what isn't. But then it's also doubly hard because of this public benchmark problem. And that's both because public benchmarks are sometimes kind of hill climbed on. Then it's like really, really hard to also get the data from the public benchmarks out of the models. And so, for instance, like one of the most popular like agent benchmarks, Sweetbench,

• 49:01Speaker 01

  is really, really contaminated in the training data of these foundation models. And so if you ask these foundation models to do a Sweetbench problem, you actually don't give them the context of a codebase. They can like hallucinate the right file path. They can hallucinate the right function names. And so the it's it's also just the public aspect of these things is tricky.

• 49:19Speaker 02

  Yeah, like in that case, it could be trained on the literal issues or pull requests themselves. And and maybe the labs will start to do a better job, or they've already done a good job at decontaminating those things. But they're not going to omit the actual training data of the repository itself. Like, these are all like some of the most popular Python repositories, like SimPy is one example. I don't think they're going to handicap their models on simpai and all these popular Python repositories in order to get true evaluation scores in these benchmarks.

• 49:50Speaker 01

  Yeah, I think that given the dearths in benchmarks, there have been like a few interesting crutches that places that build systems with these models or build these models actually use to get a sense of are they going in the right direction or not? And in a lot of places, people will actually just have humans play with the things and give qualitative feedback on these. Like one or two of the foundation model companies, they have people who that's a big part of their role. And internally, we also qualitatively assess these models and actually lean on that a lot in addition to like privacy valves that we have.

• 50:22Speaker 04

  It's like the vibe.

• 50:24Lex Fridman?

  The vibe, yeah, the vibe. Vibe benchmark, human benchmark. The human, you pull in the humans to do a vibe check.

• 50:31Speaker 04

  Yeah.

• 50:32Lex Fridman?

  Okay. I mean, that's kind of what I do, like just like reading online forums and Reddit and X. Just like, well, I don't know how to properly load in people's opinions because they'll say things like, I feel like Claude or GPT has gotten dumber or something. They'll say, I feel like, and then I sometimes feel like that too. But I wonder if it's the model's problem or mine.

• 51:00Speaker 01

  Yeah, with Claude, there's an interesting take I heard where I think AWS has different chips. And I suspect they have slightly different numerics than Nvidia GPUs. And someone speculated that Claude's degraded performance had to do with maybe using the quantized version that existed on AWS Bedrock versus whatever was running on Anthropic's GPUs.

• 51:27Lex Fridman?

  I interview a bunch of people that have conspiracy theories, so I'm glad you spoke to this conspiracy.

• 51:31Speaker 04

  Well, it's not like conspiracy theory as much. They're like, you know, humans are humans and there's these details. And you're doing like this queasy amount of flops and chips are messy. And man, you can just have bugs, like bugs are, it's hard to overstate how hard bugs are to avoid.

• 51:55Lex Fridman?

  What's the role of a good prompt in all this? You mentioned that benchmarks have really structured, well-formulated prompts. What should a human be doing to maximize success? And what's the importance of what the humans? You wrote a blog post and you called it "prompt design."

• 52:17Speaker 03

  Yeah, I think it depends on which model you're using. And all of them are slightly different and they respond differently to different prompts. But I think the original GPT-4 and the original sort of pre-deformable models last year, they were quite sensitive to the prompts. And they also had a very small context window. And so we have all of these pieces of information around the codebase that would maybe be relevant in the prompt. Like you have the docs, you have the files that you add, you have the conversation history. And then there's a problem like, how do you decide what you actually put in the prompt? And when you have a limited space. And even for today's models, even when you have long context,

• 53:00Speaker 03

  filling out the entire context window means that it's slower. It means that sometimes the model actually gets confused and some models get more confused than others. And we have this one system internally that we call Preempt, which helps us with that a little bit. And I think it was built for the era before where we had 8,000 token context windows. And it's a little bit similar to when you're making a website. You sort of, you wanted to work on mobile, you wanted to work on a desktop screen. And you have this dynamic information, which you don't have.

• 53:43Speaker 03

  For example, if you're making, like designing a print magazine, you have like, you know exactly where you can put stuff. But when you have a website or when you have a prompt, you have these inputs. And then you need to format them to always work. Even if the input is really big, then you might have to cut something down. And so the idea was, okay, like, let's take some inspiration. What's the best way to design websites? Well, the thing that we really like is React and the declarative approach where you...

• 54:10Speaker 03

  You use JSX in JavaScript and then you declare this is what I want. And I think this has higher priority or like this has higher Z index than something else. And then you have this rendering engine in web design. It's like Chrome and in our case it's a preempt renderer, which then fits everything onto the page. And as you declare, they will decide what you want and then it figures out what you want.

• 54:38Speaker 03

  And so we have found that to be quite helpful. And I think the role of it has has sort of shifted over time. Where initially was to fit to these small context windows. Now it's really useful because, you know, it helps us with splitting up the data that goes into the prompt and the actual rendering of it. And so it's easier to debug because you can change the rendering of the prompt and then try it on old prompts because you have the raw data that went into the prompt. And then you can see, did my change actually improve it for for like this entire eval set?

• 55:11Lex Fridman?

  So do you literally prompt with JSX?

• 55:14Speaker 03

  Yes, yes. So it kind of looks like React. There are components like we have one component that's a file component. And it takes in like the cursor, like usually there is like one line where the cursor is in your file. And that's like probably the most important line because that's the one you're looking at. And so then you can give priorities. So like that line has the highest priority and then you subtract one for every line that is farther away. And then eventually when it's rendered, it figures out how many lines can actually fit and it centers around that thing.

• 55:43Lex Fridman?

  That's amazing.

• 55:44Speaker 02

  Yeah. And you can do like other fancy things where if you have lots of code blocks from the entire code base, you could use retrieval and things like embedding and re-ranking scores to add priorities for each of these components.

• 55:57Lex Fridman?

  So should humans, when they ask questions, also use try to use something like that? Like, would it be beneficial to write JSX in the problem? Or the whole idea is this should be loose and messy?

• 56:09Speaker 03

  I think our goal is kind of that. You should just do whatever is the most natural thing for you. And then we, our job is to figure out, how do we actually like retrieve the relative thing so that your thing actually makes sense?

• 56:23Lex Fridman?

  Well, this is sort of the discussion I had with Arvin of perplexity. It's like his whole idea is like, you should let the person be as lazy.

• 56:31Speaker 03

  Yes.

• 56:32Lex Fridman?

  Yeah. But like, yeah, that's a beautiful thing. But I feel like you're allowed to ask more of programmers, right? So like, if you say, just do what you want, I mean, humans are lazy. There's a kind of tension between just being lazy versus like provide more as,

• 56:51Lex Fridman?

  be prompted, almost like the system pressuring you or inspiring you to be articulate. Not in terms of the grammar of the sentences, but in terms of the depth of thoughts that you convey inside the problems.

• 57:05Speaker 02

  I think even as a system gets closer to some level of perfection, often when you ask the model for something, you just are not, not enough intent is conveyed to know what to do. And there are like a few ways to resolve that intent. One is the simple thing of having the model just ask you, I'm not sure how to do these parts based on your query. Could you clarify that?

• 57:30Speaker 02

  I think the other could be maybe, if you, there are five or six possible generations, given the uncertainty present in your query so far, why don't we just actually show you all of those and let you pick them?

• 57:45Lex Fridman?

  How hard is it to, for the model to choose to speak, talk back? Sort of versus, that's, it's hard to sort of like how to deal with the uncertainty. Do I, do I choose to ask for more information to reduce the ambiguity?

• 58:02Speaker 04

  So, I mean, one of the things we, we do is, it's like a recent addition is, try to suggest files that you can add. So, and while you're typing, one can guess what the uncertainty is. And maybe suggest that like, you know, maybe, maybe you're writing your API.

• 58:23Speaker 04

  And we can guess using the commits that you've made previously in the same file that the client and the server is super useful. And there's like a hard technical problem of how do you resolve it across all commits? Which files are the most important, given your current prompt? And we're still sort of initial versions ruled out, and I'm sure we can make it much more accurate.

• 58:52Speaker 04

  It's very experimental, but then the idea is we show you like, do you just want to add this file? This file, this file also to tell, you know, the model to edit those files for you. Because if you're maybe you're making the API, like you should also edit the client and the server that is using the API and the other one resolving the API. And so that'll be kind of cool as both there's the phase where you're writing the prompt and there's before you even click enter, maybe we could help resolve some of the uncertainty.

• 59:20Lex Fridman?

  To what degree do you use agentic approaches? How useful are agents?

• 59:25Speaker 03

  We think agents are really, really cool. Like, I think agents is like, it's like resembles sort of like a human. It's sort of like the things like you can kind of feel that it like you're getting closer to AGI because you see a demo where it acts as as a human would. And and it's really, really cool. I think agents are not yet super useful for many things. They, I think we're getting close to where they will actually be useful. And so I think there are certain types of tasks where having an agent would be really nice. Like, I would love to have an agent.

• 1:00:07Speaker 03

  For example, if like we have a bug where you sometimes can't command C and command V inside our chat input box. And that's a task that's super well specified. I just want to say like in two sentences, this does not work. Please fix it. And then I would love to have an agent that just goes off, does it? And then a day later I come back and I review the thing.

• 1:00:29Lex Fridman?

  You mean it goes finds the right file?

• 1:00:31Speaker 03

  Yeah, it finds the right files. It like tries to reproduce the bug. It like fixes the bug and then it verifies that it's correct. And this is could be a process that takes a long time. And so I think I would love to have that. And then I think a lot of programming, like there is often this belief that agents will take over all of programming.

• 1:00:52Speaker 03

  I don't think we think that that's the case because a lot of programming, a lot of the value is in iterating, or you don't actually want to specify something upfront because you don't really know what you want until you've seen an initial version and then you want to iterate on that and then you provide more information. And so for a lot of programming, I think you actually want a system that's instant, that gives you an initial version instantly back and then you can iterate super, super quickly.

• 1:01:18Lex Fridman?

  What about something like that recently came out, Replant Agent, that does also like setting up the development environment and installing software packages, configuring everything, configuring the databases and actually deploying the app?

• 1:01:31Speaker 03

  Yeah.

• 1:01:32Lex Fridman?

  Is that also in the set of things you dream about?

• 1:01:36Speaker 03

  I think so. I think that would be really cool for certain types of programming. It would be really cool.

• 1:01:41Lex Fridman?

  Is that within scope of Cursor?

• 1:01:44Speaker 03

  Yeah, we aren't actively working on it right now.

• 1:01:48Speaker 03

  But it's definitely like we want to make the programmers live easier and more fun. And some things are just really tedious and you need to go through a bunch of steps and you want to delegate that to an agent. And then some things you can actually have an agent in the background while you're working. Like, let's say you have a PR that's both backend and frontend and you're working on the frontend and then you can have a background agent that doesn't work and figure out kind of what you're doing. And then when you get to the backend part of your PR, then you have some like initial piece of code that you can iterate on.

• 1:02:22Speaker 03

  And so that would also be really cool.

• 1:02:24Lex Fridman?

  One of the things we already talked about is speed. But I wonder if we can just linger on that some more and the various places that the technical details involved in making this thing really fast. So every single aspect of Cursor, most aspects of Cursor feel really fast. Like I mentioned, the apply is probably the slowest thing and for me, for my, I'm sorry, the pain.

• 1:02:48Speaker 03

  It's a pain. It's a pain that we're feeling and we're working on fixing it.

• 1:02:53Lex Fridman?

  Yeah, I mean, it says something that something that feels, I don't know what it is, like one second or two seconds, that feels slow. That means that's actually shows that everything else is just really, really fast. So is there some technical details about how to make some of these models, how to make the chat fast, how to make?

• 1:03:12Lex Fridman?

  The diff's fast. Is there something that just jumps to mind?

• 1:03:15Speaker 02

  Yeah, I mean, so we can go over a lot of the strategies that we use. One interesting thing is cache warming. And so what you can do is if, as the user is typing, you can have, you're probably going to use some piece of context and you can know that before the user's done typing. So, you know, as we discussed before, reusing the KV cache results in lower latency, lower costs, cross requests. So as the user starts typing, you can immediately warm the cache with, like, let's say, the current file contents. And then when they press Enter, there's very few tokens it actually has to pre-fill and compute before starting the generation. This will significantly lower TTFD.

• 1:03:56Lex Fridman?

  Can you explain how KV cache works?

• 1:03:59Speaker 02

  Yeah, so the way transformers work.

• 1:04:04Lex Fridman?

  I like it.

• 1:04:04Speaker 02

  I mean, like, one of the mechanisms that allow transformers to not just independently, like, the mechanism that allows transformers to not just independently look at each token, but see previous tokens, are the keys and values detention. And generally, the way attention works is you have at your current token some query, and then you've all the keys and values of all your previous tokens, which are some kind of representation that the model stores internally of all the previous tokens in the prompt. And

• 1:04:36Speaker 02

  like, by default, when you're doing a chat, the model has to, for every single token, do this forward pass through the entire model. That's a lot of matrix multiplies that happen, and that is really, really slow. Instead, if you have already done that and you stored the keys and values and you keep that in the GPU, then when I'm, let's say I have to sort it for the last N tokens, if I now want to compute the output token for the N plus one token, I don't need to pass those first N tokens through the entire model because I already have all those keys and values. And so you just need to do the forward pass through that last token. And then when you're doing attention,

• 1:05:18Speaker 02

  you're reusing those keys and values that have been computed, which is the only kind of sequential part, or sequentially dependent part of the transformer.

• 1:05:26Lex Fridman?

  Is there, like, higher level caching of, like, caching of the prompts or that kind of stuff that could help?

• 1:05:32Speaker 02

  Yeah, that, that, there's other types of caching you can kind of do.

• 1:05:38Speaker 02

  One interesting thing that you can do for cursor tab is you can basically predict ahead as if the user would have accepted the suggestion and then trigger another request. And so then you've cache, you've done a speculative, it's a mix of speculation and caching, right? Because you're speculating what would happen if they accepted it. And then you have this value that is cached, this suggestion. And then when they press tab, the next one would be waiting for them immediately. It's a, it's a kind of clever heuristic slash trick that uses a higher level caching and can give the, it feels fast despite there not actually being any changes in the, in the model.

• 1:06:20Speaker 04

  And if you can make the KV cache smaller, one of the advantages you get is like, maybe, maybe you can speculate even more. Maybe you can guess, here's the 10 things that could be useful. I like, like predict the next 10 and then like it's possible the user hits the one of the 10. It's like much higher chance than the user hits like the exact one that you show them. Maybe they type another character and we sort of hit, hit something else in the cache. So there's, there's all these tricks where the, the general phenomena here is, I think it's also super useful for RL is, you know, maybe a single sample from the model isn't very good.

• 1:06:59Speaker 04

  But if you predict like 10 different things, turns out that one of the 10, that's right. It's the probability is much higher. There's these passive K curves and you know, part of RL, like what, what RL does is, you know, you can, you can exploit this passive K phenomena to, to make many different predictions. And, and one, one way to think about this, the model sort of knows internally has like, has some uncertainty over like which of the key things is correct. Or like which of the key things does the human want. So when we RL our, you know, cursor tab model, one of the things we're doing is we're predicting.

• 1:07:40Speaker 04

  Which of the hundred different suggestions the model produces is more amenable for humans? Like which of them do humans more like than other things? Maybe like there's something where the model can predict very far ahead versus like a little bit and maybe somewhere in the middle and and you just and then you can give a reward to the things that humans would like more and and sort of punish the things that it won't like and sort of then train the model to output the suggestions that humans would like more. You have these like RL loops that are very useful that exploit these passive K-curves.

• 1:08:12Speaker 04

  Aman maybe can go into even more detail.

• 1:08:14Speaker 02

  Yeah, it's a little it is a little different than speed.

• 1:08:18Speaker 02

  But I mean, like technically you tie it back in because you can get away with the smaller model if you RL your smaller model and it gets the same performances as the bigger one.

• 1:08:29Speaker 02

  That's like and Swali was mentioning stuff about KB about reducing the size of your KB cache. There are other techniques there as well that are really helpful for speed. So kind of back in the day, like all the way two years ago, people mainly use multi-head attention. And I think there's been a migration towards more efficient attention schemes like group query or multiquery attention. And this is really helpful for then with larger batch sizes, being able to generate the tokens much faster. The interesting thing here is this now has no effect on that time to first token pre-fill

• 1:09:10Speaker 02

  speed. The thing this matters for is now generating tokens. And why is that? Because when you're generating tokens, instead of being bottlenecked by doing this super paralizable matrix multiplies across all your tokens, you're bottlenecked by how quickly it's for long context with large batch sizes by how quickly you can read those cache keys and values. And so then how that's memory bandwidth and how can we make this faster? We can try to compress the size of these keys and values. So multiquery attention is the most aggressive of these, where normally with multi-head attention, you have some number of quote unquote attention heads.

• 1:09:52Speaker 02

  And some number of query heads. Multi- query just preserves the query heads, gets rid of all the key value heads. So there's only one key value head and there's all the remaining query heads. With group query, you instead preserve all the query heads and then your keys and values are kind of, there are fewer heads for the keys and values, but you're not reducing it to just one. But anyways, the whole point here is you're just reducing the size of your KV cache.

• 1:10:26Speaker 04

  And then there is MLA.

• 1:10:28Speaker 02

  Yeah, multi-latent. That's a little more complicated. And the way that this works is it turns the entirety of your keys and values across all your heads into this one latent vector that is then expanded inference time.

• 1:10:46Speaker 04

  But MLA is from this company called DeepSeek. It's quite an interesting algorithm. Maybe the key idea is in both MQA and in other places, what you're doing is you're reducing the like the number of KV heads. The advantage you get from that is is there's less of them, but maybe the theory is that you actually want a lot of different, like you want each of the keys and values to actually be different. So one way to reduce the size is you keep one big shared vector for all the keys and values. And then you have smaller vectors for every single token.

• 1:11:30Speaker 04

  So that when you can store only the smaller thing, there's some sort of like low rank reduction. And the low rank reduction, and at the end of the time, when you eventually want to compute the final thing, remember that your memory bound, which means that you still have some compute left that you can use for these things. And so if you can expand the latent vector back out and somehow this is far more efficient because just like you're reducing, for example, maybe you're reducing like 32 or something, like the size of the vector that you're keeping.

• 1:12:04Speaker 02

  Yeah, there's perhaps some richness in having a separate set of keys and values and query that kind of pairwise matchup versus compressing that all into one.

• 1:12:15Speaker 02

  And that interaction at least.

• 1:12:17Lex Fridman?

  Okay, and all of that is dealing with being memory bound.

• 1:12:21Speaker 02

  Yeah.

• 1:12:22Lex Fridman?

  And what, I mean, ultimately, how does that map to the user experience? Trying to get the.

• 1:12:28Speaker 02

  Yeah, the two things that it maps to is you can now make your cache a lot larger. Because you've less space allocated for the KV cache, you can maybe cache a lot more aggressively and a lot more things. So you get more cache hits, which are helpful for reducing the time to first token for the reasons that were kind of described earlier. And then the second being, when you start doing inference with more and more requests and larger and larger batch sizes, you don't see much of a slowdown in as it's generating the tokens, the speed of that.

• 1:12:58Speaker 03

  Well, it also allows you to make your prompt bigger for certain.

• 1:13:00Speaker 02

  Yeah, yeah. So like the basic, the size of your KV cache is both the size of all your prompts multiplied by the number of prompts you can process in parallel. So you could increase either those dimensions, right? The batch size or the size of your prompts without degrading the latency of generating tokens.

• 1:13:18Lex Fridman?

  Arav, you wrote a blog post, Shadow Workspace.

• 1:13:20Speaker 03

  Yes.

• 1:13:20Lex Fridman?

  Iterating on code in the background.

• 1:13:22Speaker 03

  Yeah.

• 1:13:23Lex Fridman?

  So what's going on?

• 1:13:24Speaker 03

  So to be clear, we want there to be a lot of stuff, stuff happening in the background. And we're experimenting with a lot of things. Right now, we don't have much of that happening, other than like the, the cache warming or like, you know, figuring out the right context to that goes into your command prompts, for example. But the idea is if you can actually spend computation in the background, then you can help,

• 1:13:49Speaker 03

  help the user maybe like at a slightly longer time horizon than just predicting the next few lines that you're going to make. But actually, like in the next 10 minutes, what are you going to make? And by doing it in the background, you can spend more computation doing that. And so the idea of the shadow workspace that, that we implemented and we use it internally for like experiments is that to actually get advantage of doing stuff in the background, you want some kind of feedback signal to give back to the model. Because otherwise, like you can get higher performance by just letting the model think for longer. And so like O1 is a good example of that. But another way you can improve performance is by letting the model. iterate and get feedback.

• 1:14:34Speaker 03

  And so one very important piece of feedback when you're a programmer is the language server, which is this thing, it exists for most different languages and there's like a separate language server per language. And it can tell you, you know, you're using the wrong type here and then gives you an error. Or it can allow you to go to definition and sort of understands the structure of your code. So language servers are extensions developed by like, there is a TypeScript language server developed by the TypeScript people, a Rust language server developed by the Rust people. And then they all interface over the language server protocol to VS Code. So that VS Code doesn't need to have all of the different languages built into VS Code, but rather you can use the existing compiler infrastructure.

• 1:15:17Lex Fridman?

  For linting purposes?

• 1:15:18Speaker 03

  It's for linting, it's for going to definition. And for like seeing the right types that you're using.

• 1:15:25Lex Fridman?

  So it's doing like type checking also?

• 1:15:27Speaker 03

  Yes, type checking and going to references. And that's like, when you're working in a big project, you kind of need that. If you don't have that, it's like really hard to code in a big project.

• 1:15:38Lex Fridman?

  Can you say again how that's being used inside Cursor? The language server protocol communication thing?

• 1:15:46Speaker 03

  So it's being used in Cursor to show to the programmer, just like in VS Code. But then the idea is you want to show that same information to the models, the AI models. And you want to do that in a way that doesn't affect the user, because you want to do it in background. And so the idea behind the chat workspace was, okay, like, one way we can do this is we spawn a separate window of Cursor that's hidden. And so you can set this flag and it'll turn it's hidden. There is a window, but you don't actually see it. And inside of this window, the AI agents can modify code however they want, as long as they don't save it, because it's still the same folder. And then can get feedback from the linters and go to definition and iterate on their code.

• 1:16:30Lex Fridman?

  So like literally run everything in the background like as if, right?

• 1:16:34Speaker 03

  Yeah.

• 1:16:35Lex Fridman?

  May maybe even run the code?

• 1:16:37Speaker 03

  So that's the eventual version.

• 1:16:39Lex Fridman?

  Okay.

• 1:16:39Speaker 03

  And that's what you want. And a lot of the blog post is actually about how do you make that happen? Because it's a little bit tricky. You want it to be on the user's machine so that it exactly mirrors the user's environment. And then on Linux, you can do this cool thing where you can actually mirror the file system and have the AI make changes to the files. And it thinks that it's operating on the file level, but actually that's stored in in memory. And you you can create this kernel extension to to make it work. Whereas on Mac and Windows, it's a little bit more difficult. And but it's it's a fun technical problem. So that's why.

• 1:17:23Speaker 02

  One one maybe hacky but interesting idea that I like is holding a lock on saving. And so basically you can then have the language model kind of hold the lock on on saving to disk. And then instead of you operating in the ground truth version of the files that are saved to disk, you you actually are operating what was the shadow workspace before and these unsafe things that only exist in memory that you still get Lintor errors for and you can code in. And then when you try to maybe run code, it's just like there's a small warning that there's a lock. And then you kind of will take back the lock from the language server if you're trying to do things concurrently or from the the shadow workspace if you're trying to do things concurrently.

• 1:17:58Lex Fridman?

  That's such an exciting feature, by the way. It's a bit of a tangent, but like to allow a model to change files. It's scary for people, but like it's really cool to be able to just like let the agent do a set of tasks and you come back the next day and kind of observe like it's a colleague or something like that.

• 1:18:18Speaker 02

  Yeah. And I think there may be different versions of like run ability where for the simple things, where you're doing things in the span of a few minutes on behalf of the user as they're programming, it makes sense to make something work locally on their machine. I think for the more aggressive things where you're making larger changes that take longer periods of time, you'll probably want to do this in some sandbox remote environment. And that's another incredibly tricky problem of how do you exactly reproduce or mostly reproduce to the point of it being effectively equivalent for running code, the user's environment with this remote remote sandbox?

• 1:18:53Speaker 03

  I'm curious what kind of agency you want?

• 1:18:55Speaker 04

  For coding. Did you want them to find bugs? Do you want them to like implement new features? Like, what agents do you want?

• 1:19:02Lex Fridman?

  So by the way, when I think about agents, I don't think just about coding. I think so for the practice, this particular podcast, there's video editing. And a lot of, if you look in Adobe, a lot of, there's code behind. It's very poorly documented code, but you can interact with Premiere, for example, using code. And basically all the uploading, everything I do on YouTube, everything, as you could probably imagine, I do all of that through code. And so, and including translation and overdubbing all of this. So I envisioned all of those kinds of tasks. So automating many of the tasks that don't have to do directly with the editing. So that, okay, that's what I was thinking about.

• 1:19:43Lex Fridman?

  But in terms of coding, I would be fundamentally thinking about bug finding. Like many levels of kind of bug finding and also bug finding, like logical bugs, not logical, like spiritual bugs or something.

• 1:20:00Lex Fridman?

  Ones like sort of big directions of implementation, that kind of stuff.

• 1:20:04Speaker 04

  Let's go find on bug finding.

• 1:20:06Speaker 02

  Yeah, I mean, it's really interesting that these models are so bad at bug finding. When just naively prompted to find a bug. They're incredibly poorly calibrated.

• 1:20:17Speaker 03

  Even the smartest models.

• 1:20:19Speaker 02

  Exactly. Even O, even O1.

• 1:20:21Lex Fridman?

  How do you explain that? Is there a good intuition?

• 1:20:25Speaker 02

  I think these models are really strong reflection of the pre-training distribution. And, you know, I do think they generalize as the loss gets lower and lower. But I don't think the, the loss in the scale is quite, or the loss is low enough such that they're like really fully generalizing in code. Like the things that we use these things for, the frontier models. That they're quite good at are really code generation and question answering. And these things exist in massive quantities in pre-training with all of the code on GitHub on the scale of many, many trillions of tokens and questions and answers on things like Stack Overflow and maybe GitHub issues.

• 1:21:05Speaker 02

  And so when you try to push into these things that really don't exist very much online, like, for example, the cursor tab objective of predicting the next edit, given the edits done so far, the brittleness kind of shows. And then bug detection is another great example where there aren't really that many examples of like actually detecting real bugs and then proposing fixes.

• 1:21:29Speaker 02

  And the models just kind of like really struggle at it. But I think it's a question of transferring the model, like in the same way that you get this fantastic transfer from pre-trained models, just on code in general, to the cursor tab objective. You'll see a very, very similar thing with generalized models that are really good at code to bug detection. It just takes like a little bit of kind of nudging in that direction.

• 1:21:51Speaker 04

  Like, to be clear, I think they sort of understand code really well. Like while they're being pre-trained, like the representation that's being built up, like almost certainly, like somewhere in the stream, there's, the model knows that maybe there's something sketchy going on, right? It sort of has some sketchiness, but actually eliciting the sketchiness to, like actually, like part of it is that humans are really calibrated on which bugs are really important. It's not just actually, it's not just actually saying like there's something sketchy. It's like, is this just a sketchy trivial? Is this sketchy like you're going to take the server down? It's like, like part of it is maybe the cultural knowledge of, like, why is a staff engineer,

• 1:22:34Speaker 04

  staff engineer, a staff engineer is good because they know that three years ago, like someone wrote a really, you know, sketchy piece of code that took, took the server down and as opposed to like, as opposed to maybe there's like, you know, you just, this thing is like an experiment. So like a few bugs are fine, like you're just trying to experiment and get the feel of the thing. And so if the model gets really annoying when you're writing an experiment, that's really bad. But if you're writing something for super production, you're like writing a database, right? You're writing code in Postgres or Linux or whatever, like your Linus Torvalds, you're, it's sort of unacceptable to have even in that case. And just having the calibration of like,

• 1:23:15Speaker 03

  How paranoid is the user like?

• 1:23:17Speaker 02

  But even then, like if you're putting in a maximum paranoia, it's still just like, doesn't quite get it.

• 1:23:23Speaker 03

  Yeah, yeah, yeah.

• 1:23:25Lex Fridman?

  I mean, but this is hard for humans too, to understand what, which line of code is important, which is not. Like you, I think one of your principles on a website says, if, if, if a code can do a lot of damage, one should add a comment that say this, this, this line of code is, is dangerous.

• 1:23:43Speaker 03

  And all caps, repeat it 10 times.

• 1:23:46Lex Fridman?

  No, you say like, for every single line of code inside the function, you have to, and that's quite profound. That says something about human beings because the, the engineers move on, even the same person might just forget how it can sink the Titanic, a single function, like you don't, you might not intuit that quite clearly by looking at the single piece of code.

• 1:24:09Speaker 03

  Yeah, and I think that, that one is also, partially also for today's AI models, where if you actually write dangerous, dangerous, dangerous in every single line, like the models will pay more attention to that and will be more likely to find bugs in that region.

• 1:24:26Lex Fridman?

  That's actually just straight up a really good practice of labeling code of how much damage this can do.

• 1:24:34Speaker 03

  Yeah, I mean, it's controversial. I get, some people think it's ugly.

• 1:24:38Speaker 04

  Well, I actually think it's like, in fact, I actually think this is one of the things I learned from Ari, it is, you know, like I sort of aesthetically, I don't like it. But I think there's certainly something where like it's, it's useful for the models and, and humans just forget a lot. And it's really easy to make a small mistake and cause like, bring down, you know, like just bring down the server and like, like, of course we, we like test a lot and whatever, but there, there's always these things that you have to be very careful.

• 1:25:08Speaker 02

  Yeah, like with just normal doc strings, I think people will often just skim it when making a change and think, oh, I know how to do this. And you kind of really need to point it out to them so that that doesn't slip through.

• 1:25:22Lex Fridman?

  Yeah, you have to be reminded that you can do a lot of damage.

• 1:25:26Lex Fridman?

  That's like, we don't really think about that.

• 1:25:27Speaker 03

  Yeah.

• 1:25:28Lex Fridman?

  You think about, okay, how do I figure out how this works so I can improve it? You don't think about the other direction.

• 1:25:35Speaker 03

  Until, until we have formal verification for everything, then you can do whatever you want. And you, you know for certain that you have not introduced a bug if the proof passes.

• 1:25:45Speaker 02

  But concretely, what do you think that future would look like?

• 1:25:48Speaker 03

  I think people will just not write to tests anymore. And the model will suggest, like you write a function, the model will suggest a spec and you review the spec. And in the meantime, a smart reasoning model computes a proof that the implementation follows the spec. And I think that happens for, for most functions.

• 1:26:10Speaker 01

  Don't you think this gets at a little bit, some of the stuff you were talking about earlier with the difficulty of specifying intent for what you want with software? Where sometimes it might be because the intent is really hard to specify, it's also then going to be really hard to prove that it's actually matching whatever your intent is.

• 1:26:24Speaker 03

  Like you think that spec is hard to generate?

• 1:26:28Speaker 01

  Yeah, or just like for a given spec, maybe you can, I think there is a question of like, can you actually do the formal verification? Like that's like, is that possible? I think that there's like more to dig into there, but then also.

• 1:26:42Speaker 03

  Even if you have the spec? If you have the spec.

• 1:26:44Speaker 01

  But how do you? Even if you have the spec, is the spec written in a natural language?

• 1:26:47Speaker 02

  Yeah.

• 1:26:47Speaker 01

  How do you map the spec?

• 1:26:48Speaker 03

  No, the spec, spec would be formal.

• 1:26:51Speaker 02

  But how easy would that be to draw?

• 1:26:52Speaker 01

  So then I think that you care about things that are not going to be easily well specified in the spec language.

• 1:26:57Speaker 03

  I see, I see.

• 1:26:57Speaker 01

  Would be, yeah. Maybe an argument against formal verification is all you need.

• 1:27:02Speaker 03

  Yeah.

• 1:27:02Speaker 02

  The worry is there's this massive document.

• 1:27:04Speaker 01

  Replacing, replacing something like unit tests. Sure.

• 1:27:07Speaker 03

  Yeah, yeah. I think you can probably also evolve the, the spec languages to capture some of the things that. They don't really capture right now.

• 1:27:19Speaker 03

  But I don't know. I think it's very exciting.

• 1:27:21Lex Fridman?

  And you're speaking not just about like, single functions. You're speaking about entire code bases.

• 1:27:26Speaker 03

  I think entire code bases is harder, but that that is what I would love to have. And I think it should be possible. And because you can even, there is like, a lot of work recently where you can prove, formally verify down to the hardware. So like, through the, you formally verify the C code and then you formally verify through the GCC compiler and then through the Verilog down to the hardware. And that's like incredibly big system, but it actually works. And I think big code bases are sort of similar in that they're like, multi-layered system. And if you can decompose it and formally verify each part, then I think it should be possible. I think the specification problem is a real problem, but.

• 1:28:05Speaker 02

  How do you handle side effects? Or how do you handle, I guess, external dependencies, like calling Stripe API?

• 1:28:12Speaker 04

  Maybe Stripe would write a spec for their API.

• 1:28:15Speaker 02

  But like, you can't do this for everything. Like, can you do this for everything you use? Like, how do you, how do you do it for, if there's a language model? Like, maybe, maybe like, people will use language models as primitives in the programs they write. And there's like a dependence on it. And like, how, how do you now include that?

• 1:28:29Speaker 03

  I think you might be able to prove, prove that still.

• 1:28:32Speaker 02

  Prove what about language models?

• 1:28:33Speaker 03

  I think it, it feels possible that you could actually prove that a language model is aligned, for example. Or like, you can prove that it actually gives the, the right answer.

• 1:28:46Speaker 04

  That's the dream.

• 1:28:47Lex Fridman?

  Yeah, that is. I mean, that's, if it's possible, that's your, I have a dream speech. If it's possible, that will certainly help with, you know, making sure your code doesn't have bugs and making sure AI doesn't destroy all of human civilization. So the, the full spectrum of AI safety to just bug finding. So you said the models struggle with bug finding. What's the hope?

• 1:29:10Speaker 04

  You know, my hope initially is, and I can let Michael, Michael chime in too. But it was like, there's.

• 1:29:18Speaker 03

  It should first help with the stupid bugs. Like it should very quickly catch the stupid bugs. Like off by one errors. Like sometimes you write something in a comment and do the other way. It's like very common, like I do this. I write like less than in a comment and like I maybe write the greater than something like that. And the model is like, yeah, you look sketchy. Like, do you sure you want to do that? But eventually it should be able to catch harder bugs too.

• 1:29:42Speaker 01

  Yeah, and I think that it's also important to note that this is having good bug finding models feels necessary to get to the highest reaches of having AI do more and more programming for you. Where you're going to, you know, if AI is building more and more of this system for you, you need to not just generate, but also verify. And without that, some of the problems that we've talked about before with programming with these models will just become untenable. So it's not just for humans, like you write a bug, I write a bug, find the bug for me. But it's also being able to verify the AI's code and check it is really important.

• 1:30:18Speaker 03

  Yeah, and then how do you actually do this? Like, we have had a lot of contentious dinner discussions of how do you actually train a bug model? But one very popular idea is, you know, it's kind of potentially easy to introduce a bug than actually finding the bug. And so you can train a model to introduce bugs in existing code. And then you can train a reverse bug model then that can find bugs using this synthetic data. So that's like one example. But yeah, there are lots of ideas for how to.

• 1:30:48Speaker 01

  You can also, you can also do a bunch of work, not even at the model level, of taking the biggest models and then maybe giving them access to a lot of information that's not just the code. Like, it's kind of a hard problem to like stare at a file and be like, where's the bug? And, you know, that's, that's hard for humans often, right? And so often you have to run the code and being able to see things like traces and step through debugger. There's another, a whole nother direction where it like kind of tends toward that. And it could also be that there are kind of two different product form factors here. It could be that you have a really specialty model that's quite fast, that's kind of running in the background and trying to spot bugs. And it might be that sometimes, sort of our earlier example about, you know, some nefarious input box bug. It might be that sometimes you want to like, there's, you know, there's a bug. You're not just like checking hypothesis free. You're like, this is a problem. I really want to solve it.

• 1:31:32Speaker 01

  And you zap that with tons and tons and tons of compute. And you're willing to put in like $50 to solve that bug or something even more.

• 1:31:39Lex Fridman?

  Have you thought about integrating money into this whole thing? Like, I would pay probably a large amount of money for, if you found a bug, or even generated code that I really appreciated. Like, I had a moment a few days ago when I started using Cursor, where it generated a perfect, like, perfect three functions for interaction with the YouTube API, to update captions, and for localization, like, in different languages. The API documentation is not very good. And the code across, like, if I Googled it for a while, I couldn't find exactly, there's a lot of confusing information. And Cursor generated perfectly. And I was like, I just sat back, I read the code. I was like, this is correct. I tested it, it's correct.

• 1:32:24Lex Fridman?

  I was like, I want a tip on a button that goes,

• 1:32:28Speaker 03

  Yeah.

• 1:32:28Lex Fridman?

  Here's five dollars. One, that's really good, just to support the company, and support what the interface is. And the other is that probably sends a strong signal, like, good job.

• 1:32:40Lex Fridman?

  Right? There's this much stronger signal than just accepting the code, right? You just actually send, like, a strong, good job. That, and for bug finding, obviously, like, there's a lot of people, you know, that would pay a huge amount of money for a bug, like, a bug bounty thing, right? Is that, you guys think about that?

• 1:33:00Speaker 03

  Yeah, it's a controversial idea inside the company. I think it sort of depends on how much you believe in humanity, almost. You know, like, I think it would be really cool if, like, you spend nothing to try to find a bug. And if it doesn't find a bug, you spend zero dollars. And then if it does find a bug, and you click accept, then it also shows, like, in parentheses, like, one dollar. And so you spend one dollar to accept the bug. And then, of course, there's a worry, like, okay, we spent a lot of computation, like, maybe people will just copy paste. I think that's a worry. And then there is also the worry that, like, introducing money into the product makes it, like, kind of, you know, like, it doesn't feel as fun anymore. Like, you have to, like, think about money,

• 1:33:44Speaker 03

  and all you want to think about is, like, the code. And so maybe it actually makes more sense to separate it out. And, like, you pay some fee, like, every month, and then you get all of these things for free.

• 1:33:55Lex Fridman?

  But there could be a tipping component, which is not like it costs.

• 1:33:58Speaker 03

  Yeah, but it still has that, like, dollar symbol. I think it's fine, but I also see the point where, like...

• 1:34:04Speaker 04

  Maybe you don't want to introduce it.

• 1:34:06Speaker 02

  Yeah, I was gonna say, the moment that feels like people do this is when they share it. When they have this fantastic example, they just kind of share it with their friends.

• 1:34:13Speaker 01

  There is also a potential world where there's a technical solution to this, like honor system problem too. Where if we can get to a place where we understand the output of the system more. I mean, to the stuff we were talking about with like, you know, error checking with the LSP and then also running the code. But if you could get to a place where you could actually somehow verify, oh, I have fixed the bug. Maybe then the bounty system doesn't need to rely on the honor system too.

• 1:34:35Lex Fridman?

  How much interaction is there between the terminal and the code? Like, how much information is gained from if you run the code in the terminal? Like, can you use, can you do like a, a loop where it runs, runs the code? And suggests how to change the code if the code and runtime gives an error? Is right now they're separate worlds completely? Like, I know you can do Ctrl K inside the terminal to help you write the code.

• 1:35:01Speaker 02

  You can use terminal context as well, uh, inside of Shack, man, kind of everything. We don't have the looping part yet, though we suspect something like this could make a lot of sense. There's a question of whether it happens in the foreground too, or if it happens in the background, like what we've been discussing.

• 1:35:19Lex Fridman?

  Sure, the background is pretty cool, like we do running the code in different ways. Plus, there's a database side to this, which, how do you protect it from not modifying the database? But okay.

• 1:35:29Speaker 04

  I mean, there's, there's certainly cool solutions there. There's this new API that is being developed for, it's, it's not an AWS, uh, but, you know. It's certainly, I think it's in Planet Scale. I don't know if Planet Scale was the first one to add it. It's just ability to sort of add branches to a database, uh, which is, uh, like if you're working on a feature and you want to test against the prod database, but you don't actually want to test against the prod database. You could sort of add a branch to the database. And the way to do that is to add a branch to the write ahead log. And there's obviously a lot of technical complexity in doing it correctly. I guess database companies need, need, need new things to do.

• 1:36:11Speaker 04

  They have, they have good databases now. And, and I think like, you know, Turbo Buffer, which is, which is one of the databases we use as, is, is going to add, hope maybe branching to the, to the write ahead log. And so maybe the AI agents will use branching. They'll like test against them, branch, and it's sort of going to be a requirement for the database to like support branching or something.

• 1:36:36Speaker 03

  It would be really interesting if you could branch a file system, right?

• 1:36:39Speaker 04

  Yeah, I feel like everything needs branching.

• 1:36:42Speaker 03

  Yeah.

• 1:36:43Lex Fridman?

  Yeah, it's like the problem with the multiverse, right?

• 1:36:48Lex Fridman?

  Like if you branch on everything, that's like a lot.

• 1:36:50Speaker 04

  I mean, there's obviously these like super clever algorithms to make sure that you don't actually use a lot of space or CPU or whatever.

• 1:36:58Lex Fridman?

  Okay, this is a good place to ask about infrastructure. So you guys mostly use AWS? What are some interesting details? What are some interesting challenges? Why'd you choose AWS? Why is AWS still winning? Hashtag.

• 1:37:11Speaker 03

  AWS is just really, really good. It's really good. Like, whenever you use an AWS product, you just know that it's going to work. Like, it might be absolute hell to go through the steps to set it up.

• 1:37:28Lex Fridman?

  Why is the interface so horrible?

• 1:37:30Speaker 03

  Because it's just so good. It doesn't need to.

• 1:37:33Lex Fridman?

  It's the nature of winning.

• 1:37:35Speaker 04

  I think it's exactly, it's just nature they're winning.

• 1:37:37Speaker 03

  Yeah, yeah. But AWS, you can always trust, like, it will always work. And if there is a problem, it's probably your problem.

• 1:37:46Speaker 03

  Yeah.

• 1:37:47Lex Fridman?

  Okay, is there some interesting like challenges to? You guys have a pretty new startup to get scaling to like to so many people and?

• 1:37:55Speaker 01

  Yeah, I think that there. It has been an interesting journey, adding, you know, each extra zero to the request per second. You run into all of these with like, you know, the general components you're using for caching and databases run into issues as you make things bigger and bigger. And now we're at the scale where we get like, you know, into overflows on our tables and things like that.

• 1:38:15Speaker 01

  And then also there have been some custom systems that we've built, like for instance, our retrieval system for computing a semantic index of your codebase and answering questions about a codebase that have continually, I feel like, been one of the trickier things to scale.

• 1:38:30Speaker 04

  I have a few friends who are super, super senior engineers. And one of their sort of lines is like, it's very hard to predict where systems will break when you scale them. You could sort of. Try to predict in advance, like there's always something weird that's gonna happen when you add this extra zero. And you thought, you thought through everything, but you didn't actually think through everything. But I think for that particular system, we've.

• 1:38:58Speaker 04

  So for concrete details, the thing we do is obviously we upload. When like we chunk up all of your code and then we send up sort of the code for embedding and we embed the code. And then we store the embeddings in a database, but we don't actually store any of the code. And then there's reasons around making sure that we don't introduce client bugs because we're very, very paranoid about client bugs. We store much of the details on the server. Like everything is sort of encrypted.

• 1:39:34Speaker 04

  So one of the technical challenges is always making sure that the local index, the local code base state is the same as the state that is on the server. And the way technically we ended up doing that is so for every single file, you can, you can sort of keep this hash. And then for every folder, you can sort of keep a hash, which is the hash of all of its children. And you can sort of recursively do that until the top. And why, why do something, something complicated? One thing you could do is you could keep a hash for every file. Then every minute you could try to download the hashes that are on the server. Figure out what are the files that don't exist on the server? Maybe you just created a new file, maybe you just deleted a file, maybe you checked out a new branch.

• 1:40:18Speaker 04

  And try to reconcile the state between the client and the server. But that introduces like absolutely ginormous network overhead, both, both on the client side. I mean, nobody really wants us to hammer their wifi all the time if you're using cursor. But also like, I mean, it would introduce like ginormous overhead in the database. It would sort of be reading this tens of terabyte database, sort of approaching like 20 terabytes or something database like. Every second, that's just, just kind of crazy. You definitely don't want to do that. So what you do, you sort of, you just try to reconcile the single hash, which is at the root of the project.

• 1:41:02Speaker 04

  And then if something mismatches, then you go, you find where all the things disagree. Maybe you look at the children and see if the hashes match. And if the hashes don't match, go look at their children and so on. But you only do that in the scenario where things don't match. And for most people, most of the time, the hashes match.

• 1:41:16Lex Fridman?

  So it's a kind of like hierarchical reconciliation.

• 1:41:19Speaker 04

  Yeah, something like that.

• 1:41:21Speaker 02

  Yeah, it's called a Merkle tree.

• 1:41:22Lex Fridman?

  Yeah, Merkle, yeah. I mean, so yeah, this is cool to see that you kind of have to think through all these problems.

• 1:41:28Speaker 04

  And I mean, the point of, like, the reason it's gotten hard is just because, like, the number of people using it and, you know, if some of your customers have really, really large code bases, to the point where, you know, we originally reworked our code base, which is, which is big, but I mean, it's just not the size of some company that's been there for 20 years and sort of has a enormous number of files. And you sort of want to scale that across programmers. There's, there's all these details where like, building the simple thing is easy, but scaling it to a lot of people, like a lot of companies, is obviously a difficult problem, which is sort of, you know, independent of actually, so that's, there's part of this, scaling our current solution is also, you know, coming up with new ideas that obviously

• 1:42:10Speaker 04

  we're working on, but then, but then scaling all of that in the last few weeks, months.

• 1:42:14Speaker 02

  Yeah, and there are a lot of clever things, like additional things that go into this indexing system. For example, the bottleneck in terms of costs is not storing things in the vector database. The database is actually embedding the code. And you don't want to re-embed the code base for every single person in a company that is using the same exact code, except for maybe they're a different branch with a few different files, or they've made a few local changes. And so because, again, embeddings is the bottleneck, you can do this one clever trick and not have to worry about like, the complexity of like, dealing with branches and the other databases where you just have some cache on the actual vectors computed from the hash of a given chunk.

• 1:42:56Speaker 02

  And so this means that when the nth person at a company goes and embeds their code base, it's, it's really, really fast. And you do all this without actually storing any code on our servers at all. No code data stored. We just store the vectors in the vector database and the vector cache.

• 1:43:11Lex Fridman?

  What's the biggest gains at this time you get from indexing the code base? Like, just out of curiosity, like what? What benefit do users have? It seems like longer term, there'll be more and more benefit. But in the short term, just asking questions of the codebase,

• 1:43:29Lex Fridman?

  what's the usefulness of that?

• 1:43:32Speaker 03

  I think the most obvious one is just you want to find out where something is happening in your large codebase. And you sort of have a fuzzy memory of, okay, I want to find the place where we do X. But you don't exactly know what to search for in a normal text search. And so you ask a chat, you hit command enter to ask with the codebase chat. And then very often it finds the right place that you were thinking of.

• 1:43:58Speaker 02

  I think, like you mentioned, in the future, I think this is only going to get more and more powerful. Where we're working a lot on improving the quality for retrieval. And I think the ceiling for that is really, really much higher than people give it credit for.

• 1:44:12Lex Fridman?

  One question that's good to ask here. Have you considered and why haven't you much done sort of local stuff? To where you can do the, it seems like everything we just discussed is exceptionally difficult to do. To go to the cloud, you have to think about all these things with the caching and the,

• 1:44:30Lex Fridman?

  you know, large codebases with a large number of programmers are using the same codebase. You have to figure out the puzzle of that. A lot of it, you know, most software just does stuff, this heavy computational stuff locally. Have you considered doing sort of embeddings locally?

• 1:44:45Speaker 03

  Yeah, we thought about it and I think it would be cool to do it locally. I think it's just really hard. And one thing to keep in mind is that, you know, some of our users use the latest MacBook Pro. And but most of our users, like more than 80% of our users are in Windows machines, which, and many of them are not very powerful. And so local models really only works on the latest computers. And it's also a big overhead to build that in. And so even if we would like to do that.

• 1:45:18Speaker 03

  It's currently not something that we are able to focus on. And I think there are some people that do that, and I think that's great. But especially as models get bigger and bigger and you want to do fancier things with like bigger models, it becomes even harder to do locally.

• 1:45:34Speaker 04

  Yeah, and it's not a problem of like weaker computers. It's just that, for example, if you're some big company, you have big company code base. It's just really hard to process big company code base even on the beefiest Mac Pro's. So even if it's not even a matter of like, if you're just like a student or something. I think if you're like the best programmer at a big company, you're still going to have a horrible experience if you do everything locally. I mean, you could do edge and sort of scrape by, but like, again, it wouldn't be fun anymore.

• 1:46:07Speaker 02

  Yeah, like an approximate nearest neighbors and this massive code base is going to just eat up your memory and your CPU. And that's, and that's just that. Like, let's talk about like also the modeling side where, as Arvid said, there are these massive headwinds against local models where, one, things that seem to move towards MOEs, which like one benefit is maybe they're more memory bandwidth bound, which plays in favor of local versus using GPUs or using Nvidia GPUs. But the downside is these models are just bigger in total. And, you know, they're going to need to fit often, not even on a single node, but multiple nodes. There's no way that's going to fit inside of even really good MacBooks.

• 1:46:52Speaker 02

  And I think especially for coding, it's not a question as much of like, does it clear some bar of like the model's good enough to do these things? And then like we're satisfied, which may be the case for other, other problems and maybe where local models shine. But people are always going to want the best, the most intelligent, the most capable things. And that's going to be really, really hard to run for almost all people locally.

• 1:47:17Speaker 04

  Don't you want the most capable model? Like, you want Sonnet?

• 1:47:22Speaker 03

  And also with

• 1:47:24Lex Fridman?

  I like how you're pitching me. Would you be satisfied with an inferior model? Listen, I'm, yes, I'm one of those, but there's some people that like to do stuff locally, especially like that really, there's a whole, obviously, open source movement that kind of resists. And it's good that they exist, actually, because you want to resist the power centers that are growing our

• 1:47:46Speaker 03

  There's actually an alternative to local models that I am particularly fond of. I think it's still very much in the research stage, but you could imagine to do homomorphic encryption for language model inference. So you encrypt your input on your local machine, then you send that up. And then the server can use lots of computation. They can run models that you cannot run locally on this encrypted data. But they cannot see what the data is. And then they send back the answer and you decrypt the answer and only you can see the answer. So I think that's still very much research and all of it is about trying to make the overhead lower, because right now the overhead is really big.

• 1:48:29Speaker 03

  But if you can make that happen, I think that would be really, really cool. And I think it would be really, really impactful. Because I think one thing that's actually kind of worrisome is that as these models get better and better, they're going to become more and more economically useful. And so more and more of the world's information and data will flow through, you know, one or two centralized actors. And then there are worries about, you know, there can be traditional hacker attempts, but it also creates this kind of scary part where if all of the world's information is flowing through one node in plain text, you can have surveillance in very bad ways.

• 1:49:10Speaker 03

  And sometimes that will happen for, you know, initially will be like good reasons, like people will want to try to protect against like bad actors using AI models in bad ways. And then you will add in some surveillance code and then someone else will come in and, you know, you're in a slippery slope and then you start doing bad things with a lot of the world's data. And so I, I'm very hopeful that we can solve homomorphic encryption for

• 1:49:38Lex Fridman?

  Doing privacy preserving machine learning. But I would say like, that's the challenge we have with all software these days. It's like, There's so many features that can be provided from the cloud and all of us increasingly rely on it and make our life awesome. But there's downsides and that's why you rely on really good security to protect from basic attacks. But there's also only a small set of companies that are controlling that data. You know, and they they obviously have leverage and they could be infiltrated in all kinds of ways. That's the world we live in.

• 1:50:09Speaker 04

  Yeah, I mean, the thing I'm just actually quite worried about is sort of the world where I mean, so Anthropic has this responsible scaling policy. And so we're we're on like the low low ASLs, which is the Anthropic security level or whatever. Uh, of like of the models, but as we get to like code and code ASL three, ASL four, whatever models. Uh, which are sort of very powerful, but for for mostly reasonable security reasons, you would want to monitor all the prompts. Uh, but I think I think that's that's sort of reasonable and understandable where where everyone is coming from. But Matt, it'd be really horrible if if sort of like all the world's information is sort of monitored that heavily. It's way too centralized.

• 1:50:53Speaker 04

  It's like it's like sort of this like really fine line you're walking where on the one side, like you you don't want the models to go rogue. On the other side, like man, it's humans like. I don't I don't know if I if I trust like all the world's information to pass through like three, three model providers.

• 1:51:09Lex Fridman?

  Yeah.

• 1:51:10Speaker 02

  Why do you think it's different than cloud providers?

• 1:51:13Speaker 03

  Because I think the this is a lot of this data would never have gone to the cloud providers in the in the first place. Where this is often like you want to give more data to the AI models. You want to give personal data that you would never have put online in the first place. To these companies or or to these models. And it also centralizes control. Where right now, um, for for cloud, you can often use your own encryption keys and it like it just can't really do much.

• 1:51:52Speaker 03

  But here is just. Centralized actors that see the exact plane text of everything.

• 1:51:58Lex Fridman?

  On the topic of context, that's actually been a friction for me. When I'm writing code in Python, there's a bunch of stuff imported. There's a, you could probably intuit the kind of stuff I would like to include in the context. Is there, like, how hard is it to auto-figure out the context?

• 1:52:17Speaker 01

  It's tricky. I think we can do a lot better at computing the context automatically in the future. One thing that's important to note is there are trade-offs with including automatic context. So the more context you include for these models, first of all, the slower they are, and the more expensive those requests are, which means you can then do less model calls and do less fancy stuff in the background. Also, for a lot of these models, they get confused if you have a lot of information in the prompt. So the bar for accuracy and for relevance of the context you include should be quite high. But this is, already we do some automatic context in some places within the product. It's definitely something we want to get a lot better at.

• 1:53:01Speaker 01

  And I think that there are a lot of cool ideas to try there. Both on the learning better retrieval systems, like better embedding models, better re-ranking. I think that there are also cool academic ideas, you know, stuff we've tried out internally, but also the field is grappling with writ large about can you get language models to a place where you can actually just have the model itself, like, understand a new corpus of information? And the most popular talked-about version of this is, can you make the context windows infinite? Then if you make the context windows infinite, can you make the model actually pay attention to the infinite context? And then after you can make it pay attention to the infinite context, to make it somewhat feasible to actually do it, can you then do caching for that infinite context? You don't have to recompute that all the time.

• 1:53:47Speaker 01

  But there are other cool ideas that are being tried that are a little bit more analogous to fine tuning of actually learning this information in the weights of the model. And it might be that you actually get sort of a qualitatively different type of understanding if you do it more at the weight level than if you do it at the in-context learning level. I think the jury is still a little bit out on how this is all going to work in the end. But in the interim, us as a company, we are really excited about better retrieval systems and picking the parts of the codebase that are most relevant to what you're doing. We could do that a lot better.

• 1:54:18Speaker 02

  Like, one interesting proof of concept for the learning this knowledge directly in the weights is with VS Code. So we're in a VS Code fork and VS Code, the code is all public. So these models in pre-training have seen all the code. They've probably also seen questions and answers about it, and then they've been fine-tuned and RLCF to be able to be able to answer questions about code in general. So when you ask it a question about VS Code, sometimes it'll hallucinate, but sometimes it actually does a pretty good job at answering the question. And I think like, this is just by, it happens to be okay. But what if you could actually like specifically train or post-train a model such that it really

• 1:55:00Speaker 02

  was built to understand this codebase? It's an open research question, one that we're quite interested in. And then there's also uncertainty of like, do you want the model to be the thing that end to end is doing everything, i.e. it's doing the retrieval and its internals and then kind of answering the question, creating the code? Or do you want to separate the retrieval from the frontier model? Where maybe, you know, you'll get some really capable models that are much better than like the best open source ones in a handful of months. And then you'll want to separately train a really good open source model to be the retriever, to be the thing that feeds in the context to these larger models.

• 1:55:40Lex Fridman?

  Can you speak a little more to the post-training a model to understand the codebase? Like, what do you, what do you mean by that? With, is this a synthetic data direction? Is this?

• 1:55:49Speaker 02

  Yeah, I mean, there are many possible ways you could try doing it. There's certainly no shortage of ideas. It's just a question of going in and like trying all of them and being empirical about which one works best.

• 1:56:02Speaker 02

  You know, one, one very naive thing is to try to replicate what's done with VS code and these frontier models. So let's like continue pre-training, some kind of continued pre-training that includes general code data, but also throws in a lot of the data of some particular repository that you care about. And then in post-training, meaning in, let's just start with instruction fine-tuning. You have like a normal instruction fine-tuning data set about code, but then you throw in a lot of questions about code in that repository. So you could either get ground truth ones, which might be difficult, or you could do what you kind of hinted at or suggested using synthetic data,

• 1:56:41Speaker 02

  i.e. kind of having the model ask questions about various pieces of the code. So you kind of take the pieces of the code, then prompt the model or have a model propose a question for that piece of code and then add those as instruction fine-tuning data points. And then in theory, this might unlock the model's ability to answer questions about that code base.

• 1:57:05Lex Fridman?

  Let me ask you about OpenAI 01. What do you think is the role of that kind of test time compute system in programming?

• 1:57:13Speaker 02

  I think test time compute is really, really interesting. So there's been the pre-training regime, which will kind of, as you scale up the amount of data and the size of your model, get you better and better performance, both on loss and then on downstream benchmarks and just general performance, and we use it for coding or other tasks.

• 1:57:35Speaker 02

  We're starting to hit a bit of a data wall, meaning it's going to be hard to continue scaling up this regime. And so scaling up test time compute is an interesting way of now, you know, increasing the number of inference time flops that we use, but still getting like, like, yeah, as you increase the number of flops. Use inference time, getting corresponding improvements in in performance of these models. Traditionally, we just had to literally train a bigger model that always uses that always used that many more flops. But now we could perhaps use the same size model and run it for longer to be able to get an answer at the quality of a much larger model. And so the really interesting thing I like about this is there are some problems that perhaps require

• 1:58:19Speaker 02

  100 trillion parameter model intelligence trained on 100 trillion tokens.

• 1:58:24Speaker 02

  But that's like maybe 1%, maybe like 0.1% of all queries. So are you going to spend all of this effort, all this compute training model that costs that much and then run it so infrequently? It feels completely wasteful when instead you get the model that can that you train the model that is capable of doing the 99.9% of queries. Then you have a way of inference time, running it longer for those few people that really, really want max intelligence.

• 1:58:54Lex Fridman?

  How do you figure out which problem requires what level of intelligence? Is that possible to dynamically figure out when to use GPT-4, when to use, like when to use a small model and when you need the O1?

• 1:59:09Speaker 02

  I mean, yeah, that's that's an open research problem, certainly. I don't think anyone's actually cracked this model routing problem quite well. We'd like to, we have like kind of initial implementations of this for things, for something like cursor tab. But at the level of like going between 4.0 Sonnet to 0.1, it's a bit trickier. There's also a question like what level of intelligence do you need to determine if the thing is too hard for the for the four level model? Maybe you need the O1 level model. It's really unclear.

• 1:59:45Lex Fridman?

  But you mentioned, so there's a there's a there's a pre-training process. Then there's post-training and then there's like test time compute. Is that fair to sort of separate? Where's the biggest gains?

• 1:59:57Speaker 02

  Well, it's weird because like test time compute, there's like a whole training strategy needed to get test time to compute to work. And the really, the other really weird thing about this is No one, like outside of the big labs and maybe even just OpenAI, no one really knows how it works. Like there have been some really interesting papers that show hints of what they might be doing. And so perhaps they're doing something with tree search using process reward models. But yeah, I just, I think the issue is we don't quite know exactly what it looks like. So it would be hard to kind of comment on like where it fits in. I would, I would put it in post-training, but maybe like the compute spent for this kind of, for getting test time compute to work for a model

• 2:00:41Speaker 02

  is going to dwarf pre-training eventually.

• 2:00:45Lex Fridman?

  So we don't even know if O1 is using just like Chain of Thought RL. We don't know how they're using any of these. I don't know anything.

• 2:00:53Speaker 02

  It's fun to speculate.

• 2:00:56Lex Fridman?

  Like if you were to build a competing model, what would you do?

• 2:01:01Speaker 02

  Yeah. So one thing to do would be, I, I think you probably need to train a process reward model, which is, so maybe we can get into reward models and outcome reward models versus process reward models. Outcome reward models are the kind of traditional reward models that people are trained for these, for, for language models, language modeling. And it's just looking at the final thing. So if you're doing some math problem, let's look at that final thing. You've done everything and let's assign a grade to it, how likely we think, like what's the reward for this, this, this outcome. Process reward models instead try to grade the chain of thought. And so OpenAI had some preliminary paper on this, I think, last summer,

• 2:01:40Speaker 02

  where they use human labelers to get this pretty large, several hundred thousand data set of grading chains of thought.

• 2:01:50Speaker 02

  Ultimately, it feels like, I haven't seen anything interesting in the ways that people use process reward models outside of just using it as a means of affecting how we choose between a bunch of samples. So like what people do in all these papers is they sample a bunch of outputs from the language model and then use the process reward models to grade all those generations alongside maybe some other heuristics and then use that to choose the best answer. The really interesting thing that people think might work and people want to work is tree search with these process reward models, because if you really can grade every single step of the chain of thought.

• 2:02:30Speaker 01

  Then you can kind of branch out and, you know, explore multiple paths of this chain of thought and then use these process reward models to evaluate how good is this branch that you're taking.

• 2:02:40Lex Fridman?

  Yeah, when the, when the quality of the branch is somehow strongly correlated with the quality of the outcome at the very end. So like you have a good model of knowing which branch you take. So not just this in the short term, like in the long term.

• 2:02:52Speaker 01

  Yeah. And like the interesting work that I think has been done is figuring out how to properly train the process or the interesting work that has been open source and people I think talk about is how to train the process reward models, maybe in a more automated way. I could be wrong here, could not be mentioning some people, but I haven't seen anything super that seems to work really well for using the process reward models creatively to do tree search and code.

• 2:03:18Lex Fridman?

  This is kind of an AI safety, maybe a bit of a philosophy question. So OpenAI says that they're hiding the chain of thought from the user and they've said that that was a difficult decision to make. They, instead of showing the chain of thought, they're asking the model to summarize the chain of thought. They're also in the background saying they're going to monitor the chain of thought to make sure the model is not trying to manipulate the user, which is a fascinating possibility. But anyway, what do you think about hiding the chain of thought?

• 2:03:47Speaker 01

  One consideration for OpenAI, and this is completely speculative, could be that they want to make it hard for people to distill these capabilities out of their model. It might actually be easier if you had access to that hidden chain of thought to replicate the technology, because that's pretty important data, like seeing, seeing the steps that the model took to get to the final result.

• 2:04:06Lex Fridman?

  So you could probably train on that also.

• 2:04:08Speaker 01

  And there was sort of a mirror situation with this, with some of the large language model providers, and also this is speculation, but some of these APIs used to offer easy access to log probabilities for all the tokens that they're generating and also log probabilities for the prompt tokens. And then some of these APIs took those away. And again, complete speculation, but one of the thoughts is that the, the reason those were taken away is if you have access to log probabilities, similar to this hidden chain of thought, that can give you even more information to, to try and distill these capabilities out of the APIs, out of these biggest models. And to models you control. As an asterix on also the the previous discussion about us integrating O1.

• 2:04:52Speaker 01

  I think that we're still learning how to use this model. So we made O1 available in Cursor because like we were when we got the model, we were really interested in trying it out. I think a lot of programmers are going to be interested in trying it out. But O1 is not part of the default cursor experience in any way up. And we still haven't found a way to yet integrate it into an editor into the editor in a way that we we we reach for sort of, you know, every hour, maybe even every day. And so I think the jury's still out on how to how to use the model. And I we haven't seen examples yet of of people releasing things where it seems really clear like, oh, that's that's like now the use case.

• 2:05:36Speaker 01

  The obvious one to turn to is maybe this can make it easier for you to have these background things running, right? To have these models in loops, to have these models be agentic. But we're still discovering.

• 2:05:48Speaker 04

  To be clear, we have ideas. We just need to we need to try and get something incredibly useful before we we put it out there.

• 2:05:55Speaker 01

  But it has these significant limitations, like even like barring capabilities. It does not stream. And that means it's really, really painful to use for things where you want to supervise the output. And instead, you're just waiting for the wall text to show up. Also, it does feel like the early innings of Test Time Computing Search where it's just like a very, very much a V zero. And there's so many things that like, like, don't feel quite right. And I suspect in parallel to people increasing the amount of pre-training data and the size of the models in pre-training and finding tricks there. You'll now have this other thread of getting search to work better and better.

• 2:06:40Lex Fridman?

  So let me ask you about Strawberry Tomorrow Eyes. So it looks like GitHub Copilot might be integrating O1 in some kind of way. And I think some of the comments are saying, does this mean Cursor is done? I think I saw one comment saying that.

• 2:07:01Speaker 03

  I saw, "Time to shut down Cursor."

• 2:07:03Lex Fridman?

  Time to shut down Cursor, thank you. So is it time to shut down Cursor?

• 2:07:07Speaker 01

  I think this space is a little bit different from past software spaces over the 2010s, where I think that the ceiling here is really, really, really incredibly high. And so I think that the best product in three to four years will just be so much more useful than the best product today. And you can like wax poetic about Moat's this and brand that and, you know, this is our advantage. But I think in the end, just if you don't have, like, if you stop innovating on the product, you will, you will lose. And that's also great for startups. That's great for people trying to enter this market, because it means you have an opportunity to win against people who have, you know, lots of users already by just building something better.

• 2:07:50Speaker 01

  And so I think, yeah, over the next few years, it's just about building the best product, building the best system. And that both comes down to the modeling engine side of things, and it also comes down to the, to the editing experience.

• 2:08:03Speaker 02

  Yeah, I think most of the additional value from Cursor versus everything else out there is not just integrating the new model fast, like O1. It comes from all of the kind of depth that goes into these custom models that you don't realize are working for you in kind of every facet of the product, as well as like the really thoughtful UX with every single feature.

• 2:08:26Lex Fridman?

  All right. From that profound answer, let's descend back down to the technical. You mentioned you have a taxonomy of synthetic data.

• 2:08:34Speaker 02

  Oh, yeah.

• 2:08:35Lex Fridman?

  Can you please explain?

• 2:08:36Speaker 02

  Yeah, I think there are three main kinds of synthetic data. The first is, so what is synthetic data first? So there's normal data, like non-synthetic data, which is just data that's naturally created, i.e. usually it'll be from humans having done things. So from some human process, you get this data. Synthetic data, the first one would be distillation. So having a language model, kind of output tokens or probability distributions over tokens. And then you can train some less capable model on this. This approach is not going to get you a net, like more capable model than the original one that has produced the tokens.

• 2:09:19Speaker 02

  But it's really useful for if there's some capability you want to elicit from some really expensive, high latency model, you can then distill that down into some smaller task-specific model. The second kind is when like one direction of the problem is easier than the reverse. And so a great example of this is bug detection, like we mentioned earlier, where it's a lot easier to introduce reasonable-looking bugs than it is to actually detect them. And this is probably the case for humans, too. And so what you can do is you can get a model that's not training that much data, that's not that smart, to introduce a bunch of bugs in code.

• 2:10:02Speaker 02

  And then you can use that to then train, use a synthetic data to train a model that can be really good at detecting bugs. The last category, I think, is, I guess, the main one that it feels like the big labs are doing for synthetic data, which is producing text with language models that can then be verified easily. So like, you know, extreme example of this is if you have a verification system that can detect if language is Shakespeare level and then you have a bunch of monkeys typing in typewriters. Like, you can eventually get enough training data to train a Shakespeare-level language model. And I mean, this is the case, like, very much the case for math, where verification is actually really, really easy for formal.

• 2:10:47Speaker 02

  Formal languages. And then what you can do is you can have an okay model, generate a ton of rollouts and then choose the ones that you know have actually proved the ground truth theorems and then train that further. There are similar things you can do for code with lead code like problems where if you have some set of tests that you know correspond to, if something passes these tests, it has actually solved the problem. You could do the same thing where you verify that it's passed the test and then train the model the outputs that have passed the tests. I think it's gonna be a little tricky getting this to work in all domains or just in general. Like having the perfect verifier feels really, really hard to do with just like open-ended miscellaneous tasks you give the model or more

• 2:11:32Speaker 02

  like long horizon tasks, even in coding.

• 2:11:35Lex Fridman?

  That's because you're not as optimistic as Arvid. But yeah. So yeah, so that that that third category requires having a verifier.

• 2:11:42Speaker 02

  Yeah. Verification is, it feels like it's best when you know for a fact that it's correct. And like, then it like, it wouldn't be like using a language model to verify, it'd be using tests or formal systems.

• 2:11:54Speaker 01

  Or running the thing too. Doing like the human form verification where you just do manual quality control.

• 2:12:00Speaker 02

  Yeah.

• 2:12:01Speaker 01

  Yeah. But like the the language model version of that where it's like running the thing and it's actually understands the output.

• 2:12:06Speaker 02

  Yeah, no, that's.

• 2:12:06Speaker 01

  For somewhere between.

• 2:12:08Speaker 02

  Yeah. I think that that's the category that is most likely to result in like massive gains.

• 2:12:14Lex Fridman?

  What about RL with feedback side, RLHF versus RLAIIF? What's the role of that in getting better performance on the models?

• 2:12:26Speaker 02

  Yeah. So RLHF is when the reward model you use is trained from some labels you've collected from humans giving feedback. I think this works if you have the ability to get a ton of human feedback for this kind of task that you care about. RLAIIF is interesting because you're kind of depending on. Like this is actually kind of going to, it's depending on the constraint that verification is actually a decent bit easier than generation. Because it feels like, okay, like, what are you doing? Are you using this language model to look at the language model outputs and then improve the language model?

• 2:13:08Speaker 02

  But no, it actually may work if the language model has a much easier time verifying some solution than it does generating it. Then you actually could perhaps get this kind of recursive loop. But I don't think it's going to look exactly like that. The other, the other thing you could do is, that we kind of do is like a little bit of a mix of RLIF and RLHF, where usually the model is actually quite correct, and this is in the case of cursor tab, picking between like two possible generations of what is, what is, what is the better one? And then it just needs like a hand, a little bit of human nudging with only like on the, on the order of 50, 100 examples to like, kind of align that prior the model has with

• 2:13:53Speaker 02

  exactly with what you want. It looks different than I think normal RLHF, where you're usually, usually training these reward models on tons of examples.

• 2:14:01Lex Fridman?

  What's your intuition when you compare generation and verification, or generation and ranking? Is, is ranking way easier than generation?

• 2:14:12Speaker 02

  My intuition would just say, yeah, it should be. Like, this is kind of going back to, like, if you, if you believe P does not equal NP, then there's this massive class of problems that are much, much easier to verify given a proof than actually proving it.

• 2:14:30Lex Fridman?

  I wonder if the same thing will prove P not equal to NP, or P equal to NP?

• 2:14:35Speaker 04

  That would be, that would be really cool.

• 2:14:37Lex Fridman?

  That'd be a whatever Fields Medal?

• 2:14:41Lex Fridman?

  By AI, who gets the credit? Another open philosophical question.

• 2:14:47Speaker 04

  I'm actually

• 2:14:47Speaker 02

  Who prompted it?

• 2:14:50Speaker 04

  I'm actually surprisingly curious what, what, what like a good bet for when, when AI will get the Fields Medal will be. I actually don't have

• 2:14:58Lex Fridman?

  Isn't this a Mon specialty?

• 2:14:59Speaker 04

  I, I don't know what a Mon's bet here is.

• 2:15:01Lex Fridman?

  Oh, sorry, Nobel Prize or Fields Medal first?

• 2:15:04Speaker 04

  Fields Medal.

• 2:15:04Speaker 02

  Well, Fields Medal level?

• 2:15:06Speaker 04

  Needs to solve, I think.

• 2:15:07Lex Fridman?

  Fields Medal comes first. Well, you would say that, of course.

• 2:15:11Speaker 02

  But it's also this like isolated system to verify and

• 2:15:13Lex Fridman?

  Sure.

• 2:15:15Speaker 04

  Like, I don't even know if I would-

• 2:15:16Speaker 03

  You don't need to do this.

• 2:15:16Speaker 02

  I feel like I have much more history there. It felt like the path to get to IMO was a little bit more clear because it already could get a few IMO problems and there are a bunch of like, there's a bunch of low hanging fruit, given the literature at the time of like, what tactics people could take. I think I'm, one, much less versed in the space of theorem proving now. And two, yeah, less intuition about how close we are to solving these really, really hard, open problems.

• 2:15:41Lex Fridman?

  So you think it'll be Fields Medal first? It won't be like in physics or in-

• 2:15:46Speaker 04

  Oh, 100%. I think, I think, I think that's probably more likely. Like, it's probably much more likely that it'll get in. Yeah, yeah, yeah. Well, I think it goes to like, I don't know, like BSD, which is the Bird's Winter Day conjecture, or like Remont-IPod, or any one of these like, hard, hard math problems, which is like, actually really hard. It's sort of unclear what the path to, to get even a solution looks like. Like, we, we don't even know what a path looks like, let alone.

• 2:16:12Speaker 03

  And you don't buy the idea that this is like an isolated system and you can actually, you have a good reward system and it feels like it's easier to train for that.

• 2:16:22Speaker 02

  I think we might get Fields Medal before AGI.

• 2:16:25Speaker 03

  I think-

• 2:16:26Speaker 04

  I mean, I'd be very happy. I'd be very happy. But I don't know if I, I think 2028, 2030?

• 2:16:35Lex Fridman?

  Or Fields Medal.

• 2:16:37Speaker 04

  Fields Medal.

• 2:16:37Lex Fridman?

  All right. It's, uh, it feels like forever from now, given how fast things have been going. Speaking of how fast things have been going, let's talk about scaling laws. So for people who don't know, uh, maybe it's good to talk about this whole idea of scaling laws. What are they? Where do things stand? And where do you think things are going?

• 2:17:00Speaker 02

  I think it was interesting, the original scaling laws paper by OpenAI was slightly wrong because I think of some issues they did with, uh, learning rate schedules. Uh, and then Chinchilla showed a more correct version. And then from then, people have again, kind of deviated from doing the compute optimal thing because people start now optimizing more so for, uh, making the thing work really well, given a, given an inference budget. And I think there are a lot more dimensions to these curves than what we originally used of just compute, number of, uh, parameters and data.

• 2:17:36Speaker 02

  Like inference compute is the obvious one. I think context length is another obvious one. So if you care, like, let's say you care about the two things of inference compute and then context window. Maybe the thing you want to train is some kind of SSM because they're much, much cheaper and faster at super, super long contexts. And even if maybe it has 10x worse scaling properties during training, meaning you spend 10x more compute to train the thing to get the same level of capabilities. It's worth it because you care most about that inference budget for really long context windows. So it'll be interesting to see how people kind of play with all these dimensions.

• 2:18:13Lex Fridman?

  So yeah, I mean, you speak to the multiple dimensions. Obviously, the original conception was just looking at the variables of the size of the model as measured by parameters and the size of the data as measured by the number of tokens and looking at the ratio of the two.

• 2:18:26Speaker 02

  Yeah.

• 2:18:26Lex Fridman?

  And it's, it's kind of a compelling notion that there is a number or at least a minimum. And it seems like one was emerging.

• 2:18:36Lex Fridman?

  Do you still believe that there is a kind of bigger is better?

• 2:18:41Speaker 02

  I mean, I think bigger is certainly better for just raw performance.

• 2:18:47Speaker 04

  And raw intelligence.

• 2:18:48Speaker 02

  And raw intelligence. I think that the path that people might take is, I'm particularly bullish on distillation. And like, yeah, how many knobs can you turn to if we spend like a ton, ton of money on training, like get the most capable cheap model, right? Like really, really caring as much as you can. Because like the naive version of caring as much as you can about inference time compute is what people have already done with like the Llama models or just overtraining the shit out of 7B models on way, way, way more tokens than is essential optimal. But if you really care about it, maybe the thing to do is what Gamma did, which is let's just not, let's not just train on tokens. Let's literally train on.

• 2:19:28Speaker 02

  Minimizing the KL divergence with the distribution of gamma 27B, right? So knowledge distillation there. And you're spending the compute of literally training this 27 billion model, billion parameter model on all these tokens just to get out this, I don't know, smaller model?

• 2:19:46Lex Fridman?

  And the distillation gives you just a faster model, smaller means faster.

• 2:19:50Speaker 02

  Yeah, distillation in theory is, I think, getting out more signal from the data that you're training on. And it's like another, it's perhaps another way of getting over, not like completely over, but like partially helping with the data wall. Where like you only have so much data to train on, let's like train this really, really big model on all these tokens and we'll distill it into this smaller one. And maybe we can get more signal per token for this, for this much smaller model than we would have originally if we trained it.

• 2:20:17Lex Fridman?

  So if I gave you $10 trillion, how would you spend it? I mean, you can't buy an island or whatever. How would you allocate it in terms of improving the big model versus maybe paying for HF in the RLHF?

• 2:20:35Speaker 02

  Yeah. Yeah, I think there's a lot of these secrets and details about training these large models that I just don't know and only privy to the large labs. And the issue is I would waste a lot of that money if I even attempted this because I wouldn't know those things. Suspending a lot of disbelief and assuming like you had the know-how and operate or if you're saying like you have to operate with like the limited information you have now.

• 2:21:04Lex Fridman?

  No, no, no, actually, I would say you swoop in and you get all the information, all the little heuristics, all the little parameters, all the, all the parameters that define how the thing is trained. If we look in how to invest money for the next five years in terms of maximizing what you called raw intelligence.

• 2:21:23Speaker 04

  I mean, isn't the answer like really simple? You just, you just try to get as much compute as possible? Like, like at the end of the day, all you need to buy is the GPUs and then the researchers can find, find all the, all like they can sort of, you know, you can tune whether you want to pre-train a big model or a small model like.

• 2:21:40Speaker 02

  Well, this gets into the question of like, are you really limited by compute and money or are you limited by these other things?

• 2:21:47Speaker 04

  I'm more privy to Arvid's, Arvid's belief that we're sort of ideal limited, but.

• 2:21:53Speaker 04

  There's always like

• 2:21:54Speaker 03

  But if you have a lot of compute, you can run a lot of experiments.

• 2:21:59Lex Fridman?

  So you would run a lot of experiments versus like use that compute to train a gigantic model?

• 2:22:04Speaker 03

  I would, but I do believe that we are limited in terms of ideas that we have.

• 2:22:10Speaker 02

  I think, yeah, because even with all this compute and like, you know, all the data you could collect in the world, I think you really are ultimately limited by not even ideas, but just like really good engineering. Like even with all the capital in the world, would you really be able to assemble? Like, there aren't that many people in the world who really can like make the difference here. And there's so much work that goes into research that is just like pure, really, really hard engineering work. As like a very kind of hand wavy example, if you look at the original transformer paper, you know, how much work was kind of joining together a lot of these really interesting concepts embedded in the literature

• 2:22:53Speaker 02

  versus then going in and writing all the codes, like maybe the CUDA kernels, maybe whatever else. I don't know if it ran on GPUs or TPUs originally, such that it actually saturated the GPU performance, right? Getting Gnome just here to go in and do all this code, right? And Gnome is like probably one of the best engineers in the world. Or maybe going a step further, like the next generation of models, having these things, like getting model parallelism to work and scaling it on like, you know, thousands of, or maybe tens of thousands of like V100s, which I think GBD3 may have been. There's just so much engineering effort that has to go into all of these things to make it work.

• 2:23:29Speaker 02

  If you really brought that cost down to like, you know, maybe not zero, but just made it 10x easier, made it super easy for someone with really fantastic ideas to immediately get to the version of like the new architecture they dreamed up that is like getting 50, 40% utilization on the GPUs. I think that would just speed up research by a ton.

• 2:23:53Speaker 04

  I mean, I think if you see a clear path to improvement, you should always sort of take the low hanging fruit first, right? And I think probably OpenAI and all the other labs did the right thing to pick off the low hanging fruit, where the low hanging fruit is like sort of. You could scale up to a GPT four point two five scale.

• 2:24:15Speaker 04

  And you just keep scaling and like things, things keep getting better. And as long as like you, there's, there's no point of experimenting with new ideas when like everything, everything is working. And you should sort of bang on it and try to, try to get as much, as much juice out of the possible. And then, and then maybe, maybe when you really need new ideas for, I think, I think if you're, if you're spending $10 trillion, probably want to spend some, you know, then actually like create value to your ideas, like probably your idea limited at that point.

• 2:24:41Speaker 02

  I think all of us believe new ideas are probably needed to get, you know, all the way there to AGI. And all of us also probably believe there exist ways of testing out those ideas at smaller scales and being fairly confident that they'll play out. It's just quite difficult for the labs in their current position to dedicate their very limited research and engineering talent to explore all these other ideas when there's like this core thing that will probably like improve performance for some like decent amount of time.

• 2:25:22Lex Fridman?

  Yeah, but also these big labs like winning. So they're, they're just going wild. Okay. So how, uh, big question, looking out into the future. You're now at the, the center of the programming world. How do you think programming, the nature of programming changes in the next few months, in the next year, in the next two years, next five years, 10 years?

• 2:25:47Speaker 02

  I think we're really excited about a future where the programmers in the driver's seat for a long time. And you've heard us talk about this a little bit, but one that emphasizes speed and agency for the programmer and control. The ability to modify anything you want to modify, the ability to iterate really fast on what you're building. And

• 2:26:09Speaker 01

  This is a little different, I think, than where some people are jumping to in the space, where I think one idea that's captivated people is can you talk to your computer? Can you have it build software for you as if you're talking to like an engineering department or an engineer over Slack? And can it just be this sort of isolated text box? And part of the reason we're not excited about that is some of the stuff we've talked about with latency. But then a big piece of reason we're not excited about that is because that comes with giving up a lot of control. It's much harder to be really specific when you're talking in the text box. And if you're necessarily just going to communicate with a thing like you would be communicating

• 2:26:53Speaker 01

  with an engineering department, you're actually abdicating tons of really important decisions to this bot. And this kind of gets at fundamentally what engineering is. I think that some people who are a little bit more removed from engineering might think of it as, you know, the spec is completely written out and then the engineers just come and they just implement. And it's just about making the thing happen in code and making the thing exist. But I think a lot of the best engineering, the engineering we enjoy, involves tons of tiny micro decisions about what exactly you're building and about really hard trade offs between, you know, speed and costs and just all the other things involved in a system.

• 2:27:34Speaker 01

  And we want, as long as humans are actually the ones making, you know, designing the software and the ones specifying what they want to be built, and it's not just like company run by all AIs, we think you'll really want the human in a driver's seat dictating these decisions. And so the jury's still out on kind of what that looks like. I think that, you know, one weird idea for what that could look like is it could look like you can control the level of abstraction you view a codebase at. And you can point at specific parts of a codebase that, like maybe you digest a codebase by looking at it in the form of pseudocode.

• 2:28:15Speaker 01

  And you can actually edit that pseudocode too, and then have changes get made down at the sort of formal programming level. And you can gesture at any piece of logic in your software component of programming. You keep the inflow text editing component of programming. You can even go down into the code. You can go at higher levels of abstraction. Well, also giving you these big productivity gains.

• 2:28:41Lex Fridman?

  It'd be nice if you can go up and down the abstraction stack.

• 2:28:44Speaker 01

  Yeah, and there are a lot of details to figure out there. That's sort of like a fuzzy idea. Time will tell if it actually works, but these principles of of control and speed and the human in the driver's seat, we think are really important.

• 2:28:55Speaker 01

  We think for some things, like Arvind mentioned before, for some styles of programming, you can kind of hand it off chatbot style. You know, if you have a bug that's really well specified, but that's not most of programming. And that's also not most of the programming we think a lot of people value.

• 2:29:10Lex Fridman?

  What about like the fundamental skill of programming? There's a lot of people like young people right now, kind of scared, like thinking, because they like love programming, but they're scared about like, will I be able to have a future if I pursue this career path? Do you think the very skill of programming will change fundamentally?

• 2:29:30Speaker 01

  I actually think this is a really, really exciting time to be building software. Like, we remember what programming was like in, you know, 2013, 2012, whatever it was.

• 2:29:42Speaker 01

  And there was just so much more cruft and boilerplate and, you know, looking up something really gnarly and, you know, that stuff still exists. It's definitely not at zero, but programming today is way more fun than back then. It's like, we're really getting down to the delight concentration and all the things that really draw people to programming, like, for instance, this element of being able to build things really fast and speed and also individual control, like, all those are just being turned up a ton. And so I think it's just gonna be, I think it's gonna be a really, really fun time for people who build software. I think that the skills will probably change too. I think that people's taste and creative ideas will be magnified and it will be less

• 2:30:26Speaker 01

  about, maybe less a little bit about boilerplate text editing, maybe even a little bit less about carefulness, which I think is really important today. If you're a programmer, I think it'll be a lot more fun.

• 2:30:39Lex Fridman?

  What do you guys think?

• 2:30:41Speaker 03

  I agree. I'm very excited to be able to change, like, just. One thing that happened recently was like we wanted to do a relatively big migration to our codebase. We were using async local storage in OGS, which is known to be not very performant. And we wanted to migrate to a context object. And this is a big migration and affects the entire codebase. And Swal and I spent, I don't know, five days working through this, even with today's AI tools. And I am really excited for a future where I can just show a couple of examples. And then the AI applies that to all of the locations. And then it highlights, oh, this is a new example, like, what should I do? And then I show exactly what to do there.

• 2:31:25Speaker 03

  And then that can be done in like 10 minutes. And then you can iterate much, much faster than you can. Then you don't have to think as much upfront and stand at the blackboard and like, think exactly like, how are we going to do this? Because the cost is so high, but you can just try something first and you realize, oh, this is not actually exactly what I want. And then you can change it instantly again after. And so, yeah, I think being a programmer in the future is going to be a lot of fun.

• 2:31:52Speaker 02

  Yeah, I really like that point about it feels like a lot of the time with programming, there are two ways you can go about it. One is like you think really hard, carefully upfront about the best possible way to do it. And then you spend your limited time of engineering to actually implement it. But I must refer just getting in the code and like, you know, taking a crack at it, seeing how it kind of lays out. And then iterating really quickly on that, that feels more fun.

• 2:32:22Lex Fridman?

  Yeah, like just being to generate the boilerplate is great. So you just focus on the difficult design, nuanced, difficult design decisions. Migration, I feel like this is, this is a cool one. Like, it seems like large language model is able to basically translate from one programming language to another or like translate, like migrate in the general sense of what migrate is. But that's in the current moment. So I mean, the fear has to do with like, okay, as these models get better and better, then you're doing less and less creative decisions. And is it going to kind of move to a place where it's, you're operating in the design space of natural language? Where natural language is the main programming language?

• 2:33:03Lex Fridman?

  And I guess I could ask that by way of advice, like if somebody is interested in programming now, what do you think they should learn?

• 2:33:10Lex Fridman?

  Like, you guys started in Java. And I forget, oh, some PHP.

• 2:33:19Speaker 02

  Objective C.

• 2:33:20Lex Fridman?

  Objective C, there you go. I mean, in the end, we all know JavaScript is going to win.

• 2:33:27Lex Fridman?

  And not TypeScript, it's going to be like vanilla JavaScript. It's going to eat the world and maybe a little bit PHP. And I mean, it also brings up the question of like, I think Don Knuth has a this idea that some percent of the population is geeks. And like, there's a particular kind of psychology in mind required for programming. And it feels like more and more that expands. The kind of person that should be able to, can do great programming, might expand.

• 2:33:58Speaker 02

  I think different people do programming for different reasons. But I think the true, maybe like the best programmers

• 2:34:07Speaker 02

  are the ones that really love, just like absolutely love programming. For example, there are folks in our team who literally, when they're, they get back from work, they go and then they boot up Cursor and then they start coding on their side projects for the entire night. And they stay up till 3 AM doing that. And when they're sad, they said,

• 2:34:34Speaker 02

  I just really need to code.

• 2:34:37Speaker 02

  And I think like,

• 2:34:40Speaker 02

  you know, there's, there's that level of programmer where like this obsession and love of programming. I think makes really the best programmers. And I think the, these types of people will really get into the details of how things work.

• 2:34:55Lex Fridman?

  I guess the question I'm asking, that exact program, let's think about that person.

• 2:35:01Lex Fridman?

  When you're, when the super tab, the super awesome praise be the tab is succeeds, you keep pressing tab.

• 2:35:08Speaker 04

  That person in the team loves to curse the tab more than anybody else.

• 2:35:11Speaker 03

  Yeah, and it's also not just like, like pressing tab is like the, just pressing tab, that's like the easy way to say it and the catch, catchphrase, you know? But what you're actually doing when you're pressing tab is that you're, you're injecting intent all the time while you're doing it. You're, you're, sometimes you're rejecting it, sometimes you're typing a few more characters. And, and that's the way that you're, you're sort of shaping the things that's being created. And I, I think programming will change a lot to just what is it that you want to make?

• 2:35:43Speaker 04

  It's sort of higher bandwidth. The communication to the computer just becomes higher and higher bandwidth as opposed to like, like just typing is much lower bandwidth than, than communicating intent.

• 2:35:54Lex Fridman?

  I mean, this goes to your manifesto titled Engineering Genius. We are an applied research lab building extraordinary product of human AI systems. So speaking to this like hybrid element. To start, we're building the engineer of the future, a human AI programmer. That's an order of magnitude more effective than any one engineer. This hybrid engineer will have effortless control over their code base and no low entropy keystrokes. They will iterate at the speed of their judgment, even in the most complex systems. Using a combination of AI and human ingenuity, they will outsmart and out engineer the best pure AI systems. We are a group of researchers and engineers.

• 2:36:38Lex Fridman?

  We build software and models to invent at the edge of what's useful and what's possible. Our work has already improved the lives of hundreds of thousands of programmers. And on the way to that, we'll at least make programming more fun. So thank you for talking today.

• 2:36:52Speaker 03

  Thank you.

• 2:36:53Speaker 01

  Thanks for having us.

• 2:36:54Speaker 04

  Thank you.

• 2:36:54Speaker 01

  Thank you.

• 2:36:56Lex Fridman?

  Thanks for listening to this conversation with Michael, Swale, Arvid and Aman. To support this podcast, please check out our sponsors in the description. And now let me leave you with a random, funny and perhaps profound programming code I saw on Reddit. Nothing is as permanent as a temporary solution that works.

• 2:37:18Lex Fridman?

  Thank you for listening and hope to see you next time.

• 2:37:38Lex Fridman?

  Thank you for listening and hope to see you next time.