Het perspectief van een frontend engineer op de nieuwe product-engineering workflow in het AI-tijdperk
Een Getal Dat Niet Klopt
12 dagen. Twee mensen: een product designer en een frontend engineer. Een volledige platformrebuild.
Geen prototype. Geen MVP. Een volledige vervanging van een productieapplicatie, resulterend in één enkele PR die 26,000 regels legacy code verwijderde. Elke pagina, elke route, elke interactie, vanaf nul opnieuw opgebouwd en geleverd aan echte gebruikers.
In een traditioneel productontwikkelingsproces is deze tijdlijn absurd. Een project van deze omvang duurt normaal maanden: weken design in Figma, rondes stakeholderreview, een overdrachtsmoment, sprintplanning, en dan het trage proces van pixel-perfect implementatie. Wat hier gebeurde was fundamenteel anders. Niet omdat we harder werkten, maar omdat onze samenwerking veranderde.
Dit is het verhaal van hoe we het Zero-platform bij VM0 lanceerden, en wat het mij leerde over de toekomst van samenwerking tussen product en engineering.
De Oude Bottleneck
Elke frontend engineer kent de traditionele pipeline:
- Designer maakt mockups in Figma
- Design review, iteratie, goedkeuring
- Gespecificeerde specs met spacing, kleuren, breakpoints
- Engineer vertaalt visuele specs naar code
- Over-en-weer: "Kun je dit 4px naar links schuiven?"
- Tot slot de API-laag koppelen
- Integratietests, nog meer afstemming
De bottleneck zat nooit in één stap. Het zat in de gaten tussen de stappen: het wachten, het vertaalverlies, het schakelen van context. Het mentale model van een designer, eenmaal platgeslagen tot een statisch Figma-frame met annotaties, komt bij de engineer al gedegradeerd aan. De engineer bouwt een versie van wat de designer bedoelde, maar het blijft een verlieslatende kopie.
We waren zo gewend aan deze wrijving dat we het niet meer zagen. Het was gewoon "hoe het werkt".
Het Experiment: Wat Als De Designer Code Shipte?
Op 5 maart 2026 opende Ming, onze product designer, PR #3685: feat(platform): add zero app with shell, pages and polish. Het voegde 4,146 regels werkende React-code toe.
Geen Figma-bestand. Geen export van design tokens. Een draaiende applicatie.
De PR bevatte een complete app-shell: zijbalknavigatie, routingstructuur, paginaskeletten voor chat, planning, activiteit, teambeheer en instellingen, allemaal gestyled met ons design system, allemaal renderend in de browser. De data was gesimuleerd, maar de UI was echt. Je kon npm run dev en door elke pagina klikken.
Ming schreef deze code niet helemaal zelf op de traditionele manier. Ze gebruikte AI-coderingstools (eerst Cursor, later Claude Code) om haar designvisie direct om te zetten in React-componenten. De AI deed het mechanische vertaalwerk (JSX-structuur, CSS-eigenschappen, componentopbouw), terwijl Ming de visuele en interactiebeslissingen nam die geen AI kan maken: het ritme van de layout, de hiërarchie van informatie, het gevoel van de overgangen.
In de vier dagen daarna volgden drie extra PR's:
| Datum | PR | Wat Ming Shipte |
|---|---|---|
| 5 mrt | #3685 | App-shell, zijbalk, alle paginaskeletten (+4,146 regels) |
| 6 mrt | #3825 | Planningspagina's, UI-polish (+2,650 regels) |
| 9 mrt | #3993 | Onboardingflow, Slack-configuratie dialoog (+1,146 regels) |
| 9 mrt | #4050 | Over-pagina, zwevende navigatiekaart |
Op 9 maart bestond het volledige frontend van ons nieuwe platform als draaiende code. Elke pagina die je uiteindelijk in productie zou zien, was al klikbaar in een ontwikkelomgeving. Het deed alleen nog niets echts.
Daar kwam ik in beeld.
Mijn Nieuwe Taak: De Ziel Injecteren
Toen ik op 9 maart de codebase opende, stond ik niet voor de gebruikelijke uitdaging om een plat design naar code te vertalen. De code was er al. Mijn taak was om elke mock te vervangen door realiteit, om elk prachtig ontworpen oppervlak te koppelen aan de levende backend eronder.
Dit veranderde mijn werk fundamenteel. In plaats van over pixels na te denken, dacht ik aan datastromen. In plaats van "lijkt dit op de mockup?", vroeg ik me af: "welke API-call heeft deze pagina nodig, en wat gebeurt er als die faalt?"
Zo zag mijn eerste week eruit:
Dag 1 (9 maart): Authenticatie en organisatie wisselen. Ik koppelde Ming's shell aan Clerk-authenticatie, voegde cross-domain redirects toe en zorgde dat de org-switcher echt van organisatie wisselde. Twee PR's, beide dezelfde dag gemerged.
Dag 2 (10 maart): Connectors en planning. Ik verving het mock connector grid door echte API-data, koppelde het planningstabblad aan echte cronjobs en verbond de instructie-editor met de backend. Vier PR's.
Dag 3 (11 maart): De grote aansluitdag. Teampagina kreeg echte subagent-data (+3,271 regels). Activiteitspagina kreeg echte logs. En het hoogtepunt: de chatpagina werd verbonden met de echte agent-run pipeline, waarbij ~1,200 regels democode werden vervangen door een werkende AI-gespreksinterface. Diezelfde dag introduceerde ik FeatureSwitchKey.Zero, een feature flag waarmee we het oude en nieuwe platform naast elkaar konden draaien.
Dagen 4-5 (12-13 maart): Bestandsbijlagen, sessiebeheer, multi-agent chat, instellingen persistentie. Elke pagina die Ming had gebouwd deed nu echt werk.
Het ritme was bijna muzikaal. Elke ochtend koos ik een pagina uit Ming's scaffold, bestudeerde de componentstructuur, keek welke data het verwachtte, bouwde de API-integratie, handelde foutafhandeling af, en pushte. Tegen de middag leefde er weer een pagina.
De Feature Switch: Parallelle Werelden
De FeatureSwitchKey.Zero feature flag verdient aparte aandacht, want die maakte deze migratie veilig in plaats van roekeloos.
Vanaf 11 maart draaide onze productie-app twee volledige UI's parallel. Gebruikers op het oude systeem zagen de oude routes. Interne testers op het nieuwe systeem zagen Zero. Elke pagina die ik aansloot kon in productiecontext getest worden zonder het risico dat een gebruiker vastliep.
Dit is niet revolutionair. Feature flags zijn standaardpraktijk. Maar de combinatie van feature flags met de design-as-code workflow leverde iets bijzonders op: we konden de volledige UX van het nieuwe platform valideren (omdat Ming een complete, navigeerbare UI had gebouwd) terwijl ik elke pagina één voor één functioneel maakte. Als er iets misging, konden we altijd terugschakelen.
Er ging niets mis.
Dag 12: De Grote Schakelaar
Op 17 maart opende ik PR #5095: refactor: remove all non-zero platform pages and feature flag.
Het verschil: +456 regels, -26,041 regels.
Voor: het oude VM0 Platform. Tabellen, run-ID's en ruwe sessiedata.
Na: de nieuwe Zero. Een conversational AI-werkruimte met vastgezette agents en use case-kaarten.
Met één merge werden alle legacy routes verwijderd. De feature flag werd weggehaald. Zero was niet langer een optie; het was de enige modus. Een opvolgende PR (#5155) verwijderde het /zero URL-prefix volledig: wat eerst /zero/chat was, werd simpelweg /chat.
Waarom voelde ik me zeker om deze stap te zetten? Omdat:
- Elke pagina draaide al minstens 5 dagen onder de feature flag
- Elke API-integratie was getest met productiedata
- Het oude en nieuwe systeem deelden dezelfde backend. Dit was een frontend swap, geen datamigratie
- We hadden echte gebruikers op het nieuwe systeem die continu feedback gaven
De 26,000 regels werden niet met zenuwen verwijderd. Ze werden met opluchting verwijderd.
Het Patroon Herhaalt Zich
Wat me het meest verraste was niet de migratie zelf. Het was dat de workflow die we ontdekten onze standaard werd voor elke volgende feature. Ming bouwt de UI-shell met AI-hulp, ik sluit de logica aan en breid de architectuur uit. Hetzelfde design-as-code patroon, op feature-niveau:
Permissiesysteem (19 maart → 7 april)
Ming shipte PR #5467, een permissies-drawer UI met Sheet-componenten en toggle-controls. Drie commits, strakke UI.
Ik voegde 13 commits toe aan dezelfde PR: database-migratie voor firewall_access_requests, API-endpoints, integratietests, lint-fixes. In de twee weken daarna bouwden 10+ opvolg-PR's de volledige permissielaag: redesign van de goedkeuringskaart, Slack-notificaties voor toegangsverzoeken, CLI doctor-commando's voor diagnose van permissieproblemen, en uiteindelijk werd het hele concept van "firewall" naar "permission" hernoemd in de codebase.
Ming's drawer was het zaadje. Het permissiesysteem werd de boom.
Planningssysteem (23 maart → 13 april)
Ming ontwierp de planningsdetailroute en kalender-UX (#6155). Drie commits van nette UI-werk.
Ik voegde 14 commits toe: beschrijving bewerken met autogeneratie, Slack-kanaalselectie voor notificaties, bevestigingsdialogen bij niet-opgeslagen wijzigingen, kalender-/lijstweergave-unificatie en uitgebreide tests. Daarna breidden 15+ opvolg-PR's het uit tot een volledig terugkerend taaksysteem met runhistorie, tijdzone-ondersteuning en cron-expressies.
Telegram-integratie (27 april → 28 april)
Op dit punt was het patroon zo ingesleten dat we een volledige platformintegratie in 48 uur shipten. Ming bouwde de Settings-UI (#11196) en Onboarding-flow (#11399). Ik bouwde de multi-bot API, berichten verzenden/ontvangen, upload/download van bestanden, rijke berichtcontext, Ably real-time updates en E2E-tests. De volgende dag was het voor alle gebruikers beschikbaar.
Waar AI Past
Ik wil precies zijn over de rol van AI, want het is makkelijk om het te over- of onderschatten.
AI stelde de designer in staat te coderen. Ming is een product designer, geen software engineer. Ze denkt in layouts, hiërarchieën en interacties, niet in React-hooks en TypeScript-generics. AI-tools (Cursor, daarna Claude Code) overbrugden die kloof door het mechanische vertaalwerk van designintentie naar werkende code te doen. Ming stuurde aan; AI typte. Het resultaat was code die door een designer geschreven was, maar waarop een engineer kon voortbouwen.
AI versnelde de review-loop. Bij gezamenlijke PR's reviewde mijn AI-agent Ming's code, classificeerde issues op prioriteit (P0/P1/P2) en pushte direct fix-commits. PR #5060 doorliep vijf reviewrondes in 38 minuten. PR #5467 drie rondes in 20 minuten. Dit is niet "AI vervangt code review". Ik las nog steeds elke wijziging. Maar het mechanische werk van lint-issues, ontbrekende types en testgaten werd geautomatiseerd.
AI nam de designbeslissingen niet. De informatiearchitectuur van elke pagina, de interactiepatronen, de visuele hiërarchie: die kwamen uit Mings productgevoel, gevoed door gebruikersonderzoek en domeinkennis. AI kan een instellingenpagina genereren, maar niet bepalen wat een toggle of een dropdown moet zijn, of wanneer een bevestigingsdialoog nodig is.
AI nam de architectuurbeslissingen niet. De keuze voor een feature flag voor parallelle uitrol, de API-laag scheiding, de beslissing om pagina's stapsgewijs te koppelen in plaats van alles tegelijk: dat waren engineeringkeuzes. AI hielp me sneller code schrijven, maar de volgorde en risicobeheersing waren menselijk.
De eerlijke samenvatting: AI elimineerde de vertaallaag tussen design en engineering. Het verving geen van beide disciplines; het verwijderde de kloof ertussen.
Wat Er Veranderde Aan Mijn Rol
Na drie maanden in deze workflow zie ik mijn rol als frontend engineer anders.
Ik ben geen visuele vertaler meer. De tijd van een Figma-bestand ontvangen en uren besteden aan het matchen van spacing is voorbij. Niet omdat ik er sneller in ben, maar omdat het niet meer mijn taak is. De intentie van de designer komt als code, niet als een plaatje van code.
Ik ben een architectuur-uitbreider. Mijn belangrijkste waarde is het nemen van een werkend UI-oppervlak en het bouwen van de onzichtbare infrastructuur eronder: API-integraties, datavalidatie, foutafhandeling, permissiechecks, real-time updates, tests. De verhouding in de meeste gezamenlijke PR's zegt genoeg. Ming levert 3 UI-commits, ik 13 commits voor alles daaronder.
Ik ben een kwaliteitsbewaker. Met AI-ondersteunde review-loops kan ik de codekwaliteit over een veel groter oppervlak bewaken dan voorheen. De automatische review vangt de mechanische issues; ik focus op architectuur, edge cases en of de feature echt end-to-end werkt.
Ik ben een delivery-strateeg. Feature flags, stapsgewijs aansluiten, parallelle uitrol: de volgorde waarin een feature van code naar productie gaat is nu een kernonderdeel van mijn werk, geen bijzaak.
De Cijfers
Drie maanden. Twee mensen. AI-ondersteund van begin tot eind.
- 914 gemergede PR's (679 van mij, 235 van Ming)
- 12 dagen van eerste scaffold tot volledige platformvervanging
- 48 uur voor een complete Telegram-integratie (onze snelste feature)
- 26,000 regels verwijderd in één zelfverzekerde merge
- 88% van mijn PR's en 66% van Ming's met AI co-auteurschap
Dit zijn geen hustle-metrics. Geen van ons werkte in het weekend of trok nachten door. De snelheid komt door het elimineren van dode tijd: overdrachtsmeetings, misverstanden over specs, het eindeloze "kun je dit 4px verschuiven". Als designintentie direct in code stroomt, en engineering die code ter plekke uitbreidt, is er gewoon minder verspilling.
Wat Dit Betekent Voor Teams
Ik beweer niet dat elk team zo moet werken. Deze workflow ontstond uit onze context: een klein team, een greenfield-rebuild, en vroege toegang tot goede AI-coderingstools. Jouw situatie kan anders zijn.
Maar ik geloof dat de onderliggende verschuiving universeel is: de grens tussen design en engineering vervaagt, en AI is het oplosmiddel. Naarmate AI beter wordt in het vertalen van intentie naar code, zullen meer designers direct code shippen. Daardoor zullen engineers minder tijd besteden aan vertalen en meer aan architectuur, kwaliteit en levering.
De rol van frontend engineer verdwijnt niet. Ze verandert van vorm. En eerlijk? De nieuwe vorm is interessanter.
Yuma is frontend engineer bij VM0, waar hij het platform bouwt dat Zero aandrijft, een AI agent operating system. Hij heeft meer legacy code verwijderd dan hem lief is.
