Klíčová zpětná vazba při realizaci projektu vývoje softwaru není mezi vývojářem a správcem testovací sady. Probíhá mezi tvůrci funkcionality (analytikem, vývojářem, testerem), a zadavatelem-uživatelem. Jaká otřepaná pravda! Ale dobře, pojďme si dovolit ten luxus si to opravdu trochu promyslet. Vše ostatní – unit testy, integrační testy, revize kódu, CI kanály – existuje proto, aby tuto smyčku aproximovalo a překládalo v situacích, kdy přímý kontakt není možný nebo dostatečně rychlý. U podnikových systémů je tomu tak v podstatě vždy – sémantická vzdálenost mezi potřebou budoucího uživatele a kódem/daty/výstupy je tak velká a kontext tak rozsáhlý či specifický, že by to nikdo nedokázal zvládnout sám. Jedním z nejzáludnějších momentů dnešní „revoluce AI“ (kterou raději nazývám rychlou evolucí ekosystému založeného na LLM) je příslib, že dojde k průlomu i v tomto ohledu, kde jsou argumenty téměř výhradně triviální nebo specifické – v takovém případě hraje sémantika jen roli slabého omezení. Rád bych jen upozornil na problémy skryté za těmito předpoklady. Podle mého názoru hra zůstává stejná, mění se jen některá pravidla, ale v jádru byznysu „překladu potřeb do SW“ zůstává fakt, že „neexistuje nic jako porozumění na bázi vibrací“. V mnoha konkrétních tématech bych s Curtem nesouhlasil, ale myslím, že nejdůležitější sdělení vystihl skvěle:

Invariant dvou otázek

Když se testovací inženýr ptá: „Jak mám tuto funkci otestovat?“, je tato otázka strukturálně shodná s otázkou: „Co je jádrem této funkcionality (nebo ne/funkčního požadavku – hrozné slovní spojení, ale běžně používané) a proč na ní zákazníkovi (např. pro jeho misi) záleží?“. Nejsou to dvě otázky – je to tatáž otázka vyjádřená ze dvou pozic v procesu. Test, který nelze odvodit z jasné odpovědi na druhou otázku, není užitečný. Pozor na V-model! Popis funkce, který nelze přeměnit v test, není použitelnou specifikací.

Toto není pozorování o testování. Je to pozorování o komunikaci. Funkcí revize návrhu testů – v jakékoli metodice – je odhalit neshody ve sdíleném mentálním modelu systému dříve, než se tyto neshody zakódují do softwaru nebo testovacích dat. V jazyce testování jasně rozlišujeme mezi cíli validace a verifikace. I v praxi, zejména při rozhovorech s těmi, kteří mají rádi přístup „KISS“ (Keep it Simple, Stupid), nám tato nuance často uniká. Když testovací inženýr nedokáže zformulovat test pro určitý požadavek, je toto selhání signálem: požadavek obsahuje skrytý předpoklad, nejednoznačnost nebo rozpor. Proces návrhu testu je strukturovaný protokol pro extrakci těchto skrytých vlastností z popisů v přirozeném jazyce.

Chyby se opravují snadno. Koncepční problémy nikoliv.

Chyba (error) je lokalizovaná odchylka: špatný výpočet, chybějící kontrola na null, chyba o jedničku (off-by-one). Statická analýza, automatizované testy a lintery zachycují chyby spolehlivě. Náklady na jejich detekci už desítky let klesají a budou klesat i nadále. Generování kódu s pomocí LLM bude tento proces ještě více urychlovat – syntaktická kvalita generovaného kódu je obecně vysoká a běžné chybové vzorce jsou v trénovacích datech dobře zastoupeny.

Koncepční problém je odchylka v modelu systému: funkce, která správně implementuje chybnou interpretaci požadavku; datová struktura, která přesně reprezentuje doménový koncept, z něhož se vyklube koncept nesprávný; integrační vzorec, který koherentně propojuje dvě služby podle kontraktu, jenž nebyl nikdy skutečně odsouhlasen. Statická analýza tyto problémy nezjistí. Automatizované testy je nezjistí, pokud nebyly napsány podle správné specifikace – a pokud byla specifikace špatná, jsou špatné i testy a projdou.

Tato asymetrie – chyby jsou nalezitelné, koncepční problémy nikoliv – je přetrvávající strukturální výzvou kvality softwaru. S lepšícími se nástroji nemizí. Naopak se zintenzivňuje. Rychlejší cykly dodávek zkracují čas dostupný pro komunikaci, která by koncepční problémy odhalila dříve, než jsou zakódovány. Nástroje pro kódování s podporou AI zvyšují průchodnost generování kódu, aniž by zvyšovaly přesnost pochopení požadavků. Poměr rizika koncepčního problému k riziku běžné chyby se zvyšuje.

AI jako zesilovač – nikoli jako validátor specifikace

Nástroje pro kódování a dokumentaci založené na LLM jsou na své současné úrovni schopností vysoce kvalitními zesilovači toho, co je již obsaženo v kontextu promptu. Jsou vynikající v generování syntakticky správného, stylisticky vhodného kódu, který odpovídá záměru vyjádřenému v zadání. Jsou však špatnými validátory toho, zda záměr vyjádřený v promptu odpovídá záměru, který má zákazník v hlavě.

Nejedná se o kritiku – jde o popis provozního rozsahu nástroje, který vyjadřuje, čím tyto nástroje z principu jsou. Trocha pochopení matematiky za Transformery a tréninkovým procesem by opravila falešná očekávání, která jsou do těchto nástrojů tolik projektována. Ale to je téma na jiný příspěvek. Zesilovač signálu zesiluje signál i šum rovnoměrně. Pokud vstup do kódovacího nástroje LLM obsahuje koncepčně chybnou specifikaci, výstupem bude větší, propracovanější a lépe formátovaná verze této koncepčně chybné specifikace. Míra detekce chyb u implementačních chyb bude vysoká. Míra detekce koncepčních chyb bude nízká nebo nulová. Úlohou testovacího inženýra v tomto prostředí není konkurovat nástroji v detekci chyb. Je jí udržování disciplíny kladením otázky: „Odráží tato specifikace správně to, co zákazník potřebuje?“ – tedy otázky, na kterou nástroj odpovědět neumí.

Krátké zpětnovazební smyčky jako infrastruktura kvality

Praktický důsledek pro týmovou komunikaci: zpětná vazba mezi „co stavíme a proč“ a „jak to budeme ověřovat“ musí být udržována kratší než smyčka mezi „psaním kódu“ a „jeho nasazením“. V agilním týmu využívajícím AI nástroje to znamená, že schůzka k analýze testů (nebo ekvivalentní výměna informací) probíhá při definici story, nikoli po dokončení kódu. Vývojář, testovací inženýr a produktový vlastník jsou v jedné místnosti (fyzické nebo virtuální), když se píše akceptační kritérium, protože to je moment, kdy lze koncepční model ještě opravit s minimálními náklady.

Tento argument není filozofický. Je ekonomický. Náklady na opravu koncepčního problému zjištěného během akceptačního testování jsou o řád vyšší než náklady na jeho opravu během definice story. V týmu generujícím velké objemy kódu pomocí LLM nástrojů se zvyšuje objem kódu produkovaného na jednotku investice do komunikace – což znamená, že náklady na jeden defekt u koncepčních problémů rostou proporcionálně. Investice do komunikace neškáluje s objemem kódu. Investice do testování však musí. To je varování dobře známé lidem, kteří si „špiní ruce“ u všech projektových výstupů, ale nemusí být nutně plně srozumitelné pro vyšší management. Jsem hrdý na to, že stojím jednou nohou v „špinavých, kalných vodách“ reálné dodávky a druhou zůstávám v kontaktu s vizemi. Bez ukotvení rozhodnutí v reálném světě se však věci zvrhnou v chaos s jakoukoli technologií, kterou se tam pokusíme protlačit.