Kun prototype kohtaa todellisuuden: Vibe coding ja tuotannon kuilu

Törmäsin viikonloppuna mielenkiintoiseen tilanteeseen. Yrittäjä oli rakentanut toimivan web-sovelluksen AI-työkaluilla parissa päivässä. Ei IT-alan koulutusta, ei koodaajakurssia – pelkkä selkeä idea ja osaava prompt. Prototyyppi oli vaikuttava: kirjautuminen, hallintapaneeli ja datan tallennus pelasivat.

Sitten hän pyysi apua sovelluksen julkaisuun oikeille käyttäjille.

Siinä vaiheessa homma muuttui.

Prototyyppi vs. tuotanto

Viikonloppuprojekti toimi, koska käyttäjiä oli vain yksi. Kun lisäsimme toisen käyttäjän, ilmeni concurrency-bugeja. Tietokannalla ei ollut migraatioita, joten rollback olisi tuhonnut dataa. Testejä ei ollut yhtään, mikä tarkoitti sitä, että mikä tahansa refaktorointi oli kuin kumiankan silmäilemistä pimeässä. Lisäksi käyttöönotto oli täysin manuaalinen prosessi ilman dokumentaatiota.

Loistava proof of concept, mutta ei tuotantovalmiista softaa.

Tämä on se kuilu, josta vibe coding -keskustelussa puhutaan liian vähän. Työkalut ovat oikeita, nopeus on todellinen, ja ohjelmistojen demokratisoituminen on virkistävää. Mutta koodin generoimisen ja ohjelmistojen insinöörityön välillä on ero. Ja tuo ero merkitsee enemmän kuin useimmat ymmärtävät – kunnes seisoo kolmen aikaan yöllä incidentin edessä.

Se mittari, joka oikeasti merkitsee

Kun näen AI-generoitua koodia, kysyn aina saman kysymyksen: voidaanko tämä turvallisesti mergeeä shared koodipohjaan?

Ei "toimiiko se". Ei "pyöriikö demo". Turvallisesti mergeeä. Tuo sana "turvallinen" pitää sisällään paljon. Se tarkoittaa, että koodin voi peer-reviwata joku muu kuin sen kirjoittaja. Se tarkoittaa, että testit varmistavat toiminnallisuuden, eivät vain sitä, ettei koodi kaadu. Se tarkoittaa, että rollback on mahdollinen ilman datan menetystä. Se tarkoittaa, että muutos on tarpeeksi kapea ymmärrettäväksi ja selitettäväksi.

Vibe coder mittaa tyypillisesti aikaa ensimmäiseen toimivaan versioon. Se on hyödyllinen mittari prototypoinnissa ja ideoiden validoinnissa. Mutta kun softa siirtyy shared ympäristöön, tuo mittari lakkaa olemasta relevantti. Nyt puhutaan ajasta turvalliseen mergeen – mukaan lukien review-kustannukset, testien laatu, deployment-riski, koordinaatio overhead ja tuleva ylläpitotaakka.

Ohjelmistoinsinööri ajattelee koko elinkaarta alusta alkaen. Vibe coder löytää nämä huolet usein myöhemmin, kun niiden korjaaminen maksaa enemmän.

Generoitu koodi ei ole vielä sinun

Tapahtuu subtilki mutta kriittinen muutos, kun AI generoi koodisi. Tuloste ei ole vielä sinun työtäsi. Se on lähtökohta, joka pitää muuttaa joksikin, jota todella omistat.

Omistajuus tarkoittaa useita asioita. Voit selittää jokaisen merkittävän päätöksen muutoksessa. Ymmärrät, miksi jokainen tiedosto on olemassa ja mitä se tekee. Olet rajoittanut muutoksen täsmälleen siihen, mitä tarvittiin – ilman ylimääräistä boilerplatea tai epäolennaista siivousta. Olet kirjoittanut tai varmistanut testit, jotka tarkistavat käyttäytymistä, eivät vain coverage-lukuja. Olet miettinyt rollback-reitin.

Tätä työtä AI ei voi tehdä puolestasi. AI generoi. Sinä päätät. Ja "päätät" tarkoittaa, että olet ajatellut vaihtoehtoja, punninnut trade-offeja ja ymmärtänyt seuraukset.

Kun katson huonosti omistettua AI-generoitua koodia, näen usein samat ongelmat. Muutokset ovat liian laajoja, koska malli generoi tarpeettomankin. Paketteja on lisätty ilman selvää perustelua. Testit näyttävät siltä, kuin ne olisi kirjoitettu coverage-työkalun tyydyttämiseksi, eikä oikeiden bugien kiinni saamiseksi. Boilerplatea on olemassa, koska malli käyttää defaulttina scaffoldingia yksinkertaisuuden sijaan.

Mikään näistä ei ole AI:n vika. Ne ovat seurausta tekijästä, joka kohteli generoitua tulostetta edistyksenä raaka-aineen sijaan.

Review-ongelma, josta kukaan ei puhu

Jokin pitää minua hereillä öisin: AI-generoitu koodi muuttaa review-yhtälön.

Kun ihminen kirjoittaa koodia, siinä on yleensä päätösketju. Voit olla eri mieltä hänen valinnoistaan, mutta ainakin valintoja on olemassa. Voit kysyä, miksi hän käytti tuota abstraktiota, miksi validointi on siellä, miksi hän valitsi tuon kirjaston. Vastaukset voivat olla "en ajatellut sitä" tai "vaikutti järkevältä silloin", mutta ainakin on joku, jolle voi kysyä.

AI-generoidun koodin kanssa jotkut "päätökset" eivät ole päätöksiä ollenkaan. Ne ovat completioneita. Malli valitsi patternin, koska se oli tilastollisesti todennäköinen, ei koska se sopi juuri sinun ongelmaasi. Ja jos tekijä ei ole muuttanut tuota completione omistetuksi työksi, review becomes paljon vaikeampi ongelma.

Et voi kysyä mallilta, miksi se valitsi tuon lähestymistavan. Et voi kysyä tekijältä, miksi hän teki tuon päätöksen, jos hän ei oikeasti tiedä. Joten review joko löytää ongelmia kivuliaan trial and error -prosessin kautta, tai sitä ei tapahdu ollenkaan.

Tämän vuoksi uskon, että tärkein taito AI-avusteisessa kehityksessä ei ole prompting. Se on kyky ottaa generoitu output ja muuttaa se koodiksi, jonka ymmärrät tarpeeksi syvästi omistaaksesi, selittääksesi ja ylläpitääksesi.

Mitä tämä tarkoittaa tiimillesi

Jos rakennat prototyyppiä idean testaamiseen, vibe coding on täysin legitiimi lähestymistapa. Oppimisnopeus merkitsee, kun vielä validoit oletuksia. Käytä työkalut, liiku nopeasti ja rakenna jotain näytettävää.

Mutta jos prototyyppi on muuttumassa oikeaksi tuotteeksi, jossain vaiheessa generoitu koodi pitää ajaa jonkun läpi, joka ajattelee kuten insinööri. Ei portinvartijana. Ei hidastamaan. Vaan varmistamaan, että toimitukseen menee koodia, jonka tiimi voi ymmärtää, ylläpitää ja luottaa.

Näemme NameOceanilla tämän patternin jatkuvasti. Startupit, jotka liikkuvat nopeasti AI-työkaluilla ideoidensa validoimiseksi, ja sitten törmäävät seinään, kun pitää skaalautua. Hyvät tuovat insinööriapua silloin. Huonot jatkavat ominaisuuksien lisäämistä koodipohjaan, jota kukaan ei todella ymmärrä.

Tavoite ei ole välttää AI-avusteista kehitystä. Tavoite on olla rehellinen siitä, missä generointi loppuu ja missä insinöörityö alkaa. AI voi generoida koodia. Sinun täytyy insiooida software.

Lopputulos

Vibe coding on loistava lähtökohta. Se on tapa testata ideoita nopeasti, oppia mitä on mahdollista ja edetä konseptista johonkin konkreettiseen ilman kuukausien perinteistä kehitystä.

Mutta ohjelmistoinsinöörityö koskee koko elinkaarta. Se koskee koodia, jonka tiimi voi reiviwata, ylläpitää ja luottaa, kun asiat menevät pieleen kello kaksi yöllä. Se koskee muutoksia, jotka ovat tarpeeksi kapeita ymmärrettäviksi ja rollbackattaviksi tarvittaessa. Se koskee vastuun ottamista päätöksistä, vaikka nuo päätökset olisivat AI-suggestioiden informoimia.

Parhaat kehittäjät, jotka tunnen, käyttävät AI-työkaluja laajasti. He vain tekevät sen silmät avoinna. He tietävät, että generoitu koodi on raaka-ainetta, ei valmista tuotetta. Ja he tietävät, että jossain vaiheessa jonkun täytyy tehdä insinöörityö, joka tekee eron cool demon ja toimitettavan softan välillä.

Joten vibe koodaa toki. Rakenna nopeasti, kokeile vapaasti ja käytä jokaista käytettävissä olevaa työkalua. Mutta tiedä, milloin on aika siirtyä viibeestä insinöörityöhön. Tuleva itsesi ja tuleva tiimisi kiittävät.