Developer Productivity Trends

0:00 Awesome. Um, all right, let's get started. Um, thank you all so much for joining. Um, so this is developer productivity trends of 2025. Uh, I'm really excited to talk through some trends, um, what we're seeing, um, here at Curser and across the industry. Um, uh, Talal and I, uh, and Emily work with a number of customers. Um, and, uh, we're excited to kind of share some of the insights that we've been seeing. Um, and so, yeah, it'll be, uh, I'm Rohan. I'm an AI deployment manager here. Um, and then we

0:31 have Tal on the call who's also an AI deployment manager. Uh, and Emily as well. Uh, and we are going to be um, and and so like our our role as AI deployment manager is often um, basically helping customers um, drive adoption um, at their companies, help uh, executives measure productivity gains uh, and a number of other things. And so um, that sort of uh, leads us to what we're going to be talking about today.

0:55 So, um, what I want to kick us off with is just kind of, uh, sharing some stats about cursor. Uh, cursor is really the way that engineering teams build with software. Uh, there's over 50,000 enterprises building on Cursor. Um, we have 64% of the Fortune 500. 93% of engineers um, choose Cursor and head-to-head. Um, and we're seeing over 100 million lines of enterprise code written per day. Um, this is just a set of some of our, um, top customers. Uh,

1:20 and one that I like to highlight is, uh, Nvidia. And so, uh, Jensen Huang, who is the president and CEO at NVIDIA, um, recently said, "My favorite enterprise AI services cursor. Every one of our engineers, some 40,000, are now assisted by AI, and our productivity has gone up incredibly."

1:38 And so, I want to we like to highlight this quote because, you know, we work with a lot of large companies, but obviously Nvidia is one of the largest. And I think that kind of goes to show that um the scale and and sort of the enterprise scale uh at which cursor can be used for is is very very um large.

1:56 And so um today uh we'll be talking about uh measure first measuring productivity. Uh we'll then go through a productivity research study that was published a few months ago. Uh I'm going to talk through some customer case studies. Uh I'm also going to talk about some adoption rollout strategies that we've seen work really well across customers. We'll talk briefly about the organizational impact of cursor. Uh and then finally um I will demo a few

2:20 developer productivity features that we have in the admin dashboard. Uh and feel free to um use the Q&A section um to answer any questions. Tal will be answering and hopefully if we have time we can um he can ask me a few live. Okay. So let's jump in. So measuring productivity. Um the first thing I want to call out here is just where is the engineering focus shifting. So we're seeing certain fields like uh certain areas of the software development life

2:49 cycle things like onboarding new code refactors writing tests and now honestly even code reviews um being accelerated by AI by two to five times. Um but we're not seeing an even kind of uh acceleration across the entire software development life cycle. So we are seeing things like earlier in the uh life cycle like planning and design as well as security, CI/CD, maintainability, extensibility um still becoming the bottleneck. So again more and more code

3:16 is being generated but how do you actually make sure that features are getting shipped to customers faster? I think that's really kind of the crux of this. Um and you know it's important as you're thinking about this to to not just assume that you know cursor is going to help just like get features out faster. there's still going to be bottlenecks in the software development life cycle and you know cursor we're building a lot of features here to help

3:37 out with with um some of those phasages but at the end of the day it's also on you as leaders to kind of think through how to um focus on other parts of the bottleneck and one call I want to make here is I do personally think that planning and design will remain the most important focus um I think it's you know the one area that relies the most on creativity and problem solving and it's the hardest to automate right like I do think that code review we already have a

4:01 tool called bug have bought out security, maintainability, accessibility. There's going to be a lot of tools, I think, uh, over the next year or two to to really help out with all of those. Uh, but planning and design, there are tools, but they still will require kind of that human creativity.

4:17 And, um, and so, you know, cursor like being an AI native company, uh, we really do see sort of, uh, we have a front row seat into how AI shapes productivity. And so what I've seen across the industry is that um you know we used to have a lot of older metrics things like lines of code commits active users um these are great kind of proxy metrics but in a world where uh AI is actually out helping output much more code for example that doesn't necessarily mean it's better code or that it's actually reaching the customer

4:46 faster. Uh, so I think it's really or and same with active users, right? If someone's using the tool like once a week or or a couple times a week, that doesn't necessarily mean it's built into their daily workflow. And so I think it's really important to go beyond these older metrics into um some kind of more uh relevant metrics for the world of AI. And so brings me to this slide. Um I think this is a very very important slide. Um there's sort of two main

5:10 pillars that we think of with metrics uh that I've seen work really well. The first is on the left um velocity and the second is quality. I think these twin pillars can really really help in a very quantitative way help you sort of start to get to um again shipping great features faster. Um so dive into each of these. So so in the velocity category right you have things like PR velocity.

5:32 Um this is the easiest uh sorry the the easiest to implement but um the furthest away from um the actual kind of like you know shipping great features faster. I think it's a really great metric still uh and I think that you know um highly recommend implementing it a little later. We're going to talk about how we startups are going to start to surface this but really really valuable. Then there's story point velocity. Um this I know is hit or miss. Some companies use

5:56 story point some some don't. But really what this is trying to get to is a little bit more of the business value but in a way that's measurable through tools like Jira. And then finally feature completion velocity. This is really the hardest to measure. Obviously everyone defines features differently. Um, and I think that the best way to think about it is maybe like how quickly are you going down your road map. So this is something that you could maybe check out in a QBR um or or just kind of a road mapping

6:21 exercise. Again, hardest to measure like through like Git or through Jira, but really great kind of directional metric and I I think something like PR velocity coupled with feature completion velocity is really valuable. Uh the second bucket is quality and with quality I I want to call out that there's um sort of this uh external and internal view right so you want to make sure that externally for customers um the number of defects are at least staying the same if not going down um and then more internally you want to

6:50 think about everything from test coverage gains to just general code quality um extensibility maintainability things like that um and so you want to I think with both of these you know with tools like uh cursor they're not necessarily going to go down a ton on right away. Sorry, number of defects not going to go down. Number of test coverage gains is not going to go up very quickly. Uh but at least you want to kind of see some smaller gains in those. [snorts] And then finally, there's this really

7:13 interesting new one called code half-life. And this is essentially code turnover. So once code is in the codebase, how often does it persist and how often do you have to change it? Do you have to change it every week, every few months? Um I think this gets to a lot of that like you know um kind of sustainability of the code and maintainability which is really valuable. developer sentiment um is pretty is a great qualitative metric to add in. What I call out here is it's not just about um are you you know are

7:40 developers happier using the tool. It's really getting into do you feel like you've saved times with meetings and standups and some of the more qualitative ways of understanding um you know developer uh uh time being saved. And then finally, I know everyone is uh oftentimes thinking about ROI. Um onboarding speed, cost per those these are a bit more like granular. Um but the real one that you want to be working toward is this bottom one, time to

8:03 market acceleration. Uh again going back to like are you getting features uh out to the customer faster. I think there's a lot of other metrics that can be noise. Um and again because the software development life cycles bottleneck is shifting. Um I think it's really important to just continue to focus on what's the end goal for the the customer and business value. uh and then kind of work your way back from there. And this is what I've seen work best for

8:25 for some of our top customers. So I want to next jump into um a productivity research study that was done. Um so I think it was in uh yeah so in November um uh there's a a professor from the University of Chicago who published a study um on productivity uh and uh using kind of studied a thousand organizations that adopted cursor uh to try to see sort of what this actually did for um the the um company's bottom lines and what he found was that um

8:54 organizational organization level output increased by 39% with cursor that's pretty you know substantial um I think that 39% increase is is very very meaningful for for a lot of companies and customers. Uh and so um this is this was a really interesting study. Um we'll we'll share the deck after um and there's a link to the study here [snorts] in a bit more depth, but I'm going to cover some top points from the study.

9:18 So um yes, so the first is uh what I just mentioned, teams merged 39% more pull requests after agent became the default mode. Uh and this is really really valuable again just to kind of get um that this is actually merging it to production and so you're getting much closer to um you know what's shipping to customers um by uh through this metric. The second um which is very interesting um he actually uh broke down years of experience um in a very granular way and

9:47 he found that more experienced developers are actually more likely to accept agent generated code. Um, and this was something I found really fascinating because I actually would have thought that well maybe some some engineers who are newer are like more AI uh forward. Uh, I think that there's still sort of um some uh I'm sure there's there's uh examples of uh earlier developers who are great um with using AI, but it's really interesting to see that the people who are actually accepting the AI generated code um was

10:14 higher. And part of that might actually be due to the fact that they're better at planning. They're better at doing some of the upfront work um to to make sure that um you know you're you're actually getting to that higher accept rate um in the in the code. And then finally um what what's also interesting is he sort of broke down some of the tasks. Um most agent conversations began with implementing or planning. Um and I think that again this is really really important to keep in mind. I would actually really um

10:43 advocate for starting with planning and we have our plan mode uh to go with that and then jumping to implementation especially for the larger more gnarly uh tasks. So for for sort of planning a new feature or solving a very very gnarly bug recommend that path uh but it's interesting that you know people people have been starting uh with this sort of implement stage predominantly uh and just kind of jumping into to writing the code and yeah so we'll we'll link this deck afterward um and you'll be able to see

11:10 the productivity study in more depth. Um, cool. And, uh, next I want to kind of share a couple customer case studies. Um, so the first one is Salesforce. Um, Salesforce is one of the largest customers we work with. I actually work with them directly. Um, so, uh, over 90% of Salesforce engineers are using cursor. Um, which is a really, really great stat. And again, the real two things, keep honing this point in, um, are velocity and quality. They want to build faster and they want to ship with

11:41 higher quality. [snorts] And so um what they found was they they saw 2x double-digit gains in both code quality and velocity which is really really high uh especially across you know 20,000 developers and a 30 gigabyte code base. They actually have one of the largest monor repos in the world. um and and using cursor um given code cursor sort of codebase indexing and ability to really understand large code bases um they were able to um you know see these

12:07 measurable improvements in cycle time, code quality and throughput [snorts] um and and the other part that I want to call out here is this last point. Uh they really did a did a fantastic job of building AI into engineering culture. Uh and so that's that's through leadership that's through you know engineers on the ground. Um but really sort of like and I'll talk about this a little bit later on how to drive adoption but really building it into the engineering culture

12:30 is super super critical [snorts] and so their SVP Sean uh Apa Joduh said AI is transforming how software is written and designed. We've seen a huge improvement in the quality of products. Um so yeah really really awesome to see Salesforce kind of um you know using cursor to such a a great extent and again I think it goes to show that um they're also very very large organization and uh I think that cursor can definitely work well for any of your organizations as well.

12:58 And the other one I want to call out is Stripe. Um and so Stripe actually focused a bit more on reliability as their metric. um they were really really focused on um their uptime target uh of 99.99999%. So 69s uh and they wanted to shave uh hours off of setup and debugging um so engineers can ship on day one. Uh and so this is still by the way going back to sort of shipping quickly. They really want to take they really want to like remove the tech debt, remove the hours of setup and debugging so that people

13:28 can actually focus on on velocity. Uh and they they really wanted to do that upfront work. Um they also kind of uh they saw five year high-end developer sentiment. Developers were really really excited to use cursor. And then finally their prototypes in hours not days. Um and so again you know it may take a little bit more time to get to production uh ready code but what's really really valuable is this the sort of like initial kind of uplift there.

13:54 And uh their head of developer infrastructure said AI and cursor opened up new skill sets for engineers. It's helping people move beyond their comfort zones. Uh we're going to talk about this a little bit more in a second too, but I think it's really interesting to think about, you know, how potentially a front-end engineer can now do backend work or an iOS engineer can now um you know, try out something else. Uh and so just being able to move across the

14:16 stack, move across technologies in a very very straightforward way um is is super valuable. All right. And with that kind of segue, I want to talk a bit more and dive into adoption rollout strategies. So um we're seeing a really I think with enterprise adoption um the the main thing to keep in mind here is there's a big cultural shift uh that's needed 100% of people trying AI is not the same as deeply using it and deeply integrating it into their uh workflow. So, a lot of

14:47 people have mentioned, a lot of leaders have mentioned, well, I have 100% adoption. Um, and then I look at their stats and it's actually like, well, you have 100% of people using it one time a month, right? That's very different than sort of using it every day or building it into your daily workflow. And so, I think to get to that next level of of actually getting people to use it, um, there's really four tips I have for you. So, um, the first is defining the why.

15:11 um really with your engineers tying AI to outcomes and making sure that engineers are are very deeply aware of um what those outcomes are and and what this actually means for the customer, for the business value, for the roadmap. [snorts] The second is my favorite. Um I think it's super critical. It's lead from the front. Um and it's the idea that leaders leaders must model behavior, right? It's one thing if as a leader you tell engineers to sort of use cursor um and then it's another thing to actually use

15:37 it side by side with them. It's a it's a tool that really has become accessible to, you know, VPs, SVPs, and other sort of um leaders. And I think that it's really important to actually, you know, be using it yourself. It could be for your day-to-day work. Maybe it's to create a dashboard around performance.

15:52 Maybe it's to create um you know, something something else for your team, or it could just be a side project. But either way, you actually using cursor um side by side is important. The third is creating champions and catalysts. um empowering early adopters is really important and having them sort of go and evangelize the product um and and the tools and AI in general to other other people. I think it's important to do that um work up front early. And then

16:16 finally um four is evolving the culture. I think it's really important to align HR incentives. Um I talked about uh a little bit about this earlier but like basically um uh you know everything from performance to recruiting is really really important to think about. And the real key point here is adoption isn't about deploying new tools. It's about building trust and changing habits.

16:39 And here's just like an idea of an adoption plan. Um kind of four steps here. First is just again getting it into the hands of as many developers as you can to establish those benchmarks. Um you know cursor can help with uh enablement if if you're an enterprise customer. Cursor can help with enablement sessions, any other trainings. If if not, you can also do it yourself. um but really just getting it into the hands and and and having that initial kind of session on how to use it. The second step is then to kind of

17:05 grow power users and really enable those power users to distribute um effective workflows. Um you want to really understand the workflows of your power users and sort of replicate that across people across the entire or as well as really kind of empower those power users to be evangelists of uh AI cursor.

17:23 The third is then you can start to build more of the autonomous agent workflows into the systems. Um we have uh part of this is maybe just the the sort of normal agents and parallel agents but we also have things like um cloud agents and bugbot that can really help with this this structure. And this is really about scaling what you're doing with your power users across the org. And then finally um which we've already talked about is measuring right um

17:46 measuring productivity gains will help kind of and and doing it not just at the or level but a little bit more at the individual level or team level can also help guide people on effective and efficient use of AI to actually build faster and smarter with agents.

18:02 And again, um, I think the real focus here is creating a culture of shipping really fast, uh, as well as reducing the bottlenecks throughout. Okay, I'm going to talk a bit about organizational impact next and what we're seeing, um, in the industry. So, um, there's really been four big shifts that I've been seeing um, across the customers I've been working with. Um, the first is that skills are multiplying. I kind of alluded to this earlier, but um previously you had this idea of a T-shaped engineer. Um the idea

18:33 being they're the top of the tea is that they're pretty broad, but um they can go really deep in maybe one or two areas, right? So that could be like they're an iOS uh developer or they're a um you know, Java backend engineer. Um so they can go really deep in one area. We're now seeing this idea of barrel-shaped.

18:50 And the idea being here is that you can actually go deep in in one area but then pretty like relatively deep in other areas. Um and so for example um you know an iOS engineer might be able to take a first pass at shipping backend code and you know you still would want a backend engineer to review that code. Obviously um you know you want you want to maintain that trust but um they're able to sort of at least take that first pass and really reduce the cycle time. And so

19:14 instead of having uh this actually goes to point number two, right? Where instead of having a team of like eight to 10 engineers focused on one codebase, you can actually move to maybe like pods of two. You can actually and and it's not about like you know um uh letting people go or anything. Really, it's taking that group team of 10 and splitting into uh three teams of three, let's say, um three or four and really creating pods um of smaller pods where

19:38 people have the autonomy to jump across code bases and ship much faster. Right? What we're what we've seen is that one of the biggest um like uh bottlenecks is actually also communication among uh engineers. And so when you have smaller teams and especially empowered autonomous teams to be able to jump across code bases, it becomes a lot easier to ship end to end very quickly.

19:59 Um the third is um experiences disrupted. So, you know, we did talk about how uh like accepting lines of code actually can can increase, but I think uh what I've seen is that AI coachability itself is actually um uh more important than years of experience in some cases too. And so, you're actually seeing a lot of like entry- level developers uh again um being being able to jump into things. Uh maybe that it takes a little bit of time to actually, you know, accept AI generated code, but they're they're they're pretty

20:27 quick learners. Um, and then there's also a lot of senior developers who are really uh fast learners as well. Uh, and then finally, rituals disappear. So sprints and standups um are replaced by uh continuous delivery. Um, and replace may be a little bit of a stretch, but at least you're trying to kind of move away from meetings and and into sort of this continuous delivery.

20:46 And what they want to call out is that here at Cursor, we don't it's not even pods of two to three. It's actually single engineers own entire features end to end. And you know, we're an AI native company. So I don't necessarily want everyone to compare to us but um that is maybe like a north start to work toward and that kind of takes me to this slide. Um so uh evolution of developer productivity right this is what I mentioned we're seeing um you know 10

21:09 engineers kind of working on maybe one feature one codebase that's sort of where the industry is. I'm starting to see leading companies move to three three to one right three engineers to the three developers to one feature. Uh so sort of the same team size but you can do more experiments. um cursors here oneto one what I think we're going to start to see is actually you know with things like uh autonomous agents a single engineer not just owning one

21:33 feature but actually owning three features and trying out multiple ideas and then maybe even owning 10 features um towards the end here and the idea here is you just have a lot more experimentation that's going on uh and the bottleneck is not shipping software anymore it's it's really idea generation um this is I know a big paradigm shift for a lot of people um but this is really where you know we see the future future of of um software development

21:55 going. Um I've talked about kind of pods replacing specialized silos, engineers working across full stack. Um this also really helps with dramatically reducing onboarding time with AI. Uh and again this idea of concept to production cycles are measured in days not quarters. Um and I think this is really really powerful. Um I also want to call out I mentioned again like this is not about doing more with less developers. Um, you know, obviously it's up to you

22:19 how you want to structure your org, but what I really think this is about is unlocking like new levels and unprecedented innovation uh to stay ahead of competitors who are already making this shift. Um, so really shifting that framing of oh, you know, we want to find ways to cut developers to hey, how can we sort of like maintain what we're doing and do 3 to 4x more?

22:42 And uh, we kind of also have this this visual of the AI maturity curve, right? Um, so we moved from manual coding to assistant coding when cursor tag came out. This really turned it to AI as an assistant. We moved from assistant coding to prompted blocks, AI as a pair programmer with cursor agent. Um, with cursor 2.4, we've moved to uh guided feature generation, which is AI as a junior engineer. In the next year or so, I think you're going to start to see us

23:06 move more towards autonomous development where we're launching doing a lot around cloud agents um, which will really support that. And then you know eventually this idea of AI as a co-founder and builder um really intent oriented product creation where you kind of are coming up with the idea and um AI is really implementing the bulk of it. Um and so I think it's helpful to think about these abstraction layers and where we're moving um in your framing as well.

23:32 Okay. And we just have 6 minutes left. So I'm going to talk now um finally about developer productivity features that we offer. Um, so I'm first going to demo our analytics dashboard. Give me one second to pull that up. Um, and so you can uh view the analytics dashboard um by going to okay so by going to cursor.com um/dashboard and then there and then clicking on the analytics tab. Um, you can also view this in settings but you can also just view this online. Um, I'm going to show

24:08 just what it looks like in the dashboard. Um, I'm not sure if I'm uh uh I think I am an admin, but I haven't uh unfortunately shipped with cursor a lot recently. What you can see here though, um is uh I'm going to just kind of pop this open. Um so what you'd be able to see in this dashboard is um uh AI share of committed code, agent edits, tab completions, messages sent. Uh and being able to kind of see this over time, which is really really valuable. Um you also will be able to see um agent edits

24:38 um as well. Um and then again tab completions and messages sent um are down here as well. Um you can see the active users over time across all the different features that we have. So across agent, bugbot, cloud agents and CLI. Um you can also this one uh I actually have this little visualization here. Um but you can actually see um your um your usage. Um so AI line edits uh over time. Uh you can see streaks uh most active days and things like that. Um that those are in more individual and then um

25:14 uh what you can also see across your org is a usage leaderboard. Um and you can actually see sort of how often people are using cursor just across um uh your company and you know uh see see sort of that. Um, and then, um, one of my favorite new things that we added are actually conversation insights. And this is really fascinating because you can actually start to see sort of what, um, work are people actually doing um, day-to-day and sort of is it more new feature development, is it more bug

25:45 fixing, is it code refactoring? Um, so lots lots over here. Um, we're going to continue to iterate on this. This is actually customizable as well, so you can change the categories as you want. Um, and the docs are all here. Um this is this is in the deck. So we'll send that out. Uh there's also uh by the way an analytics API um that uh you can you can um get to to get this uh data.

26:09 Um that's also linked over here. So yeah mentioned conversation insights. Um this one I think is a really great addition that we have. Um we also recently launched cursor blame. Uh and cursor blame is basically able to augment get blame with line level agent co-authorship. So this actually can trace back any line that's written back to who was it co-author um how much of it was written by or like what part of it was written by ai what part of it was

26:35 written by a human. Uh and what you can do with this is actually then kind of um you know track sort of like what you know which people are actually contributing to the code the most. How are they using cursor and you can even correlate how are they using cursor with what's actually being produced. Um and I think this this is going to kind of really get you to the next level of those metrics um using cursor blame. You can uh you know customize it however you

26:58 want. And then finally, what we have coming up in the next um uh month or two is uh an enhanced ROI analytics. Um this is going to include new metrics like PR velocity, which I mentioned earlier, cycle time and revert rate. Um and I I think this is fantastic. I think this is really going to help everyone get to sort of the next level of measuring productivity. And again, you know, ideally we want to do this also at an individual or team based level so that you can also start to correlate um what

27:26 are the inputs um you know like what models are people using and is is using a more expensive model actually contributing to you know increase PR velocity for example um or like you know are people using plan mode is that really helping you know increase uh uh PR cycle time uh so things like or decrease PR cycle time things like that uh I think are going to be really valuable and so I kind of want to leave um with this this uh idea here there's there's really like I think it's important to

27:54 kind of think about these um outdated uh metrics and structures and and move towards these um kind of you know more newer ones. Uh I think it's really really important uh the opportunity here is to measure productivity and ROI and I want to be really clear here. I don't think that AI native orgs will be 10% faster. I really think they'll outshift competitors 10x or more. Um here at cursor like I mentioned we've seen AI first workflows unlock this level of

28:18 both velocity and quality and so I think it's really the time to you know implement tools like cursor really get you know build cursor into the daily workflow of people and then also start to measure that productivity and what it actually means for the end customer for the end engineer.

28:33 Cool. And just so as a next step, um if you are an enterprise customer, reach out to your account executive. Um if uh if you're not, email enterprisecursor. We can uh.com. We can help you. We can help you with a more detailed walkthrough of team usage. We can help you build out extensibility. Um so some of the tools we have around team rules, MCPS, and others. Uh and then we can also help um you calculate ROI and productivity impact as well. Um so thank

28:58 you so much for joining. Um really appreciate it. Uh sorry we didn't get to the Q&A. Hopefully uh Palal and Emily were able to help answer those. But um appreciate your time and look forward to continuing to chat.