Pullonkaula ei kadonnut, se siirtyi

Pullonkaula ei kadonnut, se siirtyi

Kahdenkymmenen vuoden ajan ohjelmistokehityksen nopeutta rajoittivat kirjoitusnopeus, syntaksin osaaminen ja se raadanta, jota aikomusten kääntäminen toimivaksi koodiksi vaati. Tekoälyavusteiset koodausassistentit murskasivat tuon rajoitteen. Käyttöönotto on nyt 84–91 % ammattikehittäjien keskuudessa [4][5], ja työn mekaanisten osien — boilerplate-koodin, runkorakenteiden, testipohjien, syntaksin tarkistamisen — osalta parannus on todellinen eikä kiistanalainen.

Mutta laajasti siteerattu InfoQ:n vuoden 2026 analyysi Agodan kehitystiimeistä havaitsi, että tekoälyavusteiset koodausassistentit eivät ole todellisuudessa nopeuttaneet toimitusta, koska rajoite ei koskaan ollutkaan kirjoittaminen [3]. Se oli varmentaminen. Se oli sen päättäminen, miltä "hyvä" näyttää. Se oli ne sata pientä harkintaan perustuvaa päätöstä, jotka tehdään sen jälkeen kun koodi on olemassa: kunnioittaako tämä tietomalliamme, syntyykö tästä teknistä velkaa kuuden kuukauden kuluttua, onko tämä kompromissi järkevä juuri tälle tuotteelle.

Madronan vuoden 2026 haastattelut tuote- ja kehitysjohtajien kanssa päätyivät itsenäisesti samaan diagnoosiin: kun kirjoittamisen pullonkaula poistetaan, ohjelmistokehitys ei nopeudu — sen sijaan paljastuu seuraava pullonkaula, joka oli aina olemassa, vain piilossa hitaamman pullonkaulan takana [7]. Yksi lainaus tästä tutkimuksesta tiivistää asian täsmällisesti: "Tekoäly on tasoittanut tuon pullonkaulan ja paljastanut sen, mikä on aina ollut todellinen rajoite: insinöörin harkintakyky."

Tämä ei ole vähäpätöinen uudelleenmuotoilu. Se muuttaa sitä, mihin palkataan, mitä mitataan ja minkä ympärille työkaluja rakennetaan.

Luottamuksen romahdus, josta kukaan ei puhu

Tässä on tietopiste, jonka pitäisi huolestuttaa jokaista tiimiä, joka nojaa vahvasti "tekoäly ensin" -kehitykseen: luottamus tekoälyn tuottaman koodin tarkkuuteen laski 29 %:iin, eli 11–14 prosenttiyksikköä vuositasolla, samalla kun käyttöönotto nousi yli 90 %:iin [4][5].

Lue tuo uudelleen. Yhä useampi kehittäjä käyttää tekoälyä koodin kirjoittamiseen. Yhä harvempi heistä luottaa siihen, mitä se kirjoittaa. Tämä ei ole ristiriita — se on harkintatalouden ilmoittautuminen. Kehittäjät ovat oppineet suoran kokemuksen kautta, että tekoälyn tuottama koodi vaikuttaa uskottavalta paljon useammin kuin se on oikein. Kuilu sen välillä, että koodi "kääntyy ja läpäisee demon" ja että se "on todella oikein", tasoittui aiemmin saman henkilön toimesta, joka kirjoitti koodin, iteratiivisesti, rakentaen samalla ymmärrystä. Nyt tuon kuilun täytyy tasoittua jonkun toisen toimesta, jälkikäteen, vähäisemmällä kontekstilla.

Vaihtuvuusluvut vahvistavat tämän. Tekoälyn tuottama koodi vaihtuu — kirjoitetaan uudelleen, palautetaan tai muokataan merkittävästi — 1,8–2,5 kertaa nopeammin kuin ihmisen kirjoittama koodi, ja ainakin yksi analyysi osoittaa vaihtuvuuden nousevan jopa 9-kertaiseksi tietyissä koodikannoissa [8]. Testikattavuus usein paranee tämän ohella, mikä on ainoa aidosti hyvä sivuvaikutus. Mutta suuri vaihtuvuus on signaali, ei kohinaa: se tarkoittaa, että koodia tuotetaan nopeammin kuin sitä ymmärretään, ja ymmärtäminen on juuri sitä, mitä harkintakyky vaatii.

Ydinajatus rakentajille: jos tiiminne vaihtuvuusaste nousee tekoälyn käyttöönoton myötä, kyse ei ole tuottavuusmittarin ongelmasta — se on merkki siitä, että varmentamiseen ei ole varattu riittävästi resursseja suhteessa tuottamiseen. Seuratkaa koodin vaihtuvuusastetta erikseen laatumittarina, ei pelkästään nopeusmittarina [8].

Mitä "harkintakyky" oikeasti tarkoittaa käytännössä

Tässä kohtaa keskustelu yleensä muuttuu epämääräiseksi, joten tehdään siitä konkreettinen. Omassa työssämme puheentunnistus-tekoälyn ja orkestrointijärjestelmien parissa "harkintakyky" jakautuu viiteen toistuvaan päätöskategoriaan, joita tekoälytyökalut eivät johdonmukaisesti pysty tekemään itsenäisesti:

Arkkitehtoninen yhteensopivuus. Tekoäly osaa tuottaa toimivan ratkaisun lähes mihin tahansa hyvin määriteltyyn ongelmaan. Se ei kuitenkaan pysty kertomaan, sopiiko kyseinen ratkaisu olemassa olevan järjestelmänne rajoitteisiin, tiiminne toiminnalliseen kypsyyteen tai viiden vuoden tiekarttaanne. Tämä vaatii kontekstia, jota mallilla ei ole eikä se pysty päättelemään pelkästä kehotteesta.

Velkaan liittyvät kompromissit. Jokainen koodinpätkä on veto — nopeus nyt versus ylläpidettävyys myöhemmin. Tekoäly noudattaa oletuksena mitä tahansa tilastollisesti yleistä mallia sen koulutusdatassa, ei sitä, mikä on oikein teidän riskinsietokyvyllenne. Fintech-startupin ja viikonlopun hackathon-projektin ei pitäisi tehdä samoja kompromisseja, eikä tekoälyllä ole mitään mekanismia tietääkseen, kumpaa se palvelee.

Yksityisyyden ja tietoturvan vivahteet. Nämä ovat juuri niitä kategorioita, joita GitHubin viittaama tutkimus merkitsee edelleen ihmisen tarkastusta vaativiksi, päiviä prosessin käynnistymisen jälkeen, riippumatta siitä kuinka nopeasti koodi tuotettiin [1]. Tekoäly pystyy tunnistamaan tunnettuja haavoittuvuuksia kaavamaisesti. Se ei pysty päättelemään teidän erityistä sääntelyriskiänne, erityistä käyttäjäkuntaanne tai sitä erityistä tapaa, jolla näennäisesti viaton kenttä saattaa myöhemmin päätyä väärinkäytetyksi.

Määrittelyn laatu. Roskaa sisään, uskottavan näköistä roskaa ulos. Tällä hetkellä ainoa vaikuttavin taito tekoälyavusteisessa kehityksessä on kirjoittaa määrittely, joka on riittävän tarkka, jotta tekoälyn tuotos on todella käyttökelpoinen ilman raskasta korjaamista. Tämä on harkintaan perustuva taito, ei koodaustaito — se muistuttaa enemmän tuoteajattelua kuin syntaksia.

Integraatio ja koordinointi. Yksittäiset funktiot voidaan tuottaa tekoälyllä loistavasti, ja silti ne saattavat yhdistyä järjestelmäksi, joka ei toimi yhtenäisesti. Jonkun täytyy pitää koko kokonaisuus mielessään. Tämä ei ole tehtävä, jonka voi pilkkoa kehotteeksi.

Yajin Zhangin laajasti levinnyt essee tekoälyajan insinöörityöstä esittää saman asian suoraan: kehittäjät, jotka menestyvät, eivät ole niitä, jotka pystyvät tuottamaan eniten koodia, vaan niitä, joilla on syvin tekninen harkintakyky sen suhteen, mitä ei pitäisi rakentaa tai mitä pitäisi rakentaa toisin [2]. Tämä on epämukava viesti kulttuurille, joka on kahden vuosikymmenen ajan optimoinut tuotannon määrää.

Uudet niukat taidot — ja keillä ne todella on

Madronan tutkimus, joka perustuu 49 kehitys- ja tuotejohtajan haastatteluihin, päätyy lyhyeen listaan piirteitä, jotka nyt erottavat huippusuorittajat muista: tuoteosaaminen, uteliaisuus, oma-aloitteisuus ja harkintakyky [7]. Huomatkaa, mikä puuttuu tästä listasta — raaka koodausnopeus, kehysten ulkoa opettelu, syntaksin sujuvuus. Nämä ovat nyt hyödykemäisiä taitoja, ja niiden hinta on sen mukainen.

GitClearin kohorttianalyysistä löytyy tähän liittyvä ja hieman intuition vastainen havainto: tekoälyavusteisia koodaustyökaluja ottavat käyttöön ja käyttävät tehokkaasti suhteettoman paljon jo entuudestaan vahvat suoriutujat, ei niinkään heikompien tasoittavana mekanismina [6]. Tämä haastaa suositun kertomuksen siitä, että tekoäly demokratisoi ohjelmistokehityksen antamalla kenen tahansa tuottaa senioritason koodia. Se, mitä todellisuudessa tapahtuu, on että vanhemmat kehittäjät käyttävät tekoälyä vahvistaakseen jo olemassa olevaa harkintakykyään, kun taas kokemattomammat kehittäjät tuottavat enemmän koodia, jota he ovat huonommin varustautuneita arvioimaan.

Tällä on suora organisatorinen seuraus: tekoäly kasvattaa kuilua vahvan harkintakyvyn omaavien insinöörien ja niiden välillä, joilla sitä ei ole, sen sijaan että se kaventaisi kuilua. Jos rekrytointi- ja ylennyskriteerinne painottavat edelleen vahvasti "osaa kirjoittaa koodia nopeasti", optimoitte taitoa, jonka arvo laskee nopeasti, ja aliarvioitte taitoa — harkintakykyä — josta on tulossa todellinen rajoite.

Perustajille tämä muuttaa sitä, miltä kevyen tiimin pitäisi näyttää. Kolmen hengen startup voi nyt tuottaa raakaa koodimäärää enemmän kuin kahdenkymmenen hengen tiimi vuonna 2019. Mutta tämä muuttuu hyväksi tuotteeksi vain, jos jollakin kolmen hengen tiimistä on riittävän vahva harkintakyky tietääkseen, mitä karsia, mitä tarkistaa kahdesti ja mihin ei koskaan päästä tekoälyä käsiksi ilman valvontaa.

Käytännön mallit: miten tiimit todella hallitsevat tätä

Tiimit, jotka hoitavat tämän hyvin, eivät hylkää tekoälytyökaluja eivätkä teeskentele, ettei luottamusongelmaa olisi olemassa. Ne rakentavat eksplisiittisiä rakenteita uuden pullonkaulan ympärille. Muutama malli, joka kannattaa omaksua:

Porrastettu katselmointi vaikutusalueen, ei koodimäärän mukaan. Sen sijaan että jokaista PR:ää katselmoitaisiin samalla tarkkuudella, tiimit priorisoivat seurausten mukaan: käyttöliittymän tekstimuutos saa kevyen kosketuksen, maksuihin liittyvä muutos tai mikä tahansa autentikointiin koskettava muutos saa täyden ihmisen tarkastuksen riippumatta siitä kuinka "pieneltä" diffi näyttää. Tämä vastaa suoraan havaintoon, jonka mukaan yksityisyyteen, velkaan ja kompromisseihin liittyvät päätökset pysyvät itsepintaisesti ihmisen portitettavina [1].

Määrittelylähtöiset työnkulut. Sen sijaan, että tekoälyä kehotettaisiin ad hoc -periaatteella, kurinalaiset tiimit kirjoittavat lyhyen määrittelyn — rajoitteet, reunatapaukset, mitä "valmis" tarkoittaa — ennen kuin mitään tuotetaan. Tämä siirtää työn painopisteen aikaisemmaksi, missä se on halvempaa, sen sijaan että se siirtyisi myöhemmäksi hitaaseen, luottamusta murentavaan katselmointikierrokseen. Se myös tuottaa artefaktin, joka nopeuttaa katselmointia, koska katselmoijat voivat verrata tuotosta määrittelyyn sen sijaan, että he yrittäisivät päätellä alkuperäistä aikomusta jälkikäteen.

Tulosperusteiset mittarit nopeusmittareiden sijaan. Useat vuoden 2026 lähteet viittaavat samaan muutokseen: tiimit siirtyvät pois "koodirivien määrästä" tai "yhdistettyjen PR:ien määrästä" kohti mittareita kuten koodin vaihtuvuusaste [8], virheiden pääsyaste tuotantoon ja aika luotettuun yhdistämiseen. Nopeus on aina ollut sijaismittari; nyt kun rajoite on siirtynyt harkintakykyyn, se on harhaanjohtava sijaismittari.

Eksplisiittinen ihmisomistajuus "valvomattomille alueille". Parhaat tiimit, joita olemme nähneet, vetävät tiukan rajan: tietyt päätöskategoriat — tietojen säilytys, autentikointivirrat, mikä tahansa sääntelyriskiin koskettava — eivät koskaan mene tuotantoon ilman nimettyä ihmisen hyväksyntää, riippumatta siitä kuinka luottavaiselta tekoälyn ehdotus näyttää. Tämä ei ole byrokratiaa byrokratian vuoksi; se on suora vastaus luottamuksen romahtamista koskevaan dataan [4][5].

Hybridityönkulut, joissa tekoäly toimii ihmisen määrittelemien rajoitteiden sisällä. Tämä on malli, jota käytämme sisäisesti Up North AI:ssa kaikissa puhe- ja orkestrointituotteissamme: ihmiset määrittelevät rajat, invariantit ja hyväksyttävän kompromissitilan etukäteen; tekoäly toimii vapaasti tuon tilan sisällä; ihmiset tarkastavat vain rajapinnoilla. Tämä on työnjako, joka vastaa kummankin osapuolen todellista vahvuutta.

Mikä muuttuu, kun tekoäly rakentaa ohjelmistoja

Ottakaa askel taaksepäin, ja muutos on suurempi kuin pelkkä työnkulun hienosäätö. Ensimmäistä kertaa sen jälkeen kun "ohjelmisto syö maailman" muuttui kliseeksi, ohjelmistokehityksen rajoite ei ole tekninen. Se on harkintakyky — selvästi inhimillinen, selvästi skaalautumaton resurssi, ainakin nykyisellä tekoälyllä.

Tällä on todellisia seurauksia. Kilpailuedusta lakkaa olemasta "kuka voi palkata eniten insinöörejä" ja siitä tulee "kuka on koonnut terävimmän kollektiivisen harkintakyvyn". Pienet tiimit, joilla on erinomainen maku, voivat nyt aidosti verkittää keskikertaista makua omaavia suurempia tiimejä, koska niiden välinen toteutuskuilu on romahtanut. Se on rehellisesti sanoen hyvin pohjoismainen etu — pienet, korkean luottamuksen tiimit, joilla on vahva jaettu konteksti, ovat aina suoriutuneet kokoaan paremmin, ja tämä trendi palkitsee juuri sellaista rakennetta.

Se tarkoittaa myös, ettei seuraava työkaluaalto koske entistä enemmän koodin tuottamista entistä nopeammin. Se ongelma on ratkaistu. Seuraava aalto koskee harkintakyvyn skaalautuvaksi tekemistä — parempia varmennusjärjestelmiä, parempia rajoitekieliä, parempia tapoja koodata "miltä hyvä näyttää" niin, että se voidaan tarkistaa automaattisesti sen sijaan, että luotettaisiin väsyneeseen ihmiskatselmoijaan perjantaina kello 18. Se on todellinen rintama, ja siihen me panostamme.

Koodista oli aina tuloillaan halpaa. Kukaan, joka työskenteli tämän muutoksen etulinjassa, ei yllättynyt siitä. Kiinnostavampaa, ja vähemmän puhuttua on se, ettei halpa koodi tehnyt ohjelmistojen hyvästä rakentamisesta helpompaa — se vain teki ensimmäistä kertaa vuosikymmeniin selväksi, ettei koodin kirjoittaminen koskaan ollut se vaikea osa.

Koodi on ilmaista. Harkintakyky ei ole. Data on samaa mieltä kanssamme.

Sources

1. https://www.logilica.com/blog/the-shifting-bottleneck-conundrum-how-ai-is-reshaping-the-software-development-lifecycle
2. https://yajin.org/blog/2026-03-25-real-engineers-ai-era/
3. https://www.infoq.com/news/2026/03/agoda-ai-code-bottleneck/
4. https://www.digitalapplied.com/blog/ai-coding-adoption-statistics-2026-50-data-points
5. https://uvik.net/blog/ai-coding-assistant-statistics/
6. https://gitclear-public.s3.us-west-2.amazonaws.com/Developer_Cohort_Analysis_AI_Coding_Output.pdf
7. https://www.madrona.com/on-to-the-next-bottleneck-what-product-engineering-leaders-told-us-about-ai-in-software-development/
8. https://larridin.com/developer-productivity-hub/code-turnover-rate-ai-quality-metric