Generointibuumi ei tuonut mukanaan nopeusbuumia

Generointibuumi ei tuonut mukanaan nopeusbuumia

Tässä on paradoksi, jota kukaan AI-koodaustyökaluja myyvä ei halua mainostaa: tiimit generoivat enemmän koodia, nopeammin, mutta toimitusnopeus ei ole parantunut suhteessa samassa määrin. Agodan insinööritiimi dokumentoi tämän suoraan — huolimatta laajasta AI-koodausassistenttien käyttöönotosta, kokonaistoimitusnopeus ei parantunut odotetusti, koska pullonkaula yksinkertaisesti siirtyi ylävirtaan [3].

Se siirtyi kysymyksestä "kuinka nopeasti tämä voidaan kirjoittaa" kysymykseen "mistä tiedämme, että tämä on oikein, ja miten määrittelemme, mitä 'oikein' tarkoittaa riittävän täsmällisesti, jotta malli osuu siihen." Tämä ei ole työkaluongelma. Se on ajatteluongelma, eikä sitä saada automatisoitua pois paremmalla automaattisella täydennyksellä.

Stanfordin 2026 AI Index -raportti tallensi puhtaan kyvykkyyshypyn: SWE-bench Verified -pisteet nousivat 60 prosentista lähes 100 prosenttiin lyhyessä ajassa [6]. Mallit ovat äärimmäisen hyviä ratkaisemaan hyvin määriteltyjä ongelmia. Ongelma on siinä, että useimmat todelliset insinöörityön ongelmat saapuvat huonosti määriteltyinä — täynnä implisiittisiä oletuksia, dokumentoimattomia reunatapauksia ja organisatorista kontekstia, joka elää jonkun päässä, ei tiketissä.

Tämä on jälki-koodiajan ydinoivallus: suoritus lakkasi olemasta niukka resurssi. Harkintakyky ei lakannut. Malli, joka ratkaisee SWE-benchin lähes 100 prosentin tarkkuudella, on silti vain niin hyvä kuin sille annettu ongelma. Roskaa sisään huonosti määriteltynä, itsevarman väärää koodia ulos — vain nopeammin kuin ennen.

Verifiointikuilu on se, missä yritykset vuotavat verta

Jos on olemassa yksi tilasto, jonka pitäisi suunnata uudelleen tiimisi tämän vuoden työskentelytapaa, se on tämä: 62 % tiimeistä toimittaa AI-generoitua koodia ilman riittävää verifiointia [2]. Tämä ei ole reunatapaus — tämä on enemmistön käytös, tapahtuu juuri nyt, laajassa mittakaavassa.

Yhdistä tähän tietoturvadata. Veracode havaitsi, että 45 % AI-generoidusta koodista sisältää tietoturva-aukkoja [8]. Cloud Security Alliance ja Endor Labs asettavat luvun vielä korkeammalle — 62 prosentissa AI-generoidusta koodista on jonkinlaisia suunnitteluvirheitä tai haavoittuvuuksia [4]. Nämä eivät ole hypoteettisia riskejä; ne ovat sisäänrakennettuja useimpien yritysten nykyiseen oletustyönkulkuun, kun ne yhä kohtelevat AI-koodin generointia samalla tavalla kuin autotäydennystä — tuottavuusominaisuutena eikä uutena riskiluokkana, joka vaatii uudenlaista kontrollia.

Kuvio on johdonmukainen kaikissa vakavissa vuoden 2026 insinöörityödatan analyyseissä: AI-generoitu koodi näyttää siistiltä ja lukee sujuvasti, mikä tekee siitä vaarallisempaa, ei vähemmän vaarallista [2][8]. Katselmoijat hyväksyvät sen nopeammin, koska se on hyvin muotoiltua ja pinnallisesti johdonmukaista. Virheet, joilla on merkitystä — logiikkavirheet tietyissä olosuhteissa, tietoturvaoletukset, jotka eivät pidä paikkaansa, arkkitehtuuripäätökset, jotka eivät skaalaudu — ovat juuri niitä asioita, jotka nopea, mallintunnistukseen perustuva katselmointi jättää huomaamatta.

Tämän vuoksi 96 % insinöörityön johtajista sanoo nyt priorisoivansa havainnointi-investointeja (observability) [4]. Kun et voi luottaa siihen, että generointiprosessi korjaa itse itseään, investoit havaitsemiseen jälkikäteen. Se on vero, joka maksetaan harkinnan ohittamisesta alkupäässä, ja se maksetaan valvontainfrastruktuurina loppupäässä.

Mitä "harkintakyky" oikeasti tarkoittaa (se ei ole fiilispohjainen käsite)

"Harkintakyky" uhkaa muuttua yhdeksi niistä sanoista — kuten "synergia" tai "linjaus" — jotka kuulostavat tärkeiltä mutta eivät tarkoita mitään operatiivisesti. Olkaamme siis täsmällisiä, sillä lähteet lähestyvät melko konkreettista määritelmää.

Harkintakyky, jälki-koodikontekstissa, jakautuu neljään osa-alueeseen:

Tarkoituksen määrittely — kyky kääntää liiketoimintaongelma täsmälliseksi, testattavaksi tekniseksi spesifikaatioksi, joka jättää mahdollisimman vähän tilaa mallin arvailla väärin. Tämä muistuttaa enemmän lakisopimuksen kirjoittamista kuin proosan kirjoittamista. Epäselvyyden, jonka ihmiskollega ratkaisisi hiljaisesti jaetun kontekstin avulla, malli ratkaisee tilastollisesti lähimmän kaavan perusteella — mikä voi olla kaukana siitä, mitä tarkoitit.

Tulosten arviointi — generoidun koodin lukeminen ei sen pohtimiseksi "vaikuttaako tämä uskottavalta", vaan sen pohtimiseksi "kestääkö tämä olosuhteissa, joista todella välitän." Harvard Business Review'n muotoilu, johon vuoden 2026 analyyseissä laajasti viitataan, on suorasanainen: AI vahvistaa olemassa olevaa harkintakykyä; se ei luo sitä [5]. Vanhempi insinööri, jolla on vahva arviointivaisto, saa dramaattisesti enemmän vipuvaikutusta AI-työkaluista kuin nuorempi kollega — työkalu on voimavaikuttaja sille harkintakyvylle, jonka tuot mukanasi, ei korvike harkintakyvylle, jota sinulla ei ole.

Arkkitehtuuriset kompromissit — päätökset järjestelmän rajapinnoista, kytkennöistä, tietomalleista ja vikatiloista, jotka määrittävät, pysyykö koodikanta ylläpidettävänä kuukauden 18 kohdalla, ei vain demopäivänä. AI-työkalut ovat paikallisesti erinomaisia ja globaalisti välinpitämättömiä — ne generoivat mielellään funktion, joka ratkaisee tämän päivän tiketin, samalla kun ne hiljaisesti vaikeuttavat ensi vuosineljänneksen refaktorointia.

Vastuunkanto — jonkun on omistettava päätös julkaisemisesta. Useat vuoden 2026 analyysit (Metacto, Mediumin IT Chronicles) osoittavat tämän vähiten automatisoitavaksi kerrokseksi: ei itse teknistä harkintaa, vaan halukkuutta olla nimi, joka liitetään päätökseen [4][5]. AI:ta ei potkita tuotantokatkoksesta. Jonkun on silti oltava se henkilö, joka päätti, että tämä oli valmis.

Huomaa, mikä puuttuu tästä listasta: kirjoitusnopeus, syntaksin muistaminen, boilerplate-tuttuus. Nämä olivat taitoja, joiden ympärille ala käytti 20 vuotta optimoiden rekrytointiputkiaan. Nyt ne ovat parhaimmillaankin perusvaatimuksia, pahimmillaan merkityksettömiä.

Mikä oikeasti toimii: harmaan laatikon malli

Agodan insinöörityöorganisaatio tarjoaa yhden hyödyllisimmistä konkreettisista malleista, jotka ovat nousseet esiin tästä muutoksesta, ja se kannattaa ottaa suoraan käyttöön [3].

Heidän lähestymistapansa hylkää molemmat ääripäät. Valkoisen laatikon lähestymistapa — jokaisen AI:n generoiman rivin katselmointi ikään kuin olisit kirjoittanut sen itse — mitätöi koko AI:n käytön tarkoituksen; maksat kirjoittamisen kognitiivisen hinnan ilman hyötyä siitä, ettei sinun tarvitse kirjoittaa itse. Mustan laatikon lähestymistapa — tulosteeseen luottaminen, koska testit menevät läpi ja diffi näyttää järkevältä — on tapa, jolla päädyt New Relicin 78 prosentin lisäesiintymälukuun.

Harmaan laatikon lähestymistapa asettuu näiden väliin: et katselmoi jokaista tokenia, mutta rakennat harkittuja tarkistuspisteitä, joissa ihmisen harkintakyky vaaditaan rakenteellisesti ennen kuin koodi etenee. Konkreettisesti tämä näyttää tältä:

• Spesifikaatio ensin -generointi: AI työskentelee yksityiskohtaisen, ihmisen kirjoittaman spesifikaation pohjalta löyhän kehotteen sijaan, jolloin epäselvyys ratkaistaan ennen generointia, ei sen jälkeen.
• Verifiointisilmukat oletusarvona, ei jälkiajatuksena: automaattinen testien generointi yhdistettynä pakolliseen ihmisen tarkistukseen kaikessa, mikä koskettaa tietoturvarajoja, tietojen eheyttä tai ulkoisia riippuvuuksia.
• Nimenomainen omistajuus per artefakti: jonkun nimi liitetään yhdistämispäätökseen riippumatta siitä, kuka — tai mikä — koodin kirjoitti.
• Havainnointi turvaverkkona sille, mitä katselmointi ohittaa: koska 96 % johtajista investoi jo tähän, kohtele valvontaa ei mukavana lisänä vaan toisena puolustuslinjana, jota katselmointiprosessisi tulee tarvitsemaan [4].

Tämä ei ole prosessia prosessin vuoksi. Se on suora vastaus siihen, missä data kertoo epäonnistumisen todella tapahtuvan — ei generoinnissa, vaan generoinnin ja julkaisun välisessä kuilussa.

Taitojen markkina hinnoittelee itseään uudelleen reaaliaikaisesti

Jos harkintakyky on uusi niukka resurssi, rekrytoinnin ja tiiminrakentamisen pitäisi jo siirtyä sen suuntaan. Jotkin edistyksellisemmistä organisaatioista tekevät juuri näin — mutta laajempi markkina laahaa perässä, käyttäen yhä työnkuvia, jotka on optimoitu kehysten tuntemuksen ja X-vuoden-kokemuksen mukaan, juuri niiden signaalien, joiden arvo romahtaa.

Epämukava seuraus yksittäisille insinööreille: arvosi ei ole enää suhteessa siihen, kuinka paljon koodia pystyt tuottamaan. Se on suhteessa siihen, kuinka hyvin pystyt määrittelemään ongelmia, arvioimaan epäselvää tulostetta epävarmuuden vallitessa ja tekemään arkkitehtuuripäätöksiä, jotka kestävät kuukausia myöhemmin. Näitä on vaikeampi opettaa, vaikeampi haastatella, ja — ainakin toistaiseksi — paljon vaikeampi väärentää AI-avusteisten sivuprojektien portfoliolla.

Tiimeille ja perustajille seuraus on vielä terävämpi. Jos rekrytointisi, ylennyskäytäntösi ja prosessisuunnittelusi optimoivat yhä suoritusnopeutta, optimoit sitä asiaa, josta juuri tuli hyödyke muiden joukossa. SonarSourcen kehityskaari — 42 % tänään, yli 21 % kasvua vuoteen 2027 mennessä — tarkoittaa, ettei tämä ole tilapäinen häiriö, jota voi odotella ohi [7]. Se osuus koodista, jota organisaatio ei itse suoraan kirjoita, kasvaa vain. Voittavat organisaatiot eivät ole niitä, jotka generoivat eniten koodia nopeimmin. Ne ovat niitä, joilla on tiukin harkintasilmukka koodin ympärillä, jonka tuottaminen on jo halpaa.

Suurempi muutos: mikä muuttuu, kun AI rakentaa ohjelmiston

Astu askel taaksepäin, niin kuvio on suurempi kuin pelkkä insinöörityöprosessi. Se on koko ohjelmistopinon arvon uudelleenjakautumista.

Kahden vuosikymmenen ajan niukka resurssi oli kyky kääntää ideat toimivaksi koodiksi — siitä johtui kehittäjähenkilöstön ylihinta, bootcamp-talous, "opi koodaamaan" -kulttuurinen hetki. Tuo niukkuus liukenee reaaliaikaisesti, näkyvissä raakoina prosentteina: 42 % tänään, ennustetusti yli 60 % vuoteen 2027 mennessä SonarSourcen kehityskaaren mukaan [7], Googlen ollessa jo 75 prosentissa [1]. Suorituksesta on tullut runsasta.

Se, mikä on runsasta, lakkaa olemasta arvokasta. Se, mikä pysyy niukkana — täsmällinen ongelmanmäärittely, tiukka arviointi epävarmuuden vallitessa, arkkitehtuurinen ennakointi ja halukkuus omistaa päätös — muodostaa koko pelin. Tämä ei ole ainutlaatuista ohjelmistoalalle sen enempää kuin muuallekaan; se on sama kuvio, joka toistuu aina, kun tuotannon pullonkaula automatisoidaan. Rajoite ei katoa. Se siirtyy sinne, mitä ei vielä ole automatisoitu.

Up North AI:ssa rakennamme orkestrointi- ja äänitekoälyjärjestelmiä päivittäin juuri tällä oletuksella: koodi on helppo 20 %. Spesifikaatio, arviointikehys (eval harness), ihmisen tarkistuspiste ennen kuin jokin koskettaa tuotantoa — siellä varsinainen insinöörityö nyt tapahtuu, ja siihen käytämme suunnittelupanoksemme. Tiimit, jotka yhä organisoituvat kysymyksen "kuka pystyy kirjoittamaan tämän nopeimmin" ympärille, optimoivat resurssia, jonka rajakustannus lähestyy nopeasti nollaa.

Koodi on ilmaista. Harkintakyky ei ole. Organisaatiot, jotka kohtelevat tätä iskulauseena, menettävät jalansijaa niille, jotka kohtelevat sitä toimintaperiaatteena.

Sources

1. https://uvik.net/blog/ai-code-generation-statistics/
2. https://newrelic.com/resources/report/2026-state-of-ai-coding
3. https://www.infoq.com/news/2026/03/agoda-ai-code-bottleneck/
4. https://www.metacto.com/blogs/judgment-definition-bottlenecks-ai-era
5. https://medium.com/it-chronicles/the-judgment-bottleneck-software-engineering-in-the-age-of-ai-f0fd5cffb57e
6. https://hai.stanford.edu/ai-index/2026-ai-index-report
7. https://www.sonarsource.com/state-of-code-developer-survey-report.pdf
8. https://antoniopagano.com/blog/code-review-ai-assisted-era/