Kódovací agent potřebuje ověřovací systém, ne slepou důvěru

TL;DR:

• Velké úpravy kódu s AI dávají smysl hlavně tam, kde umíš výsledek spolehlivě ověřit.
• Kódovací agent není náhrada za úsudek vývojáře, ale nástroj pro iteraci v dobře vymezeném prostoru.
• U migrací, přepisů a opakovaných refaktorů je klíčové mít testy, srovnání chování nebo jasný kontrolní seznam.
• Čím větší změnu agent dělá, tím méně stačí číst každý řádek a tím víc záleží na důkazech, že kód funguje.
• Praktická otázka před zadáním zní: poznám rychle a spolehlivě, že výsledek je správně?

Když dnes necháš AI opravit jednu funkci, většinou víš, kam se podívat. Přečteš změnu, pustíš testy, zkusíš krajní případ a rozhodneš. U většího zásahu je to jiné. Migrace knihovny, přepis části aplikace nebo hromadný refaktor může změnit stovky míst najednou. Tam už lidská kontrola každého řádku přestává být hlavní pojistka.

Právě v tom je důležitý posun. Smysluplné programování s asistencí AI nestojí na tom, že agent jednou vygeneruje působivý kus kódu. Stojí na tom, že mu připravíš prostředí, ve kterém se chyba rychle ukáže. Ověřovací systém je praktická brzda i motor zároveň. Brzdí špatné výsledky a zároveň dovolí agentovi zkoušet, opravovat a znovu spouštět práci bez toho, aby člověk ručně posuzoval každou drobnost.

Velký výstup není totéž co hotový software

Simon Willison zveřejnil 26. srpna 2026 krátkou citaci Paula Dixe, podle níž AI napsala a během několika měsíců ladila přibližně milion řádků kódu do spolehlivého softwaru běžícího na milionech vývojářských počítačů. Podstatná část argumentu není samotné číslo. Důležitější je tvrzení, že pokud má AI ověřovací systém a jasné zadání s mantinely, může iterovat na složitém softwaru, dokud výsledek neobstojí.

To není výzva k tomu, aby se agent pustil do libovolné části produkční aplikace. Je to spíš připomínka, že měřítkem práce agenta není objem změn, ale kvalita zpětné vazby. Bez ní může milion řádků znamenat jen milion nových míst, kde se může skrývat problém.

U software platí jednoduché pravidlo: čím víc práce deleguješ, tím přesnější musí být kontrola. Agent může psát rychleji než člověk, ale sám od sebe nemusí chápat, které chování je pro uživatele zásadní, které chyby jsou přijatelné a které drobné odchylky rozbijí byznysový proces.

Ověřovací systém je pracovní zadání v tvrdší podobě

Dobré zadání pro kódovacího agenta není jen popis cíle. Je to sada hranic, kontrol a důkazů. Testy říkají, co se nesmí rozbít. Srovnání starého a nového chování ukazuje, jestli přepis zachoval význam. Statická analýza, sestavení aplikace a typová kontrola zachytí část chyb dřív, než je uvidí člověk.

U migrace staršího kódu může ověřovací systém vypadat tak, že pro stejné vstupy spouštíš starou i novou implementaci a porovnáváš výstupy. U změny API můžeš měřit, jestli zůstaly zachované odpovědi, chybové stavy a formát dat. U refaktoru může být cílem, aby se změnila struktura kódu, ale ne chování aplikace.

Takový systém nedělá práci automaticky bezpečnou. Dává ti ale opakovatelné měřítko. Agent dostane možnost opravovat chyby podle výsledků kontrol a člověk se může soustředit na selhání, ne na procházení každého úspěšného kroku.

Kdy je úloha pro agenta vhodná

Ne každá programátorská práce je dobrý kandidát pro agenta. Vhodnější jsou úlohy, kde je cíl úzký, výsledek ověřitelný a riziko lze rozdělit na menší části. Repetitivní refaktor, mechanická migrace nebo převod mezi podobnými strukturami bývají lepší než návrh nové domény, kde se teprve hledá správné chování.

Před zadáním si polož tři otázky. Dá se správnost ověřit automaticky? Existuje srovnávací vzor, například stará implementace, testovací sada nebo jasný příklad očekávaného výstupu? Umíš změnu rozdělit tak, aby se po každém kroku dalo rozhodnout, jestli pokračovat?

Pokud je odpověď třikrát ne, agent může pořád pomoct, ale spíš jako sparingpartner pro návrh řešení nebo jako autor menších částí. Pokud je odpověď ano, začíná být zajímavé nechat ho pracovat ve smyčce: změň kód, spusť kontroly, oprav selhání, zopakuj.

Malý tým tím získá páku, ale i novou odpovědnost

Představ si freelancera, který udržuje starší aplikaci pro klienta. Potřebuje přejít na novější verzi knihovny, ale změna zasahuje mnoho souborů. Ruční práce by zabrala dny a byla by únavná. Agent může připravit první průchod, opravit typové chyby a navrhnout úpravy testů. Freelancer ale musí předem určit, které části aplikace se nesmí změnit, jaké scénáře se musí projít a kdy se práce zastaví.

Podobně malý produktový tým může použít agenta na opakovaný refaktor. Místo kontroly každé syntaktické změny nastaví pravidla, spustí testy, projde rozdíly v klíčových souborech a podívá se hlavně na případy, kde kontrola selhala. Lidská práce se tím neposouvá pryč. Posouvá se výš: od psaní každého detailu k návrhu mantinelů a rozhodování o výjimkách.

To je důležité i organizačně. Pokud tým nemá testy, nerozumí kritickým tokům aplikace a neumí popsat přijatelné riziko, agent tento dluh jen zviditelní. Rychlejší psaní kódu pak může znamenat rychlejší výrobu nejistoty.

Lidská kontrola se má přesunout na správná místa

Nejhorší kombinace je velký agentský zásah a jen povrchní lidské schválení. Člověk nemá být razítko na výstupu, kterému už nikdo nerozumí. Má být autor pravidel, správce kontrol a poslední rozhodčí u případů, kde automatická kontrola nestačí.

U větších změn proto dává smysl kontrolovat hlavně tři vrstvy. První je záměr: řeší agent správný problém a drží se hranic zadání? Druhá je důkaz: prošly testy, porovnání a sestavení bez skrytých výjimek? Třetí je dopad: nezměnil se způsob, jak aplikaci používá zákazník, administrátor nebo navazující služba?

Agent může iterovat dlouho, ale člověk musí vědět, kdy iteraci ukončit. Někdy je lepší menší změna, kterou tým umí vysvětlit, než obrovský výstup, který sice projde částí kontrol, ale nikdo mu nevěří.

Začni jednou kontrolovatelnou změnou

První krok není vybrat nejchytřejší nástroj. Vyber jednu úlohu, kde už máš aspoň částečný ověřovací systém. Může to být migrace jedné části kódu, sjednocení podobných funkcí nebo oprava série opakovaných chyb. Napiš agentovi cíl, hranice změny a příkaz, jak se má výsledek ověřit. Pak sleduj, kde kontroly selžou a co jsi musel doplnit ručně.

Po takovém pokusu budeš vědět víc než po debatě o tom, jestli AI umí programovat. Uvidíš, které části práce se dají bezpečně zrychlit, kde chybí testy a kde lidský úsudek zůstává nenahraditelný. To je praktičtější měřítko než počet vygenerovaných řádků.

Zdroj

Simon Willison: Quoting Paul Dix https://simonwillison.net/2026/Aug/26/paul-dix/