Muistio antaa myös toimintaohjeen. Kehittäjän pitää dokumentoida syy, jakaa se kollegoille, viedä se esihenkilölle ja etsiä ratkaisuja. ”Insinööri, joka osaa selittää, missä tekoäly ei vielä auta hänen työssään, osoittaa juuri sitä harkintaa, jota pyydämme”, Terkowitz kirjoittaa.
Mittarit tunnustetaan huonoiksi
Päivitys koskee Amazonin ohjelmistokehittäjien roolikuvausta, jota yhtiön ylimmät insinöörit ovat muokanneet. Ydinviesti on, ettei kehittäjän roolia eikä hänen työnsä tulosta määritä tekoälyn käyttö. Ohjetta ei sidottu yksittäisiin työkaluihin, koska sellainen ohje vanhenisi nopeasti.
Muistio myöntää, että johto on seurannut tekoälyn käyttöä niin sanotuilla syötemittareilla, kuten kulutettujen tokenien määrällä ja tekoälytyökalujen käyttöönotolla. Samalla se toteaa suoraan: ”Olemme kaikki tietoisia siitä, kuinka syvästi virheellisiä nämä mittarit ovat.” Jos lukemista tehdään tavoitteita, ne voivat muistion mukaan johtaa huonoihin lopputuloksiin ja kasvattaa kustannuksia. Mittareita saa yhä käyttää varovasti, ja huomio kiinnitetään erityisesti käyttöasteen alimpaan ja ylimpään kymmenykseen.
Tekoälyä ei silti saa jättää sivuun. Muistio kehottaa opettelemaan tekoälyn käytön ja ottamaan sen osaksi päivittäistä työtä ”niin pian kuin mahdollista”. Esihenkilöiden pitää kokeilla työkaluja itse eikä luottaa kuulopuheisiin.
Taustalla katkosten kevät
Muistio ei mainitse katkoksia, mutta ajoitus on puhuva. Financial Times kertoi helmikuussa, että AWS:n pilvipalvelussa oli joulukuussa 13 tunnin katkos sen jälkeen, kun insinöörit antoivat Kiro-tekoälytyökalun tehdä muutoksia. Amazon kiisti tekoälyn olleen syyllinen ja puhui käyttäjävirheestä.
Maaliskuussa Amazonin verkkokauppa ja sovellus olivat lähes kuusi tuntia nurin koodivirheen vuoksi. Johtaja Dave Treadwell teki tämän jälkeen viikoittaisesta tekniikkapalaverista pakollisen. ”Kuten luultavasti tiedätte, sivuston ja siihen liittyvän infrastruktuurin saatavuus ei ole ollut viime aikoina hyvä”, hän kirjoitti sähköpostissa Financial Timesin ja Techzinen mukaan. Sisäisessä aineistossa yhdeksi tekijäksi nimettiin tekoälyavusteiset muutokset. Nuorempien kehittäjien tekoälyavusteiset koodimuutokset määrättiin kokeneempien insinöörien hyväksyttäviksi.
Käyttöpakko kehittäjän arjessa
Moni suomalainenkin kehittäjä tuntee asetelman. Tekoälytyökalun lisenssi on hankittu koko talolle, ja käyttöä seurataan kojelaudalta. Kun ohjelmistotalot tavoittelevat parempaa tulosta pienemmällä väellä, kuten Siilin tapauksessa nähtiin, tehokkuusodotus kohdistuu jokaiseen yksittäiseen kehittäjään.
Arjessa paine voi näkyä niin, että työkalua käytetään myös tehtäviin, joissa se hidastaa, koska käyttölukema päätyy esihenkilön raporttiin. Vanhan koodipohjan ylläpito tai tarkka infrastruktuurityö ovat esimerkkejä tehtävistä, joissa hyöty voi jäädä pieneksi ja virheen hinta suureksi.
Amazonin linjaus antaa työntekijälle luvan sanoa tämän ääneen ja perustella sen avoimesti. Asia koskee muitakin kuin koodareita: sama kysymys on edessä jokaisella, jonka työpaikalla tekoälyn käyttöä mitataan. Yritykselle ja asiakkaalle kyse on rahasta. Kuuden tunnin katkos verkkokaupassa maksaa enemmän kuin yksi hitaammin kirjoitettu muutos.
Ratkaisevaa on se, miten esihenkilöt lukevat käyttöasteen alinta kymmenystä. Jos matalan käyttöasteen tiimiltä kysytään ensin syytä, muistion periaate toteutuu. Muuten ”havainto” on vain uusi nimi merkinnälle kehityskeskustelussa.
