Warum unsere KI-Agenten jeden Pull Request gegen 40 automatisierte Checks laufen lassen

KI-Agenten schreiben Code schneller, als Menschen ihn lesen können. Das ist ihr größter Vorteil und ihr größtes Risiko zugleich. Denn die klassische Qualitätssicherung der Softwareentwicklung, das menschliche Code-Review, war nie dafür gebaut, hunderte generierte Änderungen pro Woche zu prüfen. Wer KI-Geschwindigkeit will, ohne die Kontrolle zu verlieren, muss die Prüfung selbst automatisieren. Bei uns bedeutet das: Kein Pull Request erreicht den Hauptzweig, ohne rund 40 automatisierte Checks bestanden zu haben. Dieser Artikel zeigt, welche das sind und warum jeder einzelne existiert.

Das Grundproblem: Review-Kapazität ist der Flaschenhals

Als wir anfingen, systematisch mit Coding-Agenten zu arbeiten, kippte das Verhältnis schnell: Die Agenten produzierten an einem Tag, was das Team früher in einer Woche geschrieben hätte. Das menschliche Review wurde zum Flaschenhals, und Reviewer unter Zeitdruck winken durch. Genau da entstehen die Produktionsfehler, die KI-generiertem Code seinen schlechten Ruf eingebracht haben.

Unsere Antwort war, das Review in zwei Hälften zu teilen: Alles, was eine Maschine zuverlässiger prüft als ein Mensch, prüft die Maschine, und zwar vollständig und bei jedem einzelnen Pull Request. Der Mensch prüft nur noch das, was Urteilskraft braucht.

Die Check-Kategorien im Überblick

Unsere Pipeline gruppiert sich in sechs Blöcke:

Korrektheit (Tests). Unit-Tests, Integrationstests und End-to-End-Tests der kritischen Nutzerpfade. Neue Features ohne zugehörige Tests werden abgelehnt, das gilt für Agenten genauso wie für Menschen. Die Testabdeckung darf durch keinen Pull Request sinken.

Typsicherheit und statische Analyse. Vollständige Typprüfung ohne Ausnahmen, Linting mit strikten Regeln, Erkennung von totem Code und unerreichbaren Pfaden. KI-Modelle produzieren syntaktisch eleganten Code mit subtilen Logikfehlern, statische Analyse fängt eine erstaunliche Menge davon, bevor ein Test überhaupt läuft.

Sicherheit. Scan aller Abhängigkeiten gegen bekannte Schwachstellen, Erkennung von versehentlich eingecheckten Secrets, statische Sicherheitsanalyse des eigenen Codes, Prüfung der Lizenz jeder neuen Abhängigkeit. Der letzte Punkt wird unterschätzt: Agenten ziehen gerne die erstbeste Bibliothek, und nicht jede Lizenz ist mit kommerzieller Nutzung verträglich.

Architektur-Grenzen. Automatisierte Regeln, welche Module aufeinander zugreifen dürfen. Das klingt banal, ist aber der Check, der langfristig die Wartbarkeit rettet: Agenten nehmen ohne diese Leitplanken zuverlässig die kürzeste Abkürzung quer durch die Architektur.

Datenbank und Verträge. Jede Schemamigration wird gegen eine Kopie realer Datenstrukturen getestet, jede API-Änderung gegen die dokumentierten Schnittstellenverträge geprüft. Breaking Changes ohne Versionierung fallen hier durch.

Performance und Ressourcen. Budgets für Bundle-Größen, Erkennung offensichtlicher Performance-Fallen wie N+1-Abfragen, Laufzeitlimits der Testsuite selbst.

Der entscheidende Trick: Die Schleife läuft ohne Menschen

Der eigentliche Effizienzgewinn liegt nicht in den Checks selbst, sondern in dem, was bei einem Fehlschlag passiert: Das Ergebnis geht zurück an den Agenten, nicht an einen Menschen. Der Agent liest den Fehler, korrigiert, die Pipeline läuft erneut. Erst wenn alle Checks grün sind, sieht ein menschlicher Reviewer den Pull Request überhaupt. Unsere Entwickler reviewen dadurch ausschließlich Code, der nachweislich funktioniert, typsicher ist und keine bekannten Schwachstellen enthält. Ihre Aufmerksamkeit gehört den Fragen, die Maschinen nicht beantworten können: Ist das fachlich richtig? Passt es zur Architektur? Wollen wir das so?

Was du davon übernehmen kannst

Nichts an dieser Pipeline ist Geheimwissen, die Werkzeuge sind größtenteils Open Source. Was den Unterschied macht, ist Konsequenz: alle Checks, bei jedem Pull Request, ohne Ausnahmen für dringende Fälle. Die dringenden Fälle sind erfahrungsgemäß genau die, in denen ungeprüfter Code den größten Schaden anrichtet. Wenn dein Team KI-Tools nutzt und ihr diese Disziplin aufbauen wollt, ist genau das der Kern unseres Team-Enablements. Und warum diese Pipeline nur eine von vier Schichten unseres Qualitätssystems ist, erklärt der Überblick zu unserem Verifikations-Framework.