Článek
V metodice AI asistovaného vývoje se stroj účastní skoro všeho - od formulace kontraktu přes implementaci a testy až po jejich verifikaci a předčištění. Člověku zbývá dvojí, co stroj nedodá: záměr, tedy co má systém zaručit, a jedna nezávislá revize kódu. Jenže pokud jeden model píše všechny vrstvy, prochází celým řetězcem jeho jediný naučený předpoklad - slepé místo, které si řetězec sám nezkontroluje. Celá metodika stojí a padá s tím, jestli tu nezávislost dokáže vynutit, místo aby ji jen předstírala.
V roce 2026 vyřešily nejlepší agentní systémy kolem 87,6 % úloh ze sady SWE-bench Verified, sestavené z reálných chyb v projektech s otevřeným kódem, které kdysi opravovali lidé; hodnota platí pro Claude Opus 4.7 z dubna 2026. Působivé číslo, dokud nepřičtete druhé. Na těžší a proti memorování odolnější sadě SWE-Bench-Pro se i u špičkových modelů standardizované skóre počátkem roku 2026 drželo kolem 46 % (Claude Opus 4.5); při uvedení té sady na podzim 2025 to bývalo sotva 23 %. Mezi 87 a 46 procenty leží skoro celá pravda o tom, co dnes umělá inteligence ve vývoji umí: rutinní, dobře ohraničenou práci zvládá z velké části sama, tu těžší zhruba z poloviny. A je tu ještě jedno varování. Práce „The SWE-Bench Illusion“ (arXiv:2506.12286) doložila, že modely uhodnou cestu k souboru pouze z popisu chyby, bez přístupu k repozitáři, který by k tomu měly potřebovat. Část úspěchu je tedy zapamatování, ne uvažování.
Tahle asymetrie otevírá otázku - když stroj odvede většinu rutinního psaní, co zbude na člověka? Úzkým hrdlem dodávky dnes není psaní kódu, ale jeho revize. Je to Amdahlovo hrdlo, které určuje rychlost celého řetězce. Pokud AI to hrdlo nezahltí, ale předčistí, otevírá se metodika, kterou tu chci popsat: AI asistovaný návrh a implementace, v němž se těžiště lidské práce přesouvá od psaní kódu k jeho specifikaci a kde lidská revize může zůstat jediná, protože přichází až po strojovém filtru.
Je to možné jen za přesně popsatelných podmínek. Nosné přitom není žádné číslo o tom, kolik lidí se posune. Nosné je něco jiného: jakmile týž model odpovídá za návrh, implementaci i kontrolu, visí celá metodika na jediné věci, totiž jestli ten řetězec udrží nezávislost tam, kde ji sám nevidí. Zbytek textu je o tom, co k tomu musí platit a kde se to láme.
Tu myšlenku zformuloval Fred Brooks v roce 1987 v eseji „No Silver Bullet“. Rozdělil složitost softwaru na nahodilou a podstatnou. Nahodilá je dřina, kterou si vývoj přidělává sám: psaní opakujícího se kódu, správa typů, syntaxe. Podstatná je rozhodnutí, co vlastně postavit, jak mají části do sebe zapadat, co je předpoklad a co garance. Brooks tvrdil, že nástroje umějí ukrojit jen z té nahodilé; podstatná zůstává člověku. Má-li pravdu, pak AI, která ukrojí psaní kódu, nechává člověku přesně to, co dělá architekt. A není to povýšení kodéra na architekta, ale odkrytí toho, co bylo architektovou prací vždycky: stroj odebere pokládku asfaltu, návrhové uvažování zůstává.
Vlastní základ si tím nepodkopáváme. Obava „když psaní převezme stroj, odkud se vezmou architekti“ stojí na záměně, že architekt je nutně vysloužilý kodér. Architekt, stejně jako konstruktér, vychází primárně z vysoké školy; návrhové myšlení je samostatná disciplína, ne nadstavba nad léty u řádku. Tím se nevylučuje, že umí kódovat nebo že se vypracoval i zdola - je to legitimní cesta, jen ne ta jediná a ne ta nutná. Architekty mostů ostatně neděláme z asfaltérů: most navrhuje ten, kdo umí spočítat konstrukci, ne ten, kdo nejdéle válcoval povrch. Programátora nedělá architektem počet napsaných řádků, ale to, že přemýšlel, co má systém zaručit; a tohle přemýšlení mu AI nebere. Kde se ti budoucí architekti vezmou, je otázka pro školy, ne pro tuhle metodiku, a odpověď zní, že musí vzdělávat jiné lidi, ne chrlit identické juniory do pozic, které stejně mizí. To je téma na samostatný text; rozebral jsem ho v Poslední generaci seniorů a v Druhé derivaci znalostí.
Co musí platit, aby stačila jedna revize kódu
Začněme tím, co dělá z revize revizi, a ne hádání. Bertrand Meyer to v roce 1992 rozpracoval do návrhu podle kontraktu: každá funkce má předpoklad, který musí splnit volající, a garanci, kterou na oplátku dodá volaná strana. Přesně o to jde - kdo zodpovídá za parametry volání a jak je definované rozhraní. Teoretický základ je starší, sahá k Hoarově axiomatice z roku 1969. A je to právě tahle vrstva, jejíž záměr vlastní člověk-architekt a za niž odpovídá: kontrakt je zadání. Sám návrh kontraktu je ovšem AI-asistovaný. Z lidského záměru pomůže stroj vyjádřit předpoklady a garance, ohlídá jejich vzájemnou bezespornost i úplnost (jestli nezůstal případ bez ošetření) a teprve proti hotovému kontraktu kód implementuje, ověří jeho splnění, změří pokrytí a doplní testy. Nezastupitelně lidské tu zůstává zadání a úsudek, co vlastně má kontrakt zaručit; návrh i realizaci kolem toho stroj asistuje, jsou-li ty hranice jasné.
Pojmenováno jinak, je to vývoj řízený testy posunutý o patro výš. V klasickém TDD (Kent Beck, 2002) napíše člověk nejdřív test, pak kód, který ho splní. Tady architekt napíše kontrakt - předpoklad, garanci, vlastnost - a stroj proti němu doplní implementaci; „zelená“ tu není splněný příklad, ale ověřená specifikace. Testy založené na vlastnostech, o kterých bude řeč za chvíli, jsou tatáž myšlenka dotažená do konce: test přestává být příkladem a stává se tvrzením o záměru. Disciplína ovšem drží jen potud, pokud kontrakt řídí lidský záměr. Jakmile jeho autorství fakticky převezme týž stroj, který píše kód, mizí to, co dělalo vývoj řízený testy cenným - nezávislý popis toho, co se má stát.
Jenže pokrytí testů je zrádná metrika. Laura Inozemtseva a Reid Holmes v roce 2014 ukázali, že korelace mezi pokrytím a schopností testů odhalit chybu je při kontrole počtu testů jen slabá až střední, a vyšší procenta pokrytí na tom moc nemění. Tvrdším kritériem je mutační skóre (Jia a Harman, přehledová studie z roku 2011): kolik uměle zanesených chyb test reálně chytí. Že to není totéž, doložila Meta na vlastní testovací lince. Z 571 testů, které jeho nástroj vygeneroval k záchytu dosud nezachycených chyb, by se 277 (tedy 49 %) nezjistilo, kdyby se hodnotilo jen řádkové pokrytí: chytají chybu, aniž přidají jediný řádek pokrytí. Předpoklad tedy nezní „vysoké pokrytí“, ale „mutačně prověřené testy plus testy založené na vlastnostech, které popisují záměr, ne příklady“.
Druhým předpokladem je samotný filtr - AI revize kódu před lidskou. AI předčištění zabírá tam, kde je práce mechanická: formát, styl, typy, mrtvý kód a - nově nejzajímavěji - hodnocení nálezů statické analýzy. Nástroj SAST-Genius v roce 2025 snížil počet falešně pozitivních hlášení zhruba o 91 % (z 225 na 20) oproti samotnému Semgrepu; ZeroFalse se na srovnávací sadě OWASP dostal na přesnost přes 90 %, takže reziduální falešné poplachy spadly na jednotky procent. Tady je ale nutné přesně oddělit, co předčištění znamená, jinak se vrací problém z dílu o nezávislé revizi. Když filtr odstraní hrubý šum - formátování, triviální chybu, falešný poplach, ušetří lidskou pozornost pro podstatu a zbaví ji únavy z probírání banalit; to je ten psychologický zisk, kvůli kterému člověk nedělá první pohled na syrový strojový výstup. Když ale filtr začne dělat návrhová rozhodnutí a člověk pak jen schvaluje strojové řešení, je zpátky u ukotvení, před nímž jsem v sérii varoval. Hranice vede mezi mechanickou očistou a věcným přepisem: člověk reviduje proti kontraktu a záměru, ne proti výpisu změn, který mu stroj předložil.
Aby ta hranice držela, musí mít code reviewer před sebou něco jiného než syrový výpis změn: rozdíl v kontraktu, rozdíl ve schématu, dotčené architektonické rozhodnutí (ADR ve smyslu Nygardova zápisu z roku 2011), posun mutačního skóre a roztříděný seznam nálezů filtru. Schéma aplikace přitom nemusí být zatuchlý model, na jaký dojely CASE nástroje devadesátých let. Jazykový model ho umí na vyžádání zregenerovat z kódu, takže C4 diagram nebo PlantUML zůstává aktuální, protože vzniká znovu, místo aby se ručně udržoval.
Z toho plyne docela ostrá dělba práce. Filtr spolehlivě chytí to mechanické: styl, typy, velkou část triviálních bezpečnostních nálezů i jejich falešné poplachy, chybějící okrajové testy, porušení kontraktu, které spadne na aserci. Na člověka zůstává to, v čem je AI prokazatelně nejslabší - jestli je ten kontrakt vůbec ten správný kontrakt. To je ta podstatná složitost a zároveň místo, kde se stroj láme. Misu a kolektiv (FSE 2024) sice nechali GPT-4 vygenerovat ověřené metody v jazyce Dafny pro 58 % úloh, ale šlo o učebnicové příklady; Lahiri (FMCAD 2024) ukázal, že i specifikace, která projde verifikací, nemusí zachytit záměr - verifikuje se kód, ne to, co měl kód dělat. Architektova práce se tím nezmenšila, jen přesunula: z psaní řádků na posouzení, zda kontrakt odpovídá tomu, co se po systému doopravdy chce.
Pět vrstev, jeden původ
Nejsilnější námitka, která nikam nemizí, je strukturální. Stroj v téhle dělbě práce nepíše jen kód, testy a předčištění. V reálné praxi i návrh kontraktu vzniká s asistencí AI: člověk drží záměr, ale formulaci předpokladů a garancí dolaďuje se strojem, a vnitřní bezespornost kontraktu, jeho konzistenci, kontroluje zase AI. Sečteno: jeden model se prsty dotýká kódu, testů, předčištění, samotného návrhu kontraktu i jeho verifikace. Pět vrstev, jeden původ, jeden naučený předpoklad, a tedy jedno slepé místo, které žádná z nich nevidí, protože ho všechny zdědily ze stejných vah. Co zůstává výhradně lidské, se pak smrskává na dvě věci: na záměr (co vlastně má systém zaručit, tedy přesně tu podstatnou složitost, v níž AI selhává) a na jednu závěrečnou recenzi.
K tomu se přidává divadlo metrik. Vysoké mutační skóre i hlášení „všechny kontrakty splněny“ jdou obejít ekvivalentními mutacemi a triviálními garancemi, které jen opisují implementaci - Goodhartův zákon v přímém přenosu. Nezávislost tu tedy nezakládá autorství kontraktu, protože to je z velké části strojové; zakládá ji jen lidský záměr a ta jediná recenze, postavené proti řetězci jinak nasycenému jedním předpokladem.
Co s tím? Tři věci, a žádná z nich není kosmetická. Zaprvé člověk musí recenzovat na úrovni záměru, ne shody: jestli řetězec dělá, co kontrakt říká, ověří už stroj; co stroj neověří, je jestli je to ten správný kontrakt, a právě tam musí mířit lidská pozornost. Zadruhé „zelená“ musí něco znamenat: mutačně prověřené testy a testy založené na vlastnostech odliší skutečnou garanci od triviální, která jen kopíruje kód. Zatřetí, a to je nejdůležitější, do řetězce musí vstoupit skutečná diverzita - jiný model nebo nástroj na návrh kontraktu, jiný na jeho kontrolu, jiný na recenzi, aby se slepá místa nepřekrývala. I to má strop: modely trénované na podobných datech sdílejí část předpokladů, takže různé rodiny modelů pomáhají víc než různé verze téže. Diverzita slepé místo zmenšuje, nevymýtí je. Bez těch tří opatření není AI-asistovaný návrh nic než programování od oka o patro výš - řetězec, který obdivuje vlastní odraz.
Druhá výhrada se v debatě skloňuje nejčastěji a opírá se o studii Judy Hanwen Shenové a Alexe Tamkina z Anthropicu (leden 2026). Dvaapadesát vývojářů, kteří se učili neznámou asynchronní knihovnu, dopadlo po práci s AI v následném testu bez AI o sedmnáct procentních bodů hůř (zhruba o dva klasifikační stupně, Cohenovo d = 0,738, p = 0,01), s největším propadem v ladění. Zní to jako důkaz, že AI vývojáře otupuje. Jenže ta studie měří úplně jinou otázku, než jakou klade tahle metodika: jak si vede člověk uprostřed osvojování neznámé látky, když mu AI vezmou. Šlo přitom o zkušené programátory (většina s praxí přes sedm let), kteří jen poprvé sáhli na konkrétní knihovnu - ne o výuku začátečníků. Tady ale nikdo nepracuje bez AI a o učení nováčků nejde vůbec: architekt píše kontrakt a recenzuje s AI po ruce. Jiná populace, jiná podmínka, jiný konstrukt. Není to slabý argument proti metodice; není to argument proti ní vůbec, a dál se jím nezdržuji.
A je tu rovina, kterou nemůžu pominout. Článek 14 nařízení (EU) 2024/1689, tedy AI actu, vyžaduje u vysoce rizikových systémů lidský dohled navržený tak, aby člověk dokázal rozpoznat sklon přespříliš spoléhat na výstup stroje; automatizační zkreslení je tam pojmenované doslova. U systémů dálkové biometrické identifikace navíc článek 14 odst. 5 žádá potvrzení dvěma osobami - tam jedna revize systému ze zákona nestačí. Odpovědnost přitom nese provozovatel a poskytovatel, ne model. Po incidentu musí být jeden podpis pod nasazením dohledatelný a recenzent musí umět vysvětlit, proč konkrétní vadu pustil dál. Pokud to vysvětlit nedokáže, protože se spolehl na předčištěný výpis změn, neselhal jen on, ale celý návrh dohledu.
Aby to nebyla víra, patří sem podmínky vyvrácení. Metodika padá, pokud audit ukáže, že kontrakty soustavně neúplně popisují záměr i tehdy, když je píše člověk; pokud lidská recenze po filtru chytá chyby stejně často jako dvě lidské recenze předtím, a filtr tedy nic nepředčistil; nebo pokud po přesunu rolí zůstanou metriky dodávky na místě a celé přeskupení bylo jen kosmetické.
Psát kontrakty místo řádků není ztráta řemesla; je to řemeslo posunuté výš, protože psaní, testy i ladění míří na jedno místo - na to, co má systém zaručit. Tím se ale celé riziko stahuje do jediného bodu. Až jednou takový systém spadne, chyba nebude v kódu, který nikdo nenapsal ručně. Bude ve špatně postaveném kontraktu a v jediné recenzi, která ho měla zachytit.
Poznámka k metodice a zdrojům
Primární, recenzované nebo oficiální zdroje (vysoká důvěra):
Brooks, F. P.: „No Silver Bullet - Essence and Accidents of Software Engineering.“ IEEE Computer 20(4), 1987, s. 10-19.
Meyer, B.: „Applying Design by Contract.“ IEEE Computer 25(10), 1992, s. 40-51. (Termín „design by contract“ Meyer zavedl už dříve s jazykem Eiffel; tato esej ho rozpracovává.)
Beck, K.: Test-Driven Development: By Example. Addison-Wesley, 2002.
Hoare, C. A. R.: „An Axiomatic Basis for Computer Programming.“ Communications of the ACM 12(10), 1969, s. 576-580. DOI 10.1145/363235.363259.
Inozemtseva, L., Holmes, R.: „Coverage Is Not Strongly Correlated with Test Suite Effectiveness.“ ICSE 2014. DOI 10.1145/2568225.2568271.
Jia, Y., Harman, M.: „An Analysis and Survey of the Development of Mutation Testing.“ IEEE TSE 37(5), 2011, s. 649-678. DOI 10.1109/TSE.2010.62.
Foster, C. a kol. (Meta): „Mutation-Guided LLM-based Test Generation at Meta.“ FSE Companion 2025, arXiv:2501.12862. (Z 571 vygenerovaných testů by 277, tedy 49 %, neprošlo kritériem řádkového pokrytí, přestože chytají reálné chyby.)
Alshahwan, N. a kol. (Meta): „Automated Unit Test Improvement Using Large Language Models at Meta.“ FSE 2024 Companion, arXiv:2402.09171.
Misu, M. R. H., Lopes, C. V., Ma, I., Noble, J.: „Towards AI-Assisted Synthesis of Verified Dafny Methods.“ Proc. ACM Softw. Eng. 1(FSE), 2024. DOI 10.1145/3643763. (GPT-4 vygeneroval ověřené metody pro 58 % úloh z datové sady MBPP.)
Lahiri, S. K.: „Evaluating LLM-driven User-Intent Formalization for Verification-Aware Languages.“ FMCAD 2024. arXiv:2406.09757.
Shen, J. H., Tamkin, A. (Anthropic): „How AI Impacts Skill Formation.“ arXiv:2601.20245, leden 2026. RCT, N = 52, model GPT-4o; rozdíl ve skóre 17 procentních bodů (≈ 2 klasifikační stupně), Cohenovo d = 0,738, p = 0,01, největší propad v ladění. Účastníci byli zkušení vývojáři (většina s praxí 7+ let) učící se neznámou knihovnu, ne junioři.
DORA / Google Cloud: Accelerate State of DevOps Report 2024 (dora.dev/research/2024). Vliv AI na propustnost a stabilitu je asociační, nikoli kauzální.
METR (Becker, Rush, Barnes, Rein): „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.“ arXiv:2507.09089, 2025. Aktualizace metr.org/blog/2026-02-24-uplift-update/ (METR svůj výsledek −19 % sám označuje za zastaralý a nová data za nespolehlivá).
Nařízení Evropského parlamentu a Rady (EU) 2024/1689 (AI act), čl. 14 (vč. odst. 4 písm. b - automatizační zkreslení - a odst. 5 - dvě osoby u dálkové biometrické identifikace).
Nygard, M.: „Documenting Architecture Decisions“ (ADR), 2011. Brown, S.: model C4 (The C4 Model: Visualizing Software Architecture, O’Reilly, vyjde 2026, dostupné v raném přístupu; starší samizdatová verze Leanpub 2023).
Preprint / vendor / registr (střední důvěra, čísla se mohou rychle měnit):
SAST-Genius: arXiv:2509.15433, 2025 (snížení falešně pozitivních o ~91 %, 225 → 20 vs Semgrep). ZeroFalse: arXiv:2510.02534, 2025 (přesnost > 90 %, F1 = 0,912 na srovnávací sadě OWASP Java).
SWE-bench Verified (Jimenez a kol., ICLR 2024): hodnota ~87,6 % pro Claude Opus 4.7 (duben 2026) pochází z agregátoru citujícího oznámení Anthropicu, nebyla nezávisle přeměřena pod jednotným postupem. SWE-Bench-Pro (Deng a kol., arXiv:2509.16941, 2025): při uvedení sady (podzim 2025) řešily nejlepší modely kolem 23 %; hodnota ~46 % je standardizované skóre SEAL pro vedoucí model (Claude Opus 4.5) počátkem roku 2026. „The SWE-Bench Illusion“: arXiv:2506.12286, 2025 (důkazy o memorování).
Limity tohoto textu:
Číslo „polovina kodérů → architekti“ nemá primární zdroj; je to pracovní hypotéza a horní odhad. Empiricky podložitelný je nanejvýš rozsah „podstatná část, řádově 30-50 %“, a i ten nepřímo (Brooks 1987 + DORA 2024), nikoli měřením tohoto konkrétního workflow.
Pravidlo „70 % rychle, 30 % bolí“ je praktikové folklor (Osmani, 2024), ne důkaz; v textu proto nefiguruje jako tvrdé tvrzení.
Studie Shenové a Tamkina (2026) měří jinou otázku - výkon učících se vývojářů v testu bez AI -, než jakou klade tato metodika; v textu proto nefiguruje jako protiargument, jen jako často citovaná, ale mimoběžná námitka.
Průmyslové nasazení kontraktních jazyků je nerovnoměrné: doložené masové nasazení má hlavně SPARK/Ada (letectví, železnice); JML, ACSL a Dafny jsou převážně výzkumné.
Námitka o „sdílené slepé skvrně“ má silný teoretický základ, ale v dosavadní literatuře není kvantifikovaná - je to otevřený problém.
Analýza vznikla s pomocí AI. Data a zdroje byly ověřeny k datu zpracování (květen 2026), situace se však může měnit. Před použitím pro rozhodování doporučuji aktualizaci dat a nezávislé ověření klíčových zjištění.
Transparentnost tvorby:
Koncepce, struktura a redakční linie článku jsou dílem autora, který vypracoval obsahovou skicu, stanovil klíčové teze a řídil celý proces tvorby. Generativní AI (Claude, Anthropic) byla využita jako nástroj pro rešerši, vyhledávání primárních zdrojů a formulační rozpracování autorovy obsahové skici.
Autor výstupy průběžně redigoval, ověřil klíčová zjištění a schválil finální znění. Žádná část textu nebyla publikována bez lidské kontroly. Všechny faktické údaje byly ověřeny proti veřejně dostupným zdrojům uvedeným v textu.
Postup je v souladu s požadavky čl. 50 Nařízení EU 2024/1689 (AI Act) na transparentnost AI-generovaného obsahu. #poweredByAI
