Meidän täytyy lopettaa kaiken kutsuminen Vibe-koodaukseksi

Palasin koodaukseen pitkän tauon jälkeen, ja Lovable oli paikka, jossa otin sen jälleen käyntiin. Sovellukset näyttivät hienoilta, toimivat ensi silmäyksellä ja saatiin valmiiksi muutamassa tunnissa. Aluksi se vaikutti merkittävältä. Mutta se ei enää riittänyt hetkenä, kun halusin tietää, mitä koodi tekee – ja miksi. Siinä vaiheessa lähestymistapani alkoi muuttua.

Ero ei liity työkaluihin tai siihen, kuinka paljon koodia AI kirjoittaa puolestasi. Kyse on sopimuksesta, jonka hyväksyt tuotoksesi kanssa: pystytkö selittämään, mitä juuri julkaisit maailmaan, tai et.

Vibe-koodaus alkuperäisessä merkityksessään tarkoittaa AI:n tuottaman ohjelmiston hyväksymistä ilman, että sitä tarkastellaan tai ymmärretään kunnolla. AI-avusteinen kehitys on erilaista. Malli saattaa edelleen kirjoittaa suurimman osan koodista, mutta järjestelmää rakentava henkilö on vastuussa sen käyttäytymisen ymmärtämisestä, oletusten testaamisesta ja siitä, onko se valmis julkaistavaksi.

Kerran‑käyttöiseen kokeiluun, joka ei koskaan poistu omalta koneeltasi, ero voi olla vähämerkityksinen. Kun ohjelmisto on otettu käyttöön, sitä käyttävät muut tai se on yhteydessä todellisiin tietoihin, se on äärimmäisen merkittävää.

Miten “Vibe-koodaus” menetti merkityksensä

Termi “vibe coding” luotiin helmikuussa 2025 Andrej Karpathyn, OpenAI:n perustajajäsenen, toimesta. Hänen esimerkkinsä oli tahallaan rento: “heittokarkkiprojekti” viikonlopuksi, jonka hän rakensi automaattisesti napsauttamalla “Accept All”, sivuuttaen muutokset ja antamalla koodin kasvaa hänen ymmärryksensä ulkopuolelle.

Muutamaa viikkoa myöhemmin kehittäjä ja työkalujen tekijä Simon Willison huomasi, että termiä käytettiin hyvin eri tavalla: korvaavana sanana kaikelle AI-avusteiselle ohjelmoinnille, mistä hän väitti, että se laimentaa termiä ja antaa väärän kuvan siitä, mihin vastuullinen AI-avusteinen kehitys pystyy.

Mielenkiintoista on, että Karpathy lopulta suostui. Vuoden kuluttua hän esitteli toisen termin, joka kuvaa kurinalaisempaa työtä koodausagenttien kanssa. Hän kuvaili “agentic engineering” -prosessia työnkulkuun, jossa kehittäjät ohjaavat ja valvovat agenteja sen sijaan, että he vain hyväksyisivät niiden tuottaman. Ero on merkittävä: ammatillinen AI-avusteinen kehitys vaatii suunnittelua, tarkkuutta ja vastuullisuutta tavoilla, joita satunnainen vibe-koodaus ei tarjoa.

Raja on vastuu

Willisonin sääntö on yksinkertainen, ja se toimii testinä kaikille: älä sitouta koodia, jota et osaa selittää jollekulle muulle. Tämä ei tarkoita, että luet jokaisen rivin: kun agentit tuottavat satoja rivejä kerralla, edes kokeneet kehittäjät eivät enää tee sitä. Se tarkoittaa ydinslogiikan ymmärtämistä ja kykyä perustella, miksi koodi tekee juuri sen, mitä se tekee. Jos pystyt, ei ole merkitystä, kirjoittiko mallin sen vai sinä: se ei ole vibe-koodaus, vaan työkalun käyttö ohjelmiston rakentamiseen.

Joulukuussa 2025 julkaistu tutkimus tukee tätä eroa. Perustuen kenttähavaintoihin ja laadulliseen kyselyyn ammattilaiskehittäjiltä, tutkijat havaitsivat, että kokeneet ammattilaiset säilyttivät hallinnan ohjelmiston suunnittelussa ja toteutuksessa sen sijaan, että antaisin koko prosessin AI:lle. He kohtelivat agenteja yhteistyökumppaneina, suunnittelivat työnsä huolellisesti ja pysyivät mukana valvonnassa.

Joten pelkkä kokemus ei selitä asiaa. Kyse on siitä, oletko valmis ottamaan vastuun AI:n tuottamasta. Se on päätös, jonka jokainen kehittäjä tekee uudelleen jokaisessa projektissa.

Mitä tapahtuu, kun hallinta puuttuu

Ohjelmiston julkaisemisen seuraukset ilman sen turvallisuuden ymmärtämistä tai varmistamista eivät ole abstrakteja. Tea, sovellus, jonka tarkoitus on auttaa naisia pysymään turvassa treffailun aikana, paljasti kymmeniä tuhansia henkilötunnuskuvia ja yli miljoona yksityisviestiä kahden turvallisuusvirheen aikana. Virheet sisälsivät suojaamattoman tallennusämpärin ja erillisen tietokannan, johon pääsi ilman todennusta.

Sama perusongelma – ohjelmisto näyttää toimivan, vaikka sen valtuutuslogiikka oli vaarallisen väärin – ilmeni Lovable-alustalla rakennetussa sovelluksessa: turvallisuustutkimus havaitsi valtuutuslogiikan olevan käänteinen, estäen kirjautuneet käyttäjät mutta sallien todennettomien hyökkääjien vapaasti päästä sisään, vaikuttaen yli 18 000 käyttäjään, mukaan lukien opiskelijat.

Nämä eivät ole erillisiä tapauksia, jotka koskevat vain “huonoja” projekteja. Google:n 2025 DORA -raportin mukaan 90 % kehittäjistä käyttää nyt AI:ta työssä, vaikka noin kolmasosa raportoituu vähän tai ei lainkaan luottamusta sen tuottamaan.

AI:n käyttö on nyt laajalle levinnyt, vaikka luottamus on edelleen rajallista. Tämä tekee tarkasta tarkastuksesta erityisen tärkeää, kun generoitu koodi käsittelee todennusta, oikeuksia tai arkaluonteisia tietoja.

Hallinta rakennetaan kerroksittain, ei kerralla

Omassa tapauksessani en aloittanut muodollisella turvallisuustarkastuksella. Kieltäydyin yksinkertaisesti jatkamasta, jos en pystynyt selittämään, miksi jokin käyttäytyi niin kuin se teki – luonnollinen vaisto, jonka tuon analyytikkona työskentelemiseen. Minua kiinnostaa vähemmän syntaksi kuin se, vastaako tulos alun perin määriteltyä tarvetta. Jos ei, jatkan kaivamista.

Työskentelytapani muuttui rakenteellisemmaksi projektien vakavuuden kasvaessa. Ennen kuin luotin pelkästään kehoituksiin, aloin laatia määrittelyt ennen minkään tuottamista. Dokumentoin liiketoimintavaatimukset, teknologiakokonaisuuden ja integraatiot. Sen jälkeen tuli yksikkötestit ja Playwright-testit pääasiallisille käyttäjäpoluille.

Turvallisuustarkastuksia lisättiin samalla tavalla. Tarkastin AI:n valitsemat kirjastot ja otin käyttöön haittaohjelmien skannauksen ladatuille tiedostoille. Jokainen tarkistus syntyi kysymällä, mitä voisi mennä pieleen seuraavaksi, sen sijaan että noudattaisin alussa laatimaani tarkistuslistaa.

Tämä tapa nappasi ongelman yhdessä projektissa. AI toi kirjaston, joka oli yhteensopimaton käyttämäni kehyksen version kanssa. Sovellus ei ollut kaatunut suoraan, joten yhteensopimattomuus olisi voinut helposti jäädä huomaamatta. Jos olisi löydetty myöhemmin, syyn tunnistaminen olisi ollut paljon vaikeampaa.

Verrattuna Tea- ja Lovable-tapauksiin, tämä oli tavallinen ongelma. Löysin sen aikaisin, korjasin sen ja jatkoin eteenpäin. Tämä on se, miltä tarkastus yleensä näyttää käytännössä. Useimmiten se estää pienten ongelmien kasvamisen suuremmiksi.

En epäluota koodia pelkästään siksi, että AI on sen tuottanut. En myöskään luota siihen pelkästään siksi, että sovellus toimii. Testit ja tarkastus ovat tapani varmistaa, että se käyttäytyy suunnitellusti.

Vibe-koodauksesta agenttiseen suunnitteluun

Karpathyn oma siirtyminen “vibe coding” -termistä kohti “agentic engineering” -lähestymistapaa ei ole pelkästään sanastonmuutos. “Agentic engineering” tarjoaa käyttökelpoisemman nimen ammatillisen kehityksen suuntaukselle. Kehittäjät saattavat kirjoittaa vähemmän rivejä itse, mutta se ei vähennä heidän vastuunsa. Se siirtää heidän työnsä kohti järjestelmän tehtävien määrittelyä, agenttien ohjaamista, niiden tuotoksen testaamista ja sen päättämistä, mikä on turvallista julkaista.

Vaarana ei ole se, että AI tuottaa koodia nopeasti. Vaarana on, että generointi voi edetä nopeammin kuin ymmärrys. Kun näin tapahtuu, näennäinen tuottavuus peittää riskit, joita kukaan ei ole asianmukaisesti tarkastellut.

Sääntö, jonka kannattaa pitää

Lopeta “vibe coding” -termin käyttäminen kaikille AI-avusteisen kehityksen muodoille – se laimentaa termiä ja poistaa merkityksellisen hallinnan eron. Aseta yksinkertainen sääntö: älä julkaise sitä, mitä et pysty selittämään. Ja rakenna hallintaa projektiin sen kasvaessa kerros kerrallaan, lisäämällä tarkistuksia riskien mukana kehittyessä.

AI voi kirjoittaa suurimman osan koodista. Se ei voi ottaa vastuuta sen julkaisemisesta. Tämä vastuu on edelleen meillä.