Meeting 2026-09-22

[adamgreig]

This is the agenda for the next meeting. Please add anything you'd like to discuss below!

• Meetings: Tuesday 8pm Europe/Berlin time
• Join the Matrix chat
• IRC/Matrix logs

The REWG Code of Conduct applies.

[sgued]

AI policy update

The AI Policy that has been introduced 11 months ago seems a bit out of date today given the evolution of LLM usage over the past year.
I suggest we revisit the policy to better handle the new usages of LLMs (especially in bug reports and co-maintainers). If there appears to be an agreement I'll propose to write something to update the code of conduct.

I'll remind everyone that the last time this was discussed it went off the rails and lead to the ban of one person. Please stay respectful.

First, my observations of current interactions with regards to LLM contributions on the crates I maintain (experience from heapless and $DAYJOB)

• AI generated PRs have been pretty much useless. There haven't been many of them, I didn't want to spend much time dealing with them, @zeenix did and ended up closing all of them as far as I saw.
• AI assisted bug research has been useful. We have had multiple reports of (albeit minor) bugs being found by AI. In the case of heapless, in 4 out of 5 cases, the report itself was written by a human, even though the flaw was found with the help of AI. The one written by AI was the one most insisting to have a CVE/rustsec-advisory allocated to it (even though the risk is pretty much none).
• AI written PR descriptions/comments/PRs feel extremely rude to me. It has happened multiple times. From external contributors who tried to hide it, and from co-maintainers (who thankfully did disclose it fully). I do not want to spend time trying to read and understand something when the person behind it didn't bother understanding it themselves.

Also, the Rust project has itself adopted an LLM policy which I personally find very sane, though it is much more strict that what some members would like (based on prior discussion in the wg).

I make two propositions of updates to the policy which I would like to discuss and maybe adopt:

1. simply adopt the Rust project's LLM policy
2. Add a policy similar to CoMaps'. Generated code is ok and must be disclosed, but "All communication, that includes: commit messages, pull request messages, documentation, code comments and issues (and comments on issues/pull requests), that is intended to be read by people to understand your thoughts and work must not have been generated with AI.". As a maintainer/reviewer this is what I think is most important. A contributor respecting actually has to understand the code they're submitting. Just writing "you must understand and take responsibility for what you submit" is not enough, because as a maintainer I have zero idea of what their level of understanding of the code is if they can't explain it themselves in a PR description, even when they claim they understand it all.

[zeenix]

I'll try to participate in the meeting but in case I fail to do so, I wanted to add my thoughts:

Firstly, thanks @sgued for adding this to the agenda.

• AI generated PRs have been pretty much useless. There haven't been many of them, I didn't want to spend much time dealing with them, @zeenix did and ended up closing all of them as far as I saw.

Just to clarify, completely AI generated PRs that the "contributor" obviously didn't have any understanding of and most likely didn't use the best model and/or proper instructions, yes. However, I myself have used AI to create PRs, properly marking them as such. As you know, in fact yesterday I even used LLM to create a replacement of another LLM-generated one, that actually solves (most of) the issue at hand (rust-embedded/heapless#691).

• simply adopt the Rust project's LLM policy

That would be a pitty IMO. That policy IMO is extremely ambiguous and a complete ban on LLM usage but disguised as not being one. See the thread here regarding that. In short, I'd be completely against that FWIW.

• AI written PR descriptions/comments/PRs feel extremely rude to me.

Typically that is rude, yes when you have a wall of (mostly hard to read) extremely long text in your face, the the contributor didn't even bother to read themselves. However:

• The contributor can review the text to be good for human-consumption themselves before anyone else looks at it. If they can guarantee that it's not verbose and readable, I think it's not rude to then pass it on to other humans for reading. This is exactly like how we expect people to handle the LLM-generated code already. We can (and IMO should) most certainly have an explicit rule mandating what I wrote in the previous sentence.
• Most folks don't really add much of a description in their PRs (even, you and me @sgued) so even after the contributor has assured that the PR description is fine, if we still don't want to read it, we could also just ignore that part and only look at the code. In certain cases, you don't even need to read the description if you know what the issue being solved is and the code in the PR is simple enough.
• One can ask their LLM to be concise. We can have a rule regarding the quality and brevity of the description, in addition to the a rule regarding them having reviewed the description themselves.

One category @sgued didn't mention here, are reviews from a state-of-the-art model, that I have seen to be extremely useful. In heapless crate we have only seen a few (or just 1?) examples of these so I understand completely why it wouldn't cross someone's mind at this time. The one example I'm thinking of is here. Sure, the LLM was way too verbose here (I did appologize to @sgued about that) but what it pointed to, was a very genuine problem. Knowing how @sgued (and many other folks in our community) feels about LLMs, I came very close to just approving the PR, trusting them to know what they're doing but I'm glad I didn't do that.

There is also another aspect here: the stricter the policy, the higher the chances that we will only get pure slop (as those contributors won't bother reading and adhering to the policy) that we will have to just filter, and any rare gold burried (e.g a very important security fix) in that stream, will likely also get filtered out.

[therealprof]

Why would we get more slop with a stricter policy? We'll get the same amount but people adhering to the policy will be immediately noticeable.

[zeenix]

I'm not saying, you'll have more slop. I'm saying you'll get more slop than people using LLMs responsibly. The total amount of slop will likely remain constant (or one can hope).

[MabezDev]

I merged the update without realising there is some debate here, sorry about that! If you have any feedback please note it on the update PR: #942.

[adamgreig]

cortex-m-rt: should we adjust our default .text alignment to silence this linker warning that's soon going to be visible on stable? rust-embedded/cortex-m#678

[adamgreig]

New release of embedded-storage and embedded-storage-async 🎉