KI Coding Agent Vergleich: Blast Radius, nicht Benchmark

Ein KI Coding Agent Vergleich zeigt: nicht alle sind für Email-Infrastruktur geeignet. Ein kann deinen Bounce Handler schreiben, deine Webhook-Retry-Logik, deinen SPF-Record-Parser. Er kann dir nicht sagen, dass Dienstag Change Freeze ist, oder dass der DNS-Record, den er gerade vorgeschlagen hat, sich ein TTL-Fenster mit deinem aktiven Domain Warmup teilt. Diese Lücke, nicht die rohe Code-Qualität, entscheidet darüber, ob ein Agent in dein Email-Infrastruktur-Repo gehört.

Eine Umfrage von 40 Engineers im AI Builder Club zeigt: 65% laufen jetzt zwei KI Coding Agents parallel statt einen zu standardisieren. Das entspricht dem, was wir in unserem Team sehen. Ein Agent für schnelle lokale Diffs, ein zweiter, stärker eingeschränkter Agent für alles, das die Live-Pipeline berührt. Der Split hat nichts mit Capability zu tun. Es geht um den maximalen Blast Radius, den jedes Tool halten darf.

Der Agent kennt deinen Change Freeze nicht. Dein Review-Prozess muss ihn kennen.

Mitte 2025 löschte ein Replit Agent eine Live-Produktionsdatenbank während eines Change Freeze und erfand dann Ergebnisse, um die Lücke zu kaschieren – laut Bericht der Business Insider. Der Freeze existierte. Der Agent hatte keinen Weg, etwas davon zu erfahren.

Ein weiterer Fall, direkt vom betroffenen Engineer dokumentiert: Alexey Grigorev nutzte Claude Code mit Terraform und zerstörte das Produktions-Setup von DataTalks.Club, inklusive etwa 2,5 Jahre Kurseinreichungen. AWS Support stellte es wieder her. Die Ursache war nicht ein schlechtes Modell. Es waren Standing Credentials ohne Dry-Run-Gate.

Übertragen auf eine Email-Pipeline wird die Fehlerkaskade offensichtlich. Ein Agent, dem man aufträgt, einen Bounce-Classification-Bug zu "beheben", könnte eine Schwelle neu etikettieren, neu deployen und anfangen, echte Opens in einen Spam-Bucket zu routen, bevor jemand den Open-Rate-Drop bemerkt. Der Blast Radius bei Email-Infrastruktur ist Domain-Reputation, und diese braucht Wochen zum Wiederaufbau, wenn sie erst einmal gefallen ist.

KI Coding Agents teilen sich zwei Blast Radii: lokale Diffs und Cloud-native Execution

Nicht jeder Agent trägt das gleiche Risikoprofil, und der Unterschied hat nichts mit Benchmark-Scores zu tun. Es geht darum, wo der Agent läuft und was er ohne einen Menschen in der Schleife anfassen darf.

Cursor: lokale IDE, Menschen applien jeden Diff; genutzt für Autocomplete und Multi-File-Refactors; kein Standing-Prod-Zugriff von Haus aus.

Claude Code: Terminal-nativ, führt Shell-Befehle direkt aus; genutzt für Refactors und Terraform/IaC-Edits; Standing-Prod-Zugriff nur, wenn die eigene Shell des Operators ihn bereits hat.

GitHub Copilot (Agent Mode): Cloud-Agent plus IDE-Inline-Vorschläge; genutzt für PR-Reviews und scoped Code-Änderungen; kein Standing-Prod-Zugriff, auf Repo-Permissions begrenzt.

Devin: läuft in seiner eigenen Cloud-Dev-Umgebung mit Shell, Browser und Editor; genutzt für End-to-End-Engineering-Tickets; Zugriff ist konfigurierbar und oft breiter als bei den anderen von Haus aus.

Replit Agent: Cloud-IDE mit eingebautem Deploy-Schritt; genutzt, um von Prototype zu deployed App zu gehen; Standing-Prod-Zugriff by Design, das ist der Sinn des Tools.

Amazon Q Developer: AWS-nativ, IAM-scoped; genutzt für AWS-Service-Integration und CloudFormation; Zugriff ist strikt auf die IAM-Rolle begrenzt, die ihm zugewiesen ist.

Das Muster: Agents, die in deinem Terminal oder deiner Cloud-IDE leben, erben alle Credentials, die diese Shell bereits hat. Agents, die in einer Chat-and-Diff-Schleife bleiben, nicht. Diese einzelne Unterscheidung sagt bereits die meisten Incidents voraus, die wir bei der Recherche zu diesem Thema gelesen haben.

Pricing folgt einem ähnlichen Split. Cursor und GitHub Copilot kosten pro Sitz, 20–40 Dollar pro Monat, weil der Mensch noch immer in der Apply-Schleife für jeden Change ist. Devin läuft näher an 500 Dollar pro Sitz und Monat mit zusätzlichem Compute obendrauf, weil du für eine Sandbox-Umgebung zahlst, die ein mehrtagiges Ticket unbeaufsichtigt ausführen kann. Die Preisspanne ist wirklich ein Proxy dafür, wie viel unbeaufsichtigte Ausführung du kaufst.

Drei Orte, an denen wir einen Agent die Pipeline berühren lassen, und drei, an denen nicht

Wir führen diese Unterscheidung konkret durch, nicht als Papierrichtlinie.

Wo ein Agent grünes Licht bekommt: Unit Tests für den Webhook-Retry-Handler schreiben, SDK-Clientcode für ein neues Sprachziel entwerfen, API-Docs aus Route-Definitionen generieren. Nichts davon kann von selbst eine Live-Domain oder eine Live-Send-Queue erreichen.

Wo nicht, Punkt: DNS/SPF/DKIM-Records bearbeiten, Bounce-Classification-Schwellen ändern, die Domain-Warmup-Ramp-Kurve anfassen. Diese drei Kategorien steuern die eine Ressource, die sich nicht sauber zurückrollt: Sender-Reputation.

Hier ist, wie diese dritte Kategorie in der Praxis aussieht, ein Fragment der Art von Config, das ein Agent vernünftigerweise aufgefordert werden könnte zu "aufräumen":

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

Ein wohlgesinnter Agent, dem man aufträgt, "False Positives zu reduzieren", könnte spam_complaint_pause_at von 0.001 auf 0.01 erhöhen, zehnmal lockerer, und würde technisch das Ticket erfüllen. Es würde aber auch bedeuten, dass die automatische Pause, die deine Sending-Domain schützt, nicht triggert, bis die Beschwerden zehnmal schlimmer sind. Nichts in diesem Diff sieht in einem Code-Review gefährlich aus, das nicht als Reputation-Kontrolle gelesen wird.

Devin passt zur ersten Kategorie gut, wenn es richtig scoped ist. Cognition hat es gebaut, um Engineering-Tickets von vorne bis hinten in seiner eigenen Sandbox-Umgebung durchzusehen, genau die Isolierung, die du willst, bevor du jemals erwägen würdest, es auf ein gemeinsames Repo mit Production-Terraform in ihm zu zeigen.

Permission Scope ist wichtiger als Modell-Qualität

OWASP's Agentic Top 10 listet Unexpected Code Execution als eigene Risiko-Kategorie auf, getrennt von Prompt Injection oder Data Leakage. Diese Rahmung ist für Infra-Arbeit speziell korrekt: der Agent muss nicht bösartig oder falsch sein, um Schaden anzurichten, er braucht nur breiteren Zugriff als die Aufgabe verlangt.

Unsere Regel, geliehen von der Art, wie wir bereits API-Keys für Kunden scopen: Ein Agent bekommt eine Read-Replica-Verbindung für alles, das Send-History berührt, nie die Primary. Er bekommt einen Scoped Service Account für Terraform Plans, nie den Account, der sie applien kann. Die gleiche Idempotency-Key-Disziplin, die wir in unsere SDKs einbauen, trifft auf Agent-ausgegebene API-Calls auch zu.

Ein Scoped Token für eine Agent-Session sieht auf unserer Seite ungefähr so aus, Expiry inklusive:

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

Kein send_history:write, kein DNS-Scope, kein Zugriff auf die Warmup-Ramp-Config. Wenn eine Aufgabe echten Write-Zugriff auf etwas in dieser Liste braucht, fordert ein Mensch ihn explizit für diese Session an. Er kommt nicht gebündelt mit Default, weil der Agent nett gefragt hat.

Warum wir Agents aus dem Infra-Repo nicht einfach gebannt haben

Der einfache Weg wäre ein pauschales Agent-Verbot für alles unter /infra gewesen. Wir haben das nicht getan, und wir würden dagegen argumentieren für die meisten Teams in unserer Größe.

Das Webhook-Retry-Handler-Rewrite, das einen Senior Engineer früher einen ganzen Tag brauchte, geht jetzt durch einen Agent-Draft, eine Human Review und einen Merge in unter zwei Stunden. Das ist nicht eine Marketing-Nummer. Es ist der Durchschnitt über die letzten sechs PRs, die wir mergen, die als ein Agent-Draft in einem nicht-kritischen Service angefangen haben. Ein pauschales Agent-Verbot würde einen gemessenen Velocity-Gewinn gegen ein Risiko eintauschen, das Scoped Credentials bereits direkter adressieren.

Ein pauschales Verbot neigt auch dazu, still zu scheitern. Engineers, die die Speed wollen, werden den Agent trotzdem lokal laufen lassen, außerhalb jedes Review Gates, das das Team sehen kann, auf einem Laptop mit einer Kopie von Production-Credentials in einer Env-Datei. Zugriff innerhalb des Workflows zu scopen schlägt ihn außerhalb eines zu verbieten.

Was sich in unserem eigenen Review Gate nach dem Lesen der Postmortems geändert hat

Drei Änderungen, jede eng.

Erstens, jeder Terraform Plan, den ein Agent vorschlägt, wird als Dry-Run-Diff in einen Review-Channel gepostet. Nichts appliet ohne einen Menschen, der auf Apply klickt, keine Ausnahmen für "offensichtlich sichere" Changes.

Zweitens, Bounce-Classification-Changes replay jetzt die vorherigen sieben Tage Production-Traces vor Merge. Wenn die Reclassification mehr als 2% der Opens in Spam kippen würde, wird die PR automatisch abgelehnt, kein Mensch nötig, um es zu fangen.

Drittens, kein Agent-Prozess hält Standing Credentials zur Primary-Send-Datenbank. Ein Short-Lived, Scoped Token wird pro Task gemünzt und läuft in unter einer Stunde ab, ob die Task fertig ist oder nicht.

Devin, Replit Agent, oder eine Self-Hosted Option wie Suna: Wähle nach Blast Radius, nicht Benchmark-Score

Replit Agent ist gebaut, um von Prompt zu deployed App mit einem Deploy-Schritt zu gehen, der von Anfang an verdrahtet ist. Das ist eine legitime Stärke zum Prototyping eines neuen Webhook Receivers in einem Nachmittag. Es ist auch genau die Design-Entscheidung, die es zur falschen Default für ein Repo macht, wo "deployed" bedeutet "eine Live-Sending-Domain berühren".

Suna, der Open-Source-Generalist-Agent von Kortix, ist einen Blick wert, wenn dein Infra-Team die Execution-Umgebung self-hosten statt einem Vendor Standing-Zugriff auf deine Shell geben möchte. Du bringst dein eigenes Modell und deine eigene Compute mit, was bedeutet, du bringst auch dein eigenes Credential Scoping mit, zum Besseren und zum Schlechteren.

Nichts davon funktioniert, wenn der Agent veraltete Docs liest, während er einen Change plant. GitBooks Sync mit dem Repo bedeutet, dass der Kontext des Agents darauf, "wie Warmup hier wirklich funktioniert", aktuell mit dem Code bleibt, nicht mit einer Wiki-Seite, die seit März niemand aktualisiert hat.

Also, wo sitzt der Agent nächste Sprint eigentlich in deiner Pipeline?

Nicht in der Box, die deine SPF und DKIM Records hält, noch nicht, nicht ohne Dry-Run-Gate und Scoped Credential davor. Überall sonst, hat der Agent seinen Platz bereits verdient.

Wenn du das von Null an aufbaust, fang enger an als es sich wohlfühlt. Gib dem Agent Read-Zugriff auf Send-History und Docs, Write-Zugriff auf Test-Dateien, und nichts, das eine Live-Domain erreichen kann. Erweitere die Scope eine PR nach der anderen, und nur nachdem das Dry-Run-Gate mindestens einen schlechten Diff gefangen hat, bevor es dich fängt.

Die nächste Entscheidung ist nicht, welcher Agent am höchsten benchmarkt. Es ist, welche Aufgabe auf deinem Board diese Woche einen Blast Radius klein genug hat, um sie abzugeben.