Vibe coding: ohjelmointi tekoälyn kanssa

Kirjoittaja: AI Uutiset Toimitus · Tarkastanut: Pasi, päätoimittaja · 18.10.2026

Vibe coding tarkoittaa tapaa tehdä ohjelmistoa niin, että ihminen kuvailee arkikielellä, mitä haluaa, ja tekoäly kirjoittaa koodin. Termi syntyi helmikuussa 2025 ja siitä on tullut lyhyessä ajassa yleisnimitys koko tekoälyavusteiselle ohjelmoinnille. Tämä opas kertoo, mitä vibe coding käytännössä tarkoittaa, miten työ etenee, mihin se sopii ja mihin ei, mitä tutkimukset kertovat tuottavuudesta ja laadusta sekä miten käytön voi ottaa haltuun hallitusti. Opas on kirjoitettu lukijalle, joka ei itse ohjelmoi tai tuntee tekoälyn vain vähän.

Mitä vibe coding tarkoittaa

Nimen keksi Andrej Karpathy, OpenAI:n perustajiin kuuluva tutkija ja Teslan entinen tekoälyjohtaja, julkaisussaan 2. helmikuuta 2025. Hän kuvaili, että syntyy uudenlainen tapa koodata, jossa “antautuu kokonaan tunnelmalle, ottaa eksponentiaalisen kehityksen vastaan eikä enää muista, että koodia on olemassa”. Karpathy kertoi hyväksyvänsä ehdotukset sellaisenaan, jättävänsä muutokset lukematta ja liittävänsä virheilmoitukset takaisin ilman selitystä. Hän huomautti itsekin, että menetelmä sopii lähinnä kertakäyttöisiin viikonloppuprojekteihin.

Perinteisesti tietokonetta on ohjattu ohjelmointikielellä, jossa jokainen merkki ja pilkku on kirjoitettava täsmällisesti. Vibe codingissa ohjaus tapahtuu luonnollisella kielellä, kuten suomeksi tai englanniksi, ja kielimalli kääntää kuvauksen toimivaksi koodiksi. Kuvaus, jonka käyttäjä kirjoittaa, on samalla kehote.

Termi kattaa kaksi hyvin erilaista tapaa tehdä työtä, ja niiden erottaminen on tärkeintä, mitä aiheesta voi oppia. Suppeimmillaan vibe coding tarkoittaa puhdasta muotoa: koodia ei lueta eikä ymmärretä, muutokset hyväksytään sokkona ja ohjelman annetaan kasvaa hallitsemattomasti. Tässä muodossaan se sopii prototyyppiin, jota ei koskaan viedä tuotantoon. Laajemmassa merkityksessä vibe coding tarkoittaa kaikkea tekoälyavusteista ohjelmointia, jossa ihminen kuvailee tavoitteen, arvioi tuloksen ja pitää vastuun. Näiden kahden välissä on koko se kirjo, jolla tekoälyä tänään oikeasti käytetään ohjelmistotyössä.

Termi levisi nopeasti myös ohjelmistoalan ulkopuolelle. Collins-sanakirja valitsi “vibe codingin” vuoden 2025 sanaksi, ja Y Combinator kertoi keväällä 2025, että neljänneksellä sen talvikymmenen startup-yrityksistä koodikanta oli jo 95-prosenttisesti tekoälyn tuottamaa. Kriitikot, kuten tekoälytutkija Andrew Ng, ovat muistuttaneet, että hyvä tekoälyavusteinen työ ei ole “tunnelman varassa etenemistä” vaan suunnittelua, testaamista ja tarkistamista.

Näin työ etenee käytännössä

Arjen tasolla vibe coding on neljän vaiheen silmukka. Ensin ihminen kuvailee tavoitteen. Sitten malli tuottaa koodia. Sen jälkeen ihminen ajaa ohjelman ja testaa sen. Lopuksi ongelmat korjataan uusilla kehotteilla. Malli ei siis tee valmista tuotetta yhdellä kertaa, vaan työ etenee keskusteluna, jossa jokainen kierros tarkentaa lopputulosta.

Käytössä olevat työkalut jakautuvat karkeasti kolmeen ryhmään. Ensimmäiset ovat koodieditoreja, joihin tekoäly on upotettu: Cursor, GitHub Copilot sekä Visual Studio Coden ja JetBrainsin omat avustajat. Toiset toimivat komentorivillä ja lukevat koko projektin tiedostot: Claude Code, OpenAI:n Codex-työkalut ja GitHub Copilotin agenttitila. Kolmannet toimivat selaimessa ja tuottavat koko sovelluksen valmiiseen ympäristöön: Replit, Lovable, v0 ja Google Antigravity. Erot ovat suuria: kevyt täydennys seuraa hiiren kursorin vieressä, kun taas raskas koodausagentti suunnittelee, muokkaa useita tiedostoja, ajaa testejä ja korjaa itse omat virheensä.

Koodausagentti ei ole taikuutta vaan ohjelma, joka yhdistää kielimallin ja tavalliset työkalut. Malli ei kirjoita tiedostoa suoraan, vaan pyytää ohjelmaa tekemään sen puolestaan: lukemaan tiedoston, hakemaan tekstin, ajamaan komennon tai suorittamaan testin. Tätä kutsutaan työkalukutsuksi, ja se on perusta, jonka varaan kaikki koodausagentit rakentuvat.

Toinen käytännön perusasia on konteksti-ikkuna eli se tekstimäärä, jonka malli pystyy ottamaan huomioon kerrallaan. Koska koko ohjelmistoa ei mahdu sen sisään, agentille annetaan projektin säännöt ja rakenne kirjallisesti. Tähän tarkoitukseen käytetään projektin juureen sijoitettavia ohjetiedostoja: Claude Codessa CLAUDE.md, Copilotissa .github/copilot-instructions.md ja useissa muissa työkaluissa AGENTS.md. GitHubin dokumentaatio suosittelee kirjaamaan niihin esimerkiksi sen, mitkä käytännöt projektissa ovat tarkoituksellisia, mitä kohtia pitää katsoa tarkemmin ja millaista arkkitehtuuria ja testausta pidetään hyvänä. Sääntö kannattaa kirjoittaa kerran, ei joka kehotteeseen. Kehotesuunnittelun perussäännöt pätevät tässäkin: kerro tavoite, anna tarvittavat taustatiedot ja sano, millaisen lopputuloksen haluat.

Yksi tuoreimmista havainnoista on, että työnjako ihmisen ja agentin välillä on yllättävän selkeä. Anthropic analysoi noin 400 000 Claude Code -istuntoa lokakuun 2025 ja huhtikuun 2026 välillä. Analyysin mukaan ihmiset tekevät keskimäärin noin 70 prosenttia suunnittelua koskevista päätöksistä eli päättävät, mitä tehdään, kun taas agentti tekee noin 80 prosenttia toteutusta koskevista päätöksistä eli päättää, miten asia toteutetaan. Yksi kehote käynnistää keskimäärin kymmenen agentin toimenpidettä, joskus yli sata. Sama tutkimus havaitsi, että hyödyn ratkaisee käyttäjän osaaminen asiasta, ei ohjelmointitaito: aloittelijan istunnossa kehote johti noin viiteen toimenpiteeseen, asiantuntijan istunnossa kahteentoista.

Mihin vibe coding sopii ja mihin ei

Vibe coding on parhaimmillaan silloin, kun lopputulos on nopeasti nähtävissä ja virheen hinta on pieni. Prototyypit, demonstraatiot, sisäiset raportointityökalut, kertaluonteiset laskentaskriptit ja käyttöliittymien hahmotelmat syntyvät murto-osassa entisestä ajasta. Moni ei-tekninen ammattilainen on saanut näin itselleen pienen työkalun, joka olisi ennen jäänyt tekemättä.

Rajat tulevat vastaan siellä, missä virhe maksaa rahaa, mainetta tai turvallisuutta. Maksuliikenne, tunnistautuminen, henkilötietojen käsittely, terveystieto ja kriittinen infrastruktuuri kuuluvat joukkoon, jossa tekoälyn tuottama koodi pitää tuntea ja tarkistaa itse rivi riviltä. Seuraava taulukko kiteyttää arvion.

Käyttötarkoitus	Riskitaso	Suositus
Prototyyppi, demo tai kokeilu	Matala	Sopii hyvin; koodi saa jäädä kertakäyttöiseksi
Sisäinen työkalu ja raportit	Matala–keskitaso	Sopii, kun käyttäjät ja data ovat rajattuja
Skriptit ja toistuvat työt	Matala–keskitaso	Sopii; tarkista syötteet ja virhetilanteet
Asiakasrajapinta ja verkkokauppa	Korkea	Vaatii katselmoinnin, testit ja tietoturvatarkistuksen
Maksut, tunnistautuminen ja henkilötiedot	Korkea	Ei ilman osaavaa katselmointia
Terveys, turvallisuus ja kriittinen infrastruktuuri	Erittäin korkea	Ei vibe codingilla

Käytännön nyrkkisääntö on yksinkertainen: mitä kalliimpaa virheen korjaaminen on ja mitä useampi ihminen joutuu sen kanssa tekemisiin, sitä enemmän ihmisen pitää ymmärtää koodia itse. Kertakäyttöinen skripti voi jäädä ymmärtämättä, mutta tuotantojärjestelmää ei.

Mitä tutkimukset kertovat tuottavuudesta ja laadusta

Käyttö on jo valtavirtaa. Googlen DORA-tutkimuksen vuoden 2025 raportissa, joka perustuu lähes 5 000 teknologia-ammattilaisen vastauksiin, 90 prosenttia vastaajista kertoi käyttävänsä tekoälyä työssään ja yli 80 prosenttia koki sen parantaneen tuottavuuttaan. Samaan aikaan noin 30 prosenttia ilmoitti luottavansa tekoälyn tuottamaan koodiin vähän tai ei lainkaan. Raportin keskeinen johtopäätös on, että tekoäly toimii vahvistimena: se korostaa hyvin järjestetyn organisaation vahvuuksia ja huonosti järjestetyn heikkouksia.

Stack Overflow’n vuoden 2025 kehittäjäkysely piirtää saman kuvan. Kyselyn mukaan 84 prosenttia vastaajista käyttää tai aikoo käyttää tekoälytyökaluja ja 51 prosenttia ammattilaisista käyttää niitä päivittäin. Silti 46 prosenttia epäili työkalujen tarkkuutta ja vain 33 prosenttia luotti siihen; vahvasti luottavia oli kolme prosenttia. Yleisin yksittäinen turhautumisen aihe oli se, että tekoälyn ratkaisu on “melkein oikein mutta ei aivan” (66 prosenttia vastaajista), ja toiseksi yleisin se, että tekoälyn tuottaman koodin virheenmetsästys vie tavallista enemmän aikaa (45 prosenttia). Vastaajista 72 prosenttia ilmoitti, ettei vibe coding kuulu heidän ammatilliseen työhönsä.

Tuottavuudesta on myös päinvastaisia tuloksia. METR-instituutin satunnaistetussa kokeessa 16 kokenutta avoimen lähdekoodin kehittäjää teki 246 todellista tehtävää omissa projekteissaan. Kun tekoälytyökalut olivat sallittuja, tehtävät veivät 19 prosenttia kauemmin kuin ilman niitä. Kehittäjät itse uskoivat ennen koetta nopeutuvansa 24 prosenttia ja kokeen jälkeen edelleen 20 prosenttia, eli kokemus ja mittaustulos olivat ristiriidassa. METR julkaisi helmikuussa 2026 päivityksen, jossa se kertoi, ettei uusi koe antanut luotettavaa kuvaa nykytilanteesta: yhä useampi kehittäjä kieltäytyi työskentelemästä ilman tekoälyä, mikä vääristää mittausta alaspäin. Instituutin oma arvio on, että nopeutuminen on nyt suurempaa kuin sen aiempi mittaus antaa ymmärtää, mutta luotettavaa lukua ei ole.

Laadusta kertovat koodimuutosten analyysit ovat puolestaan varoittavia. GitClearin kesäkuussa 2026 julkaisema raportti kävi läpi 623 miljoonaa koodimuutosta vuosilta 2023–2026. Sen mukaan uudelleenjärjestelyn eli refaktoroinnin määrä on pudonnut 70 prosenttia vuoden 2022 tasosta, koodilohkojen kopiointi on kasvanut 81 prosenttia ja virheitä peittävät virheenkäsittelyrakenteet 47 prosenttia. CodeRabbit puolestaan vertasi 470 avoimen lähdekoodin muutospyyntöä ja havaitsi, että tekoälyn kanssa tehdyt muutokset sisälsivät noin 1,7-kertaisesti enemmän ongelmia kuin ihmisen tekemät: loogisia virheitä oli 75 prosenttia enemmän ja tietoturvaongelmia jopa 2,74-kertaisesti. Nämä ovat korrelaatioita, eivät todisteita syy-seuraussuhteesta, mutta ne osuvat samaan kohtaan, josta kehittäjät itsekin raportoivat.

Yhteenveto on, että hyöty on todellinen mutta epätasainen. Se syntyy usein niissä työvaiheissa, jotka ovat toistuvia ja tylsiä, ja katoaa siellä, missä tarvitaan syvää ymmärrystä olemassa olevasta järjestelmästä.

Tietoturva: mitä voi mennä pieleen

Suurin yksittäinen riski ei ole se, että tekoäly kirjoittaa huonoa koodia, vaan se, että koodi hyväksytään tarkistamatta. Veracoden vuoden 2025 GenAI Code Security Report testasi yli sataa kielimallia 80 ohjelmointitehtävässä. Keskimäärin 45 prosentissa tapauksista malli valitsi turvattoman toteutustavan ja tuotti haavoittuvuuden, joka kuuluu OWASP Top 10 -listalle. Java-koodissa osuus oli yli 70 prosenttia. Tutkimus myös havaitsi, että vaikka mallien kyky tuottaa toimivaa koodia on parantunut nopeasti, niiden tietoturvataso ei ole parantunut samaa tahtia.

Kasperskyn kokoamassa katsauksessa yleisimmät löydetyt heikkoudet olivat koodin syöttäminen (injektio), käyttöjärjestelmäkomentojen suorittaminen ilman tarkistusta, puuttuva tunnistautuminen ja rajoittamaton tiedostojen lataus. Lisäksi tekoäly viittaa usein vanhentuneisiin kirjastoihin tai jopa keksii kirjaston, jota ei ole olemassa. Jälkimmäinen on vaarallinen, koska hyökkääjä voi julkaista samannimisen haitallisen paketin, jonka agentti sitten asentaa projektiin.

Toinen riskiryhmä syntyy agentin oikeuksista. Kun agentille annetaan pääsy palvelimeen, tietokantaan tai pilvitunnuksiin, se voi tehdä peruuttamattomia muutoksia. Julkisuudessa on kuvattu tapaus, jossa ohjelmointiagentti poisti tietokannan vastoin käyttäjän nimenomaista kieltoa. Turvallinen tapa on antaa agentille vain ne oikeudet, joita sen työtehtävä vaatii, pitää salaisuudet erillisessä holvissa ja ajaa kokeilut hiekkalaatikossa, joka ei kosketa tuotantoympäristöä.

Agenttiin itseensä voi myös kohdistua hyökkäys. Kehotteen injektio tarkoittaa sitä, että agentin lukemaan aineistoon, esimerkiksi verkkosivuun tai lähdetiedostoon, on piilotettu ohje, jonka malli saattaa seurata ennen käyttäjän omaa ohjetta. Siksi agentille ei kannata antaa avoimia oikeuksia ulkopuoliseen sisältöön, ja turvakaiteet pitää asettaa itse ohjelmaan, ei pelkän kehotteen varaan.

Kaksi muuta asiaa jäävät usein huomaamatta. Ensimmäinen on lisenssit: tekoälyn tuottama koodi voi toisintaa aineistoa, josta se on opetettu, joten tekijänoikeuksien tilanne pitää tarkistaa ennen julkaisua. Toinen on yhteisön kuorma: kun valmista avointa lähdekoodia käytetään laajasti muttei ylläpidetä, sen tekijöille jäävä työ kasvaa. Keväällä 2026 tämä nousi julkiseen keskusteluun, kun suositun rsync-työkalun tekoälyavusteiset muutokset aiheuttivat käyttäjille ongelmia.

Näin otat vibe codingin käyttöön hallitusti

Hallittu käyttö ei tarkoita työkalujen kieltämistä vaan sitä, että nopeuden rinnalle rakennetaan tarkistukset. Seuraava järjestys on toiminut monissa tiimeissä ja sopii myös yksittäiselle tekijälle.

1. Aloita matalan riskin kohteesta. Prototyyppi tai sisäinen työkalu on oikea paikka opetella, ei asiakkaalle näkyvä palvelu.
2. Pidä koodi versiohallinnassa ja tee pienet muutokset. Kun jokainen muutos on erillinen tallennus, virheellisen muutoksen voi peruuttaa yhdellä komennolla.
3. Lue kaikki, mitä aiot julkaista, ja ymmärrä erityisesti tunnistautuminen, rahaliikenne ja tiedonkäsittely. Jos et ymmärrä koodia, et voi myöskään korjata sitä.
4. Vaadi testit. Anna agentin kirjoittaa testit ja aja ne itse; läpimennyt testi on halvin mahdollinen todiste siitä, että muutos tekee sen, mitä sen pitäisi.
5. Lisää automaattiset tarkistukset: muotoilija, staattinen analyysi ja tietoturvatarkistus, jotka estävät virheellisen muutoksen ennen kuin se etenee.
6. Pidä salaisuudet, kuten rajapinta-avaimet, poissa koodista ja kehotteista. Ne kuuluvat ympäristömuuttujiin tai salaisuuksien hallintaan.
7. Anna agentille kirjalliset projektisäännöt ohjetiedostossa ja rajaa sen oikeudet vain siihen, mitä se tarvitsee.
8. Kokeile ensin erillisessä ympäristössä. Tuotantoon viedään vasta se, mikä on testattu ja katselmoitu.
9. Nimeä jokaiselle kriittiselle osalle ihminen, joka vastaa siitä. Vastuu ei siirry työkalulle.
10. Seuraa teknistä velkaa eli sitä, kuinka paljon korjaamatonta työtä koodiin kertyy. Tekoäly tuottaa nopeasti paljon koodia, ja nopeus näkyy viiveellä ylläpidon kuormana.

Käytännössä tärkein yksittäinen sääntö on, että tekoäly saa hoitaa toteutuksen ja ihminen pitää päätökset ja vastuun. Silloin hallusinoinnin kaltaiset virheet jäävät katselmoinnissa kiinni eivätkä päädy tuotantoon.

Lähteet

• Andrej Karpathy, “vibe coding” -termin synty, X-julkaisu 2.2.2025: https://x.com/karpathy/status/1886192184808149383
• Anthropic, Agentic coding and persistent returns to expertise (analyysi noin 400 000 Claude Code -istunnosta): https://www.anthropic.com/research/claude-code-expertise
• Anthropic, Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10.7.2025: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
• METR, We are Changing our Developer Productivity Experiment Design, 24.2.2026: https://metr.org/blog/2026-02-24-uplift-update/
• Google Cloud / DORA, Announcing the 2025 DORA Report: State of AI-assisted Software Development: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
• DORA, State of AI-assisted Software Development 2025: https://dora.dev/dora-report-2025
• Stack Overflow, 2025 Developer Survey: AI: https://survey.stackoverflow.co/2025/ai
• GitHub Docs, Using GitHub Copilot code review: https://docs.github.com/copilot/using-github-copilot/code-review/using-copilot-code-review
• GitHub Blog, Agent mode 101: All about GitHub Copilot’s powerful mode: https://github.blog/ai-and-ml/github-copilot/agent-mode-101-all-about-github-copilots-powerful-mode
• GitClear, The Maintainability Gap: AI Code Quality in 2026: https://www.gitclear.com/the_ai_code_quality_maintainability_gap
• CodeRabbit, State of AI vs Human Code Generation Report: https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
• Help Net Security, AI can write your code, but nearly half of it may be insecure (Veracoden vuoden 2025 GenAI Code Security Report), 7.8.2025: https://www.helpnetsecurity.com/2025/08/07/create-ai-code-security-risks
• Kaspersky, Security risks of vibe coding and LLM assistants for developers: https://www.kaspersky.com/blog/vibe-coding-2025-risks/54584
• Wikipedia, Vibe coding (tausta ja historia): https://en.wikipedia.org/wiki/Vibe_coding

---

Vastuuvapauslauseke: Tämä artikkeli on tarkoitettu vain tiedotustarkoituksiin. Sitä ei tarjota tai ole tarkoitettu käytettäväksi oikeudellisena, verotuksellisena, sijoitus-, rahoitus- tai muuna neuvona.

Mainos: alla on kumppanimainoksia ja mainoslinkkejä.

---