Does AI Actually Boost Developer Productivity? (Stanford / 100k Devs Study)

[upbeat music] In January of this year, Mark Zuckerberg said that he was gonna replace all of the mid-level engineers at Meta with AI by the end of

the year. I think Mark was a bit optimistic, and he was probably acting like a good CEO would, would to inspire a vision and also probably to keep the Facebook stock price up.

But what Mark also did was create a lot of trouble for CTOs worldwide. Why?

Because after Mark said that, every single CEO in the world, almost, turned to their CTO and said, "Hey, Mark is-- says he's gonna replace all of his developers with AI.

Where are we in that journey?" And the answer probably was, "Honestly, not very far, and we're not sure we're gonna do that."

And so I personally think hopefully this is not, um, you know, gonna, gonna change, but I don't think AI is gonna replace developers entirely, at least, at least this year, let alone at, at, at Meta, right?

But, um... And I do think that AI increases developer productivity, but there's also cases in which it decreases developer productivity. So AI or using AI for coding is not a one-size-fits-all solution, and there are cases in which it shouldn't be used.

And so for the past three years, we've, uh, been running one of the largest, uh, studies on software engineering productivity at Stanford, and we've done this in a time series and cross-sectional way.

So time series meaning that even if a participant joins in twenty twenty-five, we get access to their Git history, meaning we can see trends of data across time. We can see COVID.

We can see AI. We can see all of these trends and, and, uh, things that happened. And then also cross-sectional because we have more than six hundred companies participating, enterprise, mid-sized, and also startups.

And so this means that we have more than a hundred thousand software engineers in our dataset right now, dozens of millions of commits, and billions of lines of code.

And most importantly, most of this data is private repositories. This is important because if you use a public repo to measure someone's productivity, that public repo is not self-contained.

Someone could be working on that repo on the weekend or once in a while, right? Whereas if you have a private repo, it's much more self-contained and much easier to measure the productivity of a team, of a company, of an organization.

So late last year, there was a huge, um, controversial, uh, thing around ghost engineers. So this came from kind of the ser-- the, the same research group, our research group.

And here, uh, Elon Musk was kind enough to retweet us. But what we found is that roughly ten percent of software engineers in our dataset, at the time about fifty thousand, were what we called ghost engineers.

These people collect a paycheck but basically do no work.

So that was very surprising for some people, very unsurprising for others. And so some of the people in this research team are, for example, Simon from industry. Uh, so he was CTO at a unicorn, which he exited, and he had a team of about seven hundred developers.

And as CTO, he was always the last person to know when something was up with his engineering team, right? And so he thought, "Okay, how can I change this?"

Myself, I've been at Stanford since [REDACTED:age], and I focus on what I call data-driven decision-making in software engineering. And in a past life, I was looking after digital transformation for a large company with thousands of engineers.

Part of the team is also Professor Kosinski, who is at Stanford, and his research focuses on human behavior in a digital environment. And basically, he was the Cambridge Analytica whistleblower back in the day, if you recall that.

So today, we're gonna be talking about three things.

We're gonna start off with the limitations of existing studies that seek to quantify the impact of AI on developer productivity. We're gonna showcase our methodology. And lastly, we're gonna spend most of the time looking at some of the results.

What is the impact of AI on dev productivity, and how are ways we can slice and dice these results to make them more meaningful?

And so there's lots of research being done on this topic, but a lot of it is led by vendors who themselves are trying to sell you their own AI coding tools, right?

And so there's a bit of a conflict of interest there sometimes. And the biggest three limitations that I see is that a lot of these studies revolve around commits and PRs and tasks.

"Hey, we completed more commits, more PRs. The time between commits decreased."

The problem here is that task size varies, right? And so delivering more commits does not necessarily mean more productivity. And in fact, what we found very often is that by using AI, you're introducing new tasks that are bug fixes to the stuff that the AI just coded before.

So by that case, like you're kinda spinning your wheels in place, right? So that's kind of funny.

Secondly, there's a bunch of studies who say, "Well, we grabbed a bunch of developers. We split them into two groups, and we kinda gave one AI, and one of them we didn't."

And what usually happens there is that these are kinda greenfield tasks, where they're asked to build something with kinda zero context from scratch. And there, of course, AI decimates, uh, the non-AI people, but that's bo- because AI is just really good at greenfield kinda boilerplate code, right?

But actually, most of software engineering isn't greenfield and isn't always boiler-boilerplate, right? And so there's usually an existing code base. There's usually dependencies. So these studies can't be like applied to, to well to these situations either.

And then we also have surveys, which we found to be an ineffective predictor of productivity by doing this small experiment with forty-three developers whereby we ask every developer to evaluate themselves relative to the global mean or median in five percentile, uh, buckets from zero to one hundred.

And then we compare that to their measured productivity. We'll get into what that means later. But what we found is that asking someone how productive they think they are is almost as good as flipping a coin.

There's very little correlation, right? And so we found that people misjudged their productivity by about thirty percentile points.

Only one in three people actually estimated their productivity within their quartile, o- one quartile. And I think surveys are great. They're valuable for surfacing, you know, morale and other issues that cannot be derived from metrics, but surveys shouldn't be used to measure developer productivity, much less the impact of AI on developers

for pr- p- productivity cases. You can measure it to kinda see how happy they are using AI or whatever, I suppose. Um, great. So now let's dive into our methodology.

So in an ideal world, you would have an engineer who writes code, and this code is evaluated by a panel of ten or fifteen experts who separately, without knowing what every person is, uh, answering, evaluates that code based on quality, maintainability, output, how long would this take me, how good is it, right?

So k- kind of like a, a bucket of questions. And then, um, what happens is that you aggregate those results, and we found two things. The first one is that this panel actually agrees with one another.

So it turns out that one engineering expert agrees with the other engineering exp- expert when they're talking about an objective code in front of them. And secondly, and probably most importantly, is that you can use this to predict reality, and reality is predicted by a panel like this.

The problem then is that this is very slow, it's not scalable, it's expensive. Um, and so what we did is we built a model that essentially automates this, correlates pretty well, it's fast, it's scalable, and it's affordable.

The way it works is it plugs into Git, and then the model analyzes the source code changes of every commit and quantifies them based on a bunch of these dimensions.

And then since every commit has a unique author, a unique SHA, a unique timestamp, then you can kinda understand that, uh, okay, the productivity of a team is basically the functionality of the code they deliver across time, not the lines of code, not the whatever commits, but the func-- like what that code is doing, right?

And so then you can kinda put this in a dashboard and, uh, overlay it across time and get something similar to this. [clears throat]

Great. So now let's dive into some of our results.

So here in September is when this company implemented AI. This is a team of about a hundred and twenty developers, and they were piloting whether they wanted to use, uh, you know, AI in their kinda regular workflow.

And we have here, um, these bars, and every bar is the sum total of the output done in that month

using our methodology, not lines of code. And we can see that in green it's added functionality, in gray it's removed, in blue is refactoring, and in orange is rework.

And so rework versus refactoring, they both alter existing code, but rework alters code that's much more recent, meaning it's wasteful. Refactoring could be wasteful, could be not wasteful. And so from the get-go, you see that by implementing AI, you get a bunch more of rework.

What happens is that you feel like you're delivering more code because there's just like more volume of code being written, more commits, more stuff being pushed. But not all of that is actually useful.

To be clear, I think there... I mean, based on this chart and overall, there is a productivity boost of about fifteen to twenty percent, but then a lot of the gains you're seeing are, uh, basically this kind of rework, which is a bit, you know, misleading.

So if I could summarize it into one chart with many discrepancies, it would be something like this.

So with AI coding, you generate or you increase your productivity by roughly thirty, forty percent. Like, you're delivering more code. However, you gotta go back and kinda fix some of the bugs that code introduced and kinda, you know, fix the, the, the mess that the AI made, which in turn gives you an average productivity gain across all

industries, all sectors, everything, of roughly about fifteen to twenty percent.

There's a lot of nuance here, which we're gonna see in just a second.

So here we have two violin charts, and they plot the distributions of the gains in productivity from using AI. And so kind of like the y-axis is the gains.

It starts from minus twenty percent, take note, and then it goes up. And here we have kind of four pieces of data being shown. In blue is low complexity tasks,

and in red is high complexity tasks. And kind of like your left, uh, the, the chart to the left is greenfield tasks, the chart to the right is brownfield tasks.

So right from the get-go, the first conclusion we have is that, sure, it, it seems like AI performs better in coding with simpler tasks. That's good. It's proven by data.

That's awesome. The second thing we see is that, hey, it sounds like for low complexity greenfield tasks, there is a much more elongated distribution and a much higher distribution on average.

Keep in mind that this is for enterprise settings. This doesn't apply for kinda like personal projects or vibe coding something for yourself from scratch. The improvements there would be much bigger.

This is kind of for like real world working company settings.

And the third thing we see is that if you look at the high complexity tasks, I mean, they're lower than the low complexity ones on average in terms of the distribution, but also in some cases,

they are more likely to decrease an engineer's productivity.

Now, this decrease could be for many things, many reasons, but that's kinda what we see in the data, right? The underlying causes are still not super clear to us.

If we translate this to a chart like this, which is a bit more digestible, you have, uh, in, i- in the bars and the columns

kind of like the average or the median gain, and then the line represents the interquartile range. So the bottom of the line is the twenty-fifth percentile, and the top of the line is roughly seventy-fifth percentile.

And so here it's very clear to see how we have, you know, more gains from low complexity tasks, less gains from, uh, high complexity tasks, and then brownfield, it's harder to leverage AI, um, to make increases in productivity there compared to greenfield.

So if there is maybe a slide that you could show to your leadership team, it could be this one or it could also be this one. So here I have a matrix really simplifying things.

You know, reality is a bit more difficult than this, but here we have kinda on one axis task complexity, low and high, on the other one, project maturity, greenfield versus brownfield.

Kind of we see that, hey, low complexity greenfield, thirty to forty percent gains, right, from AI.

High complexity, but greenfield, more modest gains, ten to fifteen.

Brownfield and low complexity, pretty good, fifteen to twenty percent. And most importantly, high complexity brownfield tasks, zero to ten percent.

These are orientative guidelines based on what is seen... what we see in the data. And I forgot to mention, uh, this slide has a sample size of hundred and thirty-six teams across twenty-seven companies, so pretty representative.

Um, and then that's gonna derive-- or this chart is derived from that data.

Then here we have a similar matrix, except at the bottom we have language popularity. So in low we have examples such as COBOL, Haskell, Elixir, really kinda obscure, obscure stuff, and high is things like Python, Java, you know, JavaScript, TypeScript.

And what we see is that AI doesn't really help even with low complexity, uh, tasks for low popularity languages. It can help a bit, but it's not terribly useful, and what ends up happening is that people just don't use it because if it's only helpful two times out of five, you're just not gonna use it very often.

What's funny or interesting is that for low language popularity and complex tasks, AI can actually decrease productivity because it's so bad at coding in COBOL or Haskell or Elixir that it just makes you slower, right?

Granted, this isn't very, uh... Like, this happens, but it may be five or ten percent of the kinda global development work, if that, right?

Most of the development work is probably somewhere in the lang- in the high language popularity kinda part of the chart. And here you have gains between twenty percent for the low complexity and ten to fifteen percent for the high complexity.

So now moving into something a bit more theoretical, less empirically proven, but more so kind of like what we're seeing in, in, in the data, right? This is like an illustrative chart which has kinda productivity gain from AI on the Y-axis and a logarithmic scale of the codebase size, right, from one thousand lines of code to ten

million on the X-axis. And we see that as the codebase size increases, the gains you get from AI decrease sharply, right? And I think most codebases nowadays are kinda somewhere in the...

depending on, on your use case, right? But they're bigger than a thousand lines of code unless you are a YC startup or something that's like kinda spun out a couple months ago, right?

And that's because, you know, there's three, three reasons for this really. Context window limitations. We're gonna see in a second how performance decreases even with larger context windows. The signal-to-noise ratio is...

kinda confuses the, the model, if, if you will. And then of course, larger codebases have more dependencies and more domain-specific logic present.

And so then borrowing work from this paper called NoLiMa, which shows you on a scale of zero to one hundred how LLMs perform on coding tasks, you see that as context length increases from one thousand to thirty-two thousand tokens,

performance decreases. And so we see all these models here. For example, Gemini 1.5 Pro has a context window of two million tokens, and you might think, "Whoa, I can just throw my entire codebase into it and it's gonna retrieve and then code perfectly," right?

And what we see is that even at thirty-two thousand tokens, it's already showing a decrease in performance from ninety percent to about fifty percent, right? So what's gonna happen when you move from thirty-two to sixty-four or one twenty eight, right?

You're gonna see really, really poor performance here.

And so in short, AI does increase developer productivity. You should use AI for most cases, but it doesn't increase the productivity of developers all the time and equally. It depends on things like task complexity, codebase maturity, language popularity, codebase size, and also con- context length.

Thank you so much for listening. If you'd like to learn more about our research, you can access our research portal, which is softwareengineeringproductivity.stanford.edu. You can also reach me, uh, by email or LinkedIn.

Super happy to talk about this topic at any time. Thank you so much. [audience applauding] [upbeat music]