Ako mi AI nafukuje zadanie a ako ho zmenšujem

Rozširovanie scope

Scope je rozsah zadania, teda čo všetko má vzniknúť a čo už nie. Jazykové modely ho vedia výborne rozširovať. Na lekcii Vibe Coding Summer som to účastníkom vysvetľoval tak, že AI rado pridáva, ale veľmi nerado osekáva.

Na jednu stranu to na nich mám rád, lebo domyslia veci, na ktoré som nemyslel. Na druhú stranu sa potom dlho cítite veľmi produktívne. Pribúdajú funkcie, appka rastie, všetko je boží, a pritom nemusíte riešiť správny problém. Zistíte to, až keď opravujete niečo, čo už bolo hotové, alebo agent rozbije vec, na ktorú vôbec nemal siahať.

YAGNI

YAGNI je skratka z programovania: You Aren't Gonna Need It, nebudete to potrebovať. Navrhujete len to, čo potrebujete teraz. Pripomienky, spúšťače, limity a špeciálne stavy pre zriedkavé prípady nechávate na neskôr, a väčšinou ich nikdy nedorobíte, lebo netreba.

Pri checkliste to znamenalo jedno pravidlo pre bežný prípad a nič viac. Ak by sme niečo z toho škrtnutého raz potrebovali, stačí jeden riadok na konci návrhu s poznámkou „neskôr, ak treba“. Hneď ako to napíšete, je jasné, že to do prvej verzie nepatrí.

Súbor s pravidlami

Agent v Claude Code aj Codexe si pred prácou prečíta súbor s pravidlami, ktorý sa volá AGENTS. Mám v ňom dve vety práve proti nafukovaniu. Prvá hovorí, že agent vždy začína najmenším použiteľným postupom a nepridáva formáty, cvičenia ani architektúru, ktoré zadanie nechce. Druhá, že po odovzdaní toho, o čo som žiadal, a po kontrole skončí a nerobí vylepšenia navyše.

K tomu tam mám pravidlo podľa rizika. Malá a jasne ohraničená úloha nedostane žiadnu špecifikáciu ani plán, agent ju rovno urobí. Ťažší proces nechávam na veci, ktoré sú naozaj veľké, nejasné alebo zasahujú viac systémov naraz.

Model a úsilie

Niekedy sa zadania nedrží samotný model. V lete som dva a pol dňa skúšal nový Opus 5 a vrátil som sa k predchádzajúcej verzii 4.8, lebo bol strašne výrečný a zadania sa moc nedržal. Keď vyvíjam, mám úsilie, teda ako dlho model nad úlohou premýšľa, vždy na extra high. Na zložitejší kód lacnejší model skoro nepoužívam.

Varianty s jednou zmenou

Nafúknuť sa dá aj dizajn. V októbri sme v labe porovnávali varianty detailu AI Workoutu v našej appke a každý variant niesol naraz niekoľko zmien. Odporúčaný variant potom spustil iný agent a mňa to naštvalo, lebo som z celého labu chcel jedinú vec z iného variantu: dnešný dizajn s dvoma zbalenými sekciami hore.

Odvtedy platí, že každý variant vychádza z dnešného stavu a mení jednu myšlienku. Keď sa mi niečo páči, AI to nemá rozniesť po celej stránke. Upraví presne tú vec, ktorú pomenujem, a ostatné mi len navrhne.

Reštart projektu

Keď je zadanie už nafúknuté a ja sa točím v kruhu, väčšinou to poznám podľa toho, že začínam nadávať agentovi. Vtedy je lepšie ísť sa prejsť. Potom si nechám zrozumiteľne popísať aktuálny stav, zmenším scope, alebo celú vec zmažem a začnem odznova.

Ľudia, ktorí s vibe codingom začínajú, bežne robia jeden projekt aj päťkrát. Ja tiež. Hlavne v prompt-to-code nástrojoch sa dá dostať do stavu, keď len pálite tokeny a nikam sa neposúvate. Reštart je potom lacnejší než ďalšie opravy, lebo popis toho, čo už funguje, vám AI napíše za pár minút.

Postup pri zmenšovaní zadania

1. Pýtam sa na bežný prípad. Čo potrebuje väčšina ľudí väčšinu času? Všetko ostatné ide na riadok „neskôr, ak treba“.
2. Píšem, čo nechcem. Keď v zadaní chýba hranica, AI si ju vymyslí za behu. Pri pláne kampane by stačila veta „bez akcií, ktoré treba vyrábať, a bez mojej osobnej účasti“.
3. Nechávam pravidlá v súbore. YAGNI a „žiadne vylepšenia navyše“ mám v súbore s pravidlami, aby som ich nemusel opakovať v každom chate.
4. Jedna zmena na jeden pokus. Pri dizajne aj pri kóde, aby som vedel, čo vlastne funguje.
5. Keď nadávam, prestanem. Nechám si popísať stav, zmenším scope a pokračujem, alebo začnem znova.

Ako napísať zadanie od nápadu cez idea file až po specifikáciu, sme rozpísali na blogu Aibility.