80/20-käänne, johon kukaan ei osannut varautua

80/20-käänne, johon kukaan ei osannut varautua

Vuosikymmenten ajan kehittäjän työpäivä jakautui suunnilleen näin: 80 % koodin kirjoittamista ja virheenkorjausta, 20 % kaikkea muuta — suunnittelua, katselmointia, arkkitehtuuria. Tekoälyagentit ovat kääntäneet tämän suhteen ympäri, ja nopeasti. CIO:n vuoden 2026 raportointi agenttipohjaisista kehitystyönkuluista kuvaa tiimejä, joissa tekoäly hoitaa suurimman osan toteutuksesta, kun taas kehittäjät siirtyvät tarkoituksen määrittelyyn, suojakaiteiden asettamiseen ja tuotoksen arviointiin [4].

Kyse ei ole siitä, että kehittäjät kävisivät tarpeettomiksi — kehittäjistä tulee sen sijaan editoreita, arkkitehtejä ja tuomareita kirjoituskoneiden sijaan. Backslash Securityn analyysi tekoälyvetoisesta ohjelmistokehityksen elinkaaresta (SDLC) sanoittaa tämän suoraan: uusi kehittäjän rooli keskittyy validointiin ja strategiseen suunnan näyttämiseen, ei rivi riviltä tapahtuvaan tuotantoon [5]. Henkilö, jota aiemmin arvioitiin viikoittaisten commitien määrällä, arvioidaan nyt sen perusteella, tekeekö ohjattu järjestelmä todella sen, mitä liiketoiminta tarvitsee — turvallisesti.

Epämukava puoli on se, että tämä käänne rankaisee tiimejä, jotka eivät ole päivittäneet työtapojaan. Jos katselmointiprosessi on rakennettu ihmisten tahtiin etenevälle koodille (muutama pull request päivässä, joita väsynyt seniori-insinööri katselmoi kello 16), se murtuu heti tekoälyagenttien edessä, jotka voivat tuottaa viikon edestä koodia iltapäivässä. Läpimenoaika kasvoi. Harkintakyky ei ole kasvanut samassa tahdissa — ei vielä.

Harkintakyky uutena niukkana resurssina

Tänä vuonna rakentajien piireissä kiertää lause, jonka uskomme jäävän elämään hype-syklin jälkeenkin: "Niukka resurssi ei enää ole koodi. Se on harkintakyky." [6]. Design of AI -uutiskirjeen rinnakkainen muotoilu ilmaisee asian vielä täsmällisemmin: "Vuonna 2026 niukka resurssi ei ole tuotos. Se on yhtenäisyys ja kuratointi." [7]

Molemmat lainaukset osoittavat samaan taustalla olevaan totuuteen. Kun mikä tahansa tiimi voi tuottaa toimivan koodin minuuteissa, kilpailuetu ei ole pääsy tähän kykyyn — kaikilla on se jo. Etu on siinä, että tietää, mitä pitäisi rakentaa, mitä hylätä ja mitä tekoäly hiljaisesti teki väärin. Tämä on harkintakykyä, eikä se synny mallin painoista. Se syntyy kokemuksesta, toimialaosaamisesta ja aiemmista poltetuista sormista.

Tämä on merkittävämpää kuin miltä se kuulostaa. Olemme nähneet tiimien kohtelevan tekoälyn tuottamaa tuotosta luotettavana sen vuoksi, että se kääntyy ja läpäisee perustestit. Mutta testien läpäiseminen ja liiketoiminnan kontekstissa oikein oleminen ovat eri asioita. Agentti voi kirjoittaa teknisesti pätevän nopeudenrajoitusfunktion, joka on täysin väärä todellisiin liikennemalleihinne, todellisiin petosvektoreihinne, todellisiin asiakkaisiinne nähden. Tämän havaitseminen vaatii jonkun, joka ymmärtää toimialan — ei vain syntaksin.

Käytännön ohje: jos tiiminne tekoälyn käyttöönottostrategia on "annetaan agenttien kirjoittaa enemmän koodia nopeammin", optimoitte väärää muuttujaa. Hyöty syntyy nopeammasta validoidusta koodista, ja validointi on ihmisen harkintakyvyn pullonkaula, kunnes toisin todistetaan.

Kontekstinhallinta: uusi tekniikan osa-alue

Yksi tämän vuoden tutkimuksen teknisemmistä mutta aliarvostetuimmista havainnoista koskee kontekstia — nimenomaan sitä, että sen hallinnasta, mitä tekoäliagentti tietää, muistaa ja mihin se voi toimia, on tullut oma tekniikan osa-alueensa. Fluid Attacksin tutkimus työkaluista kuten Claude Code osoittaa kontekstinhallinnan aidosti niukaksi resurssiksi agenttipohjaisissa työnkuluissa — ei pelkäksi käyttökokemuksen ärsyttäväksi yksityiskohdaksi (viitattu myös lähteessä 8).

Tämä näkyy käytännössä muutamalla tavalla:

• Kontekstin rappeutuminen — agentit ajautuvat harhaan tai hallusinoivat, kun keskustelu- tai tehtävähistoria paisuu hallitsemattomaksi, mikä vaatii aktiivista karsimista ja uudelleenrajausta pelkän "lisää kontekstia" -ajattelun sijaan.
• Artefaktien siirrot — moniagenttijärjestelmissä yhden agentin tuotos on toisen agentin syöte, ja jos tämä siirto ei ole jäsennelty (selkeät formaatit, selkeät rajoitukset), virheet kertautuvat äänettömästi koko putken läpi.
• Roolien erikoistuminen — Firecrawlin agenttipohjaista tekoälyä käsittelevä trendiraportti huomauttaa selvästä mallista, jossa roolikohtaisesti erikoistuneet agentit (suunnittelija, koodari, katselmoija, testaaja) vaihtavat keskenään erillisiä artefakteja sen sijaan, että yksi monoliittinen agentti tekisi kaiken [9].

Käytännön seuraus rakentajille: kohdelkaa kontekstin suunnittelua kuten tietokannan skeeman suunnittelua — harkitusti, versioinnin kanssa, rajojen kanssa ja jonkun ollessa siitä vastuussa. Tiimit, jotka antavat kontekstin rönsyillä hallitsemattomasti, päätyvät agentteihin, jotka ovat nopeita mutta epäluotettavia — mikä on pahempi asia kuin agentti, joka on yksinkertaisesti hidas.

Organisaation uudelleenmuotoilu: koodareista laivastonohjaajiksi

Organisaatiokaavion vaikutukset ovat kohta, jossa tämä muuttuu aidosti disruptiiviseksi, ja jossa uskomme useimpien yritysten aliarvioivan tilanteen. Stanfordin AI Index huomauttaa, että agenttien käyttöönotto on absoluuttisesti ottaen yhä suhteellisen vähäistä mutta kasvaa jyrkästi — mikä tarkoittaa, että useimmat organisaatiot ovat vasta alussa käyrää, joka näyttää hyvin erilaiselta kahdentoista kuukauden kuluttua [1].

Se, mitä näemme käytännössä — sekä omassa rakennusprosessissamme että keskustellessamme muiden tiimien kanssa — on siirtymä kohti ihmisten suorittamaa agenttilaivastojen ohjausta yksittäisten kehittäjien yksittäisten ominaisuuksien kirjoittamisen sijaan. Yksi seniori-insinööri voi olla vastuussa tuloksista puolen tusinan samanaikaisen agenttityönkulun osalta — ei siksi, että hän olisi yli-ihminen, vaan koska hänen työnsä muuttui tuottamisesta ohjaamiseksi ja tarkastamiseksi.

Tällä on raaka vaikutusketju junioritason rooleihin. Perinteinen oppipoikamalli — junior-insinöörit oppivat kirjoittamalla paljon koodia valvonnan alla — rapautuu, koska volyymikoodauksen tarve harjoittelun välineenä yksinkertaisesti vähenee. UX Tigersin vuoden 2026 puolivälin todellisuustarkistus nostaa tämän suoraan esiin: junioritason roolit vähenevät perinteisessä mielessä, ja uusia oppipoikamalleja syntyy, jotka keskittyvät harkintakyvyn opettamiseen syntaksin sijaan [10].

Tämä on aidosti vaikea ongelma. Kuinka kouluttaa seuraava sukupolvi seniori-insinöörejä — niitä, joiden harkintakyky on tulevaisuudessa tärkeintä — jos perinteinen sisäänajoreitti (paljon koodin kirjoittamista, paljon pieniä virheitä, niiden kiinnijääminen katselmoinnissa) katoaa? Osa tiimeistä kokeilee jäsenneltyjä "agenttiparillisia" oppipoikamalleja: junioreiden ei tarvitse kirjoittaa koodia tyhjästä, vaan he katselmoivat, korjaavat ja ohjaavat tekoälyn tuotosta mentoroinnin alla — aloittaen uransa käytännössä harkintakyvyn tasolta sen sijaan, että he työskentelisivät kohti sitä. On liian aikaista tietää, tuottaako tämä yhtä syvällisen vaiston omaavia insinöörejä kuin vanha polku. Epäilemme, että se tuottaa erilaisen vaiston — kaavantunnistusta tekoälyn epäonnistumismalleille pelkän kielen sujuvuuden sijaan — ja että tämä saattaa itse asiassa osoittautua arvokkaammaksi jatkossa.

Käytännön ohje: jos rakennatte tiimiä vuonna 2026, älkää palkatko koodituotoksen perusteella. Palkatkaa ihmisiä, jotka esittävät hyviä kysymyksiä vaatimuksista, jotka huomaavat hienovaraisen virheellisyyden uskottavalta näyttävässä tuotoksessa, ja jotka osaavat selittää miksi jokin on väärin sekä ihmisille että lopulta itse agenteille paremman promptauksen ja suojakaiteiden kautta.

Miltä tämä näyttää käytännössä

Abstraktiot on helppo kirjoittaa mutta vaikea toteuttaa käytännössä, joten tässä on konkreettinen kuvaus siitä, miltä tämä näyttää — poimittu malleista, joita olemme nähneet toteutuvan rakentajatiimeissä ja omassa tuotekehitystyössämme.

Tarkoituksen määrittelystä tulee ensiluokkainen artefakti. Epämääräisen tiketin sijaan ("lisää käyttäjän todennus") tiimit kirjoittavat yksityiskohtaisia tarkoitusdokumentteja — rajoitukset, reunatapaukset, turvallisuusvaatimukset, mitä "valmis" oikeasti tarkoittaa — koska juuri sen dokumentin pohjalta agentti todella toimii. Roska sisään, roska ulos — vain nopeammin kuin ennen.

Katselmointi siirtyy tyylistä sisältöön. Kukaan ei enää katselmoi tekoälyn tuottamaa koodia sisennysten tai nimeämiskäytäntöjen osalta — agentit ovat siinä johdonmukaisia. Katselmointiaika käytetään lähes kokonaan siihen: vastaako tämä liiketoimintalogiikkaa, aiheuttaako tämä turvallisuusaukon, skaalautuuko tämä todellisen kuormituksen alla. CIO:n insinöörityönkulkujen raportointi vahvistaa, että tämä siirtymä on jo vakiokäytäntö johtavissa insinöörijärjestöissä [4].

Turvallisuushallinto siirtyy aikaisemmaksi ja tiukentuu. Koska tekoälyn tuottama koodi on turvallisuustiimien suurin sokea piste, ja koska jokainen kyselyyn vastannut organisaatio kasvattaa tekoälyturvallisuuden budjettejaan, älykäs ratkaisu on rakentaa turvallisuuskatselmointi osaksi agenttiputkea — ei liittää sitä jälkikäteen käyttöönoton jälkeen [3]. Tämä tarkoittaa automaattisia käytäntötarkastuksia, jotka suoritetaan jokaiselle agentin tuottamalle artefaktille ennen kuin ihminen edes näkee sitä, jotta ihmisen harkintakyky käytetään aidosti epäselviin tapauksiin — ei linter-tason tarkastuksella havaittaviin asioihin.

Perustajatason menestys korreloi työnkulun integraatioon, ei mallin saatavuuteen. Tutkimus perustajien tuloksista tekoälyn aikakaudella (Founder to Fortune, viitattu Backslashin analyysin yhteydessä) havaitsi, että erottava tekijä ei ollut se, mitä mallia tai työkalua tiimi käytti — kaikilla on pääsy suunnilleen samoihin huippumalleihin — vaan se, kuinka syvällisesti he integroivat ihmisen harkintakyvyn silmukat itse työnkulkuun [5]. Voittavat tiimit eivät ole niitä, joilla on hienoin agenttipino. Ne ovat niitä, jotka selvittivät, missä täsmälleen ihmisen täytyy katsoa tuotosta ennen sen julkaisua.

Tämä on rehellisesti sanottuna aidosti pohjoismainen vaisto: epäluottamus hypeä kohtaan, mieltymys järjestelmiin, jotka ovat tylsiä ja luotettavia näyttävien ja hauraiden sijaan, sekä kulttuurinen mukavuus sanoa "tarvitsemme ihmisen tarkistamaan tämän" pitämättä sitä automaation epäonnistumisena. Tiimit, jotka tekevät tämän hyvin, eivät romantisoi tekoälyä, mutteivät myöskään pelkää sitä. He ovat vain täsmällisiä sen suhteen, missä ihminen istuu silmukassa.

Suurempi muutos: mikä muuttuu, kun tekoäly rakentaa ohjelmiston

Tässä on epämukava totuus kaiken tämän taustalla: ensimmäistä kertaa ohjelmistokehityksen historiassa asioiden hyvän rakentamisen rajoite ei ole kyky rakentaa niitä. Ideoita, prototyyppejä, jopa kohtuullisen valmiita tuotteita voidaan tuottaa nopeammin kuin useimmat organisaatiot ehtivät arvioida, pitäisikö niiden edes olla olemassa.

Tämä käänne muuttaa sitä, mitä "tekninen taito" edes tarkoittaa. Ennen se tarkoitti: pystytkö saamaan tietokoneen tekemään jotain. Yhä useammin se tarkoittaa: pystytkö nopeasti ja oikein sanomaan, onko se, mitä tietokone teki, oikea asia — tälle liiketoiminnalle, tälle käyttäjälle, tälle uhkamallille, tälle hetkelle. Tämä ei ole taito, jonka saa bootcampista. Se on taito, joka syntyy kokemuksesta, uteliaisuudesta ja siitä, että on ollut riittävän monta kertaa väärässä kehittääkseen aidon vaiston.

Koodi ei koskaan todella ollut tuote. Se oli aina mekanismi, jolla ilmaistiin päätös siitä, mitä pitäisi olla olemassa. Nyt kun tuo mekanismi on lähes ilmainen, päätöksenteosta — harkintakyvystä — tulee koko peli. Organisaatiot, jotka ymmärtävät tämän, uudelleenjärjestäytyvät sen mukaisesti: litteämmät tiimit, seniorit ohjaamassa agenttilaivastoja, juniorit koulutettuina arviointiin tuotannon sijaan, turvallisuus ja hallinto sisäänrakennettuina putkeen sen sijaan, että ne liitettäisiin loppuun.

Organisaatiot, jotka eivät tätä ymmärrä, jatkavat palkkaamista koodituotoksen perusteella, jatkavat nopeuden mittaamista commitien määrällä ja huomaavat toistuvasti — yleensä kalliilla tavalla, yleensä turvallisuuspoikkeaman tai teknisesti toimivan mutta väärän ongelman ratkaisevan tuotteen kautta — että he optimoivat sitä, mistä tuli hyödyke, samalla kun jättivät huomiotta sen, mistä ei tullut.

Koodi on ilmaista. Harkintakyky ei ole. Se ei ole enää pelkkä iskulause. Se on markkinoiden todellinen muoto.

Sources

1. https://hai.stanford.edu/assets/files/ai_index_report_2026.pdf
2. https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf
3. https://www.cio.com/article/4134741/how-agentic-ai-will-reshape-engineering-workflows-in-2026.html
4. https://www.cio.com/article/4134741/how-agentic-ai-will-reshape-engineering-workflows-in-2026.html
5. https://www.backslash.security/blog/the-new-role-of-developers-ai-sdlc
6. https://www.linkedin.com/posts/harissheikh012_programming-aiagents-technology-activity-7470372881684824064-4fln
7. https://productimpactpod.substack.com/p/the-design-of-ai-in-2026-strategy
8. https://www.firecrawl.dev/blog/agentic-ai-trends
9. https://www.firecrawl.dev/blog/agentic-ai-trends
10. https://www.uxtigers.com/post/2026-predictions-halfway