Prekompiluj, nerefaktoruj. Ako staviam produkčný softvér s AI, nie appku, ale systém, ktorý ju kompiluje

Štyri dni pred termínom som mal v rukách len systém, ktorý kompiluje. Žiadnu appku. V starom mindsete v tomto bode appku už pár týždňov testuješ a ladíš. Tu bol návrh hotový, ale kód appky neexistoval. Spustil som desaťhodinový produkčný build s AI a večer sme mali hotovú produkčnú appku pre klienta. Bol to zážitok: život na hrane technológie, kde veríš systému, ktorý si postavil, a nie kódu, ktorý vidíš.

Vyše pätnásť rokov navrhujem, dizajnujem a programujem appky so zakladateľmi firiem. Po štyroch rokoch práce v tíme na budovaní appiek som sa dostal späť do delivery role: znova som mohol sám uchopiť end-to-end proces, zamyslieť sa nad AI a reinventnúť, ako appka vzniká. Toto je článok o tom, ako vytváram úplne nové produkčné appky na greenfielde pre klientov, vytvorené iba s AI: jeden klientsky projekt od deviatich workshopov po desaťhodinový produkčný run.

#Tri veci, ktoré sa zmenili

Nešiel som cestou vibe-codingu, kde appku buduješ postupným promptovaním a každá zmena je ďalšia záplata. Bez architektúry rozhodnutej na začiatku sa z toho v istom bode stane chaos a technický dlh, ktorý ťa v projekte zastaví. Namiesto toho som si postavil systém, ktorý reinventuje tri veci, na ktorých stál vývoj softvéru pätnásť rokov, a ktoré sú v tomto procese gamechanger.

• Appka je na zahodenie. Neprogramujem nič. Mením definíciu produktu na vrchu a agenti ju za pár hodín prekompilujú na čistý kód nanovo, bez technického dlhu, so všetkými úpravami. Na tomto projekte appka vznikla desaťkrát nanovo a do kódu som nesiahol ani raz. Zmena scopu, ktorá rozbila dátový model a v kóde by stála týždeň refaktoringu, tu stála deň a jeden build.

• Klient testuje od prvého týždňa, nie na konci. Najväčšie riziko klasického vývoja: produkt je takmer hotový a klient až pri testovaní zistí, že niečo chýba alebo je zle navrhnuté. Tu mal od prvého týždňa v rukách appku na nerozoznanie od produkčnej, v takmer plnom scope, dával feedback a na druhý deň videl novú verziu. Šesťkrát. Kým vznikla skutočná produkčná appka, produkt, scope aj dátový model už boli overené.

• Jeden človek, jeden prompt, desať hodín. Celú produkčnú appku naprogramoval jeden autonómny agentic run na mojom počítači, z jedného promptu, bez jedinej otázky. Exekúcia celého projektu trvala mesiac. Pred érou agentov by rovnaký rozsah trval tri mesiace a potreboval produktového manažéra, dizajnéra a dvoch až troch inžinierov.

O akú appku ide: klient, firma v automotive na Slovensku s vyše 50 zamestnancami, si u mňa objednal appku na správu interných procesov a k nej customer-facing modul, kde si firemní zákazníci spravujú vlastné flotily. Zákazky, vozidlá, termíny, servisná história, notifikácie. Štyri používateľské role, každá s vlastným rozhraním, osem modulov, dve fázy.

Ako som to celé postavil, je zvyšok článku.

#Pred prvým buildom

##Deväť workshopov

Samotnej stavbe predchádzalo deväť product discovery workshopov s klientom, každý na 60 až 90 minút. Cieľ bol pochopiť požiadavky, preskúmať biznis procesy firmy a jasne pomenovať problémy, ktoré má vlastný softvér vyriešiť. Riešili sme dve vetvy: návrh nových interných procesov a softvéru, ktorý ich ponesie, a zákaznícky modul toho istého softvéru, lebo firme záleží na dlhodobej spokojnosti svojich zákazníkov. Po workshopoch som vedel, čo stavať.

Už od prvého workshopu mi AI pomáhala informácie ukladať a dávať im jasnú štruktúru. Tá bola počas celého projektu hlavným zdrojom pravdy pri rozhodovaní o návrhu systému.

##Dva harnessy

Tu je dobré miesto na zavedenie dvoch pojmov, ktoré sa budú v článku opakovať. V projekte totiž existujú dva harnessy a každý robí niečo iné.

Knowledge harness je môj vlastný systém na usporiadanie informácií zo všetkých workshopov s klientom a na ich syntézu do finálnych výstupov: roadmapy a feature špecifikácií. Zároveň je to operačný systém projektu: zápisy zo stretnutí, rozhodnutia aj s dôvodmi, mapa ľudí u klienta, celá komunikácia. Z toho istého stavu mi pripraví podklady na stretnutie, e-mail klientovi, ponuku aj zmluvu, a na otázku „prečo sme sa rozhodli takto" odpovie s odkazom na konkrétny zápis. Ako funguje zvnútra, si nechám na samostatný článok.

Coding harness je súbor textových dokumentov v repozitári aplikácie, ktoré definujú pravidlá pre coding agenta: ako programovať frontend, ako backend, aká je architektúra, ako sa testuje a ako sa nasadzuje. Je to prompt, ktorý agent dostane namiesto zadania. Práve o ňom je zvyšok tohto článku. Keď ďalej píšem len „harness", myslím tento coding harness.

Vzťah medzi nimi je jednosmerný: workshopy idú do knowledge harnessu, z neho vypadne roadmapa, špecifikácie a dátový model, a tie vstupujú do coding harnessu ako zadanie, čo sa má postaviť.

##Tech stack

Poďme sa pozrieť na môj tech stack:

• Agent – Claude Code, rozšírený o vlastné skills pre každú fázu projektu na syntetizovanie a management: discovery, roadmapa, spec, build, design/code audit.
• Frontend – React 19 s TypeScriptom a Tailwindom v4, buildovaný cez Vite, bez UI knižnice: každý komponent je vlastný a prečo, vysvetlím pri design systéme. V návrhovej fáze bežal sám, bez backendu, s IndexedDB ako lokálnou databázou.
• Backend – Laravel 13. Frontend naň sedí cez Inertiu, takže appka je monolit bez API vrstvy: controller pošle dáta stránke ako props a formulár ich pošle späť.
• Komunikácia a integrácie – E-maily cez Laravel Mail a Notifications (aktivácia účtov, mesačné reporty, pripomienky), v produkcii cez Resend. SMS cez BulkGate, bez balíka, len tenký vlastný kanál nad HTTP klientom. PDF cez dompdf na generovanie interných dokumentov. Plánovač na mesačné uzávierky a pripomienky termínov. Napojenie na SoftApp, systém servisu na sklad a fakturáciu, so servisnými záznamami párovanými cez ŠPZ.
• Infraštruktúra – PostgreSQL, Redis s Horizonom na fronty, Fortify na autentifikáciu, privátny objektový storage na faktúry a výpisy, monitoring cez Pulse a Nightwatch, testy v Peste, hosting Laravel Cloud.

Jedno pravidlo v harnesse stojí za zmienku: každý problém sa rieši first-party balíkom od Laravelu, nič iné sa bez môjho súhlasu a záznamu v decision logu neinštaluje. Agent tak nemá kde improvizovať s knižnicami.

#V číslach

#Ako generovať appku desaťkrát tak, aby vyzerala a fungovala vždy rovnako?

A navyše zakaždým aj s úpravami z klientovho feedbacku. Bez odpovede na túto otázku sa takto iterovať nedá. Nechceš dať klientovi desiatykrát do ruky appku, ktorá vyzerá vždy inak.

Odpoveďou je coding harness, náš kompilátor. Na jeho úrovni je definované všetko, čo musí medzi buildmi ostať stabilné. Design systém: ako aplikácia vizuálne vyzerá, aké má interakčné patterny a pravidlá a ako derivovať nové komponenty, ktoré v ňom ešte nie sú. Pravidlá kódu: ako presne programovať frontend, ako backend, aká je architektúra, aká je testovacia stratégia, ako sa píšu testy a ako sa nasadzuje. A nakoniec chrbtica aplikácie: celý scope funkcionalít a špecifikácia každej z nich. Všetko podstatné je raz definované na úrovni harnessu.

Ďalšie tri kapitoly idú po týchto vrstvách: design systém, pravidlá frontendu a roadmapa so špecifikáciami.

#Design systém aplikácie

Chcel som reinventnúť, ako vzniká úplne nový produkt, od prvého nápadu po produkciu. Tak začnime na začiatku: ako som vytvoril design systém bez toho, aby som otvoril Figmu a začal kresliť obrazovky.

##Vibe-coding ako hľadanie vizuálu

Predstavu som už mal: aký dashboard firma potrebuje a akým vizuálnym štýlom má hovoriť. Zameriaval som sa na funkčný dizajn, nie na estetiku, a na tomto základe som začal vibe-codovať dashboard pre majiteľa firmy. (Ukážky nižšie sú preskinované UI a katalóg komponentov z reálneho projektu, prefarbené na fiktívnu firmu, aby som ich mohol ukázať.)

Vibe-coding má v mojom procese presne toto miesto: hľadanie vizuálu, nie stavba produktu. Nebolo to nič zložité a netreba pri tom premýšľať nad best practices pre frontendový stack. Nový priečinok, otvorený Claude Code a prompt, nech vytvorí základný React projekt a v ňom stránku dashboardu majiteľa s farbami, fontami a dizajnovým smerom, ktoré som mu určil. Chcel som admin dashboard s navigačným sidebarom vľavo a typickým adminovským obsahom vpravo: tabuľky, taby, vyhľadávanie, pár štatistík.

Prvú verziu som potom viackrát iteroval a ladil, kým sa mi výsledok vizuálne páčil. Základný dashboard bol možno 15 až 20 promptov. A bol interaktívny: komponenty reagovali na kliknutie, nebola to statická obrazovka.

Takto vznikli celkom štyri varianty dashboardu s rôznym typom vizuálu. Vybral som ten, ktorý sa mi na projektové účely páčil najviac, a z neho derivoval tri ďalšie stránky: detail entity s informáciami, tabuľkami a akčnými tlačidlami, zoznam entít v tabuľke a formulár na vytvorenie novej entity. Tieto štyri stránky obsahovali väčšinu interakčných prvkov, ktoré sa v aplikácii opakujú ako základné stavebné prvky. A dali sa ukázať klientovi a pýtať si feedback na vizuál aj interakčné patterny skôr, než existovala jediná reálna funkcionalita.

##Zo štyroch stránok UI knižnica komponentov

Bola to ručná práca na dva dni explorácie a stavby základu dizajnu aplikácie. Ďalší krok bol kľúčový: nechal som Claude, nech z tých štyroch vibe-codených stránok vyextrahuje všetky UI komponenty a spraví z nich plnohodnotnú UI knižnicu komponentov pre aplikáciu. Aby sa dali vidieť a testovať, vytvoril som zároveň stránku Showcase, kde sa dajú všetky prelistovať, spolu s popisom: fonty, farby, whitespace a na čo ktorý komponent slúži a ako ho použiť.

Knižnica má jeden účel: aby coding agent staval frontend konzistentne naprieč celou aplikáciou a ja som mal plnú kontrolu nad jej vizuálom. Skúšal som aj jednoduchšiu cestu, jeden design.md dokument s tokenmi: farby, fonty, paddingy. Nefungovalo to. Agent sa vizuálu nikdy nedržal a v každom rune derivoval iný typ aplikácie, nikdy nie konzistentný. Vlastná knižnica komponentov, hotová ešte pred prvým buildom, sa ukázala ako jediný spoľahlivý spôsob, ako mať rovnaký frontend naprieč desiatimi runmi.

Pár čísel, nech je to hmatateľné. Z tých štyroch vibe-codených stránok Claude vyextrahoval 46 komponentov. Dnes, po produkčnom rune, ich má katalóg 83: 63 primitívov (tlačidlá, polia, pilulky, karty, tabuľky, drawer, modal), 4 kompozity (app shell, sidebar, hlavička stránky, formulárová karta) a 16 doménových komponentov ako časová os zákazky alebo tabuľka servisnej histórie. Ani jeden z tých 37 nových som nenapísal ja, všetky derivoval agent počas buildov.

##Prečo žiadna cudzia UI knižnica

Tu je namieste povedať, prečo v projekte nie je žiadna cudzia UI knižnica. Nikdy som ich nepoužíval, vždy som si radšej dizajnoval a programoval vlastné komponenty. UI knižnice sú pre mňa z estetického aj funkčného hľadiska limitujúce: zanášajú do kódu chaos a skrytú komplexitu a tlačia ti vlastný opinionated smer, ako má rozhranie vyzerať. Mám rád čisté riešenia na mieru. A dnes to už nie je trade-off medzi rýchlosťou a čistotou: coding agent nakóduje komponent so všetkým, čo potrebujeme, na počkanie a bez záťaže, ktorú by so sebou priniesla knižnica.

##Dizajn kontrakt: ako sa systém používa

Keď boli komponenty nakódované, spísal som do harnessu dizajn kontrakt. Nie je to popis vzhľadu, ten už žije v kóde a na stránke Showcase. Je to návod, ako sa systém používa a kde sú jeho hranice. Má sedem častí:

• Kontrakt agenta – šesť krokov v pevnom poradí, ktoré agent prejde pri každej obrazovke: vyber šablónu stránky, vyber komponenty podľa účelu, derivuj len keď nič nesedí, nikdy nevymýšľaj tokeny, každý nový komponent daj do Showcase, drž lokalizáciu.
• App shell a plátno – jeden kanonický shell pre všetky role, žiadny top bar, biele plátno, sépia len v draweroch, pevné rozmery sidebaru, obsah cez celú šírku. Tri šablóny stránok (dashboard, zoznam s detailom, centrovaný formulár), z ktorých sa každá nová obrazovka odvodí. Drawer len na dashboarde na rýchly náhľad, modal na jednu sústredenú otázku. Jediný breakpoint, kde sa shell prepne do mobilného režimu.
• Výber komponentov – tabuľka zámer → komponent: hlavná akcia, sekundárna, stavový štítok, vyhľadávanie, formulárové pole, KPI dlaždica, prázdny stav, chyba. Agent najprv pomenuje, čo chce, a až potom siahne po komponente. Plus pravidlá pre tabuľky: poradie stĺpcov, akcie v riadku, radenie na serveri.
• Recepty na deriváciu – osem tvarov (tlačidlo, pole, prepínač, pilulka, dlaždica, plocha, overlay, kompozit) a pre každý postup, z čoho a ako odvodiť nový variant.
• Kontrakt ikon – veľkosť a hrúbka ťahu podľa kontextu, farby, dvojtónové aktívne ikony v navigácii.
• Anti-patterny – zoznam vecí, ktoré sa v tomto alebo v sesterskom projekte aspoň raz dostali do kódu: žiadny raw hex, žiadne nové akcentové farby, žiadne oranžové tlačidlá, žiadne ťažké tiene, žiadny font-bold, žiadna cudzia UI knižnica, žiadne vymyslené varianty.
• Keď je dokument zle – ak pravidlá bránia rozumnému riešeniu, je to signál na eskaláciu, nie povolenie ich porušiť.

##Auto-audit: agent si dizajn kontroluje sám

Kontrakt sám o sebe nestačí. Coding agenti driftujú: keď stavajú kus frontendu alebo celú appku, po pár obrazovkách začnú syntetizovať z pamäte namiesto toho, aby čítali Showcase. Tlačidlo „Vytvoriť" sa objaví v top bare, ktorý neexistuje, plátno dostane sépiu namiesto bielej, formulár si vymyslí vlastnú šírku. Každá z týchto vecí sa reálne stala. Preto má harness audit skill.

Na konci každého epicu beží design audit ako samostatný subagent. Načíta dizajn kontrakt, tokeny design systému a stránku Showcase, potom prejde postavené obrazovky a porovná ich s nimi: shell a navigácia, šablóny stránok, farba plátna, tokeny a anti-patterny, výber komponentov, ikony, lokalizácia a či má každý nový komponent ukážku v Showcase a riadok v katalógu. Každý nález má súbor, riadok a pravidlo, ktoré porušil, bez citácie sa nález neuznáva. Audit sám neopravuje, len hlási v troch stupňoch: blokujúce, opraviť, drobnosť. Oprava ide v ďalšom kroku a epic nie je hotový, kým nemá nula blokujúcich nálezov.

##Aktualizácia Design Systému

A odpoveď na otázku, kto udržiava design systém a showcase: agent, lebo mu to vynucujú tri pravidlá a audit ich kontroluje.

• Pravidlo 80 percent – Pre každý kúsok UI musí nájsť najbližší existujúci komponent, a ak sedí aspoň na 80 percent, použije ho a doladí cez props. Nesmie ho forknúť.
• Derivačné recepty – Keď nič nesedí, ide podľa receptu pre daný tvar: od ktorého súrodenca zdedí API, ktoré tokeny smie použiť, kam súbor uložiť. Nový overlay môže byť len drawer alebo modal, tretí druh neexistuje.
• „Ukáž, čo si postavil" – Každý nový komponent dostane v tom istom commite ukážku v Showcase a riadok v katalógu COMPONENTS.md. Audit nahlási každý, ktorému to chýba, takže katalóg sa nikdy nerozíde s kódom.

Sekcia anti-patternov v kontrakte vznikla práve z týchto auditov: každý riadok v nej je chyba z kalibračných buildov, ktorú agent reálne vyprodukoval a ktorá sa už nezopakovala.

Výsledok: keď agent staval layout alebo UI, vždy vedel, ako na to. Ani raz nešiel tvoriť UI podľa vlastného uváženia, vždy podľa vopred definovaných pravidiel.

Design systém máme. Teraz sa pozrime, ako definovať harness tak, aby generoval konzistentný frontend.

#Frontend aplikácie

##Aplikácia bez backendu

S hotovým design systémom sa môžeme pustiť do definície frontendu. Backend nechajme zatiaľ bokom. Chceme čo najskôr dostať aplikáciu do rúk, vyskúšať si ju a iterovať na tom, čo vidíme. Backend v tomto bode len pridáva komplexitu a čas, ktorý by sme my museli definovať a agent strávil jeho stavbou.

Ale ako dostať do ruky funkčnú aplikáciu bez backendu? Trik je nasimulovať backend na frontende, to coding agenti zvládnu hravo. Prvá verzia každej mojej aplikácie je preto vždy bez backendu: obsahuje iba frontend a ako databáza jej slúži lokálna pamäť prehliadača, pre web je to IndexedDB. Všetka funkcionalita, ktorá by inak žila na backende, je zatiaľ na frontende. Netrápi nás, že to raz bude treba preniesť: keď si po X iteráciách schválime finálnu podobu aplikácie, pridáme do harnessu pravidlá pre písanie backendu, starú appku zahodíme a spustíme nový build s backendom - jednoduché, ako vymeniť cartridge v tlačiarni.

##Harness súbor po súbore

Ako to celé vyzerá v coding harnesse? Pozrime sa naň súbor po súbore. V ranej fáze projektu, keď sme stavali len frontend, obsahoval priečinok docs/ tieto dokumenty s vopred definovanými pravidlami:

• ARCHITECTURE.md – Popisuje, z akých častí sa aplikácia skladá a ako spolu komunikujú: čo je obrazovka, čo je logika a kde sa ukladajú dáta. Zároveň funguje ako živý zoznam všetkého, čo sa v aplikácii postupne vytvorí, aby agent aj človek vždy videli aktuálny stav.
• BOUNDARIES.md – Určuje hranice medzi jednotlivými časťami aplikácie – čo s čím smie súvisieť a čo nie, aby sa kód nezamotal. Obsahuje aj zoznam technológií a prístupov, ktoré v projekte zámerne nepoužívame, aby ich agent ani nezačal pridávať.
• COMPONENTS.md – Katalóg všetkých stavebných prvkov rozhrania (tlačidlá, karty, tabuľky, formulárové polia) s popisom, na čo každý slúži. Agent má z týchto prvkov skladať nové obrazovky ako zo stavebnice, namiesto toho, aby zakaždým vymýšľal niečo nové.
• DECISIONS.md – Denník dôležitých rozhodnutí: čo sme sa rozhodli a prečo. Vďaka nemu nikto neskôr nespochybní ani omylom nezvráti voľbu, ktorá mala svoj dôvod.
• DESIGN_SYSTEM.md – Záväzný manuál pre tvorbu vzhľadu aplikácie: ako postupovať pri návrhu novej obrazovky, ktoré vizuálne pravidlá sú nemenné a čo je zakázané. Zabezpečuje, aby každá obrazovka vyzerala, akoby ju nakreslil ten istý dizajnér.
• ROUTES.md – Mapa všetkých obrazoviek aplikácie a navigácie medzi nimi, vrátane toho, ktorá rola používateľa čo vidí. Agent podľa nej vie, kam novú obrazovku zaradiť a komu ju sprístupniť.
• ERRORS.md – Jednotné pravidlo, ako aplikácia komunikuje chyby používateľovi: vždy rovnakým spôsobom, zrozumiteľne a bez prekvapení. Používateľ tak pri každom probléme dostane rovnakú, predvídateľnú skúsenosť.

Zoznam ber ako inšpiráciu, nie predpis. Každý projekt potrebuje iné pravidlá a iné veci, ktoré treba agentovi vynútiť.

Toto je alfa a omega pravidiel, ktoré agent musí dodržiavať, keď autonómne stavia aplikáciu. Nikdy ich nedávam do hlavného súboru pravidiel agenta, ako je CLAUDE.md, aby som ho nezahltil. Lepšia prax je mať v CLAUDE.md alebo AGENTS.md len index súborov: agent si prečíta ten, ktorý sa týka problému, ktorý práve rieši, či už je to architektúra, nové UI alebo niečo iné.

##Simulovaný backend a šev pod hookmi

Teraz späť k simulácii backendu. Dôležité je, ako vyzerá zvnútra. Nie je to hromada mock dát v komponentoch. Je to plnohodnotná databáza v prehliadači, napísaná presne tak, ako by vyzerala na backende. Tabuľky v IndexedDB sú jedna k jednej kópiou dátového modelu z harnessu: rovnaké entity, rovnaké názvy, každý záznam má UUID ako primárny kľúč, vzťahy idú cez cudzie kľúče. Aj to, čo v prehliadači reálne nejde, ako odoslanie e-mailu alebo SMS, sa nasimuluje. Každé takéto odoslanie sa zapíše ako záznam do tabuľky notifikácií a odkaz, ktorý by inak prišiel mailom, sa ukáže rovno na obrazovke. Napríklad taká časová os zákazky funguje rovnako, ako bude fungovať naostro, a budúci backend má pripravený šev, kam sa napojí (reálne sa to celé prepíše, ale kto vie..., skúška dobrého dizajnu architektúry).

Aby simulácia nepresiakla do UI, harness drží vrstvy oddelené a BOUNDARIES.md to vynucuje ako pravidlo importov: typy, potom databáza, nad ňou služby s biznis logikou, nad nimi hooky, a až nad tým komponenty a stránky. Komponent ani stránka nikdy nesmie importovať databázu ani službu, všetky dáta tečú cez hooky. Toto bolo v rozhodnutiach harnessu zapísané od prvého dňa s jediným dôvodom: keď príde backend, mení sa vrstva pod hookmi, nie obrazovky.

#Definovanie, čo sa bude stavať

##Roadmapa a epicy

Design systém a pravidlá pre frontend máme. Ostáva to najpodstatnejšie: čo staviame. Na to slúži roadmapa a jej špecifikácie funkcionalít. Roadmapa sa pozerá na aplikáciu zvrchu a definuje moduly (a teda epicy), ktoré treba postaviť, aby vznikla funkčná aplikácia. Každý modul sa rozpadá na niekoľko funkcionalít a každá má popísané, ako funguje.

Scope vznikol z deviatich discovery workshopov z úvodu. Roadmapa z neho má osem epicov so 64 špecifikáciami funkcionalít. Sedem epicov patrilo prvej fáze. Ôsmy, flotily, prišiel v druhej fáze, ale jeho scope bol vyskúmaný v tých istých workshopoch, žiadne ďalšie sa nekonali.

##Špecifikácie: krátke a o produkte

Každá funkcionalita má vlastný .md dokument, ktorý popisuje, ako má fungovať. Nie je to klasická špecifikácia, ako ju poznáš z raných spec-driven frameworkov. Moja má tri časti: Goal na tri až päť riadkov, dve až tri acceptance kritériá a sekciu Layout & Design, ako má byť zložené UI. Pri čisto backendovej funkcionalite tá tretia časť chýba. Do feature specov sa zvyknú písať aj ďalšie veci: dátová entita, jej vstupy a výstupy, technická špecifikácia, ako to celé naprogramovať. Ja to nerobím. Všetky pravidlá, ako niečo implementovať, sú raz a všeobecne zapísané v harnesse, netreba ich opakovať pri každej funkcionalite. Dnešné jazykové modely sú dosť inteligentné na to, aby funkcionalitu implementovali samy. Tvoja úloha je dať agentovi dobré pravidlá na úrovni coding harnessu, zvyšok nechaj na neho.

Špecifikácie tak ostávajú čo najjednoduchšie, aby sa reviewovali ľahko, bez zbytočných detailov. Jedna vec v nich ale chýbať nesmie: pri každej funkcionalite aj obrazovke je uvedené, ktorej používateľskej roly sa týka. Agent si to sám nedomyslí a v aplikácii so štyrmi rolami je „kto čo smie vidieť a urobiť" najčastejší zdroj chýb. Z tej jednej vety neskôr vyrastú testy autorizácie aj user journeys.

##Dátový model ako hotový vstup

K týmto súborom patrí ešte jeden dokument, ktorý nepatrí k pravidlám kódu, ale k produktu: dátový model. Je to jeden súbor, entities.md, ktorý popisuje všetky entity aplikácie aj s ich typmi. Má vyše tisíc riadkov a vznikal už počas workshopov v knowledge harnesse, dávno pred prvým buildom. Rovnako ako roadmapa a špecifikácie prešiel do coding harnessu ako hotový vstup, nie ako niečo, čo by agent vymýšľal pri builde.

Každá entita v ňom má rovnakú štruktúru. Napríklad zákazka:

• Účel – jedna veta, načo entita v systéme je.
• Atribúty – tabuľka polí, pri každom typ, či je povinné, z ktorého workshopu alebo rozhodnutia pochádza a poznámka, čo znamená.
• Životný cyklus – stavy a prechody medzi nimi: čaká na príjem → otvorená → hotová.
• Vzťahy – jedna zákazka patrí jednému vozidlu a jednému klientovi.

Práve z tohto dokumentu agent odvodil tabuľky v IndexedDB a neskôr migrácie v Postgrese pre backend.

#Kalibrácia: dva buildy, kým sa z promptu stal kompilátor

##Harness je prompt

Keď je definovaný design systém, pravidlá kódu a roadmapa so špecifikáciami, môže bežať prvý testovací build. To je moment, keď sa práca zhmotní. Ak je všetko správne, uvidíš funkčnú aplikáciu so všetkými UI prvkami, interakciami a funkciami z roadmapy: plne klikateľnú a na oko hotovú, postavenú v jednom autonómnom rune coding agenta. Jediný prompt, ktorý som napísal, bol „Naprogramuj celú aplikáciu podľa roadmapy". Harness je tvoj prompt. Toto bol len spúšťač.

##Prvý run je kalibračný

Prvý run býva kalibračný. Ukáže, ako dobre máš definovaný design systém, pravidlá kódu a hlavne roadmapu so špecifikáciami. Celú aplikáciu si preklikaj, všímaj si odchýlky od svojho zámeru a každú nezrovnalosť si vystopuj späť do harnessu. Ak je niečo zvláštne, s vysokou pravdepodobnosťou to opravíš pridaním pravidla, jeho úpravou alebo dodefinovaním. To isté platí pre špecifikácie produktu: keď niečo nefunguje alebo nevyzerá, ako má, väčšinou ťa od toho delí jedna či dve úpravy pravidiel v harnesse.

U mňa to boli drobnosti: dôležité komponenty, ktoré som zabudol pridať do katalógu a do všeobecných pravidiel (napríklad toastre), špecifické rozloženie sidebaru pre rôzne persony alebo detaily v tom, ako sa skladajú formulárové stránky.

##Master harness: čo agent domyslel, prenes späť

Kalibračné runy majú ešte jeden dôvod. Pri prvom builde vidíš aplikáciu prvýkrát naozaj celú, a agent pri stavbe zaplnil aj diery, ktoré ti v harnesse chýbali: doplnil komponenty, ktoré v katalógu neboli, dopísal pravidlá, urobil rozhodnutia. Niektoré z nich sú podstatné. Pre teba ako architekta a orchestrátora je preto po každom kalibračnom rune povinný review toho, čo agent do harnessu a design systému pridal. Všetko dôležité alebo zabudnuté prenes do počiatočného stavu coding harnessu, do master verzie, z ktorej štartuje každý ďalší build. Harness sa tak nekalibruje len tvojimi opravami, ale aj tým, čo si agent sám domyslel.

Potom celú aplikáciu zahodíš a spustíš run znovu. Nestojí ťa to takmer nič, len trochu času a tokenov z predplatného. A sám uvidíš: ak máš pravidlá dobre definované, aplikácia bude na 95 percent vždy rovnaká.

Jeden takýto build, ktorý staval iba frontend, trval štyri hodiny. Odporúčam naplánovať ho ako task na pozadí a ísť medzitým do fitka alebo von.

##Iterácia s klientom

Gratulujem, máš systém, kde vstup je spec, výstup je appka, a appka je disposable: zahodiť ju je lacnejšie než ju opravovať. Teraz môžeš ísť za klientom, hrať sa s appkou, pýtať si feedback a iterovať, kým nie ste obaja spokojní. Na tomto projekte som spustil šesť frontend buildov: prvé dva boli kalibračné, ďalšie štyri priniesli zásadný feedback od klienta.

Najväčšie čaro je v tom, že feedback som neimplementoval vibe-codingom priamo v kóde, ale na úrovni harnessu a špecifikácií. Starú appku som zahodil a novú vygeneroval už s feedbackom, bez toho, aby som rozbil existujúci kód.

V praxi to vyzeralo takto: klient si preklikal appku a zistil, že v tabuľkách mu chýba triedenie podľa stĺpcov. Do design systému som dopísal, že každá tabuľka musí mať interaktívne triedenie podľa stĺpcov. Ďalší build ho už obsahoval.

Triedenie tabuliek je zámerne triviálny príklad. Feedback od klienta býva väčšinou oveľa ďalekosiahlejší: inak poskladaný tok obrazoviek, iné rozdelenie práce medzi rolami, celý kus funkcionality, ktorý na workshopoch nikoho nenapadol. Cesta je ale vždy tá istá. Zmena ide do harnessu a špecifikácií, nie do kódu, a ďalší build ju už má v sebe. A práve toto je najväčšia hodnota celého systému: veľký feedback stojí rovnako málo ako malý. Klasický vývoj má cenu zmeny úmernú tomu, koľko kódu už existuje. Tu je úmerná tomu, koľko riadkov pribudne v harnesse. Že to platí aj pre zmenu, ktorá rozbije dátový model, ukáže ďalšia kapitola.

#Keď nový modul rozbije návrh: zmena bez bolesti

Jedna z najväčších nočných môr pri greenfield projekte: produkt je takmer hotový a zistíš, že musíš prekopať jeho časť. Stalo sa to aj mne. Nie preto, že by klient chcel novú funkcionalitu, ale preto, že projekt mal dve fázy a pri plánovaní prvej som nedomyslel, ako do riešenia zapadne modul druhej. Prišiel nový scope a rozbil aktuálny návrh aplikácie.

##Čo sa stalo

Druhá fáza pridala modul flotíl: portál, kde si firemný zákazník sám spravuje svoje autá, termíny a servisnú históriu. Vozidlo, kľúčová entita celého systému, zrazu potrebovalo patriť dvom svetom naraz, interným procesom aj flotile, a dátový model prvej fázy s tým nepočítal. Niektoré väzby bolo treba prekopať. A s novým modulom prišiel do adminu nový svet funkcionalít, takže doterajšie delenie obrazoviek prestalo dávať zmysel. Presne ten stav, ktorý poznáš z bežných produktov: pridá sa nová funkcionalita bez refaktoru existujúcej a rozhranie začne pôsobiť chaoticky.

##Oprava na úrovni architekta, nie kódu

V klasickom vývoji by táto zmena stála týždeň až dva: niekto musí zmapovať, čoho všetkého sa dotkne, prerobiť dátový model, migrácie, obrazovky a všetko, čo na nich stojí. My sme nič z toho nerobili v kóde. Celá oprava sa odohrala v harnesse, na najvyššej úrovni, kde rozhoduje architekt:

• Impact assessment. Agent prešiel roadmapu, všetky špecifikácie a dátový model a zmapoval, čo nový modul rozbije a ktorých špecifikácií sa dotkne.
• Návrh zmeny. Spolu sme navrhli nové jadro modelu: vozidlo ako spoločnú entitu a nad ňou dva moduly, interné procesy a flotily, ktoré sa navzájom nepoznajú. Agent zmenu premietol do celej roadmapy a všetkých dotknutých špecifikácií naraz, aby nič z toho, čo sme už dôsledne definovali, neostalo nekonzistentné.
• Upratanie UI. Admin navigácia sa pregrupovala do nových celkov tak, aby nový modul zapadol, nie aby sa nalepil.

Všetko za jeden deň. Na druhý deň sme starú appku zahodili a nový build už mal v sebe portál pre flotily.

Toto nie je príbeh o chybe v návrhu a jej oprave. Je to feature systému. Zmenu scopu, ktorá inde znamená týždne bolesti, si tu môžeme dovoliť, lebo appku nedržíme v kóde, ale v definícii. Sme architekti: zmenu robíme na najvyššej úrovni a kód sa z nej prekompiluje. Pomohlo aj to, že sa to dialo vo frontend fáze, backend sa v mojom procese píše vždy až na konci. Nemali sme kód, na ktorom by sme si zakladali. Mali sme definíciu, ktorú sme opravili, a appku, ktorú sme zahodili a nechali postaviť znova.

#Pridajme backend a spustime produkčný run

##Prepnutie harnessu na backend

Keď je celý návrh aplikácie hotový, so všetkými funkcionalitami, klient je spokojný a nič nechýba, je čas prepnúť coding harness z režimu „len frontend" na plnohodnotnú aplikáciu s backendom a produkčným nasadením. Toto je zásadný checkpoint. Musí byť dobre definovaný, aby jeden autonómny run zvládol celú aplikáciu: frontend, backend, aj testovanie aplikácie. Pre klienta sa navonok nič nemení, appka vyzerá rovnako ako tá, ktorú si preklikával. Len hladina klesla a pod ňou sa stavia všetko ostatné.

Znamená to prejsť náš coding harness v priečinku docs/ a predefinovať súbory, kde je popísaná architektúra, hranice a ostatné pravidlá, z lokálnej aplikácie na aplikáciu s backendom. Backendy píšem v Laraveli.

Je to backendový framework s najucelenejším ekosystémom, aký poznám: jeden tím vyvíja jadro aj oficiálne balíky na všetko, čo produkčná appka potrebuje. Autentifikáciu a účty (Fortify), fronty a plánované úlohy (Horizon), e-maily a notifikácie, súbory, monitoring (Pulse, Nightwatch), testovanie (Pest), prepojenie s Reactom bez API vrstvy (Inertia) a hosting, kde sa to celé nasadí jedným pushom (Laravel Cloud). Pre agenta je to ideálne: každý problém má jedno kanonické, dobre zdokumentované riešenie, takže nemá kde improvizovať. Mne ostáva definovať pravidlá: ako servírovať frontend, ako riešiť autentifikáciu a zabezpečenie, ako aplikáciu testovať.

##Čo prežilo z lokálnej appky

Nič, nič sa nemigrovalo. Frontend sa napísal nanovo spolu s backendom, v jednom rune, z tých istých špecifikácií. Z lokálnej verzie prežil len design system, komponenty sa preniesli do nového projektu ako hotová stavebnica. Schéma z IndexedDB sa stala migráciami v Postgrese, hooky sa stali controllermi, ktoré posielajú stránkam dáta cez Inertia props. Každý build, lokálny aj produkčný, žil na vlastnej git branchi a starý sa nikdy neupravoval, len sa vytvoril nový. Úlohou dizajn fázy nebolo vyprodukovať kód, ktorý si necháme. Jej úlohou bolo overiť návrh aplikácie a dátový model s klientom skôr, než sa dotkneme backendu a finálneho odovzdania projektu. Kód bol vedľajší produkt a bol na zahodenie.

##Dva nové dokumenty

Oproti frontendovej fáze pribudli do harnessu dva nové dokumenty:

• SERVICES.md – Záväzná mapa „problém → balík": každá potreba aplikácie (autentifikácia, fronty, e-maily, PDF, vyhľadávanie, súbory) má priradený jeden oficiálny Laravel balík alebo samotný framework. Je to pravidlo o first-party balíkoch zo sekcie o stacku, zapísané tak, aby si ho agent nemusel vykladať sám.
• USER_JOURNEYS.md – Katalóg všetkých ciest používateľa naprieč rolami a portálmi, každá s krokmi a očakávaným výsledkom. Je to checklist, podľa ktorého sa dá celá aplikácia preklikať v prehliadači, rola po role. Ako sa použil, ukážem na konci kapitoly.

##Testovacia stratégia a verifikačná brána

Testovacia stratégia si pokojne zaslúži vlastný dokument v harnesse. Ja som ju dal ako všeobecné pravidlo rovno do CLAUDE.md, ako jedinú výnimku z pravidla, že CLAUDE.md je len index: je príliš dôležitá na to, aby si ju agent musel ísť hľadať. Pravidlo je krátke: každá funkcionalita sa odovzdáva aj s testami v Peste, minimálne happy path a autorizácia pre každú rolu. Kto čo smie vidieť a robiť je v aplikácii so štyrmi rolami najčastejší zdroj chýb, preto je to povinné.

K tomu patrí verifikačná brána, šesť príkazov, ktoré musia prejsť, kým sa čokoľvek vyhlási za hotové:

• testy na SQLite, pre rýchlosť,
• tie isté testy ešte raz na Postgrese, pre zhodu s produkciou,
• formát backend kódu,
• typová kontrola TypeScriptu,
• lint,
• produkčný build.

A jedna veta, ktorá sa ukázala ako najdôležitejšia: orchestrátor bránu spúšťa sám a nikdy neverí subagentovi, že „testy prešli". Kto je orchestrátor, vysvetlím hneď.

##Orchestrátor a dva audity

Produkčný run spúšťa ten istý prompt ako každý predchádzajúci: „Naprogramuj celú aplikáciu podľa roadmapy". Rozdiel je v tom, koľko toho agent musí udržať naraz: pravidlá pre frontend, backend, UI, UX, testy a nasadenie, desať hodín v kuse. Pri takýchto veľkých runoch sa mi osvedčilo nespúšťať jedného agenta, ale orchestrátora, ktorý dozerá na celý proces implementácie. Na každý epic z roadmapy spustí implementačných agentov, čaká na ich reporty, skontroluje ich prácu, spustí testovacích a audit agentov, a až keď je epic zelený a commitnutý, ide na ďalší. Sám nič neprogramuje, koordinuje a validuje.

Audity sú dva, lebo vieme, že agenti pravidlá nedodržia vždy na sto percent. Design audit už poznáš z kapitoly o design systéme: kontroluje, či obrazovky držia dizajn kontrakt, či má každý nový komponent ukážku v Showcase a záznam v katalógu. Coding audit je nový a robí to isté pre kód: prejde frontend aj backend epicu a porovná ho s pravidlami v našom coding harnesse. Oba bežia ako subagenti po dokončení každého epicu, nálezy sa opravia a commitnú, a až potom ide run ďalej. Takto pokryješ väčšinu problémov s nedodržiavaním pravidiel. Ako si taký audit skill vytvoriť? Buď ho napíšeš ručne, alebo necháš agenta zanalyzovať tvoj coding harness a skill ti napíše sám. To isté platí pre testovaciu stratégiu.

##Desať hodín bez jedinej otázky

Produkčný run trval desať hodín. Bola to jedna session, ktorá bežala autonómne na mojom počítači, bez prerušenia a bez jedinej otázky od orchestrátora: všetko, čo potreboval vedieť, mal v harnesse. Výsledok: 30 migrácií, 19 modelov, 33 controllerov, 64 stránok, 947 testov so 7 468 asserciami, štyri používateľské role a rozhrania. Úctyhodný rozsah aplikácie.

Nešiel som do toho naslepo. Za sebou sme mali šesť frontend runov, takže sme vedeli, že harness drží. Pred ostrým produkčným runom pribudli ešte dva testovacie runy backendu a jeden produkčný run v plnom rozsahu, len aby sme videli, kde sú hranice agentov v takomto meradle a či takto dlhý autonómny task zvládnu. Nebol to experiment, ale kalkulovaná voľba: z predchádzajúcich projektov som mal dosť skúseností s tým, čo agenti utiahnu. Dokopy tak aplikácia vznikla desaťkrát a ani raz nič nepadlo ani sa nereštartovalo. Žiadne extra náklady na agentov: celý run bežal na mojom bežnom predplatnom Anthropicu za 200 eur mesačne.

##Audity v akcii

Audity si svoju úlohu odpracovali. Coding audit zachytil napríklad porušenú konvenciu písania backendových controllerov. Design audit našiel stránku, kde si agent vymyslel vlastnú hlavičku namiesto existujúceho komponentu PageHeader, a nové komponenty bez záznamu v katalógu. Nálezy sa opravili, commitli a run išiel ďalej.

##Testy a päťdesiat vyklikaných journeys

Testy písal agent spolu s každou funkcionalitou, tak ako to káže pravidlo v CLAUDE.md. Počet testov sám o sebe hovorí málo, počet assercií hovorí, koľko vecí každý test reálne overuje, a necelých osem na test znamená, že testy nie sú len kontrola, či stránka nespadla.

Lenže testy sa dajú napísať aj zle a agent, ktorý testuje vlastný kód, má sklon testovať to, čo napísal, nie to, čo mal napísať. Preto sme po dokončení produkčného runu spustili ešte jeden samostatný run: agent dostal USER_JOURNEYS.md, otvoril prehliadač a appku reálne vyklikával rolu po role. Ten dokument nevznikol po rune, ale pred ním: agent ho vygeneroval z roadmapy a špecifikácií, ja som ho skontroloval a od tej chvíle zrkadlí všetko, čo sa v appke dá robiť, rola po role. Agent mal navyše inštrukciu správať sa ako neposlušný používateľ: skúšať appku rozbiť, zadávať nezmysly, klikať tam, kam nemá. Tá istá technika sa neskôr hodí pri security review.

Prihlásil sa, prešiel každý flow, otvoril stiahnuté prílohy, skontroloval odoslané e-maily. Nič neopravoval, len zapisoval každú nezrovnalosť. Výsledok po päťdesiatich journeys: žiadny blocker, žiadna funkčná chyba v logike aplikácie. Našiel dve drobné chyby, dve nekonzistencie v demo dátach a jednu odchýlku dokumentácie od kódu. Všetko sme potom opravili dodatočne.

#Bola appka hotová po produkčnom rune?

Funkčne áno, každý flow prešiel, každá rola sa dostala tam, kam mala. Odovzdateľne ešte nie: zostali drobnosti, ktoré si všimne moje odborné oko, nie test.

##Chyby, ktoré si rebuild nezaslúžia

Produkčný run dopadol lepšie, než som po revízii kódu a testovaní aplikácie čakal. Samozrejme, pár drobných chýb sa našlo. Pri spätnej analýze to boli prevažne chýbajúce usmernenia technickej implementácie, nie logické chyby v kóde. Napríklad ukladanie súborov na lokálny disk namiesto externého úložiska: po ďalšom deploymente by sa všetky súbory zmazali.

Ďalšie chyby boli z rovnakej kategórie, vyberám ich priamo z commit správ v gite:

• Tlačidlo „späť" vo formulári, ktoré formulár omylom odosielalo, lebo nemalo nastavený typ.
• Jedna prihlasovacia karta bez vnútorného odsadenia, kým všetky ostatné ho mali.
• Modal, ktorý sa na nízkych obrazovkách nedal odscrollovať.
• Pole na percento provízie, ktoré neprijalo desatinnú čiarku, len bodku.
• Šablóna textu, ktorá pridala bodku za hodnotu, ktorá už bodkou končila.
• Nejednoznačné pomenovanie súborov.

Kozmetika, setup, drobné konvencie. Ani jedna z nich nebola architektonická a to je dôležité usmernenie pre celý tento prístup. Rebuild s upravenými pravidlami si zaslúži chyba, ktorá nesie zásadný problém v architektúre a bez pravidla sa zopakuje v každej ďalšej obrazovke.

Príklad z nášho kontextu: keby agent riešil oprávnenia na frontende, skrytím tlačidiel a položiek menu podľa role, namiesto na serveri cez policies. Každá obrazovka by to zdedila, každá by sa dala obísť priamou URL a oprava v kóde by znamenala prejsť všetkých 64 stránok. To je chyba do pravidla a do rebuildu. Chyba, ktorá je jedinečná a lokálna, si rebuild nezaslúži, bola by to drahá odpoveď na lacný problém.

##Ukazuješ na chybu, nie na riešenie

Takže ako sa opravovali? Nie vibe-codingom, kde agentovi diktuješ, čo má kde prepísať. Agent dostal zoznam nálezov, tak ako ich zapísal browser run a moja vlastná revízia, a spracoval ich autonómne: pri každom sám navrhol riešenie, implementoval ho podľa pravidiel harnessu a pustil verifikačnú bránu. Ja som každú opravu overil a uložili sme to. Ukazuješ na chybu, nie na riešenie.

Osobne si myslím, že dnes je kód napísaný lepšie než na vrchole mojej aktívnej engineering kariéry, keď som denne vyvíjal aplikácie.

##Posledný ľudský dotyk

Agenti sa držali dizajn kontraktu z pravidiel v repozitári a UI mi prišlo solídne. Ako vyslúžilý UI/UX dizajnér a perfekcionista som však strávil ešte zhruba dva dni dolaďovaním UI a flowu, aby aj najmenší detail a najmenšia operácia v aplikácii pôsobili príjemne a prirodzene. Na toto už žiadny premyslený proces nemám, len starý dobrý vibe-coding: Claude, toto urob takto, tamto urob hentak. Je to dolaďovanie drobných detailov, nie vibe-codovanie nových funkcionalít. Trocha ľudského dotyku, ktorý produkčná verzia potrebovala. Bol to posledný ľudský dotyk pred odovzdaním projektu: naleštenie, nie prestavba.

Z jedného autonómneho runu dostaneš aplikáciu, ktorá funguje, drží dizajn a dá sa odovzdať po dvoch dňoch dolaďovania. Tá kvalita nevzniká v rune, ale pred ním: v harnesse s jasnými pravidlami, ako má aplikácia vyzerať, aký má interakčný pattern a ako sa má stavať. Posledné percentá sú už len otázka tvojho zmyslu pre detail. A tie sa doladia v kóde, nie v ďalšom rune.

#Čo ostalo po produkčnom rune

Kód. Zatiaľ. V mojom procese existuje bod, v ktorom sa prepnem: aplikácia sa stane jediným zdrojom pravdy a od tej chvíle iterujeme na nej, svojpomocne, ak je vývoj kontinuálny a klient prináša ďalšie biznis požiadavky. Špecifikácie a harness ostávajú ako dokumentácia toho, prečo appka vyzerá tak, ako vyzerá, ale už sa z nich nekompiluje.

##Mesiac namiesto troch

Celá exekučná časť projektu trvala mesiac. Pred érou coding agentov trval rovnaký rozsah podľa mojich skúseností dva až tri mesiace a potreboval produktového manažéra, dizajnéra a dvoch až troch inžinierov. Dnes to vie zorchestrovať jeden človek, ktorý má ako taký presah do produktu, dizajnu a engineeringu. A k tomu získaš niečo, čo sme pred AI nemali: klient má appku v rukách v ranej fáze návrhu riešenia, feedback sa vracia v hodinách a každý build je celý produkt - nie prototyp z Figmy, nie časť aplikácie, nie okresané MVP. Kód už nestaviaš. Tvoje úlohy sú len dve: naarchitektovať správne riešenie a zorchestrovať agentov, aby ho postavili.

#Čo bolo ťažké

##Manažovanie špecifikácií

Najnáročnejšie na celom procese je manažovať špecifikácie všetkých features v roadmape. Keď ich máš napríklad sto a pracuješ s nimi celý deň, je to naozaj vyčerpávajúce a musíš si sám určiť, či ti ten trade-off stojí za to. Tu treba využiť plnú silu agentov, nech ti ich pomôžu spravovať. A drž ich lean a jednoduché aby ťa to neskôr nezomlelo: dnešní agenti hlúpi nie sú a aj z minima informácií pochopia, čo potrebuješ. Hlavné informácie drž vždy na úrovni harnessu, aby si do špecifikácií zaniesol čo najmenej duplicitných inštrukcií.

##Komplexný UX flow ako prototyp

Druhá náročná vec je opísať v špecifikácii komplexnejší UX flow, povedzme desaťkrokový proces, ktorým musí používateľ prejsť. Popísať ho tak dobre, aby ho agent zreplikoval podľa tvojich predstáv, je ťažké. Hlavne keď aplikáciu v iteratívnej fáze rekompiluješ znova a znova. Mne sa osvedčilo vziať design systém a vyiterovať (áno, vibe-codingom) samostatný prototyp s UI, ktoré presne robí ten náročný flow. Uložil som ho do harnessu do docs/prototypes a špecifikácia danej funkcionality obsahuje len referenciu: agent sa naň pozrie a implementuje ho do produkčného kódu čisto a podľa produkčných pravidiel. Tak máš to najlepšie z oboch svetov, vibe-codingu aj spec as code.

#O level vyššie

##Slučka prompt, čakanie, kontrola

Všímam si, že veľa engineerov kvôli AI agentom prichádza o svoju doterajšiu radosť z práce. Programovanie bolo ich každodenná práca a AI im z nej berie radosť. Typický deň inžiniera vyzeral tak, že ráno vstaneš, uvaríš si kávu, zapneš IDE a na osem hodín sa ponoríš do problému: rozbiješ ho na časti, postavíš riešenie a večer to funguje. Niečo si vytvoril, niečo vyriešil, a to bola tvoja odmena. Dnes ten istý človek sedí celý deň v slučke prompt, čakanie, kontrola, prompt. Robí jedno drobné rozhodnutie za druhým, prácu medzi nimi urobí agent, a večer je vyčerpaný z rozhodovania bez pocitu, že niečo postavil.

##Podstata práce sa zmenila, aj odmena je inde

Ja to vnímam inak: treba ísť o level vyššie. Aplikáciu už nestaviame na úrovni kódu. Staviame harness: znalosti, ktoré agenta nasmerujú, design systém, testy a audit, aby agent postavil appku od nuly v jednom autonómnom rune. Je to iná práca a úsudok sa presúva vyššie: akými technológiami stavať, ako má vyzerať UX a UI, ako sa má systém zachovať, keď mu niečo chýba. A dá sa s tým hrať a iterovať rovnako ako s kódom. Odmena je len inde. Nie funkcia, ktorá funguje, ale systém, ktorý funguje. A to, čo z neho vyjde, je trikrát väčšie, než čo sme doteraz stavali.

Otázka už nie je, ako dobre postaviť kus kódu. Otázka je, o koľko zdvihnúť ambície. Aby tá odmena nezmizla, musí rásť scope toho, čo dokážeme. Kedysi sme ulovili zver, potom zasiali pole, potom napísali kód, ktorý automatizoval jednu vec. Dnes vieme navrhnúť celý systém, ktorý rastie a mení sa s tým, čo od neho svet okolo chce. To je teraz v našich rukách: navrhnúť ho a zorchestrovať.

#Kam to smeruje

##Harness je tiež na zahodenie

Tento článok je viac o mentálnom modeli než o presnom postupe. Ukazuje, že sa to dá aj takto, nie že sa to má robiť presne takto. Nekopíruj moje harness dokumenty. Inšpiruj sa a skúšaj, čo sedí tebe: každý človek aj každý projekt má vlastné postupy a vlastnú fázu. A harness, ktorý postavíš dnes, nebude o pol roka relevantný. Je nezmysel veriť, že bude.

Pre harness platí to isté, čo pre appku: je na zahodenie. Ostať musí jediné: ochota zahodiť starý mentálny model, keď sa svet zmení, a postaviť si nový. Harness ti dnes postaví samotná AI. Čo ti nepostaví, je pružné uvažovanie a odvaha experimentovať.

##Product builder v teréne

Ten môj smeruje k tomuto. Rýchle stavanie greenfield projektov, kde chyba v návrhu nie je katastrofa, ale lacná oprava. Kde nová funkcia pridaná za behu nie je prekliatie, ale feature. Kde som ako product builder viac v teréne a bavím sa so zákazníkom a používateľmi, než sedím pri rysovacom plátne a coding obrazovkách. A kde sa vízia riešenia dá naplniť o dosť skôr a lacnejšie, než to bolo doteraz možné. Nie okresané MVP, ale hotový produkt.

##Ďalší experiment: fixné dáta, nahraditeľná appka

A jedna vec, ktorú chcem skúsiť nabudúce. Je finálny produkčný kód naozaj zdroj pravdy, alebo ním ostáva špecifikácia produktu? Pohrávam sa s myšlienkou oddeliť produkčnú databázu ako statický prvok a aplikáciu nechať ako prvok dynamický, ktorý sa aj pri ďalších veľkých iteráciách môže znova a znova rekompilovať. Pridáš funkcionalitu alebo ju odstrániš, aplikáciu vždy prekompiluješ. Nabral si obrovské množstvo používateľov a aplikácia to nestíha? Prekompiluješ backend s inou architektúrou, prípadne v inom jazyku alebo prostredí. Produkčné dáta, ktoré vygenerovali tvoji zákazníci a tvoja firma, sú fixné, všetko nad nimi je nahraditeľné. To si nechám na budúce experimenty, možno na budúci článok.

A to je len jeden nápad. Keď o tom píšem, napadá mi obrovské množstvo problémov a príležitostí, ktoré sa dajú takto reinventnúť. Tebe pri čítaní určite napadlo aspoň desať vecí na ďalších desať článkov. Nebojím sa, že kvôli AI nebudeme mať čo robiť. Naopak, práce bude o dosť viac. Len bude iná.

Ak staviaš niečo podobné, vlastný harness, spec ako zdroj pravdy, appku na zahodenie, ozvi sa. Rád porovnám postrehy.