Von Agenten erzeugten Code verantwortungsvoll behandeln: Vercels Framework

• Coding-Agenten erzeugen Code mit beispielloser Geschwindigkeit, können aber ohne strenges Urteilsvermögen zu einem effizienten Weg werden, falsche Annahmen direkt in die Produktion auszurollen
• Von Agenten erzeugter Code kommt mit PR-Beschreibung, bestandener statischer Analyse und Testabdeckung daher und wirkt wie von einem erfahrenen Engineer geschrieben, berücksichtigt aber weder Traffic-Muster, Fehlermodi noch Infrastrukturgrenzen realer Produktionsumgebungen
• AI zu nutzen (leveraging) und sich auf sie zu verlassen (relying) sind grundverschiedene Dinge; echte Nutzung bedeutet, Funktionsweise und Risiken der Agenten-Ausgaben vollständig zu verstehen und dafür die Verantwortung zu übernehmen
• Mit den drei Prinzipien Self-driving Deployments, Continuous Validation und Executable Guardrails lässt sich eine Umgebung schaffen, in der Agenten mit hoher Autonomie handeln und zugleich sicher bleiben
• Es ist eine Zeit angebrochen, in der nicht die Engineers überleben, die am meisten Code erzeugen, sondern diejenigen, die sich ein nüchternes Urteilsvermögen darüber bewahren, was ausgerollt werden sollte

---

Das Problem: Green CI ist kein Sicherheitsnachweis mehr

• Ein bestandener CI-Lauf zeigt nur, dass ein Agent die Pipeline überzeugen konnte, sagt aber nichts über die tatsächliche Sicherheit der Infrastruktur aus
  • Es kann eine Query ausgerollt werden, die Tests besteht, in Produktion aber vollständige Zeilen-Scans ausführt
  • Retry-Logik, die harmlos wirkt, kann bei Downstream-Services einen Thundering Herd auslösen
  • Ein Cache ohne TTL kann Redis still und leise in den Tod treiben
• Agenten wissen nichts über den Auslastungszustand einer Redis-Instanz, darüber, ob in der DB eine bestimmte Region hart codiert ist, oder darüber, dass ein Feature-Flag-Rollout das Lastprofil nachgelagerter Systeme verändert
• Die Lücke zwischen „Dieser PR sieht korrekt aus“ und „Dieser PR kann sicher ausgerollt werden“ hat immer existiert — und Agenten vergrößern sie weiter

Die entscheidende Unterscheidung: Nutzung vs. Verlassen

• Verlassen (Relying): der Ansatz, davon auszugehen, dass etwas bereit für den Rollout ist, sobald der Agent es geschrieben hat und die Tests grün sind
  • Der Autor baut kein mentales Modell der Änderung auf
  • Es entstehen riesige PRs voller versteckter Annahmen, bei denen weder Autor noch Reviewer wirklich verstehen, was der Code tatsächlich tut
• Nutzen (Leveraging): der Ansatz, Agenten für schnelle Iteration einzusetzen und zugleich die volle Verantwortung für die Ausgabe zu behalten
  • Man versteht genau, wie sich der Code unter Last verhält
  • Man versteht die relevanten Risiken und ist bereit, sie zu tragen
• Den eigenen Namen unter einen PR zu setzen bedeutet: „Ich habe ihn gelesen und verstehe, was er tut“ — das ist der Maßstab des Engineering-Prozesses

Maßstab für das Urteilsvermögen: der Litmus-Test

• Einfacher Test: „Würde ich mich wohl damit fühlen, einen Produktionsvorfall zu verantworten, der mit diesem PR verbunden ist?“
• Drei Fragen, die man sich vor dem Erstellen eines PR stellen sollte
  • Was tut dieser Code? Wie verhält er sich nach dem Rollout?
  • Welche negativen Auswirkungen könnte er auf Produktion oder Kunden haben?
  • Würde ich mich wohl damit fühlen, einen mit diesem Code verbundenen Vorfall zu verantworten?
• Wenn die Antwort „Ja“ lautet, wurde AI genutzt und der Rollout ist vertretbar; lautet sie „Nein“, ist noch Arbeit nötig

Die Lösung: Drei Prinzipien zum Schutz der Produktion

• Self-driving Deployments: Jede Änderung wird über eine kontrollierte Pipeline schrittweise ausgerollt; Canary-Deployments rollen bei Leistungsabfall automatisch zurück
  • Es wird nicht darauf vertraut, dass Engineers ständig Dashboards beobachten
  • Probleme werden nur auf einen Teil des Traffics begrenzt statt auf das Ganze
• Continuous Validation: Nicht nur zum Deployment-Zeitpunkt, sondern dauerhaft wird die Infrastruktur selbst getestet
  • Lasttests, Chaos-Experimente und Disaster-Recovery-Übungen laufen kontinuierlich
  • Deshalb hatte das Database Failover, das Vercel letzten Sommer in Produktion geprobt hatte, beim tatsächlichen Azure-Ausfall keine Auswirkungen auf Kunden
• Executable Guardrails: Betriebswissen wird nicht in Dokumenten, sondern in ausführbaren Tools kodiert
  • Die safe-rollout-Skill ist keine Notion-Seite, die erklärt, wie Feature-Flags funktionieren, sondern ein Tool, das Flags verdrahtet, einen Rollout-Plan mit Rollback-Bedingungen erstellt und angibt, wie das erwartete Verhalten validiert wird
  • Wenn Guardrails ausführbar sind, können Agenten ihnen autonom folgen, und Menschen müssen sie nicht auswendig lernen

Worin Vercel tatsächlich investiert

• Stärkung gemeinsamer Infrastruktur-Guardrails mit Runtime-Validierung über alle Phasen der Deployment-Pipeline hinweg
• Verstärkte statische Prüfungen in der PR-Phase, insbesondere rund um Feature-Flags
• Einführung von End-to-End-Tests mit Production Mirroring in Staging-Umgebungen
• Betrieb schreibgeschützter Agenten, die Systeminvarianten in Produktion fortlaufend validieren, sowie Einsatz spezialisierter Agenten, die Annahmen generativer Agenten auditieren
• Einführung von Metriken wie Defect-Commit-zu-Defect-Escape-Rate, um zu erkennen, ob das Risiko über die Plattform hinweg zunimmt

Fazit: Engineers mit Urteilsvermögen sind wettbewerbsfähig

• Implementierung ist reichlich vorhanden; die knappe Ressource ist nun das Urteilsvermögen darüber, was sicher ausgerollt werden kann
• Die Zeit, in der schlechter Code auch schlecht aussah, ist vorbei; AI-Tools werden mächtiger, Diffs größer und die Versuchung, Ausgaben blind zu vertrauen, wird zunehmen
• Das Ziel ist nicht eine Welt, in der auf jede Änderung außergewöhnliche Strenge angewandt wird, sondern eine Welt, in der die Infrastruktur selbst streng ist — eine Umgebung, in der schnelles Ausrollen standardmäßig sicher ist