Tämä journalistista vibekoodauskerhoa mainostava kuva on otettu helmikuussa City University of New Yorkin Craig Newmark Graduate School of Journalismin tiloissa.

Vibekoodaus tai fiiliskoodaus tarkoittaa ohjelmointia ilman syvää teknistä ymmärrystä – mennään ”fiiliksen mukaan” siten, että esimerkiksi sovellusta rakennetaan kuvailemalla haluttuja toimintoja luonnollisella kielellä. Kyse ei kuitenkaan ole vain teknisestä ilmiöstä, vaan voidaan ajatella, että esimerkiksi uutismedioissa se avaa mahdollisuuksia laajempaan työtapojen ja työkulttuurin muutokseen. Koetan tässä kirjoituksessa avata, miten.

Tapoja fiiliskoodaukseen on monia, niin kuin on palveluitakin. Tunnetuimmasta päästä suuren yleisön silmissä lienee ruotsalainen kasvuraketti Lovable. Sillä voit halutessasi pyöräyttää vaikkapa arkipyhävapaalaskurin ja jakaa sen kaverille:

Luonnollisella kielellä tähän tapaan toimivia työkaluja ovat myös esimerkiksi ChatGPT Codex, Cursor, Claude Code tai Replit. Itse käytän eniten Codexia sekä Googlen Antigravityä, jolle annetaan hallitusti pääsy koneesi tiedostoihin, jolloin ohjelmia voi rakentaa helposti myös lokaalisti eli omalle koneelle sen sijaan että ne sijaitsevat pilvessä kuten Lovablen tapauksessa. Lokaaliuden etuna on esimerkiksi se, että omalle koneelle ladatun avoimen lähdekoodin kielimallin käyttö ei maksa mitään. Tällä logiikalla voi rakentaa vaikkapa Youtube-videoiden litteroijan, joka toimii näin:

• Syötä linkki esim. Youtube-videoon tai podcastiin.
• Sisältö latautuu omalle koneelle automaattisesti yleensä audiona.
• Ääni muuttuu transkriptioksi ja latautuu txt-tiedostona omaan kansioonsa.
• Kielimalli antaa käyttäjän kysymyksiin vastauksia transkription pohjalta.

Runko on tehty Python-ohjelmointikielellä, lataus hoituu yt-dlp:llä (avoimen lähdekoodin komentorivityökalu), litterointi OpenAI:n puheentunnistusmalli Whisperillä ja kielimallin käyttö avoimen lähdekoodin ohjelmiston Ollaman kautta. Käyttöliittymä on selaimessa.

Tämä sanottua, on hyvä tiedostaa, että tällaisissa on aina vaarana ns. demoefekti: wau, vaikuttaapa näppärältä, tuotannollistetaan tämä. Siinä on sitten kuitenkin aina edessä mm. panos–tuotos-arvio. Joka sisältää esimerkiksi sen, paljonko työkalun käyttö ja ylläpito maksaisi ihan oikeasti. Tässä piileekin ”vibekoodaussuuntauksen” suurin pullonkaula organisaatioissa: syntyy valtava määrä ideoita ja prototyyppejä – joista osa varmasti erittäin hyviä – joiden putki tuotantoon on kuitenkin joko erittäin hidas tai kokonaan tukossa. Yksi oppi tässä on minusta se, että varo hurmaantumasta liian hienoista demoesityksistä. Demo on ihan eri asia kuin tuotantoon viety versio.

Omalta osaltani haluan korostaa, että en osaa koodata, enkä ole koskaan pitänyt itseäni erityisen teknisenä ihmisenä. Jos minäkin pystyn tähän, pystyt sinäkin! Siinä sivussa opit koodista itse asiassa aika paljon, vaikka et koodaamaan varsinaisesti opikaan.

Jos aloitat aivan nollasta, suosittelen menemään osoitteeseen lovable.dev, kirjautumaan sinne Googlen tunnuksilla (pari klikkausta), jolloin käytössäsi on pieni määrä krediittejä, joilla voit kokeilla tehdä asioita ilmaiseksi.

Mahdollisuudet: nopeus, ketteryys ja uudenlaiset tavat tehdä töitä

Vibekoodaus madaltaa siis kynnystä rakentaa omia työkaluja. Kun idean ja prototyypin väliin ei tarvita raskasta kehitysprosessia, toimittaja voi esimerkiksi:

• Tehdä datan puhdistus- ja analyysityökaluja omaan käyttöönsä
• Automatisoida rutiineja (litterointi, tiedonhaku, aineiston luokittelu)

Kun kaikki ei ole enää riippuvaista keskitetystä kehitystiimistä tai keskitetystä budjetista, se voi tehdä toimituksesta ketterämmän.

Uhat: demoefekti, tekninen velka ja hallitsematon työkaluräjähdys

Demoefekti on mielestäni suurimpia uhkia, kuten aiemmin jo lyhyesti kuvasin. Prototyyppi näyttää toimivalta, mutta:

• Kuka ylläpitää sitä?
• Kuka vastaa tietoturvasta?
• Mitä tapahtuu, kun API-hinnat (API = rajapinta) muuttuvat?
• Entä jos palvelu katoaa?

Toimituksissa voi syntyä kymmeniä pieniä työkaluja, joilla ei ole omistajaa eli tahoa, joka oikeasti katsoisi työkalun perään. Tämä on omiaan synnyttämään teknistä velkaa.

Koska vibekoodaus tuntuu “ilmaiselta”, kustannuksia ei aina nähdä: kun volyymi kasvaa, kasvavat myös kulut. Jos toimitus rakentaa työkaluja vibekoodaamalla, pullonkauloiksi voivat myös muodostua ainakin seuraavat asiat:

• Ymmärtääkö tekijä, miten malli tekee päätelmiä?
• Miten varmistetaan datan käsittelyn eettisyys?
• Dokumentoidaanko työkalun toimintalogiikka?

Erityisen herkkä kysymys on lähdesuoja. Jos toimittaja syöttää arkaluonteista materiaalia pilvipalveluun, se on erityisen iso riski.

• Minne data tallentuu?
• Käytetäänkö sitä mallien koulutukseen?
• Täyttääkö ratkaisu organisaation tietoturvavaatimukset?

Lokaalit eli omalla koneella toimivat ratkaisut voivat olla turvallisempia, mutta nekin vaativat ymmärrystä riskeistä.

Parhaimmillaan vibekoodaus voi siis demokratisoida kehittämistä, nopeuttaa innovointia ja tehdä ainakin osasta toimittajia nykyistä enemmän palveluiden rakentajia. Toisaalta vibekoodaus voi johtaa hallitsemattomaan työkalujen sillisalaattiin, josta ei ole kokonaiskäsitystä kenelläkään. Tämän myötä vastuut hämärtyvät ja voi myös syntyä kitkaa sisältöpuolen ja kehityspuolen välille. Yksi ydinkysymys on, mikä on se prosessi, jolla parhaat ideat suppiloidaan tuotantoon. Jos tämä ei toimi, syntyy helposti tyytymättömyyttä.

Haluaisin itse ajatella jotenkin niin, että ajatuksena ei todellakaan ole, että kaikista tulee koodareita, vaan siitä, että jonkintasoisesta ohjelmoinnista tulee yksi uusi taito kirjoittamisen rinnalle. Yksi konkreettinen käyttötapa on ihan vain sekin, että teet ajattelemastasi konseptista prototyypin, jonka näytät sitten haluamillesi sidosryhmille. Näin nämä saavat hyvän käsityksen siitä, mitä ajat takaa.

Lähteitä, joita olen hyödyntänyt tässä kirjoituksessa:

Vibe coding for newsroom projects (Innovation.dw 15.12.2025)

Vibe coding is turning reporters into builders, and that’s a good thing for media (Fast Company 12.1.2026)

Rise of the vibecoding journalists (Nieman Lab joulukuu 2025)