Vibe coding: uhka vai mahdollisuus?

Miksi vibe coding tarkoittaa eri ihmisille eri asioita?

Vibe coding tarkoittaa alkuperäisessä merkityksessään hyvin rajattua toimintatapaa: lähdekoodia ei lueta. Termin nimennyt Andrej Karpathy kuvasi työskentelytapaa, jossa muutokset hyväksytään ilman diffien tarkastamista ja virheitä korjataan yrityksen ja erehdyksen kautta. Hän rajasi ilmiön itse matalan panoksen työhön.¹ Simon Willison on muotoillut käsitteen tarkemmin: ohjelmiston rakentaminen kielimallilla ilman tuotetun koodin katselmointia.² Huomaa, että jos ohjelmistokehityksen ammattilainen lukee koodin, testaa sen ja vastaa lopputuloksesta, kyse ei ole vibe codingista, vaikka kielimalli olisi tuottanut jokaisen rivin.²

Arkikielessä termi on kuitenkin laajentunut kattamaan lähes kaiken tekoälyavusteisen ohjelmistokehityksen. Collins valitsi termin vuoden 2025 sanaksi, ja markkinassa sitä käytetään usein kuvaamaan tekoälyn avulla tehtävää kehitystyötä tekijästä tai työskentelytavasta riippumatta.³

Päättäjän näkökulmasta tästä syntyy kaksi erilaista väärinymmärrysmahdollisuutta: 1. ammattimainen tekoälyavusteinen kehitys voidaan nähdä pelkkänä kertakäyttöisenä kokeiluna, tai 2. katselmoimaton tekoälyn tuottama lähdekoodi voidaan hyväksyä virheellisesti tuotantovalmiina.

Katselmointi ratkaisee, ei tekijä eikä työkalu

Sekaannus syntyy siitä, että puhekielessä ”vibe coding” käsitteen taakse niputetaan kolme toisistaan riippumatonta asiaa: työn tekevä henkilö, tekoälyagenttien itsenäisyyden taso ja lopputuotoksen katselmointitaso. Vibe coding ei kuitenkaan liity tekijään tai agentin autonomiatasoon. Se on katselmointiakselin vedenjakaja: se kohta, jossa lähdekoodia ei lueta.

Tästä syystä vibe coding ohjelmointitapana voi pitää sisällään joko hyvin vähän riskejä tai erittäin suuria riskejä. Myöskään agenttisen koodauksen suurempi autonomia ei ole automaattisesti parempi.⁴ Koko jäsennys neljine tekijätyyppeineen on sanastotermissä tekoälyavusteinen ohjelmistokehitys. Tämän kirjoituksen kannalta riittää yksi johtopäätös: riskin ratkaisee katselmointi suhteessa siihen, mihin tuotosta käytetään.

Missä kohtaa katselmoimaton koodi muuttuu riskiksi?

Katselmoimaton koodi muuttuu riskiksi heti, kun siirrytään ulos kokeilusta. Alla oleva ”Tekoälyn katselmointivaje” kiteyttää asian yksinkertaistettuun kuvaan. Kuvan vaaka-akselilla on tuotoksen käyttötarkoitus jaettuna kolmeen alueeseen: kokeilu, rajattu käyttö ja tuotantokäyttö. Pystyakselilla on katselmoinnin kattavuus jaettuna kolmeen tasoon: ei katselmointia, pistotarkistukset sekä täysi katselmointi testauksineen ja hyväksymiskriteereineen. Kuva on tarkoituksella pelkistetty, jotta ydinviesti välittyy selkeästi.

Kuvio antaa ylätasolla vastauksen kysymykseen siitä, millä katselmoinnin tasolla mikäkin käyttötarkoitus on mahdollinen. Ylin rivi vastaa perinteistä kokeneen ohjelmistoammattilaisen tekemää työtä, jossa lähdekoodia luetaan, testataan ja hyväksytään ennalta sovittujen kriteerien mukaan. Mallissa riski pysyy hallinnassa kokeiluista tuotantoon asti.

Keskirivillä kaikkea lähdekoodia ei lueta, vaan tarkistukset painottuvat tiettyihin alueisiin, pistokokeisiin tai vastaaviin. Malli voi olla täysin riittävä esimerkiksi kokeiluun tai rajattuun käyttöön, mutta tuotannossa riskitaso kasvaisi merkittävästi.

Alimmalla rivillä on vibe coding. Siinä riski on vähäinen vain prototypointityyppisessä kokeilussa riippumatta siitä, onko tekijä ummikko tai ammattilainen. Vibe coding -tuotoksen siirtäminen edes rajattuun käyttöön nostaa riskitasoa merkittävästi.

Katselmointivajeen raja on merkattu katkoviivalla: sen oikealla puolella katselmointi jää aina jälkeen siitä, mitä käyttötarkoitus todellisuudessa edellyttäisi.

Vibe coding ei siis ole yksikäsitteisesti huono tapa tuottaa ohjelmistoa, mutta se on käyttökelpoinen vain kuvion yhdessä sarakkeessa, mikäli riskitasot halutaan pitää hallinnassa.

Tekoälyn katselmointivaje on kirjoittajan oma sovellus vakiintuneesta periaatteesta, jonka mukaan tarkastuksen syvyys suhteutetaan kohteen kriittisyyteen. Ajatus on tuttu turvallisuuskriittisessä suunnittelussa: ilmailun DO-178C porrastaa vaadittujen tavoitteiden määrän järjestelmän vaativuustason mukaan, ja IEC 61508 sekä ISO 26262 luokittelevat menetelmiä riskitason perusteella suositelluiksi tai vahvasti suositelluiksi.⁵

Tavallisessa ohjelmistokehityksessä sama periaate näkyy katselmointikäytännöissä ja automaattisissa tarkastusprosesseissa, joissa perusteellisin arviointi kohdistetaan riskialtteimpiin muutoksiin. Yhtenäistä nimeä tälle käytännölle ei kuitenkaan ole.^{6, 7} Tekoälyn katselmointivaje soveltaa tätä ajatusta tekoälyavusteiseen kehitykseen: se yhdistää tarkastuksen määrän tuotoksen käyttökohteeseen, ei pelkästään koodin tekniseen kriittisyyteen, ja tekee näkyväksi tilanteet, joissa katselmointi ei vastaa tuotoksen riskiä.

Vibe coding voi hyvinkin olla oikea valinta silloin, kun tuotos pysyy kokeilusarakkeessa: prototyyppi, jolla testataan idean toimivuutta, oma kertakäyttöinen apuskripti tai demo, jonka jälkeen koodi joutaa pois. Näissä nopeus ja asian konkretisointi on arvokkaampaa kuin koodin laatu. Ehtona luonnollisesti on, että tuotos ei valu laajempaan tai pitkäaikaisempaan käyttöön.

Miksi kokeilu muuttuu huomaamatta tuotannoksi?

Katselmointivaje syntyy harvoin päätöksellä. Tavallisempaa on, että vibe codingilla tehty kokeilu otetaan ensin muutaman ihmisen käyttöön, huomataan käyttökelpoiseksi ja lopuksi se hiipii osaksi tiimin arkea ilman, että kukaan olisi tehnyt tuotantoonvientipäätöstä.

Siirtymä voi olla vaikea huomata, jos ei ole ohjelmistokehityksen ammattilainen. Nimittäin sovelluksissa on useimmiten kaksi puolta: näkyvä käyttöliittymä ja konepellin alle jäävä tietoturva, ohjelmistoarkkitehtuuri ja muu vastaava.

Ensin mainittu näkyy heti ensimmäisessä demossa: miten sovellus toimii. Jälkimmäinen paljastuu vasta kuormituksessa, ylläpidossa tai tietoturvakatselmuksessa tai käytön laajentuessa.

Valmiilta näyttäminen ei kerro tuotantokelpoisuudesta. Stanfordin tutkijoiden vertaisarvioidussa kokeessa tekoälyavustajaa käyttäneet kirjoittivat turvattomampaa koodia kuin ilman avustajaa työskennelleet, ja he uskoivat useammin kirjoittaneensa turvallista koodia.⁸ Luottamus tuotokseen kasvoi juuri siellä, missä olisi ollut syytä olla vähemmän luottavainen.

Voiko ammattilainenkin vibe codata?

Totta kai, ja joskus se voi olla jopa järkevin valinta (vrt. halutaan nopeasti näkyvä kertakäyttöproto). Ero on siinä, että ammattilainen osaa valita riittävän katselmointitason, kun taas ohjelmointia osaamaton ei.

Pieni varoitus on kuitenkin paikallaan. Willison kirjoitti toukokuussa 2026, että agenttien luotettavuuden kasvaessa hän on alkanut jättää osan tuotantokoodistakin katselmoimatta rivi riviltä ja että raja vibe codingin ja ammattimaisen agenttityön välillä hämärtyy tavalla, josta hän ei pidä.⁹

Huomio on inhimillinen ja tämä korostaa, että vastuu lopputuloksesta säilyy ihmisellä riippumatta siitä, luetaanko koodi vai ei. Samalla se osoittaa että ammattimainen ohjelmistokehitys muuttuu nopeasti katselmointiakselin yläosassa teknologian kehittyessä.

Mitä tämä tarkoittaa ohjelmistokehitystä ostavalle?

Kun ostat ohjelmistokehitystä, kysymys ”käytättekö tekoälyä?” ei kerro riskistä juuri mitään.

Ostajan kannalta ratkaiseva kysymys ei ole ensisijaisesti se, käytetäänkö tekoälyä, vaan se, kuinka ammattimainen prosessi on rakennettu tuotettavan koodin ympärille.

Ostajan kannattaakin selvittää mm. miten tekoälyn tuottamaa koodia katselmoidaan, kuka vastaa lopputuloksesta, ja miten tekoälyn käyttö on nivottu ohjelmistokehitysprosessiin.