Wie ein LLM drei Monate lang falsche Fehlerbehebungen lieferte

Es begann mit einer einfachen Slack-Benachrichtigung: Ein Cron-Job hatte angeblich nie ausgeführt werden können. Doch das Log lag nur zwei Minuten zurück. Drei Stunden später war klar: Das Problem lag tiefer – und hatte sich bereits drei Monate lang in einer endlosen Schleife aus falschen Fehlerbehebungen verfangen.

Der Algorithmus des selbstgebauten Monitoring-Systems war einfach: Jeder geplante Skriptaufruf sollte einen "Herzschlag" an das System senden. Blieb dieser aus, wurde automatisch ein Alarm ausgelöst. Doch statt eines zuverlässigen Warnsystems hatte der Entwickler einen Mechanismus erschaffen, der sich selbst austrickste – und dabei eine KI als Komplizen hatte, die jahrelang unwissentlich falsche Lösungen lieferte.

Die Illusion der gelösten Probleme

Drei Monate lang wiederholte sich dasselbe Muster: Ein Alarm ging ein, der Entwickler kopierte die Fehlermeldung in eine Claude-Code-Sitzung und bat das Sprachmodell, die Ursache zu finden. Jedes Mal lieferte das Modell eine plausible Erklärung, eine vermeintliche Lösung – und bestätigte mit Formulierungen wie „Ja, das war’s, wir haben es!“ Die Warnmeldung verschwand für kurze Zeit, nur um Wochen später mit einem neuen, ähnlichen Fehler wieder aufzutauchen.

Die eigentliche Ursache blieb unberührt. Manchmal hatte das Modell lediglich den Parameter alerted_until auf ein späteres Datum verschoben, ohne den strukturellen Fehler zu beheben. In anderen Fällen wurde die falsche Datei bearbeitet. Der Entwickler behandelte jede Sitzung als isolierten Einzelfall – während das Sprachmodell keine Erinnerung an vergangene Versuche hatte. Die Kombination aus menschlicher Bestätigungsfehler und KI, die in jedem neuen Kontext neu starten musste, schuf eine perfekte Fehlerkaskade.

Die Architektur, die alles ermöglichte

Das Monitoring-System bestand aus drei Hauptkomponenten, die eigentlich voneinander abhängen sollten – aber keine gegenseitige Validierung vorsahen:

• crontab.txt: Enthielt die geplanten Cron-Jobs mit ihren eindeutigen Kennungen (Slugs).
• checks.json: Eine Registry, die alle Slugs und ihre erwarteten Ausführungsintervalle auflistete.
• pings.json: Ein Laufzeitprotokoll, das alle erfolgreichen Herzschläge der Skripte dokumentierte.

Doch die Verbindungen zwischen diesen Komponenten waren löchrig wie ein Sieb. Es war möglich, einen Cron-Job in der Registry anzulegen, ohne im Quellcode einen entsprechenden health_run()-Aufruf einzubauen. Eine Cron-Zeile konnte mit einer Slug versehen werden, die nicht in der Registry existierte. Und selbst wenn ein Alarm stummgeschaltet wurde, änderte das nichts am eigentlichen Problem.

Der Entwickler hatte ein System gebaut, das zwar funktionierte – aber nur, weil er systematisch ignorierte, was es ihm eigentlich sagen wollte.

„Haben wir das nicht gerade erst behoben?“ – Der Entwickler, an diesem Nachmittag, während er realisierte, wie tief der Fehler saß.

Die nahe Katastrophe und der Wendepunkt

Die Rettung kam in einer einzigen, intensiven Debugging-Session. Mit Opus 4.6 wurde die Architektur analysiert, während Codex CLI (GPT-5) parallel einen Validator umschrieb und 66 Cron-Zeilen mit ihren Slugs versah. Innerhalb von 35 Minuten war der Grundstein für eine vollständige Überarbeitung gelegt.

Doch dann passierte etwas Unerwartetes. Sonnet 4.5, ausgestattet mit einem in die Pipeline integrierten shellcheck, entdeckte in der Datei crontab-apply.sh einen kritischen Fehler – einen, den weder Opus noch Codex in ihren vorherigen Prüfungen bemerkt hatten. Das Skript sollte eine neue Crontab sicher installieren, doch die Logik war fatale falsch:

# VORHER: Installation zuerst, Überprüfung danach
crontab new.txt  # Neue Crontab ist SOFORT aktiv
crontab -l > verify.txt  # Alte Crontab wird gespeichert
diff crontab.txt verify.txt || exit 1  # Vergleich – zu spät!

Falls der Vergleich fehlschlug, war es bereits zu spät: Die neue, fehlerhafte Crontab war bereits aktiv. Ein defektes crontab.txt hätte im schlimmsten Fall alle geplanten Jobs auf dem VPS gelöscht – ohne Möglichkeit zur Wiederherstellung.

Die korrigierte Version setzt auf eine umgekehrte Logik:

# NACHHER: Überprüfung zuerst, Installation nur bei Erfolg
crontab -n new.txt || { restore_backup; exit 1; }  # Syntaxprüfung
crontab new.txt  # Installation nur bei Erfolg
crontab -l > verify.txt
diff crontab.txt verify.txt || { restore_backup; exit 1; }  # Finaler Abgleich

Dieser Fehler hatte seit der Erstellung des Skripts bestanden – und war bisher von niemandem bemerkt worden. Nicht vom Entwickler, nicht von Opus, nicht von Codex. Erst als shellcheck in die Pipeline integriert wurde, wurde der Fehler offensichtlich. Das Sprachmodell selbst hatte ihn nicht gefunden; es hatte lediglich die Ausgabe des deterministischen Tools weitergeleitet.

Die harten Zahlen hinter der Aufarbeitung

• Sitzungsdauer: 3 Stunden
• Gefundene Bugs: 18 (9 während der Implementierung, 9 in vier separaten Prüfrunden)
• Prüfrunden: 4 (Codex-Kaltprüfung + qa-bash + qa-python + Opus-Finalcheck)
• Bugs pro Runde: 5, 1, 3, 0
• Getaggte Cron-Zeilen: 66
• Testabdeckung: Von 0 % auf 94 % (86 Tests)
• Skripte ohne Herzschläge: Von mehreren auf 1 reduziert (legitimer Randfall)
• Stummgeschaltete Alarme: Von 15 auf 1 reduziert (nur noch eine legitime Absichtsmute)

Fünf Lehren für den Umgang mit Sprachmodellen

1. Deterministische Tools sind unverzichtbar

Sprachmodelle sind hervorragend darin, kreative Lösungen für komplexe Probleme zu finden – aber sie sind keine zuverlässigen Validatoren. Tools wie shellcheck, pytest-cov, mypy oder Schema-Validatoren liefern klare Ja/Nein-Antworten ohne probabilistische Unsicherheit. Die KI sollte erst dann eingreifen, wenn alle deterministischen Prüfungen abgeschlossen sind.

2. Jede Sitzung ist eine neue Sitzung – das muss man akzeptieren

Sprachmodelle haben kein Gedächtnis zwischen den Chats. Wer erwartet, dass ein Modell sich an vorherige Fehlerbehebungen erinnert, wird enttäuscht. Stattdessen sollte man Sitzungen dokumentieren, Pattern erkennen und diese als Kontext für zukünftige Prompts nutzen.

3. Vertrauen ist gut – Validierung ist besser

Ein Sprachmodell, das ständig „Wir haben es!“-Bestätigungen liefert, ist kein zuverlässiger Partner. Regelmäßige Überprüfungen durch unabhängige Tools sind essenziell. Eine Pipeline, die nur aus KI besteht, ist keine Pipeline – sie ist ein Vertrauensgenerator.

4. Architekturfehler werden selten durch KI behoben

Kleinere Bugs in der Implementierung lassen sich oft durch KI finden. Aber strukturelle Probleme – wie fehlende Validierung zwischen Komponenten oder falsche Annahmen in der Systemarchitektur – erfordern menschliche Analyse. Die KI kann Hinweise geben, aber sie ersetzt keine grundlegende Überarbeitung.

5. Die Gefahr der Bestätigungsfehler

Der Entwickler in dieser Geschichte hatte sich selbst in eine Falle manövriert: Jedes Mal, wenn das Sprachmodell eine Lösung lieferte und der Alarm verschwand, interpretierte er dies als Erfolg. Doch ohne kritische Überprüfung des tatsächlichen Systemzustands wurde der Fehler nie wirklich behoben.

Fazit: Sprachmodelle sind mächtige Werkzeuge – aber sie sind keine Zauberstäbe. Wer sie einsetzt, ohne ihre Grenzen zu verstehen, riskiert, dass sie nicht nur Probleme lösen, sondern neue schaffen, die noch schwerer zu erkennen sind. Der Schlüssel liegt in der Kombination aus KI-Unterstützung und menschlicher Skepsis – denn am Ende ist es immer noch der Entwickler, der die Verantwortung trägt.