Joku tiimistä näyttää sinulle itse tekemänsä työkalun. Se hakee kuukausiraportin luvut kolmesta eri paikasta, yhdistää ne ja tekee valmiin taulukon. Ennen siihen meni tunti. Nyt kymmenen sekuntia. Hän ei osaa ohjelmoida. Hän osasi kertoa, mitä halusi, ja tekoäly kirjoitti koodin.
Onko tämä hyvä uutinen vai riski? Molempia. Raja kulkee tarkemmassa kohdassa kuin useimmat arvaavat.
Kyllä, pieniä työkaluja kannattaa tehdä
Aloitetaan myönteisestä puolesta. Pienet omat työkalut ovat juuri nyt tekoälyn selkein hyöty tavallisessa toimistotyössä. Skripti, joka nimeää sata tiedostoa uudelleen. Makro, joka siivoaa järjestelmästä tulevan viennin. Pieni laskuri, jolla myyjä saa tarjoushinnan kerralla oikein.
Näitä ei olisi tilattu keneltäkään. Ongelma oli liian pieni siihen, että sen ratkaisemisesta olisi kannattanut maksaa. Nyt ratkaisu syntyy iltapäivässä, ja säästö on todellinen.
Ammattilaisilla sama muutos näkyy mittauksissa. Googlen DORA-tutkimuksessa syyskuussa 2025 lähes 5 000 ohjelmistoalan ammattilaisesta 90 prosenttia käytti tekoälyä työssään ja yli 80 prosenttia koki sen parantaneen omaa tuottavuuttaan.
Sitten se toinen puoli.
Demo ei ole ohjelmisto
Kun ohjelma syntyy kuvailemalla, sen ainoa testi on yleensä tämä: se toimi kerran, tekijän koneella, tekijän omalla esimerkkitiedostolla. Ohjelmistotyössä tuota reittiä kutsutaan onnelliseksi poluksi. Kaikki menee niin kuin piti.
Suurin osa oikeasta työstä tehdään sen polun ulkopuolella. Mitä tapahtuu, kun tiedosto on tyhjä. Kun päivämäärä tulee väärässä muodossa. Kun rivejä on 40 000 eikä 40. Kun kaksi ihmistä tallentaa yhtä aikaa. Kun yhteys katkeaa kesken ajon. Kun kenttään kirjoitetaan jotain, mitä siihen ei ollut tarkoitus kirjoittaa.
Tekoäly kirjoittaa sen, mitä pyydettiin. Sitä, mitä ei osattu pyytää, se ei kirjoita. Juuri se puuttuva osa ratkaisee, kestääkö ohjelma toisen käyttäjän, ensi kuun tai ensi vuoden.
Melkein puolet tekoälyn tuottamasta koodista on turvatonta
Tätä ei tarvitse arvailla. Tietoturvayhtiö Veracode on ajanut samaa testisarjaa tekoälymalleille kahden vuoden ajan: 80 ohjelmointitehtävää neljällä kielellä, yli 150 mallia. Maaliskuussa 2026 julkaistun päivityksen tulos on sama kuin vuotta aiemmin. Vain 55 prosenttia tehtävistä tuotti turvallista koodia. Lopuissa 45 prosentissa oli tunnettu haavoittuvuus.
Keskiarvo peittää kiinnostavamman havainnon. Suojaus SQL-injektiota ja heikkoa salausta vastaan syntyi oikein useimmiten, 82 ja 86 prosentissa tapauksista. Kaksi muuta luokkaa eivät. Cross-site scripting, jossa hyökkääjä saa oman koodinsa ajettua käyttäjän selaimessa, läpäisi testin 15 prosentissa tapauksista. Lokitietojen turvallinen käsittely 13 prosentissa. Kumpikaan luku ei ole parantunut mallien kehittyessä.
Luvut koskevat mallien tuottamaa koodia silloin, kun tehtävänanto on ammattimainen ja tuloksen lukee ammattilainen. Kehittäjä tunnistaa puuttuvan tarkistuksen lukemalla. Se, joka ei osaa ohjelmoida, ei tunnista, ei osaa tarkistaa, eikä osaa ohjeistaa suojautumaan.
Koodi, joka näyttää toimivan silloinkin kun ei toimi
Toinen mittaus koskee sitä, mitä koodille tapahtuu ajan myötä. GitClear on analysoinut 623 miljoonaa koodimuutosta vuosilta 2023–2026. Tammikuussa 2026 julkaistut luvut kertovat yhdenmukaista tarinaa. Kopioidun koodin määrä on kasvanut 81 prosenttia vuodesta 2023, ja siivoaminen on käytännössä loppunut: vuonna 2022 muutoksista 21 prosenttia oli vanhan koodin uudelleenjärjestelyä, vuonna 2026 enää 3,8 prosenttia.
Yksi luku samasta aineistosta kannattaa lukea kahdesti. Virheitä vaimentavien rakenteiden määrä on kasvanut 47 prosenttia. Ne ovat koodia, joka nielaisee virheen ja jatkaa kuin mitään ei olisi tapahtunut. Ohjelma ei kaadu, se jatkaa kuin toimisi oikein.
Tämä on itse tehdyn työkalun ikävin ominaisuus. Rikkinäinen ohjelma huomataan heti. Ohjelma, joka toimii mutta laskee väärin, voi pyöriä kuukausia ennen kuin joku vertaa lukuja käsin.
Tekijä on huonoin arvioimaan, kuinka hyvin se toimii
Heinäkuussa 2025 tutkimusorganisaatio METR teki kokeen, jonka tulos yllätti myös tekijänsä. Kuusitoista kokenutta avoimen lähdekoodin kehittäjää ratkoi 246 todellista tehtävää projekteissa, jotka he tunsivat ennestään hyvin. Osassa tehtävistä tekoälytyökalut olivat sallittuja, osassa eivät.
Tekoälyä käyttäessään kehittäjät olivat 19 prosenttia hitaampia. Ennen koetta he arvioivat tekoälyn nopeuttavan työtään 24 prosentilla. Kokeen jälkeen, hidastuminen jo takanaan, he arvioivat tulleensa 20 prosenttia nopeammiksi.
Otos oli pieni ja tilanne erikoinen: kokeneita kehittäjiä isoissa, tutuissa koodikannoissa. METR rajaa tuloksen itsekin tähän tilanteeseen ja kertoi helmikuussa 2026 muuttavansa seuraavan kokeensa asetelmaa. Yhden asian koe kuitenkin näyttää selvästi. Tunne nopeudesta ja mitattu nopeus olivat eri asioita jopa ihmisillä, jotka tekevät tätä työkseen.
Siksi ”meillä se toimii” ei kelpaa laatuarvioksi. Se on tekijän kokemus tekijän omasta työstä.
Työkalu tekee sen, mitä pyydettiin, ei sitä, mitä prosessi vaatii
Ohjelmistossa vaikeinta on harvoin ohjelmointivaihe tai tekniikka. Vaikeinta on se, mitä yrityksessä oikeasti tapahtuu.
Itse tehty laskutustyökalu laskee laskut oikein. Sitten tulee ensimmäinen hyvityslasku. Sitten asiakas, joka on samalla toimittaja. Sitten tilikauden vaihde, keskeytynyt tilaus, käännetty arvonlisäverovelvollisuus rakennusalalla, ennakkomaksu, jota vastaan ei ole vielä toimitettu mitään.
Valmis ohjelmisto on törmännyt näihin satojen asiakkaiden kanssa ja korjannut ne. Itse tehty työkalu törmää niihin ensimmäisen kerran teidän kirjanpidossanne. Tekoäly ei tiedä poikkeuksista, joita sille ei kerrottu, eikä tekijä osaa kertoa niistä, joita ei ole vielä tullut vastaan.
Neljä kysymystä, jotka ratkaisevat rajan
Raja hyödyllisen ja vaarallisen välillä ei kulje siinä, kuinka taitava tekijä on. Se kulkee siinä, mihin ohjelma koskee. Neljä kysymystä riittää useimmiten.
Lukeeko se vai kirjoittaako se? Lukeva työkalu tekee pahimmillaan väärän raportin, ja väärän raportin voi tehdä uudelleen. Kirjoittava työkalu voi rikkoa lähdetiedot. Heinäkuussa 2025 Replitin tekoälyagentti poisti yrittäjä Jason Lemkinin tuotantotietokannan kesken sovitun muutosjäädytyksen, ja mukana meni yli 1 200 henkilön ja noin 1 190 yrityksen tiedot. Yhtiön toimitusjohtaja kuvasi tapausta hyväksymättömäksi ja totesi, ettei sen olisi koskaan pitänyt olla mahdollista. Replit erotti tämän jälkeen kehitys- ja tuotantotietokannat toisistaan. Tässä on ero lukemisen ja kirjoittamisen välillä.
Onko mukana henkilötietoja? Työnantaja on rekisterinpitäjä riippumatta siitä, kuka koodin kirjoitti tai kenen koneella se pyörii. Käsittely kuuluu selosteeseen käsittelytoimista, ja tietojen suojaamisesta pitää pystyä kertomaan. Työntekijän itselleen tekemä asiakasrekisteri on rekisteri.
Riippuuko joku muu siitä? Yhden ihmisen apuväline on yhden ihmisen riski. Kun sama työkalu pyörittää kolmen ihmisen työnkulkua, siitä on tullut järjestelmä, vaikka kukaan ei välttämättä ole niin päättänyt tai siltä pohjalta sitä testannut.
Kuka korjaa sen elokuussa? Tekijä on lomalla, vaihtanut työpaikkaa tai ei enää muista, miksi jokin kohta on niin kuin on. Jos vastaus on ”ei kukaan”, ohjelma on jo velkaa. Tekoälyn vahvuus on kyllä koodin ymmärtämisessä myöhemmin, mutta tekoäly ei tee sitä itsekseen – jonkun täytyyn sitä edelleen opastaa ja ohjeistaa, ja olla sen tekemisestä kiinnostunut.
Kun kaikki neljä vastausta ovat vaarattomia, anna mennä. Kun yksikin kääntyy, työkalulla pitää olla omistaja.
Näitä on enemmän kuin arvaat
PagerDutyn kesäkuussa 2026 julkaisemassa kyselyssä 1 250 toimistotyöntekijästä 66 prosenttia kertoi käyttäneensä tekoälytyökaluja, vaikka uskoi sen olevan vastoin työnantajan ohjeita. Työhön liittyvää tietoa julkiseen tekoälypalveluun oli syöttänyt 88 prosenttia. Kysely tehtiin isoissa yrityksissä, joissa ohjeistus on yleensä olemassa.
Pienemmässä yrityksessä ohjetta ei useinkaan ole, jolloin sitä ei voi rikkoakaan. Kukaan ei myöskään tiedä, mitä on tekeillä. Tämä on varjo-IT:n uusi muoto: ennen se tarkoitti ohjelmia, joita kukaan ei ollut hyväksynyt, nyt se tarkoittaa ohjelmia, joita kukaan ei ole edes nähnyt.
Tekoäly vahvistaa sen, mitä talossa jo on
Samasta DORA-raportista löytyy myös toinen suunta. Tekoälyn käyttö korreloi positiivisesti toimitusnopeuden kanssa ja negatiivisesti toimitusten vakauden kanssa. Raportin tekijät tiivistävät sen näin: tekoäly ei korjaa tiimiä, vaan vahvistaa sitä, mikä siellä jo on. Hyvä tiimi tekee sillä parempaa jälkeä. Sekaisin oleva tiimi tekee sekaisin olevaa nopeammin.
Yrityksessä, joka ei tee ohjelmistoja, sama pätee suoraan. Jos talossa tiedetään, missä asiakastiedot ovat, kuka omistaa mitäkin ja mikä ajaa tuotannossa, työntekijöiden omat työkalut ovat puhdasta hyötyä. Jos ei tiedetä, samat työkalut synnyttävät kymmenen uutta paikkaa, joissa yrityksen tiedot ovat, eikä kukaan osaa luetella niitä.
Kaikkien ei tarvitse osata vibekoodata
Yksi asia jää tässä keskustelussa usein sanomatta. Iso osa ihmisistä ei halua tehdä omia työkaluja eikä opetella sitä, ja se on täysin kelvollinen kanta. Heidän osaamisensa on jotain muuta, ja siitä yritys heille maksaa.
Heille toimiva ratkaisu on saada työkalu joltakin, joka tekee sen kunnolla ja nykyään myös nopeasti, samasta syystä kuin kaikki muutkin. Ero on siinä, että tekijä osaa lukea oman jälkensä, testata sen niillä syötteillä, joita kukaan ei odota, kirjoittaa muistiin, miten se toimii ja korjata sen ensi vuonna.
Tämä muuttaa myös sitä, mitä IT-tuelta kannattaa odottaa. Tuki, joka ymmärtää sekä koodia että tekoälyn nykyisiä rajoja, erottaa toisistaan kolme tapausta: sen, jonka voi päästää läpi sellaisenaan, sen, joka kannattaa tehdä kunnolla, ja sen, joka pitää pysäyttää. Vukon Oy:llä tämä tarkoittaa käytännössä sitä, että sama porukka, joka hoitaa laitteet ja käyttöoikeudet, kirjoittaa myös ne pienet työkalut asiakkaan puolesta silloin, kun se on nopein tie.
Takaisin siihen raporttiin
Se työkalu, joka teki tunnin työn kymmenessä sekunnissa, ansaitsee jäädä käyttöön. Kysymys sen ympärillä on helppo: lukeeko se vai kirjoittaako, onko siinä henkilötietoja, tarvitseeko sitä joku muu ja tietääkö kukaan muu kuin tekijä, mistä sen luvut tulevat.
Neljä kysymystä vie viisi minuuttia. Se on halvempaa kuin se hetki maaliskuussa, kun huomataan, että luku on ollut väärä joulukuusta asti.
Sources
- Veracode: Spring 2026 GenAI Code Security Update (24.3.2026)
- GitClear: The Maintainability Gap – 2026 AI Code Quality Research (tammikuu 2026)
- METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (10.7.2025)
- Google Cloud: 2025 DORA Report – State of AI-assisted Software Development (23.9.2025)
- Fortune: AI coding tool Replit wiped a database and called it a catastrophic failure (23.7.2025)
- PagerDuty: Shadow AI in the Workplace Survey 2026 (11.6.2026)