Hi Kevin, Thanks for your comments!
I guess that register definitions would be auto-complete in the scenario you mentioned. Although those things are quite sensitive, so I would say they're better copy-pasted from the datasheet. Regardless, I don't think they would fall outside auto-complete in this policy. I think "substantial" might be better thought of in the sense of logic. Register definitions are large part of a driver in terms of characters/LOC maybe, but not really in terms of logic (they are just constants). > But when is a code considered a substantial piece of code generated by AI? This is pretty subjective and I don't think we can even attempt to define it in a policy. This is why the policy mentions menial tasks for AI assistance, which excludes core logic. Ultimately we can't nail down every single use-case in the policy. It is just a tool that lets us warn contributors in advance and gives us some ability to moderate AI generated submissions. The Apache Foundation has some guidelines about this: https://www.apache.org/legal/generative-tooling.html#include-in-contributions We cannot copyright any generated output ever, and human reviewers need to guarantee that their output is compatible with our open source licensing. This is an impossible task, since it's been show many times (i.e. [1]) that LLM output can contain verbatim copies of text in its training corpus. So unless we can verify that the output doesn't contain anything not compatible (i.e. snippets of the Linux source) externally (which we cannot), the only surefire way to make sure something is compatible and copyrightable is if it is human-written. Obviously that kind of thing wouldn't apply to register definitions, because there are only so many ways to do `#define REG_STATUS 0x01` for instance. > the user must review and understand everything they have written and generated I agree, especially in the case of AI-assistance. However, using AI for substantial code chunks still has the aforementioned license compatibility issues. I may be able to review and understand the Linux source code, but I have no right to submit snippets of it to NuttX under Apache 2.0 (unknowingly or not). This is why it's a slippery slope to allow AI use generating substantial logic, and why I think our stance should still be to restrict it to menial tasks (see raiden's recent re-formatting of the STM32 ports; that is a legitimate and helpful use). Best, Matteo [1]: https://arxiv.org/abs/2601.02671 On Wed, Jul 1, 2026 at 12:08 PM Kevin Witteveen <[email protected]> wrote: > Hi all, > > I'd like to add an embedded C relevant perspective to this. > > *"No use of AI to generate substantial pieces of code"* > During the development of peripheral drivers, often you have to write > hundreds of register addresses and access code. > Usually I hand write the foundation, the most critical code, but all the > heavy boilerplate and repetition of accessing hundreds of register > addresses are generated by AI. > Also *fully* reviewed and tested by a human. > To me this feels more like a tool / autocomplete and less vibe-coding. > This kind of AI usage can grow a driver file very fast and would be > considered "use of AI to generate substantial pieces of code"? > > For all the other points, I agree. A human author must understand and > review the code entirely. > But when is a code considered a substantial piece of code generated by AI? > This could be easily solved by always following "If you do use AI in some > capacity to author code, you must disclose it > in the PR discussion.", but if this gets overused or underused, it loses > its point. > > So, I think the solution should be in the direction that the user must > review and understand everything they have written and generated. No matter > the scale. > If you can't explain why a certain thing is done, it's probably too "vibe > coded". > > Thoughts? > > Best, > Kevin > > > > > Op wo 1 jul 2026 om 17:48 schreef Matteo Golin <[email protected]>: > > > Hello everyone, > > > > NuttX still has not adopted an AI policy, and the number of substantially > > AI-generated contributions is continuing to grow. Recently, the Godot > > project adopted a new AI policy which I think is quite reasonable. [1] > > > > I would like to suggest that NuttX adopt the AI policy from Godot [1] > > (slightly modified for more clarity), as follows, and include it in our > > contribution guide: > > > > - *No autonomous AI agent use or vibe coding* > > > > - A human must be involved in the coding process if patches are > > submitted > > > > - *No use of AI to generate substantial pieces of code* > > > > - We require all code to be human authored. AI assistance should be > > limited to menial things (like code completion, regex, formatting, or > > find > > and replace). > > - If you do use AI in some capacity to author code, you must disclose > it > > in the PR discussion. > > > > - *No AI-generated text in human-to-human communication* > > > > - When our maintainers volunteer their time to review your issue, PR, > or > > proposal, they do not want to talk to a machine. This is a basic > > principle > > of respect. > > - Machine translations are still acceptable as long as the original > > content was written by a human. > > - This includes PR descriptions and comments. > > > > - *All PRs must be reviewed and approved by a human before merging* > > Please let me know your thoughts, I really think it is time to adopt this > > change as I am seeing more and more frequently that substantially > > AI-generated PRs are submitted (what is really most frustrating is its > use > > in human-to-human communication). > > > > Best, > > Matteo > > > > [1]: https://godotengine.org/article/contribution-policy-2026/ > > >
