277 comments

[ 0.26 ms ] story [ 36.4 ms ] thread
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?
They’ve broken their own record of massive breaking updates in the last year.
Apologies for not replying to you right away. I intended to follow up but HN wouldn't let me because my account is too new. No, it wasn't a random snipe. I used Windows extensively from 95-Vista and Win 10 for work. In my person user experience W11 is bafflingly bad, and the MS team are making design choices that honestly make me feel like Windows ME was doing more right in that area.

Now the argument that genAI is helping them find and fix bugs faster has a lot of merit because it can be pretty darn good at that. But for lack of a better phrase, 'The Windows 11 Experience' feels, as other users pointed out too, either vibe coded or like the dev teams went insane. I live and die by Debian in my servers and I really hope the same kind of thing doesn't happen to them.

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.

I followed the discussion on debian-vote with interest. I'm glad that the hysterical objections lost, as they seemed quasi-religiously motivated.
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.
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.
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.

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.

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.
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.
What stops them from submitting PRs from another account?
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 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.
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

> arguing that it’s possible to make them by hand isn’t just missing the point; it’s missing the entire discussion

>> Before they were not able to spam large PRs

I was replying to someone insinuating that there was something I might have missed.

Interjecting about the topical article, is a derail of this thread for some reason that is personal to you. Good luck with whatever.

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.

Reputation, or lack thereof.

Proof of authority, essentially.

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.

What is a good project for a human to get human mentorship? Asking for a friend :)
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 work on OpenStack, which is a project folks work on primarily due to sponsorship -- not many people who want to do security/stability work for a cloud "for the fun of it" :D.

So mentees I've worked with have usually come as part of a program, such as MLH[1] or Outreachy[2]. Other projects I've helped with mentoring have come from college programs or professors[3].

I have no idea how hard it is to get through the filters to get these opportunities; I know generally we ask them to only send us the best and that's worked out really well.

[1] https://www.youtube.com/watch?v=fbsI8l-MaFA is an interview done on my podcast (by the other host, Tabatha) with CID, who works with me on OpenStack Ironic. A little over 2 years ago, he was an MLH fellow (https://fellowship.mlh.com/) working with me -- now he's a maintainer on OpenStack and working on my team. This is an exceptional outcome, but he's not the only person who has found success via MLH that I know.

[2] e.g. https://lists.openstack.org/archives/list/openstack-discuss@...

[3] https://lists.openstack.org/archives/list/openstack-discuss@...

ngl this is just gatekeeping. Tons of people can now create software for themselves and others who couldn’t do so before. I get it that some established projects have a way of doing things and don’t want to change and to some extent that is their prerogative, but casting moral judgement on the entire field of coding agents based on that is just icky.
Most people who wrote software before AI didn’t contribute to projects like Debian because it takes a certain passion and commitment. Just being able to write code is not the bar for entrance here.
> ngl this is just gatekeeping

Gatekeeping serves a useful purpose in any functioning organization of all scales, from a community center to a country, from an open source project to a Fortune 500.

The issue at hand isn’t people using AI to make some app that they and their mom will use. That’s awesome.

It’s people who insist that potentially millions of other people should be affected by their vibe-coded stuff too, by upstreaming it into Debian.

I vibe coded some simple things for the family myself, but I don’t expect or require anyone else to want or use it.

I don't care if a project uses AI or not, but I absolutely do care that they are firmly gatekept in alignment with their vision and team dynamics. Then I can choose projects whose gatekeeping policies I agree with.

There is never not an alternative to something, and I can always have my AI botch together my own version if I think this is going to get me better results.

> ngl this is just gatekeeping

As a beneficiary of Debian, this is good, your words are praise by feint damnation. I wish Debian had done more gatekeeping in the past on specific components.

Did you intentionally write that like an AI as a joke?
I'd be impressed by an AI that can go against tons of training data by reversing the polarity of a common turn-of-phrase.

I was proud of that, and am slightly bummed to hear someone thinks it sounds AI-like. Also, I had a typo, its supposed to be "faint" (light) not "feint" (fake-out), though the latter worked out in context, and works by adding a homonym layer to the turn of phrase already turned on its head. 2 layers of smug, conceited cleverness - or 1 layer and a typo if you're not feeling charitable - that gets in the way of clear communication seems very human to me, YMMV.

Gatekeeping is good, actually. Not keeping your gate is how your town gets overrun by Mongols.
Ah, "icky gatekeeping." I'm convinced.
"Nothing" is not accurate in the context of Debian as per comments above; it's not like Github in that sense.
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

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
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.

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.
Presumably they are trying to farm karma / reputation, which (I think, mostly) doesn't work if they need to switch accounts all the time.
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.

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'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.

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.

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?
people would use LLMS for those summaries, defeating the purpose. You can already see it in PRs in companies where LLM code is pushed.
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.

A colleague once setup a PR description template that asked for short sections like:

- Why is this change needed (big picture)

- Why are you doing it this way (small picture)

- What are the trade-offs you made for this approach

- How do you know this is correct, that it works the way you think it does?

- What other changes or approaches does committing to this way block in the future?

etc. If you had actually thought through what you were doing, it was a few min to fill it all out. People were just on auto-pilot really struggled.

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.
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.
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.

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?

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?
Maybe it is for people who have written code all their lives, but as someone who started with reading code and has read far more code than I’ve ever written, reading code is WAY easier for me.
If you have little experience writing code, do you know that you actually understand what you’re reading though?

For example could you reproduce the code you read immediately after writing it?

It’s very easy to “read code” if you’re just reading for surface level understanding.

If it's easier for you to convert written code into mental models than the other way around, you are either a incredible smart and skilled person and a good programmer and should be able to convert that into a job and money easily, or you can't really write code at all.
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…
> 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?

The problem is writing such an essay takes magnitudes more of an effort for people who are not native English (or whatever the language is in which discussions are done about the project) speakers.

Also, relatedly, essays written by non-native English speakers often get considered to be AI-written by common AI detection systems, even though no AI was involved when writing them; see for example

> I'm Kenyan. I Don't Write Like ChatGPT. ChatGPT Writes Like Me.

> https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li...

I’m as skeptical of the AI writing detection as anyone else, but I’ve been trying to beat Pangram v4 for the last week and it’s essentially impossible.
Have you tried in both directions though? You need to test both sensitivity and specificity.
Yes. It’s scarily accurate.

They have a blog post on it if you look up “Pangram v4 System Card“

> 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).

Anecdotally, as someone who's been starting to get more and more agent-only/driven PRs, a good amount of the time it's by an account with little to no activity until one day they suddenly start doing 50-100+ PRs a _day_ on entirely unrelated projects... you can kind of guess what they're doing.

As for motive, it probably varies, though some will loudly put that they're some agent manager or something with lots of contributions, so you can guess their motivations there.

In other cases, these are instrad brand-new accounts which is a related but I guess slightly different story... not gonna say these are spam bot accounts being juiced with fake activity but well...

These are all fair observations, I have not personally come across these yet but I am also not looking for them. I guess someone more involved in open source collaboration would have a better lens here.
It's not winning. If I saw someone that did this I wouldn't want to hire them.

The market for juniors is complete garbage right now. The only thing they can do is open-source work and that's common advice because jobs still look at these line items.

If interviewers/jobs checked your GitHub for this behaviour the issue would go away.

If you are independently critiquing the thought process of your agent and going beyond a reviewer's comments, I want to work with you. If you're replying "that's absolutely right!" and dump more slop, I'm grateful you've publicly shown that you struggle to collaborate on GitHub.

It doesn't help with the additional work/chores, at least initially, but someone on HN had a really good idea IMO, just take the code, and close the PR.

https://news.ycombinator.com/item?id=49474708

I saw the argument that if OS maintainers "really care" about their projects, they would accept valid contributions regardless origin. Well, turn it around: if you really care so much about contributing, if you really just wanna HeLP, you don't need the credit. The warm fuzzy feeling that your contribution ended up being used should be enough.

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.
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?”

I don't think that's being mean at all, and it's valid.

Yes that's literally why I asked it. Simple questions, here, regularly elicit long form explanations. I was interested in this topic and have no experience. So I thought I'd try a broad overview type question to see if I could learn something today.

I think I read it as a bit more flippant than you meant it because it was worded assuming the answer was yes.
> 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

Even before automation, most first time PRs were a negative time contribution to the project. The only value of them was that some contributors would become trusted project members.
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.

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.

(comment deleted)
I've seen it. Walls of text with stereotypically worded non-summaries that just repeat all of the code in words, mutating values all over the place instead of the obvious canonical one place that touches related values...

Yeah you can use LLMs, but don't let me notice it from the quality of the output.

I've noticed that LLMs seem to be especially bad at things relating to space, position and movement. I guess they have to synthesize that part of human intelligence entirely, it's not in the words.

Give https://pyor.review a shot if you’re struggling with PR reviews on github.
Or, the SaaS-less approach, if a issue description is too messy/long, close it with "Please reopen with proper and concise description focusing on the issue" then lock it. Eventually people catch up and stop with the slop, just like in real life.

But you have to be able to say "No ...", rather than just slapping another subscription on top of an already broken workflow.

If you're maintaining OSS, that's understandable, and you're free to say no, but in the corporate world, that's not realistic, AI is here to stay, if they don't harness it they would just be left behind. even if the AI gets good and stops writing sloppy stuff, it's still gonna write a lot of stuff, and you're gonna review it anyway, and take responsibility and ownership, and it's still gonna take you more time, because the bottleneck is now reviewing and understanding the code.

I agree that the workflow is broken, but only on the reviewing side, AI is a tool we use to make products just like any other we used in the past, punch cards, machine code, assembly, ...etc. AI is just the new tool that sits on top of the code as the next level, no one codes with punch cards, no one writes machine code anymore, we used to write the compiled language and don't care about how it's compiled or turned into machine code, same with AI, although it's not there yet and still requires babysitting by engineers, but that's our new job now, and we need to learn how to use it and make our lifes easier.

> but in the corporate world

Sure, but that's irrelevant when someone says "I'm an OSS maintainer" and the context is explicitly about reviewing code submitted by others in a FOSS context, where you can say "No" and don't need any SaaS in order to do so.

That's not true at all of the corporate world. If your team is mass producing slop and you don't have processes in place to get it under control, you've got a big problem on your hand.

If any engineer sent me a 20,000 line refactor I'd immediately reject it and tell them to go back and start making changes incrementally at minimum. More likely I'd force them to have a whole design discussion with the team to make sure that what they are doing even makes sense.

What happens if they push out slop that significantly increases your infrastructure costs? What happens if they push out slop that significantly increases the number of bugs or outages? What happens if they push out slop that has no observational metrics, dashboards, or tooling?

In every case you push back on the team and make them fix their shit. I don't care if they are using LLMs or not. They are responsible for their work being sufficient quality. If they aren't meeting those standards, then they need to step it up.

I don't disagree with you on this, I worked my whole life in corporate and haven't worked as a OSS maintainer before, though I will _and already did_ reject PRs way less than that, I speak for myself and my team here and it's unrealistic to ship a single PR as complex as this, we usually plan features as tech designs with PRs of no more than 500 LOC, but that doesn't mean we could never have a 20k PR at all. in my experience, those huge PRs are usually the simple ones where most of it is just noise. I did one recently and moved the UI library in one of our old codebases three major versions up to the very latest, although it was 20k lines of changes, all of it is just mechanical chanes, renames, codemod stuff, test fixes, snapshot updates, ...etc. and it's not realistc to split this into multiple smaller PRs as this can bring other complications like having multiple versions of the same UI library in the codebase, which could cause more problems than it fixes, AI helps with that kinda work a lot and I would've never been able to do this migration is such a short time without it. despite that, reviewing it was a UI challenge, not code, with UI libraries, the breaking changes are usually in the UI so you can't see it from the code, and we did have a special process to review it, although on the code side, Github was a nightmare to deal with reviewing this PR, we noticed that github was the bottleneck here since it lays out the code changes without much context and is already hard to navigate and stuggles with huge PRs, the review surface and the developer experince on github was horrible, and that's why I suggested you look for better alternatives, there are a lot out there and all of them are free for OSS so why not try them?
How do you handle them? I'm not facing this problem as the team I work with is very senior and have good taste and discipline. But I can imagine it will be a problem at some point, and I frequently have to personally tell Claude to rewrite it's vomit in English. That's probably step one for people submitting poorly written PRs, reject them until they are written clearly and concisely. And if they are too big, also rejecting them and telling them to go back to the drawing board and submit smaller more focused change. But I'm not int his position so I'm taking an educated guess.
Not enough. We must kill he who made the mistake.

DEATH to anyone who makes a mistake!

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 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.

> 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.
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

Feels like those kinds of terms are moot in the big picture. Could they enforce it? Perhaps they can if a significant amount of the data produced is their IP, but who would they enforce it against? Consumers? Not much to be gained by going after them.

I can only think that they are hoping businesses might use the free plan and that they can sell them paid plans as part of an enforcement effort, but it doesn't seem like a very sustainable approach given the industry standard is to not claim ownership.

(comment deleted)
> 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) actual 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

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.

Coca-Cola literally shares their idea in every bottle they sell. The recipe being locked up in some super secure vault is a marketing gimmick and and has not relevance on anyone else being able to create clones of their drinks.
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.

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.

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.

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)

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.
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
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.
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.
This should be the policy anyway, everywhere.
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.

What a fucked up reality when you need to point out that code contributor is responsible for their code.
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.
https://git.erbosoft.com/amy/amsterdam/raw/branch/main/CODE-...
Using LLMs is basically rolling a huge number of weighted dice.
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

(comment deleted)
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.
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.
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.

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.

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.

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.
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 generally than just them.
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.

The water usage from AI is so comparatively low that it doesn’t matter.

This is where the vegan point comes in. Do you eat meat? Congratulations, you consume 1000x more water than a dozen vegan vibecoders pumping out slop 24/7.

It’s good to be environmentally conscious, but big picture here. There are reasonable ways to reduce your water and electricity consumption. Not using AI is just not one of them. There are dozens of low hanging fruit before that. The most obvious is reducing your meat consumption. You can switch to LED bulbs if you haven’t already. Shower with warm, instead of hot, water. Buy second hand clothing or furniture. Etc.

Have you considered how many data centers used the Linux kernel before anybody knew what a Chat GPT is? Does the project get a free pass on such activities?
You mean the most effective way to enact social and political change is not to stand next to someone at the urinal and tell them you are a vegan?
Bad decision, bad voting, bad move.

This will poison Debian. People will deny it now, but it's been placed on a path of death.

This combination of username and opinion are very confusing.
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
Sadly, Debian was already diseased. This is merely another symptom.
This is HN you will be voted to death by the local for talking against the AI or the last tech invention.
Good thing votes don't matter but the mob continues to be full of real idiots.
Votes unfortunately do matter in the sense that few people will see a [dead] comment like ggp.
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?

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
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
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.

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.

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.
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.

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.
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.

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.
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.
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.
I would say it's a mixed bag. On the one hand, yes, you can experiment with big changes much more easily, but on the other hand, you can have cruft build up in a big way if you're not actively looking for it and trying to cut it back.

In Debian, often the barrier to change is one or two people actively disagreeing with a change who are in a position to block it through their own action or inaction, so just being able to do more work on the change yourself is not necessarily going to make it easier to change things.

> Debian will become dependent on proprietary software for development

he also seems to have absolutely no idea what he is talking about

If they can't be bothered to write the code, can they be bothered to maintain it?
What other sensible option was there? This would be the reality either way.
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.
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 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.

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.

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.
If you’re dismissing the opposition as gatekeepers you clearly don’t understand their positions
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.

Yeah but only those experts could do that. Now average people can do what experts were doing, and the experts don't like that. They want to be unique. Same concept as "I knew that song before it was popular on the radio"
it's not gatekeeping when people are submitting PRs they don't understand and make it someone else's problem.
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?
Whoever controls the AI, as per the article we're discussing.

Debian isn't a free-for-all, they don't accept fly-by-night contributions, there needs to be a real and serious person behind every contribution.

Folk get's lazy, it'll will only be a matter of time. Ai controlling Ai.
Not being able to always prove that something wasn't done isn't a good argument no to make it clear that doing something you find unacceptable is in fact not acceptable.
I will take a guess and say every systemd-less one
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
Whelp time to deactivate unattended-upgrades
Objectively you shouldn't have had those enabled in the first place on any system that matters.
Perfectly fine for personal servers that matter. Its better IMO to risk having a rare breakage than to stay behind security upgrades.