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.
Oh. RIP. "You were supposed to be the chosen one", or something.
Maybe it's my eternal grumpy old "real programmers should write in..." fart eyes biasing me, but every single major project written in Rust that I have tried so far turned out to suffer from the same problem as major projects written in Python and JavaScript did before: it doesn't crash, but it sucks in more subtle ways that make me think that (1) if the language didn't prevent that, it would probably crash every 5 minutes and (2) if it did that, its developers and defenders would at least realise how bad their program is. It's strange because when the "it's memory safe and allows you to focus on the important things!!!" language was Python/JS, the obvious theory to explain this was that the language enables incompetent programmers who are not actually up to the task of engineering big pieces of software; but Rust is not even particularly easy to write, and arguably harder than C++ (unless you fully commit to the early-2000s high corporate obnoxious_template_factory<namespace::bullshit_factory<allocator_factory<...>,...>> style). Still, the filter fails. Maybe the missing puzzle piece is just the AI: it has no trouble emitting walls of lifetime sludge that passes the compiler, but is no better at big-picture decisions than the Python script kiddie, all the while its script-kiddie-in-mindset handler looks at it and figures that because it is Rust and it runs, the program generated is definitionally beyond reproach.
What's a concrete example of sucking "in more subtle ways"?
The most recent example I can think of is Zed, a "work with LLM agents" IDE written in Rust that has been getting a lot of traction (and seems to be the only way around to do this with a GUI if you don't want to touch Electron). I gave it about two days' college try since I'm on the market for a new IDE (after CodeLite got enshittified with a recent update). Specific examples of suck about it:
Quiet or inexplicable failures. If it doesn't like the way the LLM it connects to formats something, it either leaves you with an unactionable error message ("missing field 'path' in tool call") or outright does nothing (such as when it doesn't like the structured text format it gets back from the LLM it connects to for its "smart autocomplete" feature - a state that is indistinguishable to the user from "I failed to connect", "the suggested completion is empty" and "the model is still working"). To debug any of these things, you have to get the raw JSON data it received out of an undocumented sqlite file, and guess what the expected schema is, because that is also undocumented. (It's hard to figure out even from looking at the source, because the JSON data seems to be fed into the handling Rust class by some weird metaprogramming magic rather than an explicitly defined format.)
Sometimes parts of it, like the LSP integration, just stop working until you restart it. Again, no visual indication of failure state, the feature just doesn't fire anymore.
It tries to do something clever with pending edits, but there is no coherent underlying model. A lot of LLMs clearly assume that they can keep drafting and re-drafting an "edit file" tool call, like submit one that says "add a line saying X between the line that says A and the line that says B" and then follow up with "add a line saying X and a line saying Y between A and B". The latter fails because for the purpose of that tool the state is now A\nX\nB, but if the model tries to read the file again to get a consistent picture it still only reads A\nB.
Clearly there is lots of internal code duplication, resulting in non-orthogonal config duplication. There are separate configurations for the "agentic" LLM connection and the "autocomplete" LLM connection, supporting a slightly different subset of protocols, with slightly different design choices e.g. about whether you give the top-level URL of the API endpoint or the most specific one.
There is no build system integration whatsoever (even though this is the sine qua non that distinguishes an IDE from a fancy text editor), but the lede is buried about this. I get the sense that they want to have this eventually, but are just not too excited to work on it, while not wanting to pay the marketing cost of outright saying "we are not ready for prime time yet".
There is debugger integration, which is supposed to be able to do fancy modern things like letting you see variable values by hovering the variable in the source as you debug. This works about 10% of the time, again with no indication when it fails.
All of this hints at a level of engineering that, if it were C/C++, I'm sure would result in a program that is unusable due to segfaulting all the time, with a reputation to match. In Rust, it instead just keeps running, slowly piling the frustration on you, while the developers psychotically add one shiny new feature after the other and leave the occasional bug reports about the above to rot without a response (because who cares about one user's unverifiable report that some asynchronous thing didn't appear? It's not like they can bring receipts in the form of a stack trace, because there was no crash).
In fairness, Zed is a new project, furthermore every failure you've described I've encountered some analogue in early (C++/TypeScript) VSCode (quiet failures, random things stopping, IDE edits corrupting source, duplicate config, build system was pasting JSON into the config that runs a shell script, debugger was a buggy mess).
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link