Hacker News

I would reframe this as: Quality was always a significant bottleneck and is even more so with agentic coding.

Code review is where many of the design & code quality problems are observed/highlighted.

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.

> 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 actually dislike traditional code review. In part this is because most of our code review tools are very cumbersome to use (GitHub's and GitLab's web interfaces in particular).

But also because humans aren't all that great at code review when it comes to correctness and security. Part of the problem is that you don't have access to the author's mental model for non-trivial changes and have to reconstruct it, otherwise your understanding of the program logic will be inadequate.

The problem is that purely agentic code review has orthogonal problems, and typically remains subpar when it comes to judging architecture and design considerations, compared to human reviewers. Both false positives and false negatives also remain a concern.

My best results so far have been with agent-assisted code review in a proper IDE, helping you to quickly construct a mental model and to analyze the underlying logic (in addition to having agents do a first pass for correctness issues).

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.

As a senior engineer that is struggling to give up line-by-line reviews, I agree with your take.

I've spent literal decades where one of the most valuable practices has been code reviews, for many dimensions. It is one of the best ways to ensure quality production releases. It is one of the best ways to transfer skill to junior engineers. It increases tribal knowledge throughout the engineering org by exposing others to systems they may not be working in. The number of benefits to a traditional human-centric engineering team is hard to overstate.

But I'm starting to feel that instead of starting at one extreme (heavy handed reviews) and moving towards less review, it probably makes more sense to start at the other extreme (no review at all) and move towards a brand new practice tailored for the new agentic reality.

It is looking increasingly likely that we don't need to modify code review for the agentic era, we need some completely new practice that hasn't yet been invented.

It's not code review that's slowing things down. It takes time to get the thing you want, and then you have to be reasonably sure that it's right anyway, or you risk shipping a piece of crap to production and tanking your own reputation. Even on teams that rubber stamp PRs I see people pushing drafts and waiting to merge until they feel comfortable with what they've vibed out.

I lean towards a hybrid review process where humans accept their limitations, focus what they're good on(higher level concepts and architecture of the proposed change), and let the LLMs do the rest.

Doing a line by line review as a human is silly now.

We're going to need to start putting the month in brackets after the article title, not just the year!

> 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.

Why do you feel like that? Agents have got better but better how? Looking at the frontier model output, I’d say the same myopic approach that causes long term issues without frequent course correction is still there.

> shipping significantly faster

If you're right (and you probably are), we're in for a wild ride further down the quality death spiral.

The era of user telemetry and conversion tracking already decoupled product design from customer experience. No need to wait for customer's to articulate their experience or desires or for discerning analysts to amalgamate and ponder their opinions. The numbers tell you everything you need to know! Just throw 3000 pounds of spaghetti at the wall every month and wait to see what sticks.

But now you really were bottlenecked on engineering.

Only 3000 pounds of spaghetti per month? And throwing more bodies at it barely even makes a difference? Oof.

Of course the solution is to just flush pureed spaghetti-slop through the hose as fast as we can. Brilliant!

What could wrong? The users are sure to love it. We'll know because they keep clicking. That's how they tell us the truth, even as every forum fills with louder and louder complaints!

The study was updated in August 2026.

> 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've been hearing this for more than a year. But if these startups are all moving at superhuman speed, a month instead of a year from idea to a shipping product, where are the products? Every time I ask that, people talk about the amazing velocity gains they experience for the thing they are about to ship. It never does, unless we count throwaway hobby projects at GitHub - by that metric, AI is adding a lot of software. And I guess never-downloaded slop-games on mobile app stores.

But if you actually go shopping for consumer or enterprise software that's camera-ready, the landscape is basically the same as in 2022.

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.

What could possibly go wrong?

My experience with prototyping games is that you need very strong human driven guidance and review in the beginning, then you can increasingly take your hands off the wheel.

If you take it off too early you end up with shit and will spend weeks fixing all these baked bad assumptions your project is built on top of. I spent weeks fixing some of this shit then the LLM revived a not insignificant portion of it in a later change because it got "confused" (its words) because some of the comments it previously made were left around.

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

[flagged]

[dead]

> 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.

Both Claud and Codex would run circles around 80% of the developers I’ve worked with through my 20 year long career. This whole code review thing is a hold over that probably won’t last six months.

"The overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used" - Amdahl's Law

Or we could just recognize these llms crank out poorly architected bug infested slop. The coding work of these llms is just as garbage as all the other bland, flat, wtf writing they crank out with prose. Even worse because there's no logical mind behind the garbage. With bad human written code there was at least one human there thinking about it.

The study was updated twice with the last time on August 2026.

They've updated it for the agentic code era, and have found basically the same thing. Code can be created faster but that has moved the bottleneck to review.

> 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.

What we have today is not meaningfully better than what we had a year ago, so that isn't relevant.

I review code line by line and build a mental model of the software as I review it. I find plenty of important bugs that way. PRs are an opportunity to learn (both committer and reviewer), communicate, and improve the quality of code a team ships. Sadly, many people decline that opportunity for the sake of short-term velocity.

I’ve caught bugs in code reviews before, but I would agree that it’s probably not the most crucial thing you should strive to do with code reviews.

That said, I think I’ve done a tremendous amount of PREVENTING bugs from being introduced via code review. Caught all kinds of weird code patterns, duplication, wrong levels of abstraction, etc. Essentially, the kinds of places that bugs like to hide and grow in.

I still think that’s valuable, and it’s the kind of thing that models generally aren’t great at, to this day. It generally relies on having a large amount of context about the project and about what’s being solved, so if you wanted to do this via automated review, you maybe COULD, but it would probably get pretty expensive, especially on larger projects.

The best code review process I've done are more like oral exams ie: the person walks through the changes and we listen as they describe it.

It's a good way to catch thinking errors, which are the insidious errors.

It was more important for giant C or fortran code bases. You will legit catch pointer errors or memory mgmt stuff, going line by line. Once Sun busted in with Java is when I really saw the shift to skim reviews. So much stuff is caught by compilers now, or SAST, that using dev time to find code smells is mostly a waste of their time. And it's not like the old way caught everything, it's just that the stuff we take for granted being caught by compilers or Sonarqube now, just used to get shipped to prod and cause abends and production support calls at 3am.

I think it highly depends on what field you're in. Personal projects that I find useful in my everyday life? Churning them out like crazy. Enterprise software? It has slowed our productivity down to a halt--part of this is due to people not knowing how to use these tools, and the other part of it is the collective AI psychosis of our leadership (I work at a Fortune 500 software company).

Yes, I am literally inundated by cool new tools I've built that I never would have before.

I'm literally building a black-box client + server emulator for one of my favorite old MMOs, remotely, from a coffe shop in SF as I type this, on my laptop at home via Claude remote-control.

Insane.

Organizations that use Jira have not reaped efficiency gains from AI, news at 11

Based on a sample size of one or…?

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.

This stuff is still 90% garbage hype. See also:

https://www.youtube.com/watch?v=NnV_cWeoo5Q&list=LL&index=3

You read the paper, saw that the stated collection dates ranged from January 2021 to March 2026, and are claiming the authors are lying?

What kind of professional would spend 4 hours of their time per day playing video games?

The true professionals spend those 4 hours making snarky Hacker News comments.

Listen man. Let me give you a tip.

Don't take it seriously.

Efficiency is not your job, until you can 1) solve it, 2) present the solved and implemented problem to senior leadership in one fell swoop.

Corporate America is a giant slush fund and this is how it keeps going.

Be grateful!

I would be more concerned with playing video games half the day than whether the PMs are slowing you down by figuring out the requirements

Ars Technica in general has also been catering to their knee-jerk anti-AI audience. I used to find their comments section somewhat interesting but now it's the same old tired, outdated dunks on AI.

I confirm this diagnosis. The UIs are always clunky, disorganized, and kinda ugly. But they work well enough. I guess UIs are opinionated enough that we probably all customize them anyway. Maybe the agents know this so don't bother putting too much effort in? (Deep thought of the day: acquired)

We got rid of end to end QA as head of engineering decided to "shift left" on automation.

The paper was updated in August this year.

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.

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.

That's pretty sick.

The link is a piece of crap wrapped in candy packaging, able to fool anyone who couldn't be bothered to unwrap the candy. DOA slop. It has nothing to do with either art or craft. This is actually a perfect example why agents' code cannot be trusted.