hiya! this is my first post here. I’d like to start a discussion about contributor responsibility and review cost in the context of AI-assisted code generation
There have been periodic discussions about whether Rust should regulate or restrict AI-assisted contributions. I want to argue that this framing is both unenforceable and unnecessary
It is not possible to reliably determine whether a contribution was generated by a human, an AI, or a mixture of tools. Attempting to regulate usage rather than outcomes incentivizes superficial compliance and does not scale.
Instead, I propose that Rust explicitly treat review cost and contributor responsibility as first-class concerns:
Contributors are fully responsible for the correctness, safety, licensing, and maintainability of any code they submit, regardless of tooling used.
All contributions must be human-readable and explainable by the submitter.
Review time is a limited resource; submissions that impose excessive review cost may be rejected on that basis alone.
Repeatedly submitting low-signal or high-cost changes should lead to escalating consequences.
This mirrors long-standing open-source norms: tools do not submit patches, people do. If a contributor cannot justify or maintain generated output, that output does not belong in the project.
This approach avoids unenforceable tool policing while preserving Rust’s standards for correctness and long-term maintainability.
I’m interested in feedback on whether this framing would be a useful clarification of existing norms, and whether it should eventually be formalized as contribution guidance or policy.
I think "unenforceable" is total nonsense. Yes, determining whether something was generated by an LLM with 100% accuracy is impossible. So is determining whether somebody has the copyright to code they are submitting. That doesn't mean it's impossible or a bad idea to have a policy about use of LLMs. Or copyright laws. (I think a lot of copyright laws are bad, but that's beside the point)
That’s fair, imperfect enforceability alone doesn’t make a policy meaningless. Copyright is a good example of that.
The distinction I’m trying to draw is about what layer the policy targets. Copyright regulates the legal status of submitted artifacts; LLM-usage rules would regulate the process used to produce them.
My concern isn’t detectability per se, but that process-based rules shift review focus toward inferring tool usage rather than evaluating observable properties like correctness, readability, and maintainability. That’s why I think responsibility and review cost are a better enforcement surface.
In general I agree. The concerns you list are rather obvious.
However, I've found the specifics of them to be tricky.
The size of the change preferred by the reviewer is hard to guess.
Obviously nobody wants to look at a huge sudden rewrite, but it's also hard to guess how small the change should be:
some reviewers like tiny changes, the smaller the better. 1 line is great - gets LGTM, merge, done in 3 minutes and everyone moves onto the next incremental change. OTOH some reviewers have very specific preferences how things are supposed to be done, how PRs should be structured, which creates a high "constant overhead" to their reviews. When something isn't perfect, it creates a back-and-forth discussion, PR updates, etc. For a 1-line change it ends up being absurdly inefficient use of everyone's time.
when I change something, I usually want to refactor the codebase first to make the change simpler/cleaner afterwards. For example, instead of adding nearly-duplicate code, I first extract common code into helpers. Or if new feature makes something fallible, I'll need error handling plumbing in the code around it. The problem is that the groundwork often doesn't make sense as a standalone PR. The motivation for changes is unclear without the addition that follows. If I just submit the groundwork, it gets rejected as a pointless change for the sake of change. However, if I submit refactorings plus a new feature together, I often get told off for changing unnecessary stuff at the same time, and not splitting PRs into small enough pieces. This motivates making changes minimal in the number of lines changed in the diff. A hard PR review process can systematically incentivise such workaround for too-busy reviewers, but over time it makes the codebase a pile of bland structureless repetitive code. The more it happens, the harder it is to fix it in a PR – reviewers really don't like large changes that touch many files, but you can't clean up architecture one small PR at a time without each PR looking like it makes things less consistent.
Yes, this matches my experience as well. The core difficulty isn’t PR size per se, but that contributors are implicitly optimizing against reviewer-specific preferences and review overhead.
Preparatory refactors are a good example: taken alone they often look unjustified, but combined with a feature they look too large. Optimizing strictly for minimal diffs can reduce short-term review friction, but over time it incentivizes duplication and makes architectural cleanup increasingly expensive.
I don’t think there’s a simple rule that resolves this; which is partly why I’m more interested in making these trade-offs explicit rather than trying to encode them as hard guidelines.
This is where I wish GitHub had better handling of commit-by-commit review. I similarly most of the time do two-commit reviews where the first refactors and the second implements.
and the vibe coders will remove it in order for the LLM to work on the repo and ofc they are dumb enough to just forget about it, but then it gets recorded in the PR, so it will be then easier for the maintainers also to figure out if its AI coded or not
(i might be just very crazy and dumb right now but i will test it in my repos first and get the reports)
I tend to do this by having one PR with multiple commits, and explicitly saying in the PR description "this is best reviewed commit-by-commit, rather than all at once".
I do wish, though, that forges like github had better support for sending multiple PRs with interdependencies. And I especially wish that you could comment on individual commits and make suggestions there rather than only on the complete diff.
Sorry if this is obvious and I misinterpreted your wish, but GitHub does support per-commit review. You can either view the individual commit via the Commits tab and add comments there, or you can choose commit ranges in the Files changed view using the commit filter list in the top left (you end up in the same view with both ways):
It can be a bit painful to map which comment went where only from the review overview, so it's sometimes best to also read comments per-commit. Frankly, I don't know why one would split changes into multiple PRs that make no sense to merge individually. I think individual, self-contained commits in a single PR are a clean and convenient way to organize changesets.
suggestion-fenced blocks manually when reviewing commit-by-commit, and they render fine. Why do they hide the button from the comment editor if doing that, I don't know.
In practice the same way they already are today: through reviewer judgment, reputation, and access control over time.
“Accountability” here doesn’t mean legal liability; it means that a GitHub identity accrues trust (or loses it) based on the quality and maintainability of past contributions. Review scrutiny, rejection, loss of reviewer goodwill, and eventually restricted access are the existing mechanisms.
The statement is meant to make that implicit reality explicit, not to introduce a new enforcement model.
If you press apply for such a suggestion it is appended at the end of the commit stack, not applied to the specific commit for which the suggestion is.
