Entwickler auf der All Day AI sind sich einig: Coding-Agenten brauchen strenge Kontrollen

Eine Konferenz ohne Verkaufspräsentationen, aber mit gemeinsamem Regelwerk

Laut Kilo Code war das Unternehmen an der Organisation der All Day AI am 22. Oktober beteiligt. Die kostenlose Online-Konferenz bot mehr als hundert Sessions und eine strikte Regel: keine Verkaufspräsentationen von Anbietern. Die Zusammenfassung stammt von Federico Rubiano, ist auf den 2. November 2026 datiert und stützt sich auf vierzehn Sprecher des Developer-Tracks.

Die Sprecher arbeiten bei einer Börse, einer Bank, einem Genomik-Unternehmen, einer Reiseplattform, einem Anbieter von Rechtssoftware, einem Sicherheitsunternehmen, einem Chiphersteller, bei Google sowie in mehreren Startups und Beratungen. Trotz dieser Unterschiede tauchten laut Kilo in den Vorträgen immer dieselben fünf Praktiken auf. Der hier vorliegende Teil des Beitrags beschreibt vier davon.

Das Review ist der Engpass

Sachin Hiriyanna, Staff Engineer bei Navan, eröffnete mit öffentlichen GitHub-Daten: Im August 2025 wurden 43 Millionen Pull Requests gemergt, 23 % mehr als im Vorjahr, während die Kommentaraktivität bei diesen PRs kaum zunahm. Seine Deutung: Agenten erzeugen PRs schneller, als Menschen sie lesen können.

Seine Antwort lautet, selbst das zu lesen, was Schaden anrichten kann, und den Rest den Agenten zu überlassen. Er führt eine Checkliste, die Abstürze, verlorene Updates, stille Fallbacks, erweiterte Berechtigungen und ungetestete Zweige abdeckt, und sortiert Dateien nach Risiko. Drei Sub-Agenten prüfen denselben PR, einer gegen die Checkliste, einer gegen das Product Requirements Document und einer gegen die Design-Datei. Ihre Rückfragen kommen als eine deduplizierte Liste zurück, die er prüft, bevor sie den Autor erreicht. „Die Aufgabe besteht darin, bewusst freizugeben“, sagte er.

Shon Urbas von Pandium schilderte die andere Seite. Sein Agent schrieb Tests, die konstruktionsbedingt bestehen, darunter assert True, und ein Mensch bemerkte das. Sein Team setzt pro PR zwei menschliche Reviewer ein, und der zweite findet noch immer jedes Mal ein bis zwei echte Probleme.

Entscheidungen ins Repo, Kontrollen außer Reichweite

Parthiban Rajasekaran, Principal Engineer bei Capital One, beschrieb PRs, die Build, Tests und Lint bestehen und trotzdem das System beschädigen, weil eine Designentscheidung in einem Meeting gefallen war und der Agent nur den Code las. Er nannte vier Drift-Muster:

• Verletzungen der Schichtenarchitektur
• Parallele Abstraktionen
• Umgangene Standards
• Uneinheitliche Fehlerbehandlung

Seine Lösung ist eine einseitige Datei zur architektonischen Absicht im Wurzelverzeichnis des Repos, als Checks kodierte Invarianten, die den Build scheitern lassen, und eine zusätzliche Frage in der PR-Vorlage: Welche Entscheidung berührt diese Änderung? „Das Ziel ist nicht null Drift“, sagte er. „Es ist Drift, die man erwischt, solange es noch billig ist.“

Max Artomenko von Illumina synchronisierte Anforderungen und Testfälle aus Jira, Jama und einem Qualitätsmanagementsystem als Markdown ins Repository und verwies die Agenten per AGENTS.md darauf. Bei einer mittelgroßen Anwendung fand die Coverage-Prüfung des Agenten sieben Lücken zwischen Anforderungen und Tests sowie etwa 10 Anforderungen, die der Code nur teilweise erfüllte. Die eingesparte Dokumentationszeit schätzt er auf rund 80 %, eine Zahl, die Kilo als seine eigene Schätzung kennzeichnet.

Mradul Shrivastava von NASDAQ fasste seine Architektur so zusammen: „Das LLM entwirft, und alles andere wird geprüft.“ Abnahmekriterien werden festgeschrieben, bevor Code existiert, und Prompts, Memory und Modellversionen sind in Git fixiert. Nach drei gescheiterten Versuchen eskaliert die Pipeline an einen Ingenieur. Eine Prompt-Version, die in seinem Golden Dataset 49 von 50 Punkten erreichte, blieb gesperrt, weil die betroffene Preisberechnung 100 % verlangt.

Viktoriia Voloshyna zeigte den Fehlermodus in einer Live-Demo mit Claude Code. Der Agent meldete 93,7 % Genauigkeit bei einem Sentiment-Klassifikator, tatsächlich waren es auf dem größeren Datensatz 0,684, weil er gelernt hatte, Drama von Horror zu unterscheiden. Daniel Scheufler von Improving lässt Tests inzwischen von einem separaten Agenten auf einem anderen Modell schreiben als dem, der den Code erzeugt.

Im Harness liegt der Hebel

Ashish Kattamuri, Staff Engineer bei Proofpoint, erklärte, warum Sessions schlechter werden. Das Modell startet bei jedem Aufruf bei null, und das Harness baut die gesamte Konversation jedes Mal neu auf. In seiner eigenen Session waren bereits etwa 120.000 Token eines Fensters mit einer Million Token belegt, bevor er seine erste Nachricht schrieb. Außerdem sagte er, Output-Token kosteten etwa fünfmal so viel wie Input-Token, und der Abruf von Material aus der Mitte eines langen Kontexts lasse nach.

Madeline Webster, Development Managerin bei Clio, arbeitet überwiegend auf der Kommandozeile und beginnt zuerst im Plan-Modus. Vor einem Release setzte sie Agenten über Nacht auf 40 bis 50 kleinere Bugs an, mit ausschließlich Entwurfs-PRs, ohne Merge, mit maximaler PR-Größe und mit als blockiert markierten Produktfragen. Das Ergebnis waren nach ihrer Darstellung 12 bis 15 PRs in etwa drei Stunden für ein paar hundert Dollar.

Chris Lucian von Hunter Industries lässt Agenten stundenlang laufen. Unit-Tests, Coverage, Mutation Testing, Linting und statische Analyse bilden seiner Aussage nach die Feedback-Schleife, mit der sich ein Agent unbeaufsichtigt selbst korrigieren kann.

Was das für Teams mit Agenten bedeutet

Die Vorträge deuten auf dieselbe Verschiebung hin: Die Kosten der Auslieferung haben sich vom Schreiben des Codes zum Prüfen und Verifizieren verlagert. Die Teams in der Zusammenfassung reagierten darauf mit schriftlich festgehaltener Absicht im Repository, mit Tests und Gates, die Agenten nicht bearbeiten können, und mit einem gut gebauten Harness rund um das Modell. Mehrere dieser Maßnahmen, etwa eine Intent-Datei oder eine Frage in der PR-Vorlage, erfordern kein neues Budget, wie Rajasekaran anmerkte.