Artificial Septelligence 2025 – kaikki tehot irti agenttipohjaisesta koodaamisesta

09 | 2025 Antti Rintala, Data Architect, partner Kipinä

Kipinä Software, Artificial Septelligence tapahtuma 2025

Oli aurinkoinen syyskuun torstai, kun vähin äänin Suomen ICT-kehityksen huiput kokoontuivat yhteisen kutkuttavan teeman äärelle: Mitä agenttipohjainen tekoäly voi parhaimmillaan tarjoilla niin ohjelmistokehitykselle kuin liiketoiminnan kasvulle?

Ensimmäistä kertaa järjestetty Kipinän ‘Artificial Septelligence on tapahtuma’ oli kaikkea muuta kuin yleistasoista AI puhetta ja ennen kaikkea käytännönläheisiä kokeiluita. Kokoontuminen Agenttisen Pasi Vuorion johdattelemana, osallistujat pohtivat yhdessä miten oikein käytettynä AI agentit muuttavat koodaamisen arkea.

Ohjelmistokehityksen muuttuessa hurjalla vauhdilla yksi nykyhetken suurimmista murroksista tapahtuukin juuri agenttipohjaisen koodauksen parissa. Kun koodia generoivat tekoälyagentit voivat hoitaa osan ohjelmointityöstä, nousee pintaan kysymys: kuinka varmistaa korkea laatu ja hallittavissa oleva lopputulos? Vastaus ei löydy uusimmista ‘kikkakolmosista’, vaan paluusta perusasioiden äärelle: dokumentaatioon, testivetoiseen kehitykseen ja laadun systemaattiseen parantamiseen.

Tiivistimme Artificial Septelligence tapahtuman käytännön harjoitusten kautta syntyneet oivallukset ja uudet mahdollisuudet, kun kielimalli saa käyttöönsä työkaluja, workflow ajattelua ja laadun systemaattista ohjausta.

Document Driven Development; paluu perusasioiden äärelle

Ohjelmistokehityksessä dokumentaatio on usein nähty välttämättömänä pahana. Usein se jää jälkeen koodista tai hautautuu projektinhallintatyökalujen uumeniin. Document Driven Development kääntää tämän asetelman päälaelleen: dokumentaatio ei ole sivutuote, vaan Lähtökohta.

Kun AI-agentit generoivat koodia, niiden ohjenuorana toimivat dokumentit. Nämä kuvaukset järjestelmän vaatimuksista, prosesseista ja käyttötapauksista ovat ensiarvoisen tärkeitä, jotta agentit voivat jäsennellä omaa työtään. Hyvä dokumentaatio on samalla rajapinta, jonka kautta ihminen ja agentti ymmärtävät toisiaan.

Tässä mielessä dokumentteihin nojaava kehitys ei ole uusi villitys, vaan muistutus siitä, että selkeä suunnittelu ennen koodausta on aina ollut toimivan ohjelmistokehityksen perusta. Nyt se vain saa uuden merkityksen: dokumentaatio ei enää palvele vain ihmisiä, vaan myös tekoälyä.

TDD ja BDD; testauskehityksen tutut kivijalat

Testivetoisessa kehityksessä (TDD) ja käyttäytymislähtöisessä kehityksessä (BDD) on aina ollut kyse siitä, että vaatimukset ja laatu varmistetaan etukäteen testien avulla. Agenttipohjaisessa koodauksessa nämä käytännöt nousevat entistä keskeisempään rooliin.

Kun testit kirjoitetaan ensin, ne toimivat paitsi laadunvarmistuksen työkaluna myös ohjeena agentille: tällainen koodin pitäisi olla. 


Molemmat kuitenkin antavat AI:lle konkreettisen raamin, jonka rajoissa toimia. Esimerkiksi agentti voi generoida koodia, joka läpäisee testit, mutta ei välttämättä vastaa liiketoiminnan todellisia tarpeita. BDD:n kautta vaatimukset kirjataan ymmärrettävässä muodossa, jolloin myös agentin tuotos on lähempänä oikeaa tarvetta.

Työkalut

Agenttipohjaisen kehittämisen suurin etu ei ole pelkästään se, että kielimalli osaa tuottaa tekstiä tai koodia. Sen todellinen voima tulee siitä, että agentti voi käyttää työkaluja – eli kutsua ohjelmallisia rajapintoja, ajaa skriptejä ja jopa ohjata toisia, erikoistuneita malleja. Tätä kutsutaan tool callingiksi.

Tool calling tekee agentista enemmän kuin koodigeneraattorin: siitä tulee toimija, joka pystyy vaikuttamaan ympäristöönsä. 

Se voi esimerkiksi:

  • Ajaa testejä ja skriptejä: Agentti ei jää arvailemaan, vaan voi suorittaa koodin, nähdä tulokset ja käyttää niitä seuraavaan iterointiin.

  • Kutsua rajapintoja ja järjestelmiä: Agentti voi hyödyntää tietokantoja, CI/CD-putkia tai analytiikkatyökaluja suoraan, aivan kuten ihminenkin tekisi komentorivillä.

  • Delegoida erikoistuneille kielimalleille: Jos ongelma vaatii erityistä osaamista (esim. käännöksiä, matemaattista päättelyä tai tietoturva-analyysiä), agentti voi ohjata tehtävän toiselle mallille ja yhdistää tulokset takaisin kokonaisuuteen.

  • Rakenne oppimissilmukoita: Tool calling mahdollistaa iteraation: generoi → aja → tarkista → refaktoroi. Tämä muistuttaa ihmisen ohjelmointiprosessia, mutta tapahtuu nopeammin ja järjestelmällisemmin.

Toisin sanoen: agentti ei ole vain keskustelukumppani, vaan ohjelmoitava tiiminjäsen, jolla on pääsy työkaluihin. Mitä rikkaampi ja paremmin määritelty työkalupakki agentille annetaan, sitä monipuolisemmin ja laadukkaammin se pystyy toimimaan.

Workflow ja agenttien työnjako

Kun työkalut ja toimintatavat ovat kunnossa, seuraava askel on miettiä workflow – eli miten kokonaisuus pilkotaan hallittaviin osiin. Määritelty vaatimus tai spesifikaatio voidaan jakaa pienempiin kehitystehtäviin, joista jokainen hoidetaan erikseen.

Tässä kuvioon astuu agent swarm – joukko erikoistuneita agentteja tai sub-agentteja, jotka työskentelevät rinnakkain:

  • frontend-agentti keskittyy käyttöliittymään

  • backend-agentti rakentaa palvelinpuolen logiikkaa

  • testaus-agentti varmistaa laadun ajamalla testit ja analysoimalla tulokset

  • dokumentaatio-agentti huolehtii, että kokonaisuudesta jää jälki myös ihmisille

Workflow on siis se liima, joka yhdistää nämä erikoistuneet toiminnot yhdeksi kokonaisuudeksi. Sen avulla agenttien työskentely ei ole satunnaista, vaan etenee vaiheittain kohti valmista ratkaisua – samaan tapaan kuin ohjelmistoprojekti organisoidaan tiimeille ja rooleille.

Pattern/antipattern; parit laadun parantajina

LLM-agentti ei “ymmärrä laatua” samalla tavalla kuin ihminen, mutta se osaa ohjata tuottamaansa koodia annettujen esimerkkien ja rajojen mukaan. Siksi pelkkä “tehdään näin” ei aina riitä. Tehokkaampaa on antaa sekä pattern (mitä tavoitellaan) että antipattern (mitä pitää välttää).

Esimerkkejä pariajattelusta:


Pattern: Kirjoita testit ennen koodia (TDD).

Antipattern: Älä generoi koodia ilman, että testejä on määritelty.

Pattern: Refaktoroi koodi pieniin, selkeisiin metodeihin.

Antipattern: Vältä pitkiä, monimutkaisia funktioita, joita ei voi testata helposti.

Pattern: Käytä selkeitä, kuvaavia nimiä muuttujille ja metodeille.

Antipattern: Älä käytä kryptisiä lyhenteitä tai geneerisiä nimiä (esim. tmp, data1).

Pattern: Kirjoita dokumentaatio, joka seuraa koodia ja testejä.

Antipattern: Älä jätä dokumentaatiota irralliseksi, tai vanhentumaan erilliseen tiedostoon.

Miksi parit toimivat?

Ihmiskehittäjälle on usein itsestään selvää, että “hyvä tapa” merkitsee samalla myös sitä, että tiettyjä asioita ei tehdä. LLM-agentille näin ei kuitenkaan aina ole. Se voi hyvin tuottaa esimerkiksi sekä testejä että testaamatonta koodia, jos sille ei ole selkeästi kerrottu, mitä vältetään.

Kun pattern/antipattern-parit asetetaan ohjeeksi, agentti saa sekä positiivisen mallin että negatiivisen rajan: tee tätä mutta älä tee tuota. Tämä tekee ohjauksesta konkreettisempaa ja parantaa tuotoksen laatua.


Mitä mukaan Articial Septelligence tapahtuman oivalluksista?

Agenttipohjainen koodaus tarjoaa huimia mahdollisuuksia – aina digikehityksen vauhdittamisesta data- ja tekoälyratkaisujen hyödyntämiseen ja skaalautuviin ohjelmistoarkkitehtuureihin.

Se ei kuitenkaan poista ohjelmistokehityksen perustarvetta: selkeää dokumentaatiota, testattavaa koodia ja laadunhallintaa. Kun nämä elementit otetaan tosissaan, AI toimii tehokkaana kumppanina – ja parhaimmillaan muuttaa ohjelmistokehityksen prosesseja kestävämmiksi ja liiketoimintaa kasvattavammiksi.

Tekoälyagentit eivät siis muuta ohjelmistokehityksen peruslakeja, ne vain tekevät niistä entistä tärkeämpiä.

Jos aihe kiinnostaa, kurkkaa myös muut Insights-artikkelimme, esimerkiksi:


Seuraava
Seuraava

Tekoälyn seuraava vaihe – viisi tärkeintä näkökulmaa