Laatuinsinöörityö osaksi agenttien työnkulkua

Shift in: laadunvarmistus agentin silmukkaan

”Seuraavien viiden vuoden aikana tapahtuu enemmän muutoksia kuin viimeisten 40 vuoden aikana.” — Martin Woodward, VP Developer Relations, GitHub (2024)

Jos olet seurannut koodausagentteja vuosina 2025 ja 2026, lainaus ei enää kuulosta liioittelulta vaan kuvaukselta todellisuudesta. Agentit lukevat nyt koodia, ajavat testejä, muokkaavat tiedostoja, luovat pull requesteja ja päättelevät virheiden syitä. Ne eivät ole enää automaattista täydennystä, vaan itsenäisiä toimijoita, jotka havainnoivat ympäristöä, tekevät päätöksiä ja muuttavat järjestelmän tilaa.

Tämä aiheuttaa ongelman meille, joille laatu on tärkeää. Tutut toimintamallit — shift left, jolla virheet pyritään havaitsemaan varhain, ja shift right, jolla opitaan tuotannosta — suunniteltiin maailmaan, jossa ihmiset lukevat pipelinen tuloksia ja toimivat niiden perusteella. Agentit eivät lue ihmisiä. Ne lukevat työkaluja. Jos siis haluamme laadunvarmistuksen vaikuttavan siihen, mitä agentti tekee seuraavaksi, tarvitsemme uuden suunnan. Kutsun sitä nimellä shift in.

Tässä kirjoituksessa avaan, mistä idea syntyy, miksi se on tärkeä ja miltä se näyttää käytännössä. Matkan varrella määrittelemme modernien tekoälyagenttien rakennuspalikat — kontekstin, työkalut, taidot, hookit ja ReAct-silmukan — jotta puhumme samoista asioista ennen kuin pääsemme pääasiaan.

Kaksi vanhaa testausongelmaa agentteihin sovellettuna

Kun tarkastelen mitä tahansa tekoälyjärjestelmää — avustajaa, agenttia tai agenttiparvea — pidän hyödyllisenä, että sen (yli)yksinkertaistaa kahdeksi ongelmaksi, jotka jokainen testauksen taustan omaava jo tuntee:

• Viestintäongelma: Miten kerromme järjestelmälle, mitä haluamme? Testauksen kielellä tämä on kuilu tavoitteen ja määrittelyn välillä. Agenttipohjaisissa järjestelmissä se on kuilu käyttäjän tavoitteen sekä promptin, kontekstin ja ohjeiden välillä, jotka malli todella vastaanottaa.

• Oraakkeliongelma: Mistä tiedämme, että tulos on oikein? Testauksen kielellä kyse on testioraakkelista — totuuden lähteestä, joka päättää, meneekö testi läpi vai ei. Agenttipohjaisissa järjestelmissä se tarkoittaa evaluointia, human-in-the-loopia, LLM-as-judgea, pipeline-tarkistusta ja lopulta tyytyväistä asiakasta.

Jokainen agenttipohjaisen kehityksen suunnittelupäätös on pohjimmiltaan yritys vähentää toista näistä kahdesta ongelmasta. Paremmat promptit, rikkaampi konteksti, Retrieval-Augmented Generation — kaikki liittyvät viestintään. Evalit, suojakaiteet, regressiotestit ja arvioijat — kaikki liittyvät oraakkeliin. Kun näet nämä kaksi saraketta, rakennuspalikat asettuvat paikoilleen.

Tekoälyagentin rakennuspalikat

Ennen kuin voimme puhua siitä, mihin laatu sopii, tarvitsemme yhteisen sanaston. Tekoälytyökalut kehittyvät nopeasti, ja sama sana tarkoittaa usein eri asioita eri puheenvuoroissa. Näin käytän termejä tässä kirjoituksessa.

Large Language Model (LLM): Agentin päättely-ydin. Kun sille annetaan konteksti, se ennustaa seuraavat tokenit. Claude, GPT, Gemini ja Llama ovat LLM-malleja. Malli ei ole agentti, vaan sen sisällä oleva aivot.

Konteksti: Kaikki, minkä LLM voi ”nähdä” kullakin vuorolla: järjestelmäprompti, keskusteluhistoria, työkalujen määritelmät, haetut dokumentit ja viimeisin työkalun tulos. Konteksti-ikkunat ovat rajallisia, minkä vuoksi niiden hallinta on oma osaamisalueensa — katso.

Järjestelmäprompti: Kontekstin alkuun sijoitetut ohjeet, jotka määrittävät agentin roolin, toiminnan ja rajoitteet. Ajattele sitä agentin tehtävänkuvana ja toimintaperiaatteina.

Muisti: Mekanismi, jolla tietoa säilytetään ja haetaan vuorojen tai sessioiden välillä. Lyhytaikainen muisti sijaitsee konteksti-ikkunassa, pitkäaikainen muisti vektoridatabasessa, tiedostossa tai molemmissa.

Retrieval-Augmented Generation (RAG): Ennen vastaamista agentti hakee tietolähteestä olennaiset osiot ja lisää ne kontekstiin. RAG auttaa agenttia pysymään kiinni toimialasi terminologiassa, koodikannassasi, dokumentaatiossasi ja tiketeissäsi hallusinoinnin sijaan.

Vektoridatabasi: Tietokanta, joka tallentaa tekstin numeerisina upotuksina, jotta haku voidaan tehdä merkityksen eikä avainsanojen perusteella. Useimpien RAG-järjestelmien taustalla oleva tekniikka.

Työkalu: Kutsuttava funktio, jonka avulla agentti toimii maailmassa: lukee tiedoston, ajaa komennon, kysyy APIa tai suorittaa koodia. Jokaisella työkalulla on nimi, kuvaus ja syöteskeema. LLM päättää, milloin mitäkin työkalua kutsutaan; orkestroija suorittaa kutsun käytännössä.

Työkalun käyttö: LLM tuottaa jäsennellyn pyynnön työkalun kutsumiseksi, orkestroija suorittaa sen ja tulos palautetaan kontekstiin. Työkalujen käyttö muuttaa chatbotin agentiksi.

MCP: Model Context Protocol. Avoin standardi, jolla agentit yhdistetään työkaluihin ja tietolähteisiin ilman, että joka kerta tarvitsee kirjoittaa omia integraatioita. Ajattele sitä tekoälytyökalujen USB-C:nä. Anthropic esitteli sen vuoden 2024 lopulla — katso.

Taito: Paketoitu kyvykkyys — yleensä kansio, joka sisältää kuvauksen, ohjeet sekä skriptit tai viitteet, joita agentti tarvitsee tietyn tehtävän hyvään suorittamiseen. Taitojen avulla voit koodata toimintatavan ”näin teemme X:n täällä” muotoon, jonka agentti voi ladata tarpeen mukaan. Ne eroavat työkaluista laajuudeltaan: työkalu tekee yhden asian, kun taas taito yhdistää tietämyksen ja toimintatavan kokonaista tehtävää varten.

Hook: Deterministinen valvontapiste, joka käynnistyy automaattisesti työkalun käytön yhteydessä. PreToolUse ajetaan ennen työkalun kutsumista (estää, muokkaa tai sallii). PostToolUse ajetaan sen jälkeen (validoi, kirjaa tai muuntaa). Stop ajetaan, kun agentti uskoo olevansa valmis (pakottaa vielä yhden tarkistuksen). Hookien avulla voit rakentaa tinkimättömät säännöt silmukkaan ilman, että luotat mallin muistavan ne.

Suojakaide: Turvakerros, joka suodattaa LLM:ään menevän ja siitä tulevan sisällön — estää prompt injectionin, puhdistaa henkilötiedot ja kieltäytyy vaarallisista toimista. Suojakaiteet ovat rajapinnassa, hookit silmukan sisällä.

Eval: Agentin testi. Se muistuttaa yksikkötestiä, mutta syöte on epämääräinen (tavoite) ja tuloste on epämääräinen (etenemispolku tai artefakti), joten myös väittämä on epämääräinen — usein arviointikriteeristö, jonka arvioijamalli tai ihminen pisteyttää.

Orkestrointi: Ohjauslogiikka, joka pyörittää silmukkaa: hakee uusimman viestin, kutsuu LLM:ää, suorittaa työkalukutsut ja päättää, milloin lopetetaan. Orkestroija on tavallista koodia, LLM hoitaa päättelyn. Niiden sekoittaminen keskenään on yksi yleisimmistä virheistä agenttien suunnittelussa.

ReAct: Päättely → Toiminta → Havainnointi. Tämän päivän vallitseva agenttiarkkitehtuuri. Jokaisella kierroksella LLM päättelee tavoitteen pohjalta, valitsee toiminnon, orkestroija suorittaa sen ja tuloksesta tulee uusi havainto seuraavaa kierrosta varten. Alkuperäinen artikkeli: Yao et al., 2022.

Chatista agentiksi: ReAct-silmukka

Tavallinen chat-avustaja toimii yhdellä kierroksella. Lähetät kehotteen, se lähettää vastauksen, ja teet sillä jotain. Malli ehdottaa, ihminen toteuttaa. Ei palautesilmukkaa, ei työkaluja, ei pääsyä tiedostoihin.

Koodausagentti on erilainen. Sille annetaan tavoite ja työkalupakki, minkä jälkeen se toimii silmukassa. Se lukee tiedostoja, kirjoittaa koodia, ajaa testejä, havainnoi virheitä ja yrittää uudelleen. Monimutkaiset tehtävät vaativat tavallisesti 20–80 kierrosta.

Yksi ReAct-silmukan kierros:

1. Vastaanota: Orkestroija lisää uusimman viestin – käyttäjän syötteen tai työkalun tuloksen – keskusteluhistoriaan.

2. Ajattele: LLM lukee koko kontekstin, päättelee ja päättää: tuottaako tekstiä, kutsuuko työkalua vai päättääkö vuoron.

3. Toimi: Orkestroija tarkistaa lopetussyyn. Työkalun käyttö → suorita se. Vuoron päättäminen → tehtävä valmis.

4. Havainnoi: Työkalun tuloste lisätään työkalun viestinä. Silmukka käynnistyy uudelleen rikastetulla kontekstilla.

Kaksi asiaa ympäröi tätä silmukkaa ja ovat tarinamme kannalta olennaisia. Ensinnäkin enimmäiskierroksia, -tokeneita ja -kustannuksia koskevat suojarajat – ilman niitä orkestroija pyörisi ikuisesti. Toiseksi keskeytyskohdat, jotka mahdollistavat human-in-the-loop-tauot korkean riskin toimissa, kuten poistamisessa, käyttöönotossa ja ulkoisissa API-kutsuissa.

Tätä silmukkaa laatuinsinöörien on mietittävä. Ei arkkitehtuurikaavion DevOps-silmukkaa – se on ulompi silmukka. ReAct-silmukka on sisempi silmukka, joka suoritetaan satoja kertoja tehtävää kohden ja jossa agentti tekee varsinaiset päätöksensä.

Mihin erikoistuneet agentit sijoittuvat SDLC:ssä

Tarkastellaan koodausagenttia laajemmin ja katsotaan, miten erikoistuneet agentit sijoittuvat tuttuun DevOps-silmukkaan – Plan, Design, Code, Build, Test, Release, Deploy, Operate, Monitor. Voimme jo sijoittaa agenttitiimit sen eri vaiheisiin:

• Vasemmalla määrittelyagentit: ne tuottavat UX-briefit, käyttäjäpersoonat, palvelupolut, BDD/ATDD-määrittelyt ja avainsanaohjatut testirungot. Testaus siirtyy aiemmaksi – klassinen shift left.

• Oikealla CD pipeline -agentit: ne ajavat hyväksymis- ja suorituskykytestejä staging-ympäristössä, ottavat canary-julkaisuja käyttöön, havainnoivat järjestelmää sekä käynnistävät rollbackit ja roll-forwardit. Palaute tuotannosta – klassinen shift right.

Tuttua aluetta. Olemme puhuneet shift leftistä ja shift rightistä jo vuosia, ja samat periaatteet pätevät edelleen, vaikka silmukassa toimijana on agentti. Mutta laadulla on nyt myös kolmas suunta, eikä se sijaitse SDLC:n ulkoreunalla lainkaan.

Kolme suuntaa laatuinsinöörityölle agenttipohjaisessa kehityksessä

Samat Quality Engineering -käytännöt. Palautteen vastaanottajat ovat erilaiset.

← Shift left – Määrittelyagentit: Ihmiset ja agentit lukevat määrittelyjä. Quality Engineering muovaa tarkoitusta ennen kuin koodia on olemassa: UX-suunnittelubriefit, käyttäjäpersoonat/-polut/-tarinat, BDD/ATDD-määrittelyt ja avainsanaohjattu hyväksymistestien generointi. Kaikki viestivät tarkoituksesta. Käytä omia agentteja, jotta suunnittelukäytännöt ovat väistämätön osa työtä.

↓ Shift in – ReAct-silmukan sisällä: Koodausagentti toimii ohjeidensa mukaisesti ja käyttää taitoja ongelmien ratkaisemiseen, minkä jälkeen se lukee työkalun tulosteen. Quality Engineering -käytännöt ohjaavat oikeaan toimintaan ja muuttuvat työkaluiksi, joita agentti kutsuu jokaisella kierroksella. Hyvin määritelty Test Design -taito auttaa agenttia määrittämään arvokkaita testitapauksia. Yksikkötestit, API-testit, paikalliset integraatiotestit ja jatkuvat testausjaksot toimivat nopeana palautteena sisemmässä silmukassa.

Shift right → – CD pipeline -agentit: Tuotanto toimii oraakkelina silmukan sulkemiseksi: hyväksymistestit staging-ympäristössä, suorituskyvyn vertailumittaus tuotannossa, canary-julkaisu/dark launch vaikutusalueen rajaamiseksi, rollback/roll-forward nopeaa reagointia varten sekä sen havainnointi, miten todelliset käyttäjät kohtaavat järjestelmän. Kaikki laatuinsinöörityön käytännöt varmistavat oikeellisuutta ja tarjoavat lopulta palautetta.

Shift in: Laatuinsinöörityö agentin silmukan sisällä

Tässä on ydinasia. Koodausagentit hahmottavat maailman työkalujen tulosteiden kautta. Se on niiden koko aistikerros. Kaiken palautteen, johon haluamme niiden reagoivan, on saavuttava ReAct-silmukan sisälle jäsenneltynä työkalutuloksena.

Tämä tarkoittaa, että laatuinsinöörityöllä on uusi palautteen vastaanottaja.

Shift in -ajatus: jos haluat laadun vaikuttavan siihen, mitä agentti tekee seuraavaksi, laadun on oltava silmukan sisällä – työkaluna, jota agentti voi kutsua, automaattisesti käynnistyvänä hookina, taitona, jonka agentti voi ladata, tai evalina, joka arvioi etenemistä. CI/CD-putkesta tulee agentille koneellisesti luettavaa aistipalautetta, mutta mitä muuta palautetta voimme sille antaa?

Konkreettisesti shift in tarkoittaa neljän QE-käytännön kerroksen rakentamista uudelleen niin, että agentti on niiden lukija.

1. Quality Engineering -käytännöt ohjaavat toimintaa

Tarvitsemme agenttipohjaiseen maailmaan hyvin määritellyn ohjetiedoston, joka keskittyy laatunäkökohtiin, perusteellisesti tarkastetun ja täsmällisen taidon, joka kertoo agentille, MITEN tietyt ongelmat ratkaistaan, tai jopa erikoistuneen aliagentin, joka antaa asiantuntija-arvion tai hoitaa sille delegoituja tehtäviä. Näin saamme Quality Engineering -käytäntömme agentin käyttöön ja äänemme kuuluviin.

2. Testit työkaluina, joita agentti kutsuu jokaisella iteraatiolla

Muutamassa sekunnissa ajettava yksikkötestisarja, joka palauttaa jäsennellyn onnistumis-/epäonnistumisraportin, on täydellinen ReAct-havainto. Agentti kirjoittaa funktion, kutsuu testaustyökalua, lukee epäonnistumiset, korjaa koodin ja kutsuu työkalua uudelleen. Näin silmukka toimii. Kuvittele sama API-sopimustesteillä, nopeilla integraatiotesteillä ja muuttuneiden rivien mutaatiotesteillä. Jokainen nopea, deterministinen ja jäsennelty signaali, jonka saat silmukan sisään, estää agenttia harhailemasta – ja säästää sinut sen harhailun siivoamiselta myöhemmin.

3. Hookit deterministisinä suojakaiteina ja vaatimustenmukaisuuden varmistajina

PreToolUse-hook voi estää tuhoavan komennon ennen sen suorittamista. PostToolUse-hook voi edellyttää lint-tarkistuksen suorittamista jokaisen tiedostomuokkauksen jälkeen tai pakottaa kirjoittamaan auditointilokin. Stop-hook voi kieltäytyä merkitsemästä tehtävää valmiiksi, kunnes testit menevät läpi ja kattavuus ylittää raja-arvon. Hookien avulla et enää toivo agentin muistavan noudattaa standardejasi, vaan varmistat niiden noudattamisen. Niissä DoR-/DoD-tarkistuksesi, nopeat SAST-skannauksesi, riippuvuuksien haavoittuvuusskannauksesi, tyylisääntösi – koko tinkimätön kerroksesi – muuttuvat aidosti tinkimättömiksi.

4. Pull request -portit siltana sisäisen ja ulkoisen silmukan välillä

Agentin paikallinen silmukka ajaa yksikkö-, API- ja integraatiotestit nopeasti. Pull request -portti lisää hitaammat ja kalliimmat tarkistukset: kattavan SASTin, täydellisen regression, kompleksisuusanalyysin ja kattavuusportit. Tässä sisäinen ReAct-silmukka kohtaa ulkoisen DevOps-silmukan. Agentti näkee PR-tarkistuksen tuloksen uutena työkaluhavaintona ja reagoi siihen: korjaa epäonnistumiset, perustelee virheelliset positiiviset havainnot ja pyytää ihmisen arviota, jos jää jumiin.

Huomaa, mikä ei muuttunut. Teemme edelleen staattista analyysiä. Ajamme edelleen yksikkötestejä. Käytämme edelleen kattavuusportteja. QE-käytännöt ovat samat. Muuttui se, kuka tai mikä ajaa komennon, lukee tuloksen ja päättää, mitä tehdään seuraavaksi. Siinä on koko juju.

Mitä tämä tarkoittaa, jos työskentelet laadun parissa

QE-ammattilaisille nousee esiin kolme keskeistä vaikutusta.

Testeilläsi on uusi yleisö: Jos testitulosten käyttäjä on agentti, tulostusmuoto on yhtä tärkeä kuin testilogiikka. Kokeneen ihmisen tulkitsemat kryptiset stack tracit eivät ole agentille hyviä signaaleja. Jäsennelty, nimetty ja deterministinen tuloste – JSON-raportit, koneellisesti luettavat diffit, selkeät assertit – antaa agentille jotain, mihin se voi toimia.

CI:stäsi on tulossa API: Putkia ovat aina lukeneet ihmiset dashboardien ja PR-tarkistusten kautta. Nyt agentit lukevat niitä työkalukutsujen kautta. Sama putki palvelee molempia yleisöjä, mutta API-rajapinta – osa, jota agentti kutsuu ja jäsentää – on suunniteltava harkitusti. Continuous delivery for ML käsitteli tätä ajatusta jo aiemmin; agenttipohjainen kehitys vie sitä pidemmälle.

Roolisi on agenttia edeltävässä vaiheessa: Hyvien evalien rakentaminen, työkalusopimusten suunnittelu, testaamiseen liittyvän osaamisen kokoavien taitojen ja ohjetiedostojen kirjoittaminen sekä hook-kerroksesta vastaaminen ovat QE-työtä agenttipohjaisessa kokonaisuudessa. Työ ei katoa. Se siirtyy silmukan sisään.

Silmukan sulkeminen

Shift left oli oikea vastaus, kun silmukkaa ohjasivat ihmiset ja hitain vaihe oli julkaisun jälkeinen uudelleentyö. Shift right oli oikea vastaus, kun tuotannosta tuli oma totuuden lähteensä ja meidän piti oppia siitä. Molemmat ovat yhä oikeita.

Shift in on vastaus siihen silmukan osaan, jota agentit nyt ohjaavat. Agentin havainnointi rajoittuu siihen, minkä se voi lukea työkalun tuloksena, joten myös laatupalautteen on oltava siellä. Taidot eivät muutu – testauksen perusteet, oraakkeliongelma, viestintäongelma ja epäonnistumisia varten suunnittelun kurinalaisuus. Muuttuu palautteen lukija, ja se muuttaa kaiken siinä, miten paketoimme palautteen.

Seuraavat viisi vuotta tuovat todella enemmän muutosta kuin edelliset neljäkymmentä. Laadunhallinta pääsee silmukkaan – kirjaimellisesti – jos päätämme sijoittaa sen sinne.