If you maintain any kind of public submission queue, GNOME’s week is going to be on your reading list. The project that runs one of the most visible open source desktop environments on the planet just published new guidance aimed not at the humans submitting extensions, but at the AI models generating them. That is a structural shift in how a major open source community thinks about its review process, and the lesson travels further than the GNOME project itself.
This piece is for the maintainer of a small to mid-size project who is already seeing AI-generated submissions in their queue and wondering what to do about it. GNOME is the example, not the topic. The topic is what the next twelve months of public review queues will look like, and how to set yourself up so the answer is not “drown.”
The shape of the wave GNOME is fighting
GNOME’s extension portal, which most people call EGO, runs on manual review. Every submission gets read by a human before it lands. Last December the project tightened the rules to ban fully AI-generated extensions, the kind where the submitter obviously cannot explain what they uploaded. AI was still welcome for learning and for completion. The dump-a-whole-project-and-walk-away pattern was explicitly out.
Months later, the same bad submissions kept arriving in the same shape, with the same broken patterns, with the same over-engineered defaults. The rejection letters were not changing the input stream. So Javad Rahmatzadeh, the developer behind the original rule, did something that should make every maintainer pause. He wrote a second set of guidance aimed directly at the language models producing the bad submissions. Not a stern blog post for humans. Instructions tuned for bots.
The interesting question is not whether GNOME’s approach is right. The interesting question is what it tells you about the review queues you run.
Three problems with rejection as a strategy
The traditional review loop assumes the submitter will read the feedback and act on it. That assumption breaks down when the submitter is a person who did not write the code. Three things go wrong at once.
First, the human cannot defend the work. When a reviewer writes back asking why a particular cleanup is broken, the submitter does not have a good answer. They did not write the cleanup code, so they cannot defend it or fix it. The reviewer is now in the awkward position of giving feedback to a person who has no way to act on it.
Second, the AI that produced the code has no memory of the rejection. The next submission comes in with the same mistakes, fresh energy. Reviewers end up writing the same feedback to the same effective author over and over.
Third, volume compounds the problem. As generative tools get cheaper, the rate of submissions goes up while the per-submission quality stays flat. Review queues that were barely sustainable a year ago are now underwater.
GNOME’s response is the part worth studying. The fix was not more rejection letters or stricter rules. The fix was to change who the documentation was for. Documentation aimed at the model changes the input stream before the review queue sees it. That is a different lever than reject, and it costs less reviewer time per submission filtered.
The signs your queue is in this phase:
- You write the same rejection letter to two different submitters in the same week.
- The submitter cannot answer a single follow-up question about the code they uploaded.
- You are seeing submissions that look professional but have a telltale cleanup failure you have seen a dozen times before.
- Your review queue has more items at the start of the week than it had at the end of last week.
What good AI-aware review guidance looks like
If you are going to write guidance aimed at the AI models your submitters use, you have to commit to a few things or it will not work.
Name the specific patterns you keep seeing. Abstract rules like “write better code” do not survive a prompt rewrite. Concrete patterns like “do not add a _destroyed boolean guard when the fix is to null out the instance” do. The model can pattern-match against concrete rules. It cannot reason about what you meant.
Include code snippets. A paragraph describing the wrong way to clean up an event handler is less effective than the wrong snippet itself with a one-line correction underneath. The model’s training data has more weight on actual code than on prose about code.
For every rule, name the version it applies to. AI models love to write code that survives every version at once, and that code is usually wrong for the version you actually target. Pick one version, say so explicitly, and tell the model not to write portable code. The GNOME guidance does this in the cleanup section and it is the most actionable part of the policy.
Do not pretend the guidance is permanent. Add a sentence at the top that says “this was written for the model versions common in mid-2026 and will be revised.” Maintainers tend to skip this, and then they wonder why their carefully crafted rules stop working six months later.
The personal-use comment block is worth copying
The single rule in GNOME’s new guidance that I think travels best is the personal-use comment block. GNOME is fine with people using AI to generate an extension for themselves. What GNOME is not fine with is that same code being uploaded to EGO without any marker that it was AI-generated.
The fix is a tiny comment block that ships with the code. Something like:
// Generated with AI for personal use.
// Do NOT upload to extensions.gnome.org (EGO) unless you understand JavaScript
// and can maintain this code.
The pattern is worth copying because it does not ban anything. It just forces a moment of honesty at the upload step. If the submitter is about to publish to a public review queue, they have to look at the comment they wrote and decide whether they actually understand what is in it. Most people, I suspect, will close the tab instead. That is fine too.
A reviewer can grep for that comment block in seconds. The cost to the submitter is negligible. The cost to the reviewer in time saved is real.
How to size the effort
A common mistake is to try to write GNOME-grade guidance from scratch. Do not. Start with three rules:
- The single cleanup pattern you see most often in your queue.
- The single over-engineering pattern you see most often.
- A marker comment block that the AI is required to leave in submitted code.
That is a one-day piece of work. It will not solve your review queue problem, but it will cut the worst submissions by a noticeable fraction and give you time to write the next three rules. Iterate from there.
The maintainer hours GNOME spent on this guidance are real, but they are small compared to the reviewer hours saved over a year. For a small project, even one rule written clearly and shipped in the contribution guide pays for itself within a few weeks if it filters even ten percent of submissions.
Trade-offs
Documentation aimed at AI is not a complete fix and pretending otherwise would not help anyone. The honest limits are real and worth naming.
Models are improving faster than the guidance can be revised. The specific patterns you call out today will be obsolete by the time bad actors learn to prompt around them. Maintainers will be playing whack-a-mole, and that is a real cost the project has signed up for.
Marker comments are easy to remove. There is nothing stopping a submitter from stripping the comment block before uploading, and a determined bad actor will do exactly that. The honest answer is that the rule only helps the people who would have been honest anyway. That is still a useful filter, just not a complete one.
Reviewer bandwidth is the third limit. If GNOME is spending maintainer hours on AI hygiene, smaller projects will not have the spare cycles to write equivalent guidance, let alone enforce it. The result is uneven review quality across the open source world, which is the worst possible outcome for projects that already had thin review processes.
Upside is the framing itself. Naming the audience as the AI makes the policy reviewable, falsifiable, and updateable. That is the part other projects should copy first.
What I would tell past me about AI in review queues
If I were going back six months and talking to myself about running a public submission queue, I would say three things.
Rejection is necessary but not sufficient. You cannot review your way out of a volume problem. The queue will keep growing and the per-submission quality will not improve unless you change what arrives at the door.
Documentation aimed at the model is a real lever, not a gimmick. It looks weird at first. It is the cheapest way to change the input stream before the review queue sees it.
A marker comment is the cheapest rule of all. Ship it in the contribution guide tomorrow. It will not solve the problem, but it will buy you the time you need to write the next rule.