This is from March 2026, but it does match what I've encountered professionally. Code review was always a significant bottleneck and is even more so with agentic coding. We've had discussions about leaning more on automated review, but it hasn't translated into any practical improvements so far. I think senior engineers find it very difficult to give up on line-by-line review, no matter how much better the agents have gotten.
I think if there is a major change in code review culture, it's not going to happen first in established engineering teams. It'll happen in startups that adopt a no-human-review policy from jump and then maintain it as they mature. I'm sure that's happening, but it's likely invisible to most studies and surveys at the moment. If it proves successful, and such companies start shipping significantly faster, the rest of the industry will be forced to adopt.
We shouldn't give up on line-by-line review for serious applications.
My company's leadership is oscillating every few weeks on AI goals. Their most recent story is "we're expecting developer velocity to approximately double over the new 2-3 years as people get better at using AI". But of course that's completely non sequitur. People on my team spend about 10% of their time writing code and 90% doing design and analysis. So if AI doubles our code writing velocity, then it will make us 5% faster overall.
You don't give up on line-by-line review just because the human is getting better either, and senior engineers want other people to do line by line review on their own code. It's not a matter of how good or bad the person or program generating the code is.
I agree. The latest models are getting quite good at validation, as long as they are clear on what the requirements are. Recently I got frustrated that while we have a huge test suite I noticed the LLM was hardly ever breaking a test with its changes (PRs only added tests, never changed old ones) which seemed suspicious.
I had it do a full audit. There were about 100k lines of tests, of which it determined about 60k were near useless. Many were overly mocked, some mocked to the point that they really weren't testing anything at all. It deleted those and wrote more expansive scenario tests to replace them, caught a lot of bugs on the way and fixed those too. Total time was about 2 hours.
I think humans need to review requirements, specifications, and test scenarios. And for some industries and uses they're still going to have to review every detail. But for a typical CRUD app, I think we're at a point where we can already set the process and quality bar higher than ever, in addition to moving faster.
Glad to see someone else notice this. I dread looking at or dealing with AI written unit tests because of the incredible amount of whiteboxing that goes on, though usually for the opposite reason because AI testing is almost entirely whitebox testing which fails if some internal details change
You have to classify each code review based on what it changes and decide how to handle it, agent review and/or human review. You can have an agent do that.
I think non-senior engineers don’t realize just how much of a burden is barely reviewed ai generated code.
I’ve seen a few projects that heavily rely on ai with not very good (though senior) devs driving it - and its a mess. Not the code. The resulting product. Code is actually sound as ai is pretty good now.
All because ai does code reviews and dump decisions go into prod
> I think senior engineers find it very difficult to give up on line-by-line review
i am pretty senior. I hate code reviews so much. They are so boring, easily the most tedious part of my job. Its such a chore. Who is clinging to line-by-line review. Ppl dont really give that much about their employers.
It really depends on the context. A react button background color - meh - the critical part of the backend where a new 300ms delay will cost the company millions then yeah.
> the critical part of the backend where a new 300ms delay will cost the company millions then yeah.
If it is so critical, why don't we have tests and benchmarks for it?
Oh right, because "Greg the super-coder" never wrote any of this down and it lives in his head so he can be the arbiter of change.
It was toxic before agentic coding, it's still toxic now.
Document your systems. Add tests and benchmarks for what is important.
We've always known this, we have a dozen or more textbooks written about it. But we always gave it a pass because "Greg the super-coder" was producing more value than he was hurting.
That's no longer the case. Your best coder is now Opus or Astra
I read this paper several days ago, when my director shared it. Several things jumped out at me:
- the data is mostly from 2025 and earlier
- the baseline mean lines of code per month was 5017, the estimated increase was 1494 lines per worker-month
- the baseline is 5.34 PRs per month, and increased by 1.22
- the baseline mean for code review is 7.03 days
The second and third bullets are confirmation that this is old data. In late 2026, people aren't delivering 30% more lines of code. If people were just producing 30% more lines, they'd still be reading every line. My point isn't that "more lines is good". I'm worried about a few too many lines of code that no one reads. My point is that this shows the data is old.
For the latter, I'm a bit annoyed by using mean, median would be more valuable, but I think it's safe to say that the engineering culture was already pretty bad. If your average pull request sits for 7 days, you evidently don't care about shipping anything, and agents aren't going to change that.
Given what I've been able to accomplish with even just local models at home, and my experience at my day job, I imagine this has almost everything to do with the organizations themselves and less to do with using AI to build software.
As is standard for academic papers, this is an attempt to describe the state of the world as of when they did the research. But then it takes time to write it up and get it out, after which newspapers report it as current events.
In this case, we're looking at a picture from 2025. The models involved in the main agent results were primarily Claude 3.5 through Sonnet 4.5, GPT-4.1 through GPT-5, and Gemini 2.5. And the paper's design means you're mostly looking at the very initial effects of deployment, before companies developed good review processes.
I’d strongly disagree with one aspect. Homemade personal use software has Definately skyrocketed. Projects I never thought I’d even have the time for are now possible.
I'm noticing AI catching many bugs in code that previously went unnoticed. Some of them are important, and it's great to catch them early.
The other 11 items in the list of 12 would probably never be hit in practice, but now that you know, you have to sort out how to handle each (even if that just means documenting, filing, or ignoring: you have to understand each of the disparate 12 issues first.)
Before it was all coding on its own, I asked a model for bugs in a new project, saved me the 15 minutes of new web project I waste every time trying to remember obscure first time setup things you dont touch for years in under a minute.
I suspect theres a lot of hours saved that are otherwise wasted by devs when some simple thing throws off their implementation completely. Basically we cant measure the saved developer hours by LLMs because it could be literally anything.
I'm completely uninterested in the opinion of a video game journalist on what does and doesn't work well in writing software. The author knows about as much about writing code as he knows about performing heart surgery
Way back in the day, everyone wrote assembly. Then things like C came around, which had to be compiled to assembly, and most people objected: "I don't want to be that far from what the CPU is doing!".
Each time we move up an abstraction layer, people object, saying that nothing will work right if we move up that high in the stack. Give it time. I'll bet in 5-10 years, almost no one will look at code anymore, except in special cases.
We still have people who write in assembly, we still have people who write in C, mostly for performance reasons. Because you still need to be close to the CPU to get that last bit of performance. But in most cases, it doesn't matter. It doesn't matter if the LLM makes bad code if it works and passes all the tests.
Granted, this is the first time we're going from deterministic to non-deterministic, but is it really? Large scale distributed systems are already non-deterministic. They create inputs and situations that programs aren't designed to handle all the time. What's a little more chaos? :)
Aside from other comments mentioning flaws and cutoff of study, anyone in the industry or even working on hobby products can say this conclusion is wrong.
They generate more software too. It's just organizations haven't adapted to remove the bottlenecks yet. I replaced so much software for my self and its better than all the alternatives I used to use. And there are tons of other people doing the same thing.
Wrong thing to index on. Always bet on the slope, not on points in the slope. Things will only get better and better and factor in that downward slope thought while taking actions and pick ones that are favorable. The folks who focus on a point in time will be left behind, period.
Along these lines: agents will write mountains of super repetitive test code, seemingly uninterested in refactoring it (without explicit instruction) to reduce redundancies.
In any non-trivial integration test scenario, it's easy to end up several times the LoC in tests compared to actual shipped code.
Second problem: different models, agents, and harnesses seem to have different tendencies and they tend to avoid touching code that is not their own unless explicitly instructed. What I mean by this: it will happily duplicate some helper method from another test file rather than pulling it out and reusing it, seemingly avoiding coupling (good kind in this case since model level changes should be propagated atomically).
Tests are where I see agents just spew absolute mountains of code.
When people have gotten excited about having so many tests, I've asked them what their plan is when 500 of their 1000 test suddenly stop passing. I've always favored 50 tests I know are meaningful, where any failure is something to respond to, over 500 tests with a bunch of overlap and edge cases I'm not sure matter. But now people aren't even thinking about that, they're just letting the agents make all those decisions.
I think this approach will continue to work for some people and orgs, but others are going to hit walls where their agents can't manage the mountains anymore. It's going to be interesting to see how people and orgs respond when that happens.
> I've asked them what their plan is when 500 of their 1000 test suddenly stop passing
That's not a terrible thing; would indicate that some shared behavior is broken and -- assuming well structured code -- hopefully easy to isolate the behavior.
Bigger problems to me are more practical: 1) large tests waste context both in and out, 2) large volume of tests waste CI cycles which are becoming the bottleneck.
Every senior I've ever worked with at some point embraced the idea of minimalism. Produce minimal changes with a minimal surface. Worked well at startups and especially well on large spaghetti legacy projects. Seeing all of a sudden now how suddenly number of kLocs, PRs, token maxxing, number of tasks in progress is again a metric with which non-engineers brag about on engineering conferences feels like the industry has reverted to some braindead pre-infant state. I guess all mistakes need to be relearned at every hype cycle.
Maybe but I’d argue the frontier corps will self destruct via green annd product management enough to make this impractical. So far here’s how I see that going
1) can’t easily autopilot due to security. Ganna keep on prompting you into running weird shell commands
2) it’ll launch your code on weird Anthropic or ChatGPT sites behind a paywall
3) between the two of them it’ll
Misalign the solution so it’s unusable
This is from March 2026, but it does match what I've encountered professionally. Code review was always a significant bottleneck and is even more so with agentic coding. We've had discussions about leaning more on automated review, but it hasn't translated into any practical improvements so far. I think senior engineers find it very difficult to give up on line-by-line review, no matter how much better the agents have gotten.
I think if there is a major change in code review culture, it's not going to happen first in established engineering teams. It'll happen in startups that adopt a no-human-review policy from jump and then maintain it as they mature. I'm sure that's happening, but it's likely invisible to most studies and surveys at the moment. If it proves successful, and such companies start shipping significantly faster, the rest of the industry will be forced to adopt.
We shouldn't give up on line-by-line review for serious applications.
My company's leadership is oscillating every few weeks on AI goals. Their most recent story is "we're expecting developer velocity to approximately double over the new 2-3 years as people get better at using AI". But of course that's completely non sequitur. People on my team spend about 10% of their time writing code and 90% doing design and analysis. So if AI doubles our code writing velocity, then it will make us 5% faster overall.
I wish they taught Amdahl's law in business school. Or at the very least the simple concept of "bottleneck".
"The Goal" is a key business book for a reason, but leadership seems to not get the lesson. Or care?
Is your company striving to automate design and analysis, then?
> We shouldn't give up on line-by-line review for serious applications.
But how many changes are actually serious?
I can have an agent mass-produce security bug fixes, zip through our low-priority backlog, etc.
IMO - we need to get out of our own way.
Building is cheap now. Agents are also really good at following checklists and running tests.
So instead of having individual engineers reviewing code, we need to
* Leave human review for the most impactful changes
* Get better at defining the quality bar
* Continually codify human concerns into rules or systems that can be checked against
A lot of this was touched on a few months ago with Spec-driven development becoming a hot topic when agentic coding started.
We should continue that with spec-driven review, testing, etc.
[delayed]
You don't give up on line-by-line review just because the human is getting better either, and senior engineers want other people to do line by line review on their own code. It's not a matter of how good or bad the person or program generating the code is.
I agree. The latest models are getting quite good at validation, as long as they are clear on what the requirements are. Recently I got frustrated that while we have a huge test suite I noticed the LLM was hardly ever breaking a test with its changes (PRs only added tests, never changed old ones) which seemed suspicious.
I had it do a full audit. There were about 100k lines of tests, of which it determined about 60k were near useless. Many were overly mocked, some mocked to the point that they really weren't testing anything at all. It deleted those and wrote more expansive scenario tests to replace them, caught a lot of bugs on the way and fixed those too. Total time was about 2 hours.
I think humans need to review requirements, specifications, and test scenarios. And for some industries and uses they're still going to have to review every detail. But for a typical CRUD app, I think we're at a point where we can already set the process and quality bar higher than ever, in addition to moving faster.
Glad to see someone else notice this. I dread looking at or dealing with AI written unit tests because of the incredible amount of whiteboxing that goes on, though usually for the opposite reason because AI testing is almost entirely whitebox testing which fails if some internal details change
You have to classify each code review based on what it changes and decide how to handle it, agent review and/or human review. You can have an agent do that.
I think non-senior engineers don’t realize just how much of a burden is barely reviewed ai generated code.
I’ve seen a few projects that heavily rely on ai with not very good (though senior) devs driving it - and its a mess. Not the code. The resulting product. Code is actually sound as ai is pretty good now.
All because ai does code reviews and dump decisions go into prod
> I think senior engineers find it very difficult to give up on line-by-line review
i am pretty senior. I hate code reviews so much. They are so boring, easily the most tedious part of my job. Its such a chore. Who is clinging to line-by-line review. Ppl dont really give that much about their employers.
> Who is clinging to line-by-line review.
It really depends on the context. A react button background color - meh - the critical part of the backend where a new 300ms delay will cost the company millions then yeah.
> the critical part of the backend where a new 300ms delay will cost the company millions then yeah.
If it is so critical, why don't we have tests and benchmarks for it?
Oh right, because "Greg the super-coder" never wrote any of this down and it lives in his head so he can be the arbiter of change.
It was toxic before agentic coding, it's still toxic now.
Document your systems. Add tests and benchmarks for what is important.
We've always known this, we have a dozen or more textbooks written about it. But we always gave it a pass because "Greg the super-coder" was producing more value than he was hurting.
That's no longer the case. Your best coder is now Opus or Astra
> new 300ms delay will cost the company millions
these might be 1% typically
I read this paper several days ago, when my director shared it. Several things jumped out at me:
- the data is mostly from 2025 and earlier
- the baseline mean lines of code per month was 5017, the estimated increase was 1494 lines per worker-month
- the baseline is 5.34 PRs per month, and increased by 1.22
- the baseline mean for code review is 7.03 days
The second and third bullets are confirmation that this is old data. In late 2026, people aren't delivering 30% more lines of code. If people were just producing 30% more lines, they'd still be reading every line. My point isn't that "more lines is good". I'm worried about a few too many lines of code that no one reads. My point is that this shows the data is old.
For the latter, I'm a bit annoyed by using mean, median would be more valuable, but I think it's safe to say that the engineering culture was already pretty bad. If your average pull request sits for 7 days, you evidently don't care about shipping anything, and agents aren't going to change that.
Given what I've been able to accomplish with even just local models at home, and my experience at my day job, I imagine this has almost everything to do with the organizations themselves and less to do with using AI to build software.
As is standard for academic papers, this is an attempt to describe the state of the world as of when they did the research. But then it takes time to write it up and get it out, after which newspapers report it as current events.
In this case, we're looking at a picture from 2025. The models involved in the main agent results were primarily Claude 3.5 through Sonnet 4.5, GPT-4.1 through GPT-5, and Gemini 2.5. And the paper's design means you're mostly looking at the very initial effects of deployment, before companies developed good review processes.
I’d strongly disagree with one aspect. Homemade personal use software has Definately skyrocketed. Projects I never thought I’d even have the time for are now possible.
Organizations that use Jira have not reaped efficiency gains from AI, news at 11
I'm noticing AI catching many bugs in code that previously went unnoticed. Some of them are important, and it's great to catch them early.
The other 11 items in the list of 12 would probably never be hit in practice, but now that you know, you have to sort out how to handle each (even if that just means documenting, filing, or ignoring: you have to understand each of the disparate 12 issues first.)
Before it was all coding on its own, I asked a model for bugs in a new project, saved me the 15 minutes of new web project I waste every time trying to remember obscure first time setup things you dont touch for years in under a minute.
I suspect theres a lot of hours saved that are otherwise wasted by devs when some simple thing throws off their implementation completely. Basically we cant measure the saved developer hours by LLMs because it could be literally anything.
I'm completely uninterested in the opinion of a video game journalist on what does and doesn't work well in writing software. The author knows about as much about writing code as he knows about performing heart surgery
Way back in the day, everyone wrote assembly. Then things like C came around, which had to be compiled to assembly, and most people objected: "I don't want to be that far from what the CPU is doing!".
Each time we move up an abstraction layer, people object, saying that nothing will work right if we move up that high in the stack. Give it time. I'll bet in 5-10 years, almost no one will look at code anymore, except in special cases.
We still have people who write in assembly, we still have people who write in C, mostly for performance reasons. Because you still need to be close to the CPU to get that last bit of performance. But in most cases, it doesn't matter. It doesn't matter if the LLM makes bad code if it works and passes all the tests.
Granted, this is the first time we're going from deterministic to non-deterministic, but is it really? Large scale distributed systems are already non-deterministic. They create inputs and situations that programs aren't designed to handle all the time. What's a little more chaos? :)
Aside from other comments mentioning flaws and cutoff of study, anyone in the industry or even working on hobby products can say this conclusion is wrong.
The paper is from January, so the data is probably from 2025. Very unlikely anything in the paper is relevant now (if it ever was).
They generate more software too. It's just organizations haven't adapted to remove the bottlenecks yet. I replaced so much software for my self and its better than all the alternatives I used to use. And there are tons of other people doing the same thing.
Wrong thing to index on. Always bet on the slope, not on points in the slope. Things will only get better and better and factor in that downward slope thought while taking actions and pick ones that are favorable. The folks who focus on a point in time will be left behind, period.
Along these lines: agents will write mountains of super repetitive test code, seemingly uninterested in refactoring it (without explicit instruction) to reduce redundancies.
In any non-trivial integration test scenario, it's easy to end up several times the LoC in tests compared to actual shipped code.
Second problem: different models, agents, and harnesses seem to have different tendencies and they tend to avoid touching code that is not their own unless explicitly instructed. What I mean by this: it will happily duplicate some helper method from another test file rather than pulling it out and reusing it, seemingly avoiding coupling (good kind in this case since model level changes should be propagated atomically).
Tests are where I see agents just spew absolute mountains of code.
When people have gotten excited about having so many tests, I've asked them what their plan is when 500 of their 1000 test suddenly stop passing. I've always favored 50 tests I know are meaningful, where any failure is something to respond to, over 500 tests with a bunch of overlap and edge cases I'm not sure matter. But now people aren't even thinking about that, they're just letting the agents make all those decisions.
I think this approach will continue to work for some people and orgs, but others are going to hit walls where their agents can't manage the mountains anymore. It's going to be interesting to see how people and orgs respond when that happens.
Bigger problems to me are more practical: 1) large tests waste context both in and out, 2) large volume of tests waste CI cycles which are becoming the bottleneck.
Back up to the point where all the tests were passing, of course? Then debug.
Every senior I've ever worked with at some point embraced the idea of minimalism. Produce minimal changes with a minimal surface. Worked well at startups and especially well on large spaghetti legacy projects. Seeing all of a sudden now how suddenly number of kLocs, PRs, token maxxing, number of tasks in progress is again a metric with which non-engineers brag about on engineering conferences feels like the industry has reverted to some braindead pre-infant state. I guess all mistakes need to be relearned at every hype cycle.
Maybe for some orgs, I know theres orgs out there where there is no such review only QA and unit testing.
We got rid of end to end QA as head of engineering decided to "shift left" on automation.
I take both approaches. just /yolo or /goal or measure twice and cut once.
yolo works when I need to focus on higher priority, and make sure things just work (though not "great").
For the latter, I use it for more like spec-driven fashion with HITL. Basically everytime it ffinishes a task, I review and then move on.
Both appraoches work. just make sure your yolo slop isn't bad and passes stuff.
LoC don't mean jack shit.
Maybe but I’d argue the frontier corps will self destruct via green annd product management enough to make this impractical. So far here’s how I see that going 1) can’t easily autopilot due to security. Ganna keep on prompting you into running weird shell commands 2) it’ll launch your code on weird Anthropic or ChatGPT sites behind a paywall 3) between the two of them it’ll Misalign the solution so it’s unusable