Proč jeden prompt nestačí: Jak skutečně pracovat s AI kódem

Pojďme si to malovat. Je jedenáct večer. Potřebuješ dodělat funkci a už hodinu se handrkujes s AI asistentem. Pošleš prompt, dostaneš odpověď. Odpověď vložíš. Něco funguje. Něco ne. A vůbec nevíš, co je co.

Nezní to povědomě?

Tady je ta nepříjemná pravda: většina vývojářů používá AI agenty tak, jako byste používali kalkulačku, kdybyste museli mačkat tlačítka sami. Jo, počítá to. Ne, vlastně nevíš, co se tam děje uvnitř. A když ti to nevyhnutelně vyplivne něco, co zní plausibilně, ale je subtlně rozbitý, jsi to ty, kdo to musí debugovat o půlnoci.

Týmy, které opravdu posílají do produkce fungující kód, na to šly jinak. Přestaly přemýšlet o AI asistentovi jako o hře typu prompt-odpověď. Místo toho staví systémy — smyčky — které nechávají AI dělat malé, bezpečné a ověřitelné změny průběžně. Výsledky mluví za sebe: míň regresí, míň přetečení kontextu a diffy, které se dají actually číst.

Problém s "všechno najednou"

Jeden velkej prompt má svou lákavou jednoduchost. "Napiš mi autentifikaci." Hotovo. "Refaktoruj celej modul na nový API." Bum. Připadá ti to produktivní. Připadá ti to rychlý.

Dokud nejní.

Vem si, co se vlastně stane, když hodíš na AI velkej úkol naráz. Nejdřív narazíš na zeď kontextu. Většina kódbází, na kterých stojí za to pracovat, se nevejde целком do paměti AI. Takže začne hádat, co nevidí — dělá předpoklady o závislostech, konvencích pojmenování, architektonických vzorech, které můžou bejt úplně špatně.

Pak přijde ten review problém. Když ti AI vrátí pětisetřádkovej diff, co s ním vlastně uděláš? Prolítneš ho. Důvěřuješ mu víc, než bys měl, protože AI působí sebejistě. Sloučíš to a doufáš.

Věc ohledně naděje: není to proces kontroly kvality.

Třetí problém je nejlistější. AI modely jsou trénovaný na to bejt užitečný, což znamená, že jsou trénovaný znít sebevědomě. Když ti AI dá kód, kterej vypadá rozumně, pravděpodobně vypadá rozumně proto, že byl trénovanej na rozumným kódu. To neznamená, že je správně pro tvůj specifickej kontext. Bez brány kontrolující skutečné chování se sebevědomí stává jediným kritériem přijetí — a sebevědomí je hrozný měřítko správnosti.

Vstupuje smyčka

Alternativa zní skoro zklamaně jednoduše: místo jednoho velkýho promptu dělej spoustu malých kroků. Po každým kroku si ověř práci. Pak pokračuj dalším.

Jednej. Kontroluj. Opakuj.

To je agentic loop v její nejzákladnější podobě, a pokud ti to zní příliš obviously na to, aby o tom stálo za to mluvit, vem v potaz, že většina týmů to pořád nedělá. Kouzlo není v konceptu — je v disciplíně jeho důslednýho prosazování.

Tady je, jak to vypadá v praxi. Místo aby ses AI ptal "oprav všechny padavý testy", ty bys:

1. Spustil test suite a identifikoval první selhání
2. Požádal AI, aby opravil jen to jedno selhání
3. Znovu spustil testy pro ověření opravy
4. Pokud projde, přešel na další selhání; pokud selže, změna se revertuje
5. Opakoval, dokud nezůstane nula selhání — nebo dokud AI neohlásí, že nemůže pokračovat

Všimni si, co se tady děje. Každá změna je nezávisle ověřená. Když se něco rozbije, víš přesně, který edit to způsobil. Když něco funguje, zůstane. Smyčka staví progress ratchet — ověřenej pokrok — místo hromady doufám-že-to-je-správný kód.

Tři pravidla, který to rozjedou

Ne všechny smyčky jsou stejný. Špatně navržená smyčka je horší než žádná — může běžet do nekonečna a dělat kosmetický změny, nebo může sebejistě rozbíjet věci, zatímco působí, že funguje. Smyčky, který opravdu dodávají, mají tři nesmlouvavý charakteristiky.

Za prvé: automatizovaná brána, se kterou se nedá diskutovat. Brána je tvůj detektor pravdy. Může to bejt test suite, kterej prochází, linter vracející nulu chyb, type checker potvrzující žádný type mismatch, nebo automatizovaný srovnávání screenshotů chytající vizuální regrese. Kritickej bod je, že brána je deterministická a objektivní. Nemůžeš se kolem ní vyargumentovat, ani AI ne. Pokud kód bránou neprojde, nestalo se to — revertnuto, ne sloučeno.

To je těžší, než to zní, protože to znamená zavázat se k budování infrastruktury pro tvoje brány. Potřebuješ opravdový testy s opravdovým pokrytím. Potřebuješ, aby type checker skutečně běžel. Potřebuješ, aby CI/CD pipeline byla first-class citizen, ne afterthought.

Za druhý: jedna změna na iteraci. To působí bolestně pomalu, když jsi zvyklej na velký prompty. Proč neopravit všechny type errors najednou? Proč neadresovat každé linting varování v jednom průchodu?

Protože když toho spoustu změníš najednou a něco se rozbije, nemáš tušení, co to způsobilo. AI může opravit tři věci, rozbít jednu, a celkovej výsledek vypadá pozitivně — takže se to sloučí. Teď máš regresi bez jasnýho viníka.

Jedna změna, jedno ověření, jeden verdikt. Je to pomalejší na krok, ale monumentálně rychlejší celkově, protože každej krok je nezávisle reviewable a revertable. Když se něco rozbije v produkci, použiješ git bisect na přesnou změnu, která to způsobila, místo debugování nedokončenýho paskvilu provázaných úprav.

Za třetí: upřímná stop podmínka. Smyčka bez stop podmínky je buď nekonečná, nebo se zastaví arbitrárně. Oboje je špatný. Stop podmínka by měla bejt měřitelný signál: počet testů klesne na nulu, zpráva "nic k vylepšení" ve dvou po sobě jdoucích kolech, evaluační skóre se plateauuje.

Disciplína tady je akceptovat upřímný přeskočení. Když je kód genuinně dobrej, správnej výstup je "nezměnil jsem nic — nic nebylo potřeba měnit." Smyčka, která ví, kdy je hotová, má cenu deseti, co pořád melou marginální změny, aby působily produktivně.

Co smyčky chytí, co prompty přehlédnou

Dovol mi konkrétní příklad, proč to má smysl.

Představ si self-improvement loop běžící na produkčním admin panelu. Smyčka dělá screenshoty každý stránky, ptá se AI, aby identifikoval a opravil jeden usability problém na kolo, spouští type checks a linting, a pokračuje, dokud nenajde co zlepšit.

Přes několik kol tahle smyčka vytvoří desítky genuinních vylepšení. Čistý UI vylepšení. Lepší chybový hlášky. Chytřejší empty states.

Ale nejcennější oprava nebyl polish — byl to bug. V jednom kole screenshot harness odhalil, že settings stránka renderuje frameworkův full-page crash screen. Tady je ta věc: ten crash byl úplně client-side. API health checks byly zelený celou dobu, protože API bylo v pohodě. Člověk reviewující screenshoty by možná přes tu stránku scrollnul, nebo by ji označil za přechodný rendering glitch.

Automatizovaná smyčka to chytila, extrahovala skutečnou chybu ("Cannot read properties of undefined (reading 'memes')"), vystopovala ji k state-merge bugu v component lifecycle a opravila ji u kořene. A protože harness teď ví, že má kontrolovat ten crash screen pattern, chytí celou třídu takovejch bugů navždy.

Tady je ten payoff. Smyčka nedělá jen práci — staví ratchet, kterej akumuluje ověřený vylepšení a zabraňuje ověřeným regresím se vrátit.

Proč to záleží pro tvůj tým

Když stavíš startup, nemáš čas na AI nástroje, který vyžadujou constant babysitting. Když jsi vývojář, nemáš trpělivost pro nástroje, který přinášej víc bugů než oprav.

Agentic loops řeš obě starosti. Dělají AI asistenci genuinně spolehlivou tím, že nahrazujou důvěru ověřováním. Dělají pokrok měřitelným tím, že dělaj každou změnu accountable. Dělaj debugging tractable tím, že zajišťujou, že když se něco rozbije, víš přesně kdy a proč.

Nejlepší na tom? Tahle approach není omezená na generování kódu. Stejnej pattern funguje pro automatizovaný testování, hledání bugů, security scanning, aktualizaci dokumentace, správu závislostí — všude, kde jsi používal one-shot prompty, kde bys profitoval z kontinuálního ověřování.

Jestli letíš sólo nebo vedeš tým, otázka není, jestli používat AI pro kódování. Otázka je, jestli ho používáš způsobem, kterej tě opravdu zrychlí — nebo jen dělá dojem, že jsi busy, zatímco akumuluješ technický dluh.

Smyčky nejsou jediná cesta, jak s AI pracovat. Ale jsou jediná cesta, kterou jsem viděl škálovat na seriózní produkční práci bez akumulace hřbitova plausibilních ale špatných kódů.

Tví move.