Those are good points! I think this is a general AI problem with text; it's very verbose. In a developer setting, it's nice to only have to read as little as necessary. Something we'll need to be mindful of in reviews about docs!
I've seen this mostly in the generated PR descriptions. One big thing is that AI likes to list the paths of all changed files. No one cares, that's what the diff is for! The descriptions get really long quickly in these cases. Hard to do anything about that in review except politely ask that contributors read their generated output and try to shorten it before opening. Best, Matteo On Fri, Jul 24, 2026, 8:32 a.m. Javier Alonso <[email protected]> wrote: > 100% with raiden here. It's not only the contributions being valuable > and adding something that's really useful, but the pain in the ass of > *way too much documentation*. Don't get me wrong, I'm 100% on fully > documented APIs and modules, and this has been something greatly > discussed in this forum as NuttX lacks of documentation for a large > piece of its codebase. But overflooding commits, functions, MRs, and > discussions with AI-generated text that's way too repetitive, adds > very little value, and "scares" the maintainers is a very big pain > point. > > IDK if the AI policy already takes this into account, but for me it'd > be a big requirement for committers to the repo that use AI to keep > documentation contained, useful, simple, and to only get extensive if > really necessary. > > Javier Alonso (he, him, his) > Geotab > > Team Lead - Embedded Systems | GEUR > > Javier Alonso (he, him, his) > Geotab > > Team Lead - Embedded Systems | GEUR > > > Quickly schedule a meeting > > Toll-free > > Visit > > +1 (877) 436-8221 > www.geotab.com > > X | Facebook | YouTube | LinkedIn > > Celebrating 25 years of innovation and impact > > > > On Fri, Jul 24, 2026 at 2:27 PM raiden00pl <[email protected]> wrote: > > > > The problem I'm currently seeing with AI commits in nuttx: docstrings and > > commit messages are too long! Nobody has time to read a wall of text > longer > > than the code change itself. Sometimes a longer comment is required, but > in > > many recent commits, it doesn't make sense. Be more concise, or you'll > > clutter > > the codebase. > > > > czw., 16 lip 2026 o 18:06 Matteo Golin <[email protected]> > napisał(a): > > > > > The goal is not an outright ban, but a proper policy about AI tools so > that > > > we actually have moderation privilege as reviewers when dealing with > the > > > slop PRs. I also agree that AI tooling is, at least in the current day, > > > inevitable to encounter in open-source and it is obviously not > pragmatic to > > > ban it considering how many people on this mailing list have already > voiced > > > their positive opinion of using AI tools correctly. It is not my goal > to > > > ban it. > > > > > > It is incredibly tiring to read the AI-generated output for PR > > > descriptions, commit messages and responses to comments. It is > incredibly > > > verbose, sycophantic, sometimes makes obvious errors and it's even more > > > annoying when you are trying to have a review conversation with a > developer > > > and you are being responded to by a machine. It is not interesting when > > > people submit entirely AI-generated PRs; we can all access Claude and > we > > > can all ask it to fix a bug. I'm not saying that those PRs have no > value; > > > there have a been a number of great bug patches recently that were > clearly > > > discovered and patched with AI. But interacting with people developing > full > > > features who cannot be bothered to even respond to review comments as a > > > human and instead delegate to AI is frustrating. This is one of the > main > > > things in the Godot policy that I think is important to keep. It is > basic > > > respect to engage with your fellow human in good faith. I do think > NuttX > > > should eventually have a policy allowing us to ban GitHub users that > > > auto-open generated PRs and issue links. This is happening already and > it > > > won't slow down, at least for a while. That is not a part of the Godot > > > policy, and I think the Godot policy is a much more moderate stance. > > > > > > And again, copyright issues remain to be a huge problem with these > models > > > and that is a can of worms we are opening by allowing the merge of > entirely > > > AI-written PRs. I think that is an important issue we need to consider > as a > > > grey zone, because yes it is impossible to quantify what is AI-written > and > > > how much becomes too much for copyright issues, but I think at the very > > > least we need to have some kind of stipulation that majorly generated > PRs > > > need to show some kind of indication that the output was verified to be > > > license compatible (I am informed that Codex has such tooling > > > readily-available). > > > > > > I loathe reading AI-generated PR descriptions and I will start > refusing to > > > read them if the number continues to uptick. People at least need to > spend > > > some amount of time tailoring the text to contain only relevant > > > information. There are people on this mailing list who know how to use > AI > > > as a tool and have a respect for quality, and they submit high quality > > > code, AI-assisted or not. But it's not hard to see that AI tooling is > > > empowering a lot of lazy or low-skilled developers to quickly generate > and > > > submit patches for whatever ends (inflating a resume, getting good > GitHub > > > stats, etc.). And I do not think the people that are submitting these > kinds > > > of low-quality patches are deserving of a review. This creates a > > > back-and-forth where maintainers are spending their time basically > coaching > > > other people's models into creating a passable PR through a middle man > who > > > has no idea what they're doing. That's not sustainable and that's what > this > > > policy targets: giving us tools to close such patches until the user at > > > least opens the contribution guide themselves. > > > > > > Matteo > > > > > > On Thu, Jul 16, 2026 at 9:37 AM Alan C. Assis <[email protected]> > wrote: > > > > > > > Or a revolution in the way AI/LLM uses the Processor/GPU/Memory. > > > > > > > > The issue is not only the HW, it is also the software. > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Thu, Jul 16, 2026 at 10:35 AM raiden00pl <[email protected]> > > > wrote: > > > > > > > > > > What happens when the price goes up? > > > > > > > > > > Who knows. Some will likely pay, some will abandon AI. The market > will > > > > > decide whether the technology and companies survive. > > > > > 3D printing or CNC was also essentially useless to the masses for > > > years, > > > > > until the costs of using the technology dropped drastically. It > could > > > be > > > > > similar with AI. > > > > > > > > > > Personally, I hope that local LLMs will be the future, but this > > > requires > > > > > some kind of revolution in hardware. > > > > > > > > > > czw., 16 lip 2026 o 15:22 Nathan Hartman <[email protected] > > > > > > > napisał(a): > > > > > > > > > > > On Thu, Jul 16, 2026 at 8:18 AM raiden00pl <[email protected] > > > > > > wrote: > > > > > > > > > > > > > Currently, AI companies are completely unprofitable and are > burning > > > > > > > investors' money. It's likely they will never be profitable, so > > > using > > > > > AI > > > > > > > now, > > > > > > > when tokens are practically free with subscription plans, is > quite > > > > > > rational > > > > > > > approach. > > > > > > > > > > > > > > > > > > > > > > > > What happens when the price goes up? > > > > > > > > > > > > > > > > > > >
