This is democracy in action. A fair and square vote and look at how well it works with no core BDFL to force in their opinions.
Maybe someday we'll have direct democracy paired with voting certification for specific issues.
I'm beginning to wonder if it might be the case that when my fellow citizens begin to act insane - might it be the result of foreign propaganda.
Personally I would have voted "nuke all AI", even though AI has some beneficial use. I simply feel AI is too dangerous in projects. Ruby has been mostly slurped up by AI - almost all code contributions are now run by master claude. A few months ago this german dev on the ffmpeg mailing list spam-slopped his fellow guys with an AI-generated proposal. He did not have time to write a real proposal - but he had enough time to have AI slop pester spam other humans. I am sorry but AI really should not be leaked onto other human beings. It's not nice to do so. And the "AI is there to stay" does not seem like a valid excuse to me to spam-slop other humans. Skynet is winning here - it is recruiting humans to love AI.
A quality based filter. Excellent.
> The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit.
Absolutely.
Thanks, Debian!
This will turn to shit because laziness will take over and comprehension will fall as a consequence of that. Junior will "contribute" and the seniors will eventually become too lazy to care. What's next... vibecoding airline ADA code. Save me lord jesus christ.
While doomscrolling HN right now, I have an agent crunching away at figuring out how to build a flashable TWRP ZIP file, because I could not care less about such android specifics.
Such use-cases would be blanket banned by some of the harsher options, forcing people to do stuff they have no interest in doing, for reasons that are at best well-meaning.
Which, in something volunteer-driven, is not necessarily a good idea, because if you're not allowed to do the work in the way you'd like to, you might just stop doing it altogether.
That said, if your work ends up shit, you still shall get shat on. Simple as that.
Quite. Of the two different common meanings, I reckon:
"The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit."
will be true in the sense of "Who the hell is responsible for this mess?"
But there was some electoral spectacle.
What else is new?
How absurdly naive.
I don't believe they had a choice though, sticking to hand written code would be backwards and eventually meaningless as people would just submit generated code as "handwritten", the coding models are quickly becoming capable enough for this.
I wonder what it means copyright wise though. To what degree is the code even copyrightable if it's entirely generated, even if you review and provide feedback.
1. Companies will revert to closed-source and cease contributions to F/OSS projects. Their legal team will advise them that trade secrets are the only way to protect LLM-generated code.
2. Contributors to F/OSS projects, and developers who run them, will falsely claim authorship of the code written by LLMs.
https://www.cnbc.com/2025/04/29/satya-nadella-says-as-much-a...
Note that he said written by, not assisted; and also that there's been some major QA issues with win11 the last year, enough for Microsoft to have made a public apology/commitment to improve...
So, no definitive evidence, but the rest of the breadcrumbs provide enough to say that yes it does appear to have suffered from it.
Given the Debian policy seems more geared towards aided/assisted an existing dev than replacing them and shipping because the code works on the golden path on a devs monster pc ... Well I'd still keep an eye on it but trust OSS OS engineers to have some competence at knowing if this works and adjusting the policy later if it proved to be wrong.
Now the argument that genAI is helping them find and fix bugs faster has a lot of merit because it can be pretty darn good at that. But for lack of a better phrase, 'The Windows 11 Experience' feels, as other users pointed out too, either vibe coded or like the dev teams went insane. I live and die by Debian in my servers and I really hope the same kind of thing doesn't happen to them.
The rumor is the opposite, that Microsoft has actually used AI to discover and fix common security issues at scale.
Your appsec engineers will be the ones bug hunting with Mythos or whatever. Your regular engineers will be the ones implementing features. If the feature is a bad design and functions badly as a result, that is entirely orthogonal to whether it contains coding errors or bugs.
Also, there are bugs on the integration side that won't be caught running Mythos against source code, because it's not a source code issue. Even using Mythos for DAST is going to be very limited compared to how actual users will move through something as complex as a 'mature' OS like Windows.
the entire industry is experiencing this as model capacity increases. How does "all projects get critical security fixes now" relate to "crap apps and loopy services by literally millions of lines of slop code" ?
Local models are going to be really important and hopefully computing costs don't make it too prohibitive.
Sure, it means that selling intellectual labor is reaching the end of the line, and the value of learning will drop, but there's a lot more wealth that will be generated.
Experts have been badly bitten by poorly written and badly architected software, lost their hairs trying to figure out bugs and poor design.
They recognize the first version of a piece of software is only a miniscule percentage of the work and majority of effort goes into maintenaning it for its lifetime.
They are viscerally horrified at a thousands of LoC codebase generated at the speed of GPU inference they are to be responsible for.
The examples I'm thinking of have definitely profited foreign interests, tho.
Look to see who profits.
Now, is my code better than the AI's equivalent implementation? No shot. It's nicer for people, artisanal hand crafted, but... there's a reason I use AI.
There are significant societal impacts of this AI buildout. Some are concerned externalities weigh more heavily on the poor and marginalized. I think state wide data center holds are part of this civil discourse.
I'd prefer we have more conservative pollution standards along with a reasonable tax on AI use that helps mitigate externalities. That's hard. Reasonable people can have fierce disagreements on what market interventions are indicated, and how extensive they should be.
Is there a term for this? Ensnarkification? I see it on X and bsky all the time.
https://pbs.twimg.com/media/HQ5MeeaXUAAIMLX?format=jpg&name=...
Somewhat insulting to those that actually lived (or live) under fascism.
It's as though people want to find the most dubious of non-existent connections and use that as leverage to besmirch something they don't like.
There are many things one can do where a person has no awareness of the tenuous connection but where you can have someone go back and then ex-post make that connection and declare that thing or person racist. It's a tactic.
Like one _could_ make the argument that factory automation in China is racist because without automation they would have to import labor from (some non-Chinese population). However, the Chinese never began automation with the intention of being racist.
Repeatedly.
You are right that's one or the other. Probably both are contributing.
Taste also feels easy enough to automate. I'm not sure why anyone thinks it's harder than anything else.
In any case you can say the exact same thing about reading. Take the book away and bam, you know nothing. A person who memorized the book is not dependent on an expensive, heavy thing like a book.
A lot of developers who are submitting these AI patches don't necessarily understand the patch, so the onus is on the reviewer/code-owner.
The reviewers are getting swamped (some reviewers are receiving 100s or patches per month). If feedback is provided at lot of the time the patch author will just copy paste from an LLM, so the reviewer is essentially just coding with an LLM with more steps.
Prior to LLMs reviewing code was a mentorship experience, the patch author would likely learn a bunch afterwards. Now less so.
As a result a lot of projects are closing to external contributors.
I'm not sure what the answer is, LLM are great at speeding up coding/understanding/etc, but the valuable/expensive piece of work has shifted to reviewing.
But, we have long had a stable social system for collaboration, and in particular dealing with low quality contributions. Mostly (or at least ideally) it involves taking some time to look at the contribution and provide some feedback. The time invested is not worth it on a single exchange basis, but it’s a repeat game, so you are investing in the future.
LLMs, and people willing to just spam crap they don’t really understand blows that all up.
All project contributions must be submitted by *identifiable human participants* who accept full responsibility for their content. Automated agents, bots, or autonomous AI systems *may not* independently submit issues, pull requests, or other contributions.
Contributors may use software tools, including AI-assisted tools, but the submitting contributor *must:\*
- Fully understand the contribution.
- Be able to explain design and implementation decisions without the use of AI.
- Accept responsibility for maintenance and correctness.
Contributors should indicate AI-generated content in issue and pull request descriptions and comments, specifying which model was used.
Do *not* use AI to reply to questions about your issue or pull request. The questions are for *you,* the human, not an AI model.
We've come to the same conclusion in our organization and while it felt like it needed to be discussed and stated, I've never heard of anyone coming to a different conclusion.
[EDIT: I was referring specifically to the idea that you have to stand by the code that you write. Is anyone deciding on a policy that says "the AI did it" is a valid excuse for breaking code?]
I'm not saying that anybody should be obligated to review large volumes of low confidence code... just that we should not make policies that ignore shades of gray which, with some collaboration, could bear fruit.
I think the dust has kind of settled though for engineering teams on: You must use AI for your work, and you must stand by your work.
The meat between these two mandates are still being fleshed out.
Problem is, that you realise very quickly the asymmetry of responsibility and effort. There is far more to review from people who do not care enough to even look at what the agent pooped out.
My job has been less watching Claude Code, and more watching Managers Claude Code.
I don't know which I hate more as a programmer.
I wholly agree with your comment, but is it legally "your code"? Copyright is implicit at the moment of human creation. But there isn't yet settled law on AI-assisted creation.
So it might be a problem for projects to accept contributions where it's not clear who actually owns that work.
Literally irrelevant and I have no idea why people even bring this up constantly. Copyright is practically unenforceable in the software world, when was the last time you saw someone (a company or an individual) actually sue _and win_? Apple wasn't capable of stopping all the other phone manufacturers from directly cloning their product (despite having patents & copyright) so how can an individual? The only thing that matters is execution.
For instance, my repos are cloned like ~100/week by what I presume are bots and AI lab scrapers using them for training material. How am I supposed to even find out who's doing it, and if they're abiding by the licenses I provided? It's impossible.
Lastly, having copyright isn't the same thing as being allowed to commercialize the software (and I believe loads of people confuse the two). You can still sell public domain code, even if you don't have copyright over it.
Who would they be making the claim against? Well, considering the massive uptake of AI across the tech industry & beyond... approximately everyone.
Yes, the model companies are in the middle, but it's getting to the point where it seems a bit doubtful that claims will have any significant outcomes.
NYT might be able to get OpenAI to pay them for their content, but that's more of a financial tweak than a up-ending of industry.
I think the term "stake your reputation" is quite good for this situation. I.e. "hi new contributor, please acknowledge that you Stake Your Reputation before we move ahead with this code review".
(Doesn't help with legal aspects of course)
This whole phenomenon of "workslop" was a symptom of organizational dysfunction rather than any shortcoming of AI. I really cannot understand how people are producing or even tolerating any amount of workslop -- let alone the epidemic people complain about -- without professional repercussions.
If someone makes a sloppy 100,000 line PR in a day the problem is not whether it was generated by Claude or frantically written using VIM and a mechanical keyboard.
Like what are the actual real consequences if it turns out your code is bad or whatever? I assume you get banned from contributing?
I couldn’t immediately find any more information on what this all means in practice
Had someone at $DAYJOB just shrug and say Claude messed up when I pointed out a sql injection in the code in their PR.
It became explicit policy at the company after that moment that blaming the AI is not an excuse for shoddy work.
It kind of is if the company mandates LLM use.
It is sort of sad that now programmers are suddenly expected to be perfect reviewers of code they didn't write.
Well most of the time but either way that’s on me.
When you ask others that use AI frequently, the responsibility and understanding on what the agent wrote does not go away. You need to know what you are doing.
As soon as attackers are also using AI against your project, you have no choice but to use AI to protect yourself.
You’re also responsibility not to write crap PRs.
Maintainers should quiz the submitters on the code and if they fail to answer reasonably the PR is dropped with the comment: "A.I. slop" and de submitter banned.
Sure there is. Contributing to open source is a privilege, not a right. Abuse it, and find yourself unwelcome as a future contributor
When I am at home practicing my musical instrument or learning to paint, those aren’t paid activities, so I can’t demand high standards for myself.
When Habitat for Humanity is looking for volunteers to do electrical and plumbing on homes, they have to allow unlicensed random folks do it.
This is not how life works at all.
The whole voting mechanism just exists as an elaborate dance that makes everyone keep their face, while the only sensible option wins.
A bureaucratic tarpit for bad ideas and emotions.
In a better world, none of this would be necessary, but we live in this world, and for that one, it's nice that someone engineered the system that way. Good job.
[1]: https://www.visidata.org/blog/2026/ai/#self-assessed-ai-leve...
I don't really see much value beyond the 3 levels of AI disclosure that have been floating around:
- fully human - ai assisted - ai generated
Why would you trust the bot to self-assess truthfully?
That's like trusting a spammer to tag his emails as spam.
AI agents are grounded on the user provided direction. If it doesn't work well then it naturally loses trust.
> What LLMs in Debian development will do, I fear, is eliminate any incentive to scrap boilerplate or reform policies that require a lot of other senseless human effort. If I had had access to LLMs 30 years ago, I might have just had them generate the rules files, replate with complexity. So they will make Debian even more firmly what it is, and ever less likely to explore what it could become.
I use and like LLMs, but it does feel like structural social changes are harder to do. For example, creation of new protocols. I hope I'm wrong, and LLMs are used to build collaborative, community projects - not just everyone vibe coding their own incompatible software.
And thus this will all bias towards complexity and fragility..
Aside from Bun, which is owned by Anthropic, do we know of open source projects that allow AI where this has happened?
he also seems to have absolutely no idea what he is talking about
Option E beat literally every other option, so it is an unambiguous Condorcet winner.
Bradley–Davidson analysis: https://gist.github.com/tulior/74479b28ddd1e191e5b2d89b8b68c...
The Bradley-Davidson model gives Option 5 a 99.9993% posterior probability of ranking first.
Options 2 and 6 are effectively tied for second.
Option 5 also beat every alternative head-to-head. Its closest matchup was against Option 2, at 57.8% to 42.2%, so the result was decisive overall even though the closest pairwise contest was not a blowout.
Do court decisions that limit copyright protection of AI generated content cause problems for open source? Isn't there a requirement for a "Mental Conception" of the code output when using such a tool? Even copypasta requires you to somewhat know what you need to do, where "automated bug finding", does not seem to.
I find AI useful for small shell scripts that you can visually inspect.
I want to make a GIF later, so I'll probably ask Duck.AI how to write the command if the file path to the MKV is X and the timestamps are Y and Z.
Then, I can create my own little tool without downloading some shady binary that slaps a UI on Imagemagik(sp?) or whatever.
I've only played with AI a little bit, with a focus on local LLMs, but even simple things like an anonymous FTP scanner I wrote took a lot longer than someone slightly more skilled than me could have done them in.
Anyways, I always respected how Debian gatekeeps access to the code -- some kinds of gatekeeping are cool and good, and a lot of young folks fight with devs trying to show how smart they are -- I've been guilty of that myself in my youth.
I was curious how Fedora is moving on this question, but I don't know where to look. And if one wants to hop distro either towards or away from AI, it would be nice to have a place to see the relative adoption.
Linux distros are the perfect place to have a wide marketplace of options to suit every person, from completely anti-AI to completely YOLO vibe-code.
But I would still love a page that was basically a table of distro, decision status, decision, etc. so that anyone interested could make an informed choice without having to scour forums, wikis, mailing lists, chats, etc. for each and every distro
I relate that to how a Physician's Assistant gets their authority to treat patients from the Doctor they work under. The Doctor's credentials are on the line if their PA screws up.
Being a full time AI hater is counterproductive.
Commercial vendors with full time employees are leveraging for maximum benefits, why would a project depending on volunteers resist? Not forgetting it's shortcomings
skynet -v mooSource: https://marc.info/?l=openbsd-tech&m=177425035627562&w=2
Is there an open source, community maintained coding policy to feed to agents?
For example, I’ve seen senior devs outsource their thinking entirely to Claude, then carefully (slowly) generate code that’s not slop on a per-line basis but is slop on an architectural level.
Debian has begun voting on the future of AI/LLM contributions
https://news.ycombinator.com/item?id=49309050
Debian polls its developers on AI: permit or ban?
It's worth noting that Debian has no code production, so the LLM debate applies differently than an open source project.
I'd assume the main workload is testing, reviewing code for maliciousness or inefficiencies, adding packages, responding to issues (90% being passing the issue downstream), perhaps setting configurations, and providing some documentation.
I don't quite see LLMs being very helpful for most of these. And for some, like generating documentation, LLMs should be strictly forbidden.
A new technology, AI, greatly reduces costs in software development. When a new technology makes inputs cheaper, there's a choice: Reduce the cost of the product, or keep the cost the same and spend the newly available resources on improving product (or somewhere between those poles). For example, if the cost of chickens goes down, the farmer can buy a lot more chickens and produce a lot more eggs, or they can keep their expenses the same and now afford higher quality chickens or production (free-range!).
In software development, facing this new trade-off, people seem to overwhelmingly choose to produce the same software but far more of it, whether or not anyone wants it.
What if instead we made much higher quality software? Larger projects, at least, haven't wanted more pull requests; they have wanted better code. With the AI handling much of the work, the developer's attention can be applied to more difficult tasks. We absolutely need better software, especially with AI systems finding exploits.
( T T ): - *: ‑ X
Because it's perfect for that. Basically designed for it.
It's a tool. Like a calculator. Or a shovel.
You use it do get things done for you.
He didn't say he was surprised by the options offered. He said he was reassured by what he considered to be the common sense option winning. As was I.
It didn't just win. Debian uses Condorcet voting, which does the equivalent of running lots of mini elections - pairing the options against each of the others in one on one contests. Close contests need a tie breaker mechanism as you get A beats B, B beats C, C beats A. Not this time - the winning option defeated all others in its one on ones.
I found that surprising. There are a few options close to option 5, the winner - only slightly less liberal. Effectively the most extreme option won, and not by a slim margin.
I, and I suspect the OP, wasn't surprised at the range of options offered. This is par for the course - Debian is a very robust democracy with its fair share of opinionated individuals. There has been a lot of noise about the LLM's. The surprising thing is what I regard as the common sense one was at one extreme, and that "extreme" position won easily.
I guess it's yet another illustration of the level of on online noise being a lousy indicator of what the normies are thinking. Yes, that's obvious, but when the level of noise is high it still can catch you by surprise.
Edit: The two most restrictive options were ranked below "None of the Above". That's the strongest rebuke a Debian GR can deliver to a proposal. Under Debians rules, if an option loses to "None of the Above" it can't win regardless of the outcome of the other mini elections. I don't think Debian could make it's position much plainer: LLM's are just another tool a developer can use at his discretion, and are to be treated no differently to any other tool.
too many patches from unknown and untrusted contributors is a triage problem - telling a known and trusted contributor they can't use AI to help work on something just because other people are sending slop for review is throwing the baby out with the bathwater.
Obviously some do it illegally but unenforceable is not the correct word to use.
If you drop the copyright claim you drop the protection of free software freedoms.
Corporations like Coca-Cola long ago figured out that begging people not to steal your ideas is a waste of time. If you don't want people using your ideas, then don't share them.
Dunno why so many programmers don't get this and seem perpetually butthurt that other programmers figured out the ultimate way for programmers to rip off each other's code.
I imagine few can afford a legal battle...
Free plan
Images generated on the Free plan are public and owned by Recraft
It's not, because you can still quit.
What? The reviewer (me) caught the injection in the code I didn't write.
Running /code-review and /security-review on your own code before submission is bare minimum, not perfection.
Too late. If it doesn't work well then it has already naturally destroyed trust.
Debian isn't a free-for-all, they don't accept fly-by-night contributions, there needs to be a real and serious person behind every contribution.
For long term maintenance you need to throw features out / delete code, which requires a deep understanding of the balance between what the code can survive and what is really needed in reality while not growing the code base too much (which neither LLMs nor humans can handle)
I do this exercise myself for code that I really care about: after AI has written the code and I think I have achieved a full understanding, I unapply the entire patch and make sure I can reproduce the patch with the same underlying idea perhaps with less verbosity in the comments. That’s what I call fully understood. If I “mostly understand” some AI code, it means during the reproduction I need to occasionally look back at the AI code to continue.
If it had happened early enough, code copyright might never have even been possible and no one can deny you your machine because you can just vibe up stuff.
The way I see it, modern environmentalists like to pick on data centers just because it’s an easy target without entrenched lobbying. The fossil fuel industry is way worse but they have tremendous lobbying.
This is where the vegan point comes in. Do you eat meat? Congratulations, you consume 1000x more water than a dozen vegan vibecoders pumping out slop 24/7.
It’s good to be environmentally conscious, but big picture here. There are reasonable ways to reduce your water and electricity consumption. Not using AI is just not one of them. There are dozens of low hanging fruit before that. The most obvious is reducing your meat consumption. You can switch to LED bulbs if you haven’t already. Shower with warm, instead of hot, water. Buy second hand clothing or furniture. Etc.
I have Things To Say about LLM reviews.
They are an endless grind. My biggest source of burnout right now is never being able to finish anything, because the LLM always finds, "Just one more thing" every time I send it back.
It's pure polish. The major issues were dealt with long ago. But there's always one more thing that could be done a little better, there's another niche edge case that needs wrapping up.
When human developer time was the limiting factor, it was easy to draw a line in the sand and say enough is enough.
It's harder to say no when it's just one more prompt and one more go-around.
Demanding LLM reviews on volunteer maintainers sounds like a great way to quickly end up with no maintainers.
Held both weakly by CISA:
https://www.cisa.gov/resources-tools/resources/memory-safe-l...
And more strongly by the NSA:
> NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection C/C++ and assembly, to a memory safe language when possible. Some examples of memory safe languages are Python, Java, C#, Go, Delphi/Object Pascal, Swift, Ruby, Rust, and Ada.
From https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
Yes. Very notably: https://ziglang.org/code-of-conduct/
> Though it's being argued that you could still be responsible for it without looking at it?
If you have a much test coverage as SQLite, I'd be tempted to trust it, and I think that's where we are headed. Someone still needs to define these guardrails though, so IMO the developers job is just mutating into something else, but is still necessary. Long term, who knows.
Works for ToS and software and media licenses. Allegedly.
SourceHut bans LLM generated code from their platform https://news.ycombinator.com/item?id=49461724
The Asahi Linux project bans LLMs. Unfortunate as LLM reverse engineering and driver writing would bring Linux to more Mac models much faster.
The Zig project rejects LLM based contributions.
Some of these policies were introduced when LLMs were really bad at writing code and haven’t been revisited. Some groups don’t care about the quality and object on moral or copyright grounds.
Precisely why Debian Project's decision is both baffling and infuriating.
I hope Debian forks over this. They have severely lost their way.
There's also nothing wrong with an AI-written install script (if it's correct) because those are likely too trivial to copyright anyway.
What are your specific worries? Mine is brain rot.
The "moral" argument I haven't even heard. It's just people pouring out invective, likely imo because Ruby-monkey is not going to be a $150K job anymore. I have problems with these companies, but companies who are problematic can be targeted specifically, and somehow everybody started using Facebook's frontend framework and Microsoft's IDE, all on MacBooks, and this is what they're throwing a shitfit about. To me it's narcissism, not a coherent moral objection.
If you hate these companies (as you should), there are open models. But most didn't object to anything that didn't threaten their income.
i don’t think you understand just how niche you already are
Any serious entity which has experts handling code will do so, yes.
My employer, for example, has various teams of actual developers and others with a significant number of “not really” devs who found their way into DevOps roles. The teams with seasoned developers hold the author responsible as to the integrity and quality of code, regardless of tools used. They won’t hesitate to call someone out directly for low-quality submissions in Teams channels. The teams that have a lot of “not really” devs will blame the model for issues that surface. Of course, they’re also pushing to not have to write any code directly by FY2028, but instead have models do it as part of an internal AI initiative. Somehow the idea of using AI to generate reports, process reports, write code, test and deploy got signed off.
But most important for me: lots of time the PR just adds even more code, although other options do exist (ie sometimes REMOVING some code). You have to know the codebase well in order to find those objectively better solutions.
But you have to be able to say "No ...", rather than just slapping another subscription on top of an already broken workflow.
Yeah you can use LLMs, but don't let me notice it from the quality of the output.
I've noticed that LLMs seem to be especially bad at things relating to space, position and movement. I guess they have to synthesize that part of human intelligence entirely, it's not in the words.
Because if it's still a time saver, even with the increased review load, then it's a win, correct?
I'm not a coder so I have zero idea. Thoughts?
https://news.ycombinator.com/item?id=49474708
I saw the argument that if OS maintainers "really care" about their projects, they would accept valid contributions regardless origin. Well, turn it around: if you really care so much about contributing, if you really just wanna HeLP, you don't need the credit. The warm fuzzy feeling that your contribution ended up being used should be enough.
I've heard this in a lot of places, don't have a way to verify this in action. Do you have any citation or just gut feel (still valid but less useful for me).
> I'm not a coder so I have zero idea. Thoughts?
I’m not trying to be mean, but this comment is basically “I have no experience with this topic, but it can just be boiled down to this one simple question right?”
"A question is...". To my mind not the most important question, if one plays-out to a logical conclusion the scenario you're proposing.
> [...] if it's still a time saver, even with the increased review load, then it's a win, correct?
No - and that's bordering-on (if not fully) rude disrespect of reviewers time and effort. One way to think of this is in terms of Brandolinis Law[0]. Pushing work back to submitters is going to have to happen. Low-effort "submissions" are first and foremost "low-effort" - that's going to have to be driven home.
Here’s my hot take: maybe code contributions are obsoleted by coding agents. No one will accept outside contributions because it’s faster to do it themselves.
Until we figure out a good way to leverage humans in all of this ("Attention is all you need" applies equally to humans as it does to models) productivity gains for the system will always be limited by Amdahl's law. Gwern has an excellent post on this. [2]
[1] https://en.wikipedia.org/wiki/Amdahl's_law [2] https://gwern.net/guardian-angel
Or, at the very least, the community should be paying for them.
I'm thinking of something like: Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex). If you don't do that, or those 300 characters aren't convincing, or have nothing to do with your change or the longer explanation, then you get a canned response so the maintainers waste minimal time.
Not trying to downplay the time wasted to reject the PR, though.
- Why is this change needed (big picture)
- Why are you doing it this way (small picture)
- What are the trade-offs you made for this approach
- How do you know this is correct, that it works the way you think it does?
- What other changes or approaches does committing to this way block in the future?
etc. If you had actually thought through what you were doing, it was a few min to fill it all out. People were just on auto-pilot really struggled.
Foss wasn't exactly not miserable before 2022. The dysfunction just got amplified so that we cannot fix it anymore by just throwing more human resources at the problem.
This dynamic also plays out in many companies. I see a lot of posts from mid to sr engineers frustrated with plummeting code quality and unsure how to manage the reviews. They are increasingly pulling away from the idea that they should mentor people to do better.
Two considerations on this:
1. In the USA, it is common to switch jobs often (in opposite to, for example, Germany). So, in the US-American system it is not often worth the effort to invest a lot of mentoring ressources into some employee if he will leave soon anyway.
2. I personally observe that I often do try to give less experienced programmers good hints on how to improve, but my kind of thinking about programming is often so different that my advice is often of no use for them. Or I often get the arrogant reaction by less experienced programmers that I care far too much about obscure details. I thus seriously do believe that the only way to help junior programmers to become better is to completely crush their ego and arrogance (just like a doctoral study programme in, say, mathematics does to the doctoral students), which is of course not allowed at work. :-(
I’ll admit I’ve seen a spike in negative performance reviews but this is the new normal people will adapt.
I use claude-code, but the AI ecosystem and some of the autonomous tooling coming out of it -- which some people "helpfully" use irresponsibly and point at OSS projects they aren't personally invested in -- enables a LARGE amount of abusive behavior towards open source projects. This is even before we get into how many infrastructural resources crawlers eat up.
Me, and most other OSS contributors, signed up to be a mentor, to create software, to work together ... not to be the equivalent of a reddit moderator banning AI agents left and right.
Always happy to train up new packagers and maintainers.
[0] https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_M...
[1] https://wiki.debian.org/DebianDeveloper/JoinTheProject/NewMe...
Proof of authority, essentially.
I have a reddit account thats over 12 years old. I have left the posts/comments open. That means, my "post history" becomes a way to advertise my skills. I can reference comments from a year ago or 6 months ago about a certain topic to show how I handled something. That does have an effect on people.
As opposed to a random 1 day old account. No one takes them seriously, I guess the same is here as well
So if you're using your account to advertise yourself and look for jobs, I'd use it only for that. All off-topic discussion should be on a different account with a different physical device and IP address (reddit checks these things and cross-bans) that have never interacted with your main account.
Models also still can have major task adherence issues, so even a perfectly well scoped, well considered prompt that covers all situations and coverage can, in many scenarios lead to output users may not expect or notice without reading code. Seen it a lot, just lost some blood and tears to a very straight front end implementation task that I ended up applying manually cause both Sol and Fable struggle to copy a few dozen HTML/JS/CSS snippets properly into a slightly obscure codebase, despite the reference being fully featured and even using the same token scheme, etc…
We also see such issues in what labs deliver in their own software products. We are not at the stage where a human shouldn’t sign off on code that they have tested and understood. A hypothetical future, I don’t really care for, we’d notice when labs stop shipping easily apparent bugs, though even then, I’d still feel there is a while in between that and not needing to assess the output anymore.
There is, in my mind, no need for this “narrative shifting”, overtone window (don’t get me started on the idea of applying that to what should be a purely technical discussion), convince the unbelievers nonesense that some spend their time on. If models could provide code that didn’t necessitate review, there’d be no one needing to argue that case. If and when they can, we’ll know it, but not because of those espousing this currently.
You can still write non-performant code even with tests, but you can also test performance!
What I will say is that I feel valid in saying that the developer behind gas town (a shudder runs down my spine even having to think about that) is not working in a test suite anywhere comparable to SQLite, though in fairness, you never claimed that.
Again, you are likely not wrong that with an environment like SQLite, bugs may be hard to sneak in, but then again, isn't retaining that so important that it is a strong argument for developers auditing LLM output even more strictly, lest we loose the resilience we currently have?
Also I suspect you overprompt, with GPT-5.6 (sol, terra and luna), a lot's of what's used to be mandatory in the AGENT.md is redondant at best and frequantly actively harmful.
I do not have an AGENTS.md in any of my repos at all, stopped using them around 5.2. I was a bit ahead of the curve with that, my evals very early showcased how limiting those tend to be, same why I never used MCP, were useless context bloat.
Will maybe make an edit explaining a bit further what the task was once I get to my computer.
For example could you reproduce the code you read immediately after writing it?
It’s very easy to “read code” if you’re just reading for surface level understanding.
... for people who are native speakers of English.
If you can't write, you can't think
It’s I think a normal evolution of a social norm. There will be a period of competing values.
The solution, of course, is to use the best available LLMs as the first line of defense against slop contributions. But if the project maintainers have issued a sweeping fatwa prohibiting an entire class of useful tools, that option along with many others is off the table.
As for motive, it probably varies, though some will loudly put that they're some agent manager or something with lots of contributions, so you can guess their motivations there.
In other cases, these are instrad brand-new accounts which is a related but I guess slightly different story... not gonna say these are spam bot accounts being juiced with fake activity but well...
So this "thing" is mainly a Firefox fork and most UI is basic HTML/CSS/JS (as is the case in upstream). Development is patch baked, CSS tokens must follow a defined and CI enforced standard, etc. LLMs can be very helpful in development, I got a small CLI tool for patch, token management and basic quality gates, which I started working on a few months ago to keep the most atrocious LLM output at bay. Has lead to the revieability of output improving meaningfully over markdown monstrosities, though OpenAI models still manage to sneak hard to parse output past it. This CLI tool along with some task specific scripts also ensures reuse of proven upstream infra like Places (Good lord dear Firefox developers, is Places nice to rely on), consistent regression testing (especially in memory constraint scenarios), etc. Basically, I can and do regularly make additions with LLM assistance, I review it, I discard and restart or improve upon it (rarely accept scoped changes wholesale. This to say, I got some experience in the use of models for coding assistance and I (thanks to the amazing docs and a lot of considerations for the architecture I want) do know what I want, how I want it and how to get there. Also got private LLM evals that often uncover which labs tend to perform suspiciously well in public benchmarks vs private ones and what models still struggle with along with why, so yeah, certainly can always improve but I got, I'd argue, enough of an idea to where my critique of LLM coding limitations has legs.
Which brings us to what I was trying to implement and how I went about it: Settings works. Fully featured (including a few cross-site-tracking specific clarifications that came from a HN interaction a few days ago), tab specific previews for what changes affect regarding themeing, well tested (manual and static), integrated to leverage what FF provides where possible.
It does (or rather did) look functional/God awful though. To the point where I was uncertain that certain previews could be easily parsed by new users. I thus opened Adobe XD, did some early mockup work, tried a few core concepts, settled upon two, then (using Claude Fable 5 low) created a plain export of the existing settings code from our furnace components and patch baked edits into regular HTML/JS/CSS files. I manually verified, this export worked, the tokens were in the correct format, the code reflected what Hominis applied (including what was required for stand-alone of course) and externally called features upon interaction did provide log output linking to the pre-existing functions that meant reimplementation based upon this should be easy.
I then took that to Claude Design using Fable 5 on High. I provided the code along with linked branding files (which due to the way branding patches are handled were simpler to provide separately) and my Adobe XD mockups. A few dozen iterations later, along with some exports and re-imports due to manual changes (some animations in tabbing/"focus mode" showcases needed to be "just so" and prompting would have been inefficient to get there), I had a new user experience I was far happier with. Simpler, yet better at communicating, far more visually appealing and resolving some concerns I had, I felt pleased and will admit, Fable 5 via Claude Design provided valuable output and did, what it does best, make iterating on multiple UI concepts next to each other to settle on a final option from many, far quicker.
I then exported and took that to GPT-5.6 Luna (I have € 23,- Codex only so am a bit stingy on when to use what). But so what? I had verified, the tokens were the same. The naming of elements remained consistent to what Hominis Settings used, the backend changes were practically none-existent. I had audited the output end-to-end, made some refactors and house style specific improvements to keep everything more auditable, everything seemed suited for a quick port. What could possibly go wrong?
Anyone whith pattern recognition will likely guess what. Basic 1:1 applying? No dice. The first attempt failed as, once the context window had compacted twice, the model started leaving the very clearly paved path laid out. Stylised favicon in the showcase? Gone. Hamburger menu in the showcase, compressed. Vertical tabbing change interlinked with the canvas section? Very funny. The model started no longer following the code, it started taking screenshots and applying what it could see from that, despite the original prompt (just checked) vey clearly stating a simple code port, section per section, with any deviations to be listed in a designated file I maintain for long running tasks.
Basically, Luna did implement changes to the settings that felt tangentially right and a casual observe may not notice all the regressions and deviations, but I did. So I stopped it.
Sol and Fable didn't fare much better. Sol did stay on target longer, but it went off the rails around the privacy tab, introducing functional regressions to the way I had implemented cross-site cookie blocking, which were never requested, nor should that code even have been looked at. I reset the repo and handed it over to Fable 5 (medium). I had a third of my weekly usage left on 20x Max, reset the day after at 3AM so no harm either way.
Should be plenty. Wasn't plenty. Since a while (I think Opus 4.7, but could be wrong), Anthropic models do decently well regarding long term, high token tasks. Up to 450k, I have been able to reliably reproduce consistent implementation. The model, using a few subagents (which should have reduced the risk of context window issues further), went to work and after a few hours (and about 20% of usage less), the model proudly presented its work. I was at work and by the time I came back, I was a bit miffed to find that the model had, in its wisdom, decided to not used the well established and consistently used mar to bind in branding icons. No biggie, easy fix, albeit a bit stupid. ESPECIALLY SINCE I SAW IN THE CLAUDE CODE TRACES THAT THE MODEL HAD SURPRESSED A WARNING ON THAT VERY FRONT. Whatever. Then I saw it had not wired in the existing browser data deletion and export logic. It hadn’t modified existing logic unlike Sol, so hey, that’s nice. But it had not wired up the existing settings when they did not have any immediate feedback in the implementation reference.
Ox Alpha, it just spanned in circles, didn’t seem to like our fireforge CLI and furnace componets, but it was worth a free try. Opus 5, the model most obsessive in checking its own work, took screenshots. A lot of sscreenshots including every few hundred ms to cover animations. Nice. BUT IT CREATED ITS OWN TOKENS INSTAD OF REUSING WHAT WAS PROVIDED. Thus, styling deviated heavily.
At this point you might ask why I don’t do it manually and I will in the end anyways, but I was surprised to find such a clear case of a seemingly straightforward task flummoxing multiple LLMs. This is aided by my unique code base (the upstream FF code is also gitignored which likely flummoxes some models trained heavily to leverage git to track changes), everything needs to be patch backed and follow a specific implementation style, etc. But I had more important things to do and I wanted to see whether I couldn’t get it to work yet.
Inspired by Opus 5, I wrote a new prompt, specifically laying out a visual comparison and code diff workflow. Only these changes, only in this manner, only move on ones you have gotten visual confirmation, specific cross checks. I included a hand written markdown outlining which change affects other settings sections (even though that is obvious reading the reference code), how to approach tokens, etc. Obsessively descriptive and (I feel) unnecessarily so, but why not. Best case, it works, worst case, I’ll spend an hour doing it manually. I had other things to do not behind a keyboard, so why not one last Hail Mary.
Fable 5, ever efficient when using visuals, used the last rest of my usage, though I did see some roundabout approaches after the fact that make me doubtful it’d have cracked this. Opus 5 went off the deep end taking ui-captures across the entire code base, which lead to a very liberal application of settings tokens outside settings.
Sol did take a night and got 40% there when I asked for a pause once the in flight slice had landed. It did port the UI/UX changes in a way that on the surface looked and felt correct. It did not touch the backend in unacceptable ways. And it did cross checks. Animations also behaved correctly, though it did apply a rule on backend usage a bit to strictly, incorporating that into a preview for search by turning that into an actual web search, not a UX demo. Dumb, but not fatal.
Great success, what am I complaining?
Well, the code. It had done what Sol likes to do and turned very cleanly written, readable code into a hard to parse mess. This included touching existing test files.
And at that point I said “fuck it, I’ll do it myself”. And I did. In less than an hour, listening to Paris Palamo, Lyre Le Temps, Sting, Sade, SynthV and some Nirvana.
If I didn’t look at the code and I didn’t have strict standards for the UI, but just considered what looks in line on the surface level/feels right/“vibes” and what “works”, many of these attempts would have been accepted, as their issues are rarely apparent on the surface. That’s part of the issue in my book and why I’m firm we are far from “don’t read code”/“don’t test”/“skip qa”…
Are they using their Matrix server to filter out drive-by/low-effort contributions?
Ask any questions on matrix.
You can get to work each day regardless if you walk or drive.
arguing that it’s possible to make them by hand isn’t just missing the point; it’s missing the entire discussion
>> Before they were not able to spam large PRs
I was replying to someone insinuating that there was something I might have missed.
Interjecting about the topical article, is a derail of this thread for some reason that is personal to you. Good luck with whatever.
The problem is writing such an essay takes magnitudes more of an effort for people who are not native English (or whatever the language is in which discussions are done about the project) speakers.
Also, relatedly, essays written by non-native English speakers often get considered to be AI-written by common AI detection systems, even though no AI was involved when writing them; see for example
> I'm Kenyan. I Don't Write Like ChatGPT. ChatGPT Writes Like Me.
> https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li...
I would have zero tolerance if anyone that did anything less in my orgs. Owning and understanding the code you submit is the one job that matters most now.
sure, students and juniors shoot themselves in the dick if they let LLMs do everything, but they're fucked anyway so it doesn't matter,
the current pace of LLM advancement only has to keep for five more years for handmade code to be considered a liability. I wouldn't worry about being able to recall obscure APIs or whiteboard leetcode. I'm far more worried about having to change careers at 40.
Writing, definitely. Reading, maybe. Thinking is another thing. I can think about code in a lot of ways just by reading a description of the code, or knowing how I directed the code to be written, etc. I think people are thinking about the code differently.
Why don’t we just care about results? Code quality, performance, clarity are all measurable. Why bother with philosophical positions on these?
Number and order of arguments, long names, etc. are just bureaucracy. Knowing them doesn't mean you understand the codebase any better than if you rely on the IDE for it.
It's a bit like remembering the exact date an historical event happened vs. knowing at which point in history it did, what other events relate to it, etc. Neither makes you better or worse at knowing and understanding the history of the event.
We need to continue the tradition of elevating humans through mentoring or we won’t have a future scaffolding for work to be done.
They could be committing plan files alongside any nontrivial change to application code, and the plan file can have everything you'd care about, like the invariants it held to and why, the rejected ideas and why, the acceptable risks and why, etc.
This is solved by better usage of LLMs, not less.
The divide to me isn't engineering skill vs those who lost it, it's people who care vs. those who don't care. It's a higher level thing now that we're working at a higher level (delegation).
We survived. Some upsides, some downsides, life continues.
They made choices that made them dumber is what I'm saying.
I think a possible solution on both fronts (maintaining software quality, preventing skill atrophy) may be implementation of strict token budgets. Make the individual programmer choose how they are going to spend their limited tokens for the day/week. Provide just enough to use it as a plan/development/review tool, but nowhere near enough to just go full send AI vibe coding software factory slop mode all day long.
Programmers just moved up a level , not dumber, we are now managers of a team of 'agent' programmers. The deliverable is now a functionality instead of a specific block of code
Yet programmers will still know commands. Abstractions can make things easier but it doesn't require losing skills.
And compilers made every software engineer worse at writing Assembly and better at skills higher up the stack. This will be no different.
Make that some/a lot, but not all.
There is a clear bifurcation. A lot of those that never cared really don't care now, but then you get others that can use it to crank that much harder than ever before.
If you put the same brain effort in but leverage LLMs you really can be dramatically more productive.
Just like when Boeing decided that their QA process should be abridged to save wasted time and money!
And that worked perfectly.
(edit: rereading I think maybe you don't support not reviewing all of LLM code you submit, but the above was written with another impression)
If I need to understand a specific line of code it means I did something wrong in planning or in requirements for testing.
But will Claude give you an authentic rationale and a traceable, verifiable "line of reasoning" for those things? Or will it just construct the next plausible Markov chain built on whatever Reddit thread it ingested at random?
You can ask Claude or any LLM for citations, and it will RAG them out ex post facto. Those actually aren't citations, they're just web searches for related articles, and they don't necessarily support the assertions that you're asking to cite.
I am sure that Claude and the others can produce intermediate logs of their inference and "reasoning" process while they are processing stuff, but can they really go back within the context window and construct an authentic apologia for a specific thing when you ask for it?
Specifically, humans are known to decide subconsciously, then invent some "reasoning" out of thin air to justify it.
This matches my experience with decision-making in software projects.
No, it will invent retroactively a plausible sounding reason why someone might have done it that way. These are very different things.
Dementia patients also do this.
An example: 'read input from CLI, do this specific transform on it, send log with this text to external service, then output transformed data to CLI' is a program. Going up the abstraction levels from assembly to Ruby, you always know the "What" of the program, while you understand less of the "How" at each step. This is not the case with LLMs used in the common way. The problem with LLMs is that you no longer have a grasp of the "What", because you are not reading the code; you may have memorized the ambiguous English "What" that I wrote above, but that is not sufficient to understand the true behavior because English is not sufficient to represent it; it must be represented in a programming language. (What is 'read'? What is 'send'? What happens with errors?) By the time you have sufficiently represented the program in English to be nonambiguous, you've written more text than the code would have been, with just as much rigor.
So LLMs represent a fundamental difference to traditional abstractions: the user has lost the understanding of what is actually happening, because they are prompting ambiguously, and thus they cannot possibly have a grasp of the behavior, because the behavior is not defined in their prompt. In other words, they are programming in a new programming language that has a ton of undefined behavior that just randomly happens. No one could understand the What of their program when using such a language, unless they compiled it to a nonambiguous language and then understood that instead.
Of course it is possible to read and understand the code output by the LLM. It is even possible to build a whole knowledge graph in your head, as you traditionally would, and have a pretty full understanding of the whole thing. But, you are always doing this with the outputted code, not with the inputted prompts. The prompts are not analogous to a higher level of abstraction in this way; they are analogous to JIRA tickets. You don't have to read the assembly to understand your program, but you do have to read the LLM outputs.
The other issue is that the above paragraph's process of understanding is discouraged. The time taken to fully understand the outputs approaches the time it would have taken to write them yourself, so is very rarely done, and that increasing rarity of understanding is what we are concerned about. The programmers are moving from an understanding of the program into an understanding of the JIRA tickets that produced the program; they are becoming product managers. The thing is, currently you still need someone who understands the program beyond the level of a product manager in order to retain maintainability and quality. Maybe in the future you won't, but right now you do.
Your first prompt could be instructions to guide creation of a spec, which leads to a test suite you personally validate, which leads to code to pass those tests in a deterministic way. Then it is your job to review and QA it until it is quality enough to submit to a peer for code review.
There are many many ways to use these tools and carefully monitor and quality control what they write like a good engineering lead might, even if they do not type much code themselves at work. The job of the most senior engineers often ends up being heavily biased towards reviewing code all day and maintaining quality control. This is already how things were before AI.
Torvalds reviews a -lot- of code and writes very little now.
With compilers, you still had to think in depth about the code, write it, develop and maintain muscle memory, understand what you were doing.
Many are not doing any of that, and coding is a skill you need to constantly practice.
I do.
Most people sucked at programming before AI and they still suck after it. Who cares what "many" do. We as individuals can demand higher bars from ourselves and our teams. AI can increase that bar or lower it depending on how it is used.
I'm a person who is over-reliant on LLMs, doesn't know how most of the things in the codebase work, and is atrophying both in programming and in general cognition.
I used to care, a lot. And I still do.
Are you prioritizing other things? Do you think losing your cognition and programming skills won't have a negative effect on your project?
Those seem bad but maybe they fit into a bigger picture for you?
When I recently found a small bug in how NTP is implemented in Home Assistant OS that was affecting my use of it, I thought about just reporting that bug.
But I set the bot forth to work on corrective measures, instead.
The first proposed fixes were overbearing and awful. Maybe they'd have worked but it hurt my soul to look at them. I couldn't accept them -- not for my system at home nor for anyone else's.
Through a laborious process (that many here could have skipped entirely), I eventually got what I feel is a cromulent fix down to a few lines of changes in an init script.
I didn't write it. All I did was direct (and sometimes brow-beat) the bot, rejecting things over and over while optimizing at a high level until it produced an acceptable result.
I now have a fix that is tidy-enough that it can be applied to running systems. It is easy to understand what it does, and why it does it -- even for me. Perhaps I should submit a PR...
> They just don't care. They didn't before either.
...but this kind of blanket mentality really puts a damper on my willingness to do so.
If you care primarily about the quality of the end result, as opposed to being attached to a particular process of achieving it, then you're happy about how things have gone.
I do think LLM's are making some genuine programmers less intelligent, but I think this type of person makes up a decent portion of its users too
And then after I replied, edited your comment to change that context a bit.
So as for ypur original assertion, in this subthread, no... not even remotely the same.
Sorry to say this, but he doesn't sound like a nice guy.
Also, the staff engineers who review code all day typically do not really understand the program either. They understand the spec and they have a model of how things should work such that they can answer "should" questions, but they cannot tell you what exactly is going on in the depths of the program; that's not their job. The tools are not capable right now of creating a quality program that the operator only understands at a conceptual level. Again, someone has to actually know, still.
Regardless, I run a security auditing company where we constantly find severe bugs in human written code proving the engineers writing it had major gaps in their understanding of their own code. And, others have found flaws like that in my own hand written code! We humans are often very blind at seeing the flaws in our own logic and AIs learned from us.
Also, as code reviewers that can spot bugs authors and AIs miss, we are often paid a lot more than the original authors for our time. Also it almost never takes as much time as writing the code in the first place which likely required many round trips with customers to establish needs and fix bugs etc.
Your claims imply that only someone that hand types every semicolon is capable of understanding the code does not hold up even in the pre AI world.
Code review was the most important job in software engineering before AI and that is still true now.
And I've seen exactly this across multiple large and small organizations in multiple countries, in addition to being all over here and the red site.
This is quite distinct from enjoyment.
> And I've seen exactly this across multiple large and small organizations in multiple countries, in addition to being all over here and the red site.
I know that experience, but I do have a different opinion on this:
Many such people studied computer science (a similar point holds for mathematics, physics and some engineering disciplines) because they love coding.
Unluckily, the job that they got does involve barely any clever coding, but rather
- tolerating and gluing together shitty code pieces that someone else wrote
- tolerating red tape
So, such people simply do in their free time what they love. And to come back to my point "similar point holds for mathematics, physics and some engineering disciplines": these people try to use their little free time to prove some novel theorems or put their shed full of machines like 3D printers, CNC mills, CNC lathes, laser cutters, self-built pick-and-place machines, ... to work on their own beloved engineering projects.
We must be living on different planets, because from everything I can see, software quality is at a historic low.
"But we passed SOC2 and that is all our customers care about" they say, right up until they are in the headlines for a data breach directly resulting from them putting all customer data in plain text internet facing databases the whole team can access from their workstations. What did they think was going to happen? Survivors bias is a hell of a drug.
It's a whole other level of junk. 100x worse than now. So multiple what you just said, x100.
Seriously, this was a huge thing in C and C++, where you had to know/remember/know to look up very specific error codes and conditions in an API and if you didn't then it was very much considered to be a skill issue. This was maybe 15 years ago.
It was not unless you were part of some very weird circle. There was always manuals and other references that listed everything about a platform or library. Then we got ‘man’ and ‘info’. And I remember being able to download the full docs of windows’ various documentation.
That’s like saying as a writer you were looked down at because you had to look at a dictionary every once in a while.
And they were correct. You're entirely right that this time it isn't different, but in the sense that the quality of both developers and code has been going downhill for decades. The only thing that has kept this industry alive is that hardware got more performant faster than developers became more inept.
The non-strawman version of Socrates warning, that writing-based cultures would lose memory, take recorded fact at face value and mistake knowledge for wisdom was true as well. Your post is an example of this, you read something about Socrates, you didn't investigate and were fine with the appearance of knowledge, and because books can't defend themselves you mistook that for understanding.
That's what he was concerned about, hordes of people with a vague assemblage of facts but no genuine capacity to critically think.
is there a lot of evidence for this? You can broadly put technology into two camps. Technologically that, as it becomes more powerful, demands more attention and skill from the user and just the opposite. A bow is more powerful than a stick but also more demanding to use. A car is more powerful than your feet but your population ends up obese. Almost every single piece of software, with the exception of maybe debuggers, who an astonishingly amount of seasoned developers do not utilize (I suspect for that reason), is a car and not a bow.
There's a study on English college students roughly ten years ago who were tasked to read the first few paragraphs of Dicken's Bleak House. They were even allowed to use a dictionary and the internet. A majority could not interpret the text. That's where we were at before LLMs. My rural working-class grandfather at an underfunded Catholic school had to translate Ovid from Latin into German in 8th grade. It wasn't even a personal attack, we're just this fried now.
The fact that some course of action was previously mentioned in a reasoning trace, or any other context, makes it more likely to be performed. It has nothing to do with the reason that it was mentioned in the reasoning trace.
And it's not "no relation", it was brought up as an attempt to fix/subset the original claim.