Přejít na obsah|Přejít k hlavnímu menu|Přejít k vyhledávání
Před rokem jsem na tomto blogu psal o tom, jak AI ovlivňuje vývoj software. Tehdy jsem se ptal kolegů i lidí z komunity, kolik času jim chatboti a kopiloti šetří. V té době jsme se bavili hlavně o tom, jestli AI ve vývoji pomáhá. Dnes už tahle otázka zní skoro naivně, neboť aktuálně vidíme všude kolem sebe, jak AI násobně zrychluje procesy vývoje software. Otázka, která mě zajímá teď, zní: jak s AI vyvíjet, aby výsledek byl opakovatelný, auditovatelný a kvalitní?
Část odpovědí mi přinesly zkušenosti z projektu, na kterém jsme tento přístup postupně budovali, a rád bych se o ně s vámi nyní podělil. Vznikl z toho pohled na dvě cesty, kterými se dá při vývoji s AI vydat – a proč je jedna z nich výrazně udržitelnější.
Domnívám se, že využití AI ve vývoji může být buď řízené, nebo neřízené. To neřízené je to, kterému se často – a poměrně pejorativně – říká vibe-coding. Je to stav, kdy se vývojář nechá umělou inteligencí vést, přijímá její návrhy bez hlubšího ověření a v podstatě jen „odklikává” výsledky. Může to fungovat pro prototypy nebo jednorázové skripty, ale pro produkční vývoj to není udržitelné.
Řízený přístup, který nazývám agentický vývoj, stojí na jiném principu. Vývojář systematicky buduje kontext, ve kterém řešení vzniká. Na AI agenty se pak dívá jako na funkce, které z dobře připravených vstupů vyrábí kvalitní výstupy. Vzniká opakovatelný proces, který je možné auditovat a iterovat.
Abych nemluvil jen v abstrakcích, popíšu konkrétní případ z projektu pro jednoho z našich zákazníků, kde vyvíjíme systém pro řízení výrobních procesů.
Na tomto projektu vznikl požadavek na video archiv. V systému je N kamer, které sledují výrobní proces. Pro každou kameru může existovat M archivačních úloh. Video se ukládá po hodinových blocích do objektového úložiště, ke kterému má klient přímý přístup. Klíčová náročnost spočívala v přehrávání – navigace v archivu je zcela libovolná: skoky libovolné velikosti tam i zpátky, přehrávání různými rychlostmi dopředu i dozadu.
Dříve bych za takovou funkcionalitou viděl půl roku práce pro velký tým. V tomto případě se většina práce stihla přibližně za 3 sprinty.
Celý proces měl pět fází, ve kterých hrála umělá inteligence zásadní roli.
Na začátku stála hrubá specifikace o rozsahu přibližně 1,5 stránky A4. Nebylo to nic rozsáhlého – byly tam vypsané use cases s krátkým popisem. Důležité ale je, že ten dokument zachycoval i základní očekávání koncového uživatele.
Toto zadání jsme vzali a s pomocí AI jsme začali brainstormovat architekturní návrh. Vzniklo ADR (Architecture Decision Record) v Markdownu, na kterém jsem pracoval asi 4 hodiny – základní objekty, diagramy a představa o tom, jak budou komponenty komunikovat. Potom jsem to nechal „nabalovat jako sněhovou kouli”: AI generovala návrhy technologií, které by splnily požadavky, porovnávala je mezi sebou a já jsem validoval, zda porovnání odpovídá faktům. V rámci této fáze vznikl také draft logiky přehrávání v klientovi.
Velmi rychle na to vznikl prototyp – backend v Pythonu, frontend ve Flutteru. Prototyp sloužil k validaci logiky přehrávání a samozřejmě to nebylo správně napoprvé. Identifikovali jsme špatné předpoklady a iterovali mezi ADR a prototypem, až jsme nakonec dospěli k funkčnímu a udržitelnému návrhu.
Jakmile byla technická specifikace připravená, doplnili jsme kontext agenta popisem repozitářů a již hotových částí systému. Poté jsme mu zadali rozpad prací. Vygeneroval nám featury (první úroveň backlogu), které se dále pokoušel rozpadat na tasky. Ne vše fungovalo dokonale – rozpad na tasky byl méně spolehlivý než rozpad na featury – ale výrazně to urychlilo přípravu backlogu oproti klasickému groomingu v celém týmu.
Výsledné tasky s jasně připraveným kontextem šlo zadat přímo agentům. Tato fáze byla u první funkcionality ještě částečně manuální, ale u dalších se ukázalo, že agenti dokážou na základě připraveného zadání odvést většinu práce.
Výše popsaný postup násobně urychlil vývoj. Domnívám se, že ve všech fázích je možné ponechat minimálně 80 % práce na AI. Činnosti jako plánování a design (jednoho balíku práce) již není nutné provádět v celém týmu. Zvládne je jedna zodpovědná osoba, která brainstormuje s AI. Výstup potom validuje s produktovým a technickým vedením projektu.
Tato proměna má své stinné i pozitivní stránky. Moc mě baví spolupracovat s lidmi, ale ruku na srdce: komunikace mezi lidmi spoustu věcí brzdí. My lidi jsme chytří a máme chuť, ale někdy jsme unavení, nemáme dobrý den a vznikají tření, která proces zpomalují. Další překážky jsou čistě mechanické: jsem si jistý, že mnoho vývojářů zažilo ty nepříjemné chvíle na groomingu, kde několik lidí sleduje jednoho nešťastníka, který potí slova do pole Description v issue trackingu při plánování práce. Limitují nás meetingy, klávesnice, nebo to, že zrovna nedokážeme najít vhodná slova. AI dokáže tyto zádrhele v dosavadních procesech vývoje odstranit.
Věřím tomu, že se nejedná o žádný soumrak lidské spolupráce při vývoji software. Očekávám, že se koordinace lidí a spolupráce posune o úroveň výš – k alignmentu nad produktovými prioritami, high-level architekturou apod.
Není překvapivé, že naše postupné směřování od experimentu k funkčnímu procesu se neobešlo bez komplikací. Toto jsou ponaučení, která jsme si odnesli:
Pokud jste se rozhodli stavět vlastní proces agentického vývoje, to nejdůležitější, co byste si měli zapamatovat je: kontext je všechno. Naše práce bude čím dál víc o tom, že shromáždíme popis řešení a z tohoto popisu pak efektivně vedeme agenty i sami sebe. Tak jak jsme různými zásahy do kódu rozšiřovali výsledné řešení o další rozměry, je nyní nutné zapsat do kontextu všechny relevantní skutečnosti a naše očekávání.
Co to znamená v praxi? Kdykoliv nám zákazník sděluje svůj požadavek, musíme si okamžitě dělat poznámky v podobě textu.
Jakmile problém převezmeme a začneme uvažovat nad jeho řešením a zasazovat ho do širšího kontextu systému, musíme tuto úvahu také zapsat. Osobně se mi nejlépe osvědčil styl ADR a formát Markdown – jednoduchý, verzovatelný a strukturovatelný.
S takto připraveným kontextem pak můžeme zkusit zadat vývoj umělé inteligenci.
Bude to fungovat napoprvé? Možná ne. Výsledek nemusí být úplný, objem změn může být příliš velký na to, abychom ho strávili, nebo prostě dostaneme něco jiného, než jsme chtěli.
K překonání těchto problémů slouží dva nástroje, které dobře známe z každodenní vývojářské práce – jen je teď aplikujeme na jiné úrovni.
Iterace je přímočará. Vezmeme to, co nefunguje, vrátíme se ke specifikaci, s pomocí agenta ji upravíme na základě získané zkušenosti a necháme agenta řešení přepracovat, nebo jej zkusíme vygenerovat znovu.
Jenže i iterace má své limity. Popisy požadavků a ADR začnou bobtnat a zvětšovat se. Najednou jsou to mnohastránkové nepřehledné dokumenty, se kterými si ani agent neporadí, neboť stejně jako člověk nemá neomezeně široké kontextové okno.
Tehdy přichází na řadu rekurze – rozpadneme (ideálně také s pomocí AI) velkou featuru na několik, pokud možno nezávislých řezů, z nichž každý má svůj vlastní popis požadavků a ADR. Agenta pak zaměříme vždy jen na tu část, která je zrovna podstatná. Tento proces se dá rekurzivně opakovat do libovolné hloubky.
Tenhle princip dobře známe z klasických vývojových procesů – říká se mu backlog refinement nebo grooming. Je to činnost, která vždy byla extrémně důležitá, ale nikdo ji moc nechtěl dělat, protože stála hodně úsilí a času. Dnes je to nutný předpoklad efektivního agentického vývoje a AI s ním dokáže významně pomoci.
Kam to celé podle mě směřuje? Zaměřím se na vývoj jedné z potenciálně mnoha features nějakého systému, neboť škálování vývoje paralelním zapojením více vývojářů lze odtud snadno odvodit. Při zpracování jedné featury procházíme většinou následujícími fázemi:
S využitím AI se tento proces promění následujícím způsobem:
Děkujeme za váš zájem o odběr našeho newsletteru! Pro dokončení registrace je potřeba potvrdit vaše přihlášení. Na zadaný e-mail jsme vám právě zaslali potvrzovací odkaz. Klikněte prosím na tento odkaz, aby bylo vaše přihlášení dokončeno. Pokud e-mail nenajdete, zkontrolujte prosím složku nevyžádané pošty (spam) nebo složku hromadné pošty.
