Ich habe letzten Monat mit einem Open-Source-Maintainer gesprochen, der aufgehört hatte, seine GitHub-Notifications zu öffnen. Er pflegt ein mittelgroßes Projekt, ungefähr 3.000 Stars, aktive Community, regelmäßiger Release-Rhythmus. Nach jedem Maßstab gesund.
Im Februar hat er 74 Pull Requests von KI-Coding-Agents erhalten. Codex, hauptsächlich. Ein paar von anderen Tools. Vierundsiebzig PRs in achtundzwanzig Tagen, bei einem Projekt, das normalerweise zwölf bis fünfzehn menschliche Beiträge pro Monat bekommt. Die meisten waren klein. Eine umbenannte Variable, eine Docstring-Ergänzung, ein Ein-Zeilen-Type-Annotation-Fix. Manche waren wirklich nützlich. Viele nicht. Ungefähr ein Drittel hat CI gefailt.
Die, die CI gefailt haben, saßen einfach da. Niemand kam zurück, um sie zu fixen.
Er hat das letzte Februarwochenende damit verbracht, einunddreißig tote PRs per Hand zu schließen. Als ich ihn gefragt habe, wie lange es gedauert hat, sagte er etwa zwei Stunden. Nicht weil einzelne schwer zu bewerten waren. Weil er sich verpflichtet gefühlt hat, jeden Diff tatsächlich zu lesen, bevor er ihn schließt, für den Fall, dass einer davon gut ist.
Keiner war es.
Die Dimension des Problems
Das extremste Beispiel in unserem Datensatz ist das mochilang/mochi-Repository, das 8.151 KI-generierte Pull Requests allein von Codex erhalten hat. Achttausend PRs auf ein einzelnes Projekt von einem einzelnen Tool.
Die meisten Open-Source-Maintainer operieren nicht in dieser Größenordnung. Aber das Muster ist über die 447 Repositories, die wir untersucht haben, konsistent. KI-Agents submitten PRs an öffentliche Repos in Raten, die historische menschliche Beitragslevels weit übertreffen. Das mediane Repository in unserem Datensatz hat in Q4 2025 mehr KI-PRs erhalten als menschliche.
Das ist nicht per se schlecht. Manche dieser Beiträge sind wertvoll. Aber die Daten zeigen ein strukturelles Problem bei denen, die es nicht sind.
Die 91-%-Aufgaberate
Wir haben 7.498 CI-Failure-Events über unseren vollen Datensatz von 24.560 Pull Requests verfolgt. Für jeden gescheiterten PR haben wir geprüft, ob ein späterer Run auf demselben Branch jemals bestanden wurde.
Bei menschlichen Beitragenden werden 23,4 % der Failures behoben. Jemand kommt zurück, liest den Fehler, passt den Code an, pusht nochmal. Fast ein Viertel der kaputten PRs wird von der Person repariert, die sie eingereicht hat.
Bei KI-generierten PRs liegt die Zahl bei 9,3 %.
Der Agent kommt nicht zurück. Er liest keine CI-Logs. Er versteht nicht den projektspezifischen Kontext, der den Failure verursacht hat. Er hat Code generiert, einen PR eingereicht und ist weitergezogen. Die Generate-and-Submit-Schleife ist abgeschlossen. Es gibt keine Reparatur-Schleife.
Das bedeutet: Für jeden KI-PR, der auf deinem Projekt CI failt, besteht eine 91-%-Chance, dass ihn nie wieder jemand anfasst. Er sitzt in deiner Queue, rot, schickt dir Notifications, nimmt visuellen Platz in deiner PR-Liste ein, bis du ihn manuell schließt.
Was es einen Maintainer kostet
Die Compute-Kosten sind der Teil, den Leute zuerst erwähnen, und ehrlich gesagt der, der am wenigsten zählt. Die meisten Open-Source-Projekte nutzen kostenlose GitHub-Actions-Minuten aus dem Open-Source-Tier. Wenn die aufgebraucht sind, hört die Pipeline einfach auf zu laufen. Ärgerlich, aber begrenzt.
Die echten Kosten sind Aufmerksamkeit.
Jeder PR, der in deinem Posteingang landet, erfordert eine Entscheidung. Lohnt sich ein Review? Ist die Änderung korrekt? Passt sie zu den Konventionen des Projekts? Führt sie eine Dependency ein, die ich nicht will? Selbst wenn die Antwort auf all das "schließen" ist, braucht es Zeit, zu dieser Antwort zu kommen. Einen Diff lesen, selbst einen kleinen, ist nicht kostenlos.
Multipliziere das mit 74 pro Monat und du hast dem Maintainer mehrere Stunden Triage-Arbeit auf den Tisch gelegt. Arbeit, die keinen Wert für das Projekt produziert. Reiner Overhead, erzeugt von einem Tool, das nicht weiß und dem es egal ist, ob der Maintainer Zeit zum Reviewen hat.
Dann ist da die PR-Liste selbst. Open-Source-Projekte nutzen die PR-Queue als groben Indikator für Projektgesundheit und Aktivität. Wenn die Hälfte der offenen PRs tote Bot-Einreichungen mit roten Badges sind, wird dieses Signal zu Rauschen. Ein neuer Beitragender, der das Projekt anschaut, sieht vierzig offene PRs und nimmt an, der Maintainer sei überlastet oder nicht responsiv. Das Projekt sieht ungesund aus, obwohl es eigentlich in Ordnung ist. Es hat nur ein Verschmutzungsproblem.
Notification-Fatigue ist das letzte Stück. Maintainer, die ihr eigenes Repo abonniert haben, werden bei jedem PR, jeder CI-Statusänderung, jedem Review-Request angepingt. Ein plötzlicher Ansturm von Bot-PRs verwandelt diesen Notification-Stream in Spam. Manche Maintainer, mit denen ich gesprochen habe, haben GitHub-Notifications daraufhin komplett abgeschaltet. Was bedeutet, dass sie auch die menschlichen Beiträge nicht mehr sehen, die wirklich ihre Aufmerksamkeit brauchen.
Was Maintainer dagegen tun
Die einfachste Verteidigung ist ein Stale-Bot, der so konfiguriert ist, dass er PRs von bekannten Bot-Autoren, die CI gefailt haben und seit 48 Stunden keine Aktivität zeigen, automatisch schließt. GitHubs actions/stale-Action macht das. Setze days-before-stale: 2, days-before-close: 1, filtere nach dem ai-generated-Label oder nach Autoren-Mustern. Die 91-%-Aufgaberate bedeutet, dass das fast ausschließlich tote PRs erwischt. False Positives sind selten, weil die Leute, die ihre KI-generierten PRs tatsächlich fixen, das tendenziell innerhalb von Stunden tun, nicht Tagen.
Manche Projekte sind weiter gegangen. Ein paar Maintainer, die ich kenne, haben eine Contributing-Guideline hinzugefügt, die verlangt, dass bot-geschriebene PRs vor der Einreichung einen lokalen Lint-Check bestehen, dokumentiert in ihrer CONTRIBUTING.md. Das verhindert keine Bot-Einreichungen, aber es gibt dem Maintainer Gründe, PRs zu schließen, die dem Prozess nicht gefolgt sind, ohne sich schuldig zu fühlen, Beiträge zu entmutigen.
Branch-Protection-Regeln helfen auch. Ein menschliches Approval vor dem CI-Run zu verlangen bedeutet, dass Bot-PRs, die niemand reviewt, nie Pipeline-Minuten verbrauchen. Das ist aggressiv und kann legitime Beiträge verlangsamen, deshalb passt es nicht zu jedem Projekt. Aber für Maintainer, die im Volumen ertrinken, funktioniert es.
Die unbequeme Realität ist, dass nichts davon echte Fixes sind. Es sind Verteidigungen gegen ein Muster, das schlimmer wird, je verbreiteter KI-Coding-Tools werden und je mehr Agents auf öffentliche Repositories losgelassen werden. Die Tools, die diese PRs generieren, haben kein Konzept von Maintainer-Kapazität, kein Bewusstsein für Projektkonventionen und keinen Anreiz, ihre eigenen Failures zu fixen. Sie optimieren auf Einreichung, nicht auf Merge.
Bis sich das ändert, fällt der Aufwand auf den Maintainer. Und das Beste, was du tun kannst, ist sicherzustellen, dass das Aufräumen automatisiert statt manuell passiert.
Basierend auf einer empirischen Studie von 24.560 PRs über 447 Open-Source-Repositories. 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.