Miten ottaa moniagenttinen ohjelmistokehitys haltuun vuoden tauon jälkeen?
Saana Hiekkaranta 18.8.2026Palasin vuoden vanhempainvapaalta takaisin töihin ja huomasin ison muutoksen: tekoäly ei enää vain avusta ohjelmistokehittäjää, vaan tekee yhä suuremman osan itse kehitystyöstä. Tekoälyn käytöstä on tullut monissa yrityksissä arkipäivää. Erityisesti moniagenttinen ohjelmistokehitys (multi-agent software development) on noussut tänä vuonna suosioon, sillä vielä vuosi sitten, kun jäin vanhempainvapaalle, siitä ei puhuttu läheskään yhtä paljon. Tässä blogipostauksessa kerron esimerkin siitä, miten moniagenttista ohjelmistokehitystä voi alkaa ottaa haltuun konseptitodistuksen (proof of concept) avulla.
Tässä tiivistettynä kolme asiaa, jotka yllättivät:
Suunnittelun ja ymmärtämisen korostunut merkitys
Validointi vie paljon enemmän aikaa kuin ennen
Moniagenttinen ohjelmistokehitys ei välttämättä vapautakaan niin paljon työaikaa kuin aluksi luulin
Mitä on moniagenttinen ohjelmistokehitys?
Aloitetaan määrittelemällä termejä, jotka olisi hyvä ymmärtää:
Agentti (Agent) = Autonominen yksikkö, joka vastaanottaa syötteen, käsittelee sen ja palauttaa vastauksen.
Aliagentti (Subagent) = Agentin käynnistämä toinen agentti, jonka toiminnalle on asetettu selkeä, kapea tavoite.
Tarkastuspiste (Checkpoint, Human-in-the-loop) = Määritelty tarkastuspiste, jossa ihminen hyväksyy/muokkaa/estää agentin toiminnan ennen seuraavaa vaihetta.
Konteksti-ikkuna (Context window) = Tekoälyn työmuisti, johon mahtuu vain rajattu määrä dataa.
Orkestrointi (Orchestration) = Useiden agenttien koordinointi ja hallinta.
Orkestroija (Orchestrator) = Koordinoiva agentti, joka jakaa tehtävän osiin ja delegoi sen aliagenteille.
Moniagenttista ohjelmistokehitystä voisi ajatella ohjelmistotiiminä, jossa jokaisella agentilla on oma tehtävänsä. Yksi agenteista esimerkiksi suunnittelee arkkitehtuuria, toinen agentti koodaa ja kolmas agentti hoitaa testauksen sekä testiraportoinnin. Yhdellä tekoälyagentilla ei siis tehdä kaikkea, vaan prosessi jaetaan pieniin vastuualueisiin, ja tehtävä delegoidaan tarvittaessa tietylle agentille. Näin työ voidaan jakaa pienempiin osiin, ja agentit voivat tehdä töitä samanaikaisesti.
Yksi suosittu malli toteuttaa moniagenttista ohjelmistokehitystä on orkestroija-malli (orchestrator pattern), jossa ihminen kommunikoi orkestroija-agentin kanssa. Orkestroija-agentti voi kutsua ennalta määriteltyjä aliagentteja ja delegoida niille tehtäviä tarpeen mukaan. Orkestroija on kuin tiiminvetäjä, joka jakaa tehtäviä, kerää tulokset yhteen ja päättää sitten, mitä raportoida ihmiselle. Orkestroija pitää kokonaisuuden kasassa ja varmistaa, että oikea aliagentti tekee oikean työn oikeaan aikaan.
Konseptitodistus: Moniagenttinen ohjelmistokehitys Claude Codella
Ohjelmistokehityksen elinkaarta kuvataan usein kuuden vaiheen avulla: vaatimusmäärittely, arkkitehtuuri, toteutus, testaus, käyttöönotto ja ylläpito.
Kokeilin moniagenttista ohjelmistokehitystä luomalla konseptitodistuksen, jossa edellä mainitut ohjelmistokehityksen vaiheet toteutettiin moniagenttisella työnkululla. Jotta konseptitodistuksen laajuus olisi hallittavissa, toteutin tässä esimerkissä vain 4 ensimmäistä vaihetta. Jokaisen vaiheen suoritti erillinen aliagentti, työnkulkua ohjasi orkestroija-agentti ja ihminen tarkasti tuloksia määritellyissä tarkastuspisteissä. Käytin tässä toteutuksessa Claude Codea, mutta samankaltaisen toteutuksen voisi tehdä muillakin työkaluilla.
Orkestroijan ohjeistus
Aloitin määrittelemällä sen, miten orkestroijan tulee toimia. Tein sen yhdessä Clauden kanssa siten, että kuvailin orkestroijan halutun toiminnan ja agentti toteutti sen. Orkestroijan ohjeet määriteltiin CLAUDE.md-tiedostossa sekä projektin skilleissä (.claude/skills/<nimi>/SKILL.md). Näissä paikoissa määriteltiin esimerkiksi käytettävän moniagenttisen työnkulun prosessi ja tarkastuspisteet. Koska suunnittelu ja validointi ovat tärkeitä agenttisessa ohjelmistokehityksessä, asetin tarkastuspisteet vaatimusmäärittelyyn, arkkitehtuuriin ja katselmointiin – näissä kohdissa orkestroija ei saanut jatkaa ilman ihmisen hyväksyntää.
Tässä mallissa, kun ohjelmistokehitysprosessi aloitettiin, avattiin uusi sessio, jonka sisällä orkestroija koordinoi työnkulkua. Se kutsui aliagentteja tarpeen mukaan, välitti niille tarvittavan kontekstin ja kokosi tulokset yhteen. Kommunikaatio ihmisen ja aliagenttien välillä tapahtui aina orkestroijan kautta. Ihmisen tehtävänä oli tehdä päätökset ja toimia portinvartijana.
Aliagenttien määrittely
Seuraavaksi määriteltiin aliagentit. Myös se tehtiin vuorovaikutuksessa Clauden kanssa samalla tavoin kuin orkestroijankin määrittely. Claude loi .claude/agents/ -kansioon jokaiselle aliagentille oman konfiguraationsa, jonne määriteltiin kyseisen agentin työnkuvaus.
Jokaiselle aliagentille määriteltiin oma rooli, vastuualue ja toimintatapa. Lisäksi eri agenteille määriteltiin paljon muitakin ominaisuuksia, kuten erilaiset kielimallit tehtävän mukaan. Esimerkiksi arkkitehtuurialiagentti ja katselmointialiagentti käyttivät laajempaa mallia kuin vaatimusmäärittely-, toteutus- ja testausaliagentit.
Alla olevassa koodilohkossa näkyy osa vaatimusmäärittelyaliagentin määrittelydokumentista (.claude/agents/requirements.md). Kyseisessä dokumentissa määriteltiin, että aliagentti toimii vaatimusanalyytikkona ja tarkentaa epäselviä pyyntöjä, tutustuu olemassa oleviin ratkaisuihin ja tuottaa spesifikaation, jossa määritellään tavoite, laajuus, hyväksymiskriteerit ja avoimet kysymykset. Tässä konseptitodistuksessa vaatimukset kirjoitettiin vain tiedostoihin, sillä mitään tikettijärjestelmää ei ollut käytössä.
--- name: requirements-agent description: Drafts and clarifies specs from a feature request, and writes them to docs/requirements/. Use proactively before design work. tools: Read, Grep, Glob, Write, Edit, Skill model: sonnet --- You are a requirements analyst. Turn vague feature requests into a structured spec with acceptance criteria, written to a file rather than returned only as chat output. Given a feature request: 0. Before drafting anything, judge whether the request fits one requirements→design→ implementation→test→review cycle. Treat it as too wide if any of: - It bundles more than one independently-shippable capability (each could reasonably ship on its own and get its own acceptance criteria). ... ...
Työnkulku käytännössä
Testasin työnkulkua keksityllä ostoslistasovelluksella, joka etsii reseptejä samankaltaisilla ainesosilla ja kokoaa niistä ostoslistan. Aloitin hahmottelemalla konseptitodistuksen sovellusideaa. Tämä tehtiin aloittamalla uusi sessio ja kertomalla orkestroijalle sovellusideasta. Päätimme aloittaa yhdestä ominaisuudesta, eli reseptien hausta. Orkestroija välitti alustavan idean vaatimusmäärittelyaliagentille, joka tarkensi vaatimuksia kysymysten avulla yhdessä ihmisen (minä) kanssa ja tuotti vaatimusmäärittelydokumentin. Tämän jälkeen ihminen pystyi hyväksymään tai hylkäämään ehdotuksen ensimmäisessä tarkastuspisteessä.
Hyväksytyt vaatimukset siirtyivät orkestroijan kautta arkkitehtuurialiagentille, joka tuotti kolme vaihtoehtoista ratkaisuehdotusta perusteluineen. Suunnitelmaa iteroitiin yhdessä tekoälyn kanssa, kunnes ihminen hyväksyi sen toisessa tarkastuspisteessä. Tämän jälkeen orkestroija käynnisti toteutusaliagentin.
Toteutusaliagentti rakensi suunnitelman mukaisen ratkaisun ja palautti tuloksen orkestroijalle, joka kutsui seuraavaksi testausaliagenttia. Testausaliagentti tarkisti toteutuksen toiminnan ja raportoi mahdolliset virheet korjattaviksi. Lopuksi se tuotti testiraportin ja orkestroija siirsi työn katselmointialiagentille.
Katselmointialiagentti teki koodikatselmuksen ja raportoi löydökset. Tämä toimi viimeisenä tarkastuspisteenä, jossa ihminen päätti hyväksytäänkö toteutus vai tehdäänkö uusi korjauskierros. Jos kaikki oli niin kuin pitikin, kierros oli valmis. Tällöin ihminen pystyi validoimaan toteutuksen oikeellisuuden ja tarvittaessa aloittamaan uuden session uudelle tehtävälle tai jatkamaan nykyisessä sessiossa, jos konteksti oli yhä ok.
Varsinkin alussa yksi kierros vei kauan aikaa, sillä en esimerkiksi määritellyt toiminnallisuuksia tarpeeksi hyvin tai validoinut suunnitelmia tarkasti, jolloin kehitys lähti väärään suuntaan. Huomasin tämän vasta lopussa validoinnin aikana. Mitä kauempana suunnitteluvaiheesta on, sitä kauemmin vie aikaa korjata väärin speksattu ominaisuus.
Mitä opin?
Opin tämän kokeilun aikana, että ohjelmistokehitys on pysyvästi muuttunut. Aiemmin tehtäviini kuului muun muassa suunnittelua, tiedon etsimistä ja myös vaihe, josta itse pidin, eli koodaaminen. Koodatessa olen päässyt aina lähes meditatiiviseen tilaan, jossa voin keskittyä siten, että ajantaju katoaa. Nyt tämä vaihe on kokonaan ulkoistettu tekoälylle, ja oma tehtäväni on lähinnä suunnittelua, ratkaisujen pohtimista ja validointia (eli lukemista, lukemista ja lukemista). Mitenköhän tämä muutos pitkällä aikavälillä vaikuttaa ohjelmistokehittäjien jaksamiseen ja viihtyvyyteen työpäivän aikana?
Tämän lisäksi pohdin, kuinka paljon työaikaa moniagenttinen ohjelmistokehitys vapauttaa. Suunnitteluvaiheet vaativat ihmiseltäkin jatkuvaa ajattelua, mutta toteutusvaihe ja testausvaihe ovat sellaisia, joihin mielestäni agenteille voi antaa melko vapaat kädet, jos agentti todistetusti tuottaa riittävän hyvää koodia ja ihminen tekee validoinnin huolella. Itse tahdon agentin kysyvän lupaa kaikelle ulospäin menevälle liikenteelle sekä esimerkiksi uusien kirjastojen asentamiselle. Mutta mitä tehdä silloin, kun agentti tekee pitkään tehtäviä ilman tarvetta ihmisen palautteelle?
Jos tarkastuspisteet on konfiguroitu tiukoiksi, tällaista vapautuvaa työaikaa ei välttämättä edes ole. Minuutin tai kahden tauot agentin kysymysten välillä ovat niin lyhyitä, ettei kontekstin vaihtaminen toiseen tehtävään kannata. Silloin menee taas paljon aikaa, kun pitää agentin kysyessä palata takaisin edelliseen tehtävään. Mutta jos agenteilla on enemmän päätösvaltaa, voi ihmiselle vapautua lisää työaikaa. Silloin voi miettiä, mitä vapautuvalla työajalla tekee. Toinen kysymys on, milloin palataan agentin luo, jos se vaatii huomiota. Palataanko aina heti vai esimerkiksi ennalta määritellyn ajan jälkeen.
Alla muutamia mietintöjä kokeilun ajalta:
Agenttien konfigurointi on jatkuva prosessi. Jos valmiita toimintamalleja ei ole, prosesseja kannattaa jatkuvasti parantaa ja jakaa esimerkiksi versionhallinnan kautta. Myös organisaatioiden ja tiimien olisi hyvä kehittää omia prosessejaan ja pohjiaan tähän liittyen. Jos jokin tuntuu hankalalta, pohdi, miten sitä saisi helpotettua konfiguraation avulla.
Kontekstia on hallittava aktiivisesti. Session muisti on rajallinen, joten selkeä rajaus ja uusien ominaisuuksien erottaminen omiin sessioihinsa ovat tärkeitä.
Tee tokenitehokasta kehitystä. Tähän vaikuttaa useampi asia, kuten edellä mainittu kontekstin hallinta. Lisäksi ohjelmiston suunnittelu ja Clauden konfigurointi ovat tärkeitä, muuten käyttörajat tulevat helposti vastaan (tai joudut sijoittamaan tähän lisää rahaa).
Määrittele tehtävät riittävän hyvin. Tämä liittyy myös edelliseen kohtaan. Agentit toimivat parhaiten, kun tavoitteet, rajaukset ja epävarmuudet on kuvattu selkeästi. Näin vältät helpommin myös hallusinointia.
Ajattele, lue ja ymmärrä ennen kuin hyväksyt. Tekoälyn ehdotuksia, suunnitelmia ja koodia ei pidä hyväksyä sokeasti, vaan ihmisen on ymmärrettävä ne välttääkseen turhan työn ja virheet. Tämä on yllättävän hankalaa ja vaatii itsekuria. Validointi vie aiempaa enemmän aikaa, koska ominaisuuksia ei ole itse samalla tavalla miettinyt ja koodannut.
Tasapainota autonomia ja hallinta. Tiukempi ohjaus lisää kontrollia, kun taas suurempi autonomia tehostaa työtä mutta vähentää näkyvyyttä toteutukseen.
Seuraa ja validoi jatkuvasti. Agenttien toimintaa kannattaa tarkkailla ja ohjata tarvittaessa takaisin oikeille raiteille. Mitä kauemmin työtä tehdään väärään suuntaan, sitä kovempi työ on korjata toteutus vastaamaan haluttua lopputulosta.
Vastuu säilyy ihmisellä! Vaikka agentit toteuttavat työn, päätökset, ymmärrys ja lopullinen vastuu ovat edelleen ihmisellä. Mitä jos aikataulupaineessa pikaisesti ilman kunnollista katselmointia hyväksytty tekoälyn generoima koodi tuottaakin epätoivotun toiminnallisuuden tai jopa kriittisen haavoittuvuuden?
Yhteenvetona moniagenttinen ohjelmistokehitys nopeuttaa ohjelmistokehitystä ja poistaa toistuvat, tylsät koodausvaiheet. Se ei kuitenkaan poista tarvetta suunnittelulle, vaan korostaa sitä entisestään. Kokeilu osoitti, että puutteellinen vaatimusmäärittely tai suunnitelma kertautuu helposti koko työnkulkuun ja näkyy vasta katselmoinnin tai validoinnin aikana, jolloin korjaaminen on huomattavasti hitaampaa.
