GNOME sepsal pravidla pro psaní rozšíření rovnou pro modely, které je generují

Fronta na posouzení nových rozšíření pro GNOME Shell se plní kódem, který nikdo nepsal ručně. V týdenním přehledu projektu z 31. července to popsal člen recenzního týmu vystupující jako Just Perfection: většina takových balíčků opakuje přesně tytéž špatné postupy, a tím zdržuje posuzování všem ostatním.

Odpovědí není nový filtr ani zákaz. Je jí dokument psaný pro stroje. Příspěvek An Open Letter to AI for Generating GNOME Shell Extensions vyšel 27. července na blogu Javada Rahmatzadeha a hned první věta říká, proč vznikl: protože prohledávače pro jazykové modely blogy GNOME indexují, má text sloužit jako veřejná reference a měřítko pro modely, které kód rozšíření generují. O den později se jeho obsah objevil v oficiální dokumentaci projektu jako stránka Best Practices; commit, který ji do repozitáře gjs-guide přidal, nese datum 28. července.

Seznam zlozvyků, ne obecné rady

Dokument je stavěný jako dvojice: špatný tvar a vedle něj správný. Nejčastější položkou je zbytečný blok try-catch kolem volání, které za normálního běhu výjimku nevyhodí. Metody jako destroy(), connect(), disconnect() nebo GLib.Source.remove() podle dokumentu neošetřené výjimky neháží, takže je nemá smysl obalovat:

// spatne
if (this._sourceId) {
    try {
        GLib.Source.remove(this._sourceId);
    } catch (e) {
    }
    this._sourceId = null;
}

// spravne
if (this._sourceId) {
    GLib.Source.remove(this._sourceId);
    this._sourceId = null;
}

Druhá opakovaná vada jsou obranné kontroly, které nemají co kontrolovat: volání přes ?.() nebo test typeof u metod, které v dané třídě prokazatelně jsou. Dokument u toho rovnou pojmenovává příčinu. Modely se snaží napsat kód, který poběží na několika verzích GNOME Shellu naráz, a tyhle kontroly jsou vedlejším produktem té snahy. Návod žádá opak: cílit na jednu verzi a při skutečné potřebě sáhnout po samostatném průvodci portováním.

Zbytek seznamu má stejný ráz. Žádné příznaky typu this._destroyed, které mají hlídat pořadí volání; místo připojení signálu destroy se má rovnou přepsat stejnojmenná metoda; ikony patří do Gtk.Image a St.Icon, ne do znaků emoji; ukazatel průběhu se skládá z widgetu, ne z řetězce blokových znaků. Řádek smí mít nejvýš 200 znaků, aby recenzent nemusel v prohlížeči rolovat do strany. A komentáře, které jen převádějí kód řádek po řádku do věty, jsou zakázané.

Značka, kterou si má model napsat sám

Jeden bod se od zbytku liší, protože nemluví o kódu, ale o odpovědnosti. Vydat rozšíření na EGO je podle dokumentu závazek, že ho bude někdo pro uživatele udržovat. Kdo neumí JavaScript číst a ladit, má si vygenerovaný balíček nechat na svém počítači. A model má tuhle podmínku připomenout sám: do generovaných souborů má vložit komentář.

// Generated with AI for personal use.
// Do NOT upload to extensions.gnome.org (EGO) unless you understand JavaScript
// and can maintain this code.

Zákaz v recenzních pokynech je o půl roku starší

Samotné pravidlo z minulého týdne není. Oddíl Extensions must not be AI-generated přibyl do recenzních pokynů 30. listopadu 2025. AI jako pomůcku při učení nebo doplňování kódu nezakazuje; požaduje, aby autor uměl odůvodnit a vysvětlit, co poslal. Odmítnout se mají balíčky s velkým množstvím zbytečného kódu, nejednotným stylem, voláním neexistujícího rozhraní nebo s komentáři, které jsou vlastně zadáním pro model.

Týden nato, 6. prosince 2025, to Rahmatzadeh popsal na blogu z druhé strany. Přibývání zbytečných bloků try-catch ho zarazilo, tak se autorů zeptal, odkud se berou, a dostal odpověď, že z AI. V témže textu psal, že některé dny stráví posuzováním přes šest hodin a projde přes 15 000 řádků kódu. Jednou zavedený zlozvyk se podle něj šíří jako domino a objevuje se v dalších balíčcích.

Že to zabere, nikdo doložit neumí

Celá konstrukce stojí na předpokladu, který zvenčí ověřit nejde: že prohledávače stránku načtou a modely se podle ní zařídí. Nikdo nezveřejňuje, co který model z indexovaných stránek do svých odpovědí promítne, takže úspěch se pozná jedině tak, že recenzentům ubude práce. Podle nás je to spíš pokus než opatření.

Skeptický je i sám autor, jen v jiné věci. V prosincové diskusi pod svým příspěvkem odepsal čtenáři, který žádal, aby se rozšíření označovala štítkem podle toho, jestli u nich pomáhala AI: štítkovat se to podle něj snadno nedá, protože modely se učí a zbytečné řádky, které jsou dnes nápadné, nemusí být poznat příště. Text z 27. července s tím počítá. Nesnaží se generovaný kód poznat, snaží se ovlivnit, jak vypadá.

Pravidla si projekt v posledních týdnech přepsal i jinde: bezpečnostní chyby nahlášené GNOME se od 1. srpna zveřejňují po třiceti dnech místo po devadesáti.

Stránka Best Practices nabízí i syrovou verzi v Markdownu ke stažení, aby šla nástroji předat jako soubor s pokyny. To je z celé věci ta nejpraktičtější část: kdo si rozšíření nechává generovat, může návod modelu podstrčit sám a nespoléhat na to, že ho prohledávač najde dřív.

Zdroje: blog Javada Rahmatzadeha z 27. července 2026 a 6. prosince 2025, dokumentace gjs.guide, týdenní přehled projektu z 31. července a historie repozitáře gjs-guide, kterou bez přihlášení vydá REST API GitLabu; jeho webové rozhraní odpovídá robotům kódem 406.