Generatiivisten tekoälytyökalujen vaikutus ohjelmistokehitykseen on viime aikoina herättänyt runsaasti keskustelua sekä työpaikoilla että julkisuudessa. Pöhinää seuratessa voi löytää mielipiteitä laidasta laitaan: toisten mielestä ohjelmistokehittäjät ja -suunnittelijat ovat vuoden päästä työttömiä ATK-järjestelmien pumpatessa ulos arvoa nopeammin kuin tuhannen henkilön kehitystiimit, kun taas kehän toisesta reunasta löytyvät skeptikot, joiden mielestä nämä työkalut eivät ole kuriositeettia kummempia satunnaisgeneraattoreita.

Tekoälyhärveleiden hypekäyrän derivaatan lähestyessä äärettömyyttä heräsi kesäkuisena iltapäivänä valtakunnan pääkaupungissa erään kehittäjän ja erään suunnittelijan mielessä jalo aate: “Mitä jos näitten härveleiden hyödyllisyyttä kokeilis niinku ihan oikees projektis?”

Projektin taustaa

Otetaan kuitenkin ensin säihkyvää "AI-insightia" muutama askel taaksepäin, kun tarinankertoja maalaa kuvan projektin taustasta.

Blogi seuraa Eräkulkuri-nimisen startup-projektin toteuttamista. Palvelun ideana on metsästys- ja kalastuslupien välitystä keskitetysti, helposti ja modernisti. Vastaavia välityspalveluita on olemassa, mutta ainoa suurempi keskitetty ratkaisu on Metsähallituksen ylläpitämä Eräluvat, joka välittää lupia vain valtion maa- ja vesialueille. Eräkulkurin avulla maanomistajille avautuu uusi tulovirta, ja luvan ostajat hyötyvät lupa-alueiden määrän kasvusta.

Projektin tarkoituksena on toteuttaa niin sanottu PoC (eng. proof of concept), jonka avulla Eräkulkurin liikeidea voidaan varmentaa matalin kehityskustannuksin. PoC-toteutus on generatiivisten tekoälytyökalujen hyödyntämisen kannalta ihanteellinen lähestymistapa, sillä toiveena on, että saamme näillä työkaluilla nyhjäistyä merkittävää arvoa vaatimattomasta investoinnista. PoC-tuote ei ole tarkoitettu jatkokehitettäväksi, jolloin teknisten ratkaisujen ei tarvitse kestää samalla tavoin aikaa kuin pitkän elinkaaren IT-projekteissa.

Prototypointityökalut

Tekoälytyökalujen hyödyntämistä päästiin koeponnistamaan jo aivan projektin alkuvaiheessa. Perinteisten suunnittelutapaamisten pohjalta asiakkaan idea alkoi kirkastua ja tuotteen vaatimukset hahmottua. Vaatimusten sanoittaminen kirjalliseen muotoon mahdollisti Vercelin v0:n ja Lovablen kaltaisten työkalujen hyödyntämisen.

v0 ja Lovable ovat esimerkkejä generatiivisista tekoälytyökaluista, jotka rakentavat web-sovelluksen käyttöliittymän kehotteen (eng. prompt) perusteella. ChatGPT:stä tutulla tavalla viestikenttään loruillaan halutun käyttöliittymän määritelmä, ja työkalu tuottaa kehotteen mukaisen käyttöliittymän koodin. Tätä voidaan jatkokehittää antamalla lisää kehotteita samaan viestiketjuun, jolloin työkalu tekee mielestään tarvittavat muutokset generoimaansa koodiin. 

Vaikka markkinointimateriaalin perusteella nämä työkalut tekevät kaiken suunnittelusta toteutukseen ja jopa julkaisuun asti, aloitimme projektin aikana kutsua niitä "prototypointityökaluiksi" generoidun koodin laadun ja käyttöliittymän geneerisyyden vuoksi. Vaikkakin varsinkin geneerisyydestä on mahdollista päästä eroon lisäkehotteiden avulla, ajattelimme tämän kuitenkin nakertavan suunnittelulle varattua aikaa ilman merkittävää hyötyä.

Prototyyppien generoinnilla suunnittelun tueksi saatiin luotua nopealla tahdilla uutta käyttöliittymää. Ajantasaiset ja toiminnalliset prototyypit mahdollistivat muun muassa vaatimusten validoinnin sekä mahdollisten puutteiden ja ongelmien tunnistamisen. Suurin hyöty saatiin kuitenkin kommunikaatiossa: asiakkaan ja asiantuntijoiden on huomattavasti helpompi keskustella, kun esitettävä asia voidaan konkreettisesti näyttää prototyypin avulla. Prototyyppien käyttö vaikutti myös vähentävän väärinymmärryksen mahdollisuutta, sillä molemmat osapuolet näkivät selvästi, mitä vaatimuksilla tarkoitetaan.

Prototyypistä tuotteeksi

Suunnittelun edetessä ja prototyyppiversioiden kasautuessa heräsi kysymys taustajärjestelmän ja tietomallin rakenteesta. Suunnittelumuistiinpanojen perusteella näistäkin oli muodostunut jonkinlaisia määritelmiä. Heräsikin ajatus, että voisiko näistä muistiinpanoista kokoamalla saada aikaan ei pelkästään käyttöliittymäprototyypin, vaan kokonaisen, toimivan tuoteprototyypin.

Kuten todettua, prototypointityökaluja oli tähän mennessä hyödynnetty ainoastaan käyttöliittymäkoodin generointiin. Näitä työkaluja voi kuitenkin ohjeistaa generoimaan myös taustajärjestelmäkoodia, ja esimerkiksi Lovable sisältää valmiin integraation PostgreSQL-tietokantapalvelua varten. Subjektiivisen arvion perusteella taustajärjestelmän kehittäminen pelkästään kehotteiden avulla näitä työkaluja hyödyntäen vaikutti kuitenkin vaativan enemmän työtä kuin mitä lopputuloksesta olisi saatavissa hyötyä verrattuna osittaiseen artesaanityöhön.

Koska prototypointityökalut eivät tuntuneet taipuvan ketterästi taustajärjestestelmän tuusaukseen, oli aika kaivaa työkalupakista uusia vimpaimia. Testattavaksi putkeksi valikoitu seuraavassa kuultava yksinkertainen suunnitelma:

1. Käyttöliittymäkoodin generointi prototypointityökaluilla

2. Käyttöliittymän tarvitseman rajapinnan kuvauksen generointi OpenAPI-formaattiin prototypointityökalulla

3. Käyttöliittymäkoodin siirtäminen GitHubiin ja koodin avaaminen Cursorilla

4. Taustajärjestelmän reittien generointi OpenAPIn generaattorilla

5. Palvelu- ja tietokantakerroksen muodostaminen Cursorilla

Mainittakoon, että OpenAPI-standardi mahdollistaa taustajärjestelmän rajapintojen määrittelyn, ja näiden määrittelyjen perusteella on mahdollista generoida automaattisesti (ilman tekoälyä!) taustajärjestelmän rajapinnat. Prototypointityökalu pystyi generoimansa käyttöliittymäprototyypin perusteella tuottamaan tällaisen OpenAPI-standardin mukaisen määrittelyn. Cursor puolestaan on ohjelmistoympäristö (eng. IDE), johon on integroitu mahdollisuus hyödyntää generatiivista tekoälyä sekä koodin luomiseen että sen ymmärtämiseen.

Putki osoittautui sinänsä menestykseksi, sillä se mahdollisti etenemisen nollasta toimivaan tuotteeseen yhden työpäivän aikana. Eli siis kootuista ja selkokielisistä tuotevaatimuksista päästiin toimivaan, kokonaisvaltaiseen tuoteprototyyppiin

Negatiivisia puoliakin oli. Ensinnäkin generoidun koodin laatu oli… vähintäänkin kyseenalaista. Kielimalli esimerkiksi vaihtoi usein käyttämäänsä termistöä lennosta, jolloin muuttuja-, funktio- ja komponenttinimet olivat äärimmäisen vaikeaselkoisia. Lähdekoodi ei myöskään jakaantunut selkeisiin loogisiin osiin, vaan osa tiedostoista oli reilusti yli tuhatrivisiä, kun toisaalla atomisuus oli viety äärimmilleen käytännössä jokaisen rivin kutsuessa jotain erittäin spesifiä apufunktiota.

Sinänsä koodin vaikeaselkoisuus ei olisi ollut PoC-projektin kannalta maailmanloppu, jos koodiin ei olisi tarvinut koskea manuaalisesti. Kuitenkin aika-ajoin vastaan tuli ongelmia, jotka eivät ratkenneet pelkästään tekoälytyökalua ohjeistamalla, jolloin oli pakko tarttua itse toimeen. Näissä tilanteissa konepellin alla odotti melkoisia pommeja, ja niiden selvittäminen söi saavutettua ajansäästöä.

Tärkeää on myös huomata, että nollasta sataan vuorokaudessa -lupaus toteutui, koska perinteistä suunnittelutyötä oli tehty riittävästi etukäteen. Näin työkaluun annetut kehotteet olivat yksityiskohtaisia, ja käyttöliittymän rakennetta sekä toiminnallisuutta oli testattu useilla eri prototyypeillä. Työkalulle pystyttiin siis antamaan pitkälle viety, tarkka kuvaus halutusta tuotteesta.

Viimeisenä huomiona on todettava, että vaikka tällä menetelmällä kehitetty versio tuotteesta soveltuu erinomaisesti ongelmakentän kartoitukseen, suunniteltujen vaatimusten validointiin sekä keskustelun tueksi, en itse silti missään tapauksessa uskaltaisi ottaa sitä käyttöön tuotantoympäristössä. Erityisesti, kun ottaa huomioon, että Eräkulkuri tulee käsittelemään sekä rahaa että henkilötietoja.

Loppukaneetti

Generatiiviset tekoälytyökalut tuntuivat helpottavan suunnitteluvaihetta nimenomaan ongelmakentän kartoittamisen, ratkaisuideoiden validoinnin ja kommunikoinnin osalta. 

Kuitenkin niiden käyttämisen edellytyksenä on vanhan liiton artesaanityö, jossa asiakkaan liiketoimintaideaa kartoitetaan, jotta digitaalinen ratkaisu saataisiin määriteltyä tarkoituksenmukaiseksi. Työkaluja hyödyntämällä tätä määrittelytyötä voidaan kuitenkin tehostaa, ja suunnitteluvaiheesta kehitystyöhön siirryttäessä ratkaisu on mietitty ja validoitu huomattavasti pidemmälle kuin perinteisin menetelmin.

Blogisarjan seuraavassa jaksossa sankarimme siirtyvät suunnittelusta kehitysvaiheeseen, jossa haasteina odottavat eri työkalujen yhdistäminen, kehitystyön organisointi ja iteratiivisen kehityksen mahdollistaminen.

-

Blogitekstin kuvituskuva: Old Book Illustrations + muokkaus Google Geminillä