Tekoäly tuotekehityksessä – Kun virheisiin ei ole varaa

Tekoäly voi huomaamatta siirtyä apukuljettajasta ratin taakse. Teknologia ei varsinaisesti aja itse, mutta monissa tilanteissa olemme lakanneet kysymästä, missä ihmisen arvio on edelleen kriittistä.

Uusia työkaluja ilmestyy nopeammin kuin ehdimme muodostaa käsitystä siitä, miten ja milloin niitä kannattaa käyttää. Työkalut pystyvät vaikuttaviin suorituksiin, kuten luonnostelemaan tekstejä, tuottamaan ideoita ja koodia, tiivistämään dokumentteja ja rakentamaan prototyyppejä vauhdilla, joka olisi vielä hiljattain tuntunut epärealistiselta. Hankalampi kysymys on kuitenkin edelleen se, auttaako tekoäly meitä tekemään laadukkaampaa työtä, vai tekeekö se vain helpommaksi tuottaa määrällisesti enemmän?

Innostuksen keskellä saattaa unohtua, että kaikki tekoälyn käyttö ei ole samanlaista riskienhallinnan näkökulmasta. On aivan eri asia tuottaa luonnos sisäiseen käyttöön kuin rakentaa järjestelmä, jonka tulisi pitää ihmishenki turvassa. Ratkaisevaa eroa ei ole varaa unohtaa.

Tartumme työkaluun ennen kuin ymmärrämme ongelman

Uusien maagisten työkalujen houkutus on vahva, ja siihen tuppaa sortumaan meistä jokainen. Toivoisimme kovasti paikantavamme ongelman, jonka tekoäly voisi ratkaista. Etenemisjärjestys on kuitenkin nurinkurinen. Tehokkaampaa olisi tunnistaa ongelma, kuten hidas prosessi tai toistuva työtehtävä, ja kysyä vasta sitten, voiko työkalu auttaa.

Jos työkalu johtaa tekemistä, päädytään tuottamaan asioita, joita ei olisi välttämättä edes tarvittu: liian perusteellinen dokumentaatio, jonka läpikäyntiin kenelläkään ei ole aikaa, tai koodinpätkä, joka automatisoi kerran vuodessa eteen tulevan tehtävän.

Kaikki tämä kuluttaa aikaa, sitä ainoaa resurssia, jota harvoin mitataan. Aina mittaaminen ei ole edes mahdollista. Suuressa organisaatiossa ja etenkin tuotekehityksessä ajankäytön kontrollointi on erityisen vaikeaa, sillä uusille työtehtäville ei ole aiempaa vertailukohtaa. Ei siis tiedetä, kuinka kauan niiden kuuluisi viedä. Samaan aikaan yritykselle ja työntekijälle maksetaan tuloksista, ei silkasta uteliaisuudesta.

Promptauslaiskuus iskee parhaimpaankin meistä

Kaiken taustalla on ilmiö, jota kutsun promptauslaiskuudeksi. Kyseessä on alitajuinen toive siitä, että saamme nappia painamalla päävoiton: jotain täydellistä ja virheetöntä heti ensiyrittämällä. Kukapa ei haluaisi lyhentää tehtävälistaansa joutumatta punnertamaan jokaisen ranskalaisen viivan kohdalla?

Haaveiden sokaisemana unohdamme helposti käyttämiemme työkalujen rajoitteet. Tekoälymalli ojentaa niin itsevarman vastauksen, että olisi houkuttelevaa olla kyseenalaistamatta sitä kymmeneltä eri kantilta. Tarkistaminen, väitteleminen, vastausten ajaminen toisten mallien läpi, niiden lukeminen ja ymmärtäminen rivi riviltä ovat kuitenkin sitä työtä, jota ei voi jättää tekemättä. Tämä pätee silloinkin, kun johdon tasolta heitellään yksinkertaistettua viestiä siitä, kuinka kaiken pitäisi tapahtua nopeammin. Nyt kun tekoäly tekee kaiken puolestamme.

Usein tehokkuuden paine asetetaan ilman todellista mittaria sille, tekeekö tekoäly oikeastaan ihmisistä tuottavampia. Työkalut päätyvät jokaisen käyttöön, mutta prosessissa unohdetaan lopputulos: auttavatko ne todella ja miten?

Prototyypit ja raakaversiot – missä tekoäly todella lunastaa paikkansa

Syy ei ole teknologiassa. On käyttötarkoituksia, joissa se on aidosti poikkeuksellinen, esimerkiksi prototyyppien teossa. Jos tarvitaan yksinkertainen demonstrointi, tarpeen kuvailu riittää ja iltapäivään mennessä käsissämme on karkea, mutta täysin toimiva työversio.

Luonnostelu on toinen osa-alue, jossa tekoäly loistaa. Sen sijaan että yrittäisin sanoittaa toiveen graafiselle suunnittelijalle, se on helpompi toteuttaa karkeana tekoälyversiona, jonka suunnittelija voi sitten piirtää itse. Näin käytettynä tekoäly on kaikupohja, ei viimeistelijä. Juuri siksi pidän Clauden, Geminin ja ChatGPT:n auki yhtä aikaa ja pelautan niitä toisiaan vastaan. Ennen olisin kävellyt parin kollegan luokse pallottelemaan ideoita.

Ongelmat syntyvät siitä, kun erehdymme luulemaan kaikupohjaa valmiiksi työksi. Virhe on käynyt varmasti kaikille meistä: luonnos näyttää niin uskottavalta ja viimeistellyltä, että olemme vähällä lähettää sen valmiina eteenpäin. Toinen lukukerta kuitenkin paljastaa, kuinka pintaa syvemmällä piilee perustavanlaatuisia puutteita.

Mietitäänpä vaikka koodauskurssia, jossa opiskelijat rakentavat parissa tunnissa pienen pelin: laatikot pomppivat ympäriinsä ja ampuvat toisiaan. Vaikuttavaa! Pelihän näyttää oikeasti toimivalta. Mutta onko se valmis? Ei alkuunkaan. Todellinen työ on juuri siellä demon ja valmiin tuotteen välimaastossa.

Törmään usein toiseenkin vastaavaan tilanteeseen, kun pyydän mallia kirjoittamaan koodia. Se kirjoittaa mielellään myös yksikkötestit koodille, eli testit, joiden on tarkoitus todistaa koodin toimivuus. Kun sama tekijä laatii sekä vastauksen että kokeen, rivi vihreitä rukseja ei merkitsekään enää paljoa. Lukuisia kertoja olen nähnyt mallin tekevän oudon johtopäätöksen ja julistavan koodin täydelliseksi, sillä se läpäisi mallin omat testit. Koodi oli väärin, mutta niin olivat sen testitkin, joten mikään ei hälyttänyt.

Kuinka paljon väärässä oleminen maksaa?

Mitä kalliimpi virhe on ottaa takaisin, sitä vähemmän kannattaa luottaa tekoälyn ensimmäiseen vastaukseen. Sisäiseen käyttöön laadittu muistio saattaa mennä sellaisenaan läpi, sillä pienet epäjohdonmukaisuudet tuskin synnyttävät mittavia ongelmia. Jos kyse on asiakkaalle esitetystä perustelusta, sopimuksesta tai tuotantoon päätyvästä koodista, ollaan kuitenkin erilaisessa tilanteessa. Malli saa ehdottaa, mutta vastuu on silti aina ihmisellä ja yrityksellä, jonka nimi tuotoksiin liitetään.

Omalla alallani tämä on itsestään selvää. Tekoäly osaa luonnostella koodia ja perustella sen kauniisti, mutta sillä ei ole aavistustakaan, liittyykö jokin Safety Integrity Level tai MISRA-sääntö kontekstiin. On ihmisen tehtävä kertoa reunaehdot ja tarkistaa niiden vaikutus lopputulemaan. Turvakriittisessä työssä tarkistusta ei voi nopeuttaa, sillä väärä vastaus voi aiheuttaa todellisia vaaratilanteita.

Virheen hinnan ratkaisee myös se, voiko sen ylipäätään ottaa takaisin. Suuri osa nykyohjelmistoista voidaan päivittää etänä, joten toiminto, joka näytti laboratorio-olosuhteissa hyvältä, mutta petti tositarkoituksessa, voidaan korjata tai vetää pois seuraavassa päivityksessä. Tämä ei kuitenkaan päde kaikkeen.

Tuotekehityksessä osa koodista on nimittäin poltettu kiinni siruun tai suljettu laitteeseen, joka on jo kentällä. Myöhempää korjausmahdollisuutta ei tule. Tällöin koodin virhe ei ole vain kiusa, vaan täysi katastrofi. Eikä kyse ole edes uudesta ilmiöstä. Vuonna 1999 Mars Climate Orbiter menetettiin, koska yksi tiimeistä työskenteli anglosaksisilla mittayksiköillä ja toinen metrisillä. Ristiriitaa ei huomattu koko matkan aikana Marsiin asti. Kone teki täsmälleen niin kuin pyydettiin, mutta kukaan ei tarkistanut riittävän tarkasti, mitä sen pyydettiin tekevän.

Tarkoitus ei ole tarkastaa kaikkia nippeleitä tuhanteen kertaan, vaan oppia ymmärtämään, milloin kriittisyys on ratkaisevaa.

Kuka tahansa osaa kysyä, mutta taito on vastauksen arvioinnissa

Se, mitä pidämme taitona, on muuttunut huomaamatta. Kuka tahansa voi esittää kysymyksen ja saada vastauksen, mutta vain ammattilainen osaa arvioida vastauksen laatua.

Kollegani Janne Rosberg kirjoitti hiljattain siitä, kuinka työ siirtyy koodin kirjoittamisesta sen arvioimiseen. Toisen alan ammattilaiseksi ei tulla tekoälyn avulla. Ilman aitoa osaamista ja arvostelukykyä voi olla korkeintaan se ihminen, joka pyytää muutaman rivin koodia ja ojentaa ne eteenpäin huomaamatta niiden aukkoja.

Messuilla nuoria pysähtyy yhä ständillämme kysymään, kannattaako ohjelmistoalaa nykypäivänä opiskella. Vastaan aina kyllä: työ on vain lisääntymässä, mutta muuttamassa muotoaan. Funktioiden nimien opettelu menettää merkitystään ja fokus siirtyy sellaisiin ongelmiin, joita aidosti kannattaa ratkaista.

Seuraava sukupolvi kasvaa pitäen helposti kaikkea tekoälyn sanomaa totena. Säilyykö heillä vaisto huomata, kun jokin on pielessä? Me, jotka opimme ammatin ennen tekoälyn tuloa, osaamme kyllä kyseenalaistaa mallin ehdotukset. Itsevarma ja hyvin perusteltu vastaus ei ole aina oikea tai hyvä.

On myös käytännön syy olla päästämättä näitä taitoja ruostumaan, ammattiylpeyden lisäksi. Mitä enemmän nojaamme työkaluun, sitä nopeammin haihtuu arvostelukyky, jota ei voi korvata koneella. Ja työkalusta, jota ilman emme enää pärjää, tulee samalla sellainen, jota emme enää pysty tarkistamaan. Ainoastaan pitämällä omat taidot terävinä voimme huomata, kun malli on itsevarmasti väärässä.

Vastuu on yhä ihmisen

Kollegani Kim Meyer on esittänyt, että tekoäly ei vie kehittäjien töitä, mutta johdon tekoälystä tekemät tulkinnat ja päätökset saattavat viedä. Kyse on organisaation vastuusta. Vastuulla on kuitenkin toinenkin puoli, joka koskee yksittäistä ihmistä ja hänen tuotostaan, ja juuri siihen haluan nyt tarttua. Kun jokin menee pieleen, otammeko siitä vastuun, vai piiloudummeko sen taakse, että tekoäly oli syyllinen? Se muistuttaa vähän toisen läksyjen kopioimista: otamme hyvän arvosanan vastaan ja tajuamme vasta koko homman kaatuessa, ettei osaaminen koskaan ollut omaamme.

Koneen tuotoksen esitteleminen on helppoa. Sen takana seisominen on kuitenkin varsinainen työmme. Virheellisen luonnoksen esittely on korkeintaan kiusallista, mutta kun kyse on ohjauskoodista, ollaankin täysin eri tilanteessa. Kysymys ei ole koskaan ollut siitä, onko kone älykäs, vaan siitä, ottaako ihminen vastuun sen tekeleistä.

Juuri tämä kysymys piilee kaiken hehkutuksen alla. Istummeko yhä kuljettajan paikalla, vai olemmeko huomaamatta muuttuneet hermostuneiksi etupenkin matkustajiksi, jotka vain toivovat parasta?

Kolme kysymystä ennen enterin painamista

Tekoälyn hyödyntämiselle ei tarvita pitkää sääntökirjaa. Tärkeintä on pysähtyä toviksi ja kysyä itseltään kolme rehellistä kysymystä:

• Jos tämä vastaus on hienovaraisesti väärin, kuka huomaa sen ja milloin – minä nyt vai asiakas ensi kuussa, ja mitkä ovat todelliset seuraukset?
• Osaisinko tuottaa tai kunnolla tarkistaa tämän ilman mallia, vai luotanko siihen vain siksi, etten itse osaa arvioida sitä?
• Luovutanko tämän eteenpäin valmiina työnä vai luonnoksena, ja olenko valmis laittamaan nimeni sen alle?

Teknologia ei ole katoamassa minnekään, emmekä sitä toivoisikaan. Meidän on vain pysyttävä hereillä sitä käyttäessämme – kädet yhä ratissa.