Přejde vývoj softwaru na autopilota? AI vygeneruje většinu kódu, ale lidský úsudek nenahradí

Vibe coding funguje skvěle na rychlé prototypy nebo interní nástroje. Pokud ale v produkčních aplikacích vsadíte na přístup Andreje Karpathyho „zapomeňte, že kód vůbec existuje“, brzy narazíte. Vývoj mobilního bankovnictví nebo streamingové platformy totiž nestojí jen na generování řádků kódu.

Vibe coding vyvolal obří boom. Najednou to vypadá, že si vlastní aplikaci za odpoledne dokáže vytvořit každý. U interních nástrojů to tak být může. Můžete si sestavit třeba jednoduchý generátor reportů, který místo vás jednou týdně pošle shrnutí dat a doporučení šéfovi do Slacku. Nebo si vyrobit kalkulačku, která vám pomůže vypočítat adekvátní cenu za produkt.

Jenže u systémů, na kterých stojí reálné peníze nebo citlivá data, prostě nemůžete řadu věcí přeskočit. AI vám sice vygeneruje kód, ale nevyřeší za vás architekturu, bezpečnost, integrace ani testování. Těžko bude sama hlídat výkon, analytiku nebo UX. A rozhodně za vás neuhlídá projektové know-how zachycené v dokumentaci, architektonických rozhodnutích nebo doménovém slovníku.

Tam AI sama o sobě nestačí. Potřebuje kvalitní kontext, dobré zadání, přizpůsobené workflow a průběžnou validaci člověkem. Právě tady končí vibe coding a začíná Agentic Development Lifecycle (ADLC), tedy přístup, který do celého procesu vývoje systematicky zapojuje AI agenty.

AI na produkční kód, odborníci nezmizí

Kde tedy vibe coding v dohledné době vývojáře nahradí? U tvorby prototypů a jednoduchých nástrojů z velké části brzy. Vznik a provoz kvalitního produkčního softwaru ale zatím nepokryje. Zatímco vibe coding staví na rychlém generování kódu bez potřeby rozumět tomu, co se děje pod kapotou, ADLC dává agentům jasné zadání s kontextem, kontrolami a člověkem odpovědným za výsledek.

Přečtěte si také:

Půl roku vývoje lze zkrátit na dva týdny. Bez AI a vibe codingu nebudete konkurenceschopní, říká Čuprův ex-parťák

Spíš než konec tradičního vývoje tak probíhá proměna celého odvětví. Vývojáři tráví méně času ručním psaním kódu a více času věnují vytváření technického zadání, přípravě kontextu, návrhu architektury, orchestraci AI agentů, review a validaci výstupu. To ale neznamená, že se vývoj zjednodušil na psaní promptů. Kvalitní výstup vyžaduje dobré workflow, znalost nástrojů a schopnost poznat, kdy AI generuje správné řešení a kdy jen přesvědčivě vypadající výstup.

Časem bude sto procent produkčního kódu generovat AI, ale to neznamená, že zmizí potřeba technických lidí. Naopak vzroste potřeba těch, kteří rozumějí tomu, co se staví, proč se to staví, dokážou rozpoznat kvalitní řešení a budou umět zabránit vzniku technického dluhu.

Člověk má náskok v dobrém úsudku

V čem spočívá hlavní výhoda vývojáře oproti současné technologii? Jeho náskok stojí hlavně na jeho úsudku, znalosti technického kontextu a odpovědnosti. AI totiž dokáže bleskově navrhnout pět variant řešení. Rozhodnout, která z nich dává smysl pro konkrétní produkt, týmovou architekturu i byznys, ale musí člověk. 

Důležité tedy je umět AI kočírovat. Připravit jí kontext, zadat práci ve správné granularitě, nastavit kontroly a průběžně vyhodnocovat, co funguje a co ne. V Ackee jsme si pro zavádění AI do vývojového procesu proto vytvořili vlastní ADLC framework, který definuje, kde a jak AI zapojit a co má naopak zůstat v kompetenci člověka.

Největší lidská přidaná hodnota je totiž v definování správného problému, produktovém myšlení, navrhování architektury, technických trade-offech (hledání kompromisů mezi rychlostí, cenou a kvalitou), validaci UI a UX z pohledu reálného uživatele a schopnosti vyhodnotit, kdy už aplikace může do produkce. 

Vývoj s AI agenty pod přísným dozorem

Trend tedy míří k takzvanému spec-driven developmentu, který místo ručního psaní kódu spoléhá na přesné specifikace a AI agenty. AI agentovi nestačí jednoduchý prompt typu „udělej login“, ale potřebuje detailní zadání, kontext celé codebase, architektonické mantinely, testovací scénáře a jasnou definici hotového výsledku.

Přečtěte si také:

Ekonomiku postavenou na AI agentech ovládne ten, od koho nepůjde odejít. Začíná snaha, aby to nebylo pár gigantů

Vývoj se proto posouvá od ruční exekuce k řízení systému, ve kterém AI agenti pomáhají implementovat, ale člověk určuje cíl, pravidla a kontroluje výsledek. Aby to fungovalo, musí vývojářský tým kontinuálně budovat projektový kontext, upravit workflow, zavést automatizované kontroly a vytvořit feedback loop, který opakovaná selhání AI převádí do lepších zadání, checklistů, testů nebo dokumentace.

Důležitou roli v tom hrají i techniky, které dříve často znamenaly výrazné úsilí navíc. Například TDD (Test-Driven Development, tedy psaní testů ještě před samotným kódem), architektonická rozhodnutí, projektový glosář nebo automatizované end-to-end testování. AI dnes navíc dokáže s jejich tvorbou a průběžnou údržbou výrazně pomoct, takže už nejde o drahý nadstandard, ale o nezbytný základ pro agentický vývoj.

Jak vypadá zadání pro agenta v praxi

Takto vypadají zkrácená zadání dvou funkcí investiční aplikace, kterou vyvíjíme. Agent je dostane spolu s přístupem ke kódu.

První zadání: Důvod zamítnutého zrušení pokynu:

• Hlavička: Odkazy na ticket, návrhy obrazovek pro Android i iOS, zápis z analýzy a projektový glosář. V glosáři jsou jednou provždy definované pojmy jako „rušený pokyn“ a „rušící pokyn“.
• Co (TL;DR): Pokud broker zamítne zrušení pokynu, klient uvidí důvod v detailu pokynu a dostane notifikaci, která ho k němu dovede.
• Proč (TL;DR): Dnes se pokyn bez upozornění vrátí do původního stavu. Klient nevidí žádné vysvětlení a nepozná, zda se vůbec něco stalo.
• Klíčové omezení (TL;DR): Důvod není součástí dat, která aplikace pro detail pokynu běžně načítá, a musí se dohledat zvlášť.
• Shrnutí: Když broker odmítne zrušení pokynu, klient uvidí v detailu pokynu důvod. Dnes se pokyn tiše vrátí do původního stavu a klient neví, co se stalo. Hlavní omezení je, že důvod je uložený jinde, než kde se aplikace běžně dívá, a musí ho dohledat zvlášť.
• Problém: Situace popsaná z pohledu klienta a nejčastější důvod, proč k zamítnutí dochází.
• Řešení: Nový řádek v detailu pokynu a notifikace, která klienta dovede přímo k němu. Součástí je diagram toho, co se děje mezi klientem, aplikací a brokerem.
• Uživatelské příběhy: Pět vět ve tvaru „Jako klient, kterému broker zamítl zrušení, chci vidět důvod, abych pochopil, proč je pokyn pořád aktivní.“
• Kritéria úspěchu: Dvanáct tvrzení, která jdou ověřit. Když o zrušení nikdo nežádal, řádek se vůbec nezobrazí. Rozhoduje vždy poslední žádost o zrušení. Detail pokynu, který nikdo nerušil, nepošle na server ani jeden dotaz navíc.
• Okrajové případy: Tabulka deseti situací a očekávaného chování. Třeba když se důvod nepodaří načíst, detail se vykreslí celý a chyba se jen zapíše do logu.
• Rozhodnutí: Odkud se data čtou a proč, co počítá server a aplikace to nesmí přepočítávat, a co je sdílený kód obou platforem. Patří sem i otevřený předpoklad, na který se čeká odpověď, a co se změní, když vyjde jinak.
• Mimo rozsah: Co se měnit nemá, tedy seznam pokynů, přístupová práva a obsah notifikace. A dvě starší chyby, na které tým při analýze narazil a které se řeší zvlášť.

Druhé zadání: Nákup dluhopisu, jehož úpis je vyprodaný

• Hlavička: Odkazy na ticket, zadání dodavatele platformy, zápis z analýzy, návrhy obrazovek pro Android i iOS, specifikace průvodce nákupem a projektový glosář.
• Co (TL;DR): Pokud je primární upisování dluhopisu vyčerpáno (vyprodáno) ještě před datem emise, mobilní nákupní proces na to klienta upozorní dialogovým oknem a převede příkaz na standardní tržní nákup s platností omezenou na datum emise nebo na období po něm.
• Proč (TL;DR): Dnes může klient zadat pokyn do úpisu, i když už je vyprodaný. Takový pokyn pak buď neprojde, nebo se provede jinak, než klient čekal.
• Klíčové omezení (DL;DR): Týká se pouze dluhopisů. O tom, zda je úpis vyprodaný, rozhoduje server, aplikace to sama nepozná.
• Poznámka: Když je úpis dluhopisu vyprodaný ještě před datem emise, aplikace klienta upozorní a objednávku přepne na běžný nákup na trhu. Ten bude platit nejdřív od data emise. Funkce se týká jen dluhopisů a řídí ji nový údaj ze serveru, který říká, jestli je úpis plný.
• Problém: Klient může zadat pokyn do úpisu, který už je vyprodaný. Takový pokyn broker buď zamítne, nebo se později nečekaně provede na trhu za jiných podmínek, což klienta může nepříjemně překvapit na účtu.
• Řešení: Rozhodovací diagram o dvou otázkách: je datum emise v budoucnu a je úpis plný? Když ano, klient uvidí upozornění s volbou Zpět nebo Pokračovat. Pokračování otevře běžný nákupní formulář s omezenou platností. Formulář nenabídne pokyn platný jen na jeden den a nejbližší možné datum platnosti je datum emise.
• Uživatelské příběhy: Tři věty, například „Jako klient chci předem vědět, že se moje objednávka provede až po zahájení obchodování na trhu, aby mě nepřekvapilo zamítnutí nebo zpoždění.“
• Kritéria úspěchu: Osm tvrzení, která jdou ověřit. Upozornění se zobrazí ze všech míst, odkud jde nákup začít. Dluhopisy, kterých se změna netýká, se chovají přesně jako dnes. Finanční údaje aplikace nepočítá, jen zobrazí hodnoty ze serveru. Texty odpovídají návrhům obrazovek do písmene.
• Okrajové případy: Čtyři situace. Třeba když pravidla burzy omezují, jakou platnost pokynu smí formulář nabídnout.
• Rozhodnutí: Odkud se informace o vyprodanosti bere a jak ji aplikace vykládá. Co počítá server. A zapsané architektonické rozhodnutí, proč mobilní aplikace řeší vyprodaný úpis jinak než web. Patří sem i to, které části původního zadání z rozsahu vypadly.
• Mimo rozsah: Akcie a primární úpisy akcií, detail dluhopisu a filtr ve vyhledávání, výpočet úroku v aplikaci a změny na serveru a webu, které dodává dodavatel platformy.

Agent z takového zadání ví, co má postavit, kde jsou hranice a podle čeho se pozná hotový výsledek. Člověk pak při review kontroluje výsledek proti stejným kritériím.

Pozor na technický dluh

Pokud budete používat AI jen k rychlejšímu generování kódu, zrychlí se také vznik technického dluhu. Pokud ji ale zapojíte do dobře připraveného procesu, zvedne kvalitu ve stejném čase. Pomůže s psaním testovacích scénářů, TDD workflow, end-to-end testy, dokumentací, architektonickými rozhodnutími, analýzou edge casů i druhou nezávislou kontrolou kódu.

AI tak nepomáhá jen s rychlostí psaní kódu, ale především násobí dovednosti samotného týmu. Zlevňuje a zpřístupňuje osvědčené postupy, které byly vždycky správné, ale v praxi příliš drahé nebo časově náročné. Pořád je k tomu ale potřeba vědomý vklad vývojářů. Bez jejich zkušeností AI jen rychleji vyrobí nekonzistentní chaos.

Přečtěte si také:

Programátorům jsme zakázali psát kód, některé jsme museli propustit. AI vyhraje, hlásí další české IT firmy

• Chcete mít Lupu bez bannerů?
• Chcete dostávat speciální týdenní newsletter o zákulisí českého internetu?
• Chcete mít k dispozici strojové přepisy podcastů?
• Chcete získat slevu 1 000 Kč na jednu z našich konferencí?

Staňte se naším podporovatelem

Chci se stát podporovatelem