Hoppa till innehåll
September 1, 2026

Mäta agentgenomströmning: sammanfogade PR:er, avvisningsfrekvens och kostnad per PR

Mät genomströmningen för kodningsagenter med två siffror som läses tillsammans: sammanfogade pull requests (merged PRs) och avvisningsfrekvens (denial rate), det vill säga andelen pull requests som stängs utan att slås samman. Lägg till cykeltid från plan till merge samt kostnad per sammanfogad pull request, och du har tillräckligt med underlag för att avgöra om agenterna producerar accepterat arbete till ett försvarbart pris. Öppnade pull requests, den siffra de flesta team rapporterar först, räcker inte på egen hand: en agent kan öppna femtio pull requests om dagen som ingen någonsin mergar, och den siffran kommer ändå att se ut som framsteg. Denna artikel definierar varje mätetal, förklarar vad ett dåligt utfall innebär och visar hur Ivy Tendril samt en gratis kalkylator från Ivy spårar dem.

Mätetalen

Mätetal Definition Vad ett dåligt utfall innebär
Öppnade PR:er Pull requests skapade under perioden I sig självt ingenting. Högt och stigande med oförändrade merges betyder att agenterna producerar arbete teamet inte vill ha
Sammanfogade PR:er Pull requests sammanfogade under perioden Oförändrat eller fallande medan öppnade ökar: granskning är det långsammaste steget, eller så sjunker kvaliteten
Avvisningsfrekvens PR:er stängda utan merge, delat med alla stängda PR:er (sammanfogade plus stängda omergade) Hög: planerna är felaktiga, verifieringen är svag eller granskare avvisar sent. Nära noll med låg volym: endast de säkraste uppgifterna prövas
Cykeltid Tid från skapande av plan till merge Lång: arbetet väntar vid en mänsklig kontrollpunkt. Ta reda på vilken
Kostnad per sammanfogad PR Totala tokens eller dollar under perioden, delat med sammanfogade PR:er Stigande: omsökningar/omkörningar (retries), överdimensionerade planer eller en dyr modell där en billigare skulle klara verifieringen
Godkännandegrad för verifiering Andel körningar som klarar tester, linter och bygge vid första försöket Låg: planerna är underspecificerade eller agenten saknar kontext om kodbasen

Två definitioner kräver extra noggrannhet. Avvisningsfrekvens använder stängda PR:er, inte öppnade PR:er, som nämnare, så att öppna pull requests som fortfarande är under granskning varken räknas som godkända eller avvisade. Kostnad per sammanfogad PR delar alla utgifter – inklusive kostnader för planer som avvisades eller avbröts – med enbart sammanfogade pull requests. Detta är avsiktligt: kostnaden för det avvisade arbetet är en del av kostnaden för det sammanfogade arbetet.

Varför sammanfogade PR:er och avvisningsfrekvens är det ärliga paret

Varje enskilt mätetal kan förbättras genom att man försämrar ett annat mätetal.

  • Öppnade PR:er ökar när kraven på vad som får köras sänks. Avvisningsfrekvensen stiger i takt med det.
  • Sammanfogade PR:er ökar när granskare godkänner snabbare. Defekter som upptäcks efter merge ökar, och avvisningsfrekvensen sjunker av helt fel anledning.
  • Avvisningsfrekvensen sjunker när man enbart kör de allra säkraste planerna. Sammanfogade PR:er sjunker i takt med det.

Detta är samma resonemang som ligger bakom DORA-måtten, där genomströmning och stabilitet alltid rapporteras i par just för att endera siffran kan manipuleras på bekostnad av den andra. Sammanfogade PR:er och avvisningsfrekvens lästa tillsammans motstår detta. För att öka antalet merges utan att öka avvisningarna måste mer arbete produceras som teamet faktiskt accepterar. För att sänka avvisningarna utan att sänka merges måste planer och verifiering åtgärdas snarare än att köra färre uppgifter. Ingen av siffrorna kan förbättras genom att ignorera den andra.

Anledningen till att öppnade PR:er lockar är att det är det första en agent producerar och det enklaste att räkna. Men en öppnad pull request är en begäran om någons tid. Att räkna förfrågningar som output belönar agenter för att skapa arbete åt granskare. Att räkna merges belönar dem för att slutföra det.

Ivy publicerar sina egna data på detta sätt. Diagrammet över PR:er per dag kontra avvisningsfrekvens på sidan Varför Ivy bygger på 1 946 pull requests i Ivys repositorier från februari till april 2026. Ivy rapporterar att teamet gick från cirka 10 till fler än 100 pull requests per dag efter att ha infört arbetsflödet med planering, exekvering, verifiering och granskning som kallas en mjukvarufabrik. Volymsiffran visas bredvid avvisningsfrekvensen eftersom den på egen hand inte skulle bevisa någonting.

Kostnad per sammanfogad PR och godkännandegrad för verifiering

När merges och avvisningsfrekvens väl är på plats visar kostnaden per sammanfogad pull request vad det accepterade arbetet faktiskt kostar. Detta är siffran en CTO efterfrågar, och den måste uttryckas i dollar eller tokens per sammanfogad ändring – inte per plan eller per körning – så att omkörningar och avvisat arbete inkluderas.

Kostnad per sammanfogad pull request är också den siffra som synliggör köbildning: enligt Littles lag innebär en växande backlog av öppna pull requests vid en fast merge-hastighet att cykeltiden ökar, oavsett om någon har mätt den eller inte. Tre faktorer påverkar kostnaden per sammanfogad PR:

  1. Omkörningar (Retries). Varje misslyckad verifiering innebär en ny körning. Godkännandegraden för verifiering är den ledande indikatorn; när den faller stiger kostnaden per sammanfogad PR några dagar senare. Verifieringsgrindar beskriver vad som ska kontrolleras och varför plangrinden är viktigast.
  2. Planens storlek. Stora planer kostar mer per körning och avvisas oftare, eftersom en granskare hittar mer att invända mot. Att dela upp en plan i mindre delar sänker vanligtvis både avvisningsfrekvensen och kostnaden per sammanfogad PR, till priset av fler pull requests att granska.
  3. Modellval. En billigare modell som klarar verifieringen med samma frekvens är en direkt besparing. Det enda sättet att veta säkert är att spåra kostnad och godkännandegrad per plan och jämföra olika modeller på samma kodbas.

För det bredare skiftet från att mäta utvecklaraktivitet till att mäta accepterad output, se In the loop, out of the loop: the KPI shift behind agentic engineering.

Hur Ivy Tendril spårar dessa siffror

Ivy Tendril är en local-first skrivbordsapplikation (macOS, Windows, Linux) som kör kodningsagenter från plan till granskad pull request, och den registrerar data för varje mätetal ovan som en direkt följd av att arbetsflödet körs. Ingenting behöver instrumenteras separat.

  • Dashboard. Dashboard visar planstatus över hela livscykeln, kostnads-KPI:er, trenddiagram över tid och Git-aktivitet för de anslutna repositorierna. Planstatus ger dig öppnade, sammanfogade och avvisade PR:er; Git-aktiviteten ger dig merge-historiken.
  • Kostnad per plan och per jobb. Tokens och kostnader spåras för varje plan och för varje jobb inom en plan. En plan som krävde tre exekveringsjobb innan den klarade verifieringen visar alla tre, så kostnaden per sammanfogad PR inkluderar omkörningar automatiskt. Vyn Jobs visar varje jobbs strömmande utdata och verktygsanrop sida vid sida med dess kostnad.
  • Jämförelse mellan agenter och modeller. Tendril kör Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode och alla andra CLI-agenter, och agent eller modell väljs per plan. Kostnad och godkännandegrad kan därför jämföras mellan modeller på samma kodbas utan att ändra arbetsflödet.
  • Lokala data. Planer, loggar och kostnadsposter stannar på maskinen. De enda externa anropen går till det modell-API du konfigurerar och till GitHub.

För team som ännu inte kör Tendril tillhandahåller Ivy en kostnadsfri PR Cost Calculator med öppen källkod. Den läser publika GitHub-data för ett arkiv och beräknar rullande 14-dagars sammanfogade PR:er och avvisningsfrekvens, så att teamet kan fastställa sitt utgångsläge innan några förändringar görs. Kör den på ditt arkiv idag, och igen en månad efter att agenter har introducerats.

Hur du kommer igång

  1. Fastställ utgångsläget. Kör PR Cost Calculator på ditt huvudarkiv och registrera rullande 14-dagars sammanfogade PR:er och avvisningsfrekvens.
  2. Installera Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) eller irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Dokumentation finns på installation.
  3. Kör planer under två veckor och analysera Dashboard: sammanfogade, avvisade, kostnad per plan, trend.
  4. Beräkna kostnaden per sammanfogad PR manuellt en gång genom att dela de totala utgifterna med antalet sammanfogade PR:er, så att teamet är överens om definitionen innan den blir ett officiellt rapporterat nyckeltal.

Tendril är gratis och källkodstillgängligt under Functional Source License. Teamfunktioner, on-prem-driftsättning, SSO och import av CI-verifiering ingår i Pro ($59 per användare och månad) och Enterprise-abonnemangen.

Vanliga frågor

Vad är en bra avvisningsfrekvens?

Det finns inget universellt mål, och en siffra på noll innebär oftast att ingenting med någon reell risk prövas. Följ din egen frekvens över tid och behandla en ökning som en signal om att se över plankvalitet och verifiering – inte som en siffra som ska sänkas genom att köra färre uppgifter.

Borde kostnad per sammanfogad PR inkludera tid för mänsklig granskning?

Inkludera det om du kan mäta det konsekvent. De flesta team börjar med tokens eller modellkostnader eftersom det registreras automatiskt, och lägger till granskningstid när definitionen väl har satt sig. Att blanda de två innan man kommit överens om metoden gör siffran svår att jämföra från månad till månad.

Hur skiljer sig dessa mätetal från DORA-mått?

De överlappar varandra. Cykeltid från plan till merge ligger nära ledtid för ändringar (lead time for changes). Avvisningsfrekvens har ingen direkt DORA-motsvarighet, eftersom DORA förutsätter att en människa skrev ändringen och frågar om den driftsattes. Avvisningsfrekvensen frågar om ändringen överhuvudtaget accepterades, vilket blir den mer användbara frågan när agenter producerar kandidaterna.

Kom igång med Ivy Tendril

Är du redo för parallell agentorkestrering på utvecklarnivå?

Written by

Ivy Team