Oponentura vývoje software: kontrola v rolích

Oponentura vývoje software je kontrola hotové funkce z pohledu někoho, kdo ji nepsal. Ve velké firmě to dělají lidé z různých oddělení, u nás tyto role (účetní, právník, uživatel nebo útočník) hrají AI agenti a o výsledku rozhoduje člověk. Oponentura hledá chyby i tam, kam testy nedosáhnou: jestli jsme vůbec chtěli správnou věc. Autor je na takovou kontrolu ten nejhorší, protože obrazovku, kód i zákon čte očima svého záměru. V článku popíšu, jak oponenturu v rolích děláme při vývoji Bondie, kdy která role běží a co se stane s tím, co najde.

Pro příklad třídění jednoho nálezu použijeme tyto hodnoty:

Oponentura vývoje software – kdo hraje role

Kontrolu hotové funkce z pohledu jiných lidí dělá ve velké firmě oddělení kvality, interní audit a právní oddělení. Malý tým takové lidi u každé změny k dispozici nemá. Role u nás proto provádějí AI agenti, každý s oddělenými vstupy. Co se s nálezem stane, ale určuje člověk (víc v oddílu Rozhoduje člověk).

Princip je stejný pro kolegu z účtárny, externího právníka i agenta. Oponentura přitom nenahrazuje test, protože se ptá na něco jiného: test řekne, jestli funkce dělá, co jsme chtěli, kdežto oponentura hledá, jestli to sedí se zákonem a s účetnictvím, jestli to odpovídá tomu, jak back office opravdu pracuje, a jestli to nejde zneužít. Celkový rámec zásad popisuje článek Zásady vývoje software.

Sedm pohledů na jednu funkci

Hotovou funkci kontroluje až sedm AI agentů v rolích a každý se ptá jinak:

• účetní hlídá částky, daň a zaokrouhlení a to, jestli jde všechno zpětně dohledat a doložit,
• právník porovnává funkci se zákonem o dluhopisech, s daněmi, AML a GDPR (co se musí uchovat a co nesmí jít smazat),
• uživatel zkouší, jestli nový kolega zvládne funkci první den jen podle průvodce a kde se zasekne zkušený back office ve spěchu,
• útočník volá akci dvakrát, po stornu, po závěrce nebo pod rolí, která na ni nemá právo,
• revizor kódu kontroluje, jestli je údaj na jednom místě, akce v transakci a jestli se netestuje jen šťastná cesta,
• UX designér hledá na obrazovce jednu jasnou hlavní akci a to, jestli je vidět, co se dělo a co je další krok,
• nezávislý přepočet spočítá úroky a daň znovu jen z emisních podmínek a pravidel výpočtu, která sepsal a schválil člověk z emisních podmínek a zákona, ne z kódu, bez znalosti aplikace.

Roli přepočtu podrobně popisuji v článku Testování finančních výpočtů.

Každá role dostane jen své vstupy

Než agent v roli začne kontrolovat, dostane zadání: co se změnilo a co má zkontrolovat. Zdůvodnění autora ani jeho poznámky k řešení nedostane, protože by ho přesvědčily. Z podkladů dostane jen to, co by měl k dispozici skutečný člověk v té roli:

• právník popis funkce a texty, které uvidí uživatel, ne kód,
• účetní výstupy a přehledy s možností jen číst data, bez záměru autora,
• útočník rozhraní a účty jednotlivých rolí, kód nevidí,
• uživatel běžící aplikaci s ukázkovými daty a průvodce,
• přepočet vstupy případů a sepsaná pravidla výpočtu, bez očekávaných hodnot.

Každá role má vlastní deník nálezů, do kterého se jen připisuje. Při dalším běhu ho dostane spolu se zadáním, takže ví, co už řekla a jak to dopadlo. Zamítnuté nálezy nehlásí znovu (dokud se funkce nezmění) a u opravených ověří, že oprava drží.

Pojistka proti tomu, aby role usnula, je jednoduchá: ticho není výsledek. Role, která nic nenašla, napíše, co prošla, a přidá aspoň tři nápady na vylepšení. Jednou za čas dostane i podstrčený známý případ chyby, aby se ověřilo, že ho pořád najde.

Kdy oponentura běží

Kdyby všechny role běžely nad celou aplikací pořád, přinášely by každý den stejný výsledek za stejnou cenu. Co se kontroluje, proto řídí změna:

• po každé dokončené funkci lehká revize kódu a kontrola dopadů (co dalšího funkce zasáhla, např. průvodce, nastavení nebo ukázková data); nálezy se jen zapíšou,
• v noci role podle toho, na co změna sahá (funkce s penězi dostane účetní a přepočet, funkce s doklady právníka, funkce s rozhraním útočníka), včetně toho, co je po proudu změny,
• jednou měsíčně to, co se mění zvenčí, ne v kódu (právník kontroluje citace proti platnému znění zákonů a novelám),
• po milníku průzkum celé aplikace s čerstvým pohledem, bez ohledu na to, co se změnilo.

Nejvíc nám v praxi přináší pravidlo „po proudu“. Např. když se změní výpočet kupónu, prověří se i srážková daň, její odvod a závěrka, protože z kupónu čerpají.

Třídění nálezů: dopad, četnost a cena opravy

Když agent v roli dokončí kontrolu, zapíše nálezy do svého deníku a každý nález se pak třídí podle toho, co s ním udělat. Dostane tři čísla od 0 do 3. Dopad, když se neopraví (3 = peníze nebo daň špatně, porušení zákona, únik údajů; 0 = kosmetika). Četnost (3 = denně u každého uživatele role; 0 = jen teoreticky). Cena opravy jako přibývající složitost (0 = použije existující cestu nebo něco ubere; 3 = nový stav, nastavení nebo obrazovka). Levná oprava má cenu 0 až 1, drahá 2 až 3. Body se spočítají jako dopad × četnost − cena opravy:

Dejme tomu, že agent v roli najde chybný údaj v přehledu bez vlivu na peníze (dopad 2), který back office uvidí při každé výplatě úroků (četnost 2), a oprava znamená nový sloupec (cena 2). Body jsou 2 × 2 − 2 = 2, takže nález jde jako nápad do plánu. Kdyby stejný problém šel vyřešit úpravou existujícího textu (cena 0), vyjde 2 × 2 − 0 = 4 a opraví se hned.

Cenu opravy odečítáme z jednoho důvodu. Oponentura má sklon k tomu, že produkt jen bobtná: každá role najde něco, co by „bylo lepší“, a za rok máme dvojnásobek nastavení. Bez souhlasu majitele produktu proto smí za týden přibýt jen pár nových prvků (stav, nastavení, dialog) a ze dvou možných oprav vyhrává ta levnější.

Nálezy v číslech

Ke dni psaní článku (10. 10. 2026) jsme za dobu vývoje zapsali 724 nálezů; aktuální čísla jsou na stránce Vývoj v číslech. Nálezem je i nejasný text nebo návrh. Dopadly takhle:

Vidíme, že opravou skončilo 455 / 724 = 63 % nálezů a 167 / 724 = 23 % jsme předali do plánu nebo k rozhodnutí člověku (nápad, který se udělá při práci v oblasti, nebo otázka s doporučenou variantou). Zamítnutých je jen 30 / 724 = 4 %. Je to dáno tím, že zamítnutí je u nás záměrně drahé (viz další oddíl).

Zamítnout jde jen s důkazem

Kdo nález posuzuje, často posuzuje kritiku vlastní práce. Proto tvrzení „tohle chyba není“ nesmí být levné. Jinak je to u nálezu, který chybou je, ale nestojí za složitost. Tam stačí jedna věta proč. Pro tvrzení „chyba to není“ platí jen dva důkazy: test, který nález zkouší a projde (reprodukce selhala), nebo rozpor s ručně spočítanými a ověřenými případy či se zákonem s citací. Test, který autor napsal ke své funkci, důkazem proti účetní není.

Když chce někdo zamítnout nález s vysokým dopadem, nebo když si dvě role odporují, je nález sporný. Technický spor nejdřív posoudí další agent, který o věci předem nic neví. Dostane nález i protiargument s důkazy a vrátí verdikt s odůvodněním. Poslední slovo má ale člověk, který vidí obojí. Při retrospektivě si navíc náhodně vybere několik zamítnutých nálezů a zkontroluje, jestli důkaz opravdu drží.

Rozhoduje člověk

Tabulka bodů připraví návrh, co s nálezem udělat. Nález pak testem ověřuje a o výsledku rozhoduje člověk (human in the loop). AI agent nesmí bez člověka změnit chování pro uživatele, práva, peníze ani nic nevratného. Takový nález jde jako otázka s doporučenou variantou do seznamu práce, o kterém píšu v článku Řízení backlogu vývoje. Hned jde opravit jen jasná chyba, která je vratná a dostane test pojmenovaný podle nálezu. I tu ale vidí člověk dřív, než se dostane do verze pro zákazníka.

Na rolích také sledujeme, kolik užitku přinesou na cenu běhu. Role, která dlouho nic podstatného nenajde, poběží méně často nebo dostane užší zadání. Podle mého názoru je méně rolí, které něco najdou, lepší než mnoho rolí, které jen souhlasí.

Závěr

Hotovou funkci u nás kontrolují AI agenti v rolích, kteří ji nepsali a dostanou jen vstupy své role, takže je zdůvodnění autora nepřesvědčí. Nález má body za dopad, četnost a cenu opravy, návrh výsledku tedy dávají předem pravidla a zamítnout jde jen s důkazem. O změnách chování, práv a peněz ale vždy rozhoduje člověk.