Představme si vývojáře, který večer zadá asistentovi opravu chyby a ráno pošle do open-source projektu rozsáhlou změnu. Je spokojený: kód se překládá, aplikace nastartuje a vypadá to jako slušný příspěvek komunitě. Jenže správce projektu teď musí zjistit, proč se změnilo tolik souborů, co nové větve programu udělají při chybě a zda oprava nerozbije něco vedle. Autor si usnadnil práci. Někdo jiný ji právě dostal na stůl.
Právě na tento přesun práce reaguje tým bezpečnostního nástroje ZAP. V příspěvku z 13. října 2026 Simon Bennetts popisuje pravidla pro vývoj v době, kdy velké jazykové modely usnadňují tvorbu kódu. Projekt nechce zavírat dveře nováčkům ani zakazovat pomoc AI. Chce po člověku, který změnu předkládá, aby jí rozuměl, otestoval ji a nesl za ni odpovědnost.
Podle nás je to mnohem užitečnější odpověď než další hádka o tom, zda program napsal člověk, nebo stroj. Rozhodující otázka zní: kdo odpracuje ověření? Když autor nabídne jen výsledek generátoru a doufá, že správce doplní porozumění, testy i důvody změny, neposílá hotový příspěvek. Posílá objednávku cizí práce.
Levný kód, drahá pozornost
ZAP popisuje nerovnováhu jednoduše: vytvářet kód je snazší, recenzovat jej podle zkušenosti týmu snazší není. Kontrolující člověk potřebuje pochopit zamýšlené chování, porovnat ho s implementací a posoudit dopad na zbytek projektu. V blogu nejde o časovou studii ani o vyčíslený pokles produktivity. Jde o zkušenost správců, kteří z ní vyvozují konkrétní pravidla pro přijímání změn.
Na Radyzu jsme tato pravidla ZAP pro příspěvky připravené s LLM shrnuli v rychlé zprávě. Podstatný detail si ale zaslouží větší pozornost: vztahují se také na samotný core tým. Bennetts píše, že někteří jeho členové už museli změny vracet nebo přepracovat kvůli přílišné velikosti, slabým testům či nepřehlednosti. Nováček tedy nemá plnit podmínky, které si zavedení vývojáři odpustí.
To je důležité i lidsky. Požadavek na kvalitu se snadno změní v obrannou zeď kolem starých členů komunity: od neznámého člověka chceme důkaz všeho, známému kolegovi věříme. ZAP deklaruje opačný přístup. Nástroj ani délka členství nemají nahradit srozumitelnou změnu, kterou lze rozumně zkontrolovat.
U firem se dá podobná nerovnováha schovat do rozpočtu týmu. U komunitního projektu se projeví v tom, na co má správce večer ještě energii. Pokud ho každý příspěvek nutí rekonstruovat autorův záměr, platí se pozorností, kterou mohl věnovat opravě závažné chyby nebo pomoci dalšímu nováčkovi. Samotný počet odeslaných změn proto není dobrým měřítkem přínosu pro projekt.
„Napsal to model“ není vysvětlení
Základní pravidlo ZAP je přísnější než prosté „zkusil jsem to spustit“. Autor má umět vysvětlit, co změna dělá a proč, v případě potřeby řádek po řádku. Má být přesvědčený, že řeší zamýšlený problém, zvládá důležité okrajové situace a nepoškozuje jiné části systému. Úspěšný překlad a jeden zdařilý pokus na vlastním počítači tuto práci nenahrazují.
Vezměme modelovou opravu přihlašování. Asistent upraví funkci tak, aby běžný uživatel po zadání správného hesla prošel dál. To ještě neodpovídá na otázku, co se stane při vypršení relace, nedostupné službě nebo neočekávané odpovědi serveru. Pokud autor tyto situace neprošel, správce nedostává jen implementaci. Dostává také nevyřčený úkol vymyslet její hranice.
ZAP proto žádá malé, soustředěné pull requesty, tedy návrhy změn ke společnému posouzení. Oprava jedné chyby nemá být současně přestavbou okolního kódu a přidáním nesouvisející funkce. Kde to jde, mají ji doprovázet testy jednotlivých částí i testy celého chování aplikace. Když něco nejde pokrýt jednotkovým testem, autor má vysvětlit proč, ne nechat prázdné místo bez komentáře.
Podle nás je právě omezení rozsahu nejlevnější dostupnou ochranou času správců. Menší změna nezaručuje správnost, ale umožňuje položit přesné otázky. U rozsáhlého balíku nesouvisejících úprav se i dobrý nápad ztrácí mezi věcmi, které nikdo nežádal. Rozdělit práci není kapitulace před pomalým člověkem; je to součást dokončení příspěvku.
Druhý model může pomoci. Razítko z něj nedělejme
ZAP zároveň nesází na ruční kontrolu všeho od prvního do posledního kroku. U každé netriviální změny chce nejprve využít LLM k recenzi a přispěvatelům doporučuje, aby před odesláním zapojili jiný model než ten, který pomáhal kód napsat. Cílem je odchytit zjevné nedostatky dřív, než se jimi začne zabývat člověk: slabé zpracování chyb, chybějící okrajové případy nebo testy, které ve skutečnosti nic podstatného neověřují.
V tom není rozpor. AI může autorovi pomáhat, aby do společné fronty neposílal zbytečnou práci. Projekt ale výslovně říká, že modelová kontrola nenahrazuje lidský úsudek. Člověk musí dál rozhodnout, zda změna do projektu patří a zda jí lze věřit.
Doporučení druhého modelu také není důkazem nezávislého bezpečnostního auditu. Blog nezveřejňuje měření, kolik chyb tento postup zachytí ani kolik jich přehlédne. Souhlas dvou asistentů se nesmí stát důvodem přestat zkoumat zadání a chování programu. Pokud oba přijmou stejný chybný předpoklad, mohou jej jen dvakrát uhlazeně vysvětlit.
Přínos další kontroly je praktičtější: může autorovi položit otázku, kterou si sám nepoložil. Proč test nepokrývá odmítnutý požadavek? Proč se chyba jen zapíše do logu a běh pokračuje? Odpovědí však musí být oprava, test nebo zdůvodnění. Věta „druhý model nic nenašel“ není náhradou za žádnou z těchto věcí.
Kvalita potřebuje cestu, ne pouze zákaz
Na oznámení ZAP je sympatické, že nekončí seznamem povinností. Tým také přepracovává testovací službu, aby bylo jednodušší přidávat testovací stránky přímo k rozšířením, jejichž funkce ověřují. Už používá Dev add-on s jednoduchou webovou službou běžící uvnitř ZAP a chce její stavbu udělat modulárnější. Popisovaná přestavba je práce v průběhu, nikoli tvrzení, že všechny nové možnosti jsou hotové.
Pro testy celého chování projekt preferuje plány svého Automation Frameworku, které lze spustit bez ruční přípravy a nedokumentovaných předpokladů. To je dobrý rozdíl mezi nárokem a pomocí: nestačí napsat „dodejte pořádné testy“, když se přispěvatel nejdřív musí probojovat nejasným prostředím. Jestli správce chce reprodukovatelný důkaz, má smysl usnadnit jeho výrobu.
Podobný přesun omezení jsme už rozebírali u testů, které nestíhají tempu coding agentů. Tam jde o kapacitu infrastruktury a čekání na automatické kontroly. ZAP otevírá jinou část problému: lidské porozumění nelze navýšit pouhým přidáním výpočetního výkonu. Rychlá testovací infrastruktura pomůže, ale sama neodpoví, zda navržená změna dává smysl.
Pro malý tým z toho plyne docela konkrétní pracovní dohoda. Před odesláním má být jasné, jaký problém se řeší, proč je změna omezená právě na tento rozsah a jaké chování bylo skutečně vyzkoušeno. Autor má umět popsat také neúspěšné scénáře a známé mezery. Správce pak kontroluje předloženou práci místo toho, aby od začátku vytvářel její zadání.
Nejzajímavější na pravidlech ZAP je, že nevyžadují volbu mezi technologickým nadšením a zákazem AI. Vyžadují slušnost vůči člověku na druhé straně. Použij nástroj, který ti práci zrychlí, ale nedělej ze svého zrychlení cizí přesčas. Dokud změně nerozumíš a neumíš ji obhájit, dokončený příspěvek ještě nemáš.
