Shift in: ta in kvalitetsutveckling i agentloopen

Shift in: så får du in kvalitetsteknik i agentloopen

"De kommande fem åren kommer att innebära större förändringar än de senaste 40 åren." — Martin Woodward, VP Developer Relations, GitHub (2024)

Om du har följt kodningsagenter under 2025 och 2026 känns det citatet mindre som hype och mer som en beskrivning av verkligheten. Agenter läser nu kod, kör tester, redigerar filer, skickar pull requests och resonerar kring fel. De är inte längre autocomplete — de är autonoma aktörer som uppfattar en miljö, fattar beslut och förändrar tillstånd.

Det skapar ett problem för oss som bryr oss om kvalitet. De välkända arbetssätten — shift left för att fånga fel tidigt och shift right för att lära av produktion — utformades för en värld där människor läser resultat från pipelines och agerar utifrån dem. Agenter läser inte människor. De läser verktyg. Om vi vill att kvalitetsteknik ska påverka vad en agent gör härnäst behöver vi därför en ny riktning. Jag kallar den shift in.

I det här inlägget går vi igenom var idén kommer ifrån, varför den är viktig och hur den fungerar i praktiken. På vägen definierar vi byggstenarna i moderna AI-agenter — kontext, verktyg, skills, hooks och ReAct-loopen — så att vi har ett gemensamt språk innan vi kommer till huvudpoängen.

Två gamla testproblem, tillämpade på agenter

När jag tittar på ett AI-system — assistent, agent eller svärm — tycker jag att det är användbart att (över)förenkla det till två problem som alla med bakgrund inom testning redan känner igen:

• Kommunikationsproblemet: Hur berättar vi för systemet vad vi vill? Med testspråk handlar det om gapet mellan avsikt och specifikation. I agentbaserade system är det gapet mellan användarens mål och prompten, kontexten och instruktionerna som modellen faktiskt får.

• Orakelproblemet: Hur vet vi att resultatet är korrekt? Med testspråk handlar det om testoraklet — sanningskällan som avgör om testet godkänns eller underkänns. I agentbaserade system är det utvärderingen, människan i loopen, LLM-as-judge, pipeline-kontrollen och i slutänden den nöjda kunden.

Alla designbeslut inom agentbaserad utveckling handlar i slutändan om att minska ett av dessa två problem. Bättre promptar, rikare kontext och retrieval-augmented generation — allt handlar om kommunikation. Evals, skyddsräcken, regressionstester och bedömare — allt handlar om oraklet. När du ser de två kolumnerna faller byggstenarna på plats.

Byggstenarna i en AI-agent

Innan vi kan prata om var kvalitet passar in behöver vi ett gemensamt ordförråd. AI-verktyg utvecklas snabbt, och samma ord betyder ofta olika saker i olika presentationer. Så här använder jag termerna i det här inlägget.

Large Language Model (LLM): Agentens resonemangskärna. Med en given kontext förutsäger den nästa token. Modeller som Claude, GPT, Gemini och Llama är LLM:er. Modellen är inte agenten; den är hjärnan inuti den.

Kontext: Allt som LLM:en kan ”se” i en given tur: systemprompten, konversationshistoriken, verktygsdefinitionerna, hämtade dokument och det senaste verktygsresultatet. Kontextfönster är begränsade, vilket är anledningen till att det är en egen disciplin att hantera dem — se.

Systemprompt: Instruktionerna högst upp i kontexten som definierar agentens roll, beteende och begränsningar. Se den som agentens arbetsbeskrivning tillsammans med dess spelregler.

Minne: En mekanism för att behålla och hämta information mellan turer eller sessioner. Korttidsminnet finns i kontextfönstret, medan långtidsminnet finns i en vektordatabas, en fil eller båda.

Retrieval-Augmented Generation (RAG): Innan agenten svarar söker den i en kunskapskälla efter relevanta delar och lägger in dem i kontexten. RAG gör att en agent förblir förankrad i er domänterminologi, er kodbas, er dokumentation och era ärenden i stället för att hallucinera.

Vektordatabas: En databas som lagrar text som numeriska inbäddningar, så att den kan sökas utifrån betydelse i stället för nyckelord. Infrastrukturen bakom de flesta RAG-system.

Verktyg: En anropbar funktion som agenten använder för att agera i världen: läsa en fil, köra ett kommando, fråga ett API eller exekvera kod. Varje verktyg har ett namn, en beskrivning och ett indataschema. LLM:en avgör när den ska anropa vilket verktyg; orkestreraren kör det faktiskt.

Verktygsanvändning: När en LLM skickar en strukturerad begäran om att anropa ett verktyg, orkestreraren kör det och resultatet matas tillbaka till kontexten. Verktygsanvändning är det som förvandlar en chattbot till en agent.

MCP: Model Context Protocol. En öppen standard för att ansluta agenter till verktyg och datakällor utan att behöva skriva egna integrationer varje gång. Tänk USB-C för AI-verktyg. Anthropic introducerade det i slutet av 2024 — se.

Skill: En paketerad förmåga — vanligtvis en mapp med en beskrivning, instruktioner och eventuella skript eller referenser som agenten behöver för att utföra en specifik uppgift väl. Skills gör att du kan koda in ”så här gör vi X här” som något agenten kan läsa in vid behov. De skiljer sig från verktyg i omfattning: ett verktyg gör en sak, medan en skill samlar kunskap och procedurer för en hel uppgift.

Hook: En deterministisk kontrollpunkt som körs automatiskt i samband med verktygsanvändning. PreToolUse körs innan ett verktyg anropas (blockerar, ändrar eller tillåter). PostToolUse körs efteråt (validerar, loggar eller transformerar). Stop körs när agenten tror att den är klar (tvingar fram ytterligare en kontroll). Hooks gör att du kan bygga in regler som inte är förhandlingsbara i loopen, utan att behöva lita på att modellen kommer ihåg dem.

Skyddsräcke: Ett säkerhetslager som filtrerar det som går in i LLM:en och det som kommer ut — blockerar prompt injection, rensar PII och avvisar farliga åtgärder. Skyddsräcken finns vid gränsen; hooks finns inne i loopen.

Eval: Ett test för en agent. Som ett enhetstest, men indata är otydliga (ett mål) och utdata är otydliga (en process eller en artefakt), så även kontrollen är otydlig — ofta en bedömningsmall som poängsätts av en bedömningsmodell eller en människa.

Orkestrering: Kontrollogiken som kör loopen: hämtar det senaste meddelandet, anropar LLM, utför verktygsanrop och avgör när den ska avslutas. Orkestratorn är vanlig kod; LLM är den som resonerar. Att blanda ihop dem är ett av de vanligaste misstagen i agentdesign.

ReAct: Resonera → Agera → Observera. Dagens dominerande agentarkitektur. I varje iteration resonerar LLM kring målet, väljer en åtgärd, orkestratorn utför den och resultatet blir en ny observation som ligger till grund för nästa iteration. Ursprunglig artikel: Yao et al., 2022.

Från chatt till agent: ReAct-loopen

En vanlig chattassistent är en engångslösning. Du skickar en prompt, den skickar ett svar och du gör något med det. Modellen föreslår; människan utför. Ingen återkopplingsloop, inga verktyg och ingen filåtkomst.

En kodningsagent fungerar annorlunda. Den får ett mål och en uppsättning verktyg och kör sedan i en loop. Den läser filer, skriver kod, kör tester, observerar fel och försöker igen. Komplexa uppgifter kräver ofta 20 till 80 iterationer.

En iteration i ReAct-loopen:

1. Ta emot: Orkestratorn lägger till det senaste meddelandet – användarindata eller verktygsresultat – i konversationshistoriken.

2. Tänk: LLM läser hela kontexten, resonerar och beslutar: generera text, anropa ett verktyg eller avsluta turen.

3. Agera: Orkestratorn kontrollerar stopporsaken. Verktygsanvändning → kör verktyget. Avsluta turen → uppgiften är klar.

4. Observera: Verktygets resultat läggs till som ett verktygsmeddelande. Loopen startar om med en utökad kontext.

Två saker omger den här loopen och är viktiga för vår berättelse. För det första skyddsräcken för maximalt antal turer, token och kostnad – utan dem skulle orkestratorn loopa för alltid. För det andra avbrottspunkter för pauser med en människa i loopen vid högriskåtgärder som att radera, driftsätta och anropa externa API:er.

Det är den här loopen kvalitetsingenjörer behöver tänka på. Inte DevOps-loopen i arkitekturdiagrammet – det är den yttre loopen. ReAct-loopen är den inre loopen, den som körs hundratals gånger per uppgift och där agenten fattar sina faktiska beslut.

Var specialiserade agenter passar in i SDLC

Zooma ut från en kodningsagent och titta på hur specialiserade agenter passar in i den välkända DevOps-loopen – Planera, Designa, Koda, Bygga, Testa, Releasa, Driftsätta, Driva och Övervaka. Vi kan redan placera agentteam längs den:

• Specifikationsagenter till vänster: tar fram UX-underlag, användarpersonor, kundresekartor, BDD/ATDD-specifikationer och nyckelordsdrivna testramverk. Testningen flyttas tidigare – klassisk shift left.

• CD pipeline-agenter till höger: kör acceptanstester och prestandatester i staging, driftsätter canary-releaser, observerar systemet och initierar rollbacks och roll-forwards. Återkoppling från produktion – klassisk shift right.

Välbekant terräng. Vi har pratat om shift left och shift right i flera år, och principerna gäller fortfarande när aktören i loopen råkar vara en agent. Men det finns en tredje plats där kvalitet nu måste finnas, och den ligger inte alls utanför SDLC.

Tre riktningar för Quality Engineering i agentisk utveckling

Samma metoder inom Quality Engineering. Olika mottagare av återkopplingen.

← Shift left – Specifikationsagenter: Människor och agenter läser specifikationer. Quality Engineering formar avsikten innan koden finns: UX-designunderlag, användarpersonor/kundresor/användarberättelser, BDD/ATDD-specifikationer och nyckelordsdriven generering av acceptanstester. Allt kommunicerar avsikten. Använd dedikerade agenter för att göra designmetoderna oundvikliga.

↓ Shift in – Inuti ReAct-loopen: Kodningsagenten agerar utifrån sina instruktioner och använder färdigheter för att lösa problem, och läser sedan verktygsresultatet. Metoder inom Quality Engineering driver rätt beteenden och blir verktyg som agenten anropar i varje iteration. En väldefinierad färdighet för testdesign hjälper agenten att definiera värdefulla testfall. Enhetstester, API-tester, lokala integrationstester och kontinuerliga testcykler fungerar som snabb återkoppling i den inre loopen.

Shift right → – CD pipeline-agenter: Produktion fungerar som oraklet som sluter loopen: acceptanstester i staging, prestandamätning i produktion, canary-releaser/dark launches för att begränsa påverkan, rollback/roll-forward för att reagera snabbt och observation av hur verkliga användare möter systemet. Alla metoder inom Quality Engineering validerar korrekthet och ger slutligen återkoppling.

Shift in: Quality Engineering inuti agentens loop

Här är kärnidén. Kodningsagenter uppfattar världen genom verktygsresultat. Det är hela deras sensoriska lager. All återkoppling som vi vill att de ska agera på måste komma som ett strukturerat verktygsresultat inuti ReAct-loopen.

Det innebär att Quality Engineering får en ny mottagare.

Tesens shift in: Om du vill att kvalitet ska påverka vad agenten gör härnäst måste kvalitet finnas inne i loopen – som ett verktyg agenten kan anropa, en hook som körs automatiskt, en skill agenten kan ladda eller en eval som bedömer förloppet. CI/CD-pipelinen blir maskinläsbar sensorisk återkoppling för agenten, men vilken annan återkoppling kan vi ge den?

Konkret innebär shift in att bygga om fyra lager av QE-arbetet med agenten som mottagare.

1. Quality Engineering-metoder styr beteendet

En väldefinierad instruktionsfil med fokus på kvalitetsaspekter, en noggrant granskad och specifik skill som talar om för agenten HUR den ska lösa specifika problem, eller till och med en specialiserad sub-agent som ger expertutlåtanden eller arbetar med delegerade uppgifter – allt detta behövs för att föra in våra Quality Engineering-metoder i den agentdrivna världen och göra vår röst hörd.

2. Tester som verktyg som agenten anropar i varje iteration

En enhetstestsvit som körs på några sekunder och returnerar en strukturerad godkänd/underkänd-rapport är den perfekta ReAct-observationen. Agenten skriver en funktion, anropar testverktyget, läser felen, rättar koden och anropar det igen. Det är loopen i praktiken. Föreställ dig nu samma sak med API-kontraktstester, snabba integrationstester och mutationstester på de ändrade raderna. Varje snabb, deterministisk och strukturerad signal du kan lägga in i loopen hindrar agenten från att irra omkring – och sparar dig från att behöva städa upp efter den senare.

3. Hooks som deterministiska skyddsräcken och verktyg för att upprätthålla compliance

En PreToolUse-hook kan blockera ett destruktivt kommando innan det körs. En PostToolUse-hook kan kräva att lintning körs efter varje filändring, eller tvinga fram att en granskningslogg skrivs. En Stop-hook kan vägra att markera en uppgift som slutförd förrän testerna godkänns och täckningen ligger över tröskelvärdet. Med hooks slipper du hoppas att agenten kommer ihåg att följa dina standarder och kan i stället upprätthålla dem. Det är här dina DoR/DoD-kontroller, snabba SAST-skanningar, skanningar av sårbarheter i beroenden och stilregler – hela ditt icke förhandlingsbara lager – faktiskt blir icke förhandlingsbara.

4. Pull request-grindar som bryggan mellan den inre och den yttre loopen

Agentens lokala loop kör snabbt enhets-, API- och integrationstester. Pull request-grinden lägger till det långsammare och mer resurskrävande: fullständig SAST, fullständig regressionstestning, komplexitetsanalys och täckningsgrindar. Här möter den inre ReAct-loopen den yttre DevOps-loopen. Agenten ser resultatet av PR-kontrollen som ännu en verktygsobservation och agerar utifrån det – rättar det som misslyckades, motiverar det som var en falsk positiv eller ber om mänsklig granskning när den kör fast.

Notera vad som inte förändrades. Vi gör fortfarande statisk analys. Vi kör fortfarande enhetstester. Vi använder fortfarande täckning som grind. QE-metoderna är desamma. Det som har förändrats är vem eller vad som kör kommandot, läser resultatet och beslutar vad som ska göras härnäst. Det är hela grejen.

Vad det här innebär för dig som arbetar med kvalitet

Tre konsekvenser sticker ut för QE-specialister.

Dina tester har en ny målgrupp: Om mottagaren av testresultatet är en agent är utdataformatet lika viktigt som testlogiken. Kryptiska stack traces som en erfaren människa kan tolka är inte särskilt bra signaler för en agent. Strukturerad, namngiven och deterministisk utdata – JSON-rapporter, maskinläsbara diffar och tydliga assertions – ger agenten något att agera på.

Din CI blir ett API: Pipelines har alltid lästs av människor via dashboards och PR-kontroller. Nu läses de av agenter via verktygsanrop. Samma pipeline används av båda målgrupperna, men API-ytan – den del som agenten anropar och tolkar – måste utformas medvetet. Continuous delivery for ML berörde redan den här idén; agentdriven utveckling tar den ett steg längre.

Din roll ligger uppströms från agenten: Att bygga bra evals, utforma verktygskontrakt, skriva skills och instruktionsfiler som fångar testkunskap samt ansvara för hook-lagret – det är QE-arbete i en agentdriven stack. Arbetet försvinner inte. Det flyttas in i den inre loopen.

Slut loopen

Shift left var rätt svar när loopen drevs av människor och den långsammaste delen var omarbetning efter release. Shift right var rätt svar när produktionen blev en egen källa till sanning och vi behövde lära oss av den. Båda är fortfarande rätt.

Shift in är svaret för den del av loopen som nu drivs av agenter. Agentens förmåga att uppfatta begränsas av vad den kan läsa som ett verktygsresultat, så återkoppling om kvalitet måste också finnas där. Kompetenserna förändras inte – grunderna i testning, orakelproblemet, kommunikationsproblemet och disciplinen att utforma för fel. Det som förändras är vem som läser återkopplingen, och det förändrar allt med hur vi paketerar den.

De kommande fem åren kommer verkligen att innebära mer förändring än de senaste fyrtio. Quality Engineering får vara med i loopen, bokstavligen talat, om vi väljer att placera det där.