Bug, který AI nespraví: kde končí spolehlivost AI ve vývoji softwaru?

AI model dnes napíše funkční kus kódu, ale u chyb, které vznikají z provázaných a nikde nezdokumentovaných rozhodnutí napříč systémem, opakovaně selhává i po několika pokusech. Důvod je prostý: AI nemá kontext, proč byl kód postavený zrovna takhle, a pokud ho nemá ani nikdo ve vašem týmu, chybu nenajde nikdo. Čím víc kódu u vás vzniká bez toho, aby mu někdo skutečně rozuměl, tím větší je riziko, že narazíte na bug, na který nestačí ani nejnovější model.

Co se stane, když bug nezvládne opravit ani nejnovější AI model?

Vývojář a autor blogu Florian Herrengt popisuje v eseji o mizející střední třídě softwarového inženýrství situaci, kterou dává jako ukázkový příklad toho, co se může v týmu stát. Uživatelé nahlásí bug, tým se ho pokusí opravit počtvrté, tentokrát tak, že úkol zadá AI, a ani nejnovější model chybu nenajde. Vedoucí týmu jde za člověkem, který na dané funkci pracoval, a slyší jen „vlastně nevím, zeptám se Claude". Oba pak sledují dlouhou odpověď AI modelu, aniž by byli schopni posoudit, jestli je něco z toho pravda, model přitom působí sebejistě. Tým zkusí důkladnější kontrolu, narazí na denní limit použití a opravu odloží na další den.

Přesně tohle je jádro problému: čím je systém propletenější a čím míň lidí rozumí tomu, proč je postavený tak, jak je, tím míň pomůže i sebelepší AI model. Jak to shrnuje citace, kterou zachytil Simon Willison, projekt se stane tak zamotaným, že nikdo v týmu nedokáže ani začít chápat, co se v něm vlastně děje.

Proč AI umí kód napsat, ale nerozumí tomu, proč tam je?

AI agent je nástroj, kterému zadáte úkol a on sám navrhne i provede úpravy kódu, aniž byste museli psát každý řádek sami. Umí navrhnout architekturu, v dalším kole se rozhodne pro jinou, omluví se a zase ji změní, podle toho, jak se ho ptáte. Design rozhodnutí se tak schová do dlouhé konverzace v chatu místo do hlavy člověka, který by ho uměl vysvětlit.

V praxi to znamená, že rozhodnutí, proč je datový model postavený zrovna takhle nebo proč přibyla nová databázová tabulka, dnes často leží pohřbené v historii konverzace s AI, ne u konkrétního člověka. Když se pak objeví bug, který s tímhle rozhodnutím souvisí, AI dostane úkol najít příčinu, ale nemá kontext, jaký měl ten, kdo k rozhodnutí vůbec došel. Opakuje tak dokola stejné pokusy, protože zkoumá důsledek, ne skutečnou příčinu.

Kdy se rychlost AI vývoje změní v riziko pro vaši firmu?

Autor to přirovnává k nákupu luxusního auta na úvěr: dluh nevidíte, vidíte jen auto, které vypadá skvěle. Technický dluh je souhrnné označení pro zkratky a kompromisy v kódu, které ušetří čas teď, ale prodraží se později, až je bude potřeba napravit. Přidat do databáze novou tabulku nebo sloupec zvládne AI agent v řádu minut. Jenže jakmile se do nich začnou ukládat ostrá data, nejde je jen tak smazat, musíte naplánovat migraci, tedy bezpečný přechod dat na novou strukturu bez výpadku a ztráty, ošetřit, co se stane, když se nepovede, a pohlídat, aby nezůstaly osiřelé vazby mezi tabulkami.

Zatímco tohle řešíte, tým dál generuje další kód, další vrstvy, další rozhodnutí. Než rozmotáte jedno špatné rozhodnutí, přibude jich klidně pět dalších. Pro majitele nebo manažera firmy to znamená stejné riziko jako u každého technického dluhu, jen ve vyšším tempu: čas vašich lidí, náklady na opravu a v krajním případě nefunkční produkt ve chvíli, kdy na tom nejvíc záleží.

AI vs. zkušený vývojář: kdo na co stačí?

• Napsat novou funkci podle jasného zadání - AI model: Spolehlivě, podle zadání. Zkušený vývojář: Spolehlivě, s rozvahou nad dopady.
• Najít bug v jednoduchém, izolovaném kódu - AI model: Obvykle spolehlivě. Zkušený vývojář: Spolehlivě.
• Najít bug v provázaném systému s nejasnou historií rozhodnutí - AI model: Může selhávat i po opakovaných pokusech. Zkušený vývojář: Dokáže dohledat příčinu, i když to trvá déle.
• Vysvětlit, proč bylo rozhodnutí uděláno tak, jak bylo - AI model: Nemá kontext původního zadání. Zkušený vývojář: Rozhodnutí dělal nebo procházel jeho review.
• Bezpečně změnit strukturu databáze u ostrého systému - AI model: Navrhne změnu, ale neposoudí všechna provozní rizika. Zkušený vývojář: Naplánuje migraci a ošetří rizika výpadku.

Jak poznáte, že se tohle riziko týká i vaší firmy?

Tohle se vás týká, pokud:

• velká část vašeho kódu poslední měsíce vznikla přes AI agenta a nikdo si na review nedělal skutečně čas
• na otázku, proč systém funguje tak, jak funguje, dostanete odpověď formou odkazu na konverzaci s AI
• stejný bug se vrací i po několika „opravách" a nikdo přesně neví proč
• noví lidé v týmu nemají odkud pochopit architekturu, protože není zapsaná nikde jinde než v hlavách nebo historii chatu
• chystáte se produkt škálovat nebo prodat, ale nikdo nedokáže odhadnout, kolik práce by stála jakákoli zásadní změna

Jak se řeší bug a kód, na které AI nestačí?

Řešení bugu, který AI opakovaně nezvládne, obvykle nezačíná dalším promptem, ale auditem stavu kódu. Zkušený vývojář projde kódovou základnu, zmapuje, jak na sebe jednotlivé části navazují, a najde místa, kde se rozhodnutí dělalo bez jasného důvodu nebo se ztratilo v historii AI konverzací. Teprve pak jde odhadnout, jestli stačí bug opravit bodově, nebo jestli je potřeba přepsat celou část systému, protože je natolik provázaná, že dílčí zásah by ji jen dál zamotal.

Pokud problém sahá až k datům, řeší se jako samostatný migrační projekt s plánem, co se stane, když něco selže, a jak zajistit, aby produkt mezitím dál běžel. U firem, které potřebují propojit víc systémů dohromady nebo jim chybí vlastní aplikace na míru, se stejný přístup uplatní i mimo opravu jednoho bugu: napřed pochopit, co má systém dělat a proč, a teprve pak stavět. AI v tomhle procesu zůstává užitečným nástrojem, ale pod dohledem někoho, kdo umí posoudit, jestli navržené řešení dává smysl v kontextu celého systému, ne jen jedné konverzace.

Nejčastější otázky

Proč AI nedokáže opravit bug, který zkoušela opravit už několikrát? Protože nemá kontext, proč byl kód postavený tak, jak je. Zkoumá jen důsledek, ne příčinu, a pokud rozhodnutí, které chybu způsobilo, nikdo nezdokumentoval jinde než v historii chatu, model se motá ve stejném kruhu.

Znamená to, že se AI pro vývoj softwaru nehodí? Ne. AI spolehlivě píše nový kód podle jasného zadání a najde chyby v jednoduchém, přehledném kódu. Problém nastává u provázaných systémů s nejasnou historií rozhodnutí, kde chybí lidské porozumění celku.

Jak poznáme, že se nám kód „rozjíždí" bez kontroly? Typickým signálem jsou velké pull requesty, tedy návrhy změn kódu, které nikdo pořádně nezkontroloval, opakovaně se vracející bugy a to, že vysvětlení architektury dostanete jen jako odkaz na konverzaci s AI.

Musíme mít zkušené vývojáře, i když většinu kódu píše AI? Ano, u čehokoli složitějšího než izolovaná funkce. Někdo musí rozumět tomu, proč systém funguje tak, jak funguje, a umět posoudit, jestli navržené řešení nevytváří problém, který se projeví až později.

Kolik stojí opravit kód zanedbaný kvůli nekontrolovanému nasazení AI? Přesnou odpověď dá až audit konkrétního kódu, protože záleží na rozsahu a míře zamotanosti systému. Obecně ale platí, že čím déle se problém odkládá, tím pracnější je oprava.

Jak se pozná technický dluh vzniklý z AI generovaného kódu? Poznáte ho podle toho, že nikdo v týmu neumí bez zaváhání vysvětlit, proč je systém postavený tak, jak je, a proč přibyla konkrétní databázová tabulka, služba nebo technologie.

Kdy má smysl nechat AI upravovat kód bez podrobného lidského review? U malých, izolovaných změn s jasně měřitelným výsledkem. U čehokoli, co se dotýká datové struktury, architektury nebo víc propojených částí systému, by měl výstup vždy projít někým, kdo rozumí celku.

Jak dlouho trvá dostat zanedbaný kód zpět pod kontrolu? Záleží na rozsahu a na tom, kolik rozhodnutí je potřeba zpětně dohledat a pochopit. Konkrétní odhad dá teprve audit stavu, obecně platí, že čím dřív se do toho pustíte, tím míň se problém stihne rozrůst.

Shrnutí

AI model dnes umí kód napsat rychleji, než kdy dřív, ale u bugů, které vznikají z provázaných a nezdokumentovaných rozhodnutí napříč systémem, opakovaně selhává, protože jí chybí kontext, který mají jen lidé. Čím víc kódu u vás vzniká bez toho, aby mu někdo skutečně rozuměl, tím větší je pravděpodobnost, že narazíte na bug, na který AI nestačí ani po několika pokusech. Spolehlivost AI ve vývoji softwaru končí tam, kde začíná potřeba rozumět celému systému a historii jeho rozhodnutí, ne jen napsat další řádek kódu. Řešením není přestat AI používat, ale mít po ruce lidi, kteří umí posoudit, kdy je výstup v pořádku a kdy je potřeba zasáhnout. Bez toho se rychlost AI vývoje dřív nebo později promění v účet, který bude muset někdo zaplatit.

Pokud máte podezření, že se váš kód dostal do podobné situace, nebo řešíte bug, na který AI ani opakovaně nestačí, rádi s vámi nezávazně projdeme aktuální stav a řekneme vám, kde přesně problém vzniká.