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.
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.
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.
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,
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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 refuse to 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.
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.
Googling the name shows a 2021 podcast thing stating something about leaving the project.
I did not bother checking anything about this person or that timeline, but if true, then them continuing to be unhappy with the steering of the project doesn't exactly come as a surprise.
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.
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
> 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.
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.
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.
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.
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.
Meh, I don't think so. They have no way to ascertain what tools were used to write a piece of code. A reasonable solution is to simply hold all code and its contributors to the same standards as before. At Debian's scale, "no LLMs" is really not enforceable; whereas "no shit code" and "no incompetent maintenance" are pragmatic policies they already enforce
Doing the opposite (disallowing AI), will place it on a path of getting riddled with security issues.
When attackers are using AI to both find vulnerabilities and build exploits faster than Debian can figure out how to patch the project without AI, you are saying Debian should not move quicker to fix these issues?
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.
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" ?
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.
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,
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.
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 used to care, a lot. And I still do.
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.
And I've seen exactly this across multiple large and small organizations in multiple countries.
This is quite distinct from enjoyment.
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.
Yes. Very notably: https://ziglang.org/code-of-conduct/
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.
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.
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.
Had someone at $DAYJOB just shrug and say Claude messed up when I pointed out a sql injection in the code in their PR.
It became explicit policy at the company after that moment that blaming the AI is not an excuse for shoddy work.
It kind of is if the company mandates LLM use.
It is sort of sad that now programmers are suddenly expected to be perfect reviewers of code they didn't write.
When you ask others that use AI frequently, the responsibility and understanding on what the agent wrote does not go away. You need to know what you are doing.
As soon as attackers are also using AI against your project, you have no choice but to use AI to protect yourself.
You’re also responsibility not to write crap PRs.
Sure there is. Contributing to open source is a privilege, not a right. Abuse it, and find yourself unwelcome as a future contributor
When I am at home practicing my musical instrument or learning to paint, those aren’t paid activities, so I can’t demand high standards for myself.
When Habitat for Humanity is looking for volunteers to do electrical and plumbing on homes, they have to allow unlicensed random folks do it.
This is not how life works at all.
The whole voting mechanism just exists as an elaborate dance that makes everyone keep their face, while the only sensible option wins.
A bureaucratic tarpit for bad ideas and emotions.
In a better world, none of this would be necessary, but we live in this world, and for that one, it's nice that someone engineered the system that way. Good job.
I did not bother checking anything about this person or that timeline, but if true, then them continuing to be unhappy with the steering of the project doesn't exactly come as a surprise.
How absurdly naive.
https://bsky.app/profile/boxobark.ing/post/3mtr7j3tpok26
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.
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.
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.
When attackers are using AI to both find vulnerabilities and build exploits faster than Debian can figure out how to patch the project without AI, you are saying Debian should not move quicker to fix these issues?
This will turn to shit because laziness will take over and comprehension will fall as a consequence of that. Junior will "contribute" and the seniors will eventually become too lazy to care. What's next... vibecoding airline ADA code. Save me lord jesus christ.
While doomscrolling HN right now, I have an agent crunching away at figuring out how to build a flashable TWRP ZIP file, because I could not care less about such android specifics.
Such use-cases would be blanket banned by some of the harsher options, forcing people to do stuff they have no interest in doing, for reasons that are at best well-meaning.
Which, in something volunteer-driven, is not necessarily a good idea, because if you're not allowed to do the work in the way you'd like to, you might just stop doing it altogether.
That said, if your work ends up shit, you still shall get shat on. Simple as that.
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.
Repeatedly.
You are right that's one or the other. Probably both are contributing.
The rumor is the opposite, that Microsoft has actually used AI to discover and fix common security issues at scale.
Your appsec engineers will be the ones bug hunting with Mythos or whatever. Your regular engineers will be the ones implementing features. If the feature is a bad design and functions badly as a result, that is entirely orthogonal to whether it contains coding errors or bugs.
Also, there are bugs on the integration side that won't be caught running Mythos against source code, because it's not a source code issue. Even using Mythos for DAST is going to be very limited compared to how actual users will move through something as complex as a 'mature' OS like Windows.
the entire industry is experiencing this as model capacity increases. How does "all projects get critical security fixes now" relate to "crap apps and loopy services by literally millions of lines of slop code" ?
I don't believe they had a choice though, sticking to hand written code would be backwards and eventually meaningless as people would just submit generated code as "handwritten", the coding models are quickly becoming capable enough for this.
I wonder what it means copyright wise though. To what degree is the code even copyrightable if it's entirely generated, even if you review and provide feedback.
1. Companies will revert to closed-source and cease contributions to F/OSS projects. Their legal team will advise them that trade secrets are the only way to protect LLM-generated code.
2. Contributors to F/OSS projects, and developers who run them, will falsely claim authorship of the code written by LLMs.