Your comment is a good one and I think does a good job of highlighting that current AI policies are drawing the boundary in a weird place.
I think the distinction many teams actually want to make is: was every line in this codebase read, understood, and accepted by a human or not?
There are valid arguments in both directions:
Codebases where the answer is “yes” mean that there is a human who is claiming some level of accountability and responsibility for the code. Not in a legal sense for most open source licenses, of course. But in a “can I trust that a person gave a shit about this?” sense. Humans bring a whole cloud of moral and social values with them and when a human accepts some code, it means we can more likely trust it in the large diffuse sense of the term “trust”.
It is more likely that the codebase will continue to be maintained in the future because people have already invested real effort into it.
Codebases where the answer is “no” can grow and add features much more rapidly. I don’t think anyone knows what the long-term maintainability of vibe-coded programs is yet, but at least short-term it seems like AI can whip up a whole lot of mostly working code really fast.
So I think really where the policy line should be drawn is at code review. Does a human review every line of code or not?
The challenge is that if you have a policy that says “yes” but don’t have a policy discouraging using AI to generate code, you will rapidly overload the reviewers. So the policy line gets drawn earlier at the point of authoring to try to avoid that. But I think then it runs into all of the problems that the parent comment here are talking about where it’s not clear if a contribution or bug report is “tainted” by AI or not.
I suspect there is another approach one could take here that is a little more mechanical about the code. Maybe have a rule that says all PRs above a certain line count are auto-rejected unless a previous design discussion with maintainers has occurred.
Of course, if you object to the use of AI on moral/ethical grounds, I also think it is valid to have a policy that outright rejects all contributions tainted with AI in any way. But I think that’s a somewhat different problem being solved than AI policies that are mostly trying to deal with not overloading human reviewers.
But I think that’s a somewhat different problem being solved than AI policies that are mostly trying to deal with not overloading human reviewers.
I don’t think it’s that clear-cut either. There are also projects that use the mechanical policies as an excuse to not have to have the ethical discussion (yet).
as an excuse to not have to have the ethical discussion (yet)
I think you’ll find, if you look closely, that the people who have major ethical concerns about LLM usage are a vocal minority and that many projects and communities won’t be having that discussion because they don’t believe a problem worth discussing actually exists.
I’ve been digging quite a bit into how different major projects and communities have come to the conclusions they’ve come to so far and there are very stark differences there. There also seems to be a pretty interesting split with respect to whether project leadership themselves have any interest in hearing or engaging with the perspectives of non-contributors.
That’s the really interesting part for me, to be honest: how clustered it is. It comes as no surprise to me that the Rust community has that big of a response to it. I say this neutrally: from an outsider that has used a number of different languages and ecosystems, the Rust community seems markedly different in their mixing of software development and social causes. Rust is a cool but small pocket in the overall software development landscape.
I’ve also looked at the minutes from some significant open source foundations’ board meetings on the topic that looked about 15 minutes long. Often one board member would raise some kind of concern (environmental, provenance, etc) and not argue too hard for it. Policy agreed to (most popular: humans take responsibility of the code, don’t submit vibecode or machine-authored PRs). Done.
And some did have quite thoughtful discussions that ultimately went one way or another. I don’t have numbers for active developers for a bunch of different languages and projects. I’d be happy to see good numbers either way.
I say this neutrally: from an outsider that has used a number of different languages and ecosystems, the Rust community seems markedly different in their mixing of software development and social causes.
To understand your message better, what makes Rust “markedly different” here, specifically?
I don’t mean it in any kind of derogatory way if that’s what you’re asking. The community itself is quite new compared to, say, the C++ community and baked a lot of values and governance into the project very early on. The fact that they do surveys like https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/ and explicitly include metrics on different marginalized groups speaks to the fact that their objective isn’t just “make a memory-safe programming language” but to include community, inclusivity, and ethics into the core of the organization.
Other large projects are starting to do that too, but it’s usually more of a bolt-on / slow shift affair rather than having baked those values into the core from the beginning.
Your comment is a good one and I think does a good job of highlighting that current AI policies are drawing the boundary in a weird place.
I think the distinction many teams actually want to make is: was every line in this codebase read, understood, and accepted by a human or not?
There are valid arguments in both directions:
Codebases where the answer is “yes” mean that there is a human who is claiming some level of accountability and responsibility for the code. Not in a legal sense for most open source licenses, of course. But in a “can I trust that a person gave a shit about this?” sense. Humans bring a whole cloud of moral and social values with them and when a human accepts some code, it means we can more likely trust it in the large diffuse sense of the term “trust”.
It is more likely that the codebase will continue to be maintained in the future because people have already invested real effort into it.
Codebases where the answer is “no” can grow and add features much more rapidly. I don’t think anyone knows what the long-term maintainability of vibe-coded programs is yet, but at least short-term it seems like AI can whip up a whole lot of mostly working code really fast.
So I think really where the policy line should be drawn is at code review. Does a human review every line of code or not?
The challenge is that if you have a policy that says “yes” but don’t have a policy discouraging using AI to generate code, you will rapidly overload the reviewers. So the policy line gets drawn earlier at the point of authoring to try to avoid that. But I think then it runs into all of the problems that the parent comment here are talking about where it’s not clear if a contribution or bug report is “tainted” by AI or not.
I suspect there is another approach one could take here that is a little more mechanical about the code. Maybe have a rule that says all PRs above a certain line count are auto-rejected unless a previous design discussion with maintainers has occurred.
Of course, if you object to the use of AI on moral/ethical grounds, I also think it is valid to have a policy that outright rejects all contributions tainted with AI in any way. But I think that’s a somewhat different problem being solved than AI policies that are mostly trying to deal with not overloading human reviewers.
score 2 · canonical
I don’t think it’s that clear-cut either. There are also projects that use the mechanical policies as an excuse to not have to have the ethical discussion (yet).
score 1 · canonical
I think you’ll find, if you look closely, that the people who have major ethical concerns about LLM usage are a vocal minority and that many projects and communities won’t be having that discussion because they don’t believe a problem worth discussing actually exists.
I’ve been digging quite a bit into how different major projects and communities have come to the conclusions they’ve come to so far and there are very stark differences there. There also seems to be a pretty interesting split with respect to whether project leadership themselves have any interest in hearing or engaging with the perspectives of non-contributors.
score 1 · canonical
What’s your basis for thinking people with ethical concerns are a vocal minority? As one data point, when Rust project members were solicited for feedback, around half of them brought up ethical and environmental concerns.
score 1 · canonical
That’s the really interesting part for me, to be honest: how clustered it is. It comes as no surprise to me that the Rust community has that big of a response to it. I say this neutrally: from an outsider that has used a number of different languages and ecosystems, the Rust community seems markedly different in their mixing of software development and social causes. Rust is a cool but small pocket in the overall software development landscape.
I’ve also looked at the minutes from some significant open source foundations’ board meetings on the topic that looked about 15 minutes long. Often one board member would raise some kind of concern (environmental, provenance, etc) and not argue too hard for it. Policy agreed to (most popular: humans take responsibility of the code, don’t submit vibecode or machine-authored PRs). Done.
And some did have quite thoughtful discussions that ultimately went one way or another. I don’t have numbers for active developers for a bunch of different languages and projects. I’d be happy to see good numbers either way.
score 1 · canonical
To understand your message better, what makes Rust “markedly different” here, specifically?
score 1 · canonical
I don’t mean it in any kind of derogatory way if that’s what you’re asking. The community itself is quite new compared to, say, the C++ community and baked a lot of values and governance into the project very early on. The fact that they do surveys like https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/ and explicitly include metrics on different marginalized groups speaks to the fact that their objective isn’t just “make a memory-safe programming language” but to include community, inclusivity, and ethics into the core of the organization.
Other large projects are starting to do that too, but it’s usually more of a bolt-on / slow shift affair rather than having baked those values into the core from the beginning.
score 1 · canonical