Vibe coding tuotannossa: mitä Runditin tiimi oppi rakentaessaan tekoälyllä
Ohjelmiston rakentaminen tekoälyllä näyttää petollisen helpolta. Kuvailet mitä haluat, ja muutamassa minuutissa edessäsi on jotain, joka muistuttaa valmista tuotetta: viimeistelty käyttöliittymä, toimivat painikkeet, suodattimet ja näkymät. Tätä Andrej Karpathy kutsui vibe codingiksi lanseeratessaan termin helmikuussa 2025: rakentamista kuvailemalla, mitä haluaa, sen sijaan että kirjoittaisi koodia.
Goran Bjelajacille, Runditin Product Leadille, tuo nopeus oli lähtökohta kuukausia kestäneelle kokeilulle tekoälytyökalu Lovablen kanssa. Samalla se oli oppitunti siitä, mitä nopeus todellisuudessa maksaa.
Rundit on sijoitusrahastojen salkunhallinta- ja raportointialusta, osa Greenstepin Fund Business -tiimiä. Sitä käyttävät rahastonhoitajat yli 35 maassa salkkudatan ja sijoittajaraportoinnin hallintaan.
Miksi tekoälyn tuottama ohjelmisto näyttää valmiilta ennen kuin se toimii?
Tekoäly on hyvä tuottamaan ohjelmistoa, joka näyttää valmiilta. Käyttöliittymä on viimeistelty, tietokanta on paikallaan ja työnkulut on kytketty toisiinsa. Ongelmat ovat muualla: ominaisuus toimii yhdessä tilanteessa mutta ei toisessa, data ei tallennu oikein, ja yksi toiminto rikkoo toisen.
”Tiimimme käytti valtavasti aikaa testaamiseen. Sanoisin, että noin 80 prosenttia työstä oli testaamista”, Goran kertoo.
Havainto ei ole yksittäistapaus. METRin vuonna 2025 toteuttamassa satunnaistetussa vertailukokeessa tekoälyavusteiset koodaustyökalut hidastivat kokeneita kehittäjiä 19 prosentilla, kun koodikatselmointiin ja korjaamiseen kulunut aika laskettiin mukaan. Kehittäjät itse odottivat päinvastaista, samoin alan asiantuntijat.
Logiikka on suoraviivainen. Kun ominaisuuksia syntyy nopeasti, myös virheitä syntyy nopeasti. Rakentamisesta tulee halpaa, varmistamisesta kallista.
Tekoäly ymmärtää logiikan. Tuotetta se ei aina ymmärrä.
Selkein esimerkki tuli cap tablesta. Goran halusi, että osakeantien tekeminen ja omistajatietojen muokkaus tapahtuvat cap tablen sisällä. Lovable ehdotti toisin: koska cap table on taulukko, hallintatoiminnot kuuluvat sen mukaan erilliseen näkymään.
”Teknisesti tuo päättely ei ole täysin järjetön. Tuotteen näkökulmasta se oli väärin”, Goran sanoo.
Kukaan cap tablea käyttävä ei ajattele, että taulukko ja siihen kohdistuvat toiminnot kuuluisivat eri paikkoihin. Sama kaava toistui muuallakin: optio-ohjelmista puuttui mahdollisuus optioiden käyttöön, lainoista puuttui alaskirjaus, ja vaihtovelkakirjalainat oli mahdollista muuntaa vain kokonaan.
”Tekoäly tunnistaa erittäin hyvin yleisiä ohjelmistomalleja, mutta se ei automaattisesti ymmärrä kontekstia, jossa ne ovat järkeviä”, Goran sanoo.
Rahastoraportoinnissa ero on olennainen. Data ei ole vain näytettävää, vaan sen pohjalta tehdään päätöksiä ja laaditaan raportteja sijoittajille.
Ylimääräisen rakentamisen piilokustannus
Tekoäly ei rajoitu siihen, mitä siltä pyydetään.
”Tekoäly antaa mielellään kymmenen ylimääräistä ominaisuutta, joita et pyytänyt. Osa on hyödyllisiä. Osa on täysin turhia. Osa luo uusia ongelmia”, Goran sanoo.
Jokainen ominaisuus, joka päätyy tuotantoon, pitää testata, ylläpitää ja ymmärtää, käyttää sitä kukaan tai ei.
Näkyvissä on myös vähemmän ilmeinen kustannus. Jokainen julkaistu ominaisuus jää pyörimään ja kuluttamaan laskentatehoa riippumatta siitä, käyttääkö sitä kukaan. Kansainvälisen energiajärjestön IEA:n mukaan datakeskusten sähkönkulutus on kasvanut noin 12 prosenttia vuodessa vuodesta 2017, yli nelinkertaisella vauhdilla sähkön kokonaiskysyntään verrattuna. Kasvu kiihtyy: IEA arvioi vuoden 2025 kasvuksi 17 prosenttia, kun sähkön kokonaiskysyntä kasvoi 3 prosenttia, ja tekoälyyn keskittyvän kapasiteetin odotetaan kolminkertaistuvan vuoteen 2030 mennessä.
Tuotetiimille tämä antaa vanhalle vaistolle uuden perustelun: turhat ominaisuudet eivät ole vain ylläpitotaakka, vaan jatkuva resurssikustannus.
”Jos tekoäly rakentaa jotain, mitä en pyytänyt, minun ei välttämättä tarvitse testata sitä. Voin vain poistaa sen. Se on usein paljon halvempaa”, Goran sanoo.
Kohti avoimempaa alustaa
Nopeamman rakentamisen sijaan Rundit siirtyi toiseen suuntaan: pienempiin, itsenäisiin moduuleihin, joita voi testata ja vaihtaa ilman että koko alusta pitää rakentaa uudelleen.
Samalla se avaa alustaa asiakkaille. Runditin MCP-palvelimen kautta asiakkaat voivat rakentaa omia työnkulkujaan omilla tekoälytyökaluillaan sen sijaan, että jokainen tarve kulkisi Runditin tuotekehityksen kautta. MCP eli Model Context Protocol on avoin standardi, jonka avulla tekoälyavustajat pääsevät käsiksi ulkoisiin järjestelmiin.
”Vanha lähestymistapa oli käytännössä: kerro mitä tarvitset, niin me rakennamme sen. Uusi voi yhä useammin olla: tässä ovat rakennuspalikat, rakenna mitä tarvitset”, Goran sanoo.
Sen tietäminen, mitä ei kannata rakentaa
Tekoäly on tehnyt ohjelmiston rakentamisesta selvästi halvempaa, ja se on todellinen etu. Samalla se on poistanut rajoitteen, joka piti tuotteet kurissa: kehitysajan. Kun jonkin rakentaminen vei kolme päivää, tiimit miettivät kahdesti, tarvitaanko sitä. Kun tekoäly rakentaa saman kymmenessä minuutissa, kysymys katoaa, ja joku joutuu tuomaan sen takaisin tietoisesti.
”Pullonkaula siirtyy kysymyksestä ’voimmeko rakentaa tämän’ kysymykseen ’kannattaako tämä rakentaa’. Ja sen jälkeen: toimiiko se oikeasti”, Goran sanoo.
Mitä tämä tarkoittaa rahastoille, jotka luottavat tekoälyllä rakennettuun ohjelmistoon?
Kuri ei ole valinnaista alustalla, joka käsittelee rahastoraportointia ja salkkudataa. Raportit lähtevät aikataulussa, sijoittajat lukevat ne, eikä neljännesvuoden sulkemisen kolmannella viikolla ilmenevä virhe ole pelkkä bugitiketti. Se on luottamuskysymys.
Kokeilun onnistumisen ratkaisi työkalun sijaan tiimi. Kehittäjät olivat riittävän kokeneita tunnistamaan, milloin lopputulos oli väärä, poistamaan tarpeettoman ja testaamaan loput kunnes ne kestivät. Tekoäly kirjoitti koodin nopeasti. Tiimi päätti, mikä ansaitsi päätyä tuotantoon.
Sama erottelu pätee rahastonhoitajiin, jotka käyttävät tekoälyä omassa työssään. Luonnosteluun ja rutiinianalyysiin se on paikallaan. Mutta järjestelmiä, jotka pitävät sisällään salkkudatan ja tuottavat sijoittajaraportoinnin, koskee eri vaatimustaso, koska niiden tuotoksia lukevat rahaston ulkopuoliset ja tekevät niiden pohjalta päätöksiä. Siinä kerroksessa harkinnan pitää olla rakennettu työkaluun, ei lisätty jälkikäteen.
Nopeus on helppo näyttää toteen. Luotettavuus näkyy vasta sinä neljänneksenä, jona sitä tarvitsi.
