site banner

Culture War Roundup for the week of September 21, 2026

This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.

Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.

We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:

  • Shaming.

  • Attempting to 'build consensus' or enforce ideological conformity.

  • Making sweeping generalizations to vilify a group you dislike.

  • Recruiting for a cause.

  • Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.

In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:

  • Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.

  • Be as precise and charitable as you can. Don't paraphrase unflatteringly.

  • Don't imply that someone said something they did not say, even if you think it follows from what they said.

  • Write like everyone is reading and you want them to be included in the discussion.

On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.

4
Jump in the discussion.

No email address required.

This is really the phenomenon I'm describing. I cannot believe there are people who believe what you just said- that using the latest models, an LLM can't create a good PR including a good PR description. You are just in denial in order to protect your ego, like before it was "LLMs will never be able to code as well as me" but now that's gone so these uppity engineers are pretending LLMs can't write PR descriptions when they absolutely can do so very well with barely any handholding.

It is not the case that LLMs are capable of writing ~99% of code but are unable to write PR descriptions of the code they wrote, it is the case that egotistical engineers still want to assert a sense of superiority by calling things "AI slop" which are actually well-written and useful and vastly superior to what they would have handwritten by hand.

Show me an example then. I'm waiting. I've seen dozens of prs from the latest claude opus and they all suck.

If AI is as good as you say it is, surely there must be one pr in an open source or source a available corporate project that demonstrates this.

This is an example of an AI-generated PR with an AI-generated PR description I would instantly recognize as LLM-generated. It's totally fine. Yes, it's obvious that it was not written by the engineer and that's honestly what sets off the uppity engineers who complain about "AI Slop" that majority of the time. They can just tell it was written by AI so they complain and nitpick.

This pr description sucks, but you're just going to say that anything I say is just complaining and nitpicking.

So it seems we're at an impasse here.

Can you take that PR and write a better description that you think would be more helpful than the AI one?

It seems like that would be the major step forward: instead of saying "it sucks", break down the problems with it and provide a superior human-generated one for the same content that we can compare it with.

Good question, here is something along the lines of what human might write. Keep in mind it may be incorrect because I don't actually know what this pr accomplishes.

We discovered a race condition in follow up actions which can cause them to fail if multiple follow ups are requested at the same time. An example of this failure can be seen on #2555. This is because the PR lock is removed before the worktree is cleaned up, allowing the second task to begin execution before the follow up is completed. Here is a timeline of the events on 2555 that shows the issue:

[timeline]

  • This change updates the order of operations to clean up the worktree before releasing the lock.
  • This change also adds a safety net fix for situations ???? <- the ai slop makes zero sense, no idea what this does.

I appreciate the followup.

It seems like the concern is that the AI PR is over-technical and doesn't explain in simple language what happened: I don't see a lot of functional difference between the two. I can see the case that going back in and looking at the AI one will be harder to pick back up on "what exactly did this do", but I think I could figure it out from what they have: the AI writes overly technically, but I could easily see a human doing the same thing.

This change also adds a safety net fix for situations ???? <- the ai slop makes zero sense, no idea what this does.

It looks like there was a situation where if the directory for a worktree was gone, 'git worktree remove' isn't actually going to remove the worktree registration (presumably because it's intended to remove the directory and the registration at the same time, and possibly the original race condition detailed in the PR created a situation where that didn't happen properly for some worktrees), so it introduced a secondary method that checks "is this worktree safe to remove" then removes that worktree registration with a different command, to clean up that situation. There's another mechanism that could remove all stale worktree registrations, but the AI goes out of its way not to run that because it would create another race condition risk.

I checked the code to confirm that, but I do think that PR note actually does make sense, and someone more familiar with the codebase and effects than me (I honestly don't know what a git worktree is) would understand it more easily than me.

the AI PR is over-technical and doesn't explain in simple language what happened

Yes a major issue with slop is that it buries the information in ... well ... slop instead of explaining it clearly. A human may write badly in a human way but would never do something like this.

There are other substantiative issues here, mainly that 2555 is simply an example of a failure in this class, and likely there are other occurrences. It also doesn't mention what situation may trigger this issue.

You can just have a more detailed PR writing skill defined that tells it to start off each note with a concise description of reason for the enhancement. It's really quite easy to set this stuff up.

More comments