Kokosimme huhtikuun alussa pienen joukon ohjelmistokehityksen vetäjiä aamiaiselle Helsingin HUONE Kluuviin. Paikalla oli kuusi kehitysjohtajaa ja CTO:ta kuudesta eri organisaatiosta — edustettuja toimialoja olivat mm. energia, vakuutusala, rakennusteknologia, rekrytointialusta, taloushallinto ja paikkatietoteknologiat.
Halusimme järjestää tilaisuuden, jossa ei ole demoja, myyntipuheita eikä ylioptimistisia esimerkkitapauksia. Pelkkää vertaiskeskustelua siitä, miten tekoälyavusteista kehitystä viedään eteenpäin organisaatioissa, joissa pääosa työstä kohdistuu olemassa oleviin tuotantopalveluihin — ei tyhjälle taululle piirrettyihin prototyyppeihin.
Tässä tärkeimmät havainnot.
Seuraava agenttisen kehityksen aamiaistapahtuma Helsingissä 7.5.2026!
Oppien levittäminen organisaatiossa ratkaisee — mutta miten?
Ehkä selkein jakolinja keskustelussa kulki onnistuneiden ja epäonnistuneiden kokeilujen välillä tekoälyavusteisen kehityksen ajatuksien ja oppien levittämisessä organisaatioissa.
Mikä ei toimi: sisäinen demo, joka vie suoraan syvään päähän agenttiseen kehitykseen. Osallistujat eivät saa kiinni, kokemus jää negatiiviseksi, ja skeptisyys kasvaa.
Millaisia ratkaisuja koettiin toimiviksi:
- Yksinkertainen, konkreettinen käyttötapaus. Esimerkiksi: "pyydä kielimallia analysoimaan järjestelmää arkkitehtuurin näkökulmasta." Kun kehittäjä näkee miten yksittäinen työtehtävä helpottuu, kynnys kokeilla laskee.
- Pakollinen käytännön koulutuspäivä kaikille. Edelläkävijöille tämä voi tuntua turhauttavalta, mutta perässä tulevat tarvitsevat tämän päästäkseen alkuun. Positiiviset kokemukset leviävät sen jälkeen luonnollisesti.
- Innostuneiden kehittäjien aktivointi. Kun innokkaimmille näytetään, miten AI poistaa tylsiä rutiinitehtäviä ja vapauttaa aikaa kiinnostavaan työhön, he toimivat sisäisinä lähettiläinä.
Yksikkötestien generointi nousi yleisimmäksi "ensimmäiseksi käyttötapaukseksi" — matala riski, konkreettinen hyöty, ja testikattavuuden nouseminen on helppo mitata.
Kontekstin hallinta on kriittisin kyvykkyys
Kun kehitettävän järjestelmän koko kasvaa, tulee yhä kriittisemmäksi antaa kielimallille oikea määrä kontekstia — ei liikaa, ei liian vähän. Tämä ns. context engineering on nopeasti kehittyvä osaamisalue, jossa kukaan ei vielä ole löytänyt lopullista ratkaisua.
Domainspesifinen kontekstityö — yrityksen oman liiketoimintalogiikan, arkkitehtuurin ja rajoitteiden kuvaaminen kielimallille ymmärrettävään muotoon — on työtä, jota ei voi ulkoistaa yleiselle tekoälyratkaisulle. Se vaatii syvällistä ymmärrystä omasta järjestelmästä.
Koodikatselmointi muuttaa muotoaan
Kielimallit ovat monissa tapauksissa parempia sekä luomaan että tarkastamaan pull requesteja kuin ihmiset. Tämä ei tarkoita, että ihmistä ei tarvita — päinvastoin. Ihmisen rooli siirtyy yksittäisten muutosten katselmoinnista kokonaiskuvan hallintaan: onko testit kunnossa, onko turvaverkko paikallaan, ymmärretäänkö mitä ollaan tekemässä?
Agenttinen kehitys vaatii myös atomisempia committeja ja pull requesteja. Kun koodi syntyy nopeammin, on entistä tärkeämpää pitää muutosten koko hallittavana — jotta ihminen pystyy ymmärtämään kehityksen kokonaisuutta jälkeenpäin.
Tuotejohtaminen on uusi pullonkaula
Tämä oli ehkä tärkein yksittäinen havainto: kehityskapasiteetin kasvusta ei ole hyötyä, jos tuotehallinta ei pysty johtamaan tekemistä.
Kun kehittäjät pystyvät tuottamaan enemmän koodia nopeammin, organisaation kyky päättää mitä tehdään, kenelle ja miksi nousee kriittiseksi pullonkaulaksi. Tuotehallinnan rooli ei voi olla enää ensisijaisesti ratkaisukehityksen palvelemista — spesifikaatioiden luontia ja epävarmuuden vähentämistä. Sen pitää keskittyä strategiseen ajatteluun, tavoiteohjautuvuuteen ja asiakasymmärrykseen.
Osa osallistujista pohti avoimesti, tarvitaanko perinteistä Product Manager -roolia jatkossa lainkaan. Toisten kokemus oli, että rooli on välttämätön, mutta sen sisällön pitää muuttua radikaalisti. Yhteistä oli näkemys siitä, että kehittäjät kaipaavat suoraa kontaktia käyttäjiin — eivät tuotehallinnan kautta välitettyä tietoa.
Tietoturva ei ole vain periaatekysymys
Kielimallien tietoturva nousi esiin käytännön esteenä, ei vain teoreettisena riskinä. Osa osallistujista ei halua käyttää suoraan edes maksullisia pilvipalveluita (Claude, Codex) oman ydintuotteen kehitykseen, koska pelkäävät immateriaalisen pääoman vuotamista.
Ratkaisuina mainittiin lokaalien mallien hyödyntäminen ja LLM-proxyt, jotka suodattavat malleille lähetettävää dataa. Lisäksi keskusteltiin kielimallien kyvystä reverse-engineerata toteutuksesta taustalla olevia ajatuksia ja ratkaisuperiaatteita — mikä nostaa IPR-kysymykset uudelle tasolle.
Tiimit pienenevät, roolit laajenevat
Osallistujien yhteinen näkemys oli, että kehitystiimien koko pienenee — kolmen hengen tiimi voi olla arkipäivää agenttisen kehityksen yleistyessä. Samalla erikoistuminen vähenee: pelkkä backend- tai frontend-osaaminen ei enää riitä, vaan jokaisen tiimin jäsenen pitää hallita laajempi kokonaisuus ja ymmärtää liiketoimintaa aiempaa syvemmin.
Avoimeksi jääneet kysymykset
Puolentoista tunnin keskustelu ei luonnollisesti ratkaissut kaikkea. Nämä kysymykset jäivät avoimiksi:
1. Kuinka pitkälle agenttisen kehityksen kanssa voi mennä? Missä ovat rajat, ja miten ne löydetään turvallisesti?
2. Miten pitää oma osaaminen relevanttina? Kun AI hoitaa yhä enemmän teknistä työtä, mitä kehittäjän pitää osata?
3. Miten saadaan AI toimimaan legacy-koodin kanssa? Vanhat koodikannat ovat todellisuutta useimmissa tuotantoympäristöissä.
4. Miten tunnistaa loogiset palvelurajat uudelleen? Jos agentit pystyvät rakentamaan palveluita uusiksi, mitkä mikropalvelut kannattaisi yhdistää takaisin loogisiksi kokonaisuuksiksi?
Vertaistuki on aliarvostettua
Ehkä tärkein meta-havainto oli, että kaikilla on samanlaisia haasteita. LinkedIn ja sosiaalinen media antavat helposti vääristyneen kuvan siitä, missä organisaatiot todellisuudessa ovat — keskustelussa kävi selväksi, että maturiteetti vaihtelee valtavasti ja kukaan ei ole "valmis."
Aiomme järjestää vastaavia tilaisuuksia jatkossakin. Jos olet ohjelmistokehityksen vetäjän, CTO:n tai tuotejohtajan roolissa ja haluat osallistua seuraavaan, ilmoittaudu mukaan seuraavaan aamiaistapahtumaamme.
Tilaisuuden järjesti Flowa. Fasilitaattoreina toimivat Antti Kirjavainen ja Juha Heimonen.
