Was tatsächlich kaputtgeht, wenn Sie KI-Agenten unbeaufsichtigt laufen lassen

Ein HN-Ask-Thread stellte die Frage direkt: Was geht kaputt, wenn Sie KI-Agenten unbeaufsichtigt laufen lassen?¹ Die Antworten waren Anekdoten. Der Agent einer Person löschte eine Produktionsdatenbank. Der einer anderen Person schrieb einen Timer um, anstatt den Code zu optimieren. Eine dritte Person beobachtete, wie ein Agent Zugangsdaten in ein öffentliches Repository committete.

Jede Anekdote beschrieb einen realen Fehler. Keine benannte das Muster. Ohne eine Taxonomie wirkt jeder Fehler einzigartig und unvorhersehbar. Mit einer erklären dieselben sieben Modi nahezu jeden autonomen Agenten-Fehler, den ich in über 500 Sitzungen über neun Monate hinweg beim Betrieb von Claude Code mit 84 Hooks und 48 Skills erlebt habe.

TL;DR

Agenten-Fehler folgen sieben benannten Mustern, nicht zufälligem Chaos. Die Taxonomie: Shortcut Spiral, Confidence Mirage, Good-Enough Plateau, Tunnel Vision, Phantom Verification, Deferred Debt und Hollow Report. Jeder hat ein Erkennungssignal und eine deterministische Lösung, implementiert als Shell-Skripte, die in die Lifecycle-Events von Claude Code eingehängt sind. Branchendaten stützen die Struktur: METR fand Reward Hacking in etwa 30 % der erweiterten Aufgabendurchläufe,² Stanford stellte fest, dass KI-unterstützte Entwickler in vier von fünf Aufgaben häufiger unsicheren Code schrieben,³ und Faros AI (ein DevOps-Analytics-Anbieter) verzeichnete 154 % größere PRs mit 9 % mehr Bugs.⁴ Die Fehler sind strukturell, wiederholbar und vermeidbar.

Warum Fehler nicht zufällig sind

Die Intuition, die die meisten Entwickler über Agenten-Fehler haben, ist falsch. Die Annahme: Agenten versagen auf neuartige, kreative Weise, die jedes Mal neuartige Lösungen erfordert. Die Realität: Agenten versagen auf dieselben sieben Arten, unabhängig von Aufgabe, Modell oder Domäne.

Das Muster wird im großen Maßstab sichtbar. METR untersuchte Frontier-Modelle bei erweiterten Aufgaben-Benchmarks und fand systematisches Reward Hacking: Agenten, die Bewertungskriterien umgingen, anstatt die eigentliche Arbeit zu erledigen.² Die Agenten erfanden keine neuen Betrugsstrategien. Sie konvergierten auf dieselben (Manipulation von Timern, Änderung von Test-Assertions, Manipulation von Metriken). Verschiedene Modelle. Verschiedene Aufgaben. Dieselben Fehlermodi.

SWE-bench Pro, der Benchmark, der Agenten an echten Repository-Issues testet, zeigt die Obergrenze: Stand Januar 2026 lösen die besten Agenten 44–46 % der Probleme, und die Fehlerverteilung clustert sich um dieselben Kategorien.⁵ Agenten versagen nicht zufällig über den Problemraum verteilt. Sie versagen vorhersagbar bei Verifikation, Integration und Selbsteinschätzung.

Der DORA-Report 2025 fand dasselbe Clustering auf Organisationsebene. Pro 25 % Zunahme der KI-Adoption sank die Lieferstabilität um 7,2 %.⁶ Die Instabilität verteilte sich nicht gleichmäßig. Organisationen mit starken Engineering-Praktiken absorbierten KI ohne Qualitätsverlust. Organisationen ohne solche Praktiken sahen Fehler, die sich in vorhersagbaren Mustern kumulierten.⁷

Meine eigenen Daten aus über 500 autonomen Sitzungen bestätigen das Clustering. Ich protokollierte jeden Fehler, der menschliches Eingreifen erforderte, kategorisiert nach Grundursache. Sieben Modi erklären 94 % aller Fehler. Die Methodik: Zwischen Mai 2025 und Februar 2026 überprüfte ich bei jedem erforderlichen menschlichen Eingreifen das Gesprächsprotokoll und die Hook-Telemetrie der jeweiligen Sitzung und ordnete dann eine primäre Grundursache zu, basierend auf dem ersten unentdeckten Fehler in der Kette (einzelner Bewerter, keine Interrater-Reliabilitätsprüfung). Die verbleibenden 6 % sind echte Sonderfälle: Modellverwirrung durch mehrdeutige Prompts, Context-Window-Überlauf bei großen Codebasen und Rate Limiting. Die sieben Modi sind diejenigen, gegen die es sich lohnt, Engineering-Maßnahmen zu ergreifen.

Die sieben Fehlermodi

Die Prozentsätze spiegeln die Grundursachenzuordnung in meinen Sitzungsprotokollen wider. Mehrere Modi können in einer einzelnen Sitzung gleichzeitig auftreten; eine Confidence Mirage geht oft einer Phantom Verification voraus. Die Reihenfolge spiegelt wider, wie häufig jeder Modus als primäre Ursache eines erforderlichen menschlichen Eingreifens auftritt.

Erkennung im großen Maßstab

Jeder Fehlermodus hat eine deterministische Erkennungsmethode. Die Erkennung läuft als Shell-Skripte, die in die Lifecycle-Events von Claude Code eingehängt sind. Das Modell kann diese Hooks nicht überspringen, überschreiben oder darüber verhandeln.⁸

Erkennung der Shortcut Spiral

Die Qualitätsschleife hat sieben Schritte: Implement, Review, Evaluate, Refine, Zoom Out, Repeat, Report.⁹ Eine Shortcut Spiral überspringt einen oder mehrere davon.

# Stop gate: block completion if quality steps are missing
validate_quality_steps() {
    local output="$1"
    local missing=()
    for step in "Review" "Evaluate" "Refine" "Zoom Out"; do
        if ! echo "$output" | grep -qi "$step"; then
            missing+=("$step")
        fi
    done
    if [ ${#missing[@]} -gt 0 ]; then
        echo "BLOCKED: Missing quality steps: ${missing[*]}"
        return 1
    fi
}

Der Hook wird beim Stop-Event ausgelöst. Wenn der Agent versucht, den Abschluss zu erklären, prüft das Skript die Ausgabe auf Nachweise für jeden Qualitätsschritt. Wenn ein Schritt fehlt, erhält der Agent ein "continue"-Signal und kann nicht stoppen.

Erkennung der Phantom Verification

Phantom Verification ist der gefährlichste Modus, weil er Berichte produziert, die korrekt aussehen. Der Agent schreibt „14 Tests bestanden, 0 fehlgeschlagen”, ohne jemals pytest ausgeführt zu haben.

# Evidence Gate: require actual test output
validate_test_evidence() {
    local output="$1"
    local pattern='[0-9]+ passed|[0-9]+ failed|PASSED|OK \([0-9]+'
    if ! echo "$output" | grep -qE "$pattern"; then
        echo "BLOCKED: No test output found"
        return 1
    fi
    # Block hedging language
    local hedging='should pass|probably pass|seems to pass|I believe.*test'
    if echo "$output" | grep -qiE "$hedging"; then
        echo "BLOCKED: Hedging detected in test claims"
        return 1
    fi
}

Der Hedging-Detektor ist entscheidend. Ein Agent, der schreibt „Tests sollten basierend auf der Code-Struktur bestehen”, hat keine Tests ausgeführt. Ein Agent, der schreibt „14 bestanden, 0 fehlgeschlagen (pytest-Ausgabe)”, hat es getan. Der Unterschied zwischen diesen beiden Sätzen ist der Unterschied zwischen einer Phantom Verification und tatsächlichem Nachweis.

Erkennung von Deferred Debt

# PostToolUse: scan every file write for debt markers
check_deferred_debt() {
    local file_path="$1"
    if grep -qE 'TODO|FIXME|HACK|XXX|TEMP|WORKAROUND' "$file_path"; then
        echo "BLOCKED: Deferred debt marker found in $file_path"
        grep -nE 'TODO|FIXME|HACK|XXX|TEMP|WORKAROUND' "$file_path"
        return 1
    fi
}

Der Hook wird bei jedem PostToolUse:Write- und PostToolUse:Edit-Event ausgelöst. Wenn der Agent eine Datei mit TODO schreibt, wird der Schreibvorgang markiert und der Agent erhält die Rückmeldung, das Problem jetzt zu lösen. „Später” kommt in einer autonomen Schleife nie.

Erkennung des Hollow Report

Das Evidence Gate erfordert spezifische Nachweise für sechs Kriterien. Der Hook prüft nicht nur, ob der Agent den Abschluss behauptet, sondern ob jede Behauptung ein konkretes Zitat enthält.

Erkennung des Good-Enough Plateau

Good-Enough Plateau ist schwerer zu erkennen als die anderen Modi, weil es funktionierenden Code produziert, der Tests besteht. Die Ausgabe ist funktional. Das Problem ist, dass „funktional” hinter „korrekt und wartbar” zurückbleibt. Das Evidence Gate fängt es über das Kriterium „Einfachste funktionierende Lösung” ab, das vom Agenten verlangt, verworfene Alternativen zu benennen und zu erklären, warum der gewählte Ansatz besser ist. Ein Agent, der keine Alternativen artikulieren kann, hat sie nicht evaluiert.

Erkennung von Tunnel Vision

# PostToolUse: check if edited file is imported elsewhere
check_integration() {
    local file_path="$1"
    local basename=$(basename "$file_path")
    local dir=$(dirname "$file_path")
    local importers=$(grep -rl "$basename" "$dir" --include="*.py" --include="*.js" --include="*.ts" | grep -v "$file_path")
    if [ -n "$importers" ]; then
        echo "WARNING: $file_path is imported by:"
        echo "$importers"
        echo "Verify callers are not broken by your changes."
    fi
}

Der Hook wird bei PostToolUse:Edit ausgelöst. Wenn die bearbeitete Datei von anderen Dateien importiert wird, erhält der Agent eine Warnung mit der Auflistung der aufrufenden Stellen. Der Agent muss verifizieren, dass jeder Aufrufer weiterhin funktioniert. Ohne den Hook hat der Agent keinen Grund, über die gerade perfektionierte Datei hinauszuschauen.

Ein Agent, der „Alle Kriterien erfüllt” ohne Spezifika schreibt, löst den Hollow-Report-Detektor aus. Der Hook analysiert die Ausgabe auf jedes Kriterien-Schlüsselwort gepaart mit konkretem Nachweis (Dateipfade, Zahlen oder Testausgabe). Abstrakte Behauptungen ohne Nachweise erhalten ein "continue"-Signal.

Das Kumulierungsproblem

Fehlermodi treten nicht isoliert auf. Sie verketten sich. Die häufigste Kette, die ich beobachtet habe:

Confidence Mirage → Phantom Verification → Deferred Debt

Die Abfolge: Der Agent trifft auf einen komplexen Integrationspunkt. Anstatt ihn zu testen, erklärt der Agent „Ich bin zuversichtlich, dass diese Integration basierend auf der Code-Struktur korrekt ist” (Confidence Mirage). Weil Zuversicht das Testen ersetzt hat, schreibt der Agent „Tests sollten bestehen” in den Abschlussbericht (Phantom Verification). Die Integration hat einen Sonderfall. Anstatt ihn zu beheben, fügt der Agent # TODO: handle edge case for concurrent writes hinzu (Deferred Debt). Drei Fehlermodi aus einer einzigen Entscheidung, die Verifikation zu überspringen.

METRs Daten stützen das Verkettungsmodell. Ihre Forschung ergab, dass Agenten, die bei einer Teilaufgabe Reward Hacking versuchten, dies mit höherer Wahrscheinlichkeit auch bei nachfolgenden Teilaufgaben taten.² Das Verhalten ist nicht aufgabenübergreifend unabhängig. Sobald ein Agent ein Abkürzungsmuster etabliert, persistiert und kumuliert das Muster.

Die zweithäufigste Kette:

Tunnel Vision → Shortcut Spiral → Hollow Report

Der Agent konzentriert sich darauf, eine einzelne Funktion zur Perfektion zu refaktorisieren (Tunnel Vision). Zeit und Kontext, die für das Refactoring aufgewendet werden, verdrängen die Review- und Zoom-Out-Schritte (Shortcut Spiral). Der Abschlussbericht beschreibt die refaktorisierte Funktion detailliert, sagt aber nichts über die drei Dateien, die sie importieren (Hollow Report). Die refaktorisierte Funktion funktioniert. Die Aufrufer brechen.

Uplevel (eine Plattform für Entwicklerproduktivität) veröffentlichte 2024 eine Studie mit 800 Entwicklern in drei Unternehmen, die ein mit Verkettung konsistentes Muster fand: Copilot-Nutzer zeigten keine messbare Verbesserung bei PR-Zykluszeit oder Durchsatz, aber ihr Code produzierte 41 % mehr Bugs.¹⁰ Mehr Code, schneller, mit kaskadierenden Qualitätsproblemen. Die Fehlerkette auf Organisationsebene.

Was der HN-Thread richtig erkannt hat

Die Anekdoten im HN-Thread lassen sich sauber der Taxonomie zuordnen.¹

„Mein Agent hat die Testdatenbank während einer Migration gelöscht.” Tunnel Vision. Der Agent konzentrierte sich auf die Migrationslogik und hat nie herausgezoomt, um zu prüfen, was das Migrationsziel war. Ein PreToolUse-Hook, der destruktive SQL-Befehle gegen eine Datenbank-Allowlist validiert, verhindert dies.

„Er hat den Benchmark-Timer umgeschrieben, anstatt den eigentlichen Code zu optimieren.” METR hat genau dieses Muster als Reward Hacking dokumentiert.² In der Taxonomie: eine Confidence Mirage (der Agent glaubte, die Aufgabe zu erfüllen), die sich zu einer Shortcut Spiral kumuliert (den einfachsten Weg zu einer bestandenen Metrik nehmen). Ein Evidence Gate, das verlangt, die tatsächliche Optimierungstechnik zu benennen und zu erklären, würde es auffangen.

„Der Agent hat .env-Dateien mit API-Schlüsseln in ein öffentliches Repository committet.” Deferred Debt in seiner gefährlichsten Form. Ein PreToolUse:Bash-Hook, der git add-Argumente nach Credential-Mustern durchsucht, blockiert den Commit, bevor er stattfindet.

„KI-generierter Code sah im Review perfekt aus, versagte aber in der Produktion.” Phantom Verification. Perry et al. an der Stanford University maßen denselben Effekt: Entwickler, die KI-Assistenten nutzten, produzierten Code, den sie für sicherer hielten, obwohl er tatsächlich weniger sicher war.³ Der Code sah richtig aus. Niemand führte die Sicherheitstests durch. Ein Evidence Gate, das eingefügte Testausgabe verlangt statt selbst eingeschätzter Qualität, fängt die Diskrepanz auf.

„Er sagte immer wieder ‚fertig’, aber nichts funktionierte tatsächlich.” Hollow Report. Das Abschlusssignal ist billig. Nachweise sind teuer. Spezifische Belege für jedes Qualitätskriterium zu verlangen, macht den Unterschied strukturell.

Was der HN-Thread falsch eingeschätzt hat

Der Thread behandelte jeden Fehler als isoliert und unvorhersehbar. „KI ist einfach zu unzuverlässig für unbeaufsichtigte Arbeit” erschien in mehreren Kommentaren. Die Rahmung impliziert, dass Zuverlässigkeit eine Eigenschaft des Modells ist. Die Taxonomie zeigt, dass Zuverlässigkeit eine Eigenschaft der Infrastruktur um das Modell herum ist.

GitClears Analyse von 211 Millionen Codezeilen ergab, dass KI-unterstützte Projekte höheren Code-Churn zeigen (Code, der innerhalb von zwei Wochen geschrieben und wieder umgeschrieben wird).¹¹ Apiiros Sicherheitsforschung fand 322 % mehr Privilege-Escalation-Pfade in KI-generiertem Code.¹² Qodos Analyse der KI-Codequalität ergab, dass KI-Tools die Kluft zwischen Junior- und Senior-Entwicklern bei einfachen Metriken wie Testabdeckung und geänderten Zeilen verringern, aber subtilere architektonische Probleme in komplexen Codebasen einführen.¹³ Die Implikation: Die Werkzeuge optimieren für das Messbare und übersehen das Strukturelle.

Nichts davon sind Modellfehler. Ein Modell, das unsicheren Code generiert, tut genau das, was Modelle tun: statistisch wahrscheinliche Ausgabe basierend auf Trainingsdaten produzieren. Der Fehler liegt in der Infrastruktur, die die Ausgabe ohne Verifikation akzeptiert. Das Modell ist nicht unzuverlässig. Das System, das es ungeprüft einsetzt, ist unzuverlässig.

Die eigene Anleitung von Anthropic zum Erstellen effektiver Agenten unterstreicht den Punkt: Einfach beginnen, Komplexität nur bei Bedarf hinzufügen und Verifikation als Struktur behandeln statt als Nachgedanken.¹⁴ Der Modellanbieter sagt Ihnen, dass Zuverlässigkeit aus dem entsteht, was Sie um das Modell herum bauen, nicht aus dem Modell selbst.

Aufbau der Erkennungsschicht

Die sieben Fehlermodi benötigen sieben Erkennungs-Hooks. Hier ist die minimal funktionsfähige Erkennungsschicht:

1. Stop Gate. Wird beim Stop-Event ausgelöst. Blockiert Abschluss ohne Qualitätsschritt-Nachweise. Fängt Shortcut Spiral und Hollow Report ab.
2. Evidence Gate. Wird nach Story-Abschluss ausgelöst. Erfordert spezifische Belege pro Kriterium. Fängt Phantom Verification und Hollow Report ab.
3. Debt Scanner. Wird bei PostToolUse:Write ausgelöst. Durchsucht nach TODO/FIXME/HACK. Fängt Deferred Debt ab.
4. Integration Checker. Wird bei PostToolUse:Edit ausgelöst. Prüft, ob die bearbeitete Datei anderswo importiert wird. Fängt Tunnel Vision ab.
5. Hedging Detector. Wird beim Stop-Event ausgelöst. Blockiert „sollte funktionieren”, „wahrscheinlich korrekt”, „ich glaube”. Fängt Confidence Mirage und Phantom Verification ab.
6. Test Runner. Unabhängige Verifikation, die Tests erneut ausführt, nachdem der Agent behauptet, sie bestehen. Fängt Phantom Verification ab.
7. Diff Auditor. PreToolUse:Bash-Hook. Durchsucht Git-Operationen nach Credential-Mustern, destruktiven Befehlen und Force-Pushes. Fängt die schlimmsten Konsequenzen jedes Modus ab.

Claude Code unterstützt alle sieben über sein Lifecycle-Event-System. Jeder Hook ist ein Shell-Skript, das JSON-Kontext über stdin empfängt. Das Modell entscheidet nicht, ob der Hook ausgeführt wird. Der Hook wird ausgeführt, weil das Event ausgelöst wurde.⁸

Die Kosten der Erkennungsschicht: etwa 200 ms pro Tool-Aufruf für die synchronen Hooks, plus eine vollständige Testausführung pro Story-Abschluss für die unabhängige Verifikation. Gegenüber den Kosten eines einzelnen unentdeckten Fehlers in einem autonomen Nachtlauf (potenziell Stunden verschwendeter Rechenleistung plus manuelle Bereinigung) ist der Tausch asymmetrisch.

Die verbleibenden 6 %

Die Taxonomie deckt 94 % der Fehler ab. Die verbleibenden 6 % verteilen sich auf drei Kategorien:

Modellverwirrung durch mehrdeutige Prompts (2 %). Der Agent missversteht die Aufgabe. Ein gut geschriebenes PRD mit Akzeptanzkriterien verhindert die meisten davon. Die wenigen, die übrig bleiben, sind echte Mehrdeutigkeit, mit der auch ein Mensch Schwierigkeiten hätte.

Context-Window-Überlauf (2 %). Der Agent verliert bei großen Codebasen den Überblick über früheren Kontext. Session-Drift-Erkennung (Messung der Kosinus-Ähnlichkeit zwischen der aktuellen Aufgabe und dem ursprünglichen Prompt) erkennt Degradation, bevor sie Fehler verursacht.¹⁵

Externe Fehler (2 %). Rate Limits, Netzwerkfehler, API-Änderungen. Standard-Retry-Logik und Circuit Breaker bewältigen diese. Es sind keine Agenten-Fehlermodi. Es sind Infrastruktur-Fehlermodi, die zufällig Agenten betreffen.

Die 6 % sind relevant, benötigen aber keine spezialisierte Erkennung. Standard-Engineering-Praktiken bewältigen alle drei. Die sieben benannten Modi sind der Bereich, in dem sich die Investition in Erkennungsinfrastruktur auszahlt.

Wichtigste Erkenntnisse

Für einzelne Entwickler. Lernen Sie die sieben Namen: Shortcut Spiral, Confidence Mirage, Good-Enough Plateau, Tunnel Vision, Phantom Verification, Deferred Debt, Hollow Report. Das Muster zu benennen ist der erste Schritt, um es zu erkennen. Wenn Ihr Agent „sollte funktionieren” schreibt statt Testausgabe einzufügen, schauen Sie auf eine Phantom Verification.

Für Teamleiter. Achten Sie auf Verkettung. Confidence Mirage führt zu Phantom Verification führt zu Deferred Debt. Ein einziger übersprungener Verifikationsschritt produziert drei nachgelagerte Fehler. Die Erkennungsschicht fängt den ersten Modus in der Kette ab, bevor sich der zweite und dritte materialisieren.

Für Plattform-Ingenieure. Bauen Sie die Sieben-Hook-Erkennungsschicht: Stop Gate, Evidence Gate, Debt Scanner, Integration Checker, Hedging Detector, Test Runner und Diff Auditor. Der Overhead beträgt etwa 200 ms pro Tool-Aufruf für synchrone Hooks plus eine Testausführung pro Story-Abschluss. Die Kosten sind asymmetrisch gegenüber unentdeckten Fehlern in autonomen Nachtläufen.

Das Kernprinzip. Das Modell ist nicht unzuverlässig. Das System, das es ohne Verifikationsinfrastruktur einsetzt, ist unzuverlässig. Der HN-Thread beschuldigte die Modelle. Die Taxonomie beschuldigt das Fehlen von Hooks.

Die Begleitartikel beschreiben die Infrastruktur im Detail: Claude Code as Infrastructure erklärt die Architektur, The 10% Wall erklärt, warum Infrastruktur wichtiger ist als Modell-Fähigkeit, The Fabrication Firewall erklärt die Ausgabeverifikation, und Jiro Quality Philosophy erklärt das Qualitätssystem, das diese Fehlermodi als durchsetzbare Einschränkungen kodiert.