The next era of AI coding

1,905 words · about 8 min to read

Historical parallels in technological shifts

0:03 It's so good to see everyone. Thank you for joining us for our first event in this office. It's an exciting time in the world, and we're really glad to be able to discuss the future of software with you all. But before we jump into it, I want to talk a little bit about the place we are standing right now, and its place in technology history. A few decades ago, at the end of the 1970s, in May, the first Star Wars actually premiered here. This used to be a movie theater.

0:32 And Star Wars was an amazing film for many reasons, and a consequential film for many reasons. One of the reasons it was consequential was its place in both film technology history and in film history. And in particular, the team that worked on Star Wars didn't just-- They weren't just great storytellers, they actually innovated on the technology in many ways. For instance, this is a DijkstraFlex, I am told, which is a computer controlled camera system that can repeat the exact same camera moves multiple times. It can shoot models in layers, and it can combine them into a seamless shot.

1:09 And so the original Star Wars used this technique, without humans in the loop, entirely controlling these computers with cameras, to help make the movie a reality, and to help make the sci-fi fantasy that is Star Wars a reality. And I think that this is a great example of how technology can redefine categories, can kind of mark the boundary between a before period in an industry and

The tedium of formal programming languages

1:30 an after period in an industry, and I think we are definitely in this right now with software engineering. And so we're excited to dive into it and talk a little bit about how software has changed. But if we're going to go back again to ancient history, and look at some code, which maybe some of you haven't done in a long time, both as leaders and also maybe some of the engineers on your team are looking at code a little bit less lately. If you'll remember, just a few years ago, the way you built software was entirely by text editing formal programming languages. And so for instance, here we have a very, very simple Python script, where we're creating a list, we're going through it, we're adding to the list, we're then iterating through the list, and we're computing some things about it. But this, this act of writing down logic in the form of formal programming languages was the only way in which humanity could build software until just a few years ago.

2:22 And what's annoying and hard about this? What takes large amounts of time? What racks up hundreds of millions of dollars on a company's R&D budget with this? It's that, one, you really need to take your high level thoughts, the things you would like to build on a computer, and you have to turn them into these little itty bits of logic. You have to really spell everything out exactly for the computer. And so for instance, for the longest time, you've had to write software in if this then that statements, in statements where you're looping over things, in statements where you're saying, "Take this little piece of data over here and put it over here."

2:58 And that's really tedious. You have to be really verbose. And it might be that a feature that can be described in a couple of paragraphs to a human actually turns out to be many tens of thousands of lines of this logic. The other thing that for the longest time has made especially professional software engineering quite

The hidden complexity of massive codebases

3:15 difficult is the weight of the existing logic, because you're not dealing with a simple Python script, you're dealing with tens of millions of lines of code. And I think that this is one of the tragedies of software development, is that all of this complexity is kind of hidden. It makes software feel trivial, and I don't think that this is the case uniformly across engineering disciplines. I think, for instance, if you visit a Gothic cathedral and you look at it, it kind of wears the weight of all it took to build that thing on its sleeve. You can see just how complex the thing is. But with software, since we're serving users, we want to make it feel really simple. And so you just see buttons and just the little bits of information we want a human user to know at any given point in time, and you don't see all of this complexity and logic that exists under the hood. And so product managers, non-technical folks for decades have gone to engineers and asked them to make changes, and they've been pretty frustrated by how long it actually takes to build software.

4:08 And it's because those professional engineers are wrangling the tens of millions of lines of code under the hood, and instead of writing these simple Python

The rapid rise of agent-driven workflows

1 Highlight · Explosion of agent requests vs autocomplete

4:15 files, they're making changes throughout thousands of thousands of files, and having to edit the existing logic. We can look at the data, and we've seen over the course of twenty twenty-five, for instance, that the ratio of tab accepts to agent requests has completely exploded, where the number of agent requests in our product has gone up over fifteen X year over year. And at the start of twenty twenty-five, you were seeing ten X more tab accepts than agent requests, and at this point you see many more agent requests than tab accepts. And that's especially consequential because an agent request is usually a giant body of work, and a tab accept is maybe just a few characters or a few lines of code. And so we've seen this change happen in Cursor over the course of the past year.

4:57 And we are also seeing the start of this third era, this teams era, starting to take hold within certain, especially forward-thinking companies. To cherry pick a forward-thinking company in particular, this is our internal data of Cursor Cursor engineers. But at this point, thirty percent of the PRs within our company are entirely developed end-to-end by an agent with no human intervention, and they're done with an agent that has their own computer, that's running in a cloud environment remotely, that works for many hours or potentially even days on a task end to end. These trends are not just things that show up in startups or mid-market companies. They're showing up in an enterprise setting too, where I think that about a year ago, maybe fifteen to twenty percent of the

Developers as managers of ghost colleagues

2 Highlight · Transitioning from coding to agent management

5:40 code within our enterprise segment was AI generated. At this point, it's about seventy-five percent is entirely being AI generated, and humans just aren't touching the syntax themselves. They're instead delegating to agents. And so what does engineering become as we progress through these stages? Well, for instance, I think in the boundary of this agent era and this teams era, you're seeing that folks are more and more not touching the syntax at all. They're just becoming agent managers.

6:06 And I think the conceptual model to have of your organization as you go from the agent era to the teams era is, for the longest time, you've had this human workforce of a couple thousand engineers working on your software, and now you don't just have a couple thousand engineers working on your software, you have tens of thousands of ghost colleagues working on your software alongside these human collaborators. And both, you want to hire the most intelligent, most price performant agent colleagues to work with you, but also the workflows, the ways in which humans work with the AI and the AIs work with each other, and humans work with each other change a lot too. But we're seeing that folks are becoming agent managers and increasingly

6:44 think of their role as one that's delegating and managing all of these agents working in parallel. Folks are spending much more time on review. You definitely-- There are ways to move through this progression of tab to agents to team which can hurt an organization, and definitely, you can generate lots of code that's unsustainable, that makes bad architecture decisions, that's going to be riddled with bugs. You definitely don't want to do that. And so increasingly, people are spending much more of their time, engineers are spending much more of their time reviewing the work, looking at the syntax itself, looking at build versions of the software, testing it. And so folks are spending a bunch of time in the review phase, and folks are multitasking a lot.

7:23 In the agent era, when you're just sitting there, you're babysitting agents, you're feeding them the next bit of a task, the next bit of a task, and they're running locally on your computer, you're kind of bottlenecked in how many you can handle at once. Maybe you can handle one to three because they're all kind of editing the same version of the code base. As you move more towards the teams model with agents that have their own computer, you can be working with dozens of agent colleagues that are all working on their own task at once, running for a long time

Autonomous long-running agent experiments

7:47 autonomously. And that means a bit more multitasking. That means more parallelism. That means more context switching. That's maybe a little bit of a look into how people are working today, and I also want to tease a little bit at the far future, and this is something that we've experimented with here at Cursor, of what does it look like if you can really get to a world where there's as much self-improvement as

3 Highlight · Autonomous multi-agent browser development experiment

8:08 possible and as little human intervention as possible too? So for instance, we have played around with the idea of developing browsers entirely end-to-end autonomously using agents with no humans in the loop. And you are here seeing the progression of an agent system and an agent team that worked over the course of an entire week with no humans, generated many, many PRs, three million lines of code, and it generated a mostly functional prototype browser. And so you're seeing that on day one, it can't render apple.com well, it can't render this landing page well, and then day two, day three, day four, and then at the end, you actually have a pretty good web rendering system that was developed without humans in the loop entirely autonomously.

8:52 And this experiment is very nascent. This stuff is not ready for prime time. You can see the summary statistics here of the amount of code, the number of concurrent agents on the team that ran at once, the number of tokens that were used, and here you can also see actually a video of the agent team generating files. This is the code base, the files of a code base, and the connections between files being generated over the course of the week. This stuff is very nascent, very experimental, not ready for prime time yet, but we're excited to continue experimenting with pushing the boundaries on the side of how far can you go completely autonomously, and it's helped to inform the product decisions that we make for the teams era of

9:33 product development within Cursor.