| ▲ | staminade 6 hours ago |
| 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. |
|
| ▲ | cyb_ 5 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | cykros 25 minutes ago | parent | next [-] | | Agentic code review can also be employed, but it's worth noting that, as the so-called "Bitcoin Red Team" (which has been testing all of Bitcoin related software in the wake of the July 30 Coldcard attack) has discovered a very useful thing to consider: American models are absolute trash when it comes to reviewing code with an eye on security, due to their "safeguards." This applies even when the code being scanned for vulnerabilities was just written by the same agent. Kimi K3 seems to be the favorite there, though I believe some of the other open weight/open source models are being employed a bit as well. And yes, even that requires human oversight -- but it does a quick rough filter through things so you're not wasting time on the little stuff, allowing you more attention to find the glaring holes. | |
| ▲ | paimapi 4 hours ago | parent | prev [-] | | And test creation and maintenance. AI-generated tests will often embed existing bugs as testable patterns that fail when fixed or rely on empty asserts to increase coverage. A human author generally knows better. Coverage is increasingly becoming theater and you have runtime testing eating up CI resources and time with bloated, unnecessary, untargeted testslop that haven't been mutation tested or a human eye assessing if the business logic is actually represented. It's really the smaller firms which are able to learn quick adaptations that will win out in the long-run of this thing. Legacy firms with institutionalized bureaucracies are relying on gobbling up competitors and creating vertical monopolies while pushing out the worst slop - it's why GH goes down, why Meta products are buggy as hell now, and everything feels like it's unpolished MVPs these days. | | |
| ▲ | bunderbunder 2 hours ago | parent | next [-] | | So far this year, of the defects severe enough to warrant a formal RCA process that I’ve dealt with, “AI generated tests asserted that the defective behavior was correct,” was a contributing factor in every single one. | |
| ▲ | btown 3 hours ago | parent | prev [-] | | This. The ability to know that a vibe coded PR is all right to merge, is a function of both the thoughtfulness and simplicity of the underlying architecture, and the level of ownership that contributors have of the underlying products. Both benefit more nimble teams. |
|
|
|
| ▲ | svachalek 6 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | devin 6 hours ago | parent | next [-] | | I chuckle a little bit at this specification thing. We used to do this. We used to write big binders of specifications, and then we'd set about implementing them. We stopped doing it because it didn't really work. We'd learn things in the process of building which negated the value of the big specs we wrote. That's why we stopped doing it. This is where continuous improvement, CI/CD, tighter release cycles, etc. were all born. | | |
| ▲ | nightski 4 hours ago | parent | next [-] | | But why? On reason is that implementation was a bottleneck. That made it expensive to change a system once it was entirely implemented. It was better to get the feedback sooner so you didn't waste time implementing the wrong thing. The calculus on a lot of these old adages is changing. | | |
| ▲ | bigblind 3 hours ago | parent | next [-] | | I don't think this was only about implementation being the bottleneck. It was also because implementation forces you to think about the thing you're building at a very grannular level of detail, at which point you might discover flaws or opportunities that weren't obvious at the higher level. And I find that, when it reasons through and encounters some of those, it just makes assumptions rather than asking the user. | |
| ▲ | bunderbunder an hour ago | parent | prev | next [-] | | That phrase, “once it was entirely implemented,” is doing a lot of work. If you go back and read the literature on this stuff, one constant pattern is that technical leaders are repeatedly advocating for iterative development with frequent integration testing, and pushing back against management types’ impulse to favor giant up front over-specified design by committee plans. It’s not a phenomenon that’s unique to software, either. But managers love meticulous up-front specification because it gives them the illusion of control and predictability. They are always being asked, “How much will it cost? How long will it take?”, and this approach gets you there. I would argue that that’s the basic instinct behind meticulous up front specification for AI coding projects, too. It makes it easier to believe that, come implementation time, you can reliably one-shot it with an agent and have a working implementation that satisfies all design goals by next morning. | |
| ▲ | devin 4 hours ago | parent | prev | next [-] | | It is _still_ better to get the feedback sooner. Writing up some big specification, spending a bunch of tokens on implementation, and then shipping a massive PR to match the spec only to then find out it's wrong is a big waste of time. Nothing about writing grand plans in the face of unknown unknowns has changed. The more things change, the more they stay the same. | |
| ▲ | mrothroc 2 hours ago | parent | prev | next [-] | | Fred Brooks famously advised us to plan to throw one away. That was in the days of waterfall engineering. The reason he said that is because the best way to learn how to properly build a complex system is by going through the process of building it. Sure, implementation is a bottleneck, but the real problem is that the experience of development is the best teacher. Personally, I try to bring this lesson into my agentic coding practice by doing spikes and trial implementations first. This is where the AIs really deliver value: they can quickly build something out that touches a lot of the architecture so both it and I can get the proper shape of it. Only after that do I unleash it, constrained by what we learned. | |
| ▲ | ipsi 2 hours ago | parent | prev [-] | | Well, kind of. I think this is an interesting opinion on that: https://www.mountaingoatsoftware.com/agile/the-cost-of-chang... Which could be summarised by a single line: "In other words, the primary cost of change increasingly becomes feedback delay, not development effort." |
| |
| ▲ | Kinrany an hour ago | parent | prev | next [-] | | The problem with that was lack of iteration, not presence of specifications. | |
| ▲ | jbs789 5 hours ago | parent | prev | next [-] | | It is funny. At some point the code is the specification. | | |
| ▲ | Terr_ 5 hours ago | parent | next [-] | | Remember when it was time to fire all the engineers because your business-analysts could just make UML diagrams? | |
| ▲ | bunderbunder an hour ago | parent | prev [-] | | If the code is the specification, then the only word on what the system is supposed to do is what it actually does. When what it actually does is surprising, maybe you can make sense of it by asking the author what they were thinking. But that only works if the author is an entity that is both capable of thinking, and of remembering what it was thinking. |
| |
| ▲ | Foobar8568 2 hours ago | parent | prev [-] | | Yet software quality has been in deep dive for a while, long before AI. | | |
| ▲ | devin 17 minutes ago | parent [-] | | My theory on this is that it’s a lot of kids who would have gone into finance going into tech instead. |
|
| |
| ▲ | KylerAce 6 hours ago | parent | prev | next [-] | | 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 | | |
| ▲ | xmodem 3 hours ago | parent [-] | | Funnily enough I've found that LLMs can be effective at mitigating many of the drawbacks of black-box testing and i've significantly expanded our usage of it over the past year |
| |
| ▲ | tored 5 hours ago | parent | prev | next [-] | | Yes, unfortunately a lot of requirements and specifications are now AI slop, thus developers stop reading them, and agent produce even more slop. We need to take back writing requirements and specifications to humans. Adopting high level BDD style testing of human written user stories (cucumber) is probably a good idea. | | |
| ▲ | jimbokun 5 hours ago | parent [-] | | Just have AI write requirements then another AI write specs based on the requirements then another AI write tests based on the specs and another AI write the implementation based on the tests then another AI write the PR based on the implementation then another AI approve the PR and another AI deploy approved PRs to production! | | |
| ▲ | alterom 5 hours ago | parent [-] | | Don't forget: let the user's AI use the product, find flaws, submit AI-generated bug-reports, which get turned into AI-generated tickets, etc. | | |
| ▲ | smaudet 4 hours ago | parent [-] | | And meanwhile, did any human find the whole process useful - no, not all... | | |
|
|
| |
| ▲ | gf000 4 hours ago | parent | prev | next [-] | | FWIW, it's a great little "trick" to always ask for red-green tests. In my experience it's enough to ask for that and LLMs know what to do. | | | |
| ▲ | jopsen 2 hours ago | parent | prev | next [-] | | If before AI you couldn't deploy to production without a code review, what makes you think you will be able to with AI? To be fair, when I was a kid we'd connect the editor to the server using an unencrypted ftp connection and modify php files in production. This worked perfectly fine, and phpmyadmin made schema changes super easy. These days we do tests, schema migrations, terraform, staging sites, traffic migration, monitoring, logging, revision control, etc. ... it's a lot of boring work, and for most CRUD apps, its entirely unnecessary :) That said: I doubt we'll abandon these practices for things that matter. Because while modifying php files in production can increase velocity, it can also get very "exciting" if you have a few co-workers on the same project :) | |
| ▲ | ToucanLoucan 4 hours ago | parent | prev [-] | | I just don't understand the hype for this. "AI can do $x" quickly needs softening to "AI can try to do $x" which then becomes "humans need to verify $x has been done." If humans still have to oversee every part of the processes then what exactly is being automated!? This would be like if we had our first factory producing cars but each car was like a die roll in terms of getting a car, a washing machine, a pile of scrap metal, or a baby. And people just asserting over and over that this was the future of making cars, no matter how much scrap metal keeps coming out. |
|
|
| ▲ | bunderbunder 3 hours ago | parent | prev | next [-] |
| IME, the biggest source of rework cost that happens at (or after) code review is when someone notices that the code, correctly or not, implements the wrong thing. For example, the feature, as implemented, doesn’t sufficiently solve the original business problem. Or it solves it in a bad way, like because of overengineering or taking on unnecessary technical debt. I haven’t really seen much evidence of AI code review catching either of these problems. I’ve heard people complain that human code review doesn’t reliably catch them, either. And I have seen that with my own eyes. Just not universally. Teams that have a strong culture of shared ownership and collaborating on designs regularly catch these kinds of problems in code review. If they’re really good at it, they catch them even earlier. e.g., I know planning poker isn’t fashionable anymore, but when I’ve been on teams that take it seriously they tend to be pretty good at finding minimally expensive, correct designs pretty early in the process. Which makes both coding snd code review go faster because simpler designs are easier to manage. And design flaws that do make it to code review tend to be smaller and less expensive to fix. So those teams didn't tend to bottleneck on code review in the first place. I think that this is the kind of thing that led to folks like DORA observing that AI coding is something of a multiplier for the effects of both good and bad software development practice. If you’ve got a cowboy coding culture, throwing AI into the mix will probably just lead to agentic cowboy coding. |
| |
|
| ▲ | rbehrends 6 hours ago | parent | prev | next [-] |
| > 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). |
| |
| ▲ | necovek 5 hours ago | parent | next [-] | | > 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. I actually believe the opposite: exactly the fact that a reviewer had to develop a mental model independently is why code review is and remains valuable (and why people use different models when doing agentic reviews). The biggest value of doing code reviews is in ensuring maintainability of the code (1. someone else can understand it, 2. it is readable and 3. can be evolved in the future) — everything else is downstream from that. | | |
| ▲ | rbehrends 5 hours ago | parent | next [-] | | > I actually believe the opposite: exactly the fact that a reviewer had to develop a mental model independently is why code review is and remains valuable (and why people use different models when doing agentic reviews). I don't think we actually disagree here. I also think it is valuable, but it's also what often makes it difficult. > The biggest value of doing code reviews is in ensuring maintainability of the code (1. someone else can understand it, 2. it is readable and 3. can be evolved in the future) — everything else is downstream from that. Agree very much with that (with the slight caveat that it is not always the biggest value, just an important one). | |
| ▲ | gf000 4 hours ago | parent | prev [-] | | > exactly the fact that a reviewer had to develop a mental model But do they? In my experience, at most workplaces it's simply a meat linter phase with the occasional useless comment about style (which should probably be handled by proper CI/CD). Like if you don't even check out the code (generalized 'you'), then they can hardly build up that model. And even checked out, viewed in its proper context, Naur's famous paper comes to mind - the author who wrote it is the only one who has properly built the theory (which might have included alternative implementations that failed but have no visible artifact). I'm not claiming that there are no places that go absolutely above and beyond with their review sessions, but I would argue it's really rare - and AIs are great at figuring out some of the context the PR description lacks. | | |
| ▲ | brabel 3 hours ago | parent | next [-] | | People say one thing and do another. It’s tiring. Long before LLMs we had the joke that a PR with 10 lines changes got 10 comments (all nitpicking), a PR with 1000 lines got just one, LGTM. We’ve had several bugs where PR review would almost certainly never catch the issue, people are terrible at reviewing things thoroughly. Guess what can do that much much better? | |
| ▲ | fortzi 3 hours ago | parent | prev [-] | | What you describe sounds like little more than rubber stamping a PR target than reviewing it.. I see it too, but I don’t thing we should double down on it just because it’s common |
|
| |
| ▲ | skydhash 5 hours ago | parent | prev [-] | | > 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. Code review is not really about correctness and security. We have testing and other verification process for these. Code review is about idea discussion mostly and correcting a few stuff that may have slipped through the author's initial review. Your PR wants to change the software in some way. My review is to comment on how you've implemented that change, like did you miss some areas where you needed to change, does your description is actually what is happening (either a cursory reading or through testing), or are you doing some unnecessary change. IMO, the initial reading shouldn't take more than 10 minutes. More than that (so a big diff) it should have been discussed upfront, and the design agreed. If it's an important area, a more careful reading should be done about the tests and relevant stuff. But generally, if a review takes more than 10 minutes, there's some failure of communication going on (reviewer not apt to understand the change, big diffs that should have been discussed outside of the PR, obtuse code,...) | | |
| ▲ | lokar an hour ago | parent | next [-] | | My main goal in a review is to ensure the design of the system and approach to the change is resilient to errors (by me and the author). You have to assume there will be mistakes you can’t catch (still, catch as many as you can), but other factors heavily influence how bad the mistakes will be. | |
| ▲ | rbehrends 5 hours ago | parent | prev | next [-] | | All good points. Maybe having worked a lot with concurrent and distributed system makes me distrustful of relying on unit/integration tests for correctness; I've seen too many concurrency issues pass CI validation. But unit tests also sometimes miss edge cases in more straightforward code, so I'm still a bit more cautious. I also agree that merge requests should be short and understandable in 10 minutes, but IME this happy state often does not obtain in practice. It shouldn't, but it often does, whether it's mission creep, whether it's turning out that a change is more complex than originally imagined, or whether it is unavoidably complex and cannot be broken down further. | |
| ▲ | bluefirebrand 4 hours ago | parent | prev [-] | | > IMO, the initial reading shouldn't take more than 10 minutes. More than that (so a big diff) it should have been discussed upfront, and the design agreed Part of the code review process is to verify that the writer actually did build the agreed design too though. |
|
|
|
| ▲ | hgowietoi 6 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | uxhacker 5 hours ago | parent | next [-] | | Just to back you up most surveys say only 10% to 20% of programmers time is coding. Microsoft study of 484 developers, published in 2025 says 11%. Another Microsoft study where programmers had telemetry installed showed 21% https://gwern.net/doc/psychology/writing/2017-meyer.pdf | | |
| ▲ | LarsDu88 4 hours ago | parent | next [-] | | It's interesting. I remember around COVID, there were a bunch of startups building 3d printers for concrete housing. Then I looked up the actual cost of construction for a typical house, and only 14% of it was the most visible part (the balloon framing and physical house). Most of the cost is in foundations, plumbing, wiring, and things like insulation, flooring, cabinets, etc. I guess at Microsoft coding is similar to building a house in that sense. Either that or all big orgs devolve into large amounts of time spent on politics. | |
| ▲ | Gigachad 3 hours ago | parent | prev [-] | | 90% of my time these days is trying to understand what the wall of claudeslop jira ticket is actually asking for. It's like archeology digging for the original customer issue to work out what is actually wanted underneath paragraphs of root cause load bearing seams. |
| |
| ▲ | Sharlin 6 hours ago | parent | prev | next [-] | | I wish they taught Amdahl's law in business school. Or at the very least the simple concept of "bottleneck". | | |
| ▲ | a34729t 6 hours ago | parent | next [-] | | "The Goal" is a key business book for a reason, but leadership seems to not get the lesson. Or care? | |
| ▲ | strulovich 6 hours ago | parent | prev | next [-] | | I’m sure they learn it by other names. The point is that while good to remember, and specifically Fred Brook’s “No Silver Bullet” article about it, there are second order effects. If coding becomes 100x cheaper, what’s going to happen next? At least to some degree, design and planning was there since coding is expensive. (Not just coding, debugging also got squashed by AI and was an expensive part of the job) This is why the original comment seems pretty spot on, organizations will learn how to skip more phases, and startups are probably a place where this will be happening faster. (Not clearly though, a lot of big tech are happy tokenmaxxing to try and not stay behind those startups when they come) | | |
| ▲ | scruple 5 hours ago | parent [-] | | Brooks' point was more about accidental vs. essential complexity. You seem to be implying that design was only ever an artifact of "expensive" typing, but design exists to prevent systems from collapsing under different failure states. If the cost of emitting syntax collapses without adequately resolving the essential complexity then you have not eliminated the design phase and you're just externalizing your failure modes onto downstream teams and systems. |
| |
| ▲ | gf000 4 hours ago | parent | prev [-] | | I like the "9 women can't birth 1 baby in one month" | | |
| ▲ | redwall_hp an hour ago | parent [-] | | Fred Brooks wrote a whole ass book based on that premise, and people still haven't learned the lesson half a century later. |
|
| |
| ▲ | smaudet 4 hours ago | parent | prev | next [-] | | Coding was never the bottleneck... And how many billions or trillions have we wasted on people who didn't understand that (or did, and are just busy generating hype). Ultimately, this (llm) technology (as it is being developed/used), is not useful to us... | | |
| ▲ | euiee 4 hours ago | parent [-] | | Yup we already knew this. Google had many engineers working on a) failed projects b) people being paid to sit around. There seems to be this strange belief on here that making something more accessible to everyone will always result in better outcomes. I don’t see this being true of software. I’m very pro-tech. But nobody can point me to a product built by someone outside of the large tech firms, made by by llm’s that is a great value add to one’s life. Many of those were already created - they’re on the apple App Store for example. I’m absolutely confident coding speed is irrelevant. A person who has a real vision + strategy and hand written code will beat the team with no vision, strategy and code blasted out by llm’s. Sure llm’s could augment the former - but you’re missing the point!! | | |
| ▲ | jopsen 2 hours ago | parent | next [-] | | > A person who has a real vision + strategy and hand written code will beat the team with no vision, strategy and code blasted out by llm’s. But you have to beat the team with vision + strategy who is also blasting out code with LLMs. Certainly, the time it takes to figure out that an idea is bad had been shortened :) | | |
| ▲ | JBits 9 minutes ago | parent [-] | | If the time taken is shortened but you don't learn anything from it, then you're still behind. |
| |
| ▲ | Larrikin 3 hours ago | parent | prev [-] | | There's a difference between vibe coded slop, vibe coded kinda slop built by an engineer, AI assisted engineers, and AI planning. I enjoy writing code by hand but it's quickly becoming apparent that LLMs are now a tool that one should be using in some capacity. Nobody writes code in notepad anymore, even though you could and might even like all the black text. | | |
| ▲ | redwall_hp an hour ago | parent [-] | | I'm fairly pessimistic about LLMs, but I do find they're a good research tool. If I can accelerate finding answers amid the slurry of Confluence, Slack, assorted other intranet places and the web, I can get back to thinking about the design and programming. I have a user CLAUDE.md that tells it not to presume to modify any files, and a bunch of internal MCPs for our logging and monitoring tools, documents, git repositories and such, and I've been dabbling with writing skill files so it can access some other internal things. So I can basically say "this thing isn't working because x, and it's probably related to y not having z" and it'll go off and find info buried in the corporate abyss. Then other people yeet wildly awful LLM generated PRs over the fence and I lose my sanity from basically having fight a constant battle against a slow rot of software quality that will bite us later. |
|
|
| |
| ▲ | alterom 5 hours ago | parent | prev | next [-] | | > So if AI doubles our code writing velocity, then it will make us 5% faster overall. This tracks with the actual revenue impact of AI adoption: https://www.bcg.com/publications/2026/the-formula-for-agenti... Their very cheerful "high" revenue increase from AI adoption (that few companies in the index manage to achieve) sits at 4.5%. Most of those in the "value generating" minority are seeing sub-1% returns. Which, of course, is non-zero, real, and all that, and matters when we're talking about a 4-5% increase of a big company's revenue, assuming the expenses are not catching up with that. Which they absolutely are. The AI is subsidized by venture capital, and the subsidies are drying up (hence OpenAI upcoming funding round). None of the AI companies are profitable (much less self-sustaining), and AI prices are inevitably increasing. | |
| ▲ | jimbokun 5 hours ago | parent | prev | next [-] | | Which is basically what this study is showing. | |
| ▲ | red75prime 6 hours ago | parent | prev | next [-] | | Is your company striving to automate design and analysis, then? | |
| ▲ | keybrd-intrrpt 6 hours ago | parent | prev | next [-] | | > 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. | | |
| ▲ | kreyenborgi 4 hours ago | parent | next [-] | | > the most impactful changes Quite a lot of our bugs in production have been in seemingly less impactful changes. How do you know what's impactful a priori? | |
| ▲ | pessimizer 5 hours ago | parent | prev [-] | | > I can have an agent mass-produce security bug fixes I can't figure out what you're trying to say here. Are you saying that this is acceptable? Because I very much don't think it is. You'll have twice the bugs after you're done, and they'll be inhuman ones that you have little chance of catching. > But how many changes are actually serious? I mean, "security bug fixes" are not on your list of serious changes? What is? |
| |
| ▲ | notarobot123 6 hours ago | parent | prev [-] | | ...and they are not using LLMs to help speed up design and analysis? I'm no booster but this is most of what I currently spend tokens on so it's maybe not as absurd as it sounds. Maybe those gains are possible and without having to sacrifice serious code reviews too. |
|
|
| ▲ | asdff 2 hours ago | parent | prev | next [-] |
| Imagine no code review: poof. You still aren't shipping at lightspeed because it still comes down to knowing where to shoot. Oftentimes this is like pulling teeth from various involved stakeholders. You say small startups would be faster as they won't be doing code review. There's probably always been startups running without bothering with code review for as long as this has been a field. Bad practice? Sure, but all that matters to the business case a lot of the time is just shipping something that works alright, not the greatest piece of efficient code in the world. Moore's law has bought us a lot of slack in that. |
|
| ▲ | overfeed 2 hours ago | parent | prev | next [-] |
| > 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. Interesting framing that casts senior engineers as the impediment. If the models are now good enough now, perhaps engineering leadership could[1] do away with code review entirely - or maximally automate code reviews. I'm sure seniors would love to get their individual productivity unleashed for performance metrics/bonus reasons. 1. I'm stating this as a hypothetical, but this "vibe-coding your core product" experiment has been repeated many times and I'm yet to hear a single success story |
|
| ▲ | mort96 6 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | stillpointlab 6 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | VeninVidiaVicii 5 hours ago | parent | next [-] | | It's really about hamstringing the AIs so they can't write crap. Writing code is not a problem anymore, so anyone with an idea can write a script to do what they want. But if they try to connect two ideas together, now they have a data modeling problem. This is where everything seems to fail with AI coding (largely because the original author had the idea piecemeal). | | |
| ▲ | Gigachad 3 hours ago | parent [-] | | The problem I have is non technical people now started submitting PRs. They are like the brain damage module on GLaDOS and somehow make opus generate actual broken slop. So I still have to be on my toes to catch that, but they generate such volumes of broken PRs that it takes time away from me doing real work. |
| |
| ▲ | alchemism 5 hours ago | parent | prev | next [-] | | Perhaps spec review in the custom of code review - it can even be via PR - so there is a bottleneck before anything is generated, instead of after. Cheap-to-produce code maybe isn't worth understanding line-by-line anymore. | | |
| ▲ | stillpointlab 5 hours ago | parent [-] | | I think spec review, which is definitely valuable, solves a different problem. One question to ask is "are we building the right thing", which a spec review definitely helps to answer. But another question is "did we build what we planned, and did we build it to a high quality". Code review partially answered that question. Adversarial review is the closest we have to that in the automated LLM world, but I feel we need something better. | | |
| ▲ | alchemism 5 hours ago | parent [-] | | In the sense that ai-engineering specs (ie an elaborate prompt with skills etc.) can be said to be compiled into code language x maybe.....the spec is the new code? |
|
| |
| ▲ | 27183 2 hours ago | parent | prev [-] | | > the new agentic reality As a senior engineer, I think the code quality and review rigour slippage came well before AI. It's cultural, not technical. People just don't want to hear criticism anymore, they're thin skinned and weak minded, and they don't want to do the work to become strong. They want to be handed the answers and told they're doing great work, regardless of whether it's actually true. Generative AI coding tools have just amplified this problem. To be perfectly honest, whenever I detect this pathology in a junior my effort reviewing their code drops precipitously. There's just no point investing in an individual who doesn't want to work hard and learn. If my employer wants me to green light their vibeslopped garbage then I'll gladly oblige. Unfortunately this is the norm now. | | |
| ▲ | 33d3 an hour ago | parent [-] | | Me being selfish.. I don't mind this. I want every other firm to get weak whilst mines stays strong and wipe them out clean. |
|
|
|
| ▲ | devin 6 hours ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | danjc 5 hours ago | parent | prev | next [-] |
| We're going to need to start putting the month in brackets after the article title, not just the year! |
|
| ▲ | 01100011 5 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | bigmattystyles 2 hours ago | parent | prev | next [-] |
| For me reading ai code feels a lot like that time I tried reading Joyce. I don’t understand but I’m sure it’s beautiful. |
|
| ▲ | swatcoder 5 hours ago | parent | prev | next [-] |
| > 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 go 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! |
| |
| ▲ | euiee 4 hours ago | parent | next [-] | | Correct people need to go slower but this doesn’t benefit frontier labs. Go go go max max max is what they want. | |
| ▲ | Terr_ 5 hours ago | parent | prev [-] | | "The users-only forum for complaints about authentication errors is completely empty, therefore everything is working perfectly." |
|
|
| ▲ | geraneum 5 hours ago | parent | prev | next [-] |
| > 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. |
|
| ▲ | hajile 6 hours ago | parent | prev | next [-] |
| The study was updated in August 2026. |
|
| ▲ | socializer 5 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | bornfreddy 4 hours ago | parent | next [-] | | It's as if building something was not a bottleneck for startups. Go figure. | |
| ▲ | hand2note 2 hours ago | parent | prev | next [-] | | Codex/CC and other OpenAI and Anthropic products like Dots, are examples of how quickly real products can be built today. But to me, they feel more like mediocre products bloated with feature slop. Nothing extraordinary or technologically innovative. Pi.dev and Cursor's Tab completion are two of the most innovative and extraordinary products I know in AI era, and both were built by humans, at least in their "breakthrough" stages. | |
| ▲ | euiee 4 hours ago | parent | prev [-] | | I want the boosters to address this head on - chime in? |
|
|
| ▲ | tored 6 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | risyachka 6 hours ago | parent | prev | next [-] |
| 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 |
| |
| ▲ | nharziro 5 hours ago | parent [-] | | can you be more specific. If the code is not a mess, how is the resulting product a mess? |
|
|
| ▲ | zer00eyz 4 hours ago | parent | prev | next [-] |
| > 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. Our industry has spent the better part of the last two decades interviewing with brain teasers and leet code questions. Reading code is a skill that we just weren't assessing for, and lots of people aren't really good at it. I would argue that code review is mostly theater, politics, bike shedding and pedantry. There is a lot of work to get away from "coding" and "programing" and get down to the actual engineering that really needs to happen in the industry. |
|
| ▲ | jimbokun 5 hours ago | parent | prev | next [-] |
| What could possibly go wrong? |
|
| ▲ | bcrosby95 6 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | wrg32786 5 hours ago | parent | prev | next [-] |
| [flagged] |
|
| ▲ | iwontberude 6 hours ago | parent | prev | next [-] |
| [dead] |
|
| ▲ | dominotw 6 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | datsci_est_2015 6 hours ago | parent | next [-] | | You don’t sound very senior. Code review isn’t a quality gate, it’s a way to maintain shared understanding of a codebase. Throwing out code review is equivalent to throwing your hands up and saying you don’t need to understand anything about what your code is doing in its black box. I don’t think anyone on this forum is half as smart as they think they are, especially in terms of systems engineering a black box solution. Myself included. Someone needs to understand what’s going on inside the Widget Factory until we have full Artificial General Intelligence. | | |
| ▲ | Hamuko 5 hours ago | parent [-] | | >Throwing out code review is equivalent to throwing your hands up and saying you don’t need to understand anything about what your code is doing in its black box. I think that is what the C-suite is currently wanting out of our engineers. Prompt, don't write, maybe read a bit, don't stop, ship, ship, ship. | | |
| ▲ | curt15 3 hours ago | parent | next [-] | | Is the C-suite ready to sack the engineers and prompt Claude themselves with their business requirements? Why not cut out the middlemen if that's how they now perceive engineers? | | |
| ▲ | datsci_est_2015 7 minutes ago | parent [-] | | If they can do that, why doesn’t someone else do it first, for half as much money? What’s their moat if their business can be replicated with a few prompts? |
| |
| ▲ | Terr_ 5 hours ago | parent | prev [-] | | This will vary by company focus and size, but sometimes the C-suite just doesn't want to believe that software-engineering has important overlap with business-analysis or product-design. |
|
| |
| ▲ | jimbokun 5 hours ago | parent | prev | next [-] | | So you’re not writing the code, and you’re not reviewing the code… What exactly would you say it is you do around here? | | | |
| ▲ | jghn 5 hours ago | parent | prev | next [-] | | I initially pivoted to fully automated code reviews, sometimes with a brief skim of things. I've been shifting back to mostly manual review. In the background I'll also run some agentic scans, and once I'm done I'll look to see what the agents had to say. And then I go back in by hand armed with that knowledge and verify it & come to my own conclusion. Why? Because I started to run into way too many AI generated messes in codebases. The agents are really good at some things and complete ass at others. | |
| ▲ | 0x20cowboy 6 hours ago | parent | prev | next [-] | | > 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. | | |
| ▲ | keybrd-intrrpt 6 hours ago | parent | next [-] | | > 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 | | |
| ▲ | 0x20cowboy an hour ago | parent | next [-] | | > If it is so critical, why don't we have tests and benchmarks for it? Thats a fair point, but Ive seen LLMs modify the surrounding environment to “pass the test” A human still has to be responsible at some point. | |
| ▲ | jimbokun 5 hours ago | parent | prev | next [-] | | Good thing you reviewed the PR so you could catch the gap in Greg’s documentation and force him to write it before approving his PR! | |
| ▲ | weakfish 5 hours ago | parent | prev [-] | | > Your best coder is now Opus or Astra No, that's our _fastest_ coder, which is a different thing than _best_ |
| |
| ▲ | Rudybega 5 hours ago | parent | prev | next [-] | | > he critical part of the backend where a new 300ms delay will cost the company millions then yeah. If a performance regression like this isn't caught by an automated testing suite, you have made a horrible mistake. | | |
| ▲ | jimbokun 5 hours ago | parent [-] | | Reviewing the PR gives you a chance to identify this gap in the performance regression suite. | | |
| ▲ | alchemism 5 hours ago | parent [-] | | The agent could also do that part while its still in draft. If the rigorous tests already exist of course. |
|
| |
| ▲ | dominotw 6 hours ago | parent | prev [-] | | > new 300ms delay will cost the company millions these might be 1% typically |
| |
| ▲ | sroerick 6 hours ago | parent | prev | next [-] | | Absolutely. And also the idea that this is somehow the last bastion against introducing bugs? Maybe run a test | | |
| ▲ | pessimizer 3 hours ago | parent [-] | | > Maybe run a test One of those things made of code that we should neither be writing nor reviewing? Shouldn't I just assume that the LLM did that or whatever? |
| |
| ▲ | yonaguska 6 hours ago | parent | prev [-] | | I hate code reviews, but I owe it to my coworkers that I know will read my PRs to review my own generated slop line by line. Most of these agents are still overly verbose and I'm in a situation where no, not every single edge case is relevant enough to warrant the additional loc or complexity introduced. |
|
|
| ▲ | dyauspitr 5 hours ago | parent | prev [-] |
| 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. |
