Raw capture — raw/lessons-from-building-cursor.md

url: https://gist.github.com/8fc5d0c9cd23ee37abb8bd50351b3c1e date_fetched: 2026-07-05 backfilled: true

You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert

Model-building is product-building. Cursor trains its own models (like Composer 1.5) because certain capabilities—semantic search across huge codebases, recursive subagents, self-summarization—can only be learned through RL, not prompted. “If it’s not built into the model, the model won’t be able to use the thing.”

RL infrastructure is a new kind of hard. Training with millions of sandboxes and 100M+ CPU hours per year forces you to build your own orchestration; you can’t just outsource to cloud providers. Monitoring and deploying long-running agents (minutes to days) breaks traditional RPC assumptions. Workflow engines like Temporal and Restate are early answers.

Cloud agents need a step change, not a UI tweak. Today’s cloud agents are a worse version of local agents. To grow usage 1000×, the model must take responsibility for testing its own code and proving correctness. The blocker is “devex”: models silently degrade when services aren’t started in the right order, because no one writes them a clear runbook. Companies will need “devex teams” that document how to boot up a repo for an AI.

Context windows are a solved problem through RL. Instead of prompting a model to summarize, RL incentivizes it to produce summaries that are genuinely useful to its future self. The model also learns to dump old conversations to files and grep them later. “You don’t need a trick.”

Coding got solved in six months. Between March/April and December, the best engineers stopped writing code by hand. This is a “boring fact,” not a provocation. Engineering practice will keep changing with one or two capability jumps every half-year. The next jump: engineers adopt a “managerial instinct,” overseeing agents rather than writing lines.

The browser experiment revealed a qualitative shift. Watching a model build a functional browser—something the speaker says he couldn’t do himself in a month—made it visceral that models are now doing things humans simply cannot. This points toward “self-driving codebases” where you allocate a budget and the codebase manages its own security, tech debt, bugs, and features.

Advice for engineers is pragmatic, not prescriptive. If the codebase lives for years, review every line. If it’s a weekend project, who cares? Artisanal coding will survive in niches, but most engineers already enjoy coding more because boring debugging has vanished.

Pithy and provocative quotes

“It’s not just about have a model that you press Enter and then you have to go to sleep. I think the goal would be you make models where it’s quite engaging to use them and they’re extremely fast, and you type your query and the model does it as fast as possibly can.”

“I think software companies that have been built in the last decade, most of the time if you had to do something really hard, you just bonded off to a provider… I think you can’t do that when you’re doing 100 million plus of CPU compute per year or something like you actually need to think through how exactly are you going to orchestrate the hundreds of thousands of sandboxes or millions of sandboxes that are running at the same time for rl.”

“I don’t think we’re in a world where routing works really well. But in a perfect world you should not have to be picking between many different models. It feels kind of… I don’t know if you use Google, you never think through ah, should I use this fast index or the slow index or the medium index? You just press enter, you forget about it.”

“It should feel like the model wrote the code and it should be the model’s responsibility to figure out if it’s correct or incorrect.”

“You can’t really grow anything by a factor of 1000 by just tweaking the UI. That’s like, you know, small tweaks never really get you factors of 1000. So to get a factor of 1000, something fundamentally has to change about the product, like it has to be a step change.”

“The model never yells at you when the devex is off, the model just kind of silently gets degraded and there’s no big red glaring. The model is yelling at you for fix your devex.”

“In some ways, coding got solved in six months. And I don’t mean it some queasy, inflammatory statement about everyone should be riled up by it. It’s just a boring fact about the world. It’s that six months and coding kind of got solved.”

“The best engineers I know are not writing code by hand anymore.”

“I think for the first time I was thinking, I can’t do this. This is something where I just can’t do it. If you give me Opus or codecs and composer 1.5 and you let me rip for a month on an island, I probably couldn’t make a browser that’s really functional.”

“I’m excited about a world where there’s some world of a self driving code base where you allocate $100,000 on your code base… and the rest of the code base sort of manages itself. What does GitHub look like in that world? What does Git infrastructure look like? I don’t know.”

“If your code base will stay for many years, review every line of code. If your code base is for a weekend, who cares?”

Tools, practices, and methodologies

Composer 1.5 model — A fast, RL-trained coding model positioned between Sonnet 4.5 and Opus 4.5. Use it when you want low-latency, engaging code generation with baked-in skills like semantic search and self-summarization.

RL for tool-use and self-summarization — Instead of prompting a model to use grep or write summaries, train it with RL so that it learns to produce grep queries and summaries that are genuinely useful for its future self. This is how Cursor makes models effective over very long tasks.

Semantic search in large codebases — The Composer model is trained to find relevant code in 1–3 queries rather than tens of greps. This is a capability that only emerges through RL, not prompting.

Self-summarization with file dumps — When the context window fills, the model writes a summary and dumps the previous conversation to a file. It can later grep that file to retrieve past context. RL makes the summaries lossy in the right way—retaining what matters.

Temporal / Restate — Workflow engines for long-running, reliable agents. Temporal (from Uber) and Restate allow you to run agents that take hours or days, with automatic retry if any step fails. The speaker sees these as the right client-server abstraction for agents.

Cloud agents with built-in testing — The next capability jump: agents that run in the cloud, test their own code, and prove correctness before showing you a diff. This shifts responsibility from the human reviewer to the model and could increase cloud agent usage by 1000×.

Devex runbooks for models — Teams should create explicit instructions for how to boot up all services in the right order so that an AI agent can test an app like a human would. Without this, the model silently degrades.

Managerial workflow for engineers — As models improve, engineers will spend more time allocating tasks, reviewing high-level output, and using “managerial instinct” rather than writing code line-by-line.

Self-driving codebase (future concept) — Allocate a daily budget (e.g., $100K) to a codebase, and agents autonomously handle security, tech debt, bug fixes, and feature work. This is a speculative vision, not a current practice.

Unanswered questions and omissions

What are the specific RL algorithms? The speaker explicitly declines to discuss them, calling them “hard to talk about.” The entire training methodology remains a black box.

How does the model “prove” correctness? The talk insists the model should test its own code, but never explains the mechanism. Is it running unit tests, integration tests, doing visual regression, or something else? The hard part of testing—knowing what to test—is left unaddressed.

Why doesn’t model routing work? The speaker says routing confuses users and that Cursor avoids it, but there’s no diagnosis of the underlying problem. Is it a UX issue, a technical limitation, or a model-capability gap?

What did the browser experiment actually teach about agent organization? The interviewer asks about flat vs. hierarchical agent structures, but the speaker only shares the emotional shock of seeing the model do something he couldn’t. The concrete lessons about multi-agent coordination are missing.

How do you prevent a self-driving codebase from going off the rails? The vision of allocating $100K/day with no human review raises obvious questions about quality, security, alignment, and cost control. None of these are addressed.

What about cost, latency, and environmental impact? Running millions of sandboxes and training models with massive RL is expensive and energy-intensive. The talk doesn’t mention trade-offs or accessibility for smaller teams.

“Coding got solved” — what does that actually mean? The statement is deliberately provocative, but it’s never defined. If coding is solved, why are capability jumps still needed? What remains unsolved? The tension is left hanging.

What skills should engineers develop now? The advice boils down to “go along with it” and “review every line if it matters.” There’s no concrete guidance on how to cultivate the “managerial instinct” or which niches will remain artisanal.

The “devex for models” problem is described but not solved. The speaker says companies will need devex teams to write runbooks for AI, but offers no examples, standards, or tooling. How do you maintain such runbooks as the codebase evolves? How do you verify the model follows them correctly?

Job displacement and ethics are barely touched. The talk acknowledges the scariness in passing but offers no reflection on the societal implications of “no one writing code by hand” or self-driving codebases.

Speaker A: Hey, Swaley. So a few days ago, you guys released the Composer 1.5. Congratulations.

Speaker B: Thank you.

Speaker A: So it's a really good model. And can you talk a little bit about it?

Speaker B: So I think it's probably one of the best models that you can use. We think it's somewhere between Sonnet 4.5 and Opus 4.5 in capability

Speaker A: and

Speaker B: almost entirely trained through lots and lots and lots of rl. It's hard to make good models. So, yes, it's not OPUS yet, but I think we'll be making really great models and I think I'm very excited for people to try it. In general, I think we've been trying to make models that are really fast and feel really good to use. It's not just about have a model that you press Enter and then you have to go to sleep. I think the goal would be you make models where it's quite engaging to use them and they're extremely fast, and you type your query and the model does it as fast as possibly can.

Speaker C: So what's the thought process of making your own model versus riding the frontier wave?

Speaker B: I think in general, as the products and the models get a lot more integrated, it's really important to build the features that you care about right into the model itself. So there are certain capabilities where if it's not built into the model, the model won't be able to use the thing. I think in general, you can think of. Previously, there were models that couldn't even use GREP very well. And so part of the things that made the model really good at GREP is URL for making the model extremely good at tools. A classic example of the Composer models are very good at using things like semantic search. So for a very, very, very large code base, the models are exceptionally good at figuring out where to go in one to three queries as opposed to tens of grabs.

Speaker A: And

Speaker B: I don't know, I think those things can only be learned during rl. So, for example, one of the things we really want the model to be good at is like tons of recursive subagents to the point where we can nail your query in almost all queries in less than two to three minutes. And those would require things that are basically training our own model.

Speaker C: Just some of the technical detail of the rl. You could paint a picture how difficult it is.

Speaker B: In some sense, RL is, you know, it's new technology, and because it's a new technology, both the infrastructure, as you're scaling, the thing gets quite complicated. It's hard to point towards exactly. It's hard to talk about exactly the algorithms that are used. So I don't think I can say that. But maybe I can talk a little bit more about the sort of infra on running the code in environments. Those I think are much more fun to talk about there. I think you're running millions of sandboxes and I think there's no. There comes a point when you're making such infrastructure where you can't actually buy the infrastructure from anyone. I think software companies that have been built in the last decade, most of the time if you had to do something really hard, you just bonded off to a provider and there was this great separation of concerns between AWS handles. All of my. And I just built a great software on top. I think you can't do that when you're doing 100 million plus of CPU compute per year or something like you actually need to think through how exactly are you going to orchestrate the hundreds of, you know, hundreds of thousands of sandboxes or millions of sandboxes that are running at the same time for rl.

Speaker C: So help the audience here. So there's a lot of models, right? There's Frontier, you have your composer 1.5. What are some of the decision process that could help?

Speaker B: Currently there's two ways to think through it. One of them is I think one of the goals of one of the things I really want to happen is like you have an input box, you press Enter and you don't have to worry about the model at all. Given that for easy ish queries you can use a really fast model and for things that are really, really, really difficult, it just goes to a very smart model. We try not to do routing at all nowadays. We tried to make it very transparent what we're doing for the user. I think a lot of people get very confused. I don't think we're in a world where routing works really well. But in a perfect world you should not have to be picking between many different models. It feels kind of. I don't know if you use Google, you never think through ah, should I use this fast index or the slow index or the medium index? You just press enter, you forget about it. I think the world should look a lot more like Google than it looks like today.

Speaker C: So we're not quite, quite there yet, right? So what's the mental model that could help us decide which one to use?

Speaker B: I think right now it's mostly a matter of preferences. I think I've seen people who you know, even among the team, there's like a split between the folks who use Composer and then there's folks who use, you know, OPUS or Codecs. It really comes down to personal preferences. I feel like I don't know if I can like rationalize some chain. Yeah, Opus people maybe like talking to the model more about like the plans and, you know, how to think through the problem. And codec people just want to one shot. I don't know. I don't know what their reasoning process is there.

Speaker C: Cool, thanks.

Speaker A: That's great. Yeah. Next, we are really excited about the cloud agents because right now, like when I run agents, I usually have to carry my laptop around. So can you share a bit about the plan and maybe the architecture for the cloud agents?

Speaker B: The way I think through this is I think through them as like capability jumps of like the product plus model combined. And capability jumps is what gets people excited. I think a lot of people got excited after the Opus launch because it felt like a big capability jump from the previous generation. And then people got excited about the original version of Cursor because it felt like a big capability jump on top of Copilot. And we think there's still many more capability jumps to go. And Cloud feels like the next big capability jump that people will use. It's not like the cloud agents today. So Codex Web or cloud code Web or Cursor Web. They both feel like a worse version of the local agent. You have your local agent that's really fast and responsive and does almost everything in five minutes and then you do it on the web. And the setup takes a long time, it's slow to boot up, it's hard to see what the files have changed. It's just like almost everything about it is worse other than you can close your computer, but if you're working from your desk, you don't really close your computer that much. And one of the big problems if you just think like a five year old, is that you press, write the prompt, press enter, come back and you see 1000 line diff and you have no clue whether the 1000 line diff is mergeable or not. And in any way it is your responsibility to figure out is correct or wrong. That feels fundamentally wrong. It should feel like the model wrote the code and it should be the model's responsibility to figure out if it's correct or incorrect. So I would not be surprised. Well, I think Cursor is going to be releasing a product here, which I think I'm very excited about. And once you get the model to actually test its code and prove to you that it's done the thing correctly. We've seen usage of cloud agents go up by factors of 10. One mental model to have is that, vaguely speaking, probably cloud agents to local agents right now have a ratio of 1%. So 1% of all compute is dedicated towards cloud agents. And if you want to be in a future where 90% of compute is dedicated toward cloud agents, means you have to grow cloud agent usage by a factor of 1000. You can't really grow anything by a factor of 1000 by just tweaking the UI. That's like, you know, small tweaks never really get you factors of 1000. So to get a factor of 1000, something fundamentally has to change about the product, like it has to be a step change. And I think models being able to test the code is one of those. But we'll see how it goes. As another note, I think why is testing the code really hard? I think the testing the code is hard because you have this weird devex problem where to be able to test the code correctly, the model needs to be able to use your app like a human would. And for most companies, there's these human devex teams. The human devex teams are responsible for making sure that any new employee that joins, they have perfect running devex. It's really easy to use or even open source really optimizes for making it really easy for people to use that repository and get started. We're in a weird world where sometimes the way companies operate is if you start service B before service A on your first day and everything is crashing and everything is horrible, you go to the person on the side and you go, what the hell is going on? The person on the side goes, you need to start service A before B and everything is fine now and you just remember it and life is great. But the model never yells at you when the devex is off, the model just kind of silently gets degraded and there's no big red glaring. The model is yelling at you for fix your devex. So I think companies in the future will have some devex teams where you tell the model, please, here's all the nice ways of using this repository, even if it gets really complicated, even if you're like stripe or something, here's all the services you need to boot up in this order. You boot them up, then you can spin up this website. Everything should work as expected. You can click around, those will come more and more important.

Speaker C: So what are some of the Lessons learned in building this cloud agent infrastructure seems really challenging that you have so many agents running on the cloud.

Speaker B: I mean the main challenge comes down to what the normal model of the last 10 to 20 years of building infrastructure was. You had, you had RPCs and each RPC would terminate between 100 milliseconds and a second or two. If you have RPCs that take between 100 milliseconds to 2 seconds, you could monitor their P50. P90 was really easy to monitor. It's really easy to understand the input output of what's going inside of the servers. That's unfortunately just really not true with agents. Agents could take anywhere from a few minutes to a few days and the natural variance of it is so high that you have no way of telling if your system is degraded or just the agent takes a long time. Building infrastructure is just very challenging. As another note, for example, what happens if you want to do a deploy for an agent that's running for 12 hours? How do you even replace a server? And so I think one of the things that as companies build longer and longer running agents, they will find it very challenging to figure out how exactly to deploy the agent. And like, what is the natural client server model for something like this? Naturally there's two models. One of them is sort of the cloud code ask model. There is no client server. Everything is a single binary that runs locally, which has many disadvantages. You can't like disaggregate anything outside of, outside of that machine and you can't get any reliability if that machine dies. And so the only way out to get some client server abstraction is

Speaker C: you

Speaker B: go with something that looks like temporal. Temporal is this sort of workflow engine out of Uber generally allows you to run super long running workloads that are like very, very, very reliable. If any step within the middle dies, it can boot it up again. And I think I'd be excited to see there's only like two really good services. I know there's temporal and there's this thing called Restate. But I'd be excited to see more of these in the future as agents become pretty important.

Speaker C: Yeah, because as the model getting smarter and smarter and can run for like minutes and, and then maybe hours, I find it difficult to sometimes get the agent to do the right thing to take advantage of that. Is there any advice you could give us on doing long running? Try to get the agent to run as long as possible.

Speaker B: Getting the agents to run for a long time tends to be, I feel like getting Easier and easier in that I think if you give them a very hard task and there's a clear way of making sure that the task is correct or wrong, the model would be very happy to go on for hours or days. I think one of the great advantages of doing something like the browser experiment was seeing the model, just setting the model with the goal of, hey, build a browser and seeing the model just rip for, I don't know, three days in a row to be able to at least. I think the model made something like three or four thousand commits over that period. Or I guess I shouldn't say the models like the harness, the model and the harness combined. And yeah, I've become less and less worried about if that will happen. And it's more like, I think it'll be very natural. The models will just do it. And yeah, they'll be pretty reliable at it because.

Speaker C: What was the trick though? Because context is still limited, like 200k, maybe a million.

Speaker B: I think this is one of the things we trained into the composer model. And then I think OpenAI is also releasing an endpoint for it. So, you know, almost simultaneously all the. Yeah. One of the things you do during RL is you don't like. Once the model hits the context window, the model just writes out a summary or a document for itself to remember what it was doing. And obviously you can prompt the model to write such a thing, which is what used to happen over all of last year. But nowhere in the prompt is it incentivized to write a really good summary that will be helpful to its future self in the same way that you could have previously asked the model to grep, but there was no incentive to produce grep such that a future version of itself would be able to use those answers to make progress on the problem. I think things like these self summarization endpoints will make the model produce actually helpful versions of summaries that it can then use to continue working on it, no matter if the context window is 200k or a million. So these kind of self summarization, I think as you RL the model to longer and longer tasks, things like self summarization will just make the model, you know, it's kind of like, you know, it's part of the optimization stack. And so the optimization stack is forcing the model to produce things that are very like summaries that are very helpful. And I don't know, composer's getting really

Speaker C: good at it because I want to push back a little bit. It's like the Summarization is lossy. Right. So what's the trick that you have?

Speaker B: You don't need a trick. I think, again, like, I think in rl, if you force the model, like humans, again, have some sort of lossy summarization, but the lossy is not as bad as you think. I think that's because humans are forced to remember things that are important. It. If you remembered everything, it would be horrible. Obviously, over years, whatever RL process that's happening in our brains has forced us to remember things that are really important. We don't really know what's going on in brains, but I think somewhere between summaries, I think there's also other cool ideas. One cool idea would be every time you do some form of compaction summarization, you dump the previous conversation into a file and the model can grab that file every single time it wants to look up a version of it in the past and it can learn to be effective after. RL will force it to learn to grep effectively. So that will just be baked into a version of itself. It's like if it needs to look up a past version of itself, it can just grab the conversations in the past.

Speaker C: This sounds like there's a trick that I could pick up as my workflow too then, right? Because you could basically say by reference, you could point to some data that the model might need later on.

Speaker B: Yeah, I think again, there's some generalization effects where the model will learn to use them, but I think the most powerful version of it will only come if you like to harness this RL to actually really, really, really use the tips and tricks that you're adding effectively.

Speaker A: Cool. Yeah. So I'm going to ask you a question I think every developer really cares about right now. Like last year, we developers are still writing a lot of code, but this year, many people tell me the AI is writing 100% of the code. Where do you think the industry is going one year from now? What do you think will happen?

Speaker B: I mean, in some ways it's kind of crazy. I think March or April, everyone is kind of writing code by hand. In December, no one is writing code by hand. So in some ways, coding got solved in six months. And I don't mean it some queasy, inflammatory statement about everyone should be riled up by it. It's just a boring fact about the world. It's that six months and coding kind of got solved. That doesn't mean engineering is done and there's no engineers anymore or something. But the best engineers I know are not writing code by hand anymore. And that is the way it is. And I would expect that there will be continued changes in the practice of engineering over the course of the next year. There's no reason to expect RL will. I think there's some sort of physical reasons why RL won't immediately deprecate all engineers. But I think outside of, you know, crazy physical limits, I think, you know, probably we'll be able to make the models a lot better. I think we should expect just like one to two capability jumps or every half. So we should expect one to two capability jumps in the models over the next half and then we should probably expect another one to two capability jumps in the half after. And capability jumps look something like the opus moment where it went from you could kind of write the code but had to review every line to like you could kind of write the code and trust that the model would just get it right. And as these capability jumps continue, you should expect people to change their workflow and adapt and that will just keep happening. So I don't know, maybe what is the spicy thing I can say maybe the next one is I think maybe like after something like cloud agents takes off, I wouldn't be surprised if people become much more like managers. Like there's sort of this manager instinct that a lot of ICs don't have that I think will be more polished over time. Like people become better and better at using that manager instinct. Another spicy take is what happens after the first six months of these like cloud agents becoming really good. I'm excited about a world where there's some world of a self driving code base where you allocate $100,000 on your code base, you're plaid and you decide, I will spend $100,000 a day on the code base. Sort of like $30 million a year is not that much compared to the R and D cost. And for the 100,000, 7% of it is spent on security and 12% of it is on, you know, removing, you know, tech debt. And 25% is finding bugs and 50% of it is handling issues on the backlog or something. And the rest of the code base sort of manages itself. What does GitHub look like in that world? What does Git infrastructure look like? I don't know. But I think there's sort of this force of technology that's pushing us all forward. And in that world I, I'd be super excited to see what that product looks like.

Speaker C: So you mentioned about the Managerial instinct that we all have. You recently run this experiment with tons of agents developing a web browser. From what I understand, you guys try a lot of different technique in the beginning. So you have the flat organization and you have hierarchical. Is there anything that surprised you in that process? What did you learn from it?

Speaker B: I mean, in some world I found the browser experiment, or in general things like making a browser as very, very, very surprising. I think everyone should have found it way more surprising than they did. I think. Yeah, before, you know, somewhere internally, deep down, even though I knew the models were getting really smart and every time you asked me intellectually I knew they were getting smart, deep down I was thinking, well, you know, they kind of plumb these RPC calls. You know, you put it through some proto and like they do all this stuff that I can do, but they do it a little faster. Like that was my mental model of how the agents worked was like they do whatever I do, but a little faster. It's like, like that is kind of what we use them for. But for the browser, I think for the first time I was thinking, I can't do this. This is something where I just can't do it. If you give me Opus or codecs and composer 1.5 and you let me rip for a month on an island, I probably couldn't make a browser that's really functional. It's kind of hard. Like there's going from HTML to parsing the css, like finding the right layout rules, what exactly the architecture should be. How does that all get passed into the rendering engine? I don't know. It's kind of hard. And yeah, for the first time I could see the model doing things that are just actually queasy, just batshit crazy. And you were thinking, wow, the world will be a very different place as the models get a lot better. So I think the harnesses are still just like in these experimental phases where we're trying out different ideas, we don't know exactly what's going to land, but probably what's going to land is some version of this queasy self driving code base where at some point you're like, the models are good enough where they just commit code to the code base and there's no point of stopping them. For human review, that seems kind of an unnecessary blocker. But again, I think the other way to think through this for now is a very boring answer. It's like super, super, super lame and boring. Which is if your code base will stay for many years, review every line of code. If your code base is for a weekend, who cares?

Speaker A: Thank you for sharing. That's super interesting. So the model is getting better and better. It's really exciting and also really scary for a lot of engineers. Do you have any advice for engineers who want to stay ahead so they can be competitive in the future?

Speaker B: I think it's like, I don't know. In some ways, it's kind of exciting. In some ways, I think you just. The art of engineering is changing, and you kind of go along with it. I don't have some great meta advice. I think, for people who really like artisanally writing code, I think there will be areas of the code base where artisanally writing code is still very important. And then if you really write, you know, like writing kernels or something, I think kernels are probably going away, actually, maybe something else. You know, there exists something where, like, artisan writing code makes a lot of sense, and then there's a lot of places which will be mostly written by models. And, you know, I think a lot of people actually enjoy coding more now. Like, most engineers I know like coding more than they used to in the past, because a lot of really boring aspects like debugging for, like, hours and hours and hours for a bug has just gone away.