Frontend-kehittäjän näkökulma uuteen tuotekehitysprosessiin AI-aikakaudella
Luku, joka ei pitäisi olla mahdollinen
12 päivää. Kaksi ihmistä: tuotesuunnittelija ja frontend-kehittäjä. Yksi täydellinen alustan uudelleenrakennus.
Ei prototyyppi. Ei MVP. Täysi tuotantokäytössä olevan sovelluksen korvaus, joka huipentui yhteen PR:ään, joka poisti 26,000 riviä vanhaa koodia. Jokainen sivu, jokainen reitti, jokainen vuorovaikutus rakennettiin alusta asti ja toimitettiin oikeille käyttäjille.
Perinteisessä tuotekehitysprosessissa tämä aikataulu on järjetön. Tämän laajuinen projekti veisi tyypillisesti kuukausia: viikkoja suunnittelun tutkimista Figmassa, useita sidosryhmien arviointikierroksia, luovutusseremonia, sprinttisuunnittelu ja sitten hidas, pikselintarkan toteutuksen vaihe. Se, mitä tässä tapahtui, oli perustavanlaatuisesti erilaista. Ei siksi, että olisimme tehneet enemmän töitä, vaan koska tapamme työskennellä yhdessä muuttui.
Tämä on tarina siitä, miten toimitimme Zero-alustan VM0:lla ja mitä opin tuote- ja kehitystiimien yhteistyön tulevaisuudesta.
Vanha pullonkaula
Jokainen frontend-kehittäjä tuntee perinteisen putken:
- Suunnittelija tekee mockupit Figmaan
- Suunnittelun arviointi, iterointi, hyväksyntä
- Annotoidut speksit väleillä, väreillä, taukopisteillä
- Kehittäjä kääntää visuaaliset speksit koodiksi
- Edestakaisin: "Voitko siirtää tämän 4px vasemmalle?"
- Lopulta API-kerroksen yhdistäminen
- Integraatiotestaus, lisää edestakaista viestintää
Pullonkaula ei ollut koskaan yhdessä vaiheessa. Se oli vaiheiden välissä: odottamisessa, tiedon katoamisessa, kontekstin vaihtamisessa. Suunnittelijan mielikuva vuorovaikutuksesta, kun se litistetään staattiseksi Figma-kehikoksi ja merkitään punaviivoin, saapuu kehittäjän pöydälle jo heikentyneenä. Kehittäjä rakentaa version siitä, mitä suunnittelija kuvitteli, mutta se on väistämättä häviöllinen kopio.
Olimme tottuneet tähän kitkaan niin, ettemme enää huomanneet sitä. Se oli vain "näin tämä toimii".
Kokeilu: Entä jos suunnittelija toimittaa koodia?
5. maaliskuuta 2026 Ming, tuotesuunnittelijamme, avasi PR #3685: feat(platform): add zero app with shell, pages and polish. Se lisäsi 4,146 riviä toimivaa React-koodia.
Ei Figma-tiedosto. Ei design token -vienti. Toimiva sovellus.
PR sisälsi täydellisen sovelluksen rungon: sivupalkkinavigoinnin, reittirakenteen, sivupohjat chatille, aikataululle, aktiviteetille, tiiminhallinnalle ja asetuksille, kaikki tyylitelty design-järjestelmämme mukaisesti ja renderöity selaimessa. Data oli mockattua, mutta käyttöliittymä oli aito. Voit npm run dev ja klikata läpi jokaisen sivun.
Ming ei kirjoittanut tätä koodia perinteisessä mielessä alusta asti. Hän käytti AI-koodausvälineitä (ensin Cursor, myöhemmin Claude Code) kääntämään suunnittelun suoraan React-komponenteiksi. AI hoiti mekaanisen käännöksen (JSX-rakenne, CSS-ominaisuudet, komponenttien koostaminen), kun taas Ming ohjasi visuaaliset ja vuorovaikutukselliset päätökset, joita AI ei voi tehdä: asettelun rytmin, tiedon hierarkian, siirtymien tuntuman.
Seuraavien neljän päivän aikana saapui kolme PR:ää lisää:
| Päivä | PR | Mitä Ming toimitti |
|---|---|---|
| 5. maalis | #3685 | Sovelluksen runko, sivupalkki, kaikki sivupohjat (+4,146 riviä) |
| 6. maalis | #3825 | Aikataulusivut, UI-viimeistely (+2,650 riviä) |
| 9. maalis | #3993 | Onboarding-vaihe, Slack-asetusdialogi (+1,146 riviä) |
| 9. maalis | #4050 | Tietosivu, kelluva navigointikortti |
9. maaliskuuta mennessä koko uuden alustamme frontend oli olemassa toimivana koodina. Jokainen tuotantoon tuleva sivu oli jo klikattavissa kehitysympäristössä. Se ei vain vielä tehnyt mitään oikeaa.
Siinä kohtaa minä astuin mukaan.
Uusi työni: Sielun tuominen
Kun avasin koodipohjan 9. maaliskuuta, en kohdannut tavanomaista haastetta litteän suunnittelun kääntämisestä koodiksi. Koodi oli jo olemassa. Tehtäväni oli korvata jokainen mock oikealla toiminnallisuudella, yhdistää jokainen kauniisti suunniteltu pinta elävään backend-järjestelmään.
Tämä muutti työni perustavanlaatuisesti. Pikseleiden sijaan ajattelin datavirtoja. En kysynyt "vastaako tämä mockupia?", vaan "mitä API-kutsua tämä sivu tarvitsee ja mitä tapahtuu, jos se epäonnistuu?"
Tältä ensimmäinen viikkoni näytti:
Päivä 1 (9. maaliskuuta): Autentikointi ja organisaation vaihto. Kytkin Mingin rungon Clerk-autentikointiin, lisäsin domainien väliset uudelleenohjaukset ja tein organisaatiovaihtajasta oikeasti toimivan. Kaksi PR:ää, molemmat yhdistetty samana päivänä.
Päivä 2 (10. maaliskuuta): Yhdistimet ja aikataulu. Korvasin mock-yhdistintaulukon oikealla API-datalla, kytkin aikatauluvälilehden oikeisiin cron-töihin ja yhdistin ohjeeditorin backend-järjestelmään. Neljä PR:ää.
Päivä 3 (11. maaliskuuta): Iso kytkentäpäivä. Tiimisivu sai oikeat subagent-tiedot (+3,271 riviä). Aktiviteettisivu sai oikeat lokit. Ja kruununjalokivi: chat-sivu yhdistettiin oikeaan agentin suoritusputkeen, korvaten ~1,200 riviä demokoodia toimivalla AI-keskustelukäyttöliittymällä. Samana päivänä otin käyttöön FeatureSwitchKey.Zero, ominaisuuslipun, jonka avulla pystyimme ajamaan vanhaa ja uutta alustaa rinnakkain.
Päivät 4-5 (12-13. maaliskuuta): Tiedostoliitteet, istunnonhallinta, monen agentin chat, asetusten tallennus. Jokainen Mingin rakentama sivu teki nyt oikeaa työtä.
Rytmi oli lähes musiikillinen. Joka aamu valitsin Mingin rungosta sivun, tutkin sen komponenttirakenteen, selvitin mitä dataa se odotti, rakensin API-integraation, käsittelin virhetilat ja puskin muutokset. Iltapäivään mennessä taas yksi sivu oli elossa.
Ominaisuuslippu: Rinnakkaiset maailmat
FeatureSwitchKey.Zero-ominaisuuslippu ansaitsee oman mainintansa, koska se teki tästä migraatiosta turvallisen eikä uhkarohkean.
11. maaliskuuta alkaen tuotantosovelluksemme ajoi kahta täyttä käyttöliittymää rinnakkain. Vanhan järjestelmän käyttäjät näkivät vanhat reitit. Sisäiset testaajat näkivät Zeron. Jokainen sivu, jonka kytkin, voitiin testata tuotantoympäristössä vaarantamatta yhdenkään käyttäjän työnkulkuja.
Tämä ei ole vallankumouksellista. Ominaisuusliput ovat vakiokäytäntö. Mutta yhdistettynä design-as-code-työskentelyyn syntyi jotain erityistä: pystyimme validoimaan koko uuden alustan käyttökokemuksen (koska Ming oli rakentanut täydellisen, selattavan käyttöliittymän) samalla kun tein jokaisesta sivusta toiminnallisen (kytkemällä ne yksi kerrallaan). Jos jokin meni pieleen, voitiin aina kääntää kytkin takaisin.
Mikään ei mennyt pieleen.
Päivä 12: Iso kytkin
17. maaliskuuta avasin PR #5095: refactor: remove all non-zero platform pages and feature flag.
Diff: +456 riviä, -26,041 riviä.
Ennen: vanha VM0 Platform. Taulukot, suoritus-ID:t ja raakadata istunnoista.
Jälkeen: uusi Zero. Keskusteleva AI-työtila kiinnitetyillä agenteilla ja käyttötapakorteilla.
Yhdessä merge-hetkessä kaikki vanhat reitit poistettiin. Ominaisuuslippu poistettiin. Zero ei ollut enää vaihtoehto; se oli ainoa tila. Seuraava PR (#5155) poisti /zero-URL-etuliitteen kokonaan: aiempi /zero/chat oli nyt yksinkertaisesti /chat.
Miksi uskalsin tehdä tämän leikkauksen? Koska:
- Jokainen sivu oli ollut ominaisuuslipun alla vähintään 5 päivää
- Jokainen API-integraatio oli testattu tuotantodatalla
- Vanha ja uusi järjestelmä käyttivät samaa backendia. Kyseessä oli frontend-vaihto, ei datamigraatio
- Meillä oli oikeita käyttäjiä uudessa järjestelmässä antamassa palautetta koko ajan
26,000 riviä ei poistettu ahdistuneena. Ne poistettiin helpotuksesta.
Kaava toistuu
Eniten yllätti, ettei migraatio itsessään, vaan että löytämämme työnkulku muuttui oletukseksi kaikille seuraaville ominaisuuksille. Ming rakentaa UI-rungon AI-avusteisesti, minä kytken logiikan ja laajennan arkkitehtuuria. Sama design-as-code-kaava, ominaisuustasolla:
Oikeuksien hallinta (maaliskuu 19 → huhtikuu 7)
Ming toimitti PR #5467, oikeuksien hallintalaatikon Sheet-komponenteilla ja kytkimillä. Kolme committia, siisti UI.
Lisäsin 13 committia samaan PR:ään: tietokantamigraatio firewall_access_requests:lle, API-päätepisteet, integraatiotestit, lint-korjaukset. Seuraavien kahden viikon aikana 10+ jatko-PR:ää rakensivat koko oikeuskerroksen: hyväksymiskortin uudelleensuunnittelu, Slack-ilmoitukset käyttöoikeuspyynnöistä, CLI doctor -komennot oikeusongelmien diagnosointiin ja lopulta koko käsitteen uudelleennimeäminen "firewallista" "permissioniksi" koodipohjassa.
Mingin laatikko oli siemen. Oikeusjärjestelmä oli puu.
Aikataulujärjestelmä (maaliskuu 23 → huhtikuu 13)
Ming suunnitteli aikataulun yksityiskohtareitin ja kalenterin käyttöliittymän (#6155). Kolme committia siistiä UI-työtä.
Lisäsin 14 committia: kuvausten muokkaus automaattisella generoinnilla, Slack-kanavan valinta ilmoituksille, tallentamattomien muutosten varoitukset, kalenteri/listanäkymän yhdistäminen ja kattavat testit. Sitten 15+ jatko-PR:ää laajensivat sen täydeksi toistuvien tehtävien järjestelmäksi, jossa on suoritushistoria, aikavyöhyketuki ja cron-lausekkeet.
Telegram-integraatio (huhtikuu 27 → huhtikuu 28)
Tässä vaiheessa kaava oli niin hioutunut, että toimitimme kokonaisen alustan integraation 48 tunnissa. Ming rakensi Settings UI:n (#11196) ja Onboarding-vaiheen (#11399). Minä rakensin multi-bot-API:n, viestien lähetyksen/vastaanoton, tiedostojen latauksen, rikkaan viestikontekstin, Ably-reaaliaikapäivitykset ja E2E-testit. Seuraavana päivänä ominaisuus oli käytössä kaikilla käyttäjillä.
Missä AI tulee mukaan
Haluan olla tarkka AI:n roolista, koska sitä on helppo joko liioitella tai vähätellä.
AI mahdollisti suunnittelijan koodauksen. Ming on tuotesuunnittelija, ei ohjelmistokehittäjä. Hän ajattelee asetteluja, hierarkioita ja vuorovaikutuksia, ei React-hookeja ja TypeScript-generiikkaa. AI-työkalut (Cursor, sitten Claude Code) kurottivat tämän kuilun hoitamalla mekaanisen käännöksen suunnittelutarkoituksesta toimivaksi koodiksi. Ming ohjasi, AI kirjoitti. Lopputuloksena oli koodi, jonka suunnittelija oli tehnyt, mutta jonka kehittäjä pystyi laajentamaan.
AI nopeutti tarkistuskierrosta. Yhteisissä PR:issä AI-agenttini tarkisti Mingin koodin, luokitteli ongelmat tärkeysjärjestykseen (P0/P1/P2) ja puski korjauscommitit suoraan. PR #5060 kävi läpi viisi tarkistuskierrosta 38 minuutissa. PR #5467 kolme kierrosta 20 minuutissa. Tämä ei ole "AI korvaa kooditarkistuksen". Luin silti jokaisen muutoksen. Mutta mekaaninen työ lint-ongelmien, puuttuvien tyyppien ja testiaukkojen tunnistamisessa automatisoitiin pois.
AI ei tehnyt suunnittelupäätöksiä. Jokaisen sivun tietorakenne, vuorovaikutusmallit, visuaalinen hierarkia: nämä tulivat Mingin tuotevaistosta, käyttäjätutkimuksesta ja alan asiantuntemuksesta. AI voi generoida asetussivun, mutta ei voi päättää, mikä on kytkin ja mikä pudotusvalikko, tai milloin vahvistusdialogi on perusteltu ja milloin se on kitkaa.
AI ei tehnyt arkkitehtuuripäätöksiä. Päätös käyttää ominaisuuslippua rinnakkaiseen käyttöönottoon, API-kerroksen erottelustrategia, päätös kytkeä sivut vaiheittain eikä kerralla: nämä olivat kehittäjän harkintaa. AI auttoi minua kirjoittamaan koodin nopeammin, mutta järjestys ja riskienhallinta olivat ihmisen vastuulla.
Rehellinen yhteenveto: AI poisti käännöskerroksen suunnittelun ja kehityksen väliltä. Se ei korvannut kumpaakaan osaamista; se poisti niiden välisen kuilun.
Mikä muuttui roolissani
Kolmen kuukauden jälkeen tässä työnkulussa näen frontend-kehittäjän roolini eri tavalla.
En ole enää visuaalinen kääntäjä. Figma-tiedoston vastaanottaminen ja tuntien käyttäminen väliarvojen täsmäämiseen on ohi. Ei siksi, että olisin siinä nopeampi, vaan koska se ei enää ole työni. Suunnittelijan tarkoitus saapuu koodina, ei kuvana koodista.
Olen arkkitehtuurin laajentaja. Pääarvoni on ottaa toimiva käyttöliittymä ja rakentaa sen alle näkymätön infrastruktuuri: API-integraatiot, datan validointi, virheenkäsittely, oikeustarkistukset, reaaliaikapäivitykset, testit. Useimpien yhteis-PR:ien suhdeluku kertoo kaiken. Ming tekee 3 UI-committia, minä teen 13 committia kaikkea muuta.
Olen laadun portinvartija. AI-avusteisten tarkistuskierrosten ansiosta voin ylläpitää koodin laatua paljon laajemmalla alueella kuin ennen. Automaattinen tarkistus löytää mekaaniset ongelmat; minä keskityn arkkitehtuuriin, reunatapauksiin ja siihen, että ominaisuus todella toimii päästä päähän.
Olen toimitusstrategi. Ominaisuusliput, vaiheittainen kytkentä, rinnakkaiset käyttöönotot: se, miten ominaisuus etenee koodista tuotantoon, on nyt ydintehtäväni, ei jälkiajatus.
Numerot
Kolme kuukautta. Kaksi ihmistä. AI-avusteisesti koko ajan.
- 914 yhdistettyä PR:ää (679 minun, 235 Mingin)
- 12 päivää ensimmäisestä rungosta koko alustan korvaamiseen
- 48 tuntia täyteen Telegram-integraatioon (nopein ominaisuutemme)
- 26,000 riviä poistettu yhdessä varmassa yhdistämisessä
- 88% omista PR:istäni ja 66% Mingin PR:stä AI-yhteiskirjoitettuja
Nämä eivät ole suoritusmittareita. Kumpikaan meistä ei tehnyt viikonlopputöitä tai valvonut öitä. Nopeus syntyy kuolleen ajan poistamisesta: luovutuspalaverit, speksien väärinymmärrykset, "voitko siirtää tämän 4px" -edestakainen viestintä. Kun suunnittelutarkoitus virtaa suoraan koodiin ja kehittäjä laajentaa sitä paikan päällä, hukkaa on yksinkertaisesti vähemmän.
Mitä tämä tarkoittaa tiimeille
En väitä, että jokaisen tiimin pitäisi työskennellä näin. Tämä työnkulku syntyi meidän erityisestä kontekstistamme: pieni tiimi, mahdollisuus rakentaa alusta uudelleen puhtaalta pöydältä ja varhainen pääsy kyvykkäisiin AI-koodausvälineisiin. Kokemuksesi voi vaihdella.
Mutta uskon, että taustalla oleva muutos on universaali: raja suunnittelun ja kehityksen välillä hälvenee, ja AI on liuotin. Kun AI-työkalut paranevat tarkoituksen kääntämisessä koodiksi, yhä useampi suunnittelija toimittaa koodia suoraan. Silloin kehittäjät käyttävät vähemmän aikaa käännökseen ja enemmän arkkitehtuuriin, laatuun ja toimitukseen.
Frontend-kehittäjän työ ei ole katoamassa. Se muuttaa muotoaan. Ja rehellisesti? Uusi muoto on kiinnostavampi.
Yuma on frontend-kehittäjä VM0:lla, jossa hän rakentaa alustaa, joka pyörittää Zeroa, AI-agenttien käyttöjärjestelmää. Hän on poistanut enemmän vanhaa koodia kuin haluaisi myöntää.
