Pohled frontendového inženýra na nový produktově-inženýrský workflow v éře AI
Číslo, které nedává smysl
12 dní. Dva lidé: produktový designér a frontendový inženýr. Kompletní přestavba platformy.
Ne prototyp. Ne MVP. Plná náhrada produkční aplikace, zakončená jediným PR, které smazalo 26,000 řádků starého kódu. Každá stránka, každá trasa, každá interakce, znovu postavená od nuly a nasazená skutečným uživatelům.
V jakémkoli tradičním workflow vývoje produktu je tento časový rámec absurdní. Projekt tohoto rozsahu by běžně trval měsíce: týdny designování ve Figmě, kola schvalování, předávací ceremonie, plánování sprintů a pak pomalé dolaďování pixelů. To, co se stalo zde, bylo zásadně jiné. Ne proto, že jsme pracovali tvrději, ale protože se změnil způsob naší spolupráce.
Toto je příběh o tom, jak jsme spustili platformu Zero ve VM0 a co mě to naučilo o budoucnosti spolupráce mezi designem a inženýry.
Staré úzké hrdlo
Každý frontendový inženýr zná tradiční postup:
- Designér vytvoří návrhy ve Figmě
- Revize designu, iterace, schválení
- Okótované specifikace s rozestupy, barvami, breakpointy
- Inženýr převádí vizuální specifikace do kódu
- Neustálé vracení: „Můžeš to posunout o 4px doleva?“
- Nakonec napojení na API vrstvu
- Integrační testování, další kolečko připomínek
Úzké hrdlo nebylo nikdy v jednom konkrétním kroku. Bylo v mezerách mezi kroky: čekání, ztráta při převodu, přepínání kontextu. Mentální model designéra, jak má interakce vypadat, se po zploštění do statického rámce ve Figmě a okótování dostává k inženýrovi už degradovaný. Inženýr pak staví verzi toho, co si designér představoval, ale je to nevyhnutelně ztrátová kopie.
Na tuto třecí plochu jsme si tak zvykli, že jsme ji přestali vnímat. Bylo to prostě „jak to chodí“.
Experiment: Co kdyby designér nasazoval kód?
5. března 2026 otevřela Ming, naše produktová designérka, PR #3685: feat(platform): add zero app with shell, pages and polish. Přidala 4,146 řádků funkčního React kódu.
Ne soubor z Figmy. Ne export design tokenů. Běžící aplikaci.
PR obsahoval kompletní kostru aplikace: postranní navigaci, strukturu routování, šablony stránek pro chat, plánování, aktivitu, správu týmu a nastavení, vše stylované naším design systémem a vykreslované v prohlížeči. Data byla mockovaná, ale UI bylo reálné. Mohli jste npm run dev a proklikat každou stránku.
Ming tento kód nepsala od nuly v tradičním smyslu. Použila AI nástroje pro kódování (nejprve Cursor, později Claude Code), aby převedla svou designovou vizi přímo do React komponent. AI se postarala o mechanický překlad (struktura JSX, CSS vlastnosti, skládání komponent), zatímco Ming řídila vizuální a interakční rozhodnutí, která žádná AI neumí: rytmus rozložení, hierarchii informací, pocit z přechodů.
Během následujících čtyř dnů přibyly tři další PR:
| Datum | PR | Co Ming nasadila |
|---|---|---|
| 5. března | #3685 | Kostra aplikace, postranní panel, všechny šablony stránek (+4,146 řádků) |
| 6. března | #3825 | Stránky plánování, UI vylepšení (+2,650 řádků) |
| 9. března | #3993 | Onboarding, dialog pro Slack konfiguraci (+1,146 řádků) |
| 9. března | #4050 | O stránka, plovoucí navigační karta |
K 9. březnu už celý frontend nové platformy existoval jako běžící kód. Každá stránka, kterou jste později viděli v produkci, už byla prokliknutelná v dev prostředí. Jen zatím nedělala nic skutečného.
A tam jsem přišel na řadu já.
Moje nová práce: Vdechnout duši
Když jsem otevřel kód 9. března, nečekal mě obvyklý úkol převádět plochý design do kódu. Kód už tam byl. Mojí prací bylo nahradit každý mock realitou, propojit každý krásně navržený povrch se skutečným backendem pod ním.
To zásadně změnilo moji práci. Místo přemýšlení o pixelech jsem přemýšlel o tocích dat. Místo otázky „odpovídá to návrhu?“ jsem řešil „jaké API volání tato stránka potřebuje a co když selže?“
Takto vypadaly mé první dny:
Den 1 (9. března): Autentizace a přepínání organizací. Napojil jsem shell od Ming na Clerk autentizaci, přidal přesměrování mezi doménami a zařídil, že přepínač organizací opravdu přepíná. Dva PR, oba sloučeny tentýž den.
Den 2 (10. března): Konektory a plánování. Nahradil jsem mock grid konektorů reálnými API daty, napojil záložku plánování na skutečné cron úlohy a editor instrukcí na backend. Čtyři PR.
Den 3 (11. března): Velký den zapojování. Stránka týmu dostala reálná data o subagentech (+3,271 řádků). Stránka aktivity dostala reálné logy. A hlavní klenot: chat stránka byla napojena na skutečný pipeline běhu agenta, čímž nahradila ~1,200 řádků demo kódu funkčním AI rozhraním pro konverzaci. Tentýž den jsem zavedl FeatureSwitchKey.Zero, feature flag, který nám umožnil provozovat starou i novou platformu paralelně.
Dny 4-5 (12-13. března): Přílohy souborů, správa relací, multi-agentní chat, trvalost nastavení. Každá stránka, kterou Ming postavila, teď dělala skutečnou práci.
Práce měla téměř hudební rytmus. Každé ráno jsem si vybral stránku z Mingina scaffoldu, prostudoval její komponenty, zjistil, jaká data očekává, postavil API integraci, ošetřil chybové stavy a pushnul. Odpoledne byla další stránka živá.
Feature switch: Paralelní světy
Feature flag FeatureSwitchKey.Zero si zaslouží zvláštní zmínku, protože právě on udělal tuto migraci bezpečnou, ne riskantní.
Od 11. března běžely v produkci dvě kompletní UI paralelně. Uživatelé na starém systému viděli staré trasy. Interní testeři na novém systému viděli Zero. Každou stránku, kterou jsem napojil, bylo možné testovat v produkčním kontextu bez rizika pro workflow uživatelů.
To není revoluční. Feature flagy jsou běžná praxe. Ale kombinace feature flagů s design-as-code workflow vytvořila něco speciálního: mohli jsme ověřit celé UX nové platformy (protože Ming postavila kompletní, proklikatelné UI), zatímco jsem postupně každou stránku napojoval (protože jsem je zapojoval jednu po druhé). Kdykoli, pokud by se něco pokazilo, mohli jsme přepnout zpět.
Nic se nepokazilo.
Den 12: Velký přepínač
17. března jsem otevřel PR #5095: refactor: remove all non-zero platform pages and feature flag.
Rozdíl: +456 řádků, -26,041 řádků.
Předtím: stará VM0 Platforma. Tabulky, ID běhů a surová data relací.
Poté: nová Zero. Konverzační AI pracovní prostor s připnutými agenty a kartami use-case.
Jedním sloučením byly smazány všechny staré trasy. Feature flag byl odstraněn. Zero už nebyla možnost; byla jediným režimem. Následný PR (#5155) odstranil předponu /zero v URL: co bylo /zero/chat, se stalo jednoduše /chat.
Proč jsem měl jistotu tento řez udělat? Protože:
- Každá stránka běžela pod feature flagem minimálně 5 dní
- Každá API integrace byla testována na produkčních datech
- Starý i nový systém sdílely stejný backend. Šlo jen o frontendovou výměnu, ne migraci dat
- Na novém systému byli skuteční uživatelé, kteří průběžně dávali zpětnou vazbu
Těch 26,000 řádků nebylo smazáno s úzkostí. Byly smazány s úlevou.
Vzorec se opakuje
Nejvíc mě nepřekvapila samotná migrace. Překvapilo mě, že workflow, které jsme objevili, se stalo naším výchozím způsobem práce pro každou další funkci. Ming postaví UI shell s pomocí AI, já napojím logiku a rozšířím architekturu. Stejný design-as-code vzorec, v měřítku funkcí:
Systém oprávnění (březen 19 → duben 7)
Ming nasadila PR #5467, UI zásuvku pro oprávnění s komponentami Sheet a přepínači. Tři commity, čisté UI.
Já přidal 13 commitů do stejného PR: migrace databáze pro firewall_access_requests, API endpointy, integrační testy, opravy lintů. Během dalších dvou týdnů pak 10+ navazujících PR vybudovalo celou vrstvu oprávnění: redesign schvalovacích karet, Slack notifikace pro žádosti o přístup, CLI doctor příkazy pro diagnostiku problémů s oprávněními a nakonec přejmenování celého konceptu z „firewall“ na „permission“ v kódu.
Mingin zásuvka byla semínko. Systém oprávnění byl strom.
Systém plánování (březen 23 → duben 13)
Ming navrhla detailní trasu plánování a UX kalendáře (#6155). Tři commity čisté UI práce.
Já přidal 14 commitů: editace popisu s autogenerováním, výběr Slack kanálu pro notifikace, potvrzovací dialogy při neuložených změnách, sjednocení kalendářního a seznamového pohledu a komplexní testy. Pak 15+ navazujících PR rozšířilo systém na plnohodnotné opakované úlohy s historií běhů, podporou časových pásem a cron výrazů.
Integrace Telegramu (duben 27 → duben 28)
V tuto chvíli byl vzorec tak zažitý, že jsme celou platformní integraci nasadili za 48 hodin. Ming postavila UI pro Nastavení (#11196) a onboarding (#11399). Já postavil multi-bot API, odesílání/příjem zpráv, upload/download souborů, kontext bohatých zpráv, Ably real-time aktualizace a E2E testy. Druhý den byla funkce zpřístupněna všem uživatelům.
Kde má AI své místo
Chci být přesný ohledně role AI, protože je snadné ji buď přeceňovat, nebo podceňovat.
AI umožnila designérovi kódovat. Ming je produktová designérka, ne softwarová inženýrka. Přemýšlí v rozvržení, hierarchiích a interakcích, ne v React hooks a TypeScript generikách. AI nástroje (Cursor, pak Claude Code) překlenuly tuto mezeru tím, že zvládly mechanický překlad z designového záměru do funkčního kódu. Ming řídila, AI psala. Výsledkem byl kód, který vytvořil designér, ale na kterém mohl inženýr stavět.
AI urychlila revizní smyčku. U společných PR můj AI agent revidoval Mingin kód, klasifikoval problémy podle priority (P0/P1/P2) a přímo pushoval opravné commity. PR #5060 prošel pěti koly revize za 38 minut. PR #5467 zvládl tři kola za 20 minut. Nejde o „AI nahrazuje code review“. Každou změnu stále čtu. Ale mechanickou práci s hledáním lint chyb, chybějících typů a testovacích mezer automatizovala AI.
AI nedělala designová rozhodnutí. Informační architektura každé stránky, vzory interakcí, vizuální hierarchie: to vše vycházelo z Mingina produktového citu, podloženého uživatelským výzkumem a znalostí domény. AI umí vygenerovat stránku nastavení, ale nerozhodne, co má být přepínač a co rozbalovací nabídka, nebo kdy je vhodný potvrzovací dialog a kdy je to zbytečné tření.
AI nedělala architektonická rozhodnutí. Volba použít feature flag pro paralelní nasazení, strategie oddělení API vrstvy, rozhodnutí napojovat stránky postupně místo najednou: to byly inženýrské úsudky. AI mi pomohla psát kód rychleji, ale pořadí a řízení rizik bylo lidské.
Upřímné shrnutí: AI odstranila překladovou vrstvu mezi designem a inženýry. Nenahradila ani jednu disciplínu; odstranila mezeru mezi nimi.
Co se změnilo v mé roli
Po třech měsících v tomto workflow vnímám svou roli frontendového inženýra jinak.
Už nejsem vizuální překladatel. Dny, kdy jsem dostal soubor z Figmy a hodiny ladil rozestupy, jsou pryč. Ne proto, že bych to dělal rychleji, ale protože už to není moje práce. Záměr designéra přichází jako kód, ne jako obrázek kódu.
Jsem rozšiřovatel architektury. Moje hlavní hodnota je vzít funkční UI povrch a postavit pod ním neviditelnou infrastrukturu: API integrace, validace dat, ošetření chyb, kontroly oprávnění, real-time aktualizace, testy. Poměr commitů u většiny společných PR to ukazuje. Ming přispívá 3 commity UI, já přispívám 13 commity vším ostatním.
Jsem strážce kvality. Díky AI asistovaným revizím mohu udržet kvalitu kódu na mnohem větší ploše než dřív. Automatizovaná revize zachytí mechanické chyby; já se soustředím na architekturu, okrajové případy a ověření, že funkce skutečně funguje end-to-end.
Jsem stratég doručení. Feature flagy, postupné napojování, paralelní nasazení: pořadí, jak se funkce dostane z kódu do produkce, je teď klíčovou součástí mé práce, ne dodatečnou myšlenkou.
Čísla
Tři měsíce. Dva lidé. Po celou dobu s podporou AI.
- 914 sloučených PR (679 mých, 235 Minginých)
- 12 dní od prvního scaffoldu po kompletní náhradu platformy
- 48 hodin na kompletní integraci Telegramu (naše nejrychlejší funkce)
- 26,000 řádků smazáno v jediném sebevědomém sloučení
- 88% mých PR a 66% Minginých má AI spoluautorství
Nejsou to metriky výkonu. Nikdo z nás nepracoval o víkendech ani netahal noční směny. Rychlost plyne z odstranění mrtvého času: předávacích schůzek, nedorozumění ve specifikacích, neustálého „můžeš to posunout o 4px“. Když designový záměr proudí přímo do kódu a inženýr jej rozšiřuje na místě, je prostě méně plýtvání.
Co to znamená pro týmy
Netvrdím, že každý tým by měl pracovat tímto způsobem. Tento workflow vznikl z naší konkrétní situace: malý tým, příležitost na zelené louce a brzký přístup k schopným AI nástrojům pro kódování. Vaše zkušenost se může lišit.
Ale věřím, že základní posun je univerzální: hranice mezi designem a inženýry se rozpouští a AI je tím rozpouštědlem. Jak se AI nástroje zlepšují v převodu záměru do kódu, více designérů bude nasazovat kód přímo. Jakmile k tomu dojde, inženýři budou trávit méně času překladem a více architekturou, kvalitou a doručením.
Práce frontendového inženýra nezmizí. Mění tvar. A upřímně? Nový tvar je zajímavější.
Yuma je frontendový inženýr ve VM0, kde staví platformu pohánějící Zero, operační systém pro AI agenty. Smazal už více starého kódu, než by rád přiznal.
