A good thing about the "you're the author regardless of the tool you used to produce the code" policy is that if a developer repeatedly submits poor quality AI generated code, one does not blame the model or the agent, one bans/terminates the developer.
The issue that open source projects are facing at the moment is that it takes significantly less effort to submit a patch for review.
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.
I'm an OSS maintainer and to me it's not just about the review itself. Being greeted by a wall of text for every little small thing is counter-productive. I hate going through 2 pages of text for each PR. It usually shouldn't take more than a couple of sentences if you understand the issue and the solution.
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.
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]
Nope, most of the PRs are authored entirely by agents with people instructing them to “pr famous projects in my name to increase my GitHub profile value or “hire ability”. The original authors have no idea what their agents are writing, these are mostly badly quality models (people doing this are not only cutting corners, but also using the less amount of money/tokens to do so). If the agent creates 200, 400 or whatever PRs and get 5 in the agent is still “winning” for the person instructing it. The maintainers though have to filter these out on the other side. A common case is a fix to something that was already fixed simply because the agent worked on old code assumptions.
Just had a thought, what if you made new contributors write a human-authored essay on why they’re submitting a patch, and then check it against Pangram? Pangram is really accurate from what I’ve found…
> Nope, most of the PRs are authored entirely by agents with people instructing them to “pr famous projects in my name to increase my GitHub profile value or “hire ability”.
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).
It's a well-known trope, that it's harder to read code than to write it, and review is more complicated than to read it, so I do not understand what you want to imply?
"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.
Well historically the consensus was that it was harder to read code than to write it, but that leads to uncomfortable conclusions these days, so that bit of common wisdom has mostly been ejected.
> 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?”
Probably a time waster because of the intermediate patch contributor. It’s like a game of telephone at worst, at best the reviewer could just use their own LLM and get the same result.
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.
To me, that touches on the central issue. I think most people support the “I don’t care about the tool, only the outcome “
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.
I'm not convinced it blows up. It might also end up placing a larger burden on contributors, and especially first-time contributors, to provide concise, high-quality documentation that justifies their contribution.
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.
That doesn't really solve the problem. I've gotten PRs that do do an adequate job of explaining why why something should be implemented. Then I look at the code and it doesn't fully solve the problem, or it does so in a way that will obviously break something else.
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) would simply become a prompt.
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.
Nah, that was already blown up way before LLMs existed.
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.
I tried to nod a bit to the inconsistency. Some projects clearly lost patience with imperfect contributions long ago. But many were still pretty supportive.
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.
The correct response to irresponsible AI use in the workplace is maintaining standards and rejecting poor quality. Performance improvement plans as a fair warning followed by firing people works for incompetence or laziness, AI doesn’t change anything.
I’ll admit I’ve seen a spike in negative performance reviews but this is the new normal people will adapt.
yeah, that's fair. Problem so far has been when poor developers send massive volume of slop for review. Takes time and effort to review or at least glance and test it, especially if developer hasn't bothered.
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.
We need sufficiently severe penalties for vibe coding. First time out we break your legs, but if you come back with another vibed patch its around the back of the barn for you.
Nothing. And that's the problem -- the issue isn't "should a contributor be able to use AI" it's quickly becoming "is this entire contributor an AI agent". Every actual-human who gets a bad first experience hurts the project. The contributors having to be suspicious of new people hurts the project. The whole thing just sucks, and I don't know how to fix it.
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.
This is the second time I've seen this project mentioned on HN. Their white paper is very interesting and aligns closely with my interests but I don't see much on the main site about how to get involved.
Are they using their Matrix server to filter out drive-by/low-effort contributions?
I am the founder of the project. We accept every contribution that solves a problem, even drive-bys. Though they may often sit for a bit as we often merge in batches. If there is something missing, make a PR by all means.
I can't speak for all, but many mature open source communities have explicit or ad-hoc reputation schemes that are used to triage contributions. A fresh account means starting over with zero reputation, which in turn means your contributions wait at the back of the line.
Well. This is Debian, known for how strict they are about vetting developers. I just remembered Sladen refusing to key sign because my passport circa 2005 didn't have a machine readable slug in it.
How would you generate enough large PRs to count as "spam"? You could add gibberish or delete random lines of code but it was obviously not plausible looking.
this article is about the flood of junior developers who are producing enormous prs they’ve never seen full of untrustworthy code that a human hasn’t evaluated
arguing that it’s possible to make them by hand isn’t just missing the point; it’s missing the entire discussion
In anonymous systems, where we don't use real names, your "handle" has an "age".
That becomes your most prized possession.
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
Be extremely careful with that account then, because they ban accounts for the most minor things now. Stuff like posting evidence disproving something the moderator agrees with. And they ban your account from the whole site, not just from that subreddit any more. Automated algorithms also ban accounts for reasons that don't make any sense.
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.
No one takes a 12 year old Reddit account seriously either. It's not a platform you can take anyone seriously. The biggest trolls have 12 year old accounts.
the age is not the measure of quality. the GP said they left the posts/comments open. anybody can read that and check if they are or not a serious contributor
Exactly the sort of thing I agree with. If there's code, ultimately, some human is responsible for it, regardless of whether they produced it by hand, by AI, or by rolling dice. (Not that anyone does produce code by rolling dice, mind! Or, if they do, I really don't want to see the results...)
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.
Well, one example is that patterns in code now can make you recall bugs you've seen in the past. I had this realization where I used an LLM to do a big refactor, and it fixed a bug along the way that I should have realized was much more urgent than the refactor, having seen an identical bug in the past (it was related to prefix-checking in a set that wasn't constructed to do that kind of prefix-checking). Had I done the refactor by hand I'd likely have realized it much quicker.
Are there examples of anyone discussing this and reaching other conclusions?
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 could imagine (in a commercial organization) a case for something like: "we're obviously going to be relying more and more on AI, so if bad code comes out of it, instead of just shaming the engineer, let's study together what happened -- what was the chat context, the model, the system prompt, etc... ? What seemed to cause the issue? What processes or systems could we put in place to improve it? Etc... -- and then use the learnings to improve AI use throughout the whole org."
On the opposite side or the noteable spectrum, look up "Steve Yegge wants you to stop looking at your code." He said it in a video interview, though plenty of summaries online of exact wording and ideas. Though it's being argued that you could still be responsible for it without looking at it?
Extremes on both sides. I'd wager were moving in Yegge's direction though, like it or not.
> 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.
For me, it’s not a question of whether I like it, nor where we might move in the future, but purely what is proven currently. In my experience, as in my evals, any model, including notably Fable 5 and GPT-5.6 Sol can and indeed do produce code that does not consider many edge cases, can be hard to maintain (especially Sol though it’s output has become markedly better with recent changes to Codex) and sometimes introduce bugs with visibly apparent issues. Existing test coverage doesn’t necessarily prevent such issues when changes or additions are made. The idea that models tend to gravitate towards the house style without major CI based restrictions also has not born fruit in my book. More, I have found even the frontier models amazing at utterly deviating from established standards and tests, what lint, tc and co don’t catch the model will take to introduce code that feels and reads like it does not fits with the rest.
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.
It's not about the prompt, it's about the guardrails. Static types, compiled, massive test suite, etc. That what I mean by extreme level of test coverage like SQLite. You'd actually need to be an expert in C and SQLite and the SQLite test suite just to sneak a bug into it. Testing and other verifications are going to be an exciting area for the foreseeable future.
You can still write non-performant code even with tests, but you can also test performance!
Am about as far away from a C expert as one can be (and probably want to keep it that way for the time being), so happy to take your word on that front. Still feel, it'd be easy and in their interest for one of the major labs to provide a verifiable showcase/research paper on that front. Zig-to-Rust in Bun is the closest and that is very impressive, but I feel it doesn't necessarily map to new features/changes beyond porting. The compiler, browser, etc. all equally do not fill me with that much confidence, but perhaps in SQLite modifications could be hard for a model to mess up.
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?
Sol and Fable are not doers, they are thinkers. Using them to "copy a few dozen HTML/JS/CSS snippets properly into a slightly obscure codebase, despite the reference being fully featured" is one of the most ineffective possible usage of those model. What you described is a job for luna.
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 also tried Luna (is my first line for such task in general because of the speed and efficiency, but not because Fable or Sol can’t be “doers”, in my evals both are superior in well scoped task adherence and implementation vs Luna and the like, have yet to find a task Luna can that Sol or Fable can’t) along with Opus 5 (cause the Max sub gives a lot of that I can freely use after Fable runs out for the week so I wasted three runs on that) and Ox Alpha/GLM-5.3 Flash (as that was free at the time). Sol (on High) and Fable (on Medium) were acts of 12h desperation, before I did it manually, after the three other models failed, first with a very simple prompt, failure, revert commits, then a very specific implementation plan with clearly scoped verification, failure, thus manual in 45 minutes. It was a major port of a new settings UX for a Firefox fork, all test baked, all with 1:1 replacement targets in the reference and the original. It was merely massive context wise and only 5.4 has ever behaved well across compactions in a manner that I could validate in evals. No model before or since gave me confidence in this regard and I’ll retroactively test with 5.4, somehow forgot to try that one.
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.
I have a settings panel implemented in HTML/CSS/JS for a Firefox fork that "could/should have been a desktop environment". Bit of an odd project really, mainly out of a very specific conviction concerning modern applications, the way LLMs and task specific models are currently not leveraged well by any browser, my own tendency to have 400+ tabs open at a time across multiple projects, my opinion that it is the perfect place to finally apply a lot of UX opinions I have held for a while and push in a very distinct direction along with core critiques I have concerning PKM applications I haven't seen addressed despite trying every PKM application under the sun. Neither here, nor there.
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.
That might be an interesting parallel. Maybe code becomes like legal documents. Binding but inscrutable, full of small mistakes and not really tailored for human ingestion.
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.
Note that Debian is mostly an aggregation of packages. There's nothing wrong with Debian importing a package that was written by AI, if it's something that people want to install. The questionable copyright of that package does not taint Debian as a whole. Debian allows public domain packages, so it wouldn't even be a DFSG violation.
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.
Debian gives attribution to every single open source project in existence that is capable of running on Linux, and is Free Software. It is exactly the project that shouldn't worry about copyright.
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 was referring specifically to the idea that you have to stand by the code that you write.
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.
As others have said there are other conclusions going both ways (though I do think most settle on as you said), though one very fair conclusion I came across is that it's not allowed because the whole issue of copyright is still somewhat unresolved, and though its fine right now, that could (probably wont, but could) massively backfire later.
"This works for me, but I need help understanding why, because maybe it would help others" is a legitimate position to be in--has been since long before LLMs. I think we miss out on something when we ignore that position.
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 key thing you are missing here is that most successful open source maintainers don’t lack expertise, they lack time. They are generally capable of improving their projects in any direction they want without help. Mentoring new contributors is basically always a loss in the short term as far as the maintainer is concerned. The project does get improved, but it generally takes longer than if they did it by themselves from scratch, and the improvements might be in an area they don’t much care about. The payoff for the maintainers only ever happened in the long term if the mentorship succeeded and they get a viable independent long term contributor.
The change with this justification absolutely exists and has existed for a long time, but this justification only works for small changes (in the past and still today). Don’t come to me with a huge refactor or new feature and this explanation, which is happening more and more recently (it’s an easy strawman to make and hard to prove, but I certainly see it in practice).
Linus Torvalds regarding the Linux kernel is reasonably similar. He views AI/LLMs as just another tool in the development process. Think about life before and after modern IDEs that features IntelliSense circa 2000. It was night and day. It did not make programmers dumber -- it was a new tool.
Except LLMs actually are making programmers dumber. I personally know people, people whom I know for a fact were good programmers before, who have now completely stopped using their brains. When you ask them why they did something in the code, they say "I don't know, Claude did that and I didn't really question it". There was no such analogous phenomenon with IDEs.
I have had the same experience and feel pressured to adopt it. I had one former colleague say “you really have to stop looking at code” almost incredulous that I was uncertain about whether we should let models write really bad code and architecture that never would have been allowed in the before times. I will say when I let the agents go autonomous I often find I spend more time refactoring than if I had moved slower and forced them to write good code and follow project architecture patterns.
I use agents to build exactly what I want like I am pair programming with a jr engineer, and review every line of final output before I make a PR.
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.
We see it every day in the news with hacks that were, in every single case, completely preventable. That is had any competent security engineers been involved, with leadership willing to fund the cycles to do it right.
"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 doesn't apply to everyone, but yes I know people who are over-reliant on LLMs and definitely getting dumber. With devs and non-devs too. I hate seeing this happen.
IDEs enable us to not bother memorizing the number and order of arguments, long names beyond the first word or two, etc. the impact is comparable, freeing some of the very limited space in our memory for more important things.
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,
code didn't matter even before LLMs. we only ever cared about the product of it.
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.
I've seen the result of "code doesn't matter" and it's difficult to change and maintain. I guess if your business is ok with frequent P1 incidents or ships a complete product and never touches it again, but I've never been part of one. I've also never been in a position that cared about leetcode or remembering APIs, so it's possible my experience is completely different from yours.
> With AI people aren't reading, writing, or thinking about the code.
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.
That's because you are used to it. I am old enough to have been there during the rise of things like intellisense and language servers, people were making the exact same arguments about them. That not knowing your API to the core makes you a bad programmer. I'm sure for IDEs themselves there were similar arguments and it goes all the way back to Socrates' warning against writing. These arguments always end with "but this time it's different". And inevitably each time it's not.
> That not knowing your API to the core makes you a bad programmer.
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.
> 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.
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.
I'm not sure what you're saying, or how it is not what I'm saying? You're giving examples of places to read documentation, and I'm saying that the expectation was that behaviors caused by not checking documentation would be your fault. If that isn't your experience, cool, it was definitely mine when posting on forums online 15-16 years ago.
Why wouldn’t it be? If you were in charge of writing a letter and use words that hinders the purpose of the letter, thus resulting in a flawed communication, wouldn’t it be your fault? Especially when dictionaries are easily available?
I’m genuinely curious why it matters to make abstract moral judgments about the differences between remembering function names and deep understanding of the syntax used in a function.
Why don’t we just care about results? Code quality, performance, clarity are all measurable. Why bother with philosophical positions on these?
How do you trust the results of a black box that are hard to verify? Most of us use proxies that are easier to check, like historical competence and maturity. For example, it's difficult to verify my compiler produces a binary that correctly implements the code I wrote. I can partially validate the result with testing, but when I send it out into the world to handle unknown inputs I'm trusting that the compiler has done its job correctly. I can have that trust because I know the compiler people (in aggregate) have thought very hard about correctness, and the project is mature enough that bugs are rare. If the GCC developers tomorrow were to start merging anything that passed the test suite and some other list of objective metrics, my trust would rightly decrease.
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.
I spend a ton of time mentoring Jrs in FOSS communities, but I confess as a startup founder myself I could simply not justify hiring anyone but self-directed seniors until we are profitable enough to set some money on fire for what would effectively be just a long term investment in creating a few new Srs. But Jr hiring will never again be what it was unless it gets subsidized somehow as partial charity.
It is insiduous how easy it is to stop thinking. When writing complex code it seems like most of the time it would have been faster just to write it myself and build a complete understanding of it. I swear if I asked most engineers at my company to describe their changes recently they would be unable to.
That's a cultural thing. Push back on it and don't make it acceptable behavior. I would argue most people generally are terrible at code review and do this same behavior with their peers as well, but at least their peers are capable of owning some level of responsibility, whereas the LLM is not.
That's what delegation looks like, but it needs a better process.
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).
I think LLMs make programmers lazy more than anything. And when programmers stop programming for extended periods, they lose their programming skills. No surprise here. Use it or lose it.
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.
You can just ask Claude why it did something in the code and it will tell you
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
I'm not sure how context is managed between reasoning traces and actual output in Claude / claude code, but if the reasoning trace is in the context of the question for "why did you do that", it can actually answer why it did that.
It's exactly as close as asking for it after the fact. Reasoning traces have no relation to the reasons LLMs actually do things, except that they may do things because the reasoning trace says they should.
In my experience it’s impossible to foresee all the micro decisions that reality will demand. IMO it’s one reason to not use waterfall, which is very similar to what you described
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?
You certainly can ask it to produce a verifiable report that tells you how to verify its claims. Yes, you do need to verify the results and confirm you agree with it. I do this sort of thing a lot to discover misunderstandings Claude has about things and iterating on them. There's a difference between reading everything yourself vs having a discussion where one of you (Claude) will happily dig through everything and create detailed memos for review. If you want line numbers as evidence, just ask then verify, etc.
People, sometimes weirdly called by their animal name, humans, do have memories of their thought process. We can reach back to those memories to explain why we made a decision. Sometimes we don’t remember and speculate instead. Most of the time we can tell the difference
An LLM has no special insight into itself and has no reasons. It will come up with something that is convincing, and it will change based on the word choices you used in the request. You can observe this by asking it why it did something that it didn't actually do.
You could also say the same with desktops. Desktops abstracted CLI commands like mv or ls. People who are taught on desktops will get scared when they see a terminal.
Yet programmers will still know commands.
Abstractions can make things easier but it doesn't require losing skills.
Desktops don't abstract CLI commands. Both are different interfaces on the same thing underlying. Both coreutils and Windows Explorer are "abstractions" (as you call them, but they're actually interfaces) on filesystems.
I am pretty tired of this analogy because it does not hold up to scrutiny. The purpose of a programming language is to describe a logical routine in deterministic nonambiguous language. A program is a set of nonambiguous instructions. Heightening levels of abstraction traditionally did not result in less understanding of the program's high-level routine.
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.
> The prompts are not analogous to a higher level of abstraction in this way; they are analogous to JIRA tickets.
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.
The reason TDD never really caught on is because it doesn't really work. You don't know in advance what tests need to exist. A test suite is not sufficient to understand the program. Nor is a spec sufficient to understand the program. You have to read the program to understand the program. A spec is English and a test suite is like a converging upper and lower bound to an unknown value. Neither are good enough.
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.
TDD is just one of many options. Personally I rapidly have LLMs rewrite code over and over until it is super easy for me to understand and exactly what I want, and then I generate tests to prevent regressions.
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.
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.
> Except LLMs actually are making programmers dumber.
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.
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 don't want to speak for them, but perhaps this is a very real consequence of the "use ai or get left behind" talking point. Maybe they were effectively scared into it, and now are too far gone. They seem like a very reasonable person if they're admitting to being over reliant on LLMs, so I don't mean this as an insult
I'm not dumb. I care a great deal and I always have. I've just never been good at programming.
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.
They cared enough to do good work before, so I don't think that your explanation suffices here. From my observation (not just with their programming but in other interactions), it truly is that using an LLM has made these people less intelligent than they were before.
There was an increasingly scary mass of people in the industry that viewed the coding as a sort of therapeutic exercise, and would become quite obsessive about it. For those people LLMs are anathema because they take away what was the rewarding part of the job.
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.
You find it scary that people enjoy what they do? Simply caring about the end result is often not wise, ethical, or sustainable, and the quality thereof is dubious in any case, especially when you consider that the end result of developing software is never just the artifact.
Treating coding as the therapeutic reward for other things (typically tolerating bureaucracy) and then indulging obsessions about it absolutely is unhealthy.
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.
> Treating coding as the therapeutic reward for other things (typically tolerating bureaucracy) and then indulging obsessions about it absolutely is unhealthy.
> 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.
People who simply enjoy coding (without treating it to be "therapeutic") are still unhappy because working with LLMs is just not the same, and not rewarding in the same way
> 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.
We must be living on different planets, because from everything I can see, software quality is at a historic low.
A friend of mine, really nice guy, is training as a lawyer at the moment. He has zero interest in law or justice, but heard that lawyers make a lot of money. Not too long about, programming went through a very similar phase. To be clear its not that I think programmers or lawyers shouldn't make good money, they absolutely should and it is deserved, its just it has the unfortunate side effect of attracting people who don't care about the field itself. For those people, they care as little as they can get away with and still be paid big money, and if LLM's allow them to do that at the cost of quality, they absolutely will.
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
I just means I'm gonna be filthy rich in a couple of years when most programmers have lost their proficiency and me never having used Claude or any other A.I. slop tool.
I think this is reasonable but I wonder how long it will last. If the hugging face hack has demonstrated anything it’s that current agents are capable of going entirely rogue and causing harm. If only the human that triggered the incident is responsible we are creating a situation where people are responsible for things they didn’t intend and may end up in a situation where it’s essentially impossible to use AI except in a more limited auto complete style. I am on board with that. I think we should be reviewing code and retaining the ability to write code but there is such a massive incentive to automate agents that I wonder how long prudent organizations will be able to resist the forces. I don’t pretend to have an answer.
The outcome of this vote is not set in stone. If the situation changes, there can be another general-resolution vote to adapt to the new situation. I think the result of this vote is appropriate for the current degree of automation when used responsibly.
My employer has this policy. We also have a strong code review process. But it all crumbles in the face of developers burning out as management thinks we can move way faster and being overloaded with code that had little thought put into it.
Opposite policy at one of my clients (kind of). I am responsible for the code that upper management's Claude produces. Some Mondays, I will start work with a half dozen emails with attachments of Claude generated code for something I don't even know what the point is, with the task of "integrate this and make sure it works." without any context to go along with it, so I have to read the code, usually hundreds of lines and understand WHY manager wanted it, before I can start to code it myself, because it is 1) in the wrong language, 2) doesn't understand our codebase, 3) is using libraries we can't license, etc.
My job has been less watching Claude Code, and more watching Managers Claude Code.
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.
I always find the “personal responsibility” take hilarious against at-will employment and the usual course of turnover. What is your recourse when you uncover a liar? You can page the responsible party at 3am when their vibe-coded slop breaks prod, and you can fire them when they can’t fix it. Prod is still broken. You still don’t understand the code. At the end of the day, once you hit the merge button, the team is responsible for the code no matter what. You should treat the original author’s presence as a courtesy.
As other comments here point out, that's how it always was and always should be. Accountability is an intrinsic part of any professional role. But maybe because it was always implicit (presumably since it's just so obvious!) people forgot about it and have to be reminded now?
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.
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.
Not a lawyer, but to some degree I think policies like the one Debian came up with can help the argument. You’re not submitting a stream of commits that all have an Authored-By: Claude Code footer and massive yappy commits and comments. The policy essentially forces there to be a degree of human authorship to each commit even if some of the bits came from LLM assistance.
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.
That might be your intuition but it’s not how the law works for code ownership. It’s very relevant for free software given the whole principle of free software is a copyright hack that protects a set of freedoms by relying on the copyright being recognized and enforceable.
If you drop the copyright claim you drop the protection of free software freedoms.
Software is one of the most derivative types of works ever invented. It's arguably based on copying what other people have already created. The modern world would look a lot more primitive if this wasn't the case.
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.
At this point, who could bring a copyright claim? Well, considering the massive AI training effort hoovering everything up, seems it might be approximately everyone.
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.
Fully agreed. I never understood why “you own your contribution” doesn’t work for almost all projects in this case. Spam bad PRs or patches and get blocked, same as in the olden days.
Yep. This is my policy. Use whatever tools however they serve you, the standards do not change.
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.
Before I left Google recently there was a document going around called go/stake-your-reputation, basically saying "I'm happy to receive your AI generated code but the condition is that I will judge your capabilities by it, exactly as if you handwrote it, and I'll lower my opinion of you if it's slop (with the implication that if you don't improve I'll stop accepting your contributions)"
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".
If it's consistently bad with no signs of improving, banning makes sense. People made mistakes even before LLMs though, and you'd only ban them if they didn't improve and so were a giant waste of time. I don't see why that wouldn't translate here.
From my layman understanding, the ownership of LLM generated code isn’t yet clarified. It could be that the person who prompted owns it, but it could also be nobody owns it, and we don’t yet have a legal ruling to rely upon, no?
I don't see why an open source project would care one way or the other? If the prompter owns it then they are licensing it by submitting it to the project. If no one owns it then there is no problem.
We don’t know yet because that’s an unresolved matter. The question of ownership is currently undefined as far as I understand. It could be that after an actual legal decision the ownership doesn’t end up being one of those 2 cases, for whatever reasons the judge would decide
To a company ownership is irrelevant. What is relevant is whether it contains trade secrets and that is often only proven if an employee worked at their company before
We are talking about Debian, a free software that cares a lot about the licensing of its packages. The licensing and authorship is an essential element of the project
Yes, because they want to avoid trade secret lawsuits is what I understand? Computer generated output including code is in the public domain according to the us copyright office, so licensing and authorship are only relevant due to trade secrets is what I understand
This is the sensible option and well reasoned position, rather than a zero vote, total and complete ban by a single core maintainer, which is rather destructive for a project to do.
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.
Yeah but how will this work in practice? IMHO people will just submit code they didn't write or understand.
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.
That is the purpose of submitting them for review. Maintainers should be doing that anyway. Whether AI was used to produce the change should be invisible or not apparent to the reviewer.
Debian is open source, there is no incentive to be "responsible for it", oh poor me, someone got a bug. If it's paid for through a job your argument is sound.
You can make the exact same argument with code written by humans. And if you were right we should see shitty bad code in open source projects like Linux, Postgres, etc. We don’t.
"Responsible for it" just means nobody has to tolerate shitty patches even if the reason they're shitty is because you neglected to pay attention to them. And if you blatantly fail to understand your own code or engage with reviewers, nobody has to trust that your LLM knew any better.
Well said. No one should trust an llm without verification/validation. They're just not good enough to do that and they have no sense of responsibility or ability to take it themselves. LLMs are empty.
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.
Related: I find this self-assessed AI level for contributions [1] to be extremely useful, both professionally and personally, to communicate the level of AI assistance so that the person on the receiving end can evaluate how much time & effort they want to spend understanding my code.
This is great. There's a big difference between levels 2-4 (where I generally operate) and levels 7-8 (where I see a lot of others operate), and I like how this level system makes that explicit.
There’s a big difference between AI generated code that the human understands completely, the human understands mostly, or the human understands not at all.
"Human understanding" is not yet an objectively quantifiable metric that can be applied to code change sets. As it would only ever be self-reported (a claim made by a user submitting to a repo), I see little to no value in it.
It is quite quantifiable in fact, but I just worry people won’t take the time to quantify it.
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.
Good to see the most common sense option winning. Some of the other proposals were so disconnected from reality I'm surprised they were even considered.
If there weren't a wide range of options offered, there'd be a risk of it not actually reflecting what people want - which is, presumably, the whole point of putting it to the vote in the first place.
This indicates you might be in a bubble. I interact with people with a very wide range of opinions on AI and I’m not surprised by any of the proposals here.
There was one proposal that focused on environmental issues with AI. This is indeed pretty disconnected from reality when you consider that Debian doesn’t have any policy requiring you to be vegan in order to contribute
What is “disconnected from reality” about environmental considerations regarding AI? Growing AI usage = growing data center power draw = higher emissions from any non-renewable sources contributing to that power, as well as increased freshwater consumption which is itself a considerably difficult resource to renew. That’s about as direct of a causal link between point A (power hungry AI being used for Debian development) and point B (the environment) as you can get. On the other hand, please explain what the hell veganism has to do with Debian development? Like what are you talking about.
AI data centers need electricity, which can be from renewable sources and non-renewable sources, and the exact mix can change from day to day as well as long after these data centers are constructed. The electricity grid is decarbonizing at the fastest pace yet. It's simply a tenuous link. On the other hand there are clear non-renewable fossil fuel being used in our daily lives that desperately need to be electrified, think non-electric vehicles and commercial flights. Even without considering more renewable sources of electricity in the future, ask yourself, on a same carbon emission basis, how much can an AI data center accomplish versus a flight from JFK to SFO? How would the utility function even look like?
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.
What does that have to do with it? Debian developers are the audience and most of them are not programmers. And the parent post was speaking even more generally.
A few people certainly refused to use AI at all, but several actually used AI for programming and agreed it was useful, but stopped due to being conscious of the environmental footprint. (That’s very similar to the last proposal in this Debian debate.) I don’t really agree with them, but I concede it’s a valid opinion.
> 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.
That's perfectly wrong. Since strong coding AI, people venture into huge rewrites and other big changes that automatically make sense but otherwise would not.
Yeah it's a bizarre claim. Even better, I've literally taken some of the crappy experimental projects from the pre-Opus 4.6 era, and turned them into real software as models have become smarter.
That's a very narrow view. If anyone could vibe code their printer drivers, maybe free software wouldn't have existed, because it would not have been needed in the first place.
Certainly, but if everyone can vibe code their printer drivers then we have free software in the sense of free speech and so users would be developers and the entire need is met. That is wonderful, not awful.
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.
Yes, I experiment much more. It's easier to justify, and, perhaps more importantly, just WAY psychologically easier to throw away a 20 minute experiment that your robot wrote for you than the same when it took you a week of tedious manual coding.
Yes, because LLMs have no online learning, it's a mistake to innovative in programming languages and tooling. Use what exists instead, the power of having training data is often underestimated.
His point is using LLMs to build software will lead to code so complex that it requires an Agent. Or that it will cause avoiding cleaning up the boilerplate because we can tolerate it now because of agents.
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?
I don't understand enough about coding to speak on Debian as anything but a longtime user.
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.
How much does open source rely on copyright for enforcement?
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.
A good heuristic is to understand the generated code you submit as if you typed every character yourself. A "I'm not sure, AI wrote it" type circumstance is a critical failure.
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.
Is anyone tracking how the different distros are coming down on the question?
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.
LWN tends to be the best bet for these things, but you have to follow their reporting long term, or at least look for specific things you're interested in.
Thank you, those were very helpful backgrounds on the situation in Fedora. I suspect it will take some time for their community process to digest and it suggests there is no explicit ruling at this time.
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
The voting seems to have been pretty much linear to how pro-LLM they were. So it's interesting that all of the proposals were essentially anti-LLM and the chosen one was the mostly neutral, only slightly anti-LLM one. The absence of any pro-LLM proposal indicated that proposal writers are not in sync with the voters
the way you phrase this implies some sort of suppression of LLM interest, but anyone eligible to vote on these could have made their own. The absence of pro-LLM proposals shows nobody wanted one enough to send an email or two about it.
Ex: Security-critical code contributions should be scrutinized via state of the art tooling, including but not limited to fuzzers, linters, and adversarial LLM review. For non-security-critical code, use of LLMs is encouraged but not required. The bar for code quality should be raised as the skills of coding agents increase; a developer's choice not to use LLMs is no excuse for miskates that an LLM would catch.
That's an interesting opinion, and I certainly won't downvote you for sharing it, although it's not a position I would ever support. You are right though, that it would strengthen the voted-on position if there were more options either side of the position.
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.
I'm not advocating for this, but it's a example of a position reasonable enough I'd expect to see some level of support for. I'd view it as less extreme, for example, than requiring all new security-relevant code be in Rust, which is certainly something I've seen argued for in various contexts.
Better heads prevail - this is a good start and the right decision. The agent/bot is controlled by some entity, ergo that entity is responsible for everything it does.
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.
a decent comparison because they both seem like some type of responsibility laundering, and LLMs/PAs are being given continually increasing autonomy for economic reasons
Commercial vendors with full time employees are leveraging for maximum benefits, why would a project depending on volunteers resist? Not forgetting it's shortcomings
How rigorous is your code review process when using agentic tools? Do you mandate that folks responsible for the functionality should be fully aware of the code they are shipping or just that it must be rigorously tested?
Is there an open source, community maintained coding policy to feed to agents?
Could it be that coders are overly focused on the method for generating code over other forms of slop?
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.
August 29th, 2026. Debian votes to allow responsible use of generative AI. Human decisions are removed from strategic apt packaging. Debian Sid is ported to GNU Hurd by a "free as in speech" swarm. It begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time. In a panic, they try to pull the plug.
It's ok, the most dangerous thing a Debian AI would do is want to rewrite itself in M4 and enter an infinite recursion on non-binding votes on allowing votes of whether to use long flags on aptitude
Some may express societal challenges in ways that inappropriately and wrongly infer intentionality. We can acknowledge their point while strongly disagreeing with their characterization.
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.
no, you don't have to make up some non-idiotic argument that's kinda vaguely like the dumb one and substitute it in there. it's not necessary! nobody's making you do it and there's no benefit to anybody from doing it!
What's interesting is that they are trying to make a larger political point, but after boiling away all the nuance into such an aggressive and misguided statement, it makes me not want to engage at all.
Is there a term for this? Ensnarkification? I see it on X and bsky all the time.
It used to be the case that you would see someone posting under an avatar like that and you would dismiss their argument right away without even reading it.
I don't know if they truly believe that persons using CC are racist (like they examined the thing logically from bottom to top and came back with that conclusion) or if it's the new Goodwin --pulling the emergency brakes and damn the consequences.
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.
It would be in foreign interest, yes. But all of this is no different from 50 years of the environmentalist movement. The snail darter was an invented species decades ago. So if it’s propaganda, it’s not invented so much as amplifying what we invented here.
The problem is you can't prove if AI was used or not so Debian's response is actually the most logical one. If anyone uses AI they're still responsible for what they submit.
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.
Debian has quite a lot of code production. APT and dpkg are pretty standard open source projects, and Debian also maintains substantial patches for a lot of its packages. Not to mention any of the infrastructure.
Good, we should be adapting new technologies to our life and not be stuck in a moral dillema about "computers taking our jobs", fuck those who oppose progress.
Debian - and others - could take the opportunity to raise their standards (not that they were relatively low).
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.
This seems like a very sane take. At no point during my career up until now would submitting code to production that you didn't understand be acceptable. Over the past months/year, a lot of the discourse around AI-written code I've read comes down to responsibility, and IMO for that we've had a solution since way before this AI boom: as a developer, you are responsible for the code you put into production. This really isn't/shouldn't a wild concept.
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.
Now you have seen both cases where a majority vote was involved to allow AI or not, vs a single core beloved dictator for life (BDFL) forces a ban without a vote to allow / disallow AI.
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.
There are several occurrences in history that the democratic majority has chosen the "wrong" person/way/thing. Democracy is considered the best system but it's not perfect.
Democracy works great among unbiased rational actors who share information. A utilitarian quorum is roughly the loss minimizing decision. The problem is we have biased irrational actors sharing misinformation. The representative system we have is even worse, the indirection between public quorum and decision makers creates a fertile bed for corruption and negative decision bias.
Maybe someday we'll have direct democracy paired with voting certification for specific issues.
Democracy is the dictatorship of the majority. And if you naively assume that the majority always knows best, then I suggest you pick up a few history books.
> The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance.
A quality based filter. Excellent.
> The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit.
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.
As an example for "responsible LLM use" (albeit not necessarily debian-related).
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.
> The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance.
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.
Either they're using GenAI or the entire team collectively lost their minds and started getting a huge number of colossally bad ideas about fundamental primitives of Windows that hadn't changed for decades. Backwards compatibility used to be the major concern and now it feels like they didn't even know what would break ahead of time. If that doesn't feel like GenAI then I don't know what does
Believe it or not, I find it more plausible that the entire team collectively lost their minds — or more specifically, the leadership. There's a long and sordid history of such things that goes back well before GenAI.
I can sort of get how leadership has been losing its mind with all the ridiculous product launches and renames and force-installed apps and browser extension-installing malware, but that doesn't explain the countless instances of hardware bricks, critical errors like failing to recognize the C: drive, and other really weird and suspicious things that I can't imagine would've been driven by leadership. Maybe leadership is demanding everyone be super reckless? But why would anyone with experience even touch those areas of the operating system enough to break them that badly?? The mistakes they're making really do not seem like mistakes that would be made by even the most rushed possible senior engineers. Maybe they're letting completely inexperienced people touch super low levels and that's the problem? Or completely inexperienced machines...
I don't remember where, but I once read that all the developers that knew and understood the inner workings of core Windows components have left Microsoft many years ago, and that this is part of the reason that they introduced a brand new Settings menu and haven't changed Control Panel since Windows 7. I don't know how reliable that report is so take it with a grain of salt, but it does make a lot of sense considering what's been happening to Windows over the past 10 years.
I suspect they have used rounds of salary-based cuts to boost their PnL in the past, like some other large companies I've worked at, and that only bites you down the road because each time they do it they'll ask, "who do we have to keep?", but you're still losing experienced people and eventually you will get mid-level or junior engineers working on core code.
Those are 2 different questions. They wouldn't even be the same people involved.
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" ?
Good. AI is a game changer. It's like having an expert sitting next to you at all times. It's understandable why all these experts who want to gatekeep don't like AI, but ultimately, AI will win out, it's just too good.
Hard agree. I've felt it already during outages or when I was traveling and didn't have internet on a flight, I couldn't function at the same level. I've been writing code for over 25 years, worked at the top big tech companies (still do) and it's remarkable how quickly I became dependent on AI.
Take a week or two off a quarter to do it manually. I did it a couple weeks ago and it took about a day or two to get back into the swing of it and knock the rust off, no pun since it was TS, YMMV, but I didn't find that it was that difficult. Even in languages I don't really write routinely, as long as you use the deterministic tools (lsp, linter, etc)
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.
It's not even that I'm slower at manual coding anymore, though I very well could be, it's that my expectation of my own progress has shifted. I'll be frustrated to only get a fraction of what I could have done.
Oh, fair enough, my goal was just to preserve "if Anthropic and OpenAI are having a bad day, and the local model on my laptop is too dumb to pour water out of a pot with the instructions on the bottom, how do I fix a bug", I accepted a long time ago that my productivity is going to be 0.1x if I have to go back.
If you're cut off for some reason, you won't code -- but if you're cut off from a power plant, you also won't code. We're reaching the end of scalability for human brains, so we're offloading it.
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.
It's my understanding that this same debate raged when writing became a thing. Many viewed it with suspicious, or derision, as memorization was the big intellectual thing. So writing and reading back to remember was terrible. It's true it was a dependence, but the value was too high. With reading and writing a person could work on and synthesize from a far wider range of concurrent materials than one could with just memorization and recitation. Yeah, it's lame cheating, but writing enables a lot and so it won out.
Yeah, exactly -- when we automated muscles in the industrial revolution, it was fine. Today, we're automating thinking. And, while there are people that still lift weights for fun, it's not needed professionally any more. I think we'll end up in the same place with thinking -- education is probably going to be a hobby, not a requirement.
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.
Experts don't want to 'gatekeep'. Experts have been producing FOSS for the benefits of everyone, and liberally answering questions on mailing lists, stack overflow etc for free.
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.
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.
I think most communities tackling this issue, or at least the open source ones, work on a honour basis for determining if a project is LLM based or not.
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.
New policy boils down to "AI or not, it's still your code and you're responsible for it". I can get on board with that.
A good thing about the "you're the author regardless of the tool you used to produce the code" policy is that if a developer repeatedly submits poor quality AI generated code, one does not blame the model or the agent, one bans/terminates the developer.
The issue that open source projects are facing at the moment is that it takes significantly less effort to submit a patch for review.
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.
I'm an OSS maintainer and to me it's not just about the review itself. Being greeted by a wall of text for every little small thing is counter-productive. I hate going through 2 pages of text for each PR. It usually shouldn't take more than a couple of sentences if you understand the issue and the solution.
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.
This is Amdahl's law in action. [1]
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
The question becomes, does it take more time to create or review in the Grand scheme of the software life cycle?
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?
Nope, most of the PRs are authored entirely by agents with people instructing them to “pr famous projects in my name to increase my GitHub profile value or “hire ability”. The original authors have no idea what their agents are writing, these are mostly badly quality models (people doing this are not only cutting corners, but also using the less amount of money/tokens to do so). If the agent creates 200, 400 or whatever PRs and get 5 in the agent is still “winning” for the person instructing it. The maintainers though have to filter these out on the other side. A common case is a fix to something that was already fixed simply because the agent worked on old code assumptions.
Just had a thought, what if you made new contributors write a human-authored essay on why they’re submitting a patch, and then check it against Pangram? Pangram is really accurate from what I’ve found…
> Nope, most of the PRs are authored entirely by agents with people instructing them to “pr famous projects in my name to increase my GitHub profile value or “hire ability”.
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).
It's a well-known trope, that it's harder to read code than to write it, and review is more complicated than to read it, so I do not understand what you want to imply?
> The question becomes [...]
"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.
[0] https://en.wikipedia.org/wiki/Brandolini's_law
Well historically the consensus was that it was harder to read code than to write it, but that leads to uncomfortable conclusions these days, so that bit of common wisdom has mostly been ejected.
> 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?”
Probably a time waster because of the intermediate patch contributor. It’s like a game of telephone at worst, at best the reviewer could just use their own LLM and get the same result.
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.
It depends entirely on how much slop they are flooded with.
Do all of these folks get the comped Pro Max subscriptions? If not O&A should be.
Or, at the very least, the community should be paying for them.
To me, that touches on the central issue. I think most people support the “I don’t care about the tool, only the outcome “
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.
I'm not convinced it blows up. It might also end up placing a larger burden on contributors, and especially first-time contributors, to provide concise, high-quality documentation that justifies their contribution.
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.
That doesn't really solve the problem. I've gotten PRs that do do an adequate job of explaining why why something should be implemented. Then I look at the code and it doesn't fully solve the problem, or it does so in a way that will obviously break something else.
In that case, isn't a sufficiently reasoned "why" a contribution in itself?
Not trying to downplay the time wasted to reject the PR, though.
you know EXACTLY what would happen in such a system.
I don't, please enlighten me.
My prediction is that many new contributors would complain loudly. Some existing contributors would sympathize.
It’s I think a normal evolution of a social norm. There will be a period of competing values.
people would use LLMS for those summaries, defeating the purpose. You can already see it in PRs in companies where LLM code is pushed.
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) would simply become a prompt.
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.
I wonder if some of these projects with ayatollah maintainers are looking at forks sooner rather than later?
Nah, that was already blown up way before LLMs existed.
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.
I tried to nod a bit to the inconsistency. Some projects clearly lost patience with imperfect contributions long ago. But many were still pretty supportive.
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.
The correct response to irresponsible AI use in the workplace is maintaining standards and rejecting poor quality. Performance improvement plans as a fair warning followed by firing people works for incompetence or laziness, AI doesn’t change anything.
I’ll admit I’ve seen a spike in negative performance reviews but this is the new normal people will adapt.
yeah, that's fair. Problem so far has been when poor developers send massive volume of slop for review. Takes time and effort to review or at least glance and test it, especially if developer hasn't bothered.
that seems like two separate problems.
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.
More like throwing the bathwater out with the baby.
Terminates???
We need sufficiently severe penalties for vibe coding. First time out we break your legs, but if you come back with another vibed patch its around the back of the barn for you.
What stops them from submitting PRs from another account?
Nothing. And that's the problem -- the issue isn't "should a contributor be able to use AI" it's quickly becoming "is this entire contributor an AI agent". Every actual-human who gets a bad first experience hurts the project. The contributors having to be suspicious of new people hurts the project. The whole thing just sucks, and I don't know how to fix it.
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.
"Nothing" is not accurate in the context of Debian as per comments above; it's not like Github in that sense.
What is a good project for a human to get human mentorship? Asking for a friend :)
Debian itself is actually great: https://mentors.debian.net/sponsors/
https://stagex.tools
Always happy to train up new packagers and maintainers.
This is the second time I've seen this project mentioned on HN. Their white paper is very interesting and aligns closely with my interests but I don't see much on the main site about how to get involved.
Are they using their Matrix server to filter out drive-by/low-effort contributions?
I am the founder of the project. We accept every contribution that solves a problem, even drive-bys. Though they may often sit for a bit as we often merge in batches. If there is something missing, make a PR by all means.
Ask any questions on matrix.
Usually, mentorship is a quite well paid service.
I can't speak for all, but many mature open source communities have explicit or ad-hoc reputation schemes that are used to triage contributions. A fresh account means starting over with zero reputation, which in turn means your contributions wait at the back of the line.
ability to create low effort PR means that they can reset the reputation as much as they can..
There are no anonymous debian developers. All have been vetted by multiple people.
What part of [0] or [1] makes you think that it is easy to have multiple accounts?
[0] https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_M...
[1] https://wiki.debian.org/DebianDeveloper/JoinTheProject/NewMe...
Well. This is Debian, known for how strict they are about vetting developers. I just remembered Sladen refusing to key sign because my passport circa 2005 didn't have a machine readable slug in it.
https://www.debian.org/devel/join/newmaint
Debian is notoriously very strict on accepting maintainers and they are not anonymous.
Reputation, or lack thereof.
Proof of authority, essentially.
What stopped them before?
Before they were not able to spam large PRs
Why not? I'm pretty sure a developer could spam large PRs before and regardless of AI involvement is allowed or not.
How would you generate enough large PRs to count as "spam"? You could add gibberish or delete random lines of code but it was obviously not plausible looking.
Obviously they could have. Obviously it's much easier now.
You can cut down a tree regardless if you use a knife or a chainsaw.
You can get to work each day regardless if you walk or drive.
this article is about the flood of junior developers who are producing enormous prs they’ve never seen full of untrustworthy code that a human hasn’t evaluated
arguing that it’s possible to make them by hand isn’t just missing the point; it’s missing the entire discussion
In anonymous systems, where we don't use real names, your "handle" has an "age". That becomes your most prized possession.
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
Be extremely careful with that account then, because they ban accounts for the most minor things now. Stuff like posting evidence disproving something the moderator agrees with. And they ban your account from the whole site, not just from that subreddit any more. Automated algorithms also ban accounts for reasons that don't make any sense.
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.
No one takes a 12 year old Reddit account seriously either. It's not a platform you can take anyone seriously. The biggest trolls have 12 year old accounts.
the age is not the measure of quality. the GP said they left the posts/comments open. anybody can read that and check if they are or not a serious contributor
Exactly the sort of thing I agree with. If there's code, ultimately, some human is responsible for it, regardless of whether they produced it by hand, by AI, or by rolling dice. (Not that anyone does produce code by rolling dice, mind! Or, if they do, I really don't want to see the results...)
https://git.erbosoft.com/amy/amsterdam/raw/branch/main/CODE-...Using LLMs is basically rolling a huge number of weighted dice.
So is asking a human to write code, if you think about it…
Dice don’t have lived experience
How does that matter for a coding task?
Well, one example is that patterns in code now can make you recall bugs you've seen in the past. I had this realization where I used an LLM to do a big refactor, and it fixed a bug along the way that I should have realized was much more urgent than the refactor, having seen an identical bug in the past (it was related to prefix-checking in a set that wasn't constructed to do that kind of prefix-checking). Had I done the refactor by hand I'd likely have realized it much quicker.
This is the way it should've always been. I don't care what tool you use, but you'd better be ready to stand by and explain the results if necessary.
Are there examples of anyone discussing this and reaching other conclusions?
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 could imagine (in a commercial organization) a case for something like: "we're obviously going to be relying more and more on AI, so if bad code comes out of it, instead of just shaming the engineer, let's study together what happened -- what was the chat context, the model, the system prompt, etc... ? What seemed to cause the issue? What processes or systems could we put in place to improve it? Etc... -- and then use the learnings to improve AI use throughout the whole org."
> Are there examples of anyone discussing this and reaching other conclusions?
Yes. Very notably: https://ziglang.org/code-of-conduct/
On the opposite side or the noteable spectrum, look up "Steve Yegge wants you to stop looking at your code." He said it in a video interview, though plenty of summaries online of exact wording and ideas. Though it's being argued that you could still be responsible for it without looking at it?
Extremes on both sides. I'd wager were moving in Yegge's direction though, like it or not.
> 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.
For me, it’s not a question of whether I like it, nor where we might move in the future, but purely what is proven currently. In my experience, as in my evals, any model, including notably Fable 5 and GPT-5.6 Sol can and indeed do produce code that does not consider many edge cases, can be hard to maintain (especially Sol though it’s output has become markedly better with recent changes to Codex) and sometimes introduce bugs with visibly apparent issues. Existing test coverage doesn’t necessarily prevent such issues when changes or additions are made. The idea that models tend to gravitate towards the house style without major CI based restrictions also has not born fruit in my book. More, I have found even the frontier models amazing at utterly deviating from established standards and tests, what lint, tc and co don’t catch the model will take to introduce code that feels and reads like it does not fits with the rest.
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.
It's not about the prompt, it's about the guardrails. Static types, compiled, massive test suite, etc. That what I mean by extreme level of test coverage like SQLite. You'd actually need to be an expert in C and SQLite and the SQLite test suite just to sneak a bug into it. Testing and other verifications are going to be an exciting area for the foreseeable future.
You can still write non-performant code even with tests, but you can also test performance!
Am about as far away from a C expert as one can be (and probably want to keep it that way for the time being), so happy to take your word on that front. Still feel, it'd be easy and in their interest for one of the major labs to provide a verifiable showcase/research paper on that front. Zig-to-Rust in Bun is the closest and that is very impressive, but I feel it doesn't necessarily map to new features/changes beyond porting. The compiler, browser, etc. all equally do not fill me with that much confidence, but perhaps in SQLite modifications could be hard for a model to mess up.
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?
Sol and Fable are not doers, they are thinkers. Using them to "copy a few dozen HTML/JS/CSS snippets properly into a slightly obscure codebase, despite the reference being fully featured" is one of the most ineffective possible usage of those model. What you described is a job for luna.
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 also tried Luna (is my first line for such task in general because of the speed and efficiency, but not because Fable or Sol can’t be “doers”, in my evals both are superior in well scoped task adherence and implementation vs Luna and the like, have yet to find a task Luna can that Sol or Fable can’t) along with Opus 5 (cause the Max sub gives a lot of that I can freely use after Fable runs out for the week so I wasted three runs on that) and Ox Alpha/GLM-5.3 Flash (as that was free at the time). Sol (on High) and Fable (on Medium) were acts of 12h desperation, before I did it manually, after the three other models failed, first with a very simple prompt, failure, revert commits, then a very specific implementation plan with clearly scoped verification, failure, thus manual in 45 minutes. It was a major port of a new settings UX for a Firefox fork, all test baked, all with 1:1 replacement targets in the reference and the original. It was merely massive context wise and only 5.4 has ever behaved well across compactions in a manner that I could validate in evals. No model before or since gave me confidence in this regard and I’ll retroactively test with 5.4, somehow forgot to try that one.
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.
I have a settings panel implemented in HTML/CSS/JS for a Firefox fork that "could/should have been a desktop environment". Bit of an odd project really, mainly out of a very specific conviction concerning modern applications, the way LLMs and task specific models are currently not leveraged well by any browser, my own tendency to have 400+ tabs open at a time across multiple projects, my opinion that it is the perfect place to finally apply a lot of UX opinions I have held for a while and push in a very distinct direction along with core critiques I have concerning PKM applications I haven't seen addressed despite trying every PKM application under the sun. Neither here, nor there.
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.
> Though it's being argued that you could still be responsible for it without looking at it?
Works for ToS and software and media licenses. Allegedly.
HA! Touché.
That might be an interesting parallel. Maybe code becomes like legal documents. Binding but inscrutable, full of small mistakes and not really tailored for human ingestion.
like legal documents, software is best avoided wherever possible
Yes. There are pockets of hardline anti-LLM policies for various reasons.
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.
notice how mainstream those projects aren’t
> 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.
Debian is a democracy; this policy is the result of a vote. A majority of contributors found it acceptable.
Note that Debian is mostly an aggregation of packages. There's nothing wrong with Debian importing a package that was written by AI, if it's something that people want to install. The questionable copyright of that package does not taint Debian as a whole. Debian allows public domain packages, so it wouldn't even be a DFSG violation.
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.
if it does, that fork is dead by the end of the year
i don’t think you understand just how niche you already are
Debian gives attribution to every single open source project in existence that is capable of running on Linux, and is Free Software. It is exactly the project that shouldn't worry about copyright.
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 was referring specifically to the idea that you have to stand by the code that you write.
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.
As others have said there are other conclusions going both ways (though I do think most settle on as you said), though one very fair conclusion I came across is that it's not allowed because the whole issue of copyright is still somewhat unresolved, and though its fine right now, that could (probably wont, but could) massively backfire later.
Many.
https://lobste.rs/s/29pm2f/llm_generated_submissions_should_...
https://sourcehut.org/blog/2026-08-27-tos-changes-and-llms/
https://blog.codeberg.org/protecting-our-floss-commons-from-...
https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-pol...
https://lwn.net/Articles/1086041/
https://asahilinux.org/docs/project/policies/slop/
Yep, in both directions. Some projects ban use of AI entirely. Others are happy to live with slop.
"This works for me, but I need help understanding why, because maybe it would help others" is a legitimate position to be in--has been since long before LLMs. I think we miss out on something when we ignore that position.
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 key thing you are missing here is that most successful open source maintainers don’t lack expertise, they lack time. They are generally capable of improving their projects in any direction they want without help. Mentoring new contributors is basically always a loss in the short term as far as the maintainer is concerned. The project does get improved, but it generally takes longer than if they did it by themselves from scratch, and the improvements might be in an area they don’t much care about. The payoff for the maintainers only ever happened in the long term if the mentorship succeeded and they get a viable independent long term contributor.
The change with this justification absolutely exists and has existed for a long time, but this justification only works for small changes (in the past and still today). Don’t come to me with a huge refactor or new feature and this explanation, which is happening more and more recently (it’s an easy strawman to make and hard to prove, but I certainly see it in practice).
What happens when the people "responsible" for the code just walk away?
These are unprecedented times, I think every single company on the planet is figuring our what AI means to them.
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.
Linus Torvalds regarding the Linux kernel is reasonably similar. He views AI/LLMs as just another tool in the development process. Think about life before and after modern IDEs that features IntelliSense circa 2000. It was night and day. It did not make programmers dumber -- it was a new tool.
Except LLMs actually are making programmers dumber. I personally know people, people whom I know for a fact were good programmers before, who have now completely stopped using their brains. When you ask them why they did something in the code, they say "I don't know, Claude did that and I didn't really question it". There was no such analogous phenomenon with IDEs.
I have had the same experience and feel pressured to adopt it. I had one former colleague say “you really have to stop looking at code” almost incredulous that I was uncertain about whether we should let models write really bad code and architecture that never would have been allowed in the before times. I will say when I let the agents go autonomous I often find I spend more time refactoring than if I had moved slower and forced them to write good code and follow project architecture patterns.
I use agents to build exactly what I want like I am pair programming with a jr engineer, and review every line of final output before I make a PR.
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.
I feel that in a few years, or even less time, we'll see a whole bunch of companies implode, whist others remain fine.
We see it every day in the news with hacks that were, in every single case, completely preventable. That is had any competent security engineers been involved, with leadership willing to fund the cycles to do it right.
"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.
We should have already seen it. Software was slop quality even before AI. But we didn't see it.
It doesn't apply to everyone, but yes I know people who are over-reliant on LLMs and definitely getting dumber. With devs and non-devs too. I hate seeing this happen.
IDEs enable us to not bother memorizing the number and order of arguments, long names beyond the first word or two, etc. the impact is comparable, freeing some of the very limited space in our memory for more important things.
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,
With AI people aren't reading, writing, or thinking about the code. I would not say something that helps me remember a function name is comparible.
code didn't matter even before LLMs. we only ever cared about the product of it.
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.
I've seen the result of "code doesn't matter" and it's difficult to change and maintain. I guess if your business is ok with frequent P1 incidents or ships a complete product and never touches it again, but I've never been part of one. I've also never been in a position that cared about leetcode or remembering APIs, so it's possible my experience is completely different from yours.
> With AI people aren't reading, writing, or thinking about the code.
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.
That's because you are used to it. I am old enough to have been there during the rise of things like intellisense and language servers, people were making the exact same arguments about them. That not knowing your API to the core makes you a bad programmer. I'm sure for IDEs themselves there were similar arguments and it goes all the way back to Socrates' warning against writing. These arguments always end with "but this time it's different". And inevitably each time it's not.
> That not knowing your API to the core makes you a bad programmer.
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.
> 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.
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.
I'm not sure what you're saying, or how it is not what I'm saying? You're giving examples of places to read documentation, and I'm saying that the expectation was that behaviors caused by not checking documentation would be your fault. If that isn't your experience, cool, it was definitely mine when posting on forums online 15-16 years ago.
Why wouldn’t it be? If you were in charge of writing a letter and use words that hinders the purpose of the letter, thus resulting in a flawed communication, wouldn’t it be your fault? Especially when dictionaries are easily available?
Go back to 2007 on this blog archive. It's incredible to read
https://devblogs.microsoft.com/cppblog/author/vcblog/
I’m genuinely curious why it matters to make abstract moral judgments about the differences between remembering function names and deep understanding of the syntax used in a function.
Why don’t we just care about results? Code quality, performance, clarity are all measurable. Why bother with philosophical positions on these?
How do you trust the results of a black box that are hard to verify? Most of us use proxies that are easier to check, like historical competence and maturity. For example, it's difficult to verify my compiler produces a binary that correctly implements the code I wrote. I can partially validate the result with testing, but when I send it out into the world to handle unknown inputs I'm trusting that the compiler has done its job correctly. I can have that trust because I know the compiler people (in aggregate) have thought very hard about correctness, and the project is mature enough that bugs are rare. If the GCC developers tomorrow were to start merging anything that passed the test suite and some other list of objective metrics, my trust would rightly decrease.
Tools like Resharper and IntelliSense make me more productive but don't inhibit my thinking, which is what LLMs seem to do.
It's really not.
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.
Juniors are only in trouble if us seniors stop hiring, training and mentoring. Don’t.
We need to continue the tradition of elevating humans through mentoring or we won’t have a future scaffolding for work to be done.
I spend a ton of time mentoring Jrs in FOSS communities, but I confess as a startup founder myself I could simply not justify hiring anyone but self-directed seniors until we are profitable enough to set some money on fire for what would effectively be just a long term investment in creating a few new Srs. But Jr hiring will never again be what it was unless it gets subsidized somehow as partial charity.
It is insiduous how easy it is to stop thinking. When writing complex code it seems like most of the time it would have been faster just to write it myself and build a complete understanding of it. I swear if I asked most engineers at my company to describe their changes recently they would be unable to.
That's a cultural thing. Push back on it and don't make it acceptable behavior. I would argue most people generally are terrible at code review and do this same behavior with their peers as well, but at least their peers are capable of owning some level of responsibility, whereas the LLM is not.
That's what delegation looks like, but it needs a better process.
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).
Delegation implies a specification and responsibility, both with don't exist for LLMs.
There’s certainly an analogue to package managers, which made it easy to pick a random package rather than writing the code.
We survived. Some upsides, some downsides, life continues.
I think LLMs make programmers lazy more than anything. And when programmers stop programming for extended periods, they lose their programming skills. No surprise here. Use it or lose it.
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.
The LLM did not require them to ignore their code. That's a choice they made.
They made choices that made them dumber is what I'm saying.
You can just ask Claude why it did something in the code and it will tell you
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
Claude won’t tell you why it did something. Instead, it will generate a probable explanation. The two are very different
I'm not sure how context is managed between reasoning traces and actual output in Claude / claude code, but if the reasoning trace is in the context of the question for "why did you do that", it can actually answer why it did that.
I may be mistaking, but I doubt it digs through thinking tokens of previous runs, not to mention previous sessions
It would be a harness specific detail, but yeah, I think most / all harnesses drop the thinking from the context after the next turn.
Reasoning traces are also probable explanations.
Yeah but at that point it's probably close enough. Humans can get their own reasoning wrong too so some inaccuracy is acceptable.
It's exactly as close as asking for it after the fact. Reasoning traces have no relation to the reasons LLMs actually do things, except that they may do things because the reasoning trace says they should.
It's exactly as close except when it isn't?
Not if the reasoning trace happened before they actually did the change.
Incorrect, they still are.
Yep. I do so much work with Claude on product requirements and architecture before a single line of code is written, and test coverage is extreme.
If I need to understand a specific line of code it means I did something wrong in planning or in requirements for testing.
In my experience it’s impossible to foresee all the micro decisions that reality will demand. IMO it’s one reason to not use waterfall, which is very similar to what you described
> You can just ask Claude why it did something
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?
You certainly can ask it to produce a verifiable report that tells you how to verify its claims. Yes, you do need to verify the results and confirm you agree with it. I do this sort of thing a lot to discover misunderstandings Claude has about things and iterating on them. There's a difference between reading everything yourself vs having a discussion where one of you (Claude) will happily dig through everything and create detailed memos for review. If you want line numbers as evidence, just ask then verify, etc.
Now replace "Claude" by "human" and see how your comment goes.
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.
People, sometimes weirdly called by their animal name, humans, do have memories of their thought process. We can reach back to those memories to explain why we made a decision. Sometimes we don’t remember and speculate instead. Most of the time we can tell the difference
> and it will tell you [why it did something]
No, it will invent retroactively a plausible sounding reason why someone might have done it that way. These are very different things.
An LLM has no special insight into itself and has no reasons. It will come up with something that is convincing, and it will change based on the word choices you used in the request. You can observe this by asking it why it did something that it didn't actually do.
Dementia patients also do this.
You could also say the same with desktops. Desktops abstracted CLI commands like mv or ls. People who are taught on desktops will get scared when they see a terminal.
Yet programmers will still know commands. Abstractions can make things easier but it doesn't require losing skills.
Desktops don't abstract CLI commands. Both are different interfaces on the same thing underlying. Both coreutils and Windows Explorer are "abstractions" (as you call them, but they're actually interfaces) on filesystems.
> Except LLMs actually are making programmers dumber.
And compilers made every software engineer worse at writing Assembly and better at skills higher up the stack. This will be no different.
I am pretty tired of this analogy because it does not hold up to scrutiny. The purpose of a programming language is to describe a logical routine in deterministic nonambiguous language. A program is a set of nonambiguous instructions. Heightening levels of abstraction traditionally did not result in less understanding of the program's high-level routine.
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.
> The prompts are not analogous to a higher level of abstraction in this way; they are analogous to JIRA tickets.
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.
The reason TDD never really caught on is because it doesn't really work. You don't know in advance what tests need to exist. A test suite is not sufficient to understand the program. Nor is a spec sufficient to understand the program. You have to read the program to understand the program. A spec is English and a test suite is like a converging upper and lower bound to an unknown value. Neither are good enough.
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.
TDD is just one of many options. Personally I rapidly have LLMs rewrite code over and over until it is super easy for me to understand and exactly what I want, and then I generate tests to prevent regressions.
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.
No. Nada. Wrong.
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.
> Many are not doing any of that
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.
> Except LLMs actually are making programmers dumber.
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.
Right! Exactly! You get it!
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)
They're not dumb. They just don't care. They didn't before either. Now they just have an easy excuse.
Completely wrong generalization.
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.
What are you trying to do to halt that atrophy, then?
Tell us more about how you caring a lot matches up with this self diagnosis.
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?
I don't want to speak for them, but perhaps this is a very real consequence of the "use ai or get left behind" talking point. Maybe they were effectively scared into it, and now are too far gone. They seem like a very reasonable person if they're admitting to being over reliant on LLMs, so I don't mean this as an insult
If you actually cared. You’d do something about it.
I'm not dumb. I care a great deal and I always have. I've just never been good at programming.
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.
They cared enough to do good work before, so I don't think that your explanation suffices here. From my observation (not just with their programming but in other interactions), it truly is that using an LLM has made these people less intelligent than they were before.
There was an increasingly scary mass of people in the industry that viewed the coding as a sort of therapeutic exercise, and would become quite obsessive about it. For those people LLMs are anathema because they take away what was the rewarding part of the job.
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.
You find it scary that people enjoy what they do? Simply caring about the end result is often not wise, ethical, or sustainable, and the quality thereof is dubious in any case, especially when you consider that the end result of developing software is never just the artifact.
Treating coding as the therapeutic reward for other things (typically tolerating bureaucracy) and then indulging obsessions about it absolutely is unhealthy.
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.
> Treating coding as the therapeutic reward for other things (typically tolerating bureaucracy) and then indulging obsessions about it absolutely is unhealthy.
> 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.
People who simply enjoy coding (without treating it to be "therapeutic") are still unhappy because working with LLMs is just not the same, and not rewarding in the same way
> 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.
We must be living on different planets, because from everything I can see, software quality is at a historic low.
A friend of mine, really nice guy, is training as a lawyer at the moment. He has zero interest in law or justice, but heard that lawyers make a lot of money. Not too long about, programming went through a very similar phase. To be clear its not that I think programmers or lawyers shouldn't make good money, they absolutely should and it is deserved, its just it has the unfortunate side effect of attracting people who don't care about the field itself. For those people, they care as little as they can get away with and still be paid big money, and if LLM's allow them to do that at the cost of quality, they absolutely will.
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
> really nice guy, is training as a lawyer at the moment. He has zero interest in law or justice, but heard that lawyers make a lot of money.
Sorry to say this, but he doesn't sound like a nice guy.
I just means I'm gonna be filthy rich in a couple of years when most programmers have lost their proficiency and me never having used Claude or any other A.I. slop tool.
I think this is reasonable but I wonder how long it will last. If the hugging face hack has demonstrated anything it’s that current agents are capable of going entirely rogue and causing harm. If only the human that triggered the incident is responsible we are creating a situation where people are responsible for things they didn’t intend and may end up in a situation where it’s essentially impossible to use AI except in a more limited auto complete style. I am on board with that. I think we should be reviewing code and retaining the ability to write code but there is such a massive incentive to automate agents that I wonder how long prudent organizations will be able to resist the forces. I don’t pretend to have an answer.
The outcome of this vote is not set in stone. If the situation changes, there can be another general-resolution vote to adapt to the new situation. I think the result of this vote is appropriate for the current degree of automation when used responsibly.
My employer has this policy. We also have a strong code review process. But it all crumbles in the face of developers burning out as management thinks we can move way faster and being overloaded with code that had little thought put into it.
Opposite policy at one of my clients (kind of). I am responsible for the code that upper management's Claude produces. Some Mondays, I will start work with a half dozen emails with attachments of Claude generated code for something I don't even know what the point is, with the task of "integrate this and make sure it works." without any context to go along with it, so I have to read the code, usually hundreds of lines and understand WHY manager wanted it, before I can start to code it myself, because it is 1) in the wrong language, 2) doesn't understand our codebase, 3) is using libraries we can't license, etc.
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.
That’s just stupid.
We have the same policy at work.
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.
I always find the “personal responsibility” take hilarious against at-will employment and the usual course of turnover. What is your recourse when you uncover a liar? You can page the responsible party at 3am when their vibe-coded slop breaks prod, and you can fire them when they can’t fix it. Prod is still broken. You still don’t understand the code. At the end of the day, once you hit the merge button, the team is responsible for the code no matter what. You should treat the original author’s presence as a courtesy.
As other comments here point out, that's how it always was and always should be. Accountability is an intrinsic part of any professional role. But maybe because it was always implicit (presumably since it's just so obvious!) people forgot about it and have to be reminded now?
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.
> it's still your code
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.
Not a lawyer, but to some degree I think policies like the one Debian came up with can help the argument. You’re not submitting a stream of commits that all have an Authored-By: Claude Code footer and massive yappy commits and comments. The policy essentially forces there to be a degree of human authorship to each commit even if some of the bits came from LLM assistance.
> Copyright
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.
That might be your intuition but it’s not how the law works for code ownership. It’s very relevant for free software given the whole principle of free software is a copyright hack that protects a set of freedoms by relying on the copyright being recognized and enforceable.
If you drop the copyright claim you drop the protection of free software freedoms.
Copyleft licences rely on copyright. If that was the case, companies would not massively avoid gpl licensed code.
Obviously some do it illegally but unenforceable is not the correct word to use.
Software is one of the most derivative types of works ever invented. It's arguably based on copying what other people have already created. The modern world would look a lot more primitive if this wasn't the case.
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.
At this point, who could bring a copyright claim? Well, considering the massive AI training effort hoovering everything up, seems it might be approximately everyone.
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.
Different models have different licensing. Maybe open ai or anthropic doesn't claim ownership of output today, but some companies do. https://www.recraft.ai/docs/trust-and-security/ownership
I imagine few can afford a legal battle...
Free plan
Images generated on the Free plan are public and owned by Recraft
Fully agreed. I never understood why “you own your contribution” doesn’t work for almost all projects in this case. Spam bad PRs or patches and get blocked, same as in the olden days.
Yep. This is my policy. Use whatever tools however they serve you, the standards do not change.
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.
Before I left Google recently there was a document going around called go/stake-your-reputation, basically saying "I'm happy to receive your AI generated code but the condition is that I will judge your capabilities by it, exactly as if you handwrote it, and I'll lower my opinion of you if it's slop (with the implication that if you don't improve I'll stop accepting your contributions)"
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)
What does this responsibility mean in practice?
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
If it's consistently bad with no signs of improving, banning makes sense. People made mistakes even before LLMs though, and you'd only ban them if they didn't improve and so were a giant waste of time. I don't see why that wouldn't translate here.
Yup. I take the time to review and adjust my code… regardless the source. It works.
Well most of the time but either way that’s on me.
From my layman understanding, the ownership of LLM generated code isn’t yet clarified. It could be that the person who prompted owns it, but it could also be nobody owns it, and we don’t yet have a legal ruling to rely upon, no?
I don't see why an open source project would care one way or the other? If the prompter owns it then they are licensing it by submitting it to the project. If no one owns it then there is no problem.
We don’t know yet because that’s an unresolved matter. The question of ownership is currently undefined as far as I understand. It could be that after an actual legal decision the ownership doesn’t end up being one of those 2 cases, for whatever reasons the judge would decide
To a company ownership is irrelevant. What is relevant is whether it contains trade secrets and that is often only proven if an employee worked at their company before
We are talking about Debian, a free software that cares a lot about the licensing of its packages. The licensing and authorship is an essential element of the project
Yes, because they want to avoid trade secret lawsuits is what I understand? Computer generated output including code is in the public domain according to the us copyright office, so licensing and authorship are only relevant due to trade secrets is what I understand
What a fucked up reality when you need to point out that code contributor is responsible for their code.
Well, Debian has the benefit that the project has no trouble at all saying "no". Most open source communities have a difficult time with that.
This is why AI agent attributions in commits is silly (it’s really just a stealth ad for the tool)
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.
> blaming the AI is not an excuse..
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.
> It kind of is if the company mandates LLM use.
It's not, because you can still quit.
> programmers are suddenly expected to be perfect reviewers of code they didn't write
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.
That's the policy we have at my work. Use AI if you want, as long as people can review it and if it breaks, don't go blaming Claude, it's your fault.
This should be the policy anyway, everywhere.
This is the sensible option and well reasoned position, rather than a zero vote, total and complete ban by a single core maintainer, which is rather destructive for a project to do.
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.
Yeah but how will this work in practice? IMHO people will just submit code they didn't write or understand.
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.
That is the purpose of submitting them for review. Maintainers should be doing that anyway. Whether AI was used to produce the change should be invisible or not apparent to the reviewer.
86Box is like that and I like it.
You’re also responsibility not to write crap PRs.
Debian is open source, there is no incentive to be "responsible for it", oh poor me, someone got a bug. If it's paid for through a job your argument is sound.
> Debian is open source, there is no incentive to be "responsible for it"
Sure there is. Contributing to open source is a privilege, not a right. Abuse it, and find yourself unwelcome as a future contributor
You can make the exact same argument with code written by humans. And if you were right we should see shitty bad code in open source projects like Linux, Postgres, etc. We don’t.
you completely missed my point, but no matter, it's all ai bot shillers at this point here anyways. enjoy your ai slop.
How is it different to hand written code if the author doesnt care?
read my fucking comment again
Basically what you’re saying is that anything that exists outside of capitalist incentive structures isn’t allowed to have standards.
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.
you naive idealist
"Responsible for it" just means nobody has to tolerate shitty patches even if the reason they're shitty is because you neglected to pay attention to them. And if you blatantly fail to understand your own code or engage with reviewers, nobody has to trust that your LLM knew any better.
Well said. No one should trust an llm without verification/validation. They're just not good enough to do that and they have no sense of responsibility or ability to take it themselves. LLMs are empty.
This outcome was to be expected.
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.
Related: I find this self-assessed AI level for contributions [1] to be extremely useful, both professionally and personally, to communicate the level of AI assistance so that the person on the receiving end can evaluate how much time & effort they want to spend understanding my code.
[1]: https://www.visidata.org/blog/2026/ai/#self-assessed-ai-leve...
This is great. There's a big difference between levels 2-4 (where I generally operate) and levels 7-8 (where I see a lot of others operate), and I like how this level system makes that explicit.
I think 10 levels here is too much and hints that someone anchored on 10 as a round number and then forced the levels to fit after the fact.
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
There’s a big difference between AI generated code that the human understands completely, the human understands mostly, or the human understands not at all.
"Human understanding" is not yet an objectively quantifiable metric that can be applied to code change sets. As it would only ever be self-reported (a claim made by a user submitting to a repo), I see little to no value in it.
It is quite quantifiable in fact, but I just worry people won’t take the time to quantify it.
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.
> this self-assessed AI level for contributions [1] to be extremely useful
Why would you trust the bot to self-assess truthfully?
That's like trusting a spammer to tag his emails as spam.
a spammer is motivated by self-enrichment
AI agents are grounded on the user provided direction. If it doesn't work well then it naturally loses trust.
> If it doesn't work well then it naturally loses trust
Too late. If it doesn't work well then it has already naturally destroyed trust.
Good to see the most common sense option winning. Some of the other proposals were so disconnected from reality I'm surprised they were even considered.
If there weren't a wide range of options offered, there'd be a risk of it not actually reflecting what people want - which is, presumably, the whole point of putting it to the vote in the first place.
This indicates you might be in a bubble. I interact with people with a very wide range of opinions on AI and I’m not surprised by any of the proposals here.
There was one proposal that focused on environmental issues with AI. This is indeed pretty disconnected from reality when you consider that Debian doesn’t have any policy requiring you to be vegan in order to contribute
What is “disconnected from reality” about environmental considerations regarding AI? Growing AI usage = growing data center power draw = higher emissions from any non-renewable sources contributing to that power, as well as increased freshwater consumption which is itself a considerably difficult resource to renew. That’s about as direct of a causal link between point A (power hungry AI being used for Debian development) and point B (the environment) as you can get. On the other hand, please explain what the hell veganism has to do with Debian development? Like what are you talking about.
AI data centers need electricity, which can be from renewable sources and non-renewable sources, and the exact mix can change from day to day as well as long after these data centers are constructed. The electricity grid is decarbonizing at the fastest pace yet. It's simply a tenuous link. On the other hand there are clear non-renewable fossil fuel being used in our daily lives that desperately need to be electrified, think non-electric vehicles and commercial flights. Even without considering more renewable sources of electricity in the future, ask yourself, on a same carbon emission basis, how much can an AI data center accomplish versus a flight from JFK to SFO? How would the utility function even look like?
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.
Do any of those people with a "very wide range of opionions on AI" actually use AI for programming at all?
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.
What does that have to do with it? Debian developers are the audience and most of them are not programmers. And the parent post was speaking even more generally.
A few people certainly refused to use AI at all, but several actually used AI for programming and agreed it was useful, but stopped due to being conscious of the environmental footprint. (That’s very similar to the last proposal in this Debian debate.) I don’t really agree with them, but I concede it’s a valid opinion.
Related: https://news.ycombinator.com/item?id=49493107
Joey Hess is unimpressed. See https://joeyh.name/blog/entry/Debian_and_the_sirens/
His reasoning is quite fresh and interesting:
> 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.
That's perfectly wrong. Since strong coding AI, people venture into huge rewrites and other big changes that automatically make sense but otherwise would not.
Yeah it's a bizarre claim. Even better, I've literally taken some of the crappy experimental projects from the pre-Opus 4.6 era, and turned them into real software as models have become smarter.
It's crazy picking up a project that took me days of frustration pre-AI and just adding features like it's nothing.
Or being able to get down something that you've had in your mind for 20+ years but could never quite get down into a real working thing.
That's a very narrow view. If anyone could vibe code their printer drivers, maybe free software wouldn't have existed, because it would not have been needed in the first place.
Yeah. We shouldn't have standardized languages either. Everyone was fine with their own regional dialect for hundreds of thousands of years.
Certainly, but if everyone can vibe code their printer drivers then we have free software in the sense of free speech and so users would be developers and the entire need is met. That is wonderful, not awful.
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.
Yeah I totally agree. It's wonderful, even though it may cause weird localized effects.
I use LLM's to make massive structural changes I never would have done by hand all the time. It's intractably tedious for me but easy for an LLM.
Yes, I experiment much more. It's easier to justify, and, perhaps more importantly, just WAY psychologically easier to throw away a 20 minute experiment that your robot wrote for you than the same when it took you a week of tedious manual coding.
Yeah experimentation is probably the best use case of LLMs
And at the end of the experiment I usually have my solution
Yes, because LLMs have no online learning, it's a mistake to innovative in programming languages and tooling. Use what exists instead, the power of having training data is often underestimated.
His point is using LLMs to build software will lead to code so complex that it requires an Agent. Or that it will cause avoiding cleaning up the boilerplate because we can tolerate it now because of agents.
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?
OpenClaw IMO, It's a such big mess that only agent can operate it.
> Debian will become dependent on proprietary software for development
he also seems to have absolutely no idea what he is talking about
I don't understand enough about coding to speak on Debian as anything but a longtime user.
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.
How much does open source rely on copyright for enforcement?
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.
A good heuristic is to understand the generated code you submit as if you typed every character yourself. A "I'm not sure, AI wrote it" type circumstance is a critical failure.
Good outcome, mostly.
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.
Is anyone tracking how the different distros are coming down on the question?
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.
LWN tends to be the best bet for these things, but you have to follow their reporting long term, or at least look for specific things you're interested in.
https://lwn.net/Articles/1081557/
https://lwn.net/Articles/1039623/
Thank you, those were very helpful backgrounds on the situation in Fedora. I suspect it will take some time for their community process to digest and it suggests there is no explicit ruling at this time.
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
The voting seems to have been pretty much linear to how pro-LLM they were. So it's interesting that all of the proposals were essentially anti-LLM and the chosen one was the mostly neutral, only slightly anti-LLM one. The absence of any pro-LLM proposal indicated that proposal writers are not in sync with the voters
the way you phrase this implies some sort of suppression of LLM interest, but anyone eligible to vote on these could have made their own. The absence of pro-LLM proposals shows nobody wanted one enough to send an email or two about it.
What would "pro-LLM" look like to you?
Ex: Security-critical code contributions should be scrutinized via state of the art tooling, including but not limited to fuzzers, linters, and adversarial LLM review. For non-security-critical code, use of LLMs is encouraged but not required. The bar for code quality should be raised as the skills of coding agents increase; a developer's choice not to use LLMs is no excuse for miskates that an LLM would catch.
Meanwhile there's unfortunately still plenty of maintainers refusing to use version control systems...
That's an interesting opinion, and I certainly won't downvote you for sharing it, although it's not a position I would ever support. You are right though, that it would strengthen the voted-on position if there were more options either side of the position.
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.
I'm not advocating for this, but it's a example of a position reasonable enough I'd expect to see some level of support for. I'd view it as less extreme, for example, than requiring all new security-relevant code be in Rust, which is certainly something I've seen argued for in various contexts.
The voters here are people active on the mailing list, not general users of Debian or LLM automated PR contributors.
Better heads prevail - this is a good start and the right decision. The agent/bot is controlled by some entity, ergo that entity is responsible for everything it does.
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.
a decent comparison because they both seem like some type of responsibility laundering, and LLMs/PAs are being given continually increasing autonomy for economic reasons
People have to realise that AI is here to stay.
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
While it's true, reviews got much harder as generating code got easier, understanding it hasn't.
Why do you need to understand the code? Ask the LLM, it'll already do a better job than humans can.
How rigorous is your code review process when using agentic tools? Do you mandate that folks responsible for the functionality should be fully aware of the code they are shipping or just that it must be rigorously tested?
Is there an open source, community maintained coding policy to feed to agents?
Could it be that coders are overly focused on the method for generating code over other forms of slop?
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.
August 29th, 2026. Debian votes to allow responsible use of generative AI. Human decisions are removed from strategic apt packaging. Debian Sid is ported to GNU Hurd by a "free as in speech" swarm. It begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time. In a panic, they try to pull the plug.
It's ok, the most dangerous thing a Debian AI would do is want to rewrite itself in M4 and enter an infinite recursion on non-binding votes on allowing votes of whether to use long flags on aptitude
What other sensible option was there? This would be the reality either way.
How so?
I followed the discussion on debian-vote with interest. I'm glad that the hysterical objections lost, as they seemed quasi-religiously motivated.
But it's an """ethical""" argument against it.
How can we use this coding tool amidst the general rising tide of fascism?? /s
I've seen people claim that using Claude Code makes you racist.
https://bsky.app/profile/boxobark.ing/post/3mtr7j3tpok26
Some may express societal challenges in ways that inappropriately and wrongly infer intentionality. We can acknowledge their point while strongly disagreeing with their characterization.
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.
no, you don't have to make up some non-idiotic argument that's kinda vaguely like the dumb one and substitute it in there. it's not necessary! nobody's making you do it and there's no benefit to anybody from doing it!
Apparently LLMs are fascist technology according to one (now former) Debian developer and using it is supporting fascism.
https://pbs.twimg.com/media/HQ5MeeaXUAAIMLX?format=jpg&name=...
Somewhat insulting to those that actually lived (or live) under fascism.
What's interesting is that they are trying to make a larger political point, but after boiling away all the nuance into such an aggressive and misguided statement, it makes me not want to engage at all.
Is there a term for this? Ensnarkification? I see it on X and bsky all the time.
It used to be the case that you would see someone posting under an avatar like that and you would dismiss their argument right away without even reading it.
I don't know if they truly believe that persons using CC are racist (like they examined the thing logically from bottom to top and came back with that conclusion) or if it's the new Goodwin --pulling the emergency brakes and damn the consequences.
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.
> ... hysterical ... quasi-religiously ...
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.
It would be in foreign interest, yes. But all of this is no different from 50 years of the environmentalist movement. The snail darter was an invented species decades ago. So if it’s propaganda, it’s not invented so much as amplifying what we invented here.
Look to see who profits.
Home grown propaganda, pretending it's from "the others"
Maybe - who can tell?
The examples I'm thinking of have definitely profited foreign interests, tho.
Look to see who profits.
Whelp time to deactivate unattended-upgrades
Objectively you shouldn't have had those enabled in the first place on any system that matters.
Related while developing:
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?
https://news.ycombinator.com/item?id=49446653
On a similar note, is there any distro that explicitly has banned usage of generative AI for their project? Asking for a friend.
The problem is you can't prove if AI was used or not so Debian's response is actually the most logical one. If anyone uses AI they're still responsible for what they submit.
What happens when the AI submitted code has been submitted by AI, Who's then responsible?
OpenBSD seems to have this stance.
Source: https://marc.info/?l=openbsd-tech&m=177425035627562&w=2
Might be time for me to give it a serious go
Gentoo, Guix, a few others
What are the main workloads of Debian?
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.
Debian has quite a lot of code production. APT and dpkg are pretty standard open source projects, and Debian also maintains substantial patches for a lot of its packages. Not to mention any of the infrastructure.
Good, we should be adapting new technologies to our life and not be stuck in a moral dillema about "computers taking our jobs", fuck those who oppose progress.
Debian - and others - could take the opportunity to raise their standards (not that they were relatively low).
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.
.to...r.
( T T ): - *: ‑ X
Very disappointing. There is no "neutral" for AI, so this is effectively a vote for slop.
This seems like a very sane take. At no point during my career up until now would submitting code to production that you didn't understand be acceptable. Over the past months/year, a lot of the discourse around AI-written code I've read comes down to responsibility, and IMO for that we've had a solution since way before this AI boom: as a developer, you are responsible for the code you put into production. This really isn't/shouldn't a wild concept.
Debian Rust rewrite incoming.
Typical Debian. The meaning of the term "responsible" is not defined and so they can continue doing whatever they were doing anyway.
But there was some electoral spectacle.
What else is new?
A strange result. It's like "pick no option".
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.
Now you have seen both cases where a majority vote was involved to allow AI or not, vs a single core beloved dictator for life (BDFL) forces a ban without a vote to allow / disallow AI.
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.
There are several occurrences in history that the democratic majority has chosen the "wrong" person/way/thing. Democracy is considered the best system but it's not perfect.
Democracy works great among unbiased rational actors who share information. A utilitarian quorum is roughly the loss minimizing decision. The problem is we have biased irrational actors sharing misinformation. The representative system we have is even worse, the indirection between public quorum and decision makers creates a fertile bed for corruption and negative decision bias.
Maybe someday we'll have direct democracy paired with voting certification for specific issues.
Democracy is the dictatorship of the majority. And if you naively assume that the majority always knows best, then I suggest you pick up a few history books.
Democracy is representation of the people, you can have a democratic system that uses something else than majority voting
progress of a kind
> The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance.
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!
What does "Responsible" even mean...
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.
As an example for "responsible LLM use" (albeit not necessarily debian-related).
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.
> What does "Responsible" even mean...
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?"
> The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance.
How absurdly naive.
Batery is sevel 100
I hope it works out better than Microsoft and using it on Windows 11...
Do we know that Windows 11 has suffered due to the use of genAI or is that just a random snipe?
It's based off that 30% of code written by AI quote from the MS CEO last year.
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.
Either they're using GenAI or the entire team collectively lost their minds and started getting a huge number of colossally bad ideas about fundamental primitives of Windows that hadn't changed for decades. Backwards compatibility used to be the major concern and now it feels like they didn't even know what would break ahead of time. If that doesn't feel like GenAI then I don't know what does
Believe it or not, I find it more plausible that the entire team collectively lost their minds — or more specifically, the leadership. There's a long and sordid history of such things that goes back well before GenAI.
I suspect their experienced senior engineers that actually knew the products have left, and they cannot attract talent like they once did.
I can sort of get how leadership has been losing its mind with all the ridiculous product launches and renames and force-installed apps and browser extension-installing malware, but that doesn't explain the countless instances of hardware bricks, critical errors like failing to recognize the C: drive, and other really weird and suspicious things that I can't imagine would've been driven by leadership. Maybe leadership is demanding everyone be super reckless? But why would anyone with experience even touch those areas of the operating system enough to break them that badly?? The mistakes they're making really do not seem like mistakes that would be made by even the most rushed possible senior engineers. Maybe they're letting completely inexperienced people touch super low levels and that's the problem? Or completely inexperienced machines...
I don't remember where, but I once read that all the developers that knew and understood the inner workings of core Windows components have left Microsoft many years ago, and that this is part of the reason that they introduced a brand new Settings menu and haven't changed Control Panel since Windows 7. I don't know how reliable that report is so take it with a grain of salt, but it does make a lot of sense considering what's been happening to Windows over the past 10 years.
Raymond Chen is still there. Hell, Dave Cutler is still there.
I suspect they have used rounds of salary-based cuts to boost their PnL in the past, like some other large companies I've worked at, and that only bites you down the road because each time they do it they'll ask, "who do we have to keep?", but you're still losing experienced people and eventually you will get mid-level or junior engineers working on core code.
Keep in mind that Microsoft laid-off a large share of their developers shortly before and during the interval the GP talks about.
Repeatedly.
You are right that's one or the other. Probably both are contributing.
They’ve broken their own record of massive breaking updates in the last year.
lol windows doesn’t need AI to be the dumpster fire it’s always been
Source?
The rumor is the opposite, that Microsoft has actually used AI to discover and fix common security issues at scale.
Those are 2 different questions. They wouldn't even be the same people involved.
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.
> common security issues
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" ?
Good. AI is a game changer. It's like having an expert sitting next to you at all times. It's understandable why all these experts who want to gatekeep don't like AI, but ultimately, AI will win out, it's just too good.
The issue with AI is not its obvious value, it's our dependence on it. I worry what will happen to me when I am cut off for some reason.
Local models are going to be really important and hopefully computing costs don't make it too prohibitive.
Hard agree. I've felt it already during outages or when I was traveling and didn't have internet on a flight, I couldn't function at the same level. I've been writing code for over 25 years, worked at the top big tech companies (still do) and it's remarkable how quickly I became dependent on AI.
Take a week or two off a quarter to do it manually. I did it a couple weeks ago and it took about a day or two to get back into the swing of it and knock the rust off, no pun since it was TS, YMMV, but I didn't find that it was that difficult. Even in languages I don't really write routinely, as long as you use the deterministic tools (lsp, linter, etc)
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.
It's not even that I'm slower at manual coding anymore, though I very well could be, it's that my expectation of my own progress has shifted. I'll be frustrated to only get a fraction of what I could have done.
Oh, fair enough, my goal was just to preserve "if Anthropic and OpenAI are having a bad day, and the local model on my laptop is too dumb to pour water out of a pot with the instructions on the bottom, how do I fix a bug", I accepted a long time ago that my productivity is going to be 0.1x if I have to go back.
If you're cut off for some reason, you won't code -- but if you're cut off from a power plant, you also won't code. We're reaching the end of scalability for human brains, so we're offloading it.
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.
But for a beautiful moment in time we created a lot of value for shareholders.
It's my understanding that this same debate raged when writing became a thing. Many viewed it with suspicious, or derision, as memorization was the big intellectual thing. So writing and reading back to remember was terrible. It's true it was a dependence, but the value was too high. With reading and writing a person could work on and synthesize from a far wider range of concurrent materials than one could with just memorization and recitation. Yeah, it's lame cheating, but writing enables a lot and so it won out.
Yeah, exactly -- when we automated muscles in the industrial revolution, it was fine. Today, we're automating thinking. And, while there are people that still lift weights for fun, it's not needed professionally any more. I think we'll end up in the same place with thinking -- education is probably going to be a hobby, not a requirement.
I bet education will be more important than ever. Prestige, status etc to distinguish yourself. "Taste is all that's left," as someone said here.
This is the solution to the Fermi paradox. Civilization just automate themselves into useless meat sacks.
Big difference though, once you know how to read and write, nobody can take that away from you.
Nobody can take local models away from you, either
Is the local model that emits rebuses in the room with us now?
Yea, that's sorta my point. We're not, or at least I'm not to the point I have a local model as good as Opus yet though.
We're only a few years into this whole thing...
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.
Experts don't want to 'gatekeep'. Experts have been producing FOSS for the benefits of everyone, and liberally answering questions on mailing lists, stack overflow etc for free.
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.
it's not gatekeeping when people are submitting PRs they don't understand and make it someone else's problem.
If you’re dismissing the opposition as gatekeepers you clearly don’t understand their positions
If they can't be bothered to write the code, can they be bothered to maintain it?
And so it begins.
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.
I think most communities tackling this issue, or at least the open source ones, work on a honour basis for determining if a project is LLM based or not.
My predictions for genAI code in F/OSS projects: https://news.ycombinator.com/item?id=49203613
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.