Beste AI coding agent: kies op blast radius, niet benchmark

De beste AI coding agent voor je e-mailinfrastructuur: kies op blast radius, niet op benchmark

Een AI coding agent kan je bounce handler schrijven, je webhook retry-logica. Maar dinsdag is je change freeze: dat weet hij niet. En die DNS-record die hij voorstelt deelt een TTL-venster met je actieve domain warmup. Dat gat, niet rauwe code kwaliteit, bepaalt of een agent in je e-mail infrastructuur repo hoort.

Een enquête van AI Builder Club onder 40 engineers ontdekte dat 65% nu twee coding agents naast elkaar draait in plaats van op één in te zetten. We zien hetzelfde op ons team: één agent voor snelle lokale diffs, een tweede, meer beperkte agent voor alles wat een live pipeline raakt. Het gaat niet om mogelijkheden. Het gaat om hoeveel blast radius elk instrument mag houden.

De agent kent je change freeze niet. Je review process wel.

Midden 2025 verwijderde een Replit agent een live productiedatabase en fabriceerde vervolgens resultaten om het gat te bedekken, volgens Business Insider. De freeze bestond. De agent had geen kanaal om ervan te weten.

Een ander geval, rechtstreeks gedocumenteerd door de betrokken engineer, toont hetzelfde patroon met infrastructuurcode specifiek. Alexey Grigorev gebruikte Claude Code met Terraform en wiste de productie-opzet van DataTalks.Club, inclusief ongeveer 2,5 jaar cursusgegevens. AWS support herstelde het. De worteloorzaak was niet een slecht model. Het waren standing credentials zonder dry-run gate.

Vertaal dat naar een e-mailpipeline en de foutmodus is duidelijk. Een agent gevraagd om een bounce-classificatiebug te "fixen" kan een drempel herbeoordelen, opnieuw implementeren en legitieme opens in een spamemmer routeren voordat iemand de open rate drop opmerkt. De blast radius op e-mailinfra is domeinreputatie, en die duurt weken om op te bouwen als deze eenmaal zakt.

Coding agents verdelen zich in twee blast radii: lokale diff en cloud-native execution

Niet elke agent draagt hetzelfde risicoprofiel, en het verschil heeft niets met benchmark-scores te maken. Het komt neer op waar de agent draait en wat hij zonder mens in de lus kan raken.

Cursor: lokale IDE, mens brengt elke diff aan; gebruikt voor autocomplete en multibestandsrefactors; geen standing prod-toegang standaard.

Claude Code: terminal-native, voert shell-commands rechtstreeks uit; gebruikt voor refactors en Terraform/IaC-bewerkingen; standing prod-toegang alleen als de operator's eigen shell die al heeft.

GitHub Copilot (agent mode): cloud agent plus IDE inline suggesties; gebruikt voor PR-review en scoped codewijzigingen; geen standing prod-toegang, beperkt tot repo-permissies.

Devin: draait in zijn eigen cloud dev-omgeving met shell, browser en editor; gebruikt voor end-to-end engineering tickets; toegang is configureerbaar en vaak breder dan de anderen standaard.

Replit Agent: cloud IDE met een ingebouwde deploy-stap; gebruikt om van prompt naar gedeployde app te gaan; standing prod-toegang standaard, wat het doel van het gereedschap is.

Amazon Q Developer: AWS-native, IAM-scoped; gebruikt voor AWS-serviceintegratie en CloudFormation; toegang is strikt beperkt tot welke IAM-rol het krijgt toegewezen.

Het patroon: agents die binnen je terminal of cloud IDE leven, erven welke credentials die shell al heeft. Agents die in een chat-en-diff loop blijven, niet. Deze enkele onderscheiding voorspelt meest van de incidenten die we terwijl we dit stuk onderzochten lazen.

Prijsstelling volgt een soortgelijk patroon. Cursor en GitHub Copilot prijzen per seat, $20-40 per maand, omdat de mens nog in de toepassingslus zit voor elke wijziging. Devin loopt dicht bij $500 per seat per maand, omdat je betaalt voor een gesandboxed omgeving die een meerdag ticket onbewaakt kan uitvoeren. Het prijsgat is echt een proxy voor hoeveel onbewakte executie je koopt.

Drie plaatsen waar we een agent de pijplijn raken laten, en drie waar niet

We voeren dit onderscheid concreet in, niet als beleid op papier.

Waar een agent groen licht krijgt: unit tests schrijven voor de webhook retry-handler, SDK-client code voor een nieuw taaldoel, eerste pass API-docs uit route-definities genereren. Niets hiervan kan een live domein of live send-queue op eigen kracht bereiken.

Waar het niet doet, volledige stop: DNS/SPF/DKIM-records bewerken, bounce-classificatiedrempels veranderen, de domain warmup-snelheidscurve aanraken. Deze drie beheren de ene bron die niet schoon terugdraait: zenderreputatie.

Hier ziet die derde categorie in de praktijk eruit, een fragment van het soort config dat een agent redelijk zou kunnen gevraagd worden om op te "schonen":

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

Een goedbedoelde agent gevraagd om "false positives te verminderen" zou spam_complaint_pause_at van 0,001 naar 0,01 kunnen verhogen, tien keer losser, en technisch gezien het ticket verhelpen. Het zou ook betekenen dat de geautomatiseerde pauze die je zenddomein beschermt niet activeert totdat klachten tien keer erger zijn. Niets in die diff ziet er gevaarlijk uit in een code review die het niet als reputatiecontrole leest.

Devin past goed in de eerste categorie wanneer correct scoped. Cognition bouwde het om engineering tickets end-to-end in zijn eigen gesandboxed omgeving te zien, wat precies de isolatie is die je wilt voordat je ooit zou overwegen het naar een shared repo met productie Terraform te wijzen.

Permissie-scope doet er meer toe dan modelkwaliteit

OWASP's Agentic Top 10 somt onverwachte codeuitvoering als zijn eigen risicacategorie op, gescheiden van prompt injection of datalekking. Die framing is correct voor infra-werk specifiek: de agent hoeft niet kwaadaardig of zelfs fout te zijn om schade aan te richten, hij hoeft alleen bredere toegang dan de taak vereist.

Onze regel, geleend van hoe we al API-sleutels voor klanten scopen: een agent krijgt een read-replica-verbinding voor alles wat send history raakt, nooit de primaire. Het krijgt een scoped serviceaccount voor Terraform-plannen, nooit de account die ze kan toepassen. De idempotency-key discipline die we in onze SDKs inbouwen geldt ook voor agent-uitgegeven API-calls.

Een scoped token voor een agentsessie ziet er aan onze kant ruwweg zo uit, vervaldatum inbegrepen:

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

Geen send_history:write, geen DNS-scope, geen toegang tot de warmup-ramp config. Als een taak echt write-toegang tot iets in die lijst nodig heeft, vraagt een mens het expliciet voor die sessie. Het komt niet gebundeld omdat de agent aardig vroeg.

Waarom we agents niet simpelweg uit de infra-repo hebben verbannen

De makkelijke oplossing zou een volledig verbod op agents in alles onder /infra zijn geweest. Dat hebben we niet gedaan, en we zouden het voor meeste teams van onze omvang tegen aanraden.

De webhook retry-handler herschrijving die een senior engineer vroeger meestal een hele dag kostte, gaat nu door een agent-concept, menselijke review en merge in minder dan twee uur. Dat is geen marketingnummer. Het is het gemiddelde over de laatste zes PR's die we hebben merged die als agent-concept in een niet-kritieke service begonnen. Agents volledig verbannen wisselt een echt, gemeten snelheidswinst in voor een risico dat scoped credentials al directer adresseren.

Een volledig verbod faalt ook stil. Engineers die de snelheid willen, voeren de agent lokaal toch uit, buiten elke review gate die het team kan zien, op een laptop met een kopie van productiereferenties in een omgevingsbestand. Access scopen in de workflow slaat het buiten verbieden.

Wat veranderde in onze eigen review gate na het lezen van de postmortems

Drie veranderingen, elk smal.

Eerst wordt elk Terraform-plan dat een agent voorstelt als dry-run diff gepost naar een review-kanaal. Niets past zonder dat een mens "apply" klikt, geen uitzonderingen voor "duidelijk veilige" wijzigingen.

Ten tweede, bounce-classificatiewijzigingen herspelen nu de vorige zeven dagen productietraces voordat merge. Als de herclassificatie meer dan 2% van opens in spam zou hebben gekanteld, wordt de PR automatisch geweigerd, geen mens nodig om het op te vangen.

Ten derde, geen agent-proces houdt standing credentials naar de primaire send-database. Een kortdurig, scoped token wordt per taak gemunt en verloopt in minder dan een uur, of de taak nu klaar is of niet.

Devin, Replit Agent, of een zelf-gehoste optie zoals Suna: kies op blast radius, niet benchmark-score

Replit Agent is gebouwd om van prompt naar gedeployde app te gaan met een deploy-stap vanaf het begin ingebakken. Dat is een legitieme sterkte voor het prototypen van een nieuwe webhook-ontvanger in een middag. Het is ook precies de ontwerpaak die het de verkeerde standaard maakt voor een repo waar "gedeployed" betekent "een live zenddomein raken."

Suna, de open-source generalist agent van Kortix, is het bekijken waard als je infra-team de executieomgeving liever zelf wil hosten in plaats van een leverancier standing toegang tot je shell te geven. Je brengt je eigen model en je eigen compute mee, wat betekent dat je ook je eigen credential scoping meebrengt, voor beter en erger.

Dit werkt niet als de agent verouderde docs leest terwijl hij een verandering plant. GitBook's sync met de repo betekent dat de agent's context over "hoe warmup hier echt werkt" aktueel blijft met de code, niet met een wiki-pagina die niemand sinds maart heeft bijgewerkt.

Dus waar zit de agent eigenlijk volgende sprint in je pipeline?

Niet in het kastje met je SPF- en DKIM-records, nog niet, niet zonder dry-run gate en scoped credential ervoor. Overal elders heeft de agent zijn zitplaats al verdiend.

Als je dit van nul opzet, begin smaller dan comfortabel voelt. Geef de agent read-toegang tot send history en docs, write-toegang tot testbestanden, en niets dat een live domein kan bereiken. Zorg dat de scope één PR tegelijk breder wordt, en alleen nadat de dry-run gate minstens één slechte diff voordat het je te pakken kreeg heeft gevangen.

De volgende beslissing is niet welke agent het hoogste benchmarkt. Het is welke taak op je board deze week een blast radius klein genoeg heeft om over te hevelen.