GNOME Shell Extensionsチームは、AI生成コードの明確な痕跡を帯びた拡張機能の流入が増えていることを受け、EGOカタログにおけるモデレーション規則を強化することを決定しました。レビューチームのメンバーによれば、引き金となったのは、一部の開発者がAIツールを無造作に使い始め、ソースコードに実際に何が書かれているのかを十分に理解しないままパッケージを提出していることでした。
筆者は、拡張機能開発者の負担を軽くすることを目的にチームへ参加したと説明しています。まず移植ガイドから着手し、その後レビューに深く関わるようになり、ベストプラクティスの共有、コード例の提供、ときには自ら問題を修正してマージリクエストを提出することもありました。Andy Holmesとともに、拡張機能作者向けのドキュメント一式を整備し、例を添えた、厳格でありながら透明性のあるレビュールールを確立しました。並行してコミュニティも成長を続け、言及されているとおりGNOME ExtensionsのMatrixチャンネルでは迅速な回答と支援が得られ、EGOへの提出数も着実に増加していきました。
しかし、その成長は新たな負担ももたらしました。日によってはレビューに6時間以上を費やし、15,000行を超えるコードがレビュアーの手を通る一方で、コミュニティメンバーからの質問も絶え間なく寄せられます。特にこの2か月間、EGOでは新規拡張機能が急増し、AI生成の回答から明らかに引き継がれた不要なコードや不適切な慣行に、チームが遭遇する機会が増えています。筆者は、この問題はドミノ効果によってさらに悪化すると主張します。ある拡張機能で悪い癖が一度現れると、すぐに他へコピーされ、結果として誰にとってもレビュー待ちの列が長くなるのです。
象徴的な例として挙げられているのは、単純にsuper.destroy()を呼び出せばよいところを、作者がtry–catchブロックで包み、型チェックを追加し、警告まで出すケースです。しかもそのメソッドは親クラスに明示的に定義されています。結果としてコードは肥大化し、より複雑で読みにくくなり、ひいてはレビュー工程を遅らせます。そのため、EGOの規則には新たな条項が追加されます。AI生成と思われる不要なコードを含む提出物は却下される、というものです。
同時にチームは、AIをツールとして捨てるべきだと主張しているわけではないことも強調しています。AIは学習、エラー診断、問題の慎重な修正において有用になり得ます。問題視されているのは、拡張機能全体を生成して、その仕組みを理解しないまま提出することです。拡張機能開発の初心者に対して筆者は、助言や指導を求めるためにGNOME Extensions Matrixチャンネルへより頻繁に参加することを勧めています。
