Hyvät, pahat ja rumat: Kun tekoäly koodaa softaa – Osa 3: Rumat

Tekoälyllä voidaan tuottaa muutamassa minuutissa jotain, mihin aiemmin kului tunteja tai päiviä. Ruudulle ilmestyy käyttöliittymä, testi menee läpi ja ensimmäinen demo näyttää vakuuttavalta. Tästä olisi helppo vetää johtopäätös, että myös ohjelmistokehitys olisi muuttunut helpoksi. Näin ei kuitenkaan ole, kertoo Web Developer Santtu Lehtinen blogisarjassaan. 

Kolmiosaisessa blogisarjassa Lehtinen ruotii tekoälyavusteisen koodauksen hyvät, pahat ja rumat. Pahimmillaan jälki voi olla kovinkin rumaa – tämänkertaisessa blogissa perehdymme apurien nurjaan puoleen. 

Kun koodia syntyy enemmän kuin ymmärrystä 

Kun hyvä ratkaisu voidaan toteuttaa aiempaa nopeammin, syntyy selvää hyötyä. Vauhtisokeuden iskiessä nopeudesta voi olla myös haittaa. Tekoäly voi kasvattaa huonosta perusratkaisusta nopeasti suuren, todella huonon ratkaisun. Koodia, rakenteita ja riippuvuuksia kertyy ennen kuin koodari ehtii kissaa sanoa tai kukaan pysähtyy kysymään, miksi ne ovat olemassa.

Tästä syntyy pahimmillaan teknistä velkaa: nopeuden nimissä tehdään ratkaisuja, joiden kustannus maksetaan myöhemmin hitaampina muutoksina, vaikeampina virhetilanteina ja kasvavana ylläpitotyönä. Jos koodin määrä kasvaa ymmärrystä nopeammin, katselmoinnista tulee pullonkaula ja kokonaisuuden omistajuus hämärtyy.

Sama työkalu, eri käyttäjä, eri lopputulos

Tekoäly voi olla aloittelevalle kehittäjälle erinomainen oppimisen apuväline. Se voi selittää käsitteitä, näyttää esimerkkejä ja auttaa pääsemään alkuun. Samalla se voi ohittaa juuri sen ajatteluvaiheen, jossa koodaus-, suunnittelu- ja arkkitehtuuritaidot tavallisesti kehittyvät.

Toimivan vastauksen saaminen ei vielä tarkoita, että käyttäjä ymmärtää, miksi ratkaisu toimii, missä tilanteessa se hajoaa tai mitä muita vaihtoehtoja olisi ollut. Ilman vertailupohjaa on myös vaikea tunnistaa vakuuttavasti esitettyä mutta heikkoa ehdotusta.

Riski ei koske vain uransa alussa olevia kehittäjiä. Myös kokenut kehittäjä voi olla vastaavassa tilanteessa, jos teknologia, koodipohja tai ratkaistava liiketoimintaongelma on uusi. Tällöin tekoälyn vastausta ei voi verrata tuttuun toteutukseen tai aiemmin opittuun käytäntöön, joten sen oletukset ja perustelut on syytä tarkistaa tavallista huolellisemmin.

Oppimisen kannalta ratkaisevaa on, käytetäänkö tekoälyä ajattelun tukena vai sen korvikkeena. Kun tekoälyltä pyydetään perusteluja, vaihtoehtoja ja testejä, se voi syventää ymmärrystä. Jos sen ehdotus vain hyväksytään, osaamisaukko voi jäädä piiloon myös tekijältä itseltään.

Aloittelevan kehittäjän oppimista voidaan tukea pyytämällä häntä selittämään ratkaisu omin sanoin, muuttamaan sitä ilman tekoälyn apua ja arvioimaan, mitä tapahtuu virhetilanteessa. Näin työkalun käytön myötä kasvaa myös kyky ottaa vastuuta sen tuottamasta koodista.

Yksi toimiva näkymä ei vielä ole toimiva palvelu

Tekoäly voi luoda nopeasti näyttävän käyttöliittymän tai yksittäisen ominaisuuden. Tuotannossa toimiva palvelu on kuitenkin kokonaisuus. Sen pitää huolehtia kirjautumisesta ja käyttöoikeuksista, käsitellä tietoja luotettavasti, toimia yhdessä muiden järjestelmien kanssa ja selvitä virhe- ja poikkeustilanteista.

Lisäksi palvelua pitää voida seurata, päivittää ja korjata turvallisesti. Sen on toimittava myös silloin, kun käyttäjiä on enemmän kuin ensimmäisessä kokeessa tai jokin ulkopuolinen palvelu ei vastaa odotetusti. Tässä full stack -ajattelu korostuu: yksittäisen koodinpätkän tuottaminen on helppoa, mutta järjestelmän koko elinkaaren ymmärtäminen ei ole.

Ensimmäisen version tekijä saattaa vielä pystyä korjaamaan ongelmia jatkamalla keskustelua tekoälyn kanssa. Haaste kasvaa, kun palveluun lisätään uusia ominaisuuksia, käyttäjämäärä kasvaa tai alkuperäinen tekijä vaihtuu. Jos ratkaisun rakennetta ja valintoja ei ymmärretä, jokainen muutos lisää epävarmuutta. Tuotantokelpoisuus on siksi myös sitä, että ohjelmisto voidaan turvallisesti luovuttaa seuraavan ihmisen ylläpidettäväksi.

”Tehdään tämä itse tekoälyllä”

Yllä olevan otsikon ajatus on usein täysin järkevä. Tekoälyllä voidaan testata konseptia, rakentaa rajattu sisäinen työkalu tai selvittää, kannattaako ideaa kehittää pidemmälle. Riskit muuttuvat, kun ratkaisu käsittelee henkilötietoja, maksuja, asiakasprosesseja tai yrityksen kannalta kriittisiä integraatioita.

Vaikka kynnys ensimmäisen version rakentamiseen on madaltunut, täytyy ihmisen ottaa vastuu tuotantoon menevästä järjestelmästä joka tapauksessa. Ennen käyttöönottoa pitäisi tietää esimerkiksi seuraavat:

• mitä tapahtuu, jos ratkaisu epäonnistuu

• kuka osaa korjata sen

• kuka ylläpitää sitä vuosien päästä

• onko tekoälyn antama vastaus riittävän hyvä

Siksi ohjelmistokehityksessä tarvitaan edelleen ihmisiä – oma tiimi tai kumppani – jotka kantavat vastuuta kokonaisuudesta. Arvo ei synny vain siitä, että koodi saadaan kirjoitettua, vaan siitä, että ratkaisu toimii turvallisesti ja palvelee tarkoitustaan myös ensimmäisen demon jälkeen.

Tekoäly on hyvä renki, huono isäntä

Vanha sananlasku pätee tekoälyyn yllättävän hyvin. Tekoäly on hyvä renki, kun ihminen määrittelee tavoitteen, pilkkoo tehtävän järkevästi, asettaa rajat ja arvioi lopputuloksen. Huono isäntä siitä tulee, jos tekoälyn ehdottamat oletukset, rakenteet ja ratkaisut hyväksytään ilman omaa harkintaa.

Tekoäly ei tunne yrityksen tavoitteita samalla tavalla kuin ihmiset, kanna vastuuta järjestelmän tulevaisuudesta tai joudu ylläpitämään tekemiään ratkaisuja. Siksi ohjelmistokehittäjän ammattitaito koostuu yhtä enemmän siitä, kuinka hyvin hän ymmärtää järjestelmää, tekee valintoja ja arvioi lopputulosta ja vähemmän siitä, kuinka nopeasti hän pystyy kirjoittamaan koodia.

Tekoäly tekee koodin tuottamisesta helpompaa. Siksi ohjelmistokehityksen vaikeimmat asiat, kuten syvällinen ymmärrys, harkinta ja vastuu tulevat entistä näkyvämmiksi.