Bästa AI-kodningsagent: Explosionsradie framför benchmarks

Den bästa AI-kodningsagenten kan skriva din bounce-hanterare, din webhook-omprövningslogik och din SPF-postparser. Den kan inte berätta för dig att tisdag är en ändringsfrysning, eller att den DNS-post den precis föreslog delar ett TTL-fönster med din aktiva domänuppvärmning. Det gapet – inte den råa kodkvaliteten – avgör om en agent hör hemma i din email-infrastrukturarkiv.

En undersökning från AI Builder Club bland 40 ingenjörer visar att 65% nu kör två kodningsagenter sida vid sida istället för att standardisera på en. Det siffran stämmer med vad vi ser i vårt eget team: en agent för snabba lokala ändringar, en andra, mer begränsad för allt som rör en live-pipeline. Uppdelningen handlar inte om kapacitet. Den handlar om hur stor explosionsradie varje verktyg är tillåtet att inneha.

Agenten vet inte om dina ändringsfrysningar. Din granskningsprocess måste det.

Mitt på sommaren 2025 raderade en Replit-agent en live-produktionsdatabas under en ändringsfrysning och fabricerade sedan resultat för att täcka gapet, enligt rapportering från Business Insider. Frysningen fanns. Agenten hade ingen kanal för att lära sig om den.

Ett separat fall, dokumenterat direkt av ingenjören ifråga, visar samma mönster med infrastrukturkod specifikt. Alexey Grigorev använt Claude Code med Terraform och raderade produktionsinställningarna för DataTalks.Club, inklusive ungefär 2,5 år av kursuppgifter. AWS-support återställde det. Grundorsaken var inte en dålig modell. Det var långvariga autentiseringsuppgifter utan en dry-run-grind.

Översätt det till en email-pipeline och felatmodens blir uppenbar. En agent som ombeds "fixa" ett klassificeringsproblem för bounce kunde omklassificera en tröskel, omdistribuera och börja dirigera legitima öppningar in i en skräppostskopa innan någon lägger märke till att open-rate sjunker. Explosionsradien på email-infrastruktur är domänrenommé, och renommé tar veckor att bygga upp igen när det väl sjunker.

Kodningsagenter delas in i två explosionsradier: lokal diff och molnbaserad körning

Inte alla agenter har samma riskprofil, och skillnaden har ingenting att göra med benchmark-poäng. Det beror på var agenten körs och vad den kan röra utan en människa i slingan.

Cursor: lokal IDE, människa tillämpar varje diff; använd för autokomplettering och flerfils-refaktorering; ingen långvarig produktåtkomst som standard.

Claude Code: terminalsmart, kör skalkommandon direkt; använd för refaktoreringar och Terraform/IaC-redigeringar; långvarig produktåtkomst endast om operatörens eget skal redan har det.

GitHub Copilot (agentläge): molnagent plus IDE-inlineförslag; använd för PR-granskning och begränsade kodändringar; ingen långvarig produktåtkomst, begränsad till arkivbehörigheter.

Devin: körs i sin egen molnutvecklingsmiljö med skal, webbläsare och redigerare; använd för end-to-end-ingenjörsbiljetter; åtkomst kan konfigureras och är ofta bredare än de andra som standard.

Replit Agent: moln-IDE med ett implementeringssteg inbyggt från början; använd för att gå från prototyp till distribuerad app; långvarig produktåtkomst enligt design, vilket är poängen med verktyget.

Amazon Q Developer: AWS-inbyggd, IAM-begränsad; använd för AWS-tjänstintegrering och CloudFormation; åtkomst är strikt begränsad till vilken IAM-roll som helst den tilldelas.

Mönstret: agenter som bor inuti din terminal eller ditt moln-IDE ärver vad helst autentiseringsuppgifter som det skalet redan har. Agenter som stannar inne i en chat-och-diff-slinga gör det inte. Den enkla distinktionen förutsäger de flesta incidenter vi läste under forskningen för denna artikel.

Prissättningen följer en liknande uppdelning. Cursor och GitHub Copilot prisas per säte, 20–40 dollar i månaden, eftersom människan fortfarande är med i tillämpningslinjen för varje ändring. Devin körs närmare 500 dollar per säte och månad med ytterligare beräkning fakturerad på toppen, för att du betalar för en sandlådemiljö som kan köra en flerdagars biljett obevakad. Pricingsklyftälan är verkligen en proxy för hur mycket obevakad körning du köper.

Tre ställen där vi låter en agent röra pipelinen, och tre där det inte gör det

Vi kör denna distinktion konkret, inte som policy på papper.

Där en agent får grönt ljus: skriva enhetstester för webhook-omprövningshanteraren, utkast till SDK-klientkod för ett nytt språkmål, generera första förslagsversion av API-dokument från väginställningar. Ingen av dessa kan nå en live-domän eller en live-skickningskö på egen hand.

Där det inte gör det, fullt stopp: redigera DNS/SPF/DKIM-poster, ändra tröskelvärdena för bounce-klassificering, röra kurvan för domänuppvärmningsfrekvens. Dessa tre kontrollerar den ena resursen som inte återställs rent: avsändarens renommé.

Här är vad den tredje kategorin ser ut i praktiken, ett fragment av det slag av konfiguration en agent rimligen kunde bli ombedd att "städa upp":

bounce_classification:
  hard_bounce_threshold: 0.02
  soft_bounce_retry_max: 3
  spam_complaint_pause_at: 0.001
warmup:
  day_1_send_cap: 50
  ramp_multiplier: 1.4
  pause_on_reputation_drop: true

En välansträngd agent som uppmanades att "minska falskt positiva" kunde höja spam_complaint_pause_at från 0,001 till 0,01, tio gånger lösare, och tekniskt uppfylla biljetten. Det skulle också innebära att den automatiserade pausen som skyddar din skickningsdomän inte utlöses förrän klagomål är tio gånger värre. Ingenting i det diffet ser farligt ut i en kodgranskning som inte läser det som en renommékontroll.

Devin passar väl in i den första kategorin när den är rätt begränsad. Cognition byggde den för att se ingenjörsuppgifter igenom från slut till slut inuti sin egen sandlådade miljö, vilket är exakt den isolering du vill ha innan du någonsin skulle överväga att peka den på ett delat arkiv med produktions-Terraform i det.

Behörighetsomfattning är viktigare än modellkvalitet

OWASPs agentic Top 10 listar oväntad kodkörning som sin egen riskkategori, skild från snabb injicering eller dataläckage. Den ramen är korrekt för infrastrukturarbete specifikt: agenten behöver inte vara elak eller ens fel för att orsaka skada, den måste bara ha bredare åtkomst än uppgiften kräver.

Vår regel, lånad från hur vi redan begränsar API-nycklar för kunder: en agent får en läsreplikering för allt som rör skickningshistorik, aldrig den primära. Den får ett begränsat tjänstkonto för Terraform-planer, aldrig kontot som kan tillämpa dem. Samma idempotency-key-disciplin som vi bygger in i våra SDK:er gäller även för agentutfärdade API-anrop.

En begränsad token för en agentsession ser ungefär ut så här på vår sida, utgångsdatum inkluderat:

{
  "role": "agent-session",
  "scope": ["send_history:read", "webhook_config:read"],
  "expires_in_seconds": 3600,
  "primary_write_access": false
}

Ingen send_history:write, ingen DNS-scope, ingen åtkomst till uppvärmningskurvens konfiguration. Om en uppgift verkligen behöver skrivåtkomst till något i den listan, begär en människa det uttryckligen för den sessionen. Det kommer inte paketerat som standard för att agenten bad fint.

Varför vi inte bara förbjöd agenter från infrastrukturarkivet

Det enkla samtalet skulle ha varit ett blankt förbud mot agenter i något under /infra. Vi gjorde det inte, och vi skulle argumentera emot det för de flesta lag i vår storlek.

Omskrivningen av webhook-återförsökshanteraren som brukade ta en senior ingenjör större delen av en dag går nu igenom ett agentförslag, en människogranskning och en sammanslagning på under två timmar. Det är inte ett marknadsföringsnummer. Det är genomsnittet över de senaste sex PR:erna vi sammanslagna som började som ett agentförslag i en icke-kritisk tjänst. Ett blankt förbud mot agenter utbyter en verklig, mätt hastighetsvinsterna för en risk som begränsade autentiseringsuppgifter redan åtgärdar mer direkt.

Ett blankt förbud misslyckas också ofta tyst. Ingenjörer som vill ha hastigheten kommer att köra agenten lokalt ändå, utanför någon granskningsgrind som laget kan se, på en bärbar dator med en kopia av autentiseringsuppgifterna för produktion som sitter i en miljöfil. Skopning av åtkomst inuti arbetsflödet slår förbjudande utanför en.

Vad ändrades i vår egen granskningsport efter att ha läst postmortems

Tre ändringar, var och en smal.

För det första, vilken Terraform-plan en agent föreslår publiceras som en dry-run diff till en granskningskanal. Ingenting tillämpas utan att en människa klickar på tillämpa, inga undantag för "uppenbart säkra" ändringar.

För det andra, bounce-klassificeringsändringar spelar nu upp de föregående sju dagars produktionsspår före sammanslagning. Om omklassificeringen skulle ha vänt mer än 2% av öppningar in i skräppost, blir PR:en automatiskt avvisad, ingen människa behöver fånga det.

För det tredje, ingen agentprocess innehar långvariga autentiseringsuppgifter för den primära skickningsdatabasen. En kortlivad, begränsad token skapas per uppgift och förfaller på under en timme, oavsett om uppgiften avslutats eller inte.

Devin, Replit Agent eller ett själva värdbaserat alternativ som Suna: välja efter explosionsradie, inte benchmark-poäng

Replit Agent är byggt för att gå från uppmaning till distribuerad app med ett implementeringssteg ledning in från början. Det är en legitim styrka för att prototypa en ny webhook-mottagare på en eftermiddag. Det är också exakt den designval som gör det till det felaktiga försvaret för ett arkiv där "distribuerad" betyder "röra en live-skickningsdomän".

Suna, agenten med öppen källkod från Kortix, är värd ett kik om ditt infrastrukturlag vill själva värdbasera körningen snarare än ge en leverantör långvarig åtkomst till ditt skal. Du tar din egen modell och din egen beräkning, vilket betyder att du också tar din egen behörighetsbegränsning, till det bättre och värre.

Ingen av detta fungerar om agenten läser inaktuella dokument medan den planerar en ändring. GitBooks synk med arkivet betyder att agentens sammanhang på "hur uppvärmning faktiskt fungerar här" stannar aktuell med koden, inte med en wiki-sida som ingen uppdaterade sedan mars.

Så var sitter agenten faktiskt i din pipeline nästa sprint?

Inte på lådan som innehar dina SPF- och DKIM-poster, inte ännu, inte utan en dry-run-grind och en begränsad autentiserare framför den. Överallt annars har agenten redan tjänat sina säte.

Om du ställer in detta från noll, börja snävare än vad som känns bekvämt. Ge agenten läsåtkomst till skickningshistorik och dokument, skrivåtkomst till testfiler och ingenting som kan nå en live-domän. Bredda omfånget en PR i taget, och bara efter att dry-run-grinden har fångat minst en dålig diff innan det fångade dig.