Vibe koodaus ja Spec-Driven Development

Ourolaiset kerääntyivät hiljattain kuukausittaista Kullanhuuhdontaa varten, tällä kertaa oppimaan uutta aiheesta vibe coding & Spec-Driven Development (SDD).

Tuntuu, että valtaosalla pitkään tällä alalla työskennelleillä ihmisillä on hyvin samanlainen suhtautuminen tekoälyn kanssa koodaamiseen:
– ”Se hallusinoi ihan omiaan.”
– ”Sen tuottamaa koodia on todella hankala ylläpitää.”

Hieman vastaavanlaisia fiiliksiä (vibes, if you will) ja ennakkoluuloja oli rivien välistä luettavissa myös meidän Kullanhuuhdontapäivän aamuna. Iltapäivän yhteenvetoon mennessä nämä fiilikset olivat kuitenkin jääneet hieman taka-alalle ja tilalla oli (ainakin allekirjoittaneen, koulutuksen vetäjän mielestä) positiivista yllättyneisyyttä ja uudesti syttynyttä mielenkiinnon kipinää tekoälyä kohtaan.

Softa-ala tuntuu muuttuvan nopeammin kuin koskaan ja generatiivinen tekoäly ei ole enää sinänsä mitään uutta kenellekään, se tuntuu olevan kaikilla enemmän tai vähemmän käytössä – ja nyt kun siitä on kovaa tahtia tulossa vakiintunut osa ohjelmistotuotannon työkalupakkia, niin koimme tämän koulutuksen olevan hyvä päivitys meidän AI-taidoille.

Vibe koodauksella tarkoitetaan tietenkin ohjelmointityyliä, jossa tekoälymalli tuottaa valtaosan (tai kaiken) koodista ja ihmisen rooli on enemmänkin ideointi ja koodin katselmointi. Tämä toimintatapa on ollut viime vuoden aikana yksi alamme kuumimmista puheenaiheista ja on kerännyt paljon kritiikkiä sen sekasortoisuuden sekä sillä tuotetun koodin huonolaatuisuuden vuoksi. Spec-Driven Development on sen sijaan ohjelmistotuotannon toimintatapa, jossa määrittely (Specification) luodaan aina ennen koodia hieman samantyylisesti kuin Test-Driven Developmentissa kaikelle kirjoitetulle koodille täytyy olla valmiiksi olemassa oleva testi. SDD:ssä otetaan käytännössä vielä isompi askel taaksepäin itse implementaatiosta ja projektin todellinen tuotos ei olekaan itse koodi vaan tarkkaan kuvailtu, projektin edetessä elävä ja kehitettävä määritelmä, jonka perusteella voidaan tekoälyn avulla generoida tarpeen mukaan niin monta variaatiota kuin on tarve. SDD:llä pyritään siis antamaan selkeitä ohjenuoria ja rajauksia jotka helpottavat tekoälymallin kanssa työskentelyä pitkässä juoksussa.

Päivän koulutus oli jaettu kolmeen osaan:

Aluksi kävimme läpi hieman NLP:n, LLM:ien ja vibe koodauksen historiaa sekä tutustuimme Spec-Driven Developmentin taustalla pyörivään ajattelu- ja toimintatapaan. Pohdimme myös minkälaisia projekteja halusimme pyrkiä toteuttamaan loppupäivän koulutuksen aikana tekoälyn avulla. Kun jokaisella oli selkeä visio mielessä, siirryimme koulutuksessa käytännön osuuteen.

Ensimmäisen käytännön osuuden pääpaino oli vibe coding. Käytännössä jokainen meistä oli tehnyt aiemmin koodauskokeiluita tekoälyn avulla – mutta tällä kuitenkin varmistettiin, että jokaisella osallistujalla on tuore muistijälki siitä, miltä AI:n kanssa koodaaminen tuntuu (voihan olla, että joku joka sanoo kokeilleensa AI:lla koodausta on viimeksi oikeasti kokeillut sitä ChatGPT:n alkuaikoina, kun OpenAI:n tuorein malli oli GPT-3.5). GitHub Copilotia apuna käyttäen koodasimme jokaiselle oman data factoryn, jolla pystyimme helposti tuottamaan hyödyllistä testidataa lopullisia projektejamme varten.

Toisessa käytännön osuudessa lähdimme määrittelemään omia projektejamme Spec Kitin (GitHubin julkaisema avoimen lähdekoodin SDD toolkit) avulla. Tämä vaihe olikin koulutuksemme työläin osuus vaikka Spec Kit tarjoaakin loistavat mallipohjat määrittelyjen luomiselle tekoälyn avulla. Pikkuhiljaa projektikansiomme täyttyi erilaisista toisiaan täydentävistä ja tarkentavista dokumenteista, joista viimeisimpänä on pitkä lista riittävän pieneksi pilkotuista tehtävistä joita tekoäly (tai ihminen, SDD:tä kun voi harjoittaa ihan perinteisillä biologisilla koodareillakin) voi alkaa toteuttamaan. Tämän jälkeen päästimmekin tekoälymallit työstämään näitä tehtävälistojen kohtia yksi kerrallaan ja seurasimme vierestä työn etenemistä sekä katselmoimme tekoälyn tuottamaa koodia. Jatkoimme tätä katselmointi- ja hallinnointisykliä kunnes tekoälymallit olivat käyneet kaikki tehtävälistan tehtävät läpi ja käytännössä jokaisella osallistujalla oli lopputuloksena valmis sovellus demottavaksi (vaikka yhdessä tapauksessa heitimme tarkoituksella myös hieman kapuloita rattaisiin muuttamalla määrittelyjä melko perustavanlaatuisesti kesken implementaatiovaiheen). Tämän viimeisen vaiheen aikana syntyi myös luonnostaan todella hyvää keskustelua tästä kehitystavasta sekä tekoälyn käytöstä muutenkin.

Koulutuksen aikana oli hienoa nähdä useamman varttuneen ohjelmistoammatilaisen kasvoilla positiivista yllättyneisyyttä tekoälyn kyvykkyydestä. Varsinkin agenttisen tekoälyn autonomisuus ja debug-taidot nousivat esille loppukeskusteluissa. Spec-Driven Developmentin tuoma projektin rakenteellisuus ja ”specification -> plan -> tasks” -tyylinen määrittelyjen pilkkominen edisti vielä entisestään AI:n kykyä luoda projekteihin arvoa todella nopeasti.

Koulutus toi esille kuinka suuret kielimallit voivat parhaassa tapauksessa nopeuttaa eri ohjelmistotuotannon vaiheita merkittävästi, kunhan pidetään mielessä että tekoäly ei ole vielä millään tasolla täysin erehtymätön ja se vaatii edelleen ihmisen ohjaamaan sitä jatkuvasti oikeaan suuntaan ja varmistamaan sen työn jälkeä. Tekoäly siis tehostaa ohjelmistoalan ammattilaisten työtä, ei korvaa sitä.

Spec-Driven Developmentista voi lukea lisää esimerkiksi Spec Kitin GitHub reposta:
https://github.com/github/spec-kit/blob/main/spec-driven.md

 

Kirjoittaja on Ouron ohjelmistoautomaatio kehittäjä Joni Fofonoff

 

 

Edellinen artikkeli
Git log