Kielimallit ohjelmistoja tekemässä
Suomalaisessa mytologiassa esiintyy ajatus ihmekoneesta, joka tuottaa vaurautta ja hyötyä käyttäjälleen. Sampo on tarinoissa laite, joka jauhaa loputtomasti suolaa, jauhoja tai kultaa. Se on samalla teknologinen metafora koneelle, joka tekee melkein mitä vain.
Tämän päivän teknologisessa mielikuvituksessa sama asema on yhä selvemmin koodaavilla kielimalleilla. Kun Sampo jauhoi elämän aineksia, kielimallit tuottavat ohjelmakoodia. Ne pystyvät luomaan hyvin erilaisia sovelluksia, automatisoimaan prosesseja, yhdistämään palveluita ja rakentamaan kokonaisia ohjelmistoekosysteemejä tekstikehotteiden pohjalta.
On vaikeaa tarjota tyhjentävää listaa siitä, mitä kaikkea niiden avulla voi tehdä. Kokonaisia verkkosivustoja, rajapintoja, analytiikkaputkia, pelejä ja sovelluksia voidaan toteuttaa vain keskustelemalla mallin kanssa. Ne pystyvät rakentamaan automaatioita, ohjaamaan fyysisiä järjestelmiä (esim. Raspberry Pi ja Arduino -pohjaiset prototyypit), kehittämään mikropalveluarkkitehtuureja ja hyödyntämään kolmansien osapuolien kirjastoja, jolloin kokonaisratkaisu syntyy vaihe vaiheelta ilman, että kirjoittaja välttämättä tuntee loppukoodin yksityiskohtia.
Vibe-koodaus: keskusteleva ohjelmistokehitys
Kansainvälisesti on alettu puhua vibe coding -ilmiöstä. Käsitteen teki tunnetuksi tekoälytutkija Andrej Karpathykuvatessaan interaktiivista, iteratiivista ja intuitiivista ohjelmistokehittämistä, jossa kielimalli toimii dialogisena työparina (katso lisää esim. Wikipedia-artikkelista) Kirjoittaja ei välttämättä tiedä etukäteen, miten jokin pitäisi toteuttaa; hän vain etsii oikeaa suuntaa ja keskustelee mallin kanssa kohti haluttua lopputulosta.
Vibe-koodaus muistuttaa improvisaatiota. Koodaus ei ole käyttöliittymien tekemistä kuten perinteisissä no-code-työkaluissa, vaan keskustelua tavoitteesta, jossa malli generoi ehdotuksia, koodia ja seuraavia askelia. Ero edeltäviin suljettuihin no-code-työkaluihin on olennainen: kielimalli osaa periaatteessa hyödyntää mitä tahansa ohjelmointikieltä, kirjastoja ja järjestelmiä, eikä toimi valmiiden rajattujen komponenttien puitteissa.
Vaikka ohjelmointitaitoa ei välttämättä tarvita, siitä on usein hyötyä. Tällöin käyttäjä voi pyytää käyttämään tiettyjä ratkaisuja, tiettyjä rajapintoja tai ehdottaa tietynlaista ohjelmistoarkkitehtuuria. Yksi vaihe, jossa koodausosaamisesta on hyötyä, on debuggaus, eli virheiden korjaus. Kun ohjelmisto ei toimi syystä tai toisesta, on hyötyä, jos käyttäjä osaa ehdottaa kielimallille mahdollisia virhepaikkoja.
Toisaalta debuggausta ja suunnittelua voi tehdä oman osaamisensa rajoissa. Prosessia seuraneen ihmisen huomiot ja looginen päättelykyky voivat riittää hyvin pitkälle ongelmien ratkaisussa. Tällä kurssilla on aikaisemmin puhuttu useiden tekoälymallien hyödyntämisestä. Ohjelmistokehitys ei ole poikkeus. Voi olla hyödyllistä suunnitella projektia esimerkiksi ChatGPT:n kanssa, vaikka käyttäisikin itse koodaamiseen Claude Codea. Samoin jos Claude Code jää jumiin jonkin bugin kanssa, voi olla kannattavaa laittaa ChatGPT:lle ongelman kuvaus ja antaa vastaus jälleen Claudelle.
Jos on joskus toiminut ohjelmistoprojektien parissa esimerkiksi käyttökokemussuunnittelijana tai graafikkona, saattaa omata monia taitoja, joista on hyötyä vibe-koodauksessa. Tietyllä tavalla vuorovaikutus muistuttaa sitä, kun esimerkiksi käyttöliittymän suunnitellut henkilö keskustelee ohjelmistokehittäjän kanssa. On tärkeää, että pystyy selväsanaisesti kertomaan, mitä tavoittelee.
Erilaiset työkalut ja lähestymistavat
Koodia tuottavia kielimalleja voi hyödyntää useilla eri tavoilla. Yksi tapa on käyttää komentoriviltä toimivia työkaluja, kuten Claude Codea tai OpenAI:n Codexia. Tällöin projekti rakentuu keskustelemalla mallin kanssa: käyttäjä kuvailee, mitä haluaa, ja malli luo projektirakenteen, ehdottaa kirjastoja, asentaa riippuvuuksia ja suorittaa koodia. Työnkulku muistuttaa tilanteita, joissa ohjelmistokehittäjälle annetaan suunta, ja tämä tekee työn, mutta nyt kehittäjä on kone. Komentorivin käyttö vaatii hieman totuttelua, jos ei ole käyttänyt sitä aikaisemmin, mutta Claude Code tai Codex tekevät tarvittaessa suurimman osan komennoista käyttäjän puolesta.
Toinen lähestymistapa on käyttää visuaalisia ympäristöjä, kuten Lovablea. Ne sopivat erityisen hyvin luovan alan tekijöille, joille käyttöliittymät ja visuaaliset rakenteet ovat luontevia. Työskentely muistuttaa prototyyppien rakentamista: ensin hahmotellaan käyttöliittymän muoto ja toiminnallinen idea, ja kielimalli rakentaa teknisen toteutuksen kulisseissa. Käyttäjän tehtävänä on kertoa, miltä haluaa kaiken näyttävän ja tuntuvan, ja järjestelmä toteuttaa pyynnön teknisellä tasolla.
Monelle kuitenkin kaikkein helpoin ensiaskel ovat chat-pohjaiset kielimallit, kuten ChatGPT, Claude tai Gemini. Niille voi kuvailla omin sanoin, millainen sovellus olisi tarpeen, ja malli kirjoittaa koodin. Usein kielimalli-chat pystyy myös suorittamaan ohjelman, jolloin esimerkiksi juuri luotu verkkosivu voidaan avata ja testata saman tien. Malli voi myös opastaa julkaisuprosessin askel askeleelta: sen voi pyytää kertomaan, kuinka toteutus siirretään palvelimelle tai liitetään olemassa olevaan verkkosivustoon. Alkuun pääsee kertomalla, mitä haluaa, eikä pyytämällä tiettyä teknistä ratkaisua.
Kuinka kehittää ohjelmistoja kielimallin kanssa
Kielimallien vahvuus luovan alan näkökulmasta on siinä, että ne avaavat ohjelmistoteknologiat myös niille, joilla ei ole perinteistä koodaustaustaa. Työskentely muuntuu keskusteluksi: ideasta voidaan tehdä luonnos, luonnoksesta prototyyppi ja prototyypistä toimiva demoversio ilman että käyttäjän tarvitsee ohjelmoida itse.
Toimintamalli sopii erityisen hyvin suunnittelijoille, jotka ovat tottuneet ajattelemaan iteratiivisesti ja joiden työ rakentuu luonnosten ja kokeilujen varaan. Työtapa muistuttaa design-sprinttejä: ideaa tarkennetaan vuorovaikutteisesti, ja kielimalli auttaa kehittämään koodillisen pohjan. Ohjelmistoa testataan, mikä saattaa jälleen synnyttää uusia ajatuksia sen toimintalogiikasta ja ominaisuuksista. Lukuisten kierrosten jälkeen lopputulos voi olla aivan jotain muuta, kuin mitä alunperin lähdettiin tavoittelemaan. Nopean tekemisen ja testaamisen sykli mahdollistaa intensiivisen kehittämisen. Näin tekninen ja luova työ alkavat limittyä, ja uudenlaiset roolit tulevat mahdollisiksi. Ei ole enää välttämätöntä erottaa suunnittelua ja koodausta toisistaan yhtä jyrkästi kuin vielä muutama vuosi sitten.
Tämä myös madaltaa kynnystä tutkia oman työn laajennuksia. Visuaalinen suunnittelija voi rakentaa näyttelyn verkkopohjaisen version, äänitaiteilija voi luoda sovelluksen, joka manipuloi audiota reaaliajassa, tanssitaiteilija voi rakentaa sensoridataa hyödyntävän interaktiivisen teoksen.
Koodaavat kielimallit eivät kuitenkaan tee ohjelmistokehityksestä aivan automaattista. Ne voivat tuottaa vaikuttavan näköistä ja toimivaa koodia, mutta samalla ne saattavat jättää tekijän melko kauas järjestelmän varsinaisesta toiminnasta. Moni kokeilu saattaa lupaavan alun jälkeen muuttua turhauttavaksi taisteluksi, joka ei johda toimivaan lopputulokseen.
Jos sovellusta täytyy myöhemmin ylläpitää, laajentaa tai korjata, voi olla haastavaa jatkaa, mikäli koodin sisäinen logiikka on jäänyt hämäräksi. Siksi kehitykseen kannattaa suhtautua samalla tarkkuudella kuin muihinkin teknisiin prosesseihin: mallin tuottamaa koodia on hyvä lukea, kommentoida ja dokumentoida.
Malleja voi, ja kannattaakin pyytää noudattamaan ohjelmistokehitysalalla yleisiä tapoja dokumentoida ja tekstata sovelluksia. Vaikka et tietäisi, mitä ne tarkoittavat, osaa kielimalli tällöin palata paremmin työn pariin.
Luotettavuus on toinen keskeinen kysymys. Kielimalli voi tehdä virheitä, joita se ei itse tunnista. Monet virheistä ovat harmittomia, mutta eivät kaikki. Kun malli asentaa riippuvuuksia internetistä tai käyttää kirjastoja automaattisesti, syntyy myös tietoturvaan liittyviä kysymyksiä. Myös tässä voi pyytää kielimallilta apua: Siltä voi kysyä, onko kehittämämme ratkaisu tietoturvallinen vai ei.
Kriittisiä järjestelmiä ja vaikkapa rahaliikennettä ei vibe-koodatuilla systeemeillä kannata varmasti ohjata. Muutkin sovellukset voivat vaatia vielä paljon hiomista, ennen kuin ne ovat valmiita loppukäyttäjille.
Toisaalta kehittämisen nopeus tarjoaa uusia mahdollisuuksia ideoinnille. Käyttöliittymästä tulee paljon parempi, kun sitä pääsee heti testaamaan aidossa tilanteessa. Virheet nousevat esille aikaisemmin ja kehittämisestä tulee halvempaa.
Esimerkiksi startup-yhtiöille on keskeistä saada käytettävissä olevilla resursseilla mahdollisimman hyvä lopputuote. Varaa täydellisyyden hiomiseen ei ole, vaan tärkeintä on saada kehitettyä jotain toimivaa, joka osoittaa liiketoimintamallin kehityskelpoiseksi. Tässä vibe-koodaus on erityisen tehokasta. Viikkojen tai kuukausien sijaan kehityksessä saatetaan puhua tunneista tai päivistä sekä kymmenien tuhansien sijaan kymmenistä euroista. On myös täysin mahdollista tehdä markkinoille kelpaavia tuotteita, kun kielimallien koodaustavan sekä niiden yleisimmin tuottamat virheet oppii.