Zerstören AI-Coding-Agents deine CI/CD-Pipeline?

Letzten Monat rief mich ein Kunde an, weil sich seine GitHub-Actions-Rechnung verdreifacht hatte. Drei Entwickler, dasselbe Repo, dieselbe Codebase. Das Einzige, was sich geändert hatte: Sie hatten Copilot und Codex Commit-Zugriff gegeben. Dutzende kleine PRs pro Tag, die meisten fehlerhaft, keiner wurde gefixt. Ihre CI lief Builds durch, die niemals grün werden würden.

Also ging ich auf die Suche nach Daten.

Ich habe eine Studie durchgeführt, die 24.560 Pull Requests in 447 Open-Source-Repositories analysiert hat. Ich habe jeden PR mit seinen tatsächlichen GitHub-Actions-Workflow-Runs verknüpft, Job-Ergebnisse in sechs Kategorien klassifiziert und Propensity-Score-Matching verwendet, um Störfaktoren wie Repo-Größe, PR-Komplexität und Timing zu kontrollieren. Die Datenaufteilung war 20.463 AI-generierte PRs gegen 4.097 menschlich verfasste.

Beobachtbare Störfaktoren wie Repo-Alter, Star-Anzahl und PR-Größe erklären etwa 54 % der Rohdifferenz. Der Rest bleibt nach der Adjustierung bestehen.

Aber diese Zahl allein ist im Grunde nutzlos. Der interessante Teil ist, wo sich die Fehler häufen.

Kleine PRs sind das eigentliche Problem

Die AI-Strafe existiert nur bei kleinen Pull Requests.

Unter 55 Codezeilen scheitern AI-generierte Änderungen doppelt so häufig wie menschliche Änderungen (OR = 2,12). Über 400 Zeilen verschwindet der Unterschied. Bei den größten PRs schneidet AI sogar etwas besser ab als Menschen.

Der Grund ist naheliegend. Kleine AI-PRs sind spekulative Einzelversuche. Der Agent probiert etwas, pusht es und geht weiter. Niemand reviewt einen 12-Zeilen-Bot-Commit so wie einen 600-Zeilen-Feature-Branch. Große AI-PRs werden tendenziell reviewed, bearbeitet und lokal getestet, bevor sie die Pipeline erreichen. Größe ist ein Indikator dafür, wie sehr sich ein Mensch um die Änderung gekümmert hat, bevor sie verschickt wurde.

Es scheitert am Linting, nicht an Tests

Hier ist der Teil, der mich überrascht hat. Nach Kontrolle für Within-Repo-Clustering ist der Unterschied bei Testfehlern zwischen AI- und menschlichen PRs nicht statistisch signifikant. Tests bestehen ungefähr gleich häufig.

Was explodiert, ist das Linting. AI-PRs lösen 76 % mehr Lint-Verstöße aus als menschliche PRs.

Wenn du schon mal gesehen hast, wie Copilot eine perfekt funktionale Funktion mit Tabs statt Spaces, einfachen statt doppelten Anführungszeichen und Imports in der falschen Reihenfolge generiert, dann ist genau das, was in 447 Repos im großen Maßstab passiert. Der Agent schreibt Code, der kompiliert, läuft, Tests besteht und dann von einer Formatierungsregel abgelehnt wird, von der er nie erfahren hat.

Niemand fixt die kaputten PRs

Das ist das Ergebnis, das dich mehr beunruhigen sollte als die Fehlerrate selbst.

Wenn ein AI-PR bei der CI scheitert, wird er fast nie repariert. 9,3 % der fehlgeschlagenen AI-PRs bestehen schließlich bei einem späteren Lauf. Bei menschlichen PRs liegt diese Zahl bei 23,4 %. Fehlgeschlagener AI-Code wird 2,5-mal häufiger aufgegeben als gefixt.

Deine Pipeline führt nicht nur mehr fehlgeschlagene Builds aus. Sie führt fehlgeschlagene Builds aus, die in der Warteschlange liegen bleiben, bis jemand sie manuell schließt und dabei die ganze Zeit Rechenleistung verbrauchen. Der Kunde, den ich erwähnt habe? Er hatte 340 offene Bot-PRs, alle rot, alle seit Wochen unberührt. Niemand hat sie sich mehr angeschaut.

Was du dagegen tun kannst

Das Erste ist, nicht jeden kleinen Bot-Commit deine gesamte Pipeline auslösen zu lassen. Ein zweiminütiger Vorcheck (nur Lint und Type-Check, kein Build, keine Integrationstests) fängt die 76 %-Lint-Lücke ab, bevor du teure CI-Minuten für Code verbrennst, der sowieso nie bestehen würde. GitHub Actions unterstützt das nativ mit Pfadfiltern und Job-Conditions. Die meisten Teams, mit denen ich arbeite, richten das an einem Nachmittag ein.

Zweitens: Schließe veraltete Bot-PRs automatisch. Wenn ein AI-PR scheitert und innerhalb von 48 Stunden keine Commit-Aktivität zeigt, ist er tot. Schließ ihn. Eine GitHub Action oder ein einfaches Cron-basiertes Script, das nach Bot-erstellten PRs sucht, die älter als zwei Tage sind und fehlschlagende Checks haben, räumt deine Queue in Sekunden auf. Die 91 %-Abbruchrate bedeutet, dass du hier ruhig aggressiv sein kannst.

Drittens (und das ist der einfachste Gewinn): Übergib deine Linter-Konfiguration an den Agenten. Wenn du ESLint, Prettier, Ruff, Black oder was auch immer dein Stack verlangt verwendest, füge diese Config-Dateien in das Context-Window des Agenten ein. Die meisten AI-Coding-Tools unterstützen das mittlerweile. Die Lint-Lücke ist keine grundsätzliche Einschränkung der AI-Code-Generierung. Es ist ein Konfigurationsproblem. Fix die Config, und ein großer Teil deiner Fehler verschwindet.

Das letzte Puzzleteil ist die Pipeline-Architektur. Die meisten CI-Setups wurden für menschliche Rhythmen designed: eine Handvoll PRs pro Tag, jeder einzelne repräsentiert Stunden fokussierter Arbeit. AI-Agents reichen Dutzende PRs pro Tag ein, jeder ein schneller Versuch. Deine Concurrency-Limits, deine Caching-Strategie, deine Benachrichtigungsregeln, die Art, wie du Runner zuweist - alles basierte auf einem Muster, das nicht mehr gilt. Ein Audit dieser Annahmen dauert ein paar Stunden und kann deine CI-Kosten um 40-60 % senken.

Die eigentliche Frage

AI-Coding-Agents sind nicht generell schlecht für die CI. Sie scheitern an kleinen spekulativen Änderungen und Lint-Compliance. Bei großen, gut reviewten Beiträgen funktionieren sie gut. Das pauschale "AI-Code ist schlechter"-Narrativ passt nicht zu den Daten.

Die eigentliche Frage ist, ob deine Infrastruktur für die Art und Weise konzipiert wurde, wie diese Tools tatsächlich funktionieren. Für die meisten Teams, mit denen ich spreche, lautet die Antwort nein. Und die Lösung ist günstiger als das Problem.