6 ms·

To me, the most salient point was this: > Code reviewing coworkers are rapidly losing their minds as they come to the crushing realization that they are now th

To me, the most salient point was this: > Code reviewing coworkers are rapidly losing their minds as they come to the crushing realization that they are now the first layer of quality control instead of one of the last. Asked to review; forced to pick apart. Calling out freshly added functions that are never called, hallucinated library additions, and obvious runtime or compilation errors. All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.” LLMs have made Brandolini's law ("The amount of energy needed to refute bullshit is an order of magnitude larger than to produce it") perhaps understated. When an inexperienced or just inexpert developer can generate thousands of lines of code in minutes, the responsibility for keeping a system correct & sane gets offloaded to the reviewers who still know how to reason with human intelligence. As a litmus test, look at a PR's added/removed LoC delta. LLM-written ones are almost entirely additive, whereas good senior engineers often remove as much code as they add.

CjHuber 1y ago
I'd say it depends on how coding assistants are used, when on autopilot I'd agree, as they don't really take the time to reflect on the work they've done before going on with the next feature of the spec. But in a collaborative process that's of course different as you are pointing out things you want to have implemented in a different way. But I get your point, most PR's you'd flag as AI generated slop are the ones where someone just ran them on autopilot and was somewhat satisfied with the outcome, while treating the resulting code as blackbox
jihadjihad 1y ago
> whereas good senior engineers often remove as much code as they add https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html
- MisterTea 1y ago
  "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson
  - sevenseacat 1y ago
    oh yes I've had times like this. Recently I was looking at building a gnarly form, that had some really complex interactions and data behind it. It just kept being subtly buggy in all different ways. I threw Claude at it, went down so many rabbit holes, it was convinced there were bugs in all the different frameworks and libraries I was using because it couldn't find the issue in the code (that it had written most of). After a couple of days of tearing my hair out, I eventually dug in and rewrote it from first principles myself. The code afterwards was so much shorter, so much clearer, and worked a hell of a lot better (not going to say perfectly, but, well, haven't had a single issue with it since).
Etheryte 1y ago
In my opinion this is another case where people look at it as a technical problem when it's actually a people problem. If someone does it once, they get a stern message about it. If it happens twice, it gets rejected and sent to their manager. Regardless of how you authored a pull request, you are signing off on it with your name. If it's garbage, then you're responsible.
- Ekaros 1y ago
  Maybe the process should have actual two stage pull requests. First stage is you have to comment the request and show some test cases against it. And only then next person has to take a look. Not sure if such flow is even possible with current tools.
  - oblio 1y ago
    Build the PR and run tests against it. Supported by all major CI/CD tools.
- tyleo 1y ago
  I agree and I’m surprised more people don’t get this. Bad behaviors aren’t suddenly okay because AI makes them easy. If you are wasting time you may be value negative to a business. If you are value negative over the long run you should be let go. We’re ultimately here to make money, not just pump out characters into text files.
  - jackblemming 1y ago
    How do you know the net value add isn’t greater with the AI, even if it requires more code review comments (and angrier coworkers)?
    - y0eswddl 1y ago
      all the recent studies (that are constantly posted here) that say so.
aleph_minus_one 1y ago
The problem rather is that you still have to stay somewhat agreeable while calling out the bullshit. If you were "socially allowed" to treat colleagues like > All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.” as they really deserve, the problem would disappear really fast. So the problem that you outlined is rather social, and not the LLMs per se (even though they very often do produce shitty code).
- AnimalMuppet 1y ago
  They should get a clear explanation of the problem and of the team expectations the first time it happens. If it happens a second time? A stern talk from their manager. A third time? PIP or fired. Let your manager be the bad guy. That's part of what they're for. Your manager won't do that? Then your team is broken in a way you can't fix. Appeal to their manager, first, and if that fails put your resume on the street.
  - aleph_minus_one 1y ago
    > Let your manager be the bad guy. That's part of what they're for. > Your manager won't do that? Then your team is broken in a way you can't fix. If you apply this standard, then most teams are broken.
    - 01HNNWZ0MV43FF 1y ago
      "A big enough system is always failing somewhere" - can't remember who said it
  - sudahtigabulan 1y ago
    > If it happens a second time? A stern talk from their manager. In my experience, the stern talk would probably go to you, for making the problem visible. The manager wouldn't want their manager to hear of any problems in the team. Makes them look bad, and probably lose on bonuses. Happened to me often enough. What you described I would call a lucky exception.
ge96 1y ago
I'm working on the second project handed to me that was vibe-coded. What annoys me assuming it runs is the high number of READMEs which I'm not even sure which one to use/if applicable. They are usually verbose/include things like "how to run a virtual env for python"
- cutemonster 1y ago
  Lots of READMEs? Might make total sense, if lines of code added, is a metrics the managers look at. Can't be any compilation errors in a README, no need to worry about bugs. And if they're long and boring enough, no one will ever read them. AI generated READMEs = free metrics bonus points, for the performance reviews :-)
CaptainOfCoit 1y ago
> All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.” Now I don't do code reviews in large teams anymore, but if I did and something like that happened, I'd allow it exactly once, otherwise I'd try to get the person fired. Barring that, I'd probably leave, as that sounds like a horrible experience.
- bloppe 1y ago
  Ya, there's not much you can do when leadership is so terrible. If this kind of workflow is genuinely blessed by management, I would just start using Claude for code reviews too. Then when things break and people want to point fingers at the code reviewer, I'd direct them to Claude. If it's good enough to write code without scrutiny, it's good enough to review code without scrutiny.
cookiengineer 1y ago
You have two options: Burn out because you need to correct every stupid line of code, or... Start to not give a damn about quality of code and live a happy life while getting paid. The sane option is to join the cult. Just accept every pull request. Git blame won't show your name anyways. If CEOs want you to use AI, then tell AIs to do your review, even better.
jakub_g 1y ago
I feel like I went through this stage ahead of time, a decade ago, when I was junior dev, and was starting my days by: first reviewing the work of a senior dev who was cramming out code and breaking things at the speed of light (without LLMs); and then leaving a few dozen comments on pull requests of the offshore team. By midday I had enough for the day. Now that I'm no longer at that company since a few years ago, I'm invincible. No LLM can scare me!
yodsanklai 1y ago
> All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.” After you made your colleagues upset submitting crappy code for review, you start to pay attention. > LLM-written ones are almost entirely additive, Unless you noticed that code has to be removed, and you instruct the LLM to do so. I don't think LLMs really change the dynamics here. "Good programmers" will still submit good code, easy for their colleagues to review, whether it was written with the help of an LLM or not.
- 000ooo000 1y ago
  >After you made your colleagues upset submitting crappy code for review, you start to pay attention. If the only thing keeping you from submitting crappy code is an emotional response from coworkers, you are not a "good programmer", no matter what you instruct your LLM.
zamalek 1y ago
> LLM-written ones are almost entirely additive I have noticed Claude's extreme and obtuse reluctance to delete code, even code that it just wrote that I told it is wrong. For example, it might produce a fn: fn foo(bar) And then I say, no, I actually wanted you to "foo with a frobnitz", so now we get: fn foo(bar) // Never called fn foo_with_frobnitz(bar)
- igor47 1y ago
  This tendency must get reenforced through RL in the training phase. It's very high profile when an LLM deletes the wrong thing, eg https://arstechnica.com/information-technology/2025/07/ai-coding-assistants-chase-phantoms-destroy-real-user-data/ https://arstechnica.com/information-technology/2025/07/ai-co...
smoody07 1y ago
This is a broader issue about how where we place blame when LLMs are involved. Humans seem to want to parrot the work and take credit when it’s correct while deflecting blame when it’s wrong. With a few well placed lawsuits this paradigm will shift imho
- y0eswddl 1y ago
  that's just capitalism 101 - privatize profits, socialize failures
brailsafe 1y ago
I think this is why I've been feeling less productive overall lately. Partly due to the fact that more code is expected to be produced more quickly, and partly because using an agent or something puts me into the wrong frame of mind where I don't really have the full context of what I've written and why, and the amount of quality work I can produce is necessarily qualified by how much I can reliably review, line-by-line, over whatever period of time. I've been using them more conservatively, slowing down, and manually writing things more. It's easier when I'm just replicating logic over a bunch of different well-defined properties of a clear type definition or spec, but even then results are a bit questionable sometimes.
Quis_sum 1y ago
I am probably too old school: Unless properly documented (the "whats" and especially the "whys") and provided with a test harness (plus the test cases, including all fringe cases btw.) just reject it straight away. And in the case it is provided and you have a hard time understanding it, reject it as well with the comment that, the "demi-god" (author) should provide documentation which mere mortals can follow. That principle can be applied to both LLM slop and handcrafted rubbish. Eventually most people will get it.
sqircles 1y ago
How are these "engineers" maintaining jobs? How is pushing code generated by someone/something else that hasn't even as much as been looked at before acceptable in any realm? Better yet- why are there orgs that accept this behavior? I know mine is far from it, as they should be.

CjHuber 1y ago

I'd say it depends on how coding assistants are used, when on autopilot I'd agree, as they don't really take the time to reflect on the work they've done before going on with the next feature of the spec. But in a collaborative process that's of course different as you are pointing out things you want to have implemented in a different way. But I get your point, most PR's you'd flag as AI generated slop are the ones where someone just ran them on autopilot and was somewhat satisfied with the outcome, while treating the resulting code as blackbox

jihadjihad 1y ago

> whereas good senior engineers often remove as much code as they add https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html

MisterTea 1y ago
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson
- sevenseacat 1y ago
  oh yes I've had times like this. Recently I was looking at building a gnarly form, that had some really complex interactions and data behind it. It just kept being subtly buggy in all different ways. I threw Claude at it, went down so many rabbit holes, it was convinced there were bugs in all the different frameworks and libraries I was using because it couldn't find the issue in the code (that it had written most of). After a couple of days of tearing my hair out, I eventually dug in and rewrote it from first principles myself. The code afterwards was so much shorter, so much clearer, and worked a hell of a lot better (not going to say perfectly, but, well, haven't had a single issue with it since).

Etheryte 1y ago

In my opinion this is another case where people look at it as a technical problem when it's actually a people problem. If someone does it once, they get a stern message about it. If it happens twice, it gets rejected and sent to their manager. Regardless of how you authored a pull request, you are signing off on it with your name. If it's garbage, then you're responsible.

Ekaros 1y ago
Maybe the process should have actual two stage pull requests. First stage is you have to comment the request and show some test cases against it. And only then next person has to take a look. Not sure if such flow is even possible with current tools.
- oblio 1y ago
  Build the PR and run tests against it. Supported by all major CI/CD tools.
tyleo 1y ago
I agree and I’m surprised more people don’t get this. Bad behaviors aren’t suddenly okay because AI makes them easy. If you are wasting time you may be value negative to a business. If you are value negative over the long run you should be let go. We’re ultimately here to make money, not just pump out characters into text files.
- jackblemming 1y ago
  How do you know the net value add isn’t greater with the AI, even if it requires more code review comments (and angrier coworkers)?
  - y0eswddl 1y ago
    all the recent studies (that are constantly posted here) that say so.

aleph_minus_one 1y ago

The problem rather is that you still have to stay somewhat agreeable while calling out the bullshit. If you were "socially allowed" to treat colleagues like > All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.” as they really deserve, the problem would disappear really fast. So the problem that you outlined is rather social, and not the LLMs per se (even though they very often do produce shitty code).

AnimalMuppet 1y ago
They should get a clear explanation of the problem and of the team expectations the first time it happens. If it happens a second time? A stern talk from their manager. A third time? PIP or fired. Let your manager be the bad guy. That's part of what they're for. Your manager won't do that? Then your team is broken in a way you can't fix. Appeal to their manager, first, and if that fails put your resume on the street.
- aleph_minus_one 1y ago
  > Let your manager be the bad guy. That's part of what they're for. > Your manager won't do that? Then your team is broken in a way you can't fix. If you apply this standard, then most teams are broken.
  - 01HNNWZ0MV43FF 1y ago
    "A big enough system is always failing somewhere" - can't remember who said it
- sudahtigabulan 1y ago
  > If it happens a second time? A stern talk from their manager. In my experience, the stern talk would probably go to you, for making the problem visible. The manager wouldn't want their manager to hear of any problems in the team. Makes them look bad, and probably lose on bonuses. Happened to me often enough. What you described I would call a lucky exception.

ge96 1y ago

I'm working on the second project handed to me that was vibe-coded. What annoys me assuming it runs is the high number of READMEs which I'm not even sure which one to use/if applicable. They are usually verbose/include things like "how to run a virtual env for python"

cutemonster 1y ago
Lots of READMEs? Might make total sense, if lines of code added, is a metrics the managers look at. Can't be any compilation errors in a README, no need to worry about bugs. And if they're long and boring enough, no one will ever read them. AI generated READMEs = free metrics bonus points, for the performance reviews :-)

CaptainOfCoit 1y ago

> All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.” Now I don't do code reviews in large teams anymore, but if I did and something like that happened, I'd allow it exactly once, otherwise I'd try to get the person fired. Barring that, I'd probably leave, as that sounds like a horrible experience.

bloppe 1y ago
Ya, there's not much you can do when leadership is so terrible. If this kind of workflow is genuinely blessed by management, I would just start using Claude for code reviews too. Then when things break and people want to point fingers at the code reviewer, I'd direct them to Claude. If it's good enough to write code without scrutiny, it's good enough to review code without scrutiny.

cookiengineer 1y ago

You have two options: Burn out because you need to correct every stupid line of code, or... Start to not give a damn about quality of code and live a happy life while getting paid. The sane option is to join the cult. Just accept every pull request. Git blame won't show your name anyways. If CEOs want you to use AI, then tell AIs to do your review, even better.

jakub_g 1y ago

I feel like I went through this stage ahead of time, a decade ago, when I was junior dev, and was starting my days by: first reviewing the work of a senior dev who was cramming out code and breaking things at the speed of light (without LLMs); and then leaving a few dozen comments on pull requests of the offshore team. By midday I had enough for the day. Now that I'm no longer at that company since a few years ago, I'm invincible. No LLM can scare me!

yodsanklai 1y ago

> All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.” After you made your colleagues upset submitting crappy code for review, you start to pay attention. > LLM-written ones are almost entirely additive, Unless you noticed that code has to be removed, and you instruct the LLM to do so. I don't think LLMs really change the dynamics here. "Good programmers" will still submit good code, easy for their colleagues to review, whether it was written with the help of an LLM or not.

000ooo000 1y ago
>After you made your colleagues upset submitting crappy code for review, you start to pay attention. If the only thing keeping you from submitting crappy code is an emotional response from coworkers, you are not a "good programmer", no matter what you instruct your LLM.

zamalek 1y ago

> LLM-written ones are almost entirely additive I have noticed Claude's extreme and obtuse reluctance to delete code, even code that it just wrote that I told it is wrong. For example, it might produce a fn: fn foo(bar) And then I say, no, I actually wanted you to "foo with a frobnitz", so now we get: fn foo(bar) // Never called fn foo_with_frobnitz(bar)

igor47 1y ago
This tendency must get reenforced through RL in the training phase. It's very high profile when an LLM deletes the wrong thing, eg https://arstechnica.com/information-technology/2025/07/ai-coding-assistants-chase-phantoms-destroy-real-user-data/ https://arstechnica.com/information-technology/2025/07/ai-co...

smoody07 1y ago

This is a broader issue about how where we place blame when LLMs are involved. Humans seem to want to parrot the work and take credit when it’s correct while deflecting blame when it’s wrong. With a few well placed lawsuits this paradigm will shift imho

y0eswddl 1y ago
that's just capitalism 101 - privatize profits, socialize failures

brailsafe 1y ago

I think this is why I've been feeling less productive overall lately. Partly due to the fact that more code is expected to be produced more quickly, and partly because using an agent or something puts me into the wrong frame of mind where I don't really have the full context of what I've written and why, and the amount of quality work I can produce is necessarily qualified by how much I can reliably review, line-by-line, over whatever period of time. I've been using them more conservatively, slowing down, and manually writing things more. It's easier when I'm just replicating logic over a bunch of different well-defined properties of a clear type definition or spec, but even then results are a bit questionable sometimes.

Quis_sum 1y ago

I am probably too old school: Unless properly documented (the "whats" and especially the "whys") and provided with a test harness (plus the test cases, including all fringe cases btw.) just reject it straight away. And in the case it is provided and you have a hard time understanding it, reject it as well with the comment that, the "demi-god" (author) should provide documentation which mere mortals can follow. That principle can be applied to both LLM slop and handcrafted rubbish. Eventually most people will get it.

sqircles 1y ago

How are these "engineers" maintaining jobs? How is pushing code generated by someone/something else that hasn't even as much as been looked at before acceptable in any realm? Better yet- why are there orgs that accept this behavior? I know mine is far from it, as they should be.