How Cursor uses Cursor

0:00 For sure. >> Awesome. Well, it's great to meet you all. I'm really excited to do this session today and share a little bit about how we built Cursor internally using Cursor. Uh my name is Jed Simson, I'm a field engineer here at Cursor. Uh my job revolves centrally around doing enablement sessions with many of our enterprise customers and working with our community organizations to get people excited about Cursor and share kind of what we've been working on and

0:28 how you can best use Cursor. The goal for today will give you we need to give you a little bit of insight on best practices and how we apply them at our organization and then we'll do a Q&A towards the end where you can ask any questions and we'll try and reveal as much as we can about what's what's going on here. We'll kind of first start I don't know. We're just getting everyone aligned on working with Cursor and and what different options there are to interact

0:55 with the Cursor agents. If you haven't used Cursor previously, it's an agentic software engineering platform covering multiple different mediums available at cursor.com/download. We'd highly recommend if you haven't used it just go ahead and getting it set set up and and hopefully following along with some of the things that we'll talk about today and then trying it down on your own. As an update for anyone who's maybe hasn't been up to date with what we've been

1:16 releasing, there's lots of new exciting things coming out with Cursor. We're still maintaining our IDE as a first class product, but there are some advancements that are coming out of that primarily with a focus on agentic development in the future where you're more of managing agents instead of working within singular code files. We're also investing extremely heavily into our cloud agent platform including adding automations on top of that where you can create event-driven cloud agents to respond to different actions

1:46 in your software development life cycle. We're also supporting our CLI as a first class product where it's going to have feature parity with the IDE and be another great option for working with her agents. Lastly, the two things I would recommend checking out are BugBug code review.

2:02 It's kind of a we're leading the space in terms of code review and giving you the best experience to integrate with your existing remote code hosting environment and really only surfacing the highest priority issues for your agents to resolve. And then lastly, if you are a JetBrains user, we have a partnership with with their IDEs where you can use the cursor agent using their ACP. But we'll dive into the primary content today with focus on how has software engineering What is your team doing and how can you

2:31 maybe apply this to your own workflows or engineering organizations? Where we'll start is actually talking about how a software engine an engineering team has developed over time. And so, um if you think about a traditional team, oftentimes it's going to include multiple different specialties and roles including people who specialize in the front end, back end, quality assurance, testing, product manager and their part handing off different parts of the project. And traditionally, you're looking at a a 10

3:01 to 1 developer to feature ratio ratio. Um as you kind of have previously seen 3 to 1 ratios, but now with cursor and specifically with our team, we're kind of looking at a 1 to 1 developer to feature ratio. And and what that means is that one person with tools provided by cursor now has the agency and capability to cover all different parts of the software development development life cycle and all the different specialties that exist within that.

3:24 And a good example of that is that someone who might be an expert in one particular programming language or one particular parts of of your tech stack. For example, it could be a very good front end in front end engineer, all of a sudden has the capability with cursor agents to be a back end specialist, be really good at testing, uh be really good at UI experimentation and product management and doesn't have to rely necessarily on a much broader

3:46 team for that. And the benefit here is that uh you know, as you continue to maintain your your team is that each individual person is able to produce a lot more code and contribute to the product in an extremely meaningful way without having to wait for potential other hand-offs.

4:01 As we continue to develop the agentic experience what that could look like in the future as a world where a singular engineer is managing a team of agents that are all working on different parts of the code base and pushing uh many features at a very high rate. And so looking at kind of exponential gains moving forward.

4:21 Looking at the IDE itself, right? This is kind of where we started with IDEs coming around in the '60s and '70s giving developers a way to interact with their code in a meaningful way writing abstractions over existing like programming languages. Right? Since then there's been a lot of improvements. Where we launched with Cursor is kind of focusing on this in-file experience working with our tab model to really kind of augment human engineers and build on top of their engineering expertise.

4:50 And where we've continued to move as models have improved is more focusing on on this agent view over here, right? And so Cursor for the past few years has kind of been a very similar code editing experience to what many engineers are familiar with or learned in school where they're looking at files and then using the agent almost as an assistant to augment their existing knowledge. Where we're moving with Cursor 3 and our continued product roadmap is a world in which you might not be focused

5:17 necessarily on on code files directly. And part of the development process that went into this new product is thinking about what are the most important features of an IDE that you will need to have taking up most of your screen real estate in a world where agents are writing a lot of code and we can verify that that code is actually correct. And what we landed on through a lot of experimentation is that engineers then need to have access to all of the

5:40 different agents via very nice interface where they can view all of the different repositories Um, agents working across the cloud and on their local machine. Uh, and they need a a large amount of space to actually chat with their agents, view the code that they're producing, and then review the outcomes, right? And so, an outcome we traditionally think of like a line of code, uh, but an outcome in a world where agents are kind of driving a lot of the engineering could be things like demos and artifacts uh, that allow you

6:08 to verify the functionality of your product, and also be uh, a good participant in the review process. And what we're seeing as engineers at Cursor continue to develop more and more code and use agents more often uh, with their engineering process uh, is that there's a much higher burden on the review team uh, to go through and review all that code. And so, we're working on building solutions that solve all the different bottlenecks that can slow down

6:30 the engineering process. Here's another example of how software engineering has kind of changed in this world with agents. Um, this is an example of using our Slack integration. Uh, where instead of creating a ticket, going and assigning an engineer, and and having someone actually make a change to the code base, instead what's happening here uh, is we wanted to make a change to our landing page, and one of our engineers said, "Hey, @cursor uh, as a almost like a co-worker in Slack, can

6:59 you go make this change and create a pull request?" And the outcome is Cursor actually responding in this conversation, giving a summary of what changes have been made, and then creating a pull request that can then be reviewed and merge, right? And so, this is a pretty explicit example of speeding up the development process specifically, um, where you can use Cursor cloud agents to be be a co-worker that can assist assist you in your development.

7:26 Looking more into this asynchronous world, uh, cloud agents are going to be a primary focus with in Cursor, and have really ex- usage over the past couple months. We're focusing on building a team of workers that can all coordinate with each other uh, and access multiple parts of your code base and have the capabilities to work without you having to micromanage your agents. And so the biggest way to think about the distinction between local development and asynchronous cloud agent development is with local

7:55 development, you're going to be very involved with the agent. You're going to be seeing responses very quickly and providing feedback, eventually building plans in a very synchronous manner with the agent. With asynchronous agents, you're going to build an initial prompt or initial plan, hand that off and the expectation is the agent that the agent is going to be able to work through problems and be able to kind of make assumptions on its own that will lead to

8:14 a successful outcome. Here's a graph that we really like to show. This looks into some data of, you know, how PRs have changed and how velocity has has improved over time as our cloud agents product has improved. And so this is when we released a product called Cursor Cloud Agent Artifacts, which I'll show a video of a little bit later in the presentation. But it's the feature if you've used cloud agents where these agents will actually have the ability to

8:42 build your project locally in their virtual environments and give you a really easy way to review and and basically approve changes made by a cloud agent. And since that was released and we have more observability into what cloud agents are doing, the percentage of PRs being merged by cloud agents has improved by by 3x, right? And we expect this number to actually continue to increase if it continues with current trends where most of our our code is

9:06 actually by cloud agents. I believe actually cloud agent written code surpassed code written in the Cursor IDE, right? So lots of code is being generated, lots of code is being reviewed, and with things like artifacts, we have the observability to make sure that code is correct.

9:33 This is another graph just kind of showing cloud agent usage over time, right? So previous graph we're looking at the percentage of PRs that have been merged. As we've been continuing to develop the product, we're seeing kind of an exponential increase in just the amount of experimentation and and coding we're able to do with cloud agents.

9:50 And through the first, you know, third of April, we're expecting to surpass March by by quite a bit. A big advantage here is that you also have the ability to experiment and prototype with pretty low overhead, right? If you have a couple of different ideas for how you want to build a feature or build out a new interface, the solution within Cursor is just to deploy a team of cloud agents, potentially using different models, sub agents, and approaches to build out

10:16 different prototypes that you then can compare and choose which one you want to move forward with, right? And so, with cloud agents, you really aren't kind of pigeonholed into one development process where you're isolated to your your local machine. Instead, you can have almost like a team of engineers working via cloud agents to help you meet your your long-term outcome.

10:37 A key part of the development process at Cursor is using integrations. And so, here is an inside look into our tech stack and kind of what we use at different points in the software development life cycle. Our source of truth for tracking feature development, where we have a built-in integration where you can deploy agents directly from tickets, as well as use the linear MCP to have Cursor update your tickets and manage that process.

11:05 A lot of our features are integrated with GitHub, where we have bug bot commenting directly on pull requests, where we're working in Slack, where we're actually delegating tasks to Cursor as an external account, where we can have Cursor go and launch cloud agents directly in Slack in conversations, and that's tickets in Linear and then go use external assist to go find errors and and actually complete and build a pull request that is then uh, submitted to

11:30 GitHub. For design, our team primarily uses Cursor in Figma and leverages our Figma plugin to draw static mocks from Figma, bring them directly into Cursor, and actually bridge the gap between engineering and design. And when I mentioned that teams are able to get more agency and singular developers are able to do more with Cursor, uh, designers are also able to do that in the same way. Uh, where a designer might not have to rely on an engineering team to actually get

11:55 something done. Rather, they can outsource some of the code execution to Cursor and really bridge that gap and ease the friction that normally happens with the design to engineering handoff. We're also seeing with other teams that are more on the non-technical side or operations side of the company, uh, they're actually using Cursor to build internal applications and do analysis that would have previously taken a long time to do via other applications.

12:20 A great example of this is our accounting and in revenue management team actually uses Cursor, uh, to go and investigate accounting practices and also build internal applications that are still processes. The last integration that's fairly important at Cursor, uh, is is Datadog. Uh, this is where engineers who are doing any type of debugging or resolving customer concerns can use the Datadog MCP within Cursor to really easily find information in logs that's helpful for

12:49 for resolving, uh, outstanding tickets. So, all of this in conjunction is really helps every engineer be more productive, uh, and also increases the velocity at which they're able to ship code. We talked about this a little bit about when we're going over the different mediums which you can use Cursor, uh, but automations is a recent release that has opened a lot of gates for our team where we can have event-driven cloud agents that respond to events such as PagerDuty, uh, pages, issues being

13:18 opened in linear, or CI/CD pipelines failing within GitHub. And so, cloud agents can work synchronously with an engineer to investigate or incident or even potentially respond faster. And with the power of cloud agents within cursor, they actually have the ability to write code and then potentially submit a pull request to GitHub that can then be resolved and merged into your your main branch. So, very exciting opportunity to have more customization for how you're using cloud agents and also have them

13:46 automatically run without a manual user deployment. Awesome. For this next segment, we'll focus more on code generation and what tools cursor is using specifically to increase the velocity at which we're shipping code in this kind of new world of software engineering.

14:06 If you're interested in reading our CEO's take on all of this, we recently released an article I believe in March called the third kind of era of software development where where Michael actually goes in detail kind of where we're at in terms of and how that is actually influencing what we do at Ultimately, however, there is still a fairly simple process that we recommend for any engineer using cursor to to follow where you're really starting with ask mode and plan mode to

14:37 work with the agent and build up a strong layer of context that the agent can then take into the execution phase and successfully build a final outcome. The biggest mistake I often see with cursor is to try and jump straight into working with an agent or a cloud agent and not going through this process of planning. And often what will happen is the agent will potentially make a decision that the engineer did not intend intend for or do too much or too

15:01 little. In which case, you then have to go and rip and replace code which can become you know, expensive in terms of the time you have to spend working with the agent, but also more expensive in terms of the amount of tokens that you need to use. And so, following this simple workflow is going to help you effectively manage your tokens and help you get a much higher quality outputs at the end of the software development process here. The biggest decision you likely need to

15:26 make when you're going through this flow is deciding if you're going to do local development via the agent or remote development during the cloud. And what we're seeing is that as cloud agents continue to improve, uh most engineers at Cursor are actually skewing towards this direction.

15:41 Rather hand something off to a cloud agent and review the artifacts that it produces instead of walking the agent through um the local development process. Once things are built, we have a set of tools such as debug mode and bug bot uh that really make it easy to follow a an extremely structured process um to find and resolve bugs fairly quickly um in in a much faster way than if you were to do that manually.

16:09 And it sounds like the Wi-Fi is cutting a little bit here, so I'll try and, you know, make sure to be a little bit slower and and go through and review some of these things as well. One important part as well um for Cursor is building up a shared knowledge and context for our team. One thing that's really important is that if a singular engineer has a really good development environments and a really good infrastruc- tools skills and stuff agents for Cursor.

16:39 We want to make sure that's easy. So, we've invested quite a bit of time in building out a marketplace uh where third-party providers can put their skills and MCPs in one place for users to use. Uh but also if you have a team of engineers, you can build out custom uh plugins that can then be deployed across the team. So, allowing for easy sharing and and discoverability. Cursor originally, right, is meant more of as a local development environment. Um but one of our priorities moving

17:02 forward as we continue to build out cloud agents uh is that we want people to be able to really easily share their agents and their configurations uh across an organization. The key to unlock that is focusing on parallelism and then scaling that.

17:19 And so as we're mentioning, you have different ways of doing this with local development where you can use our existing skills, which is best of N, where you can potentially have multiple agents operating on the same prompt at the same time. Utilizing work trees and then also just using work trees to have agents almost functionally on separate branches on your local machine. But then also leveraging cloud agent development to delegate specific tickets to certain cloud agents and then having

17:45 those go through and create artifacts that you can then review in your browser or in your IDE, and then pairing that with tools like automations and bug bot so that you can have some verifiability and observability into the quality of the code that's being produced. Here's another example for our head of developer relations of when we actually migrating our entire content management system to raw code and markdown and built it kind of from scratch using hundreds of agents and a couple of

18:23 hundred dollars in tokens, right? And so if you can be organized and manage your agents in an environment like cursor, you will have an extremely powerful tool to write, you know, many thousands of lines or even hundreds of thousands of lines of code in an effective and in managed way.

18:41 With cursor, part of building that shared knowledge context where you have all of your skills, rules, and sub-agents successfully configured, and you're also able to manage your your agents in one place in cursor, you can accomplish like pretty large tasks that you otherwise wouldn't be able to do.

19:02 Cool. This is a little bit of an insight into the lines of code added with cursor and how that has exponentially increased as we've, uh you know, built out new features and kind of unlocked the the review side of things. Uh here you can see human lines of code and AI lines of code contributed to our code base over time. Uh I believe about in in January, right, is when we started to see that AI lines of code added uh were significantly outpacing human lines. And then in March

19:30 is really where uh we saw a a massive unlock where we're we're now at about 99% of code generated uh is generated using cloud agents and AI agents in the IDE. Um and we have a lot of trust and verifiability to make sure that that code is actually um correct using tools like BugBot. And then also still pretty significantly on human review to make sure that code is high quality.

19:57 But as you can see, uh we expect is this this graph kind of continue climbing, right? As as we continue to add more engineers to our team, build out more products, um but then also continue to just improve our harness to make sure that um agents are writing the highest possible code.

20:20 Amazing. So, I'll get into some of the the research side of our company. Uh one area we are heavily invested in is long-running asynchronous agents. And these are agents that are going to be running potentially for many days uh or even weeks where they are designed to work without much human input uh and kind of resolve challenges on on their own.

20:40 And so, some examples of of how this can work is that you can have a long-running asynchronous agent that is assigned to build a product will have a very large amount of context and a lot of initial input from an engineer. But ultimately, the goal is to build a product from zero to one and cover all elements from planning to execution to testing and even deployment.

21:00 For larger organizations, this is extremely useful for things like large refactors where you might need to go across an entire code base and upgrade um a language or upgrade different dependencies and you want to make sure that agent has a large amount of context and is able to handle right potentially thousands of files of changes. And then another kind of technical challenge to this this this this feature is you need to be able to manage large

21:23 amounts of context and also coordinate between different agents, right? And so this is where you start seeing features like sub agents become extremely useful. Where you might have a singular orchestrator agent that is almost like the manager then delegating individual tasks to a team of sub agents, right? And this is almost mirroring a traditional software engineering team where you have a singular agent kind of dividing and conquering and building out and tackling these massive large projects

21:49 by by separating context into manageable chunks. And so within cursor regardless of whether or not you're in the traditional IDE or the agent view, you'll have a really enhanced design experience where you can open up a browser, view your local projects and then give context directly to the agents based on the elements that you're working with or just visual design components. And so this is kind of how we're thinking about bridging the gap between design and engineering.

22:22 Where in the future you potentially you know don't have designers and you don't have software engineers rather you just have contributors to the products who have capabilities kind of do all these different things and can focus really on the creative side of product development which is figuring out exactly what users wants and how we can kind of best deliver that to them.

22:41 And with cursor right instead of using kind of different platforms to manage your design presentations and code. Instead this just relies on code as your source of truth and can reduce friction during handoffs between engineers and design teams.

23:01 Amazing. Well we'll jump into focusing on how we handle code review and testing at Cursor. Um ultimately, it's going to follow fairly traditional paths and just obviously with a lot of AI augmentation uh during those processes. The first kind of tool is at the the local level when you're actually doing your development. We built a lot of tools into the IDE that can help you give a sanity check uh to make sure that your code uh kind of meets our existing

23:26 standards. Uh but then as well as if there are bugs that are surfaced or potential issues, you can use debug mode and agent mode to effectively go through and have the agent work with you as a as a structured companion and pair programmer while finding issues. And so personally, I found that debug mode is capable of resolving most tasks. And even if things are really complex and not resolvable by an agent, debug mode helps me organize my thoughts and and

23:50 better diagnose a problem so that I can resolve it manually if I need to. Bug Bot is going to be an extremely important factor in this process. Uh and we're seeing a very high-level of growth with our enterprise customers for Bug Bot and growth at Cursor as well. The way that you're going to deploy Bug Bot uh is on a pull request. You comments uh for the agent to review and so adding comments and then fixing them.

24:20 Uh or you can also just work with a Cursor Cloud agent directly within your pull request. And so if I was curious about maybe a decision that the agent made uh or potentially I want the agent to resolve a merge conflict if I have that, I could say, "Hey at Cursor, can you do this thing?" Uh and it will respond with another comment. Or you can also challenge its logic on certain comments. And so if if Bug Bot, you know, suggests an edit and I disagree or want to better understand how that works, I can respond to the

24:41 comment, "Hey at Cursor, can you explain this and provide the the lines of code that back up your decision?" Uh and in the same way that if you commented that to a uh you know, teammate, uh Cursor's going to respond. The outcome of Bug Bot is going to be a series of comments, and so this is what that looks like. You're going to have options to go and fix that within Cursor or fix on the web.

25:06 Related to our increase in cloud agent usage, I would say that most engineers at Cursor are probably going through this process, where instead of actually going in and locally making changes, rather they're just delegating this task to a cloud agent and having the cloud agent go and resolve and implement this code, and then either submit the new code as a commit on the existing pull request or creating a stack. You are creating a new new pull request

25:30 on top of this. A very exciting feature that we released recently is BugBot auto fix, and this is kind of the the next step in BugBot's evolution, where we are closing the loop between finding errors and resolving them. And so instead of just surfacing errors and relying on you to go and fix them, you have the ability to turn on BugBot auto fix, where a cloud agent will be deployed if BugBot detects a potential problem, that will then go through

25:58 resolve it, write new code, and if it's a false positive, and then and then push that that that new commit. A key focus for the BugBot team is focusing on avoiding noise with both pull requests. And so one thing we have noticed that could potentially be a problem for engineers is if you have a model review your code and it leaves a lot of unnecessary semantic comments, that can actually slow down the development process and have zero impact on on bugs that make it production or

26:23 actually functionality of the product. And so BugBot is truly focused on only finding finding the most severe issues and and identifying things that will have an impact for your end user. This is a a graph and a a look into how BugBot is being used at Cursor, right?

26:43 And so you can see as as BugBot has started to be adopted and we've started tracking analytics more and more for how BugBot operates, it's actually unlocked our ability to write more PRs, and we continue to expect that to increase, right? And so the the theme for all of these graphs is that as our agents continue to improve and we make developments within our harness and our and our products, um our amount of code that we're generating and able to review is going up and to the right.

27:10 The important thing to note here is that lines of code generated and our ability to review code is extremely related. Um if either one of those decline, right, you'd see a decline in the other. Um if we're generating a lot of code but not able to review it fast enough, right, that's a bottleneck that creates a a problem and ultimately slows down our velocity. And so that is why Cursor is focused on the entire process, uh not just a singular aspect of code

27:34 generation or code review. We're kind of building everything in tandem to make sure you have a smooth and and cohesive experience. This is also a graph that was released as part of uh the most recent iteration from the BugBot team. Um it's actually very exciting.

27:51 As we find more bugs within our running and are able to be more accurate in in in what things we are surfacing, we're actually seeing a higher resolution rate. Right? And so often times uh when people think about bug review, there there's basically two different directions you can go. You can increase the amount of bugs that um an agent surfaces or you can decrease that. Often times if you increase the number of bugs that an agent surfaces, um less of them

28:15 will be resolved because they'll be perceived as as less important. But we're actually seeing the opposite of that with BugBot. That as BugBot exposes more problems, uh it's actually finding important problems. And so engineers are going through and taking the effort to resolve those and and validating them as actual um problems that need to be solved.

28:38 Another important aspect is the ability to review the work that your agents are doing. And so when I was mentioning cloud agent artifacts, this is what I mean. Uh when you assign a ticket or a task to a cloud agent, you're not just going to get a bunch of code that you then have to review.

28:53 Rather, you're going to get pictures of your application actually running locally, and then videos of the agent going through and clicking through your application, testing those workflows, and verifying verifying the product as if it was an end user. Right? And so, historically, you might think of a software team where you design the product, you hand it off to a team that's then going to go in look for edge cases and test them as if they were a user. With Cursor, we can kind of automate

29:19 that process and allow the agent to do a lot more testing and do it at a very high level of accuracy. Amazing. We'll shift into the discussion about models and how we are thinking about different models within Cursor, specifically focusing on Composer 2 and the team here that's focused on machine learning and building the best best possible software engineering experience, while also talking about how different models from other providers fit into our development life cycle.

29:56 When you're working with multiple agents and across multiple different domains in your code base, you should be leveraging multiple models at different points in that process. The way that we like to break this down at Cursor, if we think back to that core development flow, is that we have a research and planning phase, we have an execution phase, and then we have a review phase. And so, at the research and planning phase, this is where you're going to be using ask mode and plan mode. This is where you're going to be

30:24 wanting to use your highest powered models. So, models like GPT-5.3, GPT-5.4, Opus-4.6, and also Composer 2 here, right? And this is where you'll want to have a deep code base understanding, make sure that your agents are coordinating all of their sub-agents and exploring all the different portions of the code base to give you the best possible context and and plan to continue with.

30:48 I highly recommend kind of using your most powerful models at the research and planning phase because this is where you're going to get the the most kind of like output for the investment you make here. If you get your plan correct and can guide agent from start, you're going to get a much better outcome once you actually start writing code.

31:06 And this is a you know, a common pattern we see with engineers at Cursor, right? It's kind of before we had plan mode, people were already doing this just with kind of custom prompts and skills for the agent to work with, but once we codified plan mode into an actual feature within Cursor, it was the the fastest adopted feature I believe we've we've ever had and it's kind of the guiding principle for like how each you know, new feature development process

31:27 happens at at Cursor. Within that research and planning mode, your agents are are going to be able to spin off sub agents that will be able to divide up context in this allows you to have more control over each individual model. And so even if you start with GPT-5.4 as your overarching line of like planning manager, that agent's going to have the ability to delegate tasks to Gemini 3 Flash, Composer 2, you know, Opus, whatever model it might be, you can make sure to do that. And what we found is that often times

31:57 people have you know, have personal preferences for what domains agents are best at, but what we've seen at Cursor is that we usually use models like GPT-5.3 and 5.4 for things like debugging and potentially planning. For front end tasks, it's very popular popular to use Gemini 3.1 for things. For some complex tasks, it's usually use Opus 4.6. And then Composer 2 is kind of like a nice general catch all model where it can handle all of those tasks and do so in an extremely efficient and fast way.

32:28 Once you get your plan effectively handled, then we get into the execution mode where we have to make a decision if we want to continue locally or if we want to potentially hand this off to a cloud agent. And depending on what task you're working on, right, that's where model choice is going to become super important. If you're working across multiple files and have an extremely complex task, you want to make sure to use one of those frontier reasoning models so that the agent can work through problems.

32:51 Uh but if you're if you're doing something simple such as changing where a button is on a page or or maybe adding a simple test case, that might be a really good example to use a a powered more affordable models that we can ask extremely quickly and get that merged into your code base as fast as possible.

33:11 The last phase is going to be that debugging review. Um with BugBug, we're going to handle most of the model selection for you there. Um but with debug mode, you have the opportunity to choose between different models. Um and what I'd recommend is is think about the personality that each agent has. And so for debugging, I often like to use GPT 5.4 because it gives a little bit more concise responses and I think it's a little bit more granular about how it

33:32 approaches um bug resolution. Um but Opus 6 and Sonnet are also going to give great explanations and the process. Again, Composer 2 is also a great option. Um it's going to deliver an extremely high level of intelligence and be extremely fast with the way it responds. Looking at Composer 2 specifically, um if you look at third-party benchmarks, where it's going to sit in terms of intelligence is between GPT 5.4 and Opus 4.6. And so delivering an extremely uh

34:00 high level of code execution while also operating at a very fast token delivery speed. So Composer 2 fast goes in about 200 tokens per second and you'll notice a an extremely meaningful difference if you're using Composer 2 uh versus the GPT and and Claude models.

34:18 The biggest and most important distinction here is that you get a similar level of intelligence to frontier level models very fast speeds um but you also get a very competitive price. And so we're able to serve Composer 2 uh at almost 10 times less, right, than Opus 4.6 faster or even even more than that in some cases.

34:36 Looking at this graph over here, that also becomes extremely evident. Um the Composer 2 sits at kind of like a Goldilocks spot over here, uh where we're able to get a a really high level of code execution, uh but then a a lower cost. The way that this is able to be is able to be accomplished is because Composer 2 um is a model that's focused on post-training and reinforcement learning, uh meaning that it is truly an expert at software engineering, um and it's a master of

35:01 one, not all, right? If you try and take Composer 2 and apply it to general knowledge tasks in in the legal settings or financial settings, right, it is not going to be the best model, um but if you apply it to software engineering, it's going to compete with the best models out there and do so at an extremely fast rate, because it has much fewer parameters than some of these general knowledge models like GPT and Opus.

35:22 There's a lot of very exciting technical details into how Composer 2 was actually trained and how that team approaches model development, that exists in a white paper that was published uh a couple of weeks weeks ago, um that dives extremely deeply into into what decisions were made and how we were able to get those um cost and speed improvements compared to models out there.

35:44 I kind of looking at top frontier models side by side in terms of spend efficiency, um I think this is a good way to think about a models especially you can serve tokens and and trying to conserve costs, is that if you think about you know, how many tokens do I get for every $100 I spend? If you're using a model like Composer 2, you're going to get a very high level of intelligence, but just have a you know, much longer amount of time that you can work with

36:10 the agents. Additionally, a big benefit here is that you need to think about how each model approaches its effort level and gives a certain task. And so, with different models, they're going to consume different amounts of tokens for different tasks based on how much reasoning they do. Um Composer 2 is a nice balance of this where it is still doing a lot of reasoning, um but it's not going to unnecessarily consume tokens, um whereas kind of with the Claude and GPT models, uh often times

36:33 are designed again for general knowledge tasks, they're going to consider a a lot of potential inputs and go through a very lengthy reasoning process that that consumes tokens during during that process. Some tips for token efficiency that our team follows, um that are good to share with the group here. Um there are a lot of things that Cursor does behind the scenes to actually manage your context for you. And so, an important distinction for why our agent harness is very effective, um compared to some of

37:02 the native environments for for models, is that we're doing a lot of behind-the-scenes caching. It's very efficient, and anytime you submit a prompt within a singular agent session, we're caching those tokens and kind of reusing them over time during that session, giving you some nice token savings there. We're also doing dynamic context discovery, where you're going to have access to all of your different MCP tools, skills, and rules in one place, um but they're not always necessarily

37:24 going to be included in the context window each time, giving you some token savings. And then, the Cursor indexing mechanism behind the scenes is allowing the agent to perform semantic search and pull in the most relevant files and lines of code to each task that you submit to Cursor.

37:39 Some things that you can do on your side to manage your spend and token efficiency is choose the right model for each job, and to use plan mode before executing. And when I talk about choosing the right model for each job, Cursor's in a unique position where we've designed the product to let you switch your model um during an agent agent session and between different models. And you should think of your your models like a tool belt, right? Um where some of them are going to be extremely powerful, like

38:06 jackhammer-style tools that are going to solve your most complex issues, but for many of your everyday or simple tasks, you might just need a simple screwdriver or a hammer, right? And you don't want to be using a sledgehammer to hammer in a nail, for a small problem using a bunch of cost to do something you could have done with a much smaller tool. And so that's the way that I think about models and I like to switch between models all the time depending on what

38:28 task I'm working on and also what I'm trying to accomplish. The second part of using plan mode before executing, we we've talked about this quite a bit, but just want to reiterate plan mode lets you organize your thoughts and make sure the agent is going in the correct direction before letting it go and and consume tokens and work on work on your different tasks.

38:49 The last thing was before moving into the Q&A portion of the section is our product roadmap and kind of how we're thinking about the evolution of agentic coding. Our vision for the next 6 months focuses primarily on agents in the cloud and how we can improve quality of an agent so that we can improve velocity.

39:10 And so thinking about knowledge, we want knowledge to be modular and we want to be able to be shared between different teams. And so we're working on giving our agent harness the ability to choose the correct MCPs, school skills and and and sub agents for each agent and we'll continue to do that. A big focus for my team in particular is that we want to be surfacing like the correct guidance for for users. And so we're hopefully going to provide more kind of commentary on

39:36 skills that we think could be valuable and also what MCPs for particular tasks. I think that this is if you're working on a team or at a large engineering organization, we're going to make Cursor kind of a teamwork heavy environment where you'll be able to share your configurations really easily and potentially even work with agents across multiple people. For asynchronous agents, we want to focus on building the best possible environment for you to manage your

40:04 agents, right? Ultimately, regardless of how powerful the agents are, they will be limited by your ability to kind of observe them and make sure that they're going in the correct direction. And so that's where Cursor 3 and our agent config are going to continue to improve and give you an environment to be a really good manager over your agents to make sure they're they're going in the correct direction. For code quality in particular, this is primarily where things like bug bot are going to play and also development

40:30 our agent harness where we want to make sure that you give you're giving agents the correct context but that they're also providing proof that they're working on the right things. And then the final component of this is controls, right? And so for enterprise level teams, we're making sure you have an effective way to manage all of your agents in one place and ensure that all of your users are effectively using cursor at the highest level.

40:56 Amazing. Well, Emily and Samantha, if there's anything you would like to add, feel free to. I mean otherwise we can kind of jump into Q&A if that sounds good. >> Yeah, let's do Q&A. I have a few surface questions. I think some folks had a lot of questions about cloud agents and when you'd recommend them over local agents.

41:14 I think the one I asked was is it just about more agents running them kind of in velocity and quality? What what would you say? >> Yeah, that's a great question. I would say cloud agents are extremely useful for separating your concerns. And so if you think about having multiple agents running locally on your machine, the obvious problem that arises is how do you manage the potential conflicts that could occur. And with cloud agents, you don't have to worry about that in any sense, right? It's the same as asking a

41:42 teammate to go and build a new feature branch and work in a completely separate environment and push changes there and then consolidate them at the the pull request level, right? And so I would say for cloud agents, I like using them because they're extremely convenient. I use them for large tasks and small tasks just because it helps me, you know, get to the pull request phase faster than than maybe if I were to do things locally. I would say anything that you do locally

42:10 it be something that you want to be extremely like particular about or have a conversation with the agents at multiple different phases in the development process. And so that could potentially be for like extremely mission-critical parts of your code base, for example, where you want to be very particular about how the agent is approaching something. You kind of want to review like every single file that's being produced at the local level.

42:30 That's a good approach there. >> Yeah, the way I would use it, I think it's super helpful whenever someone has a request. There's a ton of context switching and it's really minimized with cloud agents. So, yesterday someone's like, "Hey, in the blog, the images look poor look bad in mobile on Safari. Can someone fix it?" And I was like, "At cursor, please fix." And so before that would have had me I have to check out a new branch, kind of stash my changes,

42:54 make these corrections, test, push. I think what happened was I had a PR that like Versel had an automatic preview. I clicked on it. Everything looked good, automatically shipped. Um I think some other stuff is I had a ton of ideas for like experiment um experiment experiments for the website.

43:10 So, I was like, "Oh, I want like the blog to be cached. I want to add new language support. I want to add a new experiment to the homepage." And so I like spun off like five things in parallel. And then the most complex one, it like got 80% there. I pulled it in locally and continued it the rest of the way while the other stuff was running. So, I think it just lets you me kind of context switch less. Um and the agents are getting pretty good now. It can

43:32 almost like one shot a ton of stuff. Especially tomorrow after this workshop, I'll go to cursor and say, "Here's the workshop recording. Add it to cursor.com/workshops." Um and I'll it'll probably get that one on a single shot. Another question, um someone asked and I know we are at time. I think we can probably stay for a few more minutes if you guys are free, but also you're welcome to hop. We'll share the recording afterwards. Um but someone asked, "Do we internally design everything in Figma or is Cursor making

43:58 those design decisions?" Um happy to take a pass, but I think for those complex kind of structural changes, I don't know if you guys have seen Cursor 3 um, Cursor Glass. For that, it was a lot of experiments and Figma designs. What do we want a unified agent-first experience to look like? Um, and then kind of ideating happened in Figma, and then the actual build-out happened in Cursor. I think for a lot of engineers, once we have those components and

44:21 principles, I myself don't know how to use Figma or design it. So, I think Cursor is able to do a lot of the design work for me. Um, so I think it depends on how complex a feature is, how kind of different is the style path. Um, and yesterday we had a sync on changing kind of the dashboard experience. And so, the designer actually pulled out like a Versel preview she built in Cursor, and we were all able to click around with it, change from individual to admin

44:44 view. Um, and it made that kind of dogfooding and I ideation experience a lot better. And then, yeah, just a question for you. Um, how are we thinking about kind of code quality um at Cursor? I think if we have teams separately working on client work, server work, um how do we make sure that we're all aligned and shipping um fast without kind of causing any regressions?

45:11 >> For sure. And this is kind of a different one. Uh, I think the biggest thing is just having central sources of truth where you're tracking all of the different developments that's happening across your teams. And so, for us, Linear is kind of like that source of truth. Um, where at any point someone can check in and kind of see what other people's agents are up to uh or how different parts of the product are progressing. I also think just communication between your teams is is extremely valuable. And so, part of the

45:35 culture at at Cursor is that if there's ever any questions or concerns with some part of the product, uh right, people are accessible. And so, um that is definitely where like the people component of this becomes extremely important. Where an agent is not going to be able to explain why a product decision was made or like what the priorities are for the future. And sometimes the easiest way to do that is just to add someone to like a Slack channel or a Teams channel, whatever it might be. Um, and or even go up to their

45:59 desk and just ask them, you know, um what's going on. And sometimes like that is just the best way of of staying coordinated and organized. I don't know, Emily, if you have, uh, some thoughts there as well. >> Yeah. No, I do think, um, one thing that we do is we have an automation that runs that also like rings the severity of the PR. And so someone we're touching the core Stripe checkout flow, like it's going to flag that as high, um, severity. It's going to tag it up for a code review. If I'm changing like a

46:26 title bar on this one button, it's just going to automatically say like, "Hey, that's okay. Like you're you're using the button design component, um, and the risk is pretty low." Awesome. Well, I think with that, um, sorry if I couldn't get to your questions, but thank you so much everyone for joining. Thank you for the great presentation, Jed, and we'll make sure to send it out after the call.

46:45 Bye, everyone. >> Awesome. Thank you, everyone.