Der Slack-Channel hieß #ci-alerts. Zwölf Leute waren drin. Als ich ihn an einem Montagmorgen zum ersten Mal geöffnet habe, hatte er 94 ungelesene Benachrichtigungen vom Wochenende. Alle rot. Alle CI-Failures. Alle von bot-geschriebenen Pull Requests, die niemand jemals reparieren würde.
Ich habe zurückgescrollt, um die letzte menschliche Reaktion in dem Channel zu finden. Donnerstag. Vier Arbeitstage Stille. Nicht weil das Team faul war. Weil der Channel physisch unmöglich geworden war zu benutzen.
Das war ein Sechser-Engineering-Team bei einem Startup, das ich berate. Sie hatten zwei ihrer Entwickler ungefähr einen Monat vorher Zugang zu Cursor und Copilot gegeben. Beide Engineers waren begeistert. Beide haben angefangen, PRs in einem Tempo zu pushen, das das Team noch nie gesehen hatte. Fünfzehn, manchmal zwanzig am Tag zwischen den beiden. Kleine Änderungen, meistens. Zwölf Zeilen hier, dreißig Zeilen dort. Schnelle Fixes, die der Agent vorgeschlagen hat, sofort gepusht.
Die Agents waren produktiv. Sie lagen auch bei ungefähr einem Drittel daneben.
Was eine 30-%-Fehlerrate in einem Slack-Channel tatsächlich bedeutet
Wir haben 24.560 Pull Requests über 447 GitHub-Repositories analysiert. KI-generierte PRs in diesem Datensatz haben eine 32-%-Fehlerrate. Menschliche PRs liegen bei 25,5 %. Diese 6,5 Prozentpunkte klingen nach wenig, bis du das Volumen einrechnest.
Ein menschlicher Entwickler pusht vielleicht zwei oder drei PRs am Tag. Ein Engineer mit KI-Agent pusht zehn bis zwanzig. Wenn 30 % davon scheitern, sind das drei bis sechs Failure-Notifications pro Entwickler pro Tag. Bei zwei Vibecodern in einem Sechser-Team sind das sechs bis zwölf rote Alerts täglich, auf die niemand reagieren kann, weil niemand den Code geschrieben hat, der gescheitert ist.
Der CI-Channel fängt an, sich mit Rauschen zu füllen. Und sobald das Rauschen eine bestimmte Schwelle überschreitet, stirbt der Channel. Nicht formell. Niemand meldet sich ab. Die Leute hören einfach auf zu lesen.
12 Minuten auf 3 Stunden
Ich habe die Reaktionszeit des Teams auf CI-Failures über sechs Wochen gemessen. In den ersten zwei Wochen, vor dem KI-Tooling-Ramp-up, lag ihre mediane Reaktion auf einen echten Failure bei etwa 12 Minuten. Jemand hat den roten Badge gesehen, sich durchgeklickt, die Logs gelesen, einen Fix gepusht oder den PR kommentiert. Schnell.
Zwei Wochen nachdem das Vibecoding losging, lag dieselbe Metrik bei über 3 Stunden.
An dem Team hatte sich nichts geändert außer dem Signal-zu-Rauschen-Verhältnis in ihrem Alert-Channel. Dieselben Leute, dieselbe Codebase, dieselbe Pipeline. Aber wo sie früher ein oder zwei Failures am Tag gesehen haben (fast immer echte Probleme, die es wert waren untersucht zu werden), sahen sie jetzt acht bis zwölf, und die meisten waren Bot-PRs, die bereits aufgegeben worden waren.
Das menschliche Gehirn ist dabei nicht subtil. Du trainierst dich selbst, die Sache zu ignorieren, die dich meistens anlügt. Nach ein paar Dutzend Fehlalarmen verflüchtigt sich der Instinkt, sich durchzuklicken. Ein echter CI-Failure, eine echte Regression in produktionsrelevantem Code, sitzt jetzt ungelesen in einem Channel, der sich wie Spam anfühlt.
Der Failure, der zählte
Woche drei. Ein Senior-Engineer hat eine Datenbank-Migration gepusht, die die Staging-Umgebung zerlegt hat. CI hat es erwischt. Roter Badge erschien in #ci-alerts direkt neben elf anderen roten Badges von Bot-PRs, die an Lint-Regeln gescheitert waren.
Niemand hat es fünf Stunden lang bemerkt.
Die Staging-Umgebung war die ganze Zeit down. Eine QA-Engineerin hat es zufällig gefunden, als sie ein Feature testen wollte und sich nicht verbinden konnte. Sie hat den Channel angepingt, und drei Leute haben innerhalb von Minuten geantwortet. Der Alert hatte die ganze Zeit dort gesessen, ungelesen, unter Rauschen begraben.
Dieser Fünf-Stunden-Gap wäre einen Monat vorher zwölf Minuten gewesen. Die Pipeline hat den Bug genau wie designed gefangen. Das Team hat nur nicht mehr zugehört.
Die Mathematik der aufgegebenen PRs
Hier ist die Zahl, die das Alert-Fatigue-Problem strukturell macht statt nur verhaltensbedingt. Wir haben 7.498 CI-Failure-Events in unserem Datensatz verfolgt und bei jedem geprüft, ob der gescheiterte PR jemals repariert wurde.
Bei menschlichen PRs: 23,4 % der Failures werden gefixt und bestehen irgendwann.
Bei KI-PRs: 9,3 %.
Einundneunzig Prozent der gescheiterten KI-Pull-Requests werden nach dem initialen Failure nie wieder angefasst. Der Agent hat submittet, CI hat ein Problem gefunden, und niemand ist zurückgekommen. Nicht der Agent. Nicht der Entwickler, der ihn angestoßen hat. Der PR sitzt in der Queue, rot, schickt bei jedem Dashboard-Refresh Notifications, bis jemand ihn manuell schließt oder ein Stale-Bot aufräumt.
Jeder dieser toten PRs sieht in deinem Alert-Channel exakt wie ein lebendiger Failure aus. Selber roter Badge. Selbes Notification-Format. Selbes visuelles Gewicht. Dein Team hat keine Möglichkeit, "Bot-PR, der an einem Semikolon gescheitert ist und nie repariert wird" von "jemand hat eine Migration gepusht, die Staging zerlegt hat" zu unterscheiden, ohne sich jedes einzelne Mal durchzuklicken und die Logs zu lesen.
Bei sechs bis zwölf Fehlalarmen am Tag hören die Leute auf zu klicken.
Den Channel fixen, nicht die Leute
Der erste Instinkt der Teamleitung war, allen zu sagen, sie sollen besser auf CI-Alerts achten. Das hat ungefähr zwei Tage gehalten, bevor das Rauschen sie wieder überwältigt hat. Man kann ein Signal-zu-Rauschen-Problem nicht lösen, indem man Leute bittet, mehr Rauschen zu tolerieren.
Was tatsächlich funktioniert hat, war das Rauschen zu reduzieren.
Sie hat Auto-Close für jeden PR mit dem Label ai-generated eingerichtet, der CI gefailt hat und seit 48 Stunden keine Commit-Aktivität zeigte. Das hat die am längsten herumhängenden Fehlpositiven aus der Queue entfernt. Tote PRs haben aufgehört, sich anzusammeln.
Dann hat sie die Notification-Regeln aufgesplittet. Bot-PRs wurden in einen separaten Channel geroutet, #ci-bot, den niemand monitoren musste. Menschliche PRs blieben in #ci-alerts. Der Haupt-Channel ging von zwölf Notifications am Tag zurück auf zwei oder drei. Alle echt.
Die mediane Reaktionszeit des Teams auf CI-Failures fiel in der ersten Woche von 3 Stunden zurück auf etwa 18 Minuten. Nicht ganz zurück auf die ursprünglichen 12, aber nah dran. Der Senior-Engineer, der die Datenbank-Migration gepusht hat, hätte innerhalb von 20 Minuten jemanden gehabt, der sich das anschaut, statt fünf Stunden.
Gesamte Einrichtungszeit für den Split und das Auto-Close: ungefähr drei Stunden. Die Alternative war ein Team, das funktional darauf trainiert worden war, sein eigenes Build-System zu ignorieren.
Basierend auf einer empirischen Studie von 24.560 PRs über 447 Open-Source-Repositories. Details wurden geändert. Ich helfe Startups und Teams beim Einrichten von CI/CD-Pipelines, DevOps-Infrastruktur und Entwicklungs-Workflows, die mit KI-Tools arbeiten statt gegen sie.
Ist deine CI/CD Pipeline bereit für AI-Agents?
Die meisten Pipelines sind nicht für AI-Coding-Tools ausgelegt. Ein kurzes Audit kann dir jede Woche Stunden an verschwendeter Rechenzeit sparen.