Miksi valmiit AI-työkalut turhauttavat tiimejä — ja mitä tehdä siitä

Useimmissa teknologioissa on niin, että mitä kauemmin niitä käytetään, sitä enemmän niistä tulee luonnollista. AI-työkaluissa on kuitenkin ollut toisin: Stack Overflown vuosittaisessa kyselyssä yli 49 000 kehittäjälle rekisteröityneistä osallistujista, AI-työkalujen käyttö kasvoi 84 prosenttiin, mutta luottamus näiden työkalujen tarkkuuteen laski 40 prosentista 29 prosenttiin vain yhden vuoden aikana.

Tämä vaikutus on minulle tuttu. Olemme kokeilleet AI-työkaluja kehityksessämme, ja aluksi ne eivät olleet meille mitään ihmeellisiä. Koodi, jonka AI tuotti, oli keskinkertaista, ja sen tarkastaminen vei paljon aikaa. Lopulta koodin oli kirjoitettava uudelleen. Tiimi odotti, että AI säästäisi aikaa, mutta sen sijaan he saivat vain enemmän työtä. Pian ensimmäisten AI-kokeilujen jälkeen tiimi palasi vanhaan tapaan työskennellä.

Nykyään nämä työkalut nopeuttavat koodin kirjoittamista ja tarkastamista kehittäjillemme — ei siksi, että olisimme löytäneet paremman mallin, vaan siksi, että olemme muuttaneet työtapaamme. Tässä on se, mitä auttoi meitä pääsemään tähän pisteeseen.

Miksi AI-koodi turhauttaa kehittäjiä

AI nojautuu valtavaan määrään julkista koodia internetistä, ja tämä koodi on harvoin esimerkkitapauksia: sen laatu on keskinkertainen, ja malli toistaa tämän keskinkertaisuuden.

“Keskinkertainen” ei kuitenkaan ole se, mihin on mahdollista päästä — se on vain se, mitä malli tuottaa, kunnes se tuntee projektisi: sen konventiot, koodirakenteen, arkkitehtuuriset päätökset. Yli 600 kehittäjän kyselyssä Qodo löysi, että niistä, jotka eivät olleet tyytyväisiä AI-koodin laatuun, 44 prosenttia piti sitä johtuvan puutteellisesta kontekstista. Tämä on se, mikä pitää tulokset keskinkertaisella tasolla.

Hyviä uutisia on, että konteksti, jonka AI saa, on ainoa muuttuja, jota tiimi voi täysin hallita. Sen, kuinka hyvin työkalu ymmärtää projektin, ei riipu mallista, vaan siitä, mitä sille syötetään.

Toinen syy on mielentila — työn luonne muuttuu. Kun AI kirjoittaa suurimman osan koodista, kehittäjän päätehtävä ei ole enää koodin kirjoittaminen, vaan sen tarkastaminen, mitä on tuotettu: toisen henkilön ratkaisun lukeminen, vaihtoehtojen punnitseminen, päätöksen tekeminen siitä, mitä on valmis toimitettavaksi. Tämä on eri taito kuin koodin kirjoittaminen itse, ja se ei tule helposti kenellekään, joka on rakastanut koodin kirjoittamisen.

GitHubin vuoden 2025 Octoverse-raportissa kuvataan tarkalleen tämä muutos: kehittäjät, jotka ovat menneet pisimmälle AI:n kanssa, eivät enää kutsu itseään “koodin kirjoittajiksi”, vaan ovat lähempänä “luovia ohjaajia”, joilla avainosaamista on ohjata ja vahvistaa. Mutta tie tähän rooliin kulkee virheiden ja turhautumisen kautta, kunnes henkilö näkee tulokset omassa työssään.

Mikä muuttaa AI:n turhauttavasta työkalusta toimivaksi työkaluksi

Kun tiimimme aloitti AI:n käytön, jotkut kehittäjät työskentelivät Claude Coden, toiset kokeilivat OpenAI Codexia, GitHub Copilottia tai Gemini CLI:ää, ja jokainen työkalu antoi eri tuloksen. Kun päättimme järjestellä tiimin työtä AI:n kanssa, ensimmäinen asia, jonka teimme, oli valita yksi työkalu.

Tämä ei ole vain meidän käytäntö. Otetaan esimerkki Linearin tiimistä: he toimivat “jokainen työskentelee parhaansa mukaan” -periaatteella, kunnes vuoden 2026 alussa he luopuivat tästä lähestymistavasta ja siirtyivät yhtenäiseen työtapaan — karsivat valinnan kahteen AI-työkaluun ja pyysivät kehittäjiä kirjoittamaan koodin ainoastaan näiden työkalujen avulla, ei käsin. Yhtiön mukaan keskimääräinen tuottavuus kasvoi seuraavassa kuussa 30 prosentilla yhdistetyissä PR:issä ja 33 prosentilla tehtävissä, jotka suljettiin kunkin insinöörin osalta.

Tämä sanoo, että jaettu työkalu itsessään ei paranna koodia — se on konfiguroitava: asetettava sääntöjä, jotka määrittelevät, miten koodia kirjoitetaan — mitkä lähestymistavat noudatetaan, mitä vältetään. Sitten tulevat mukautetut taidot tyypillisille projekteille, jotta ei tarvitse selittää samaa asiaa toistuvasti. Lopulta on arvokasta osoittaa agentti olemassa olevaan koodipohjaan: se analysoi, miten projekti on kirjoitettu, ja tuottaa uuden koodin samalla tyylillä, ei geneerisellä tyylillä. Mitä enemmän kontekstia työkalu saa, sitä vähemmän on kirjoitettava käsittäin myöhemmin.

Haasteellisin osa ei kuitenkaan ole tekninen. Siirtymä koodin kirjoittajasta sen arvioijaksi ei tapahdu itsestään — tämä siirtymä tarvitsee apua. Suorin reitti on koulutus ja sertifikaatti. Esimerkiksi meillä kymmenen kehittäjää osallistuu työkalun tarjoajan kumppanusohjelmaan, ja heidän rinnallaan toimii henkilö, joka vastaa työkalun omaksumisesta ja selittää, miksi työkalu tuotti tietyn tuloksen ja miten sitä voidaan korjata.

Kun tiimi työskentelee koordinoitusti, yksi pullonkaula on edelleen arviointi — ja se on arvokasta vahvistaa AI:lla. Agentti käy läpi jokaisen pull-pyynnön ensin ja ottaa haltuunsa ilmiselvät asiat: rutiinivirheet, tyyli, toisto, turvallisuusaukot. Ihmisarvioija ei enää tarkasta kaikkea yleisesti, vaan ainoastaan arkkitehtuuria ja kriittisiä päätöksiä. Vaikutus on havaittavissa jopa niiden yritysten sisällä, jotka rakentavat näitä työkaluja: Anthropicissa, kun tällainen agentti otettiin käyttöön, osuus pull-pyynnöistä, jotka saivat merkittävän arvion, kasvoi 16 prosentista 54 prosenttiin, ja insinöörit erosivat vähemmän kuin 1 prosentilla sen kommentteja.

Meillä tämä lyhensi arviointikierroksen, joka aikaisemmin venyi useiden päivien yli useita kierroksia, ja se vapautti seniori-insinöörit rutiinotyöstä, jättäen heille vain haasteelliset kohdat. Kun työkalu vihdoin alkoi tuottaa tuloksia, jotka eivät vaatineet uudelleenkirjoittamista, luottamus siihen ilmestyi myös.

Missä AI-työkalujen luottamus maksaa itsensä takaisin

Ensisijaisesti — koodin kirjoittamisessa: kun työkalu tuntee projektin ja agentti käsittelee ensimmäisen arvion, tiimi kirjoittaa enemmän ja paremmin samassa ajassa. Meillä AI-työkalut nopeuttivat työtä noin 30–40 prosentilla.

Lisäksi AI on tehnyt uuden työntekijän perehdytyksen helpommaksi. Kun uusi henkilö liittyy projektiin, kokeneella henkilöllä on yleensä vastattava lukuisia kysymyksiä siitä, miten projektin koodi on koottu. Nyt agentti ottaa tämän roolin: jos projekti on hyvin dokumentoitu, uusi työntekijä ohjaa jopa 95 prosenttia näistä kysymyksistä sille eikä kollegoille.

Samoin on dokumentaation kanssa: karkeat arkkitehtuuripiirustukset, jotka aikaisemmin veivät useita tunteja, kirjoitetaan nyt pääosin itse agentin toimesta — noin 80 prosenttia luonnoksesta, jos sille annetaan tarpeeksi kontekstia. Ihmisille jää se, mitä ei ole repositoriossa — päätökset, kompromissit, asiantuntemus.

Yhtä tärkeää on olla rehellisiä AI:n rajoituksista, koska se on se, mikä aiheuttaa pettymyksen ensimmäisestä käyttökerrasta lähtien. AI ei ota vastuuta — ihminen allekirjoittaa lääketieteellisen tai rahoituksellisen datan, ja yritys, ei malli, vastaa vuodosta. Se ei nopeuta integraatioita ith partners, jossa kymmenet tunnit menevät puheluihin ja koordinaatioon. Ulkoisista AI-työkaluista ei ole apua, kun niitä käytetään valmiina ratkaisuna. Koko ero turhautumisen ja hyödyn välillä piilee siinä, mitä rakennetaan sen ympärille: jaettu standardi, projektin konteksti ja kehittäjän uusi rooli.