Agentbaserad AI behöver fler testare, inte färre

Agentbaserad AI håller på att förändra hur programvara levereras. Assistentverktyg tar fram utkast till pull-förfrågningar, agenter skapar migreringar och granskningsbotar hävdar att en ändring är säker innan någon människa hunnit dricka upp kaffet. Branschen framställer ofta detta som en väg mot färre personer som arbetar med kvalitet. Det är helt bakvänt. När maskiner skriver en allt större del av kodbasen blir den sällsynta kompetensen inte att generera kod. Den består i att verifiera den oberoende.

I 2025 års utvecklarundersökning från Stack Overflow uppgav 84 % av de svarande att de använder eller planerar att använda AI-verktyg i utvecklingsarbetet, och 51 % av yrkesverksamma utvecklare använder dem dagligen. Den positiva inställningen sjönk till 60 %, och fler utvecklare misstror aktivt AI:s träffsäkerhet (46 %) än litar på den (33 %). Den vanligaste frustrationen, som 66 % nämnde, var lösningar som nästan är rätt, men ändå inte riktigt. DORA:s forskning från 2025 visade att 90 % av yrkesverksamma inom programvaruutveckling använder AI och att över 80 % ansåg att AI förbättrade produktiviteten, men bara 24 % uppgav att de hade mycket eller ganska stort förtroende för AI. Nytta utan förtroende är precis den situation som utökar testarens arbete, inte minskar det.

Hastighet är inget bevis

Jag arbetar som kvalitetsingenjör inom programvara med fokus på agentbaserad testning och CI-grindar för AI-skriven kod. Internt har vi tagit fram en granskare av pull-förfrågningar och en generator för testfall. Båda är verktyg som skapar utkast. Inget av dem rättar sina egna prov. Den regeln är viktig eftersom agenter uttrycker sig med säkerhet. Säkerhet är inte detsamma som korrekthet.

Vi fick lära oss det den dyra vägen. Under ett pilotförsök med en AI-byggd granskare av pull-förfrågningar godkändes en ändring av CI på under 4 minuter. Två dagar senare visade en nedströms instrumentpanel orimliga temperaturer. En felvänd omräkning från Celsius till Fahrenheit fanns i en kodväg som testsviten aldrig körde. Bygget var grönt. Produkten var felaktig. En grön CI-körning som aldrig ställde den svåra frågan är teater.

Den händelsen ingår i ett större mönster. CodeRabbits rapport om AI jämfört med mänsklig kodgenerering analyserade 470 pull-förfrågningar på GitHub med öppen källkod (320 med bidrag från både AI och människor, 150 enbart från människor). AI-författade ändringar ledde till ungefär 1,7 gånger fler problem totalt, med 75 % fler problem med logik och korrekthet och upp till 2,74 gånger fler säkerhetsbrister. Veracodes rapport om kodsäkerhet för generativ AI från 2026 testade modeller inom olika säkerhetsuppgifter och fann att den genomsnittliga andelen godkända säkerhetstester var 56 %, knappt förändrat från 55 % i den föregående rapporten, samtidigt som ungefär 44 % av uppgifterna för AI-kodgenerering ledde till en känd sårbarhet. Syntaxen är i stort sett löst. Säkert och korrekt beteende är det inte. Testare är de som vägrar att blanda ihop de två.

Påhittade beroenden är ett testproblem

Kodgenerering hittar också på paket. I säkerhetsforskningen från USENIX Security 2025, Vi har ett paket åt dig!, utvärderades påhittade paket i 16 kodgenererande LLM:er och 576 000 prover. Kommersiella modeller hittade i genomsnitt på paket i minst 5,2 % av fallen; för modeller med öppen källkod var genomsnittet 21,7 %, med 205 474 unika påhittade namn. Ihållande fantompaket skapar ett enkelt mål för så kallad slop-squatting: angripare registrerar det påhittade namnet och väntar på att en utvecklare eller agent ska installera paketet.

Kontroller av beroendens ursprung hör hemma på samma nivå som funktionstester. Om en agent hittar på ett NuGet- eller npm-paket ska sammanslagningen stoppas innan någon ens börjar diskutera om enhetstesterna var tillräckligt noggranna. Kontroll av ursprung är inte valfri hygien. Det är en kvalitetsgrind för AI-författade ändringar.

Grindar som skalar med agenter

När vi genomförde en organisationsomfattande uppgradering från .NET 8 till .NET 10 på ungefär två veckor med AI-stödd automatisering ansvarade jag för kvalitetsgrindarna. Det gick verkligen snabbt. Men det behövdes också kontroller som inte tog agentens sammanfattning för god fisk. De grindar jag kör på ändrad kod omfattar:

• Mål för mutationspoäng på mellan 60 % och 70 % för berörd logik, så att testsviten måste upptäcka verkliga mutationer och inte bara täcka kodrader
• Egenskapsbaserade tester för logik med hög risk, där exempel i sig inte specificerar beteendet tillräckligt
• Kontroller av beroendens ursprung för att upptäcka slop-squatting och påhittade paket
• Signaler om duplicering och kodomsättning som flaggar agenters planlösa kopierande och klistrande
• Oberoende verifiering av agenters påståenden, till exempel ”migreringen är klar”, eftersom ett påstående är en hypotes tills det finns belägg

Mutationspoäng är inget skönhetsmått. Det visar om testerna upptäcker ett avsiktligt fel. Kodtäckningen kan öka samtidigt som testsviten fortfarande missar Celsius-kodvägen. Egenskapsbaserade kontroller tvingar systemmodellen att hålla för olika värden, inte bara för ett enda gynnsamt scenario. Kontroller av ursprung stänger paketförrådet. Kodomsättning och duplicering fångar upp agenters vana att skriva om samma idé på tre olika sätt. Tillsammans ger de ett förhållningssätt: utgå från att agenten har fel tills testsviten bevisar motsatsen. Jag håller fast vid den principen vid granskning.

Inget av detta ersätter API-testning, autentiseringstester, röktester eller automatisering av användargränssnitt. FlaUI och PowerShell fångar fortfarande sådant som API:er missar. Paketering via NuGet, MSI och MSM kräver fortfarande validering av installationen och av installationsflödet i tyst läge. Agentbaserade arbetsflöden ökar volymen. De gör inte att de här disciplinerna blir överflödiga.

Fler testare, ett annat arbete

Farhågan är att agenterna skriver testerna och att människor blir överflödiga. Agenter kan utforma testfall. De bör inte själva godkänna sina utkast. Bland Stack Overflow-respondenter som planerar att använda AI för testning framöver står misstron mot AI fortfarande i centrum: det främsta skälet till att de skulle be en annan person om hjälp var att de inte litade på AI:s svar. Den instinkten är yrkets styrka.

Det är viktigt att anställa och ge förutsättningar för personer med okonventionella bakgrunder. Jag bytte till kvalitetsarbete efter en karriär inom HR-drift och data, tog en masterexamen i informationssystem vid UMBC i maj 2024 och ägnar nu dagarna åt att göra agentbaserade kvalitetsgrindar praktiskt användbara. Den agentiska AI:n kommer inte att vänta på att alla ska ha samma bakgrund. Den behöver fler människor som kan utforma evidens, inte färre som slentrianmässigt godkänner byggen som fått grönt ljus.

Produktfrågan är enkel. Om agenter levererar snabbare än er verifiering hinner tänka har ni inte ökat produktiviteten. Ni har skjutit upp en incident. Satsa på testare som ifrågasätter varje påstående från en agent, bygger in mutationstestning och proveniens i CI och behåller sitt oberoende omdöme där modellen är som mest välformulerad och minst tillförlitlig. Agentisk AI behöver fler testare, inte färre.