Koodaajan työ on muuttunut tekoälyn myötä perusteellisesti. Koodin tuottaminen on aiempaa nopeampaa, mutta lisäksi tekoälystä on apua suunnittelussa, vaihtoehtojen tutkimisessa, testaamisessa, dokumentoinnissa ja koodin arvioinnissa.
Tekoäly on muuttanut kehittämistä niin, että nyt voidaan toteuttaa muutamassa päivässä asioita, joihin aikaisemmin olisi kulunut viikkoja, jopa kuukausia. Oma työnikin on aivan toisenlaista kuin vuosi sitten.
Koska koodaaminen on nopeaa, kehittämisen pullonkaula alkaa siirtyä muualle. Pelkkä koodaamisen nopeutuminen ei kuitenkaan tehosta kehittämistä kokonaisuutena, jos määrittely, hyväksymiskäytännöt, tuotantoon vienti ja ylläpito eivät muutu mukana. Entistä tärkeämmäksi nousee myös kysymys siitä, mitä meidän ylipäätään kannattaa tehdä.
Pohdin tässä kirjoituksessa erityisesti sitä, mitä koodaamisen nopeutuminen tarkoittaa kokeilujen, tuotantoon viemisen, ylläpidon ja kustannusten kannalta.
Helpot ja nopeat demot konkretisoivat suunnitelmia
Tekoälyn avulla erilaisia kokeiluja voidaan tehdä todella helposti, nopeasti ja aiempaa halvemmalla. Enää ei tarvitse keskustella pelkistä tekstimuotoisista kuvauksista ja suunnitelmista, vaan ideoita voidaan testata käytännössä tekemällä POC (proof of concept).
POC on rajattu ja alustava toteutus, jolla voidaan kokeilla ja havainnollistaa, miten ohjelma toimisi ja miltä se näyttäisi. Kun ideasta on olemassa jotakin kokeiltavaa tai edes nähtävää, keskustelu muuttuu konkreettisemmaksi. POC auttaa osallistujia pääsemään samalle viivalle siitä, mitä ollaan ratkaisemassa, kenelle ja millä tavalla. Samalla huomataan usein sellaisia oletuksia ja käytännön ongelmia, jotka eivät olisi tulleet esiin pelkkää suunnitelmaa lukemalla.
Helpolta näyttävä on vasta puolitiessä
Helppous voi myös johtaa harhaan. Vaikka ensimmäinen versio syntyisi nopeasti, jokainen kokeilu kuluttaa edelleen ihmisten aikaa, laskentakapasiteettia, energiaa, luonnonvaroja ja huomiota. Helposti syntyvästä POCista voi myös tulla puolivahingossa pysyvä ratkaisu. Sehän näyttää ihan valmiilta.
Mutta vaikka kehittäjän omalla koneella pyörivä POC näyttää toimivalta, se ei tarkoita, että palvelu olisi hetkessä julkaisuvalmis. Tarvitaan esimerkiksi riskikartoituksia, tietosuojaa ja tietoturvaa koskevia selvityksiä sekä saavutettavuuden varmistamista. Sovellus pitää myös saada omalta koneelta oikeaan ympäristöön. Palvelulle täytyy löytää omistaja ja selvittää, kuka ylläpitää palvelua kehitysvaiheen jälkeen. Julkaisun pitäisi olla automatisoitu ja toistettava. Palvelua täytyy monitoroida, virheisiin reagoida ja riippuvuuksia päivittää. Tietoturvaa pitää kehittää koko sovelluksen elinkaaren ajan. Tämä muu ketju ei välttämättä nopeudu samaa tahtia kuin koodaaminen, joten nopeasti tehty POC voi olla vielä kaukana tuotantoversiosta.
Ennen POC-kokeiluun ryhtymistä pitäisikin tietää, mitä kokeilun jälkeen tapahtuu. Jos kokeilun lopputulos on se, että ratkaisu halutaan viedä tuotantoon, pitää miettiä kunnolla, onko meillä edellytyksiä viedä se tuotantoon ja ylläpitää sitä. Muuten tuloksena voi olla nopeasti kasvava joukko kokeiluja ja sovelluksia, joille ei ole selkeää omistajaa tai kestävää ylläpitomallia.
Kun toteuttaminen helpottuu, valintojen merkitys kasvaa
Tekoäly pienentää kokeilemisen kustannusta, mutta ei poista priorisoinnin tarvetta. Kun toteuttaminen muuttuu helpommaksi, korostuu entisestään kyky valita oikeat ongelmat. Mitä halutaan ratkaista ja keille ratkaisut toteutetaan?
Tavoitteena ei voi olla vain se, että tuotamme enemmän sovelluksia. Meidän pitäisi pystyä viemään oikeat sovellukset turvallisesti tuotantoon ja pitämään ne toimintakykyisinä kohtuullisella työmäärällä.
Haasteena on, ettei ongelmien tai toteutustapojen valinta ole vain yhden kehittämisalueen asia. Sitä pitäisi tarkastella nykyistä vahvemmin kokonaisuutena koko organisaation tasolla.
Katse seuraavaksi ylläpitoon ja elinkaaren hallintaan
Nyt kun tekoälystä saadaan jo huomattavaa hyötyä koodaamisessa, seuraava suurempi kehityskohde on mielestäni palveluiden ylläpito ja DevOps, eli se, miten sovellukset saadaan luotettavasti tuotantoon ja pidetään siellä toimivina, turvallisina ja ajan tasalla.
Tekoälyä pitäisi hyödyntää nykyistä vahvemmin esimerkiksi julkaisuputkien tekemisessä, infrastruktuurin määrittelyssä, monitoroinnissa, lokien analysoinnissa, riippuvuuksien päivittämisessä ja tietoturvapoikkeamien tunnistamisessa. Myös erilaisten selvitysten ja dokumentaation tekemisessä olisi paljon automatisoitavaa.
Tekoälyn kustannuksiin voidaan vaikuttaa valinnoilla
Tekoälyn käytön kustannusrakenne muuttuu. Tehokkaimpien mallien käyttäminen voi tulla kalliiksi, kun käyttö kasvaa. Toisaalta samaan aikaan pienemmät ja edullisemmat mallit paranevat.
Jokaiseen tehtävään ei välttämättä tarvita parasta ja kalleinta mallia. Usein tärkeämpää olisi löytää tehtävään riittävän hyvä malli ja käyttää tehokkaampia malleja vain siellä, missä niistä saadaan oikeasti hyötyä.
Organisaatioiden eteen tulee myös kysymys siitä, milloin kielimallien laskentatehoa kannattaa ostaa pilvipalveluna ja milloin malleja olisi järkevää ajaa omassa ympäristössä. Valintaan vaikuttavat hinnan lisäksi tietosuoja, tietoturva, suorituskyky ja ylläpidon vaatima työ. Tekoälymallin ajaminen omassa ympäristössä voi muuttua kiinnostavammaksi laitteiden kehittyessä. Sekään ei silti ole automaattisesti halpa tai helppo ratkaisu, koska laitteistosta, päivityksistä ja toimintavarmuudesta pitää huolehtia itse.
Mitä kannattaa jatkaa, mitä uudistaa?
Kehityksessä on mielestäni kaksi vastakkaista riskiä.
Voimme syöksyä liian nopeasti uusien ja ihmeellisten tekoälyn avulla tehtyjen sovellusten maailmaan ja unohtaa kaiken vanhan ja toimivan. Mutta kaikkea ei tarvitse rakentaa uudelleen vain siksi, että se on nyt aikaisempaa helpompaa.
Toisaalta vanhasta kiinni pitäminen voi olla aivan yhtä suuri ongelma. Jos jatkamme tuttujen mutta tehottomien ratkaisujen käyttöä vain siksi, että ne ovat jo olemassa, tekoälyn tarjoama tuottavuushyöty jää helposti pieneksi.
Tarvitsemme sekä kokeilunhalua että kykyä rajata tekemistä. Tekoäly auttaa rakentamaan nopeammin, mutta se ei päätä puolestamme, mitä kannattaa rakentaa, miten ratkaisu viedään vastuullisesti tuotantoon tai milloin vanhasta on aika luopua.
Ehkä tärkein tekoälyajan kehittäjätaito ei lopulta olekaan kyky tuottaa mahdollisimman paljon koodia. Tärkeämpää on tunnistaa, mikä on tekemisen arvoista ja miten siitä tehdään kestävä osa organisaation toimintaa.
