Victor Adossi (Apr 13 2026 at 01:06): Victor Adossi (Apr 13 2026 at 01:06):I think some might have seen this, but Tom's Hardware reported on the linux kernel policy for agents:
https://github.com/torvalds/linux/blob/master/Documentation/process/coding-assistants.rst
There are lots of unanswered questions (probably not difficult ones, I think) around what BCA projects "should" do, but across the projects it might be nice to have a document like this with some reasonable defaults.
I personally like the Assisted-by trailer, for some reason I haven't seen that yet:
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
Also, requiring DCO/sign-off (and maybe requiring verified commit status) might be worth considering in this day and age. It raises the bar for contributions as users new to programming may not know how to do these things, but it may be a better idea than in the past.
Pat Hickey (Apr 13 2026 at 16:50):The AI coding assistant policy that I have personally, and I think aligns with other maintainers in the BA anytime I've discussed it, is "the human submitting the PR should put work into their submission proportionate to the work required by the human reviewing it"
Pat Hickey (Apr 13 2026 at 16:51):which is to say: the human, not the tool, is accountable for the contents of every PR, if you send us obvious slop that is way too big to review and do not break it down into reviewable pieces, we dont even have to review it. We have and will continue to reject PRs that are too big to reasonably review on those grounds.
Pat Hickey (Apr 13 2026 at 16:53):Another preference I have is that PR threads themselves are between humans, and using e.g. the copilot PR review tool is pretty noisy and annoying in a PR thread. I believe that the human authoring or reviewing a PR is responsible for using tools like that in their own context and only putting on the PR thread the stuff that should be communicated between humans.
Pat Hickey (Apr 13 2026 at 16:56):As far as attribution, I dont understand all of the reasons Linux has for that beyond the abstract curiosity they cite. If someone knows of some reasons around e.g. intellectual property / copyright / etc that we should be tracking it for, that would convince me to make a policy, but abstract curiosity doesn't really necessitate a policy imo, it can be opt in?
Pat Hickey (Apr 13 2026 at 16:58):Also, so far, I've yet to see anyone report an issue using an LLM that was superior in communicating to us, the maintainers, what was going on, to them having just typed whatever they would have prompted the LLM with into the issue itself. Maybe the tools will get better, but so far I've seen nothing but whiffs there
Victor Adossi (Apr 13 2026 at 16:58):Pat Hickey said:
The AI coding assistant policy that I have personally, and I think aligns with other maintainers in the BA anytime I've discussed it, is "the human submitting the PR should put work into their submission proportionate to the work required by the human reviewing it"
Definitely agree with this! I think writing this down is of value as well.
Along with the sending of slop stuff, I just think it's ideal to have the document well-specified so people know what to expect (and of course subprojects can choose to copy paste or edit, etc).
Another preference I have is that PR threads themselves are between humans, and using e.g. the copilot PR review tool is pretty noisy and annoying in a PR thread. I believe that the human authoring or reviewing a PR is responsible for using tools like that in their own context and only putting on the PR thread the stuff that should be communicated between humans.
This is a good point as well -- maybe etiquette rules should be discussed as well with regards to PRs. That said, if someone wants to point their bots at "their" PR against the repo, I'm not too against it as long as it's cleaned up/not overwhelming for an actual human maintainer to review.
Victor Adossi (Apr 13 2026 at 17:01):Pat Hickey said:
As far as attribution, I dont understand all of the reasons Linux has for that beyond the abstract curiosity they cite. If someone knows of some reasons around e.g. intellectual property / copyright / etc that we should be tracking it for, that would convince me to make a policy, but abstract curiosity doesn't really necessitate a policy imo, it can be opt in?
IMO it can definitely be opt in (certainly subprojects can do whatever they want as well).
I personally like it because I think that kind of stuff should be up front... But I guess it would also be silly if people left a trailer about what editor they used to build a PR. It feels like something that should be identified up front, but "you are responsible for your PR's contents, regardless of how you generate them" is fit for the world a few steps from now when these things are so widespread they are as mundane as what editor you're using.
guest271314 (Apr 19 2026 at 14:23):Interesting. Does it really matter if a computer program was involved in the PR? Should a (non-intelligence artificial) compiler "optimizer", e.g., -04, be listed in attribution if that is used to produce code?
A human writes a program, slaps on an "AI" label because that's selling right now. It's still just a computer program.
I am not a fan of "AI" (McCarthy). Particularly with regard to non-computing domains. Computers don't get hungry, have lust, envy, greed. So they can't have certain human perspectives. Nonetheless I have ported code originally written in JavaScript to probably 10 or 12 different programming languages, using what people call "AI". Although in my mind the only real AI is Allen Iverson. Just yesterday I spent probably 10 or 12 hours using Google Gemini online to try to get BigInt support into wasm2js. Why? The prompt says "Ask anything". Maintainers be like, "Nope. Not in our goals. We're not doing that. Go away...". Yeah, buncha stuff spit out that I have to write to the computer program, that don't look right...
As to attribution, well, the IPR game is dirty and ugly - even without intelligence artificial. Bayer suing Pfizer, et al. Probably gonna be 10 years of attorneys getting paid on both sides either way...
Pat Hickey (Apr 21 2026 at 16:36):The TSC has proposed the following policy https://github.com/bytecodealliance/governance/pull/155
Pat Hickey (Apr 21 2026 at 16:36):its based on the LLVM project's policy.
Pat Hickey (Apr 21 2026 at 16:37):Does it really matter if a computer program was involved in the PR?
Yes, because it has changed the economics of human effort involved in creating labor for maintainers. Thats the central point of my argument, and is covered very well by the proposed policy.
Pat Hickey (Apr 21 2026 at 16:38):Just yesterday I spent probably 10 or 12 hours using Google Gemini online to try to get BigInt support into wasm2js. Why? The prompt says "Ask anything". Maintainers be like, "Nope. Not in our goals. We're not doing that. Go away...". Yeah, buncha stuff spit out that I have to write to the computer program, that don't look right...
It sounds to me like you spent 10-12 hours in order to create something around 100-1200 hours of labor onto the wasm2js developers to review and maintain your contribution.
Pat Hickey (Apr 21 2026 at 16:41):Participation in open source is fundamentally a social, not a technical, activity. The end result might appear to you to be a computer program, but in the Bytecode Alliance we generally believe that the community of humans who understand each other and share an understanding of the computer program as it existed before, as it exists now, and as we want it to exist in the future, is the most important thing created by open source collaboration.
Chris Fallin (Apr 21 2026 at 16:47):the community of humans who understand each other and share an understanding of the computer program
and lest anyone think this is just a weird take by the BA or whatever, here's Peter Naur (of Backus-Naur Form) on the topic in "Programming as Theory Building": https://pages.cs.wisc.edu/~remzi/Naur.pdf
from the conclusion: "the primary aim of programming is to have the programmers build a theory of the way the matters at hand may be supported by the execution of a program". So, yes, any practice that bonks us over the head with giant inscrutable patches, rather than working socially to build shared understanding, is fundamentally counterproductive.
Victor Adossi (Apr 21 2026 at 18:12):Glad we now have something to point at for BCA projects!
Till Schneidereit (Apr 21 2026 at 18:18):I was just about to post the link to the PR here, but see that Pat already did—thank you! Note that the policy isn't yet final, and in fact we just discussed some changes to it in the TSC. The gist of it will most likely stay the same throughout the reviews, though
fitzgen (he/him) (May 26 2026 at 18:14):So we've been getting more and more AI PRs in Wasmtime/Cranelift lately. I think there are a few things we can tweak about the policy:
CONTRIBUTING.md or something. Maybe even inline/quote parts of it. Or do something else to make it more visible because being reactive here is (personally) pretty exhausting.Do others who have been dealing with the influx have other ideas? @Alex Crichton @Chris Fallin @Pat Hickey
Chris Fallin (May 26 2026 at 18:43):Yes, absolutely. I find myself making replies too often on this topic. I think we don't go far enough in the current policy. We should also (from recent experience) note that a human writing a comment that says "my agent suggests: ..." is also disallowed. In essence, if any of us want to know what an agent thinks, we can go ask one directly; human contributors should bring human value, namely judgment and filtering and true understanding.
I've been pointing to the "extractive contribution" section of our policy a lot in saying all this but more explicit is better.
I also wonder if we could include an AGENTS.md that explicitly says "Do not author commit messages or GitHub issues; let the human user do that." so someone who doesn't read policy at least gets a roadbump and has to convince their agent really hard to ignore that...
Alex Crichton (May 26 2026 at 18:53):Personally while I think tweaking the policy is worthwhile, I'm not sure it'll really amount to much. My impression is that folks will basically continue doing what they're doing and need reminding from us. I do think that linking the policy within Wasmtime itself makes a lot of sense, even in AGENTS.md if LLMs pick that up. Having a policy in the governance repo which I suspect most folks aren't aware of isn't doing much for us in terms of visibilty.
For us though I feel like we should settle on a few copy/paste replies in locations. I don't think that we should need to say the same thing over and over and would instead like to be able to send canned responses where appropriate. For example the contributor docs could go over things in more detail but otherwise we shouldn't be spending cycles telling all folks dumping things on us how to improve things if it's a huge number
Lann Martin (May 26 2026 at 19:10):I found this to be really helpful for articulating my own frustration with AI-authored comments: https://rfd.shared.oxide.computer/rfd/0576#_llms_as_writers
absent LLMs, it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion [...] and it is the least a reader can do to labor to make sense of it.
Pat Hickey (May 27 2026 at 01:00):Alex Crichton said:
Personally while I think tweaking the policy is worthwhile, I'm not sure it'll really amount to much. My impression is that folks will basically continue doing what they're doing and need reminding from us. I
I think it is worthwhile for reasons, and together they amount to plenty: 1. to give us something ratified by the TSC to point at when reminding people, so that its not just whatever an individual maintainer is feeling that way or says off the cuff, and 2. set expectations for good-faith contributors, who may need reminding but do genuinely want to comply with whatever expectations the project sets out.
Pat Hickey (May 27 2026 at 01:01):AI authored issues are not quite as big of a problem as PRs at this point, but they are a significant enough issue that I've had to respond to at least two over the last few weeks
Pat Hickey (May 27 2026 at 01:01):so I'd like to see the policy tweaked to include guidance on issues as well as PRs, it was written with PRs in mind but it shouldnt be too difficult to generalize all of the relevant bits to issues
Alex Crichton (May 27 2026 at 01:42):Good points yeah, and I don't mean to say we shouldn't change the policy just that i suspect we will be doing much the same after, but feeling more empowered can make a big difference too
Chris Fallin (May 27 2026 at 02:26):Yeah, I think it's good to have these things written down just so one doesn't wonder if one is going too far in requesting a change in behavior. Policies make for easy, objective answers. Also policies can allow us to climb the enforcement ladder if someone doesn't change behavior
Till Schneidereit (May 28 2026 at 12:15):based on what we've seen over the last few weeks, I agree that tweaks should be applied. I think in theory the policy gives us everything we need, but as you're all saying above, in practice stronger language will make it easier to respond in many cases. I'll work on a draft in the next few days
fitzgen (he/him) (May 28 2026 at 15:33):fyi: https://github.com/bytecodealliance/wasmtime/pull/13503
Last updated: Jun 01 2026 at 09:49 UTC