Mitä jos voisit vaan kertoa jollekin, millaisen sovelluksen haluat, ja se joku kehittäisi sovelluksen sinun puolestasi? Nyt se on mahdollista, mutta siinä on myös riskinsä. Tällaista on vibe-koodaaminen.
Ohjelmoinnin historia alkaa 1900-luvun puolivälistä, jolloin tietokoneet olivat harvojen käsissä ja ohjelmointi tarkoitti binääristä puljaamista, matalan tason käskyjä ja fyysisiä kytkentöjä. 60- ja 70-luvuilla syntyivät ensimmäiset ohjelmointikielet, ja niiden myötä ajatus siitä, että ohjelmointi voisi olla loogista, systemaattista ja ihmisen luettavaa. Vielä pitkälle 2000-luvulle ohjelmistokehitys oli asiantuntijatyötä, jossa kehitysympäristöt olivat raskaita ja julkaisusyklit hitaita.
Viimeisen 15 vuoden aikana kaikki on muuttunut. Pilvi, selain, avoin lähdekoodi ja erityisesti low-code- ja no-code-työkalut ovat muuttaneet tapaa, jolla sovelluksia kehitetään. Ne ovat jatkuvasti monipuolisempia, tehokkaampia ja mahdollistavat yhä laajempien sovellusten tekemistä tavalla, josta aiemmin voitiin vain unelmoida. Siinä missä ennen piti osata kirjoittaa satoja rivejä koodia yksinkertaisenkin toiminnallisuuden toteuttamiseksi, nyt voidaan rakentaa saman asian raahamalla ja pudottamalla komponentteja visuaalisessa editorissa, luonnollisella kielellä. Koodiahan nämäkin alustat kirjoittavat, mutta tapa tuottaa koodia on vain erilainen.
Ja nyt, ollaan jälleen päästy uuden asian äärelle, nimittäin vibekoodaamiseen, eli promptaamalla koodaamiseen. Tässä tekstissä kerrotaan mitä vibekoodaus tarkoittaa, mitä hyötyä ja riskejä siinä on, sekä miten vibekoodausta kannattaa ajatella.
Vibekoodaus (vibe-coding), tai "fiiliskoodaus" tarkoittaa ohjelmointia syöttämällä toiveet koodausalustan tekoälylle, joka kehittää sovellusta pala kerrallaan annetun promptin perusteella. Toisin sanottuna, käyttäjä kirjoittaa promptin ja AI kirjoittaa koodin, luo elementit ja kaiken teknisen kehittäjän puolesta, ilman että itse tarvitsee kliksutella yhtään mitään. Ja tämäkös se vasta nopeaa onkin.
Kehitys on todella intuitiivista, sillä tekoäly kertoo jatkuvasti chatissa mitä tekee, ja koodi muodostuu kehittäjän katsellessa chatti-ikkunaa. Tästä syntyy oikein tehokas jatkuva feedback-loop, joka auttaa kehittäjää ymmärtämään mitä ollaan tekemässä ja miten sovellus muodostuu.
Lyhyesti, mitä vain. Nämä alustat toimivat ihan kuten muutkin ohjelmointialustat. Erona kehittämiseen on alustassa oleva chat-ikkuna, jonka kautta koodia promptataan.
Helpoiten pääsee liikkelle esimerksi ihan nettisivujen tekemisestä. "Tee simppeli laskeutumissivu tällaiselle yritykselle käyttäen HTML, CSS ja JavaScript- yhdistelmää." Tämän jälkeen todennäköisesti innostutaan toiminnallisuuksista, eli siitä, että tämä sivu oikeasti tekeekin jotain. Saanko sivulle laskurin, joka kertoo esimerkiksi tämän tuotteen vaihtoehdot ja hinnan? - saat. Saanko sivulle lyhyen tietämystestin ja tulostenlaskujärjestelmän? - Tietysti saat.
Tästä päästäänkin luontevasti erilaisten mikroSaaSien tekoon, johon tarvitaan jo erilaisten kysymysten kysymystä ja erilaista osaamista. Miten sovellukseen kirjaudutaan ja missä tietokanta on? Miten tietokanta yhdistetään vibekoodaamalla tehtyyn sovellukseen? Minne sovellus julkaistaan, jotta käyttäjät löytävät sen? Saadaanko näitä sovelluksia julkaistua sovelluskauppoihin?
Me käytämme näitä alustoja tällä hetkellä paljon prototyyppien tekemiseen asiakasprojekteissa. Asiakkaalla saattaa olla monimutkainen sovellusidea mielessä ja nämä ovat yleensä aika abstrakteja idean alkuvaiheessa, onhan kyseessä tuote, jota ei ole vielä olemassa. Sovelluksen auki piirtäminen wireframeille auttaa alkuun, mutta toimiva ja kliksuteltava prototyyppi auttaa paljon pidemmälle. Tämä on ollut todella hyödyllistä ja helpottavaa sekä meille, että asiakkaille. Ideat saadaan auki nopeammin, niitä voidaan pallotella tehokkaammin ja saadaan yksinkertaisesti konkreettinen tuotos aikaiseksi erittäin vauhdikkaasti.
Parasta vibekoodaamisessa on se, että voit päättää ohjelmointikielen sen mukaan, millaisen sovelluksen aiot tehdä. Low-codessa alusta on tehty yleensä yhdelle kielelle tai frameworkille, ja kaikki sovellukset tehdään sillä (esimerkkinä Flutterflown Flutter ja Dart). Se on hyvä asia siinä mielessä, että kun tiedät, mihin käyttöön alusta on optimoitu, kuten Flutterflow natiiveille mobiilisovelluksille, voit valita alustan tarpeen mukaan.
Toisaalta, tämä voi olla myös huono asia siinä mielessä, että nyt vastuu päätöksestä on promptaajalla. Ellet pyydä jotain tiettyä, et välttämättä saa sitä. Täytyy siis ymmärtää ja selvittää mitä ollaan tekemässä ja mitä sen tekeminen vaatii teknisesti. Mikä ohjelmointikieli soveltuu parhaiten mobiilisovellukseen? Onko tämä vai tämä frameworkki parempi? Kummalla yleensä tehdään vastaavia toteutuksia? Mikä on olemassa vielä 5 tai 10 vuoden päästä?
Jo low-coden kohdalla on puhuttu paljon siitä, kuinka nykyään "kuka vain" voi tehdä sovelluksia. Tämä on teoriassa totta, mutta käytännössä myös low-codella ohjelmointi vaatii opiskelua, perehtymistä ja tekemistä, jotta saadaan oikeasti nopeaa ja hyvälaatuista sovellusta aikaiseksi. Kuka vain voi oppia, mutta kenestä vain ei välttämättä tule ammattilaista low-code kehittäjää, eikä tietysti tarvitsekaan. Parhailla osaajilla on usein myös yksi tai useampi ohjemointikieli hallussa, jotta he voivat tarvittaessa laajentaa sovellusta omilla komponenteilla, eli liittämällä itse kirjoitettua ulkoista koodia valmiin sovelluksen sisään.
Vibekoodauksessa varsinkin, kun kehittäjän täytyy pystyä kertomaan spesifisti mitä haluaa ja erottaa hyvä toteutus huonosta toteutuksesta, perus ohjelmoinnin termistö ja perusteet olisi hyvä olla hallussa. Muuten voi olla vaikeaa selittää tekoälylle, mitä tarkalleen haluaa. Tämä ei välttämättä tule vastaan heti, mutta sovelluskehityksen edetessä, kun mennään entistä pienempiin ja tarkempiin muutoksiin, spesifin promptin kirjoitus on tärkeää, jotta tekoäly varmasti ymmärtää mitä tarkoitat, sekä että koodipohja pysyy selkeänä, skaalaavana ja turvallisena.
Tästä päästäänkin laadukkaan koodin kirjoitukseen. Vibekoodauksen valtavan suosioryntäyksen yhteydessä on puhuttu viime aikoina erityisen paljon siitä, miten paljon koodin laatu on tutkitusti laskenut, kun kehittäjät käyttävät enemmän ja enemmän tekoälyä ohjelmointiin. Ei pelkästään vibekoodissa tai low-codessa vaan myös ihan perinteisessä ohjelmoinnissa. Mitä vähemmän kehittäjä katsoo koodin perään ja antaa vastuun täysin tekoälylle, saadaan vahingossa luotua raskaita ja huonosti toimivia koodinpätkiä, jotka eivät todellisuudessa ratkaise toivottua toiminnallisuutta parhaalla tavalla.
Ongelma syntyy siitä, kun tekoäly kirjoittaa koodin, eikä kehittäjä välttämättä osaa erottaa hyvää lopputulosta huonosta. Kommenttien puuttuminen, sekava kansiorakenne tai vahingossa hassusti tehdyt komponentit saattavat ensi alkuun toimia aivan hyvin ja silmämääräisesti ja testaamalla täyttää tarkoituksensa, mutta yhtäkkiä kun päälle aletaan lisäämään monimutkaisuutta, virheet ja ongelmat alkavat toistumaan jatkuvasti. Tätä voi olla toisinaan vaikea huomata ennenkuin ollaan jo menty pitkälle kohti metsää.
Koodin laadun kanssa samassa yhteydessä voidaan puhua turvallisista, tai ei niin turvallisista sovelluksista. Kun tekoälylle annetaan liikaa vastuuta koodista, ilman että muistetaan muistuttaa tietoturvasta, salauksesta ja kryptaamisesta, tai tässäkin yhteydessä, ilman että tiedetään miltä hyvä näyttää, saadaankin vahingossa tehtyä sovellus, joka laajalle yleisölle auetessaan avaisi mahdollisuuden vaikka minkälaiseen ei-toivottuun toimintaan. Tämän kanssa tulee siis olla erityisen tarkkana, etenkin jos sovellusta aletaan yhdistää ulkoiseen tietokantaan tai muihin järjestelmiin API-avaimia hyödyntäen. Tekoäly ei osaa lukea ajatuksia. Se ei automaattisesti tee tietoturvallista tai GDPR-vaatimuksia täyttävää sovellusta, ellet sitä erikseen pyydä, tarkasta ja muistuta uudelleen kehityksen edetessä.
Cursor on AI-natiivikoodieditori, joka on rakennettu Visual Studio Coden pohjalle ja suunniteltu ammattilaiskehittäjille. Cursor on tarkoitettu kehittäjille, jotka haluavat säilyttää täyden kontrollin koodista ja hyödyntää AI:n apua suurten koodikantojen hallinnassa, tiimityössä ja monimutkaisissa ohjelmistoprojekteissa. Cursorin keskeisiä toiminnallisuuksia ovat mm. älykäs automaattitäydennys, moniriviset koodiehdotukset, koodikannan laaja ymmärrys, Git-integraatio, tehokas refaktorointi ja virheiden tunnistus.
Lovable puolestaan on verkkopohjainen AI-sovellusten rakentaja, joka on suunnattu erityisesti niille, joilla ei ole syvällistä koodausosaamista. Lovable on suunnattu ei-teknisille käyttäjille, startup-tekijöille ja tuoteomistajille. Lovablen keskeisiä ominaisuuksia ovat mm. kokonaisen sovelluksen generointi yhdellä kehotteella (frontend, backend, tietokanta), valmiit integraatiot (esim. Stripe, Supabase), helppo käyttöönotto ja julkaisu. Siinä on kuitenkin vähemmän kontrollia yksityiskohtiin. Lovable tuottaa nopeasti toimivan tuotteen, mutta koodin yksityiskohtainen muokkaaminen ja optimointi on rajallisempaa kuin Cursorilla.
Tämähän saattaa kuulostaa varsin houkuttelevalta. Miksi maksaa ohjelmoinnista, perinteisestä, low-codesta tai mistään muustakaan, kun voin vain itse toteuttaa oman ideani?
Totta, vibekoodaus avaa peliä jälleen eri tavalla niille, jotka eivä ole aiemmin voineet kuvitellakaan tekevänsä itse sovelluksia. Mutta kuten tekstissä mainittu, on hyvä muistaa, että kaikki kirjoitettu koodi ei ole hyvää koodia. Etenkin jos puhutaan isommista, paljon monimutkaisuutta sisältävistä sovelluksista, joissa käyttäjien tietoja käsitellään monin tavoin, tai sovelluksen kautta liikutellaan esimerkiksi rahaa käyttäjiltä omistajalle (kuten SaaSeilla on monesti tapana tehdä), on paljon asioita, joita ensi kertaa liikkeelle lähtiessä ei välttämättä tule otettua huomioon. Seuraukset saattavat olla erittäinkin huonot.
Parasta sovellusta tehdään silloin, kun tekoälyä käytetään kumppanina, mutta kehittäjän ammattitaito on edelleen se, joka ohjaa sovelluksen valmistumista. Oli se sitten yksittäisten scriptien pyytäminen ChatGPT:ltä tai kokonaisen sovelluksen tekeminen Cursorilla. Tekoälyltä voidaan ottaa ideoita, pohtia toteutustapoja tai pyytää toiminnallisuuksia, mutta loppukädessä kehittäjän on hyvä pystyä jatkamaan ja muokkaamaan koodia, tulkitsemaan koodin laatua ja pyytämään muutoksia tarpeen mukaan. On tärkeää tietää, miltä hyvä näyttää ja osata ennakoida riskejä sekä tulevia kehitystarpeita.
Hopealuotia ei ole vieläkään olemassa. Vaikka myönnettävä on, että onhan tässä menty kehityksessä taas jo valovuosia eteenpäin. Jäädään mielenkiinnolla seuraamaan, mitä tulevaisuus tuo tullessaan, ehkä jo ensi viikolla.
tiivis infopaketti sovelluskehityksestä 2025
- Ohjeet sovelluksen ideointiin ja suunnitteluun
- Miten sovellusprojekti käytännössä toteutetaan
- Lisätietoa projektien kestosta ja hinnasta
