The Programmer Identity Crisis

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.

> whereas good senior engineers often remove as much code as they add

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

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

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.

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.

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

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.

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.

"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson

What do you do if the manager enables it?

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"

The problem is leadership buy in. The person throwing the LLM slop at github has great metrics when the leadership are looking at cursor usage, lines of code, PR numbers, while the person slowing down to actually read wtf the other people are submitting is now so drowning in slop that they have less time to produce on their own. So the execs look at it as the person complaining "not keeping up with the times".

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

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

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.

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!

The solve is just rejecting the commit with a "clean this up" message as soon as you spot some BS. Trust is earned!

If leadership is that inept, then this is likely only 1 of many problems they are creating for the organization. I would be looking for alternative employment ASAP.

"A big enough system is always failing somewhere" - can't remember who said it

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.

Build the PR and run tests against it. Supported by all major CI/CD tools.

the issue isn't recognizing malign influence within your current organization... it's an issue throughout the entire industry, and I think what we're all afraid of is that it's becoming more inevitable every day, because we're not the ones who have the final say. the luddites essentially failed, after all, because the wider world was not and is not ready for a discussion about quality versus profit.

This a million times. If you do this three times, that's grounds for firing. You're literally not doing your job and lying that you are.

It's bizarre to me that people want to blame LLMs instead of the employees themselves.

(With open source projects and slop pull requests, it's another story of course.)

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

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

A poor quality product can only be profitable if no high quality alternative exists (at a similar price point). Every time that's the case, it's an epic opportunity for anybody with the wherewithal to raise some funding and build that high quality alternative themselves. A dysfunctional industry running on AI slop will not be able to keep you from eating their lunch unless they can achieve some sort of regulatory capture, which would be a separate (political) issue.

Regarding your Luddite reference, I think the cost-vs-quality debate was actually the centerpiece of that incident. Would you rather pay $100 for a T-shirt that's only marginally better than one that costs $10? I certainly would not. People are constantly evaluating cost-quality tradeoffs when making purchasing decisions. The exact ratio of the tradeoff matters. There's always a price point at which something starts (or stops) making sense.

I largely agree with sibling responses.

BUT...

How do have code review be an educational experience for onboarding/teaching if any bad submission is cut down with due prejudice?

I am happy to work with a junior engineer and is trying, and we have to loop on some silly mistakes, and pick and choose which battles to balance building confidence with developing good skills.

But I am not happy to have a junior engineer throw LLM stuff at me, inspired the confidence that the psycophantic AI engendered in it, and then have to churn on that. And if you're not in the same office, how do you even hope to sift through which bad parts are which kind?

To mentor requires a mentee. If a junior is not willing to learn (reasoning, coming up, with an hypothesis, implementing the concept, and verifying it), then why should a senior bother to teach. As a philosopher has once said, a teacher is not meant to give you the solution, but to help you come up with your own.

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

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

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

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)?

Yeah it doesn’t really seem different from people copy/pasting from stack overflow without reading through it. This isn’t really a new thing, though I guess nobody was really acting like SO was the second coming so it’s probably happening more now.

> Yeah it doesn’t really seem different from people copy/pasting from stack overflow without reading through it.

It is vastly different because there are no (as far as I've ever seen) multi-thousand line blocks of code to cut & paste as-is from stack overflow.

If you're pasting a couple dozen lines of code from a third party without understanding it, that's bad, but not unbearable to discover in a code review.

But if you're posting a 5000 line pull request that you've never read and expect me to do all your work validating it, we have a problem.

all the recent studies (that are constantly posted here) that say so.

...have you seen the funding numbers for AI startups versus non-AI? it's not even remotely close rn...

A major problem of the way we have built our society in a way such that the wrong people end up with the most power and authority.

the majority of engineers across the industry feel the same way we do and yet there's little most of us can do unless we all decide to do something together :/

that's just capitalism 101 - privatize profits, socialize failures

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 :-)

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

The Stanford study showed mixed results, and you can stratify the data to show that AI failures are driven by process differences as much as circumstantial differences.

The MIT study just has a whole host of problems, but ultimately it boils down to: giving your engineers cursor and telling them to be 10x doesn't work. Beyond each individual engineer being skilled at using AI, you have to adjust your process for it. Code review is a perfect example; until you optimize the review process to reduce human friction, AI tools are going to be massively bottlenecked.

Code review as an educational device is done. We're going to stop caring about the code before people who are bad programmers right now have time to get good.

We need to focus on architectural/system patterns and let go of code ownership in the traditional sense.

Because we know what the value is without AI. I’ve been in the industry for about ten years and others have been in it longer than I have. Folks have enough experience to know what good looks like and to know what bad looks like.

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

For interrupting the velocity and efficiency of the other dev.

I think virtually all leadership across corporate America is very metrics-driven. Unfortunately, that means this a lot of the time.

Aren't you effectively saying that no one will understand the code they're actually deploying? That's always true to an extent, but at least today you mostly understand the code in your sub area. If we're saying the future is AI + careful review, how am I going to have enough context to even do that review?

I expect that in most cases you'll review "hot spots" that AI itself identifies while trusting AI review for the majority of code. When you need to go deeper, I expect you'll have to essentially learn the code to fix it, in roughly the same way people will occasionally need to look at the compiler output to hunt down bugs.

Seriously. What companies are these where “Oops, Claude wrote that and I have no idea what it does” is even remotely acceptable? No company I have ever worked at. This kind of behavior would be corrected immediately, at all levels from the eng TL up to director if it had to go that far.

You have it exactly backwards. If you are consuming my time with slop, it’s on you to prove there’s still a net benefit.

An epic opportunity is an epic opportunity. If most investors are too stupid to notice one (yes, that is often true, I know), then that's also an epic opportunity for the 1 investor who might take the chance.

I'm not saying the industry is perfect, but if the scale of the missed opportunity is so large and so obvious to so many engineers, and we live in a world with tens of thousands of VC firms and probably millions of other avenues for funding like angels, incubators, and grant programs, it's hard to imagine 100% of them missing it. And it only takes 1 to take advantage.

There is precious little alternative employment that cares about the long-term sustainability of their software, is the problem.

Maybe that’s true of each individual case, but we still have the systemic problem of the way these AI tools interact with human psychology. It tends to turn off the user’s brain, even people who know better.

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.

Unfortunately, your reasoning has an enormous hole in it. A huge part of a product's quality is how it fares over time, i.e. how many years it lasts and how much it costs to maintain. Sadly, this either takes time or a realistic assessment to determine, both of which cannot part of a market bubble.

The 10$ shirt becomes a much shittier proposal once, in addition to its worse looks, fit, and comfort, you factor in its significantly lower durability and lifespan. That's why the 100$ shirt still exists after all. Nevermind that the example is a bad one to begin with because low-price commodities like T-shirts are never worth fixing when they break, but code with a paid maintainer clearly is.

In an market bubble like the one we find ourselves in, longevity is simply not relevant because the financial opportunity lies precisely in getting off in the train right before it crashes. For investors and managers, that is. Developers may be allowed to change cars, but they are stuck the train.

It's sad how some of the doomed are so desperate to avoid their fate that they fall prey to promises they know to be bullshit. The argument for Wish and TEMU products is exactly the same, yet we can all see it for what it is in those cases: a particularly short-lived lie.

Just addressing the comparison: a t-shirt can be changed for the cost of the new t-shirt. A software product costs not only the new one (being AI, very cheap) but also the cost of integrating it with processes and people - and this can kill you.

> We’re ultimately here to make money, not just pump out characters into text files.

Different projects have other incentives. Dealing with AI slop from internet randos is a very real problem in open-source codebases. I've pretty much just stopped reviewing code from people that I don't know on one project that I work on when it's obviously going to take way more time than it would have done to do the patch myself. There used to be an incentive to help educate new contributors, of course, but now I can't know whether that is even happening.

Human trust has to be earned, why should AI trust be any different? If I’m supposed to yolo-approve any random code a machine spits out, it had better prove to me it’s nearly flawless, otherwise I’m applying the same review regiment I apply to any other code. To do otherwise is to shame the word “engineering” and the field thereof.

What I mean is that, at least where I’ve worked, copy/pasting from SO without checking it and taking responsibility for it was already not acceptable. Making a machine generate it instead of a human is… still not acceptable.

Engineering is a game of tradeoffs. Time is one of the things you have to trade off, given your strong opinions I expect this is something you've been in the industry long enough to understand intuitively.

Regarding proof, if you have contracts for your software write them up. Gherkin specs, api contracts, unit tests, etc. If you care about performance, add stress tests with SLOs. If you care about code organization create custom lint rules. There are so many ways to take yourself out of the loop rigorously so you can spend your time more efficiently.

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.

In a scenario where what we're doing is describing and assigning work to someone, having them paste that into an LLM, sending the LLM changes to me to review, me reviewing the LLM output, them pasting that back into the LLM and sending the results for me to review...

What value is that person adding? I can fire up claude code/cursor/whatever myself and get the same result with less overhead. It's not a matter of "is AI valuable", it's a matter of "is this person adding value to the process". In the above case... no, none at all.

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.

> Regarding proof, if you have contracts for your software write them up. Gherkin specs, api contracts, unit tests, etc.

We really need widespread adoption of stuff like design-by-contract in mainstream PLs before we can seriously talk about AI coding.

You don't need regulatory capture to monopolize a market.

What happens in practice is teams are made "leaner" by laying off people (and, as seen in Microsoft layoffs, the people targeted are often veterans, due to their large salaries - which means that the team loses a lot of deep knowledge of the code in the process). And then the remaining ones are told to deal with the same amount of work as before, since "AI makes you more productive". I can't blame the remaining developers for saying, "fuck you then, I'm going to do the bare minimum". The blame is entirely on the management, and every single big tech company is complicit.

Yeah, fair enough. This applies to both business cases and OSS and the OSS incentive often isn’t money.