Järjestelmissäsi on jo sokeita kohtia. Tekoäly vain pahentaa ne.

Vuonna 2022, ennen kuin generatiiviset koodausvälineet olivat osa päivittäistä insinöörityötämme, kirjoitin filosofiastani työkalujen valinnassa. Se on kestänyt paremmin kuin odotin. Silloin väitin, että tulisi aloittaa todellisten ongelmien ratkaisemisesta, tuntea omat heikkoudet ja priorisoida, miten käytät työkaluja, sen sijaan että hyppäisit suoraan mikä tahansa vaikuttavimmalta kuulostava väline ja toivoisit sen toimivan. Tunne itsesi ja tavoitteesi, jotta voit asettaa realistiset odotukset työkaluillesi.

Silloin ajattelin SaaS-hajautumista, ei tekoälyn tuottamaa koodia. Mutta tänään filosofiani on vieläkin kiireellisempi, ja tärkeämpi pitää kiinni.

Monet meistä ovat lukeneet 2025 DORA raportti, joka totesi, että toisin kuin edellisvuonna, tekoälyn käyttöönotto korreloi nyt positiivisesti toimituskapasiteetin kanssa. Sen alla oleva havainto oli, että toimituksen epävakaus jatkoi nousua, ja he testasivat kattavatko nopeuslisäykset sen. Ne eivät. Se vastaa kokemustamme. Tiimimme otti käyttöön agenttisen ohjelmistokehityksen ja havaitsi 48 %:n kasvun toimituskapasiteetissa kahden neljänneksen aikana, jonka jälkeen vakausongelmat kasvoivat 16 %. Kymmenen henkeä on pieni otos, mutta se on myös otos, josta näen koko kuvan, ja malli pysyi.

Tekoälyn käyttöönotto ei enää ole oikeastaan kysymys. Olet joko vasta aloittelemassa tai olet jo syvällä siinä. Ero nyt on, että insinöörijohtajilta odotetaan tekoälyn käyttöönottoa ja myös sen osoittamista, että se tuottaa tulosta. Toimitusjohtaja, hallitus ja talous haluavat tietää, miten optimoida heidän tekoälyinvestointinsa. He kysyvät, ratkaisevatko valitsemasi työkalut todellisia ongelmia tehokkaasti.

Kuilu oli aina olemassa. Tekoäly vain laajensi sen.

Toimitusjohtajana (CTO) vietän suuren osan ajastani keskustellen muiden insinöörijohtajien, asiakkaiden, potentiaalisten asiakkaiden ja kollegojeni kanssa vertaillakseni saavutuksia ja valituksia siitä, mitä koemme tekoälyn kanssa. Kun olen käynyt tarpeeksi näitä keskusteluja, olen alkanut nähdä malleja tekoälyn käyttöönotossa ja sen tuloksissa.

Pääasiallinen havainto ei ole omani. DORA on korostanut tätä kahden vuoden ajan: tekoäly vahvistaa sitä, mitä organisaatiossa jo tapahtuu, sekä vahvuuksia että heikkouksia. Tiimi, jolla on puhdas arkkitehtuuri ja terveet tarkistusrutiinit, nopeutuu. Tiimi, joka on juuri riittävästi käsitellyt monimutkaisen teknisen velan saadakseen koodin julkaistuksi, huomaa nyt, että tekninen velka kasvaa merkittäväksi esteeksi. Mikä kuitenkin puuttuu tästä näkökulmasta, on se, miksi tämä yllättää niin monia tiimejä. Tekoäly ei piilottanut näitä heikkouksia; järjestelmät, joihin olemme luottaneet, eivät koskaan paljastaneet niitä.

Useiden insinööriorganisaatioiden käyttämä tiketti- ja raportointikokonaisuus rakennettiin vastaamaan ihmisten kysymyksiin ihmisen nopeudella, ihmisiltä, jotka ymmärsivät karkeasti, mitä “valmis” tarkoitti kyseisessä työtehtävässä. Se ei koskaan ollut täydellinen kirjaus. Se oli aina likimääräinen, jonka joku täytti tiivistäen alla olevan monimutkaisemman asian. Nyt tekoäly lisää määrää ja tuottaa uusia syötteitä, jotka luovat uutta toimintaa. Mikään näistä järjestelmistä (tai työkaluista), joita perinteisiin, ei‑tekoälymenetelmiin käytettiin, ei koskaan suunniteltu tähän.

Siitä huolimatta olemme yhä vastuussa samoista tavoitteista. Omistat edelleen nopeuden, laadun, kulut ja sen, miten tiimisi todella suoriutuu. Et voi enää ottaa viime vuoden hallintanäkymiä uskomalla niiden olevan oikeita.

Tässä on oikeutettu vastaväite. 2026 ROI -raportti kuvaa J‑käyrän: tuottavuuden laskun heti käyttöönoton jälkeen, jonka aiheuttavat oppimiskäyrä, tekoälyn tuottaman koodin tarkistamisen kustannus ja jälkijonon prosessit, jotka eivät ole vielä mukana. He kutsuvat sitä muutoksen “koulutusmaksuksi”, ja varoittavat johtajia olemaan sekoittamatta sitä epäonnistumiseen. Se on reilua. Mutta koulutusmaksu ja todellinen ongelma näyttävät identtisiltä tiketeistä koostetussa hallintanäkymässä. Jos et pysty erottamaan, missä olet, et ole kärsivällinen. Arvaat.

Meidän on palattava perusasioihin. Tunne itsesi. Tunne tiimisi. Tiedä, mitä ongelmia ratkaiset.

Miten “Know Thyself” -lähestymistapaa voi käyttää tekoälyn kanssa?

Keskusteluistani olen tunnistanut viisi pääaluetta, joissa perinteiset järjestelmät, jotka on rakennettu ihmisten tuottamaan ja raportoimaan työhön, ovat sokeita. Jos jätät ne huomiotta, riskinä on heikkouksiesi vahvistuminen tekoälyn käyttöönoton edetessä.

Sokea kohta 1: Nopeusteatteri

Enemmän committeja ja PR:eja voi tuntua edistyksenä, ja usein se onkin. Tekoäly nostaa molempien määrän automaattisesti. A Stanford tapaustutkimus osoitti, että tekoälyn käyttöönotto nosti PR-määrää 14 %. Mutta mitä et näe, on kuinka suuri osa tästä toiminnasta on ominaisuustyötä, joka julkaistaan, verrattuna ylläpitoon, uudelleentyöstöön tai refaktoroinnin aiheuttamaan vaihteluun, joka ei pysynyt.

Tämän ratkaisemiseksi tarkkaile ominaisuustyön ja ylläpidon välistä jakautumista sekä tarkkaile käyttöönottojen tiheyttä ja läpimenoaikaa oman historiallisen peruslinjan suhteen, ei alan keskiarvoa. Ilman tätä jakautumista raportoit edistystä, jota et voi todellisuudessa perustella.

Sokea kohta 2: Tarkistusvelka

Arviointikapasiteetti ei automaattisesti skaalaudu tuotannon mukana. Vahvistusveroa ei voi nähdä läpikäytävänä vaiheena; se on osa jatkuvaa kustannusta agenttisen kehityksen osalta. A viimeaikainen kysely insinöörijohtajilta toteaa, että 80 % tiimeistä käyttää vähintään 10 % ajastaan tarkasteluun, ja noin yksi kymmenestä käyttää yli 40 %. Tämän kuormituksen alla tiimit heiluvat kasvavan takapakan ja pintapuolisen hyväksynnän välillä, eikä kumpikaan ole todellinen ratkaisu.

Toimituksen rajoite ei enää ole se, kuinka nopeasti koodi kirjoitetaan. Se on kuinka nopeasti ihminen voi todella olla varma, että muutos on oikea, kuinka nopeasti ja tarkasti virheet voidaan havaita ja korjata. Seuraa, miten tarkastuksen kuorma todellisuudessa jakautuu tiimisi kesken; muuten riskinä on ylikuormittaa seniorikehittäjiä, viivästyttää julkaisuja tai aiheuttaa vakavia tuotanto-ongelmia.

Sokea kohta 3: Piilotettu työ

Uudelleenkirjoituksilla ja arkkitehtuurimuutoksilla on tapana piiloutua muiden tikettien sisään, jos ne ylipäätään ilmestyvät tikettijärjestelmään. AI tuottaa enemmän tällaista työtä, ei vähemmän. Agentti ei epäröi koskea kaksitoista tiedostoa yhden virheen korjaamiseksi, kun taas ihminen saattaa pysähtyä ja harkita uudelleen. Työ, joka ohittaa tallennusjärjestelmän, ohittaa myös suunnittelun, mikä tarkoittaa, että kapasiteettimallisi on väärä, ja kaikki sen päälle rakennettu ennuste on myös väärä.

Jotta ymmärtäisit, kuinka paljon työtä todella tehdään, sinun täytyy seurata, kuinka paljon koodikanta ja pull request -historia muuttuvat. Ilman sitä kapasiteettisuunnitelmasi perustuu siihen, mitä ihmiset muistivat kirjata, eikä siihen, mitä he todella tekivät.

Sokea kohta 4: Laadun poikkeama

Sama kysely havaitsi, että lähes puolet insinöörijohtajista kamppailee turvallisuusongelmien havaitsemisessa viikosta toiseen. Monimutkaisuus, duplikaatiot ja riippuvuudet, jotka eivät täysin kuulu, kerääntyvät lukuisten pienten, yksittäin kohtuullisten muutosten aikana. Yksikään niistä ei yksinään vaikuta huolestuttavalta. Samassa Stanfordin tapaustutkimuksessa koodin laatu laski 9 % ja sen vaihtelu yli kolminkertaistui. Vaikka keskiarvo muuttui vähän, hajonta (se osa, jonka huomaat) muuttui paljon. AI‑volyymissa ne kasaantuvat nopeammin kuin useimmat tarkastusprosessit ehtivät napata ne. Poikkeama ilmenee usein hälytyksenä valmiusvalvonnassa, joka jäljittää riippuvuuteen, jota kukaan ei muista tarkastaneen. Silloin on melko todennäköistä, että asiakas on huomannut sen ensin.

Seuraa trendiviivoja turvallisuuslöydöissä, riippuvuuksissa sekä epäonnistumisissa ja palautumisissa – älä keskity yksittäiseen commit‑iin. Monimutkaisuuden ja duplikaatioiden nousu useiden viikkojen aikana on merkittävämpää kuin mikä tahansa tarkastuksessa merkitty muutos. Ilman tätä havaitset poikkeaman samalla tavalla kuin useimmat tiimit: vasta sen jälkeen, kun se on jo aiheuttanut tapahtuman.

Sokea kohta 5: Todistamaton kulutus

Kun tekoälyn käyttöönotto ei enää ole kiistaa, tekoälyn kulutus ja ROI nousevat kaikkien keskeiseksi kysymykseksi. Talous haluaa tietää, mikä on kapitalisoitavaa ja mikä operatiivista. Johto haluaa tietää, mihin investointi on johtanut. Useimmat tiimit tekevät edelleen työkalujen, istuinten ja henkilöstömäärän päätöksiä intuitiosta, eivätkä todisteesta rahojen ja toimitetun työn välisestä yhteydestä.

Seuraa, mihin insinööriresurssit todellisuudessa suuntautuvat koodikannassa kvartaaleittain – älä siihen, mitä tiekartta sanoo niiden suuntaavan. Ilman tätä yhteyttä puolustat ensi vuoden budjettia anekdooteilla, eikä anekdootit kestä kovaa keskustelua talousjohtajan kanssa.

Aloita siitä, mitä et näe

Talouden kysymys kapitalisoidusta kulutuksesta ja valmiusvalvonnan sivu klo 2 aamulla vaikuttavat erillisiltä, mutta eivät ole. Molemmat voidaan “arvioida” toiminnasta. Mutta molempiin on todellakin mahdollista vastata todisteiden perusteella suoraan koodista.

DORAn vastaus kaikkeen tähän on itse insinöörijärjestelmä: alustan laatu, työnkulun selkeys, tiimin yhtenäisyys. Se on totta, mutta se ei myöskään ole ensimmäinen askel. Et voi korjata järjestelmää, jota et näe. Jokainen näistä viidestä alueesta on jotain, mitä sinun täytyy pystyä havainnoimaan ennen kuin voit perustella siihen investoinnin.

Ensimmäinen hyödyllinen askel ei ole uusi työkalu tai uusi prosessi. Se on tuntea itsensä rehellisesti ja määrittää, mitkä näistä viidestä alueesta ovat sokeita kohtia, joissa puuttuu todellinen näyttö. Useimmat johtajat pystyvät heti tunnistamaan (ja kiinnittävät huomiota) ongelmiin yhdessä näistä alueista. Kuitenkin juuri ne alueet, joista sinulla on vähiten tietoa, todennäköisimmin nousevat esiin ja aiheuttavat ongelmia, kun jatkat tekoälyn käyttöönottoa.