Perspektywa frontend developera na nowy workflow produktowo-inżynierski w erze AI
Liczba, która nie powinna mieć sensu
12 dni. Dwie osoby: projektant produktu i frontend developer. Całkowita przebudowa platformy.
Nie prototyp. Nie MVP. Pełna wymiana produkcyjnej aplikacji, zakończona jednym PR, który usunął 26,000 linii starego kodu. Każda strona, każda ścieżka, każda interakcja – zbudowane od nowa i udostępnione prawdziwym użytkownikom.
W tradycyjnym workflow rozwoju produktu taki harmonogram jest absurdalny. Projekt o takim zakresie zwykle trwałby miesiące: tygodnie eksploracji w Figma, rundy przeglądów ze stakeholderami, przekazanie projektu, planowanie sprintu, a potem powolna, perfekcyjna implementacja. To, co się tu wydarzyło, było fundamentalnie inne. Nie dlatego, że pracowaliśmy ciężej, ale dlatego, że sposób naszej współpracy się zmienił.
To historia, jak wdrożyliśmy platformę Zero w VM0 i czego nauczyło mnie to o przyszłości współpracy projektowo-inżynierskiej.
Stary wąskie gardło
Każdy frontend developer zna tradycyjny pipeline:
- Projektant tworzy makiety w Figma
- Przegląd projektu, iteracje, akceptacja
- Opisane specyfikacje: odstępy, kolory, breakpoints
- Developer tłumaczy specyfikacje wizualne na kod
- Wymiana uwag: „Możesz przesunąć to o 4px w lewo?”
- Na końcu podpięcie warstwy API
- Testy integracyjne, kolejne poprawki
Wąskie gardło nigdy nie tkwiło w jednym kroku. Było w lukach między krokami: czekaniu, utracie informacji przy tłumaczeniu, przełączaniu kontekstu. Mentalny model interakcji projektanta, spłaszczony do statycznej ramki Figma i opisany czerwonymi liniami, trafia do developera już zdegradowany. Developer odtwarza wersję tego, co projektant sobie wyobraził, ale to zawsze jest kopia z utratą jakości.
Tak przywykliśmy do tej tarcia, że przestaliśmy je zauważać. To było po prostu „jak to działa”.
Eksperyment: Co jeśli projektant wdraża kod?
5 marca 2026 Ming, nasza projektantka produktu, otworzyła PR #3685: feat(platform): add zero app with shell, pages and polish. Dodał 4,146 linii działającego kodu React.
Nie plik Figma. Nie eksport tokenów designu. Działająca aplikacja.
PR zawierał kompletny szkielet aplikacji: nawigację boczną, strukturę routingu, szkielety stron czatu, harmonogramu, aktywności, zarządzania zespołem i ustawień, wszystko ostylowane naszym systemem designu i renderowane w przeglądarce. Dane były mockowane, ale UI był prawdziwy. Można było npm run dev i przeklikać każdą stronę.
Ming nie pisała tego kodu od zera w tradycyjnym sensie. Używała narzędzi AI do kodowania (najpierw Cursor, potem Claude Code), by przetłumaczyć swoją wizję projektową bezpośrednio na komponenty React. AI zajmowało się mechanicznym tłumaczeniem (struktura JSX, właściwości CSS, kompozycja komponentów), a Ming podejmowała decyzje wizualne i interakcyjne, których AI nie jest w stanie podjąć: rytm układu, hierarchia informacji, odczucie przejść.
| Data | PR | Co wdrożyła Ming |
|---|---|---|
| Mar 5 | #3685 | Szkielet aplikacji, sidebar, wszystkie szkielety stron (+4,146 linii) |
| Mar 6 | #3825 | Strony harmonogramu, dopracowanie UI (+2,650 linii) |
| Mar 9 | #3993 | Onboarding, dialog konfiguracji Slack (+1,146 linii) |
| Mar 9 | #4050 | Strona „O nas”, pływająca karta nawigacji |
Do 9 marca cała powierzchnia frontendowa naszej nowej platformy istniała jako działający kod. Każda strona, którą później zobaczysz w produkcji, była już klikalna w środowisku deweloperskim. Po prostu jeszcze nie robiła nic prawdziwego.
W tym momencie pojawiłem się ja.
Moja nowa rola: Wstrzykiwanie duszy
Gdy otworzyłem repozytorium 9 marca, nie musiałem mierzyć się z typowym wyzwaniem tłumaczenia płaskiego projektu na kod. Kod już tam był. Moim zadaniem było zastąpić każdy mock rzeczywistością, połączyć pięknie zaprojektowane powierzchnie z żywym backendem pod spodem.
To fundamentalnie zmieniło moją pracę. Zamiast myśleć o pikselach, myślałem o przepływach danych. Zamiast pytać „czy to się zgadza z makietą?”, pytałem „jakie wywołanie API jest potrzebne na tej stronie i co jeśli się nie powiedzie?”
Tak wyglądał mój pierwszy tydzień:
Dzień 1 (9 marca): Autoryzacja i przełączanie organizacji. Podpiąłem shell Ming do uwierzytelniania Clerk, dodałem przekierowania między domenami i sprawiłem, że przełącznik organizacji faktycznie zmieniał organizację. Dwa PR, oba zmergowane tego samego dnia.
Dzień 2 (10 marca): Connectory i harmonogram. Zastąpiłem mockowaną siatkę connectorów prawdziwymi danymi z API, podpiąłem zakładkę harmonogramu do rzeczywistych zadań cron i połączyłem edytor instrukcji z backendem. Cztery PR.
Dzień 3 (11 marca): Wielki dzień podpinania. Strona zespołu dostała prawdziwe dane subagentów (+3,271 linii). Strona aktywności dostała prawdziwe logi. I najważniejsze: strona czatu została połączona z rzeczywistym pipeline uruchamiania agenta, zastępując ~1,200 linii kodu demo działającym interfejsem konwersacji AI. Tego samego dnia wprowadziłem FeatureSwitchKey.Zero, flagę funkcji pozwalającą uruchamiać starą i nową platformę równolegle.
Dni 4-5 (12-13 marca): Załączniki plików, zarządzanie sesją, czat wieloagentowy, trwałość ustawień. Każda strona zbudowana przez Ming zaczęła wykonywać prawdziwą pracę.
Rytm był niemal muzyczny. Każdego ranka wybierałem stronę ze scaffoldu Ming, analizowałem jej strukturę komponentów, sprawdzałem, jakich danych oczekuje, budowałem integrację z API, obsługiwałem stany błędów i pushowałem. Po południu kolejna strona ożywała.
Przełącznik funkcji: Równoległe światy
Flaga funkcji FeatureSwitchKey.Zero zasługuje na osobną wzmiankę, bo to ona sprawiła, że ta migracja była bezpieczna, a nie ryzykowna.
Od 11 marca nasza produkcyjna aplikacja działała z dwoma kompletnymi UI równolegle. Użytkownicy starego systemu widzieli stare ścieżki. Testerzy wewnętrzni widzieli Zero. Każda strona, którą podłączałem, mogła być testowana w kontekście produkcyjnym bez ryzyka dla workflow użytkowników.
To nie jest rewolucja. Feature flagi to standard. Ale połączenie flag funkcji z workflow design-as-code dało coś wyjątkowego: mogliśmy zweryfikować cały UX nowej platformy (bo Ming zbudowała kompletny, przeglądalny UI), jednocześnie stopniowo nadając każdej stronie funkcjonalność (bo ja podłączałem je po kolei). W każdej chwili, jeśli coś poszło nie tak, mogliśmy przełączyć się z powrotem.
Nic nie poszło nie tak.
Dzień 12: Wielki przełącznik
17 marca otworzyłem PR #5095: refactor: remove all non-zero platform pages and feature flag.
Różnica: +456 linii, -26,041 linii.
Przed: stara platforma VM0. Tabele, identyfikatory run, surowe dane sesji.
Po: nowy Zero. Konwersacyjny workspace AI z przypiętymi agentami i kartami use case.
W jednym merge'u każda stara ścieżka została usunięta. Flaga funkcji zniknęła. Zero nie było już opcją – stało się jedynym trybem. Kolejny PR (#5155) usunął całkowicie prefiks URL /zero: to, co było /zero/chat, stało się po prostu /chat.
Dlaczego miałem pewność, by zrobić ten krok?
- Każda strona działała pod flagą funkcji przez co najmniej 5 dni
- Każda integracja API była testowana na produkcyjnych danych
- Stary i nowy system korzystały z tego samego backendu. To była zamiana frontendu, nie migracja danych
- Mieliśmy prawdziwych użytkowników na nowym systemie, którzy na bieżąco dawali feedback
26,000 linii nie zostało usuniętych z niepokojem. Zostały usunięte z ulgą.
Schemat się powtarza
Najbardziej zaskoczyło mnie nie samo przejście, ale to, że workflow, które odkryliśmy, stało się naszym domyślnym trybem pracy przy każdej kolejnej funkcji. Ming buduje szkielet UI z pomocą AI, ja podpinam logikę i rozbudowuję architekturę. Ten sam wzorzec design-as-code, w skali funkcji:
System uprawnień (marzec 19 → kwiecień 7)
Ming wdrożyła PR #5467, szufladę uprawnień z komponentami Sheet i przełącznikami. Trzy commity, czysty UI.
Dodałem 13 commitów do tego samego PR: migracja bazy dla firewall_access_requests, endpointy API, testy integracyjne, poprawki lintera. W ciągu kolejnych dwóch tygodni 10+ PR rozbudowało pełną warstwę uprawnień: redesign karty zatwierdzeń, powiadomienia Slack o prośbach o dostęp, polecenia CLI doctor do diagnozowania problemów z uprawnieniami i ostatecznie zmianę nazwy całej koncepcji z „firewall” na „permission” w kodzie.
Szuflada Ming była zalążkiem. System uprawnień – drzewem.
System harmonogramu (marzec 23 → kwiecień 13)
Ming zaprojektowała trasę szczegółów harmonogramu i UX kalendarza (#6155). Trzy commity czystej pracy UI.
Dodałem 14 commitów: edycja opisu z autogeneracją, wybór kanału Slack do powiadomień, dialogi potwierdzenia przy niezapisanych zmianach, ujednolicenie widoku kalendarza/listy i kompleksowe testy. Następnie 15+ PR rozwinęło to w pełny system zadań cyklicznych z historią uruchomień, obsługą stref czasowych i wsparciem dla wyrażeń cron.
Integracja Telegram (kwiecień 27 → kwiecień 28)
Na tym etapie schemat był już tak wyćwiczony, że całą integrację platformy wdrożyliśmy w 48 godzin. Ming zbudowała UI ustawień (#11196) i onboarding (#11399). Ja zbudowałem API multi-bot, wysyłanie/odbiór wiadomości, upload/download plików, kontekst bogatych wiadomości, aktualizacje w czasie rzeczywistym przez Ably i testy E2E. Następnego dnia funkcja była dostępna dla wszystkich użytkowników.
Gdzie tu miejsce dla AI
Chcę precyzyjnie określić rolę AI, bo łatwo ją przecenić lub nie docenić.
AI umożliwiło projektantce kodowanie. Ming jest projektantką produktu, nie programistką. Myśli w układach, hierarchiach i interakcjach, nie w hookach Reacta i generykach TypeScript. Narzędzia AI (Cursor, potem Claude Code) zniwelowały tę lukę, tłumacząc intencje projektowe na działający kod. Ming kierowała, AI pisało. Efektem był kod, który stworzyła projektantka, a inżynier mógł rozwijać.
AI przyspieszyło pętlę przeglądu. Przy wspólnych PR mój agent AI przeglądał kod Ming, klasyfikował problemy według priorytetu (P0/P1/P2) i bezpośrednio pushował poprawki. PR #5060 przeszedł pięć rund przeglądu w 38 minut. PR #5467 – trzy rundy w 20 minut. To nie jest „AI zastępujące code review”. Nadal czytam każdą zmianę. Ale mechaniczna praca wykrywania błędów lintera, brakujących typów i luk w testach została zautomatyzowana.
AI nie podejmowało decyzji projektowych. Architektura informacji każdej strony, wzorce interakcji, hierarchia wizualna – to pochodziło z instynktu Ming, popartego badaniami użytkowników i wiedzą domenową. AI może wygenerować stronę ustawień, ale nie zdecyduje, co powinno być przełącznikiem, a co rozwijaną listą, ani kiedy dialog potwierdzenia jest potrzebny, a kiedy jest zbędnym tarciem.
AI nie podejmowało decyzji architektonicznych. Wybór flagi funkcji do wdrożenia równoległego, strategia separacji warstwy API, decyzja o stopniowym podpinaniu stron zamiast hurtowo – to były decyzje inżynierskie. AI pomogło mi pisać kod szybciej, ale kolejność i zarządzanie ryzykiem były po stronie człowieka.
Szczere podsumowanie: AI wyeliminowało warstwę tłumaczenia między designem a inżynierią. Nie zastąpiło żadnej z tych ról – usunęło lukę między nimi.
Co się zmieniło w mojej roli
Po trzech miesiącach w tym workflow inaczej patrzę na swoją rolę frontend developera.
Nie jestem już tłumaczem wizualnym. Czasy, gdy dostawałem plik Figma i godzinami dopasowywałem odstępy, minęły. Nie dlatego, że robię to szybciej, ale bo to już nie moja rola. Intencja projektanta trafia jako kod, nie obrazek kodu.
Jestem rozbudowującym architekturę. Moja główna wartość to wzięcie działającej powierzchni UI i budowanie pod spodem niewidzialnej infrastruktury: integracji API, walidacji danych, obsługi błędów, kontroli uprawnień, aktualizacji w czasie rzeczywistym, testów. Proporcje commitów w większości wspólnych PR mówią same za siebie. Ming wnosi 3 commitów UI, ja 13 commitów reszty.
Jestem strażnikiem jakości. Dzięki AI-wspomaganym pętlom przeglądu mogę utrzymać jakość kodu na znacznie większej powierzchni niż wcześniej. Automatyczny przegląd wyłapuje kwestie mechaniczne, ja skupiam się na architekturze, edge-case'ach i upewnieniu się, że funkcja działa end-to-end.
Jestem strategiem wdrożenia. Flagi funkcji, stopniowe podpinanie, wdrożenia równoległe – kolejność przejścia funkcji z kodu do produkcji to teraz kluczowa część mojej pracy, nie dodatek.
Liczby
Trzy miesiące. Dwie osoby. Wspomaganie AI przez cały czas.
- 914 zmergowanych PR (679 moich, 235 Ming)
- 12 dni od pierwszego scaffoldu do pełnej wymiany platformy
- 48 godzin na pełną integrację Telegram (nasza najszybsza funkcja)
- 26,000 linii usuniętych w jednym pewnym merge'u
- 88% moich PR i 66% Ming mają współautorstwo AI
To nie są metryki „hustle”. Żadne z nas nie pracowało w weekendy ani po nocach. Szybkość wynika z eliminacji martwego czasu: spotkań przekazujących, nieporozumień w specyfikacji, wymiany „przesuń to o 4px”. Gdy intencja projektowa trafia bezpośrednio do kodu, a inżynier rozwija ten kod na miejscu, po prostu jest mniej strat.
Co to oznacza dla zespołów
Nie twierdzę, że każdy zespół powinien tak pracować. Ten workflow powstał w naszym specyficznym kontekście: mały zespół, okazja do przebudowy od zera, wczesny dostęp do zaawansowanych narzędzi AI do kodowania. Wasze doświadczenia mogą być inne.
Ale wierzę, że podstawowa zmiana jest uniwersalna: granica między designem a inżynierią się zaciera, a AI jest rozpuszczalnikiem. Gdy AI coraz lepiej tłumaczy intencje na kod, coraz więcej projektantów będzie wdrażać kod bezpośrednio. Wtedy inżynierowie będą mniej czasu poświęcać na tłumaczenie, a więcej na architekturę, jakość i wdrożenie.
Rola frontend developera nie znika. Zmienia kształt. I szczerze? Ten nowy kształt jest ciekawszy.
Yuma jest frontend developerem w VM0, gdzie buduje platformę napędzającą Zero, system operacyjny AI agentów. Usunął już więcej starego kodu, niż chciałby przyznać.
