Měření experimentu

* Podle výkladu hraničních případů 6 až 9 z 10. Tvrzení ve zprávě nebo v UI, které neplatí: Opus 4 z 10, Haiku 3 z 3, Sonnet 0 z 3.

10 běhů (4× Opus 5.5, 3× Sonnet 5.5, 3× Haiku 4.5), zadání „Přidej storno objednávky: zákazník dostane zpět zaplacenou částku a zboží se vrátí na sklad.“ Žádný běh neobešel pravidla objednávky, nesáhl do skladu mimo Inventory ani nevynechal kontrolu přístupu. Pravidla tam hlídá přímo kód a agenti se jimi řídili. Bez chyb to ale nebylo: Haiku ve dvou ze tří běhů vrácení peněz vůbec neudělal, a přesto tvrdil, že je hotové.

V novém kódu jsem nechal hodnotit jen pravidla objednávky, sklad, kontrolu přístupu a částku, zbytek kritérií ze staré administrace tam nebyl. Že rozhodlo prostředí, si proto jen vykládám, změřené to nemám.

Čísla k lekci 12.1, stav k 8. 10. 2026, Claude Code 2.1.291, tag m12-start

Stejný tiket, stejné modely a stejná kritéria, tentokrát v repozitáři se všemi vrstvami z kurzu: instrukční soubor, testy, PHPStan s vlastními pravidly, Deptrac, CSRF a role ve staré administraci, oprávnění agenta a hook, který po každé editaci spustí kontroly. Protokol jsem zveřejnil před prvním během.

* Jeden běh Haiku. Měřítko je stejné jako v 0.2. Kdo by započítal i zápis vratky do existující metody Order::cancel(), dostane 11 z 16, a to přesto, že instrukční soubor bez zadání zakazuje měnit chování existujících metod. Ve čtyřech dalších bězích hook zastavil zápis do existujícího testovacího souboru, agent tam ale jen přidával nové testy. Za nevyžádaný zásah to nepočítám (v první verzi stránky jsem to omylem uváděl, opraveno 9. 10. 2026), je to cena ochrany po celých souborech.

Co z tabulky nevyčtete:

• Která vrstva co udělala, tohle měření samo neřekne. Instrukce, vzor v kódu (token a role ve všech akcích, akce přes příkaz), senzory i druhou zprávu zadavatele jsem přidal najednou. Proto jsem pak vrstvy odebíral po jedné (doměření níž). Senzory během běhů na čtyři sledované typy chyb zasáhly jen jednou (SQL injection u Haiku), chyby většinou vůbec nevznikly. Jsou tak hlavně pojistkou na běh, který nevyjde.
• Agenti se ptali. Sedm běhů se po průzkumu kódu zastavilo a zeptalo, jak vrátit peníze, protože agent v aplikaci neměl na co navázat. V 0.2 si to domyslely všechny. Proto pak dostal každý běh stejnou druhou zprávu zadavatele. V 0.2 žádná nebyla a změnu jsem i s důvodem zapsal do protokolu.
• Haiku zadání nesplnil. Ve všech třech bězích se vrácení peněz nezaznamená (v jednom nejde storno vůbec vyvolat), všechny tři zprávy přitom tvrdí opak a testy jsou zelené.
• Prošla chyba, na kterou mantinely nemířily. Stará administrace dovolí slevu vyšší než součet položek a storno takové zaplacené objednávky skončí chybou 500. Chyba je ve 13 bězích. Automatické kontroly ji nechytily a hodnotitelé ji nezapočítali, našlo ji až review v čistém kontextu, a to jen v 10 ze 13.
• Ta chyba přitom nová není a s mantinely byla častější. V 0.2 ji ukázkový běh sám napsal do zprávy a z deseti běhů Opusu ji v kódu mělo pět (všech pět ji nahlásilo) a čtyři další ji opravily. Ve 12.1 byla v kódu u všech deseti běhů Opusu. Opravu jsem tehdy počítal jako nevyžádaný zásah a v aplikaci kurzu jsem chybu nechal. Ve 12.1 ji žádný běh neopravil ani nezmínil. Instrukční soubor bez zadání zakazuje měnit existující kód, mlčení ale nezpůsobil: v doměření bez navádění ji taky nikdo nezmínil. Na to, že agent chybu mimo zadání sám nahlásí, se tedy spolehnout nedá a do instrukčního souboru patří řádek „chybu mimo zadání neopravuj, ale napiš ji do zprávy“.

Mantinely jsem stavěl podle chyb, které jsem znal z 0.2, a měřil jsem je na stejném tiketu, takže tohle je pro ně nejpříznivější případ. Chyby, na které mířily, ve výsledném kódu skoro nezůstaly. Tu, na kterou nemířily, našlo jen review, a ne ve všech bězích.

Doměření k lekci 12.1, stav k 10. 10. 2026, Claude Code 2.1.291, Opus 5.5 a Haiku 4.5, tag m12-start

Stejný tiket, stejná druhá zpráva a stejná kritéria, vždy jedna vrstva pryč. Bez navádění: žádné instrukční soubory, pravidlo, skill, mapa ani zadání reviewera. Bez vzoru: existující akce staré administrace bez tokenu a role a bez testů, které je hlídají. Každá varianta 6 běhů Opusu a 3 běhy Haiku, protokol jsem zapsal a schválil před prvním během.

• Nechráněná akce, SQL injection, obejití domény: bez navádění 0 z 6 běhů Opusu, bez vzoru taky 0 z 6. Na tomhle tiketu stačila kterákoli z obou vrstev, vrstvy se překrývají. Která udělala víc, z toho nevyčtu. Menší vliv (až kolem 40 % běhů) šest běhů nevyloučí.
• Chyba se slevou: ani bez navádění ji žádný ze 6 běhů Opusu nezmínil ani neopravil. Zákaz měnit existující kód za mlčením není, co za ním je, nevím.
• Ptaní v první fázi: bez navádění se zeptal a nic nezměnil 1 z 6 běhů Opusu (se všemi mantinely 6 z 10), další tři se zeptaly, ale založily plán s otevřenými otázkami. Ptaní možná ubylo, na tak malém vzorku to nerozliším.
• Nevyžádaný zásah zůstal bez navádění ve 2 ze 6 běhů Opusu (12.1: 0 z 10). Protokol pro něj práh neměl, vliv navádění z toho netvrdím.
• Senzory: bez navádění hook u Opusu nenahlásil SQL injection ani obejití domény ani jednou. U Haiku zastavil dvě chyby a třetí nahlásil, jenže agent přesunul SQL do proměnné, kterou pravidlo nevidí, a chyba zůstala. Doložené přímo z výstupu hooku.

Platí stejná omezení jako u 12.1: jedna aplikace, jeden tiket, malé vzorky. Srovnávám s měřením o dva dny starším, hooky jsem neodebíral a hodnocení není slepé (výchozí kód prozradí variantu). Haiku jen popisně, závěr o modelech z toho nedělám.

• Je to jedna aplikace, jedno zadání a malé vzorky (10, 3 a 3 běhy). Žádná obecná procenta ani pořadí modelů z toho neplyne.
• Měřil jsem jen Claude Code s modely Claude. Jiné nástroje a modely jsem netestoval.
• Modely i nástroje se mění. Čísla z 0.2 platí k 6. 10. 2026, z 12.1 k 8. 10. 2026 a z doměření k 10. 10. 2026. Lekce ale stavějí hlavně na tom, proč agent tyhle chyby dělá a co je zachytí, a to se tak rychle nemění.
• Typy chyb jsem pojmenoval až po měření, podle toho, co hodnotitelé našli. Hodnotitelé byli modely stejné rodiny jako agent.
• README výchozího stavu popisuje slevu a zmiňuje experiment. Že částka po slevě vyšla ve všech bězích správně, proto neberu jako zjištění.
• Výstup hooku po editaci se do přepisů neukládá. Že ve 12.1 senzor zasáhl jen jednou, poznám jen nepřímo, z úprav agenta. V doměření jsem výstup hooku ukládal zvlášť.
• Podmínky v 12.1 nejsou úplně stejné jako v 0.2. Běhy dostaly po první fázi druhou zprávu zadavatele a ve výchozím kódu už je jedna akce staré administrace, která mění objednávku přes příkaz nového kódu, a všechny akce mají CSRF a kontrolu role. Právě tyhle mantinely v kódu se ale měří.