A Policy on AI Coding Assistants · general

I think some might have seen this, but Tom's Hardware reported on the linux kernel policy for agents:

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

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

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

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

Pat Hickey (Apr 21 2026 at 16:37):

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

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

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

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

Stream: general

Topic: A Policy on AI Coding Assistants

Victor Adossi (Apr 13 2026 at 01:06):

Pat Hickey (Apr 13 2026 at 16:50):

Pat Hickey (Apr 13 2026 at 16:51):

Pat Hickey (Apr 13 2026 at 16:53):

Pat Hickey (Apr 13 2026 at 16:56):

Pat Hickey (Apr 13 2026 at 16:58):

Victor Adossi (Apr 13 2026 at 16:58):

Victor Adossi (Apr 13 2026 at 17:01):

guest271314 (Apr 19 2026 at 14:23):

Pat Hickey (Apr 21 2026 at 16:36):

Pat Hickey (Apr 21 2026 at 16:36):

Pat Hickey (Apr 21 2026 at 16:37):

Pat Hickey (Apr 21 2026 at 16:38):

Pat Hickey (Apr 21 2026 at 16:41):

Chris Fallin (Apr 21 2026 at 16:47):

Victor Adossi (Apr 21 2026 at 18:12):

Till Schneidereit (Apr 21 2026 at 18:18):