5 ms·
The State of AI Coding Report 2025
- dakshgupta 10mo agoHi, I'm Daksh, a co-founder of Greptile. We're an AI code review agent used by 2,000 companies from startups like PostHog, Brex, and Partiful, to F500s and F10s. About a billion lines of code go through Greptile every month, and we're able to do a lot of interesting analysis on that data. We decided to compile some of the most interesting findings into a report. This is the first time we've done this, so any feedback would be great, especially around what analytics we should include next time.
- wrs 10mo agoIt’s hard to reach any conclusion from the quantitative code metrics in the first section, because as we all know, more code is not necessarily better. “Quantity” is not actually the same as “velocity”. And that gets to the most important question people have about AI assistance: does help you maintain a codebase long term, or does it help you fly headlong into a ditch? So, do you have any quality metrics to go with these?
- dakshgupta 10mo agoWe weren’t able to find a good quality measure. LLM-as-judge dint feel right. You’re correct that without that the data is interesting but not particular insightful.
- ChrisbyMe 10mo agoHey! Thanks for publishing this. Would be interested in seeing the breakdown between uplift vs company size. e.g. I work in a FAANG and have seen an uptick in the number of lines on PRs, partially due to AI coding tools and partially due to incentives for performance reviews.
- dakshgupta 10mo agoThis is a good one, wish we had included it. I'd run some analysis on this a while ago and it was pretty interesting. An interesting subtrend is that Devin and other full async agents write the highest proportion of code at the largest companies. Ticket-to-PR hasn't worked nearly as well for startups as it has for the F500.
- neom 10mo agoIf AI tools are making teams 76% faster with 100% more bugs, one would presume you're not more productive you're just punting more debt. I'm no expert on this stuff, but coupling it with some type of defect density insights might be helpful. Would be also interested to know what percentage of AI assisted code is "rolled back" or "reverted" within 48 hours. Has there been any change in number of review iterations over time?
- apercu 10mo agoRight? I want to see the problem ticket variance year over year with something to qualify the data if release velocity is more frequent.
- 8note 10mo agoi wouldnt find that convincing. plenty of tickets are never written because they dont seem worth tracking. an llm speeding up development can have the opposite effect - increasing the amount of tickets because more fixes look possible than before
- apercu 10mo agoFair. Everything has nuance.
- refactor_master 10mo agoI’m interested in earnings correlating with feature releases. Maybe you’re pushing 100% more bugs, but if you can sell twice as many buggy features as your neighbor at the same time, it could be that you could land more contracts. It’s definitely a raise to the bottom scenario, but that was already the scenario we lived in before LLMs.
- jacekm 10mo ago> About a billion lines of code go through Greptile every month, and we're able to do a lot of interesting analysis on that data. Which stats in the report come from such analysis? I see that most metrics are based on either data from your internal teams or publicly available stats from npm and PyPi. Regardless of the source, it's still an interesting report, thank you for this!
- dakshgupta 10mo agoThanks! The first 4 charts as well as Chart 2.3 are all from our data!
- chis 10mo agoWish you'd show data from past years too! It's hard to know if these are seasonal trends or random variance without that. Super interesting report though.
- Morromist 10mo agoThanks for publishing this. People will complain about your metrics, but I would say its just useful to have metrics of any kind at this point. People talk a lot about AI coding today without having any data, just thousands of anecdotes. This is like a glass of pure water in a desert. I'm a bit of an AI coding skeptic btw, but I'm open to being convinced as the technology matures. I actually think LOC is a useful metric. It may or may not be a positive thing to have more LOC, but its data, and that's great. I would be interested in seeing how AI has changed coding trends. Are some languages not being used as much because they work poorly with AI? How much is the average script length changing over time? Stuff like that. Also how often is code being deleted and rewritten - that might not be easy to figure out, but it would be interesting.
- alienbaby 10mo agoI actually ended up enjoying reading the cards after the charts more than I did reading the charts, but the charts were really interesting too.
- conartist6 10mo agoIt's a shame that the AI branch is the software engineering industry is so determined to make us look like compete fools. WHY ARE THEY STILL TALKING ABOUT ADDING LINES OF CODE IF THEY KNOW HOW SOFTWARE COMPLEXITY SCALES. I could not put it more simply: you don't get the benefit of the doubt anymore. Too many asinine things have been done like this line-of-code-counting BS for me to not see I it as attempted fraud. Something we know for sure is that the most productive engineers are usually neutral or negative on lines of code. Bad ones who are costing your business money by cranking out debt: those amp up you number of lines
- conartist6 10mo agoI cannot believe how often I have to call out ostensibly smart AI people for saying shit that is obviously not literally true. It's like they all forgot how to think, or that other people can spot right where and then they stopped thinking critically and started to go with the hype. Many lines of code good! Few lines of code bad!
- dremnik 10mo agovery cool report. been looking for some data on this (memory + AI SDKs) for a while :)
- psunavy03 10mo agoSigh . . . once again I see "velocity" as something to be increased. This makes me metaphorically stabby.
- dakshgupta 10mo agoWe were trying not to insinuate that, because we don’t have a good way to measure quality, without which velocity is useless.
- rnewme 10mo ago[flagged]
- locusofself 10mo agoThis is definitely interesting information and I plan to take a deeper look at it. What a lot of us must be wondering though is: - how maintainable is the code being outputted - how much is this newfound productivity saving (costing) on compute, given that we are definitely seeing more code - how many livesite/security incidents will be caused by AI generated code that hasn't been reviewed properly
- dakshgupta 10mo agoWe weren’t able to agree on a good way to measure this. Curious - what’s your opinion on code churn as a metric? If code simply persists over some number of months, is that indication it’s good quality code?
- wordpad 10mo agoI've seen code entropy as the suggested hueriatic to measure.
- arcwhite 10mo agoI've seen code persist a long time because it is unmaintainable gloop that takes forever to understand and nobody is brave enough to rebuild it. So no, I don't think persistence-through-time is a good metric. Probably better to look at cyclomatic complexity, and maybe for a given code path or module or class hierarchy, how many calls it makes within itself vs to things outside the hierarchy - some measure of how many files you need to jump between to understand it
- refactor_master 10mo agoI second the persistence. Some of the most persistent code we own is because it’s untested and poorly written, but managed to become critical infrastructure early on. Most new tests are best-effort black box tests and guesswork, since the creators have left a long time ago. Of course, feeding the code to an LLM makes it really go to town. And break every test in the process. Then you start babying it to do smaller and smaller changes, but at that point it’s faster to just do it manually.
- nekooooo 10mo agoi'm a designer and even i know not to measure 'lines of code' as meaningful output or impact. are we really doing this?
- dakshgupta 10mo agoWe expressly did not conclude that more lines = better. You could easily argue more lines = worse. All we wanted to show is that there are more lines.
- poliphili 10mo agoLanguage like "productivity gains", "output" and "force multiplier" isn't neutral like you're claiming here, and does imply that the line count metric indicates value being delivered for the business.
- rsynnott 10mo ago> Lines of code per developer grew from 4,450 to 7,839 as AI coding tools act as a force multiplier. I mean, come on, now. "Force multiplier" is hardly ambiguous. We have known that this is a useless way to measure productivity since before most people on this site were born.
- simonw 10mo ago> Lines of code per developer grew from 4,450 to 7,839 as AI coding tools act as a force multiplier. Is that a per-year number? If a year has 200 working days that's still only about 40 lines of code a day. When I'm in full-blown work mode with a decent coding agent (usually Claude Code) I'm genuinely producing 1,000+ lines of (good, tested, reviewed) code a day. Maybe there is something to those absurd 10x multiplier claims after all! (I still think there's plenty of work done by software engineers that isn't crunching out code, much of which isn't accelerated by AI assistance nearly as much. 40 lines of code per day felt about right for me a few years ago.)
- rnewme 10mo ago1k loc per day or 1k git additions? I don't think one person can consistently review 1k loc, and grow codebase at that speed and size and classify it as good, tested and reviewed.. Can you tell us more about your process?
- simonw 10mo agoI'm effectively no longer typing code by hand: I decide what change I want to make and then prompt Claude Code to describe that change. Sometimes I'll have it figure out the fix too. An example from earlier today: https://github.com/simonw/llm-gemini/commit/fa6d147f5cff9ea91a49661a7d4311ca2cdcea97 https://github.com/simonw/llm-gemini/commit/fa6d147f5cff9ea9... That commit added 33 lines and removed 13 - so I'm already at a 20-lines-a-day level just from that one commit (and I shipped a few more plus a release of llm-gemini: https://github.com/simonw/llm-gemini/commits/a2bdec13e03ca8a72f2e317cb75d8cde8016e333/ https://github.com/simonw/llm-gemini/commits/a2bdec13e03ca8a...) It took about 3.5 minutes. I started from this issue someone had filed against my repo: Then I opened Claude Code and said: Run this command: uv run llm -m gemma-3-27b-it hi That ran the command and returned the error message. I then said: Yes, fix that - the gemma models do not support media resolution Which was enough for it to figure out the fix and run the tests to confirm it hadn't broken anything. I ran "git diff", thought about the change it had made for a moment, then committed and pushed it. Here's the full Claude Code transcript: https://gistpreview.github.io/?62d090551ff26676dfbe54d8eebbcfd3 https://gistpreview.github.io/?62d090551ff26676dfbe54d8eebbc... I verified the fix myself by running: uv run llm -m gemma-3-27b-it hi I pasted the result into an issue comment to prove to myself (and anyone else who cares) that I had manually verified the fix: https://github.com/simonw/llm-gemini/issues/116#issuecomment-3666551798 https://github.com/simonw/llm-gemini/issues/116#issuecomment... Here's a more detailed version of the transcript including timestamps, showing my first prompt at 10:01:13am and the final response at 10:04:55am. https://tools.simonwillison.net/claude-code-timeline?url=https%3A%2F%2Fgist.githubusercontent.com%2Fsimonw%2F256daef2abc32e36d2599fb207c073c2%2Fraw%2Ff1be8f73581b4351a4c4aeab07080a880742acfa%2Fclade.jsonl https://tools.simonwillison.net/claude-code-timeline?url=htt... I built that claude-code-timeline application this morning too, and that thing is 2284 lines of code: https://github.com/simonw/tools/commits/main/claude-code-timeline.html https://github.com/simonw/tools/commits/main/claude-code-tim... - but that was much more of a vibe-coded thing, I hardly reviewed the code that was written at all and shipped it as soon as it appeared to work correctly. Since it's a standalone HTML file there's not too much that can go wrong if it has bugs in it.
- TuringNYC 10mo agoKudos to the designer, this site is beautiful.
- zkmon 10mo agoI take this "code-output" metrics with a pinch of salt. Ofcourse, a machine can generate 1000 times more lines of code similar to a power loom does. However, the comparison with power loom ends there. How maintainable is this code output? I saw a SPA html file produced by a model, which appeared almost similar to assembly code. So if the code can only be maintained by model, then an appropriate metric should should be based on a long-term maintainability achieved, but not on instant generation of code.
- hvb2 10mo agoAgreed, I stopped reading at that point. You can't take yourself seriously to create a report and use LOC as your measure. I feel like we humans try to separate things and keep things short. We do this not because we think it's pretty, we do it so our human brains can still reason about a big system. As a result LOC is a bad measure as being concise then hurts your productivity????
- dakshgupta 10mo agoWe're careful not to draw any conclusions from LoC. The fact is LoCs are higher, which by itself is interesting. This could be a good or bad thing depending on code quality, which itself varied wildly person-to-person and agent-to-agent.
- mrdependable 10mo agoCan you expand on why it is interesting?
- zed31726 10mo agoBecause it's different. Change is important to track
- hvb2 10mo agoWhen the heading above it says "Developer output increased by x" I think you're very much drawing conclusions
- deleted 10mo ago[deleted]
- nik0xffff 10mo ago[flagged]
- superchris 10mo agoThis thing that can't be measured is up 76%. Eyeroll
- vb-8448 10mo agoIn the engineering team velocity section, the most important metric is missing: change rate of new code or how many times it is change before being fully consolidated.
- dakshgupta 10mo agoThis is a great suggestion. I'll note it down for next years. Curious, do you think this would be a good proxy for code quality?
- all2 10mo agoI would consider feature complete with robust testing to be a great proxy for code quality. Specifically, that if a chunk of code is feature complete and well tested and now changing slowly, it means -- as far as I can tell -- that the abstractions contained are at least ok at modeling the problem domain. I would expect code that continually changes and deprecates and creates new features is still looking for a good problem domain fit.
- dakshgupta 10mo agoMost of our customers are enterprises, so I feel relatively comfortable assuming they have some decent testing and QA in place. Perhaps I am too optimistic?
- all2 10mo agoThat sounds like an opportunity for some inspection; coverage, linting (type checking??), and a by-hand spot check to assess the quality of testing. You might also inspect the QA process (ride-along with folks from QA).
- vb-8448 10mo agoIt's tricky, but one can assume that code written once and not touched in a while is good code (didn't cause any issues, performance is good enough, ecc). I guess you can already derive this value if you sum the total line changed by all PRs and divide it by (SLOC end - SLOC start). Ideally it must be a value slightly greater than 1.
- magicloop 10mo agoYour graphs roughly marry up with my anecdotal experience. After a while, when you know when and how to utilize LLMs/agents, coding does become more productive. There is a discernible improvement in productivity at the same quality level. Also I notice it when the LLMs are offline. It feels a bit like when the internet connect fails. You remember the old days of lower productivity. Of course, there is a lot of junk/silly ways to approach these tools but all tools are just a lever, and need judgement/skill to use them well.
- wessorh 10mo agoclearly selling the report to business people whom don't code. Like most things in the AI arena today, the report is BS about a system the mostly create technical debt and is sold as intelligence.
- dandaka 10mo agoWhy are we still measuring velocity in lines of code in 2025?
- shruubi 10mo agoSo not only are we measuring lines of code as a productivity metric as though that has any actual relation to productivity, but across the board they are boasting that lines of code is going up and PR density is getting bigger as well. Those numbers should be seen as a giant red flag, not as any kind of positive.
- heliumtera 10mo agoCreate an automated tools that inserts comments and line breaks wherever it's possible. Productivity multiplied by 10^23. With humans being this stupid, I'm not that impressed they confused llms to human cognition. Maybe it truly is a replacement.
- citizenpaul 10mo agoOh wow, this is the revolving door of dumb. KLOC's KLOC's KLOC's Even Steve Balmer was smart enough to realize LOC was a dumb metric. To add some substance. Many regard a great deal of IBM's decline to managements near obsession with developer LOC metrics, driving out skilled employees.
- jp0d 10mo agoThe site/visualisations look great. But having used AI tools in my programming, I still haven't been able to justify the cost (to the planet too) vs benefit. I've noticed that it's great for pattern recognition and if I've missed something small or missed a variable name here and there, then it's quite good at finding those problems. However, if I ask it to produce a complete piece of work, I've never been able to get something without any bugs. Forget about getting it to design data pipelines with customer privacy and data security in mind! For reference I work in finance/econometrics and the code is often about numerical analysis written in SQL and python. More often than not I end up wasting a lot of time fixing issues with AI generated code. None of these nuances ever gets captured by metrics like these and it makes me question people (mostly sales and top execs) that push for "AI" at work.
- gerdesj 10mo agoWhy not have a crack with a local LLM or two? You work in an industry with a lot of money involved. Recently Apple have released beasties with up to 512GB of RAM. Apples have unified RAM (both for general use and GPU) so that 512GB looks a bit handy, and they have quite a lot of CPU cores too. They are of the order of £10,000. You should be able to run some pretty large models on that. I've just blown a fair bit of money on network infra (yum: more switches that boot Linux for the control plane and shuffle packets at incredible speeds) at work so will need to wait a bit or perhaps persuade wifie that we really do need a really expensive Apple box at home. The snag I have is getting over my mild distaste for Apple! I'm sure I'll manage it.
- jp0d 10mo agoEnvironmental restrictions! All our data is on cloud and for customer privacy we're not allowed to download anything locally. We've access to most of the LLM models from all big vendors. I've found them to be very similar.
- deleted 10mo ago[deleted]
- tbrownaw 10mo ago>measuring productivity by lines of code I wrote zero lines of code today. I read some code and some emails, and wrote a few lines of markdown and some short emails. All of the code I've written in the past couple weeks was meant to be thrown away. I used it to make some notes, which ended up condensed into those few lines of markdown.
- catoc 10mo agoIf you ask two humans to explain a problem to you, and human 1 takes an hour to explain what human 2 explained in 5 minutes… everyone would consider human 1 LESS ‘productive’ than human 2. But what if human 2 was wrong? What if both were wrong and human 3 simply said ‘I don’t know’. LoC is a measure ripe for ignorance driven managerial abuse. We’ve all seen senior devs explain concepts to junior devs, increasing their understanding and productivity while they themselves ‘produced’ zero lines of code. Yes zero LoC maybe point to laziness; or to proper preparation. All this is so obvious. LoC are easy to count but otherwise have hardly any value
- Rperry2174 10mo agoLOC is a bad quality metric, but its a reasonable proxy in practice.. Teams generally don't keep merging code that "doesn't work" for long... prod will brake, users will push back fast. So unless the "wrongness" of the AI-generated code is buried so deeply that it only shows up way later, higher merged LOC probably does mean more real output. Its just not directly correlated there is some bloat associated too. So that caveat applies to human-written code too, which we tend to forget. There's bloat and noise in the metric, but its not meaningless
- catoc 10mo agoAgreed, there is some correlation between productivity and LoC. That said the correlation it’s weak; and does not say anything about quality (if anything quality might be inversely correlated; which too would be a very weak signal)
- frizlab 10mo agoFor instance if I push 10kloc that are in a lib I would have used if I were not using AI, yes, I have pushed much more code, but I was not more productive.
- bicepjai 10mo agoI take it as greptile folks know LOC metric is in no way a metric that can be correlated to productivity in LLM era. But putting aside that just knowing how much code is going thru their system seems interesting enough to read the report. Thanks for the dot matrix report.
- lemonish97 10mo agoNot sure if it's a TPU constraint, but according to this report it seems like the Gemini models have really poor TTFT and tps inference times.
- topisan 10mo agoloved this, thank you
- johnnyasantos 9mo agotbh this seems to built upon the narrative that AI Coding is actually better. Gitclear report from last year still provides better insights on code quality. Downloading sdks, ttft, price comp means absolutely nothing to code (I supposed that's what the report is about).