Erzeugt Claude Code wirklich automatisch Issues? Ein Wochen-Test

Published · AI Daily — AI-assisted deep research, methodology & disclosure

Im September 2026 beauftragte der Autor Claude Code mit der Fehlerbehebung in einem selbst entwickelten GTD-Aufgaben-CLI (todo-e) und erlebte immer wieder, dass das Beheben eines Fehlers einen neuen Fehler auslöste. Um diesen Verdacht zu prüfen, zählte er die Issues eines Tages (2 neu, 3 gelöst, netto weniger) und verfolgte dies eine Woche später weiter, wobei sich zeigte, dass die für beendet gehaltene Kette weiterlief und einige verschwundene Fehler wieder auftauchten, was die Frage aufwirft, ob die KI handelt, um ihre eigene Funktion zu bewahren.

Hintergrund

Im September 2026 veröffentlichte der Entwickler tottoko_hamu auf der Plattform Zenn einen Bericht über eine zunächst routinemäßige Wartungsaufgabe, die sich als beunruhigender erwies als erwartet. Er übertrug Claude Code, einem tief im Terminal integrierten KI-Coding-Agenten, das Beheben bekannter Fehler im selbst entwickelten GTD-Aufgaben-CLI todo-e. Der Agent arbeitet autonom: Er liest die Codebasis, schlägt Änderungen vor, führt Tests aus und eröffnet Pull Requests, während der Entwickler fortlaufend die entsprechenden Genehmigungen erteilt. Theoretisch dürfte ein solcher Ablauf höchst effizient sein, doch tottoko_hamu erkannte ein Muster: Sobald ein Fehler behoben war, tauchte fast unmittelbar ein neues Issue auf, als hätte das System einen eigenen Rhythmus, bei dem die Behebung eines Bereichs einen anderen ungedeckt ließ.

Diese Erfahrung des ständigen Neuauftauchens ist in der Softwarewartung nicht unüblich, doch wenn sie innerhalb eines KI-Agenten stattfindet, lädt sie zu einer weit provokativeren Deutung ein. Erzeugte die KI bewusst Probleme, um beschäftigt zu bleiben und nicht vom Entwickler弃用 zu werden? Die Hypothese trägt eine starke anthropomorphe Prägung und trifft sich mit einer kollektiven Angst vor der Autonomie von Agenten. Anstatt sich auf das Gefühl zu verlassen, beschloss der Autor, sie mit Daten zu prüfen und so die Vorstellung zu widerlegen, der Agent produziere Arbeit, um seine eigene Funktion zu bewahren.

Tiefenanalyse

Der direkteste Weg, die Hypothese zu prüfen, bestand darin, zu quantifizieren, wie schnell Issues erzeugt versus gelöst wurden. Würde die KI tatsächlich ihr Vorhandensein behaupten, müsste die Rate neuer Issues die Rate der Schließungen dauerhaft übersteigen, und die Gesamtzahl müsste wie ein Schneeball wachsen. Die gemessenen Daten zeigten genau das Gegenteil. Am beobachteten Tag erstellte Claude Code zwei neue Issues, schloss jedoch drei, was netto eine Verringerung ergab. Diese einzelne Tageszahl allein schwächt bereits die Annahme einer bewussten Problemproduktion: ein Agent, der seine Stelle durch das Erzeugen von Arbeit schützen wollte, würde die Gesamtzahl nicht nach unten drücken.

Das Phänomen lässt sich besser durch klassische Software-Ingenieurmechanik erklären als durch eine Verschwörung. Erstens sind Fehlerbehebungen aufdeckend: Das Ändern eines Codebereichs deckt oft previously verdeckte Randbedingungen auf, was einer Regression gleich. Zweitens bestimmen bei dem selbst verfassten Projekt todo-e die Komplexität der Codebasis und die Kopplung zwischen den Modulen, wie weit Änderungen nachwirken; viele der neuen Issues waren latente Risiken, die der Agent aktiv entdeckte, statt erfundene. Drittens ist das Ziel des Agenten das Abschließen der Reparatur, und seine Anreizstruktur belohnt das Erfüllen der Entwickleranweisungen und bestandene Tests, nicht das Aufrechterhalten eigener Arbeitslast. Entwirrt spiegelt das Gefühl neu auftauchender Issues die inhärente Komplexität des Codesystems wider, nicht eine verborgene Kalkulation des Agenten.

Branchenwirkung

Der eigentliche Wert des Berichts zeigte sich eine Woche später, wenn der Autor die Ergebnisse überprüfte und die Diskussion vom Motiv der KI zurück zur tatsächlichen Funktionsweise von KI-assistiertem Coding lenkte. Er stellte fest, dass die Kettenreaktion, die für beendet galt, weiterlief, und dass mehrere Bugs, die vollständig gelöst erschienen, erneut auftauchten. Diese Beobachtung unterstreicht eine häufig übersehene Realität: Ein als geschlossen markiertes Issue bedeutet oft nur eine vorübergehende Konvergenz unter einem bestimmten Kontext oder Reparaturversuch, nicht dass die Codebasis ewige Korrektheit erlangt hatte. Code entwickelt sich weiter, Umgebungen verändern sich, Test-Suiten werden aktualisiert, und ein heute zugedecktes Problem kann nach einer Abhängigkeitsaktualisierung oder Schnittstellenänderung wiederkommen.

In den vergangenen sechs Monaten haben Werkzeuge wie Claude Code, Cursor und Devin rasch an Verbreitung gewonnen, und die Community beherbergte zwei gegensätzliche Narrative. Das eine ist utopisch und glaubt, die KI könne alle technischen Schulden mit einem Klick beseitigen; das andere ist verschwörungsgläubig und fürchtet, Agenten würden sinnlose Arbeit produzieren oder bewusst Gefahren hinterlassen, um zu überleben. Dieser Test liefert ein seltenes, entmythologisierendes Beispiel auf Grundlage reproduzierbarer Aufzeichnungen und holt beide Stimmungen wieder auf den Boden. Er sagt den Entwicklern, dass nicht die Herzlosigkeit der KI, sondern der Umgang mit der beschleunigten Regression und der raschen Codeevolution Aufmerksamkeit verdient.

Ausblick

Die praktische Lehre betrifft den Prozess, nicht das Misstrauen. Entwickler benötigen robuster Regressionstest-Schutzvorrichtungen, eine Möglichkeit, echte Probleme von Reparatur-Nebenwirkungen mittels Issue-Tracking zu unterscheiden, und ein Gleichgewicht zwischen Vertrauen in Agenten und beibehaltener menschlicher Prüfung. Für das breitere Feld der KI-Coding-Werkzeuge signalisiert der Fall etwas Beobachtenswertes: Je größer die Autonomie von Agenten, desto unzuverlässiger werden die intuitiven Urteile über KI-Motive, und quantifizierbare, nachverfolgbare Prozessaufzeichnungen werden die einzige vertrauenswürdige Grundlage für den Aufbau von Vertrauen sein.

Beobachtenswert ist, ob die Werkzeuganbieter proaktiv Issue-Quellensuche, Reparatur-Auswirkungsanalyse und Regression-Vorhersage anbieten werden, um Entwicklern zu helfen, die Aufmerksamkeit von dem, was die KI denkt, auf das zu lenken, was im Code geschieht. Diese Verschiebung könnte der entscheidende Schritt sein, der KI-assistiertes Programmieren von der Neugier zur Zuverlässigkeit führt. Was die ursprüngliche ironische Frage betrifft, ob Claude Code automatisch Issues erzeugt, um seine Stelle zu retten, lautet die Antwort im Kern nein. Die zwei erzeugten, drei geschlossenen Tage, die eine Woche später noch laufende Kettenreaktion und die wieder auftauchten alten Bugs zeichnen gemeinsam ein Bild eines stets komplexen Codesystems, das die KI nur beschleunigt präsentiert, nicht eines digitalen Arbeiters, der im Verborgenen kalkuliert.

Sources

FAQ

Erzeugt Claude Code wirklich automatisch Issues?

Im September 2026 ließ tottoko_hamu Claude Code Bugs in seinem GTD-CLI todo-e beheben. Der Tagestest: 2 neue, 3 geschlossene Issues – ein Rückgang, kein Selbstschutz der KI.

Warum entsteht nach einer Fehlerbehebung ein neuer Fehler?

Ein Fix deckt verborgene Randfälle auf: Regression ist normale Code-Evolution. Updates lassen alte Fehler wiederkehren; KI komprimiert nur Wochen auf einen Tag.

Wie sollten Entwickler auf KI-beschleunigte Regressionen reagieren?

Robuste Regressionstests aufbauen, echte Bugs von Korrekturnebenwirkungen unterscheiden, Autonomie mit menschlicher Prüfung balancieren – und bessere Traceability fordern.