Evidence receipt / prediction
Published · transcript-backedSpeaker unverified: prediction
6 Oct 2024 Lex Fridman Podcast #447 – Cursor Team: Future of Programming with AI
“They have good databases now. And I think turbopuffer, which is one of the databases we use, is going to add maybe branching to the write-ahead log.”
— Speaker unverified
Source trail
Everything needed to verify it.
- Speaker
- Speaker unverified
- Attribution
- Not verified from this transcript
- Claim type
- prediction
- Recorded
- 6 Oct 2024
- Publisher
- Lex Fridman Podcast
Transcript context
…languages. The API documentation is not very good and the code across, if I… I googled it for a while. I couldn’t find exactly, there’s a lot of confusing information, and Cursor generated perfectly. I just sit back, I read the code, I was like, “This is correct. I tested it, it’s correct.” I was like, “I want to tip.” I want a button that goes, “Here’s $5.” 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. So there’s this much stronger signal than just accepting the code. You just actually send a strong good job. That and for bug finding, obviously, there’s a lot of people that would pay a huge amount of money for a bug bounty thing, right? You guys think about that? Yeah, it’s a controversial idea inside the company. I think it sort of depends on how much you believe in humanity almost. I think it would be really cool if you spend nothing to try to find a bug. And if it doesn’t find a bug, you spend $0. And then if it does find a bug and you click accept, then it also shows in parentheses like $1. And so you spend $1 to accept the bug. And then of course, there’s a worry like okay, “We spent a lot of computation, maybe people will just copy paste.” I think that’s a worry. Then there is also the worry that introducing money into the product makes it… It doesn’t feel as fun anymore. You have to think about money. And all you want to think about is the code, and so maybe it actually makes more sense to separate it out, and you pay some fee every month, and then you get all of these things for free. But there could be a tipping component which is not like it cost this- Yes, but it still has that dollar symbol. I think it’s fine, but I also see the point where maybe you don’t want to introduce it. Yeah, I was going to say the moment that feels like people do this is when they share it. When they have this fantastic example, they just share it with their friends. 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 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. How much interaction is there between the terminal and the code? How much information is gained from if you run the code in the terminal? Can you do a loop where it runs the code and suggests how to change the code? If the code and runtime gets an error? Is right now there’s separate worlds completely? I know you can do control K inside the terminal to help you write the code. You can use terminal context as well inside of check command K kind of everything. We don’t have the looping part yet, so 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. art yet, so 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. Sure. The background’s pretty cool. I could be 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. I mean, there’s certainly cool solutions there. There’s this new API that is being developed for… It’s not in AWS, but it certainly… I think it’s in PlanetScale. I don’t know if PlanetScale was the first one to you add it. It’s this ability sort of add branches to a database, which is like if you’re working on a feature and you want to test against the broad database, but you don’t actually want to test against the broad database, you could sort of add a branch to the database. And the way they do that is they 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 new things to do. They have good databases now. And I think turbopuffer, which is one of the databases we use, is going to add maybe branching to the write-ahead log. So maybe the AI agents will use branching, they’ll test against some branch, and it’s sort of going to be a requirement for the database to support branching or something. It would be really interesting if you could branch a file system, right? Yeah. I feel like everything needs branching. It’s like- Yeah. Yeah. The problem with the multiverse, right? If you branch on everything that’s like a lot. There’s obviously these super clever algorithms to make sure that you don’t actually use a lot of space or CPU or whatever. 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. AWS is just really, really good. It is really good. Whenever you use an AWS product, you just know that it’s going to work. It might be absolute hell to go through the steps to set it up. Why is the interface so horrible? Because it’s- It’s just so good. It doesn’t need to- It’s the nature of winning. I think it’s exactly. It’s just nature they’re winning. Yeah, yeah. But AWS we can always trust, it will always work. And if there is a problem, it’s probably your problem. Yeah. Okay. Is there some interesting challenges to… You guys are pretty new startup to scaling, to so many people and- Yeah, I think that it has been an interesting journey adding each extra zero to the request per second. You run into all of these with 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 into overflows on our tables and things like that. And then also there have been some custom systems that we’ve built. For instance, our retrieval system for computing, a semantic index of your code base and answering questions about a code base that have, continually, I feel like been one of the trickier things to scale. instance, our retrieval system for computing, a semantic index of your code base and answering questions about a code base that have, continually, I feel like been one of the trickier things to scale. … that have continually, I feel like, been one of the trickier things to scale. I have a few friends who are super senior engineers and one of their lines is, it’s very hard to predict where systems will break when you scale them. You can try to predict in advance, but there’s always something weird that’s going to happen when you add these extras here. You thought through everything, which you didn’t actually think through everything. But I think for that particular system, we’ve… So for concrete details, the thing we do is obviously we upload when… We chunk up all of your code, and then we send up 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. Everything is encrypted. 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. The way, technically, we ended up doing that is, for every single file you can keep this hash, and then for every folder you can keep a hash, which is the hash of all of its children. You can recursively do that until the top. Why do something complicated? One thing you could do is you could keep a hash for every file and 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, and try to reconcile the state between the client and the server. But that introduces absolutely ginormous network overhead both on the client side. Nobody really wants us to hammer their WiFi all the time if you’re using Cursor. But also, it would introduce ginormous overhead on the database. It would be reading these tens of terabytes database, approaching 20 terabytes or something data base every second. That’s just crazy. You definitely don’t want to do that. So what you do, you just try to reconcile the single hash, which is at the root of the project. 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. 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. For most people, most of the time, the hashes match. So it’s like a hierarchical reconciliation- Yeah. … of hashes- Something like that. Yeah, it’s called a Merkle tree. Yeah, Merkle. Yeah. Yeah, this is cool to see that you have to think through all these problems.…
Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.