En frontend-utviklers syn på den nye produkt-ingeniør-arbeidsflyten i AI-tidsalderen
Et tall som ikke burde gi mening
12 dager. To personer: en produktdesigner og en frontend-utvikler. En komplett plattformombygging.
Ikke en prototype. Ikke et MVP. En fullstendig erstatning av en produksjonsapplikasjon, kulminerende i én PR som slettet 26 000 linjer med gammel kode. Hver side, hver rute, hver interaksjon, bygget opp fra bunnen og levert til ekte brukere.
I enhver tradisjonell produktutviklingsprosess er denne tidslinjen absurd. Et prosjekt av denne størrelsen ville vanligvis tatt måneder: uker med designutforskning i Figma, runder med gjennomgang, en overleveringsseremoni, sprintplanlegging, og så den langsomme jobben med pikselsikker implementering. Det som skjedde her var fundamentalt annerledes. Ikke fordi vi jobbet hardere, men fordi måten vi samarbeidet på endret seg.
Dette er historien om hvordan vi lanserte Zero-plattformen hos VM0, og hva det lærte meg om fremtiden for samarbeid mellom produkt og ingeniør.
Den gamle flaskehalsen
Alle frontend-utviklere kjenner den tradisjonelle prosessen:
- Designer lager skisser i Figma
- Designgjennomgang, iterasjon, godkjenning
- Annoterte spesifikasjoner med avstand, farger, breakpoints
- Utvikler oversetter visuelle spesifikasjoner til kode
- Frem og tilbake: "Kan du flytte dette 4px til venstre?"
- Til slutt koble til API-laget
- Integrasjonstesting, mer frem og tilbake
Flaskehalsen lå aldri i ett enkelt steg. Den lå i mellomrommene mellom stegene: ventingen, tapet i oversettelsen, kontekstbyttene. En designers mentale modell av en interaksjon, når den først er flatet ut til en statisk Figma-ramme og merket med røde linjer, kommer til utvikleren allerede forringet. Utvikleren bygger en versjon av det designeren så for seg, men det blir uunngåelig en tapt kopi.
Vi hadde blitt så vant til denne friksjonen at vi sluttet å legge merke til den. Det var bare "slik ting fungerer".
Eksperimentet: Hva om designeren leverer kode?
Den 5. mars 2026 åpnet Ming, vår produktdesigner, PR #3685: feat(platform): add zero app with shell, pages and polish. Den la til 4,146 linjer fungerende React-kode.
Ikke en Figma-fil. Ikke en eksport av designtokens. En kjørende applikasjon.
PR-en inneholdt et komplett app-skall: sidemeny, rutingstruktur, sideskjeletter for chat, timeplan, aktivitet, teamadministrasjon og innstillinger, alt stylet med vårt designsystem, alt synlig i nettleseren. Dataene var mocket, men brukergrensesnittet var ekte. Du kunne npm run dev og klikke deg gjennom hver side.
Ming skrev ikke denne koden fra bunnen av på tradisjonelt vis. Hun brukte AI-kodeverktøy (først Cursor, senere Claude Code) for å oversette sitt design direkte til React-komponenter. AI-en håndterte den mekaniske oversettelsen (JSX-struktur, CSS-egenskaper, komponentoppsett), mens Ming styrte de visuelle og interaksjonsmessige valgene som ingen AI kan ta: rytmen i layouten, informasjons-hierarkiet, følelsen i overgangene.
De neste fire dagene kom tre PR-er til:
| Dato | PR | Hva Ming leverte |
|---|---|---|
| 5. mar | #3685 | App-skall, sidemeny, alle sideskjeletter (+4,146 linjer) |
| 6. mar | #3825 | Timeplansider, UI-polering (+2,650 linjer) |
| 9. mar | #3993 | Onboardingflyt, Slack-konfigurasjonsdialog (+1,146 linjer) |
| 9. mar | #4050 | Om-side, flytende navigasjonskort |
Innen 9. mars eksisterte hele frontend-flaten til vår nye plattform som kjørende kode. Hver side du til slutt ville se i produksjon var allerede klikkbar i et utviklingsmiljø. Den gjorde bare ikke noe ekte ennå.
Det var her jeg kom inn.
Min nye jobb: Å gi sjel til koden
Da jeg åpnet kodebasen 9. mars, sto jeg ikke overfor den vanlige utfordringen med å oversette et flatt design til kode. Koden var allerede der. Min jobb var å erstatte alle mock-data med virkelighet, å koble hver vakkert designet flate til den levende backend-en under.
Dette endret arbeidet mitt på en grunnleggende måte. I stedet for å tenke på piksler, tenkte jeg på dataflyt. I stedet for å spørre "stemmer dette med skissen?", spurte jeg "hvilket API-kall trenger denne siden, og hva skjer hvis det feiler?"
Slik så min første uke ut:
Dag 1 (9. mars): Autentisering og organisasjonsbytte. Jeg koblet Mings skall til Clerk-autentisering, la til kryssdomene-videresendinger, og gjorde at org-bytteren faktisk byttet organisasjon. To PR-er, begge merget samme dag.
Dag 2 (10. mars): Koblede integrasjoner og timeplan. Jeg erstattet det mockede integrasjonsrutenettet med ekte API-data, koblet timeplanfanen til faktiske cron-jobber, og koblet instruksjonseditoren til backend. Fire PR-er.
Dag 3 (11. mars): Den store koblingsdagen. Teamsiden fikk ekte subagent-data (+3,271 linjer). Aktivitetsiden fikk ekte logger. Og kronen på verket: chatsiden ble koblet til den faktiske agent-run-pipelinen, og erstattet ~1,200 linjer med demokode med et fungerende AI-samtalegrensesnitt. Samme dag introduserte jeg FeatureSwitchKey.Zero, en feature flag som lot oss kjøre gamle og nye plattformen side om side.
Dagene 4-5 (12-13. mars): Filvedlegg, øktstyring, multi-agent chat, innstillingspersistens. Hver side Ming hadde bygget gjorde nå ekte arbeid.
Rytmen var nesten musikalsk. Hver morgen valgte jeg en side fra Mings stillas, studerte komponentstrukturen, identifiserte hvilke data den trengte, bygde API-integrasjonen, håndterte feilsituasjoner og pushet. Innen ettermiddagen var enda en side levende.
Funksjonsbryteren: Parallelle verdener
FeatureSwitchKey.Zero-feature flaggen fortjener egen omtale, fordi det var den som gjorde denne migreringen trygg i stedet for risikabel.
Fra og med 11. mars kjørte produksjonsappen vår to komplette brukergrensesnitt parallelt. Brukere på det gamle systemet så de gamle rutene. Interne testere på det nye systemet så Zero. Hver side jeg koblet opp kunne testes i produksjonskontekst uten å risikere en eneste brukers arbeidsflyt.
Dette er ikke revolusjonerende. Feature flags er standard praksis. Men kombinasjonen av feature flags og design-as-code-arbeidsflyten skapte noe spesielt: vi kunne validere hele brukeropplevelsen til den nye plattformen (fordi Ming hadde bygget et komplett, klikkbart UI) mens jeg gradvis gjorde hver side funksjonell (fordi jeg koblet dem opp én etter én). Hvis noe gikk galt, kunne vi når som helst slå bryteren tilbake.
Ingenting gikk galt.
Dag 12: Den store overgangen
Den 17. mars åpnet jeg PR #5095: refactor: remove all non-zero platform pages and feature flag.
Diffen: +456 linjer, -26,041 linjer.
Før: den gamle VM0-plattformen. Tabeller, run-ID-er og rå øktdata.
Etter: nye Zero. Et samtalebasert AI-arbeidsområde med festede agenter og brukskort.
I én merge ble alle gamle ruter slettet. Feature flaggen ble fjernet. Zero var ikke lenger et valg; det var eneste modus. En oppfølgings-PR (#5155) fjernet /zero-URL-prefikset helt: det som hadde vært /zero/chat ble bare /chat.
Hvorfor følte jeg meg trygg på å gjøre dette kuttet? Fordi:
- Hver side hadde kjørt under feature flaggen i minst 5 dager
- Hver API-integrasjon var testet mot produksjonsdata
- Gamle og nye systemer delte samme backend. Dette var en frontend-bytte, ikke en datamigrering
- Vi hadde ekte brukere på det nye systemet som ga tilbakemeldinger underveis
26 000 linjer ble ikke slettet med angst. De ble slettet med lettelse.
Mønsteret gjentar seg
Det som overrasket meg mest var ikke selve migreringen. Det var at arbeidsflyten vi hadde funnet ble vår standard for hver nye funksjon etterpå. Ming bygger UI-skallet med AI-hjelp, jeg kobler på logikken og utvider arkitekturen. Samme design-as-code-mønster, i funksjonsskala:
Rettighetssystem (mars 19 → april 7)
Ming leverte PR #5467, en rettighetsskuff med Sheet-komponenter og brytere. Tre commits, rent UI.
Jeg la til 13 commits i samme PR: databasemigrering for firewall_access_requests, API-endepunkter, integrasjonstester, lint-rettinger. Så, over de neste to ukene, bygde 10+ oppfølgings-PR-er ut hele rettighetslaget: redesign av godkjenningskort, Slack-varsler for tilgangsforespørsler, CLI-doctor-kommandoer for å diagnostisere rettighetsproblemer, og til slutt omdøping av hele konseptet fra "firewall" til "permission" i kodebasen.
Mings skuff var frøet. Rettighetssystemet ble treet.
Timeplansystem (mars 23 → april 13)
Ming designet detaljruten for timeplan og kalender-UX (#6155). Tre commits med rent UI-arbeid.
Jeg la til 14 commits: redigering av beskrivelse med autogenerering, valg av Slack-kanal for varsler, bekreftelsesdialoger for ulagrede endringer, sammenslåing av kalender- og listevisning, og omfattende tester. Så utvidet 15+ oppfølgings-PR-er det til et komplett system for tilbakevendende oppgaver med kjørelogg, tidssonehåndtering og cron-uttrykk.
Telegram-integrasjon (april 27 → april 28)
På dette tidspunktet var mønsteret så innarbeidet at vi leverte en hel plattformintegrasjon på 48 timer. Ming bygde innstillings-UI (#11196) og onboarding-flyt (#11399). Jeg bygde multi-bot-API, sending/mottak av meldinger, filopplasting/-nedlasting, rik meldingskontekst, Ably sanntidsoppdateringer og E2E-tester. Neste dag var det aktivert for alle brukere.
Hvor AI passer inn
Jeg vil være presis om AI sin rolle her, fordi det er lett å enten overdrive eller undervurdere den.
AI gjorde det mulig for designeren å kode. Ming er produktdesigner, ikke programvareutvikler. Hun tenker i layout, hierarkier og interaksjoner, ikke i React-hooks og TypeScript-generics. AI-verktøy (Cursor, deretter Claude Code) bygde broen ved å håndtere den mekaniske oversettelsen fra designintensjon til fungerende kode. Ming styrte; AI skrev. Resultatet var kode som en designer hadde laget, men som en utvikler kunne bygge videre på.
AI akselererte gjennomgangssyklusen. På samarbeids-PR-er gjennomgikk min AI-agent Mings kode, klassifiserte problemer etter prioritet (P0/P1/P2), og pushet fiks-commits direkte. PR #5060 gikk gjennom fem gjennomganger på 38 minutter. PR #5467 fullførte tre runder på 20 minutter. Dette er ikke "AI som erstatter kodegjennomgang". Jeg leste fortsatt hver endring. Men det mekaniske arbeidet med å finne lint-feil, manglende typer og testhull ble automatisert bort.
AI tok ikke designbeslutningene. Informasjonsarkitekturen på hver side, interaksjonsmønstrene, den visuelle hierarkiet: dette kom fra Mings produktinstinkt, informert av brukerinnsikt og domeneekspertise. AI kan generere en innstillingsside, men kan ikke avgjøre hva som skal være en bryter versus en nedtrekksmeny, eller når en bekreftelsesdialog er nødvendig kontra når det er friksjon.
AI tok ikke arkitekturbeslutningene. Valget om å bruke feature flag for parallell utrulling, strategien for API-lagsseparasjon, beslutningen om å koble opp sider gradvis i stedet for alt på én gang: dette var ingeniørvurderinger. AI hjalp meg å skrive koden raskere, men rekkefølgen og risikohåndteringen var menneskelig.
Den ærlige oppsummeringen: AI fjernet oversettelseslaget mellom design og utvikling. Den erstattet ikke noen av disiplinene; den fjernet gapet mellom dem.
Hva som endret seg i min rolle
Etter å ha jobbet slik i tre måneder ser jeg min rolle som frontend-utvikler annerledes.
Jeg er ikke lenger en visuell oversetter. Dagene med å motta en Figma-fil og bruke timer på å matche avstand er over. Ikke fordi jeg er raskere, men fordi det ikke lenger er min jobb. Designerens intensjon kommer som kode, ikke som et bilde av kode.
Jeg er en arkitekturforlenger. Min viktigste verdi er å ta en fungerende UI-flate og bygge den usynlige infrastrukturen under: API-integrasjoner, datavalidering, feilhåndtering, rettighetskontroller, sanntidsoppdateringer, tester. Forholdet på de fleste samarbeids-PR-er sier alt. Ming bidrar med 3 commits UI, jeg bidrar med 13 commits av alt annet.
Jeg er en kvalitetsportvokter. Med AI-assisterte gjennomganger kan jeg opprettholde kodekvalitet over et mye større område enn før. Den automatiserte gjennomgangen fanger de mekaniske feilene; jeg fokuserer på arkitektur, edge cases og at funksjonen faktisk virker fra ende til ende.
Jeg er en leveringsstrateg. Feature flags, gradvis kobling, parallelle utrullinger: rekkefølgen på hvordan en funksjon går fra kode til produksjon er nå en kjerneoppgave, ikke en ettertanke.
Tallene
Tre måneder. To personer. AI-assistert hele veien.
- 914 merge-de PR-er (679 mine, 235 Mings)
- 12 dager fra første stillas til full plattformbytte
- 48 timer for en komplett Telegram-integrasjon (vår raskeste funksjon)
- 26 000 linjer slettet i én trygg merge
- 88% av mine PR-er og 66% av Mings har AI-medforfatterskap
Dette er ikke prestasjonsmålinger. Ingen av oss jobbet helger eller tok netter. Farten kommer av å fjerne dødtid: overleveringsmøter, misforståelser i spesifikasjoner, frem-og-tilbake om "kan du flytte dette 4px". Når designintensjon flyter direkte inn i kode, og utvikling utvider den koden på stedet, blir det rett og slett mindre sløsing.
Hva dette betyr for team
Jeg påstår ikke at alle team bør jobbe slik. Denne arbeidsflyten oppsto i vår kontekst: et lite team, en grønnfelt-ombygging, og tidlig tilgang til gode AI-kodeverktøy. Din erfaring vil variere.
Men jeg tror det underliggende skiftet er universelt: grensen mellom design og utvikling viskes ut, og AI er løsemiddelet. Etter hvert som AI-verktøy blir bedre til å oversette intensjon til kode, vil flere designere levere kode direkte. Da vil utviklere bruke mindre tid på oversettelse og mer på arkitektur, kvalitet og leveranse.
Frontend-utviklerens jobb forsvinner ikke. Den endrer form. Og ærlig talt? Den nye formen er mer interessant.
Yuma er frontend-utvikler hos VM0, hvor han bygger plattformen som driver Zero, et operativsystem for AI-agenter. Han har slettet mer gammel kode enn han liker å innrømme.
