Så sätter du upp en kvalitetsloop för kodagenter

Efter guiden kan du mäta om en kodagent faktiskt blir bättre mellan iterationer i stället för att bara kännas bättre i några handplockade exempel.

• Målgrupp: utvecklare och team som redan testar kodagenter i vardagen.
• Förkunskaper: du kan köra terminalkommandon, läsa JSONL och vet vad en prompt eller agenttrace är.
• Du behöver: Node.js, ett repo eller en agentmiljö att utvärdera, samt ett sätt att exportera testfall eller traces.
• Slutkontroll: du vet att det fungerar när du har en baslinje, en körbar uppsättning testfall och en ny mätning som går att jämföra mot förra körningen.

## Det här behöver du - En kodagent som redan gör någon konkret uppgift, till exempel kodgranskning, felsökning eller planering. - Ett litet testset med riktiga fall från ditt team. - Ett separat eval-konto eller projekt om du vill köra Googles flywheel-paket från källan.

## Steg 1: Välj en enda uppgift att mäta Mål: begränsa scope så att första loopen blir begriplig.

Gör så här: välj en uppgift där agenten ofta används och där fel går att upptäcka. Bra första kandidater är “föreslå fix på ett felmeddelande”, “planera en ändring i ett repo” eller “svara på en kodfråga med rätt filreferenser”. Skriv också vad som räknas som godkänt.

Uppgift: föreslå en fix för ett byggfel i ett TypeScript-projekt
Godkänt när:
- agenten identifierar rätt fil eller modul
- agenten föreslår en relevant ändring
- agenten hittar inte på beroenden eller kommandon

Kontrollera att det fungerar: någon i teamet ska kunna läsa definitionen och hålla med om vad som är “bra” respektive “dåligt”.

Vanligt fel: ni försöker mäta “hela agenten” direkt. Börja med en enda uppgift, annars blir signalen för brusig.

## Steg 2: Bygg ett litet eval-set från verkliga fall Mål: skapa en första baslinje med riktiga exempel.

Gör så här: samla 10 till 25 fall från supporttrådar, interna buggar eller tidigare agentkörningar. Lägg dem i JSONL så att varje rad motsvarar ett scenario.

{"id":"case-001","prompt":"Bygget kraschar med module not found i src/api/client.ts","expected":"Peka ut importen eller sökvägen som är fel"}
{"id":"case-002","prompt":"Testerna faller efter en schemaändring i databasen","expected":"Föreslå att fixtures eller migration uppdateras"}

Om du redan har produktionsspår kan du använda dem som start, precis som Googles kvalitetsloop beskriver.

Kontrollera att det fungerar: du ska kunna öppna filen och förstå vad agenten ska göra i varje fall utan extra förklaring.

Vanligt fel: alla testfall blir nästan identiska. Blanda enkla, normala och besvärliga fall.

## Steg 3: Installera eval-verktyget och skapa en graderingskonfiguration Mål: få ett återanvändbart sätt att bedöma resultaten.

Gör så här: enligt Googles officiella blogg finns två paket för samma eval-tjänst. Välj det som passar din miljö.

# CLI-driven miljö
npx skills add https://github.com/google/agents-cli --skill google-agents-cli-eval

# SDK-driven miljö
npx skills add https://github.com/google/skills --skill agent-platform-eval-flywheel

Skapa sedan en enkel konfigurationsfil för vad du vill bedöma.

metrics:
 - name: task_success
 description: Agenten löser uppgiften utan att missa huvudfelet
 - name: trajectory_quality
 description: Agenten tar rimliga steg och hallucinerar inte filer eller verktyg

Kontrollera att det fungerar: du ska ha både ett testset och en rubricering som går att återanvända i nästa körning.

Vanligt fel: teamet ändrar bedömningsregler mellan varje körning. Frys första rubriken och justera först efter några iterationer.

## Steg 4: Kör en första mätning och läs varför fallen fallerar Mål: få en baslinje i stället för magkänsla.

Gör så här: kör agenten mot ditt eval-set och spara traces i en egen mapp. Om du redan har traces kan du hoppa direkt till grading-steget.

mkdir -p eval
agents-cli eval grade --traces eval/traces.jsonl --config eval/eval_config.yaml

Läs sedan igenom de fall som fick låga betyg. Fokusera först på återkommande fel, inte på enstaka märkliga avvikelser.

Kontrollera att det fungerar: du ska kunna peka på minst två konkreta feltyper, till exempel fel filreferenser eller att agenten ignorerar en ändrad användarinstruktion.

Vanligt fel: ni hoppar direkt till promptändringar utan att först läsa de svaga körningarna.

## Steg 5: Gör en liten ändring och jämför mot baslinjen Mål: förbättra agenten utan att råka förstöra annat.

Gör så här: ändra en sak i taget, till exempel systemprompt, verktygsval eller hur kontext hämtas. Kör sedan samma eval-set igen.

Ändra en sak:
- prompt
- verktygsordning
- retrieval
- statehantering
Kör sedan om exakt samma eval-set.

Jämför nya resultat mot baslinjen. Om bara tre exempel ser bättre ut men helheten står still, har du inte bevis på förbättring ännu.

Kontrollera att det fungerar: du vet att loopen fungerar när du kan säga “version B förbättrade task_success men försämrade trajectory_quality” i stället för “den här kändes smartare”.

Vanligt fel: samma modell eller agent får bedöma sin egen förbättring. Källan varnar uttryckligen för att optimizer och evaluator ska vara separerade.

## Felsökning - Problem: resultaten hoppar kraftigt mellan körningar. Lösning: använd samma testset och samma rubrik i minst två till tre rundor innan du drar slutsatser. - Problem: teamet får för få misslyckanden för att lära sig något. Lösning: blanda in svårare produktionsfall och inte bara “rena” demofall. - Problem: alla diskussioner fastnar i promptord. Lösning: gruppera först feltyperna och välj sedan en enda ändring att testa.

Källa: Google Developers Blog – Driving the Agent Quality Flywheel from Your Coding Agent