Many GNOME projects have adopted a policy banning all contributions generated by LLMs. This policy was originally developed by Sophie for Loupe, but is now used in many other notable places:
This project does not allow contributions generated by large languages models (LLMs) and chatbots. This ban includes, but is not limited to, tools like ChatGPT, Claude, Copilot, DeepSeek, and Devin AI. We are taking these steps as precaution due to the potential negative influence of AI generated content on quality, as well as likely copyright violations.
This ban of AI generated content applies to all parts of the projects, including, but not limited to, code, documentation, issues, and artworks. An exception applies for purely translating texts for issues and comments to English.
AI tools can be used to answer questions and find information. However, we encourage contributors to avoid them in favor of using existing documentation and our chats and forums. Since AI generated information is frequently misleading or false, we cannot supply support on anything referencing AI output.
I won’t attempt to argue that you should allow use of AI for writing code. If you wish to ban LLM-generated code, fine. That’s probably inadvisable, but I am not going to object.
But this policy is far stricter than that. Notably, it strictly prohibits AI-generated content in issue reports (except to translate text). Don’t do this! Prohibiting bug reports is stupid and just makes your software worse. Please make sure your project’s AI policy allows for at least AI-generated static analysis results and AI-generated vulnerability reports. Otherwise, you prohibit entirely unobjectionable problem reports.
It’s hard to imagine what could possibly be the value of prohibiting valid bug reports. AI-generated static analysis works well: the AI is able to think about your code, follow execution paths, and automatically discard most false positives to avoid bothering you with them, and the quality of reports is generally pretty high. They are far from perfect, but the same is true of humans.
Here is a typical example of an AI-generated static analysis finding:
2. Resource leak in update_credentials_cb on gnutls_credentials_set failure
File: tls/gnutls/gtlsconnection-gnutls.c:169-172
When gnutls_credentials_set() fails, the function returns without calling g_gnutls_certificate_credentials_unref(credentials). The credentials was either freshly allocated or ref-bumped, so it leaks.
Pasting this into an issue report clearly violates the ban on AI-generated content. And yet, why would you not want to receive a clear and concrete bug report for memory leak?
I understand not all maintainers are fond of AI, but is your dislike really so extreme that you would choose to ignore valid problems and intentionally make your software worse? If not, then your AI policy should thoughtfully consider how to handle AI-generated content in issue reports. Certainly do not adopt a policy that outright bans all AI-generated content in issue reports.
As an issue reporter, you could theoretically take the problem found by the AI and rephrase all the words, then claim that it is no longer AI-generated content because it is rewritten. This is a waste of time and usually results in a lower-quality, less-detailed result, but you could plausibly do that. Or, if you want to go above and beyond, you could just jump ahead to creating a merge request. But realistically, if your project does not allow any use of AI in issue reports, it’s more likely that either (a) you won’t receive the issue report in the first place, or (b) you won’t receive such issue reports from experienced developers who read and respect your policy, while users who do not read your policy will continue to submit them.
What about security vulnerability reports? Since the start of this year, I have reviewed well over 100 vulnerability reports that I strongly suspect were generated by AI. To reach the “over 100” claim, I sadly only considered vulnerability reports submitted during a particularly heavy four week period, so this is an extremely loose lower bound. Suffice to say, I have seen a lot of them. The quality varies dramatically. Vulnerability reports are now often better or worse than before: better because an experienced human working with a good AI is able to find vulnerabilities that would have surely gone unnoticed without AI, and worse because an inexperienced human with a bad AI might create some pretty terrible issue reports, a significant proportion of which are just outright spam. Low-quality reports remain a problem, but nowadays most AI-generated issue reports are quite good.
Maintainers do not need to tolerate spammy vulnerability reports. If an issue report is bad, of course go ahead and close it. If it’s really bad, then I sometimes don’t even bother replying. But banning good vulnerability reports solely because some portion of the report was generated by AI is unacceptable. AI-assisted vulnerability reports are the new industry standard, and this is not likely to change. Prohibiting issue reports reduces the quality and safety of your software, punishing your users. This is too extreme.
Comments
12 responses to “Please Do Not Ban AI-Assisted Issue Reports”
Meanwhile Flathub has gone nuclear and bans anything even remotely looked at by AI tools, eliminating entire swathes of apps from being published there. This ecosystem has become toxic, I’m honestly considering just going back to Windows at this point.
Basically they are Throwing the baby out with the bathwater!
The problem is that until relatively recently, these AI-assisted vulnerability reports were unmitigated crap, overwhelming maintainers with noise. That’s no longer as true, with AI now giving relatively good results from this kind of static analysis, but I understand why a lot of maintainers are feeling burned out when it comes to AI, and don’t want anything to do with it.
If an issue report was written by forced labour, then we should accept it if it’s a valid issue report too then, right? The end does not justify the means for me, and I assume other maintainers too.
Comparing AI usage to forced labour is basically Godwins Law territory.
No, the AI is not able to think.
This is plainly untrue.
And irrelevant. If the aim is to receive and action a valid bug report (and hence improve your software) then whether or not the submitter can “think” is of no consequence. Such a requirement would also have the side effect of excluding many non-AI submissions!
In my experience, AI issues are worse than AI assisted/vibecoded PRs. If nothing else the latter gives you code that likely passes tests and might be salvageable. Code inherently constrains the AI so that by reading it you can at least get a gist of what its trying to do even if the overall pr is not good. And in general someone submitting code is more likely to know what they are doing.
The same cant be said for issues where I have seen LLMs generated issues routinely hallucinate problems in code where there are none to be seen. Personally, the worst thing an issue could do is waste your time on a wild goose chase with nothing to show for it and that is a lot more likely with LLMs. Even if the users issue is genuine, the AIs description or summary might be wrong and not really reflecting what the user actually faced.
Besides, the distinction between AI assisted and fully AI text doesnt mean much to a maintainer. If a human actually verifies an AI finding and writes it up cleanly, it would be practically indistinguishable from a normal report anyway. We only notice “AI issues” when its lazy copy pasted AI text.
People bring up AI assisted security reports as a drawback of this policy. However, if a researcher is convinced there is a real security issue they have found using AI, is it wrong for me or other foss devs, who are mostly volunteers, to expect them to reach out to us directly or through the security contacts? They can send their AI generated report once I have an idea of what they are talking about. Even if AI finds thousands of genuine security issues, managing them through direct contact is still more feasible than scanning through potentially tens of thousands of reports to separate real bugs from hallucinations. The curl projects defunct bug bounty program shows how bad the noise to signal ratio can get.
And while the bounty obviously drives a higher volume of reports, the core issue remains the asymmetric workload. It might take a user moments to prompt an LLM and copy paste a hallucinated issue, but it can take hours of a maintainers limited free time to audit and dismiss it.
Plus we arent mechanical turks whose only role is to fix bugs on demand. There is a human element to volunteering, and we want to interact with the people using our software. I find it more rewarding to work through problems directly with users on discord or matrix.
Anyway, sorry for the wall of text (I know, very LLM of me :P). This got longer than I intended, but this has been bugging me lately as I have seen this sentiment elsewhere too. I wanted to share why others and I are averse to AI issues because these policies dont come from an irrational dislike of AI. The article doesnt address the core problems that make these policies necessary. Identifying which reports are genuine among thousands is itself unpaid work that many maintainers would rather opt out of through policies like this.
Thanks for the writeup and for sharing your thoughts. Cheers.
One possibility is to not ban AI bug reports outright, but treat them as a sign of bad faith and asymmetric effort if you run into a bad one (be more willing to pull the trigger on banning reporters for wasting your time, if it didn’t take up their time)?
Respectfully, you’re looking at this backward.
I understand your reasoning. You see good bug reports being generated by LLMs and think “Why would you not want this?” but this is not the repo managers’ reality and ignores the complaints being raised, which caused the bans in the first place.
Repos cannot simply accept the working reports and ignore or dismiss the others when they are getting overwhelmed with low quality reports. You’re asking them to do something impossible, mostly for free.
They cannot go through 10,000 bug reports, all plausibly phrased, and easily identify which are high and low quality. The reason these are being banned is not merely that some poor bug reports are getting submitted, but because good bug reports cannot be differentiated from them and are thus not able to be addressed in a timely manner.
Think of AI bug reports as essentially a DOS attack, deliberate or not, and you will understand why these policies are being put in place.
Plenty of repos are actually choosing a middle-ground policy. You can use AI to find a bug, but you must understand that bug yourself and write up your report using your brain. This seems like a reasonable compromise which both addresses the reality that small repos are being overwhelmed and that LLMs can sometimes find bugs quite well.
Moreover, and this is a mostly irrelevant point, LLMs do not think. This isn’t an insult, just the truth.
Fortunately, the only GNOME project that’s currently receiving a high volume of AI-generated issue reports is GIMP. And the GIMP developers are not complaining, because they are all good reports. The only problem there is duplicates.
All other GNOME projects currently have a fairly low volume of incoming security issue reports. The deluge earlier this year was due to the GNOME Bug Bounty Program, which is closed now.