En frontend-ingeniørs syn på den nye produkt-ingeniør workflow i AI-tidsalderen
Et tal, der ikke burde give mening
12 dage. To personer: en produktdesigner og en frontend-ingeniør. En komplet platform-genopbygning.
Ikke en prototype. Ikke et MVP. En fuld erstatning af en produktionsapplikation, kulminerende i én PR, der slettede 26,000 linjer legacy-kode. Hver side, hver rute, hver interaktion, genopbygget fra bunden og leveret til rigtige brugere.
I enhver traditionel produktudviklingsproces er denne tidsplan absurd. Et projekt af denne størrelse ville typisk tage måneder: uger med designudforskning i Figma, runder af interessentgennemgang, en overdragelsesceremoni, sprintplanlægning og derefter den langsomme proces med pixelperfekt implementering. Det, der skete her, var fundamentalt anderledes. Ikke fordi vi arbejdede hårdere, men fordi måden vi arbejdede sammen på ændrede sig.
Dette er historien om, hvordan vi lancerede Zero-platformen hos VM0, og hvad det lærte mig om fremtiden for samarbejde mellem produkt og ingeniør.
Den gamle flaskehals
Enhver frontend-ingeniør kender den traditionelle pipeline:
- Designer laver mockups i Figma
- Designgennemgang, iteration, godkendelse
- Annoterede specifikationer med afstande, farver, breakpoints
- Ingeniør oversætter visuelle specs til kode
- Frem og tilbage: "Kan du flytte dette 4px til venstre?"
- Til sidst forbindes API-laget
- Integrationstest, mere frem og tilbage
Flaskehalsen lå aldrig i et enkelt trin. Den lå i hullerne mellem trinene: ventetiden, tabet i oversættelsen, kontekstskiftet. En designers mentale model af en interaktion, når den først er fladet ud til en statisk Figma-ramme og annoteret med røde linjer, ankommer til ingeniørens skrivebord allerede forringet. Ingeniøren genopbygger en version af det, designeren forestillede sig, men det er uundgåeligt en tabsgivende kopi.
Vi var blevet så vant til denne friktion, at vi holdt op med at lægge mærke til den. Det var bare "sådan tingene fungerer".
Eksperimentet: Hvad hvis designeren leverer kode?
Den 5. marts 2026 åbnede Ming, vores produktdesigner, PR #3685: feat(platform): add zero app with shell, pages and polish. Den tilføjede 4,146 linjer fungerende React-kode.
Ikke en Figma-fil. Ikke en eksport af designtokens. En kørende applikation.
PR'en indeholdt et komplet app-skelet: sidebjælkenavigation, routingstruktur, sideskeletter til chat, tidsplan, aktivitet, teamadministration og indstillinger, alt stylet med vores designsystem, alt gengivet i browseren. Dataene var mockede, men UI'et var ægte. Du kunne npm run dev og klikke dig gennem alle sider.
Ming skrev ikke denne kode fra bunden i traditionel forstand. Hun brugte AI-kodeværktøjer (først Cursor, senere Claude Code) til at oversætte sin designvision direkte til React-komponenter. AI'en håndterede den mekaniske oversættelse (JSX-struktur, CSS-egenskaber, komponentkomposition), mens Ming styrede de visuelle og interaktionsmæssige beslutninger, som ingen AI kan tage: layoutets rytme, informationshierarkiet, fornemmelsen af overgange.
I løbet af de næste fire dage landede tre flere PR'er:
| Dato | PR | Hvad Ming leverede |
|---|---|---|
| 18. mar 5 | #3685 | App-skelet, sidebjælke, alle sideskeletter (+4,146 linjer) |
| 21. mar 6 | #3825 | Tidsplansider, UI-polering (+2,650 linjer) |
| 24. mar 9 | #3993 | Onboarding-flow, Slack-konfigurationsdialog (+1,146 linjer) |
| 27. mar 9 | #4050 | Om-side, flydende navigationskort |
Den 9. marts eksisterede hele frontend-overfladen af vores nye platform som kørende kode. Hver side, du til sidst ville se i produktion, var allerede klikbar i et udviklingsmiljø. Den gjorde bare endnu ikke noget reelt.
Det var her, jeg kom ind.
Mit nye job: At give sjæl til koden
Da jeg åbnede kodebasen den 9. marts, stod jeg ikke over for den sædvanlige udfordring med at oversætte et fladt design til kode. Koden var der allerede. Mit job var at erstatte hver mock med virkelighed, at forbinde hver smukt designet overflade til den levende backend nedenunder.
Det ændrede mit arbejde fundamentalt. I stedet for at tænke på pixels, tænkte jeg på dataflows. I stedet for at spørge "matcher dette mockuppet?", spurgte jeg "hvilket API-kald har denne side brug for, og hvad sker der, hvis det fejler?"
Sådan så min første uge ud:
Dag 1 (9. marts): Auth og organisationsskift. Jeg forbandt Mings skelet til Clerk-autentificering, tilføjede cross-domain redirects og fik organisationsskifteren til faktisk at skifte organisation. To PR'er, begge merged samme dag.
Dag 2 (10. marts): Connectorer og tidsplan. Jeg erstattede det mockede connector-grid med rigtige API-data, forbandt tidsplansfanen til faktiske cron-jobs og forbandt instruktionseditoren til backend. Fire PR'er.
Dag 3 (11. marts): Den store forbindelsesdag. Teamsiden fik rigtige subagent-data (+3,271 linjer). Aktivitetsiden fik rigtige logs. Og kronen på værket: chatsiden blev forbundet til det faktiske agent-run pipeline, hvilket erstattede ~1,200 linjer demokode med et fungerende AI-samtaleinterface. Samme dag introducerede jeg FeatureSwitchKey.Zero, et feature flag, der lod os køre de gamle og nye platforme side om side.
Dagene 4-5 (12-13. marts): Filvedhæftninger, session management, multi-agent chat, indstillingspersistens. Hver side, Ming havde bygget, lavede nu rigtigt arbejde.
Rytmen var næsten musikalsk. Hver morgen valgte jeg en side fra Mings skelet, studerede dens komponentstruktur, identificerede hvilke data den forventede, byggede API-integrationen, håndterede fejltilstande og push'ede. Om eftermiddagen var endnu en side levende.
Feature-flaget: Parallelle verdener
FeatureSwitchKey.Zero feature-flaget fortjener sin egen omtale, for det var det, der gjorde denne migration sikker frem for hensynsløs.
Fra 11. marts kørte vores produktionsapp to komplette UI'er parallelt. Brugere på det gamle system så de gamle ruter. Interne testere på det nye system så Zero. Hver side, jeg forbandt, kunne testes i produktionskontekst uden at risikere en eneste brugers workflow.
Det er ikke revolutionerende. Feature-flags er standardpraksis. Men kombinationen af feature-flags med design-as-code-workflowet skabte noget særligt: vi kunne validere hele UX'en på den nye platform (fordi Ming havde bygget et komplet, klikbart UI), mens vi gradvist gjorde hver side funktionel (fordi jeg forbandt dem én efter én). Hvis noget gik galt, kunne vi til enhver tid slå kontakten tilbage.
Intet gik galt.
Dag 12: Den store kontakt
Den 17. marts åbnede jeg PR #5095: refactor: remove all non-zero platform pages and feature flag.
Diffen: +456 linjer, -26,041 linjer.
Før: den gamle VM0 Platform. Tabeller, run-ID'er og rå sessiondata.
Efter: den nye Zero. Et samtalebaseret AI-arbejdsområde med fastgjorte agents og brugskort.
Med ét merge blev alle legacy-ruter slettet. Feature-flaget blev fjernet. Zero var ikke længere en mulighed; det var den eneste tilstand. En opfølgende PR (#5155) fjernede /zero URL-præfikset helt: det, der havde været /zero/chat blev blot /chat.
Hvorfor følte jeg mig tryg ved at lave dette skifte? Fordi:
- Hver side havde kørt under feature-flaget i mindst 5 dage
- Hver API-integration var testet mod produktionsdata
- Det gamle og nye system delte samme backend. Dette var et frontend-skift, ikke en datamigration
- Vi havde rigtige brugere på det nye system, der løbende gav feedback
De 26,000 linjer blev ikke slettet med nervøsitet. De blev slettet med lettelse.
Mønsteret gentager sig
Det, der overraskede mig mest, var ikke selve migrationen. Det var, at workflowet, vi havde opdaget, blev vores standard for hver ny funktion. Ming bygger UI-skelettet med AI-hjælp, jeg forbinder logikken og udvider arkitekturen. Samme design-as-code-mønster, i feature-skala:
Permissions-system (marts 19 → april 7)
Ming leverede PR #5467, en permissions-skuffe UI med Sheet-komponenter og toggle-kontroller. Tre commits, rent UI.
Jeg tilføjede 13 commits til samme PR: databasemigration for firewall_access_requests, API-endpoints, integrationstests, lint-rettelser. Derefter byggede 10+ opfølgende PR'er hele permissionslaget: redesign af godkendelseskort, Slack-notifikationer for adgangsanmodninger, CLI doctor-kommandoer til diagnosticering af permissionsproblemer og til sidst omdøbning af hele konceptet fra "firewall" til "permission" i kodebasen.
Mings skuffe var frøet. Permissions-systemet var træet.
Schedule-system (marts 23 → april 13)
Ming designede schedule-detaljeruten og kalender-UX (#6155). Tre commits med rent UI-arbejde.
Jeg tilføjede 14 commits: redigering af beskrivelse med autogenerering, Slack-kanalvalg til notifikationer, bekræftelsesdialoger for ikke-gemte ændringer, samling af kalender-/listevisning og omfattende tests. Derefter udvidede 15+ opfølgende PR'er det til et fuldt tilbagevendende opgavesystem med run-historik, tidszonehåndtering og cron-udtryk.
Telegram-integration (april 27 → april 28)
På dette tidspunkt var mønsteret så indarbejdet, at vi leverede en hel platformintegration på 48 timer. Ming byggede Settings-UI (#11196) og onboarding-flow (#11399). Jeg byggede multi-bot API, beskedafsendelse/-modtagelse, filupload/-download, rig beskedkontekst, Ably realtidsopdateringer og E2E-tests. Næste dag blev det aktiveret for alle brugere.
Hvor AI passer ind
Jeg vil være præcis om AI's rolle her, for det er let enten at overvurdere eller undervurdere den.
AI gjorde det muligt for designeren at kode. Ming er produktdesigner, ikke softwareingeniør. Hun tænker i layouts, hierarkier og interaktioner, ikke i React hooks og TypeScript generics. AI-værktøjer (Cursor, derefter Claude Code) byggede broen ved at håndtere den mekaniske oversættelse fra designintention til fungerende kode. Ming styrede; AI skrev. Resultatet var kode, som en designer havde forfattet, men som en ingeniør kunne bygge videre på.
AI accelererede review-loopet. På samarbejds-PR'er gennemgik min AI-agent Mings kode, klassificerede problemer efter prioritet (P0/P1/P2) og lavede rettelses-commits direkte. PR #5060 gik igennem fem review-runder på 38 minutter. PR #5467 gennemførte tre runder på 20 minutter. Dette er ikke "AI erstatter code review". Jeg læste stadig hver ændring. Men det mekaniske arbejde med at finde lint-fejl, manglende typer og testhuller blev automatiseret væk.
AI traf ikke designbeslutningerne. Informationsarkitekturen på hver side, interaktionsmønstrene, det visuelle hierarki: disse kom fra Mings produktinstinkt, informeret af brugerundersøgelser og domæneekspertise. AI kan generere en indstillingsside, men kan ikke beslutte, hvad der skal være en toggle kontra en dropdown, eller hvornår en bekræftelsesdialog er nødvendig kontra hvornår det er friktion.
AI traf ikke arkitekturbeslutningerne. Valget om at bruge et feature-flag til parallel udrulning, strategien for API-lagsadskillelse, beslutningen om at forbinde siderne gradvist frem for på én gang: det var ingeniørmæssige vurderinger. AI hjalp mig med at skrive koden hurtigere, men rækkefølgen og risikostyringen var menneskelig.
Den ærlige opsummering: AI eliminerede oversættelseslaget mellem design og ingeniør. Den erstattede ikke nogen af disciplinerne; den fjernede kløften mellem dem.
Hvad der ændrede sig i min rolle
Efter at have arbejdet i dette workflow i tre måneder ser jeg min rolle som frontend-ingeniør anderledes.
Jeg er ikke længere en visuel oversætter. Dage med at modtage en Figma-fil og bruge timer på at matche afstandsværdier er forbi. Ikke fordi jeg er hurtigere til det, men fordi det ikke længere er mit job. Designerens intention ankommer som kode, ikke som et billede af kode.
Jeg er en arkitekturforlænger. Min primære værdi er at tage en fungerende UI-overflade og bygge den usynlige infrastruktur nedenunder: API-integrationer, datavalidering, fejlhåndtering, permissions-tjek, realtidsopdateringer, tests. Forholdet på de fleste samarbejds-PR'er fortæller historien. Ming bidrager med 3 commits UI, jeg bidrager med 13 commits af alt det andet.
Jeg er kvalitetsvogter. Med AI-assisterede review-loops kan jeg opretholde kodekvalitet på et langt større område end før. Den automatiserede review fanger de mekaniske fejl; jeg fokuserer på arkitektur, edge cases og at sikre, at funktionen faktisk virker end-to-end.
Jeg er leveringsstrateg. Feature-flags, gradvis sammenkobling, parallelle udrulninger: rækkefølgen af, hvordan en funktion går fra kode til produktion, er nu en kerneopgave for mig, ikke en eftertanke.
Tallene
Tre måneder. To personer. AI-assisteret hele vejen.
- 914 merged PRs (679 mine, 235 Mings)
- 12 dage fra første skelet til fuld platformserstatning
- 48 timer for en komplet Telegram-integration (vores hurtigste feature)
- 26,000 linjer slettet i ét selvsikkert merge
- 88% af mine PR'er og 66% af Mings har AI-medforfatterskab
Dette er ikke hustle-metrics. Ingen af os arbejdede weekender eller tog nætter i brug. Farten kommer af at eliminere dødtid: overdragelsesmøder, misforståelser i specs, "kan du flytte dette 4px" frem og tilbage. Når designintention flyder direkte ind i kode, og ingeniøren udvider den kode på stedet, er der ganske enkelt mindre spild.
Hvad det betyder for teams
Jeg påstår ikke, at alle teams skal arbejde sådan. Dette workflow opstod ud fra vores specifikke kontekst: et lille team, en grøn markedsmulighed og tidlig adgang til dygtige AI-kodeværktøjer. Jeres erfaring kan variere.
Men jeg tror, det underliggende skifte er universelt: grænsen mellem design og ingeniør er ved at opløses, og AI er opløsningsmidlet. Efterhånden som AI-værktøjer bliver bedre til at oversætte intention til kode, vil flere designere levere kode direkte. Når det sker, vil ingeniører bruge mindre tid på oversættelse og mere tid på arkitektur, kvalitet og levering.
Frontend-ingeniørens job forsvinder ikke. Det ændrer form. Og ærligt? Den nye form er mere interessant.
Yuma er frontend-ingeniør hos VM0, hvor han bygger platformen bag Zero, et AI agent-operativsystem. Han har slettet mere legacy-kode, end han bryder sig om at indrømme.
