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.
Jump in the discussion.
No email address required.
Notes -
AI & open source
What do you think about LLM's impact in software development?
Inspired by recent events in open source:
Bun's LLM-assisted rewrite
The Bun project was translated from the Zig programming language to Rust, mostly by LLM. This task usually takes months-to-years by hand (e.g. Rust to Zig rewrite), but with the LLM it took 11 days. Its success is debatable: the code isn't idiomatic Rust, and lines-of-code increased 67%, which suggests it will be harder to maintain, but it works (passes the thorough existing test suite), and the maintainer says it's going well in a blog post that provides more details.
In response, Zig's maintainer wrote a scathing blog post personally criticizing the Bun maintainer credited for the rewrite ("[he] was already writing slop well before he had access to LLMs"). Zig's maintainer is known for blunt strong opinions: he previously moved Zig off GitHub and the announcement was rewritten twice to be softer on GitHub employees.
Earlier, the Ladybird web browser was also rewritten in Rust mostly by LLM. This got less attention and controversy, probably because it was announced better, and the previous language was C++ so they got more sympathy (2-hour video on why C++ sucks).
Rsync's LLM-assisted bugs
Rsync's maintainer got accused of "vibe fuck[ing] up this software", and the discussion got very heated. He explained he has been using LLMs a lot because he's getting lots of vulnerability reports (see below). An AI-assisted analysis concludes the LLM did introduce bugs, although not more than the usual amount.
LLM slop contributions are overwhelming open source maintainers
Many projects are seeing a massive influx of low-quality contributions by inexperienced software developers and bots, heavily relying on AI. This has caused some to stop accepting any outside contributions, while others have added strict LLM contribution policies (see below).
Example: an LLM managed to implement an entire big feature, albeit incorrectly. The file headers also credit random people who it presumably stole code from, thankfully(/s) the LLM concluded there are no copyright violations.
Serious LLM-discovered vulnerabilities are also overwhelming maintainers
Among the slop contributions are actual vulnerabilities discovered with the help of the latest LLMs like Mythos. There's a vague background threat that open-source libraries will become too dangerous to use, but LLMs can also find closed-source vulnerabilities, so it's unlikely.
Cal.com has made their core codebase private and announced "open source is dead", but others point out this probably won't help them, and AFAIK this hasn't become a trend.
curl ended its bug bounty program because of an "explosion in AI slop reports", but still accepts reports and admits they have improved because LLMs have become good at finding vulnerabilities. Although Mythos only found one benign one, because curl is one of the most hardened codebases that exists. Still, legitimate (maybe-issue) reports have increased causing more work for the maintainers, so they're taking a vacation this month.
"Vulnerability Reports Are Not Special Anymore", written by a former security lead, explains that the recommended process to handle them has changed due to LLMs
Open-source LLM contribution policies
Due to the aforementioned slop contributions and/or general ideological reasons, many projects have banned LLM usage entirely, while others require it to be disclosed. Big list. Highlights:
Misc
Picrocrypt's maintainer quits open source because of LLMs: "I want to do something actually meaningful and innovative with my time and life, not command Claude like I'm speaking to a child who forgets something every ten minutes and makes an oopsies every twenty before breaking down every hour."
We mourn our craft: senior developer laments hand-writing code becoming obsolete.
The LLM Critics Are Right. I Use LLMs Anyway. This guy outright admits what most people quietly do: criticize LLMs while using them.
My opinions
For reference: I'm under 30 and have been writing code for most of my life. I've written open-source projects, although they're not popular enough to get LLM contributions. Today I work in formal methods (theoretical computer science). I've always expected my future to involve creating software.
I am sad and worried that software development is changing. I enjoy working with code directly and making it (opinionatedly) well-designed, writing prompts is less intuitive to me and it's harder to control the design. I worry if most of my time spent learning to code better has been wasted, or even my entire Computer Science career.
But software development is much more than writing code, and my specialization is much more than software development. Although I've intrinsically enjoyed it, to me, writing code has always ultimately been a means to an end. And now with LLMs I write code much faster and easier. I also still write lots of code directly, LLMs (even Fable/Sol) can't fully automate my work at least yet.
As I wrote before, in the long term I'm neither optimistic nor pessimistic about AI, but I think it's inevitable and most people should learn how to use it to their advantage. I think it should be possible for those who really despise LLMs to continue to do things manually, there should be a market for "hand-coded" software etc., but they will be at a disadvantage.
I share Linus's opinion that AI is a tool, clearly useful but can be misused or misapplied. I believe its future (at least near term) is for boring uncreative tasks. For example, right now LLMs excel at straightforward (not idiomatic) translation and research, but struggle with high-level design. They also suck at art (no good examples except shallow memes, this is my experience elsewhere) and creative writing. I believe AI's future shouldn't and probably won't be creating art, because humans intrinsically enjoy it and make it very specific to their personalities; but it will make tools that humans use for art.
Lastly, I believe that ideally everything digital would be free and its creators would be paid another way. This means I have no issue with LLMs training on open-source, except they also trained on copyleft (GPL) code, they should be open-source and open-weights themselves.
When I look at what AI has been doing to the emulation scene, I think it has been a net positive. You have some emulators like Yaba Sanshiro and Ymir where the devs have embraced it and game compatibility/feature development has skyrocketed. Sega Saturn has always had mediocre emulation and now it is rapidly improving.
Even for emulators where the devs don't want to accept AI code into the main codebase, people are creating PRs/forks with features that have been requested for years. You can now create a custom version of melonDS with built-in shaders, RetroAchievements, a Vulkan renderer for better Mac compatibility, and texture/sprite layer scaling. All a technical user needs to do is ask their copy of Claude/Codex to glue it all together. The end result might be a bit buggy, but emulation has always been buggy.
I can understand why maintainers are annoyed by these PRs, since they are essentially being asked to take on the maintenance of vibe-coded features. However, I think people should start seeing the PR tab on GitHub as more of an "optional feature list" where you just pick and choose whatever you want.
I believe the end result of this will be an increasing number of forks. You will have projects that are known as well-tested/battle-hardened, people will build AI-assisted forks on top of them, and some features that prove their worth will be merged back into the base project. In other cases, where a project never merges AI-created features, maybe because the devs don't want the maintenance burden or hate AI, most of the new development will likely happen in forks, and eventually one of those forks will become the version of the software most people use. From a user's point of view, the point of software isn't to be an artisanal work, the point is that it accomplishes a task.
I mostly agree with your points, except
Anyone completely vibe-coding a PR should submit a regular GitHub issue, since the maintainers could vibe-code it themselves, but more likely will have a usable implementation. A vibe-coded PR for a big feature can’t be merged without potentially making the codebase unmaintainable, so it’s really just an issue with a working example.
Creating a fork with the vibecoded change and linking it in the GitHub issue (for maintainers to get hints from and other users in the meantime) is preferable and good.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link