High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / belief

Published · transcript-backed

Speaker unverified: belief

6 Oct 2024 Lex Fridman Podcast #447 – Cursor Team: Future of Programming with AI

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

— Speaker unverified

Source trail

Everything needed to verify it.

Speaker
Speaker unverified
Attribution
Not verified from this transcript
Claim type
belief
Recorded
6 Oct 2024
Publisher
Lex Fridman Podcast

Transcript context

…The following is a conversation with the founding members of the Cursor team, Michael Truell, Sualeh Asif, Arvid Lunnemark, 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 in designing and engineering complicated and powerful systems. This is the Lex Fridman podcast. To support it, please check out our sponsors in the description. And now, dear friends, here’s Michael, Sualeh, Arvid and Aman. All right, this is awesome. We have Michael, Aman, Sualeh, Arvid here from the Cursor team. First up, big ridiculous question. What’s the point of a code editor? 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 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 “word processor,” the code editor can actually do a lot for you that word processors sort of in the writing space haven’t been able to do for people editing texts there. And so that’s everything from giving you visual differentiation of the actual tokens in the code so you can scan it quickly to letting you navigate around the code base, sort of like you’re navigating around the internet with hyperlinks, you’re going to definitions of things you’re using to error checking to catch rudimentary bugs. 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. I think also a code editor should just be fun. 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. 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 being fast a lot of the time. Fast is fun. Yeah, fast is… That should be a T-shirt. Fundamentally, I think one of the things that draws a lot of people to building stuff on computers is this insane iteration speed, where in other disciplines you might be sort of gate capped by resources or the ability… Even the ability to get a large group together and coding is this amazing thing where it’s you and the computer and that alone, you can build really cool stuff really quickly. esources or the ability… Even the ability to get a large group together and coding is this amazing thing where it’s you and the computer and that alone, you can build really cool stuff really quickly. 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 explanation of your own journey of editors. I think all of you 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? Yeah, so I think a lot of us… Well, all of us were originally [inaudible 00:03:39] users. Pure Vim. Pure Vim. Yeah. No Neovim, 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 code editor in which it was available, and even though I really enjoyed using Vim, just the experience of Copilot 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. And maybe we should explain what Copilot does. It’s a really nice auto complete. 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? When it’s done well, there’s an intimate feeling. There’s probably a better word than intimate, but there’s a cool feeling of holy shit, it gets me. And then there’s an unpleasant feeling when it doesn’t get you. And so there’s that kind of friction. But I would say for a lot of people, the feeling that it gets me overpowers that it doesn’t. And I think actually one of the underrated aspects of Github Copilot is that even when it’s wrong, it’s 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 it gets you. So even when it’s wrong, it’s not that bad. You can sort of iterate and fix it. I mean, the other underrated part of Copilot for me was just the first real AI product. So the first language model consumer product. So Copilot was kind of like the first killer app for LMs. Yeah. And the beta was out in 2021. Right. Okay. So what’s the origin story of Cursor? So around 2020, the scaling loss papers came out 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 looked like you could make these models a lot better if you had more compute and more data. By the way, we’ll probably talk for three to four hours on the topic of scaling loss. But just to summarize, it’s a paper in a set of papers in a set of ideas that say bigger might be better for model size and data size in the realm of machine learning. It’s bigger and better, but predictably better. Okay, that’s another topic of conversation. Yes. Yeah.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.

Search evidence