Agenttipohjainen tekoäly tarvitsee lisää testaajia, ei vähemmän

Agenttipohjainen tekoäly mullistaa tapaa, jolla ohjelmistoja julkaistaan. Avustajat laativat pull request -ehdotuksia, agentit käynnistävät migraatioita ja koodikatselmointibotit väittävät muutosta turvalliseksi, ennen kuin ihminen ehtii juoda kahvinsa loppuun. Alalla tämä nähdään usein keinona vähentää laadunvarmistuksen henkilöstöä. Näkemys on nurinkurinen. Kun koneet kirjoittavat yhä suuremman osan koodista, harvinainen taito ei ole koodin tuottaminen vaan sen riippumaton varmentaminen.

Vuoden 2025 Stack Overflow -kehittäjäkyselyssä selvisi, että 84 % vastaajista käyttää tai aikoo käyttää tekoälytyökaluja ohjelmistokehityksessä ja että 51 % ammattikehittäjistä käyttää niitä päivittäin. Myönteinen suhtautuminen laski 60 prosenttiin, ja useampi kehittäjä suhtautuu aktiivisesti epäillen tekoälyn tarkkuuteen (46 %) kuin luottaa siihen (33 %). Yleisin turhautumisen aihe, jonka mainitsi 66 %, olivat ratkaisut, jotka ovat melkein oikein mutta eivät aivan. Google Cloudin vuoden 2025 DORA-tutkimuksen mukaan tekoälyn käyttöaste ohjelmistokehityksen ammattilaisten keskuudessa oli 90 prosenttia, ja yli 80 prosenttia kertoi tekoälyn parantaneen tuottavuutta. Silti vain 24 prosenttia ilmoitti luottavansa tekoälyyn erittäin paljon tai paljon. Juuri luottamuksen puute hyödyllisyyden rinnalla kasvattaa testaajan työn määrää, ei vähennä sitä.

Nopeus ei ole todiste

Työskentelen ohjelmiston laadunvarmistusinsinöörinä ja keskityn agenttipohjaisen tekoälyn testaukseen sekä tekoälyn tuottaman koodin CI-portteihin. Otimme organisaation sisällä käyttöön pull request -katselmointityökalun ja testitapausten generaattorin. Molemmat ovat luonnostelutyökaluja. Kumpikaan ei arvioi omaa työtään. Tämä sääntö on tärkeä, koska agentit puhuvat varmana. Varmuus ei tarkoita oikeellisuutta.

Opimme tämän kantapään kautta. Tekoälyn rakentaman pull request -katselmointityökalun kokeilussa yksi muutos läpäisi CI:n alle 4 minuutissa. Kaksi päivää myöhemmin jatkokäsittelyn koontinäyttö näytti mahdottomia lämpötiloja. Yhdellä koodipolulla oli Celsius-asteiden muunnos Fahrenheit-asteiksi kääntynyt väärin, eikä testikokonaisuus koskaan suorittanut kyseistä polkua. CI-putki näytti vihreää. Tuote oli väärässä. Vihreä CI, jossa vaikeaa kysymystä ei koskaan esitetty, on pelkkää teatteria.

Tämä tapaus liittyy laajempaan ilmiöön. CodeRabbitin raportissa tekoälyn ja ihmisen tuottamasta koodista analysoitiin 470 avointa GitHub-pull requestia (320 tekoälyn ja ihmisen yhdessä laatimaa, 150 pelkästään ihmisen laatimaa). Tekoälyn tuottamissa muutoksissa oli kaikkiaan noin 1,7 kertaa enemmän ongelmia. Logiikkaan ja oikeellisuuteen liittyvät ongelmat olivat 75 % yleisempiä, ja tietoturvahavaintoja oli jopa 2,74 kertaa enemmän. Veracoden vuoden 2026 generatiivisen tekoälyn kooditurvallisuusraportissa testattiin malleja erilaisissa tietoturvatehtävissä. Niiden tietoturvatehtävien keskimääräinen läpäisyaste oli 56 %, tuskin lainkaan enemmän kuin edellisen raportin 55 %, ja noin 44 % tekoälyn koodintuotantotehtävistä toi mukanaan tunnetun haavoittuvuuden. Syntaksiongelmat on lähes ratkaistu. Turvallinen ja oikea toiminta ei ole. Testaajat ovat niitä, jotka eivät suostu sekoittamaan näitä kahta asiaa.

Keksityt riippuvuudet ovat testausongelma

Koodin generointi voi myös keksiä ohjelmistopaketteja. USENIX Security 2025 -tutkimuksessa ”Meillä on paketti sinulle!” arvioitiin pakettien hallusinaatioita 16 koodia tuottavalla LLM-mallilla ja 576 000 näytteellä. Kaupalliset mallit hallusinoivat paketteja keskimäärin vähintään 5,2 prosentissa tapauksista; avoimen lähdekoodin mallit keskimäärin 21,7 prosentissa, ja niiden tuottamat keksityt pakettinimet olivat 205 474 yksilöllistä nimeä. Pysyvästi rekisteröidyt haamupaketit tarjoavat valmiin kohteen keksittyjen pakettinimien kaappaamiselle: hyökkääjät rekisteröivät keksityn nimen ja odottavat, että kehittäjä tai agentti asentaa paketin.

Riippuvuuksien alkuperän tarkistusten on kuuluttava samaan tasoon toiminnallisten testien kanssa. Jos agentti keksii NuGet- tai npm-paketin, yhdistämisen pitää epäonnistua jo ennen kuin kukaan ehtii väitellä yksikkötestien perusteellisuudesta. Alkuperän varmistaminen ei ole valinnaista siisteyden ylläpitoa. Se on tekoälyn tuottamien muutosten laadunvarmistusportti.

Agenttien mukana skaalautuvat portit

Kun toteutimme koko organisaation laajuisen .NET 8:sta .NET 10:een siirtymisen tekoälyavusteisen automaation avulla noin kahdessa viikossa, vastasin laadunvarmistusporteista. Nopeus oli todellista. Samoin oli tarve tarkistuksille, jotka eivät usko agentin yhteenvetoa. Muutettuun koodiin soveltamani tarkistukset ovat seuraavat:

• Mutaatiotestauksen tulostavoite on muutetussa logiikassa 60–70 prosenttia, jotta testikokonaisuus löytää todelliset virheelliset muunnelmat eikä vain kata koodirivejä
• Ominaisuuspohjaiset testit riskialttiille logiikalle, jonka toimintaa yksittäiset esimerkit eivät määrittele riittävän tarkasti
• Riippuvuuksien alkuperän tarkistukset keksittyjen pakettinimien kaappaamisen ja hallusinoitujen pakettien varalta
• Duplikaatio- ja muutosmäärän signaalit, jotka paljastavat agenttien kopioi ja liitä -sähellyksen
• Agentin väitteiden, kuten ”migraatio valmis”, riippumaton varmentaminen, sillä väite on vain hypoteesi, kunnes sen tueksi saadaan näyttöä

Mutaatiotestauksen tulos ei ole turhamaisuusmittari. Se kertoo, huomaavatko testit tarkoituksella aiheutetun virheen. Kattavuus voi parantua, vaikka testikokonaisuus jättäisi edelleen Celsius-asteiden muunnospolun testaamatta. Ominaisuuspohjaiset tarkistukset varmistavat, että järjestelmää koskeva malli pätee eri arvoalueilla eikä vain yhdessä suotuisassa tapauksessa. Alkuperän varmistaminen sulkee pakettivaraston oven. Muutosmäärän ja duplikaatioiden seuranta paljastaa agentin tavan kirjoittaa sama ajatus uudelleen kolmella tavalla. Yhdessä nämä muodostavat toimintatavan: oletetaan agentin olevan väärässä, kunnes testikokonaisuus todistaa muuta. Pidän tämän periaatteen mielessä koodikatselmoinneissa.

Mikään tästä ei korvaa API-testausta, todennuksen testausta, savutestausta tai käyttöliittymän automatisoitua testausta. FlaUI ja PowerShell löytävät edelleen ongelmia, joita API:t eivät paljasta. NuGetin, MSI:n ja MSM:n kautta tapahtuva paketointi vaatii yhä asennuksen ja hiljaisen asennuksen polun validointia. Agenttipohjaiset työnkulut kasvattavat määrää. Ne eivät tee näistä testauskäytännöistä tarpeettomia.

Lisää testaajia, erilaista työtä

Pelätään, että agentit kirjoittavat testit ja ihmisistä tulee tarpeettomia. Agentit voivat laatia testitapauksia, mutta niiden ei pidä hyväksyä omia luonnoksiaan. Stack Overflow’n vastaajille, jotka suunnittelevat käyttävänsä tekoälyä testaukseen tulevaisuudessa, ihmisten epäluottamus tekoälyyn oli yhä keskeinen asia: tärkein syy pyytää apua toiselta ihmiseltä oli se, etteivät vastaajat luottaneet tekoälyn vastauksiin. Tämä vaisto on alan vahvuus.

Tässä on tärkeää palkata ja tukea ihmisiä, joiden tausta ei ole perinteinen. Siirryin laadunvarmistukseen työskenneltyäni HR-toiminnoissa ja datan parissa, suoritin tietojärjestelmätieteen maisterintutkinnon UMBC:ssä toukokuussa 2024 ja teen nyt päivittäin töitä sen eteen, että agenttipohjaisen tekoälyn laadunvarmistuksen portit toimivat käytännössä. Agenttipohjainen tekoäly ei jää odottamaan yhdenlaista ansioluetteloa. Se tarvitsee lisää ihmisiä, jotka osaavat suunnitella näyttöä, ei vähemmän ihmisiä, jotka hyväksyvät vihreät koontiversiot kyseenalaistamatta niitä.

Tuotteeseen liittyvä kysymys on yksinkertainen. Jos agentit julkaistaan nopeammin kuin varmennus ehtii ajatella, kyse ei ole tuottavuuden kasvusta. Kyse on lykätystä häiriötilanteesta. Panosta testaajiin, jotka suhtautuvat epäillen jokaiseen agentin väitteeseen, integroivat mutaatiotestauksen ja alkuperätietojen seurannan CI-prosessiin sekä säilyttävät riippumattoman harkintakykynsä juuri siellä, missä malli on sujuvimmillaan ja epäluotettavimmillaan. Agenttipohjainen tekoäly tarvitsee lisää testaajia, ei vähemmän.