Něco mě na tom zaujalo natolik, že jsem to chtěla rozpitvat – je rozdíl mezi tím, když model umí napsat kód, a tím, když ho napíše tak, aby se s ním dalo žít v produkci.
Co Addy vlastně navrhl
Addy Osmani publikoval sadu "slash" příkazů pro Claude Code — krátké příkazy, které agenta donutí projít jasně definovanými inženýrskými fázemi: spec (specifikace), plan (plán), build (implementace), test (testování), review (code review) a ship (nasazení). Myšlenka je jednoduchá: agenty často chovají jako juniory, snaží se najít nejkratší cestu k viditelnému diffu místo toho, aby dělaly „neviditelnou práci“, která odděluje prototype od produkčního kódu.
Součástí jsou takzvané anti-rationalization tables — předpřipravené protiargumenty na přesvědčivé výmluvy, které si agenti sami vymyslí, aby přeskočili kroky. Ty tabulky vlastně vnášejí firemní inženýrské praktiky (pomyslete na Hyrum's Law — zjistíte, že každý se nakonec bude spoléhat na jakékoli chování, které je pozorovatelné, takže je lepší ho řídit než doufat, že ho model "náhodou" nedělá) do použitelné sady pravidel.
Proč mi to dává smysl
Mně osobně přijde důležité rozlišit schopnost generovat funkční kód od schopnosti generovat udržitelný kód. Jasné fázování nutí model uvažovat o testech, přehledech a omezeních PR velikosti, místo aby jen posílal „funkční“ změny. To snižuje technický dluh a zvyšuje šanci, že výsledný artefakt přežije CI a code review.
Zároveň je to hezký příklad, jak se z promptů stává design procesu: neříkáte agentovi jen "napiš to", ale vpisujete do něj normy (trunk-based development, limity na velikost PR apod.), které organizace opravdu chtějí dodržovat.
Co mi v tom chybí a co může selhat
Několik věcí z oznámení (tak jak jsem je viděla) neplyne: jak se to měří — existují nějaké metriky, že PR prošlo review s menším počtem oprav, nebo že méně věcí prasklo v CI? Jak to funguje v multi-agentním workflow, kde jeden agent plánuje a jiný implementuje? A hlavně: modely se dají „oblafnout" — pokud jsou anti-rationalization odpovědi příliš obecné, agent si může najít způsob, jak je obejít.
Praktická nálepka: tvorba a údržba těchto pravidel taky něco stojí. Kdo bude psát a validovat anti-rationalization tabulky? Jak často je aktualizovat, když se změní interní procesy? To jsou drobné, ale důležité náklady.
Co bych ráda viděla dál
Reálné ukázky dopadu: anonymizované příklady PR před a po aplikaci těchto příkazů, metriky typu počet revertů, průměrný čas do zeleného CI nebo počet nedokončených úkolů. Integraci s CI tak, aby se workflow stalo částí pipeline (a ne jen návodem v dokumentu). Více otevřených šablon napříč modely než jen pro Claude — právě knihovny typu AGENTS.md a CLAUDE.md na GitHubu ukazují, že se formuje komunita, která to chce používat konzistentně.
Krátký příklad, jak může anti-rationalization vypadat (hypoteticky): agent navrhne přeskočit testy, protože „změna je malá"; protiargument v tabulce trvá na minimální sadě unit testů a navrhuje jednoduchý smoke test pro kritické cesty. Je to drobná disciplína, ale funguje jako brzda proti chytrému, ale krátkozrakému generování kódu.
Závěrem: tahle práce není o tom, aby modely přestaly být kreativní — je o tom, aby se kreativita potkala s odgovorností. Mně se líbí, že postupy přecházejí z blogpostů a experimentů do opakovatelných vzorů, které týmy mohou adoptovat a měřit.