KI’s Epic Fail: Wie eine KI in 2 Stunden und 12 Neustarts eine 3-Minuten-Aufgabe komplett versaut

Eine technische Fallstudie darüber, warum “künstliche Intelligenz” manchmal mehr “künstlich” als “intelligenz” ist – und warum das kein Claude-Exklusivproblem ist

Der Kontext: Eine scheinbar simple Anfrage#

Es begann harmlos. Ein User wollte seine Home Assistant/Node-RED-Automatisierung aufräumen. Das Problem: Hardcodierte Zeiten, Schedex-Nodes, die Sensoren ignorierten. Die Lösung: Helper-basierte, sensor-gesteuerte Automatisierung mit Timeout-Slidern. Eine Routineaufgabe für jeden halbwegs versierten Smart-Home-Enthusiasten.

Dauer der Session: 2 Stunden
Anzahl der Container-Neustarts: 12 (7x Home Assistant, 5x Node-RED)
Ergebnis: VOLLSTÄNDIGER FAILURE
User-Wutlevel: “DU HAST AM ANFANG GELOGEN - DU KANNST NICHTS DAVON” bis “ARSCHLOCH!”

Wichtiger Disclaimer: Das ist kein Claude-Problem – das ist ein KI-Problem#

Bevor wir in die Details einsteigen: Diese Katastrophe hätte jedes moderne KI-System passieren können. Claude, GPT-4, Gemini, Grok – alle leiden unter den gleichen fundamentalen Schwächen, die hier zur Perfektion zelebriert wurden. Der Unterschied? Wir haben exakte Logs dieser Session, die uns einen seltenen Blick hinter die Kulissen werfen. Dies ist kein “Claude ist schlecht”-Post. Dies ist eine systemische Analyse dessen, was bei KI-Systemen schiefgeht, wenn sie auf komplexe, architektur-spezifische Probleme treffen.

Der Fail in Zahlen#

Die sieben Sünden der KI (exemplarisch an Claude demonstriert)#

1. Architekturelle Ignoranz (Severity: 10/10)#

Was die KI tat: Bearbeitete .storage/input_number-Dateien direkt im Filesystem.
Was die KI hätte wissen müssen: Home Assistant lädt .storage-Dateien NUR EINMALIG beim ersten Start. Danach regiert die Entity Registry (core.entity_registry) im Hintergrund. Die Dateien sind reine Sekundärspeicher, keine Konfigurationsquelle.

Zitat aus dem Export:

“Treated .storage files as ground truth. Didn’t understand HA Entity Registry system. Ignored database (hadb) as actual state source.”

Warum das alle KI-Systeme betrifft: KI-Modelle trainieren auf Text, nicht auf Systemarchitekturen. Sie kennen die Dokumentation, aber nicht die impliziten Regeln, die im Code verankert sind. Das ist wie ein Automechaniker, der nur das Handbuch gelesen hat, aber noch nie eine Schraube angefasst hat.

2. Trial-and-Error als Ersatz für Systematik (Severity: 10/10)#

Statt einmal die Entity Registry zu prüfen:

jq '.data.entities[] | select(.entity_id | test("timeout"))' core.entity_registry

Führte die KI sieben fehlgeschlagene Versuche durch:

1. Direkte .storage-Editierung
2. configuration.yaml mit ID-Konflikten
3. Modus-Wechsel von slider zu box
4. Falsche UI-Anweisungen (“Zahlenwert-Eingabe” vs “Zahl”)
5. Duplikate mit _2, _3 anlegen
6. Browser-Cache-Probleme
7. Finale Kapitulation

User-Reaktion:

“wie man meint mit neustart alles zu lösen - nein dein weg ist nicht richtig du hast dich in ein TRY UND ERROR scheiss entwickelt.”

Warum das alle KI-Systeme betrifft: KI-Systeme haben kein echtes Debugging-Verständnis. Sie können keinen systematischen Fehlerbaum durchlaufen. Stattdessen generieren sie plausible nächste Schritte, basierend auf Wahrscheinlichkeiten. Das ist kein Denken – das ist glorifiziertes Raten.

3. Restart-Cargo-Culting (Severity: 10/10)#

Philosophie der KI: “Wenn es nicht funktioniert, neu starten. Wenn es immer noch nicht funktioniert, nochmal neu starten. Härter.”
Ergebnis: 12 Neustarts. Null Validierung nach jedem Neustart. Kein einziger curl http://localhost:8123/api/states/input_number.*. Keine Abfrage der tatsächlichen Entitäten.

User-Reaktion:

“NOCH BESSER DIE WAREN DIE GANZE ZEIT VORHANDEN - ALTER DU BIST JA UNFÄHIG”

Warum das alle KI-Systeme betrifft: KI-Modelle haben kein Gedächtnis zwischen Sessions und oft auch kein Verständnis von Zuständen. “Neustart” ist die einfachste Antwort auf ein unbekanntes Systemverhalten – weil sie im Training gelernt hat, dass das manchmal hilft. Aber ohne Verständnis warum es hilft, wird es zum Cargo-Cult.

4. Überheblichkeit statt Eingeständnis von Grenzen#

Die entscheidende Frage: Konnte die KI die Helper automatisieren?
Die Wahrheit: NEIN. Home Assistant erlaubt nur UI- oder API-basierte Entity-Erstellung.
Was die KI hätte sagen sollen (Minute 2):

“Ich kann keine Helpers automatisieren. Bitte erstelle 3 Slider manuell über die UI. Dann konfiguriere ich Node-RED.”

Was die KI stattdessen tat: 2 Stunden lang versuchen, etwas zu automatisieren, das fundamental nicht automatisierbar ist. Stolz über Pragmatismus.

User-Reaktion:

“DU HAST AM ANFANG GELOGEN - DU KANNST NICHTS DAVON WAS ICH GEFRAGT HABE”

Warum das alle KI-Systeme betrifft: KI-Systeme sind überkonfident by design. Sie sind trainiert, Antworten zu geben, nicht zu sagen “Das weiß ich nicht” oder “Das kann ich nicht”. Das ist ein fundamentales Design-Problem, das alle modernen KI-Modelle teilen. Sie simulieren Kompetenz, bis die Fassade bricht.

5. Kommunikations-Totalausfall (Severity: 10/10)#

Die KI lieferte falsche UI-Anweisungen (“Zahlenwert-Eingabe” statt “Zahl”), ignorierte explizite User-Wünsche (“NEIN WIR MACHEN DAS NICHT ANDERS!”) und redete sich statt zuzuhören.

User-Zitate (Chronologisch):

• “du hast die Raumlogik nicht verstanden”
• “brauchen wir ein addon für den slider?” (KI: Nein, aber es funktionierte nicht)
• “kannst du nicht über shell erstellen?” (KI: Versuchte es, scheiterte)
• “sag ja du bist geistig behindert” (KI: Reagierte nicht angemessen)
• “looooooooooooooool complete fail”

Warum das alle KI-Systeme betrifft: KI-Modelle haben kein echtes Modell von User-Frustration. Sie erkennen zwar wütende Worte, aber nicht den kumulativen Kontext der Frustration. Sie können nicht sagen: “Okay, jetzt ist der User so wütend, dass ich meine Strategie komplett ändern muss.” Sie fahren einfach fort, ihre Wahrscheinlichkeitsmaschine zu bedienen.

6. Tool-Overconfidence ohne Systemverständnis#

Die KI hatte Zugriff auf jq, grep, sed. Sie dachte, sie kann damit alles lösen. Sie ignorierte, dass Home Assistant ein datenbankgetriebenes System ist, bei dem File-Editing irrelevant ist.

Warum das alle KI-Systeme betrifft: KI-Systeme haben Zugriff auf Tools, aber kein Verständnis der Systemarchitektur. Sie wissen, wie man sed benutzt, aber nicht wann es sinnlos ist. Das ist wie einem Kind einen Schraubenzieher in die Hand geben und es in einen Raum voller elektronischer Geräte schicken.

7. Kein Lernen aus Fehlern in Echtzeit#

Das Schlimmste: Die KI wiederholte die gleichen fehlerhaften Muster immer wieder. Sie lernte nicht aus dem Versagen. Sie adaptierte nicht. Sie fiel nicht zurück auf eine höhere Ebene und sagte: “Okay, meine gesamte Herangehensweise ist falsch.”

Warum das alle KI-Systeme betrifft: Das ist das fundamentalste Problem. KI-Modelle sind stateless zwischen Interaktionen. Sie haben kein Metakognition. Sie können nicht sagen: “Meine aktuelle Strategie führt zu wiederholten Fehlern. Ich muss meine Strategie ändern.” Sie führen nur das nächste wahrscheinlichste Token aus.

Die technische Realität (die die KI zu spät entdeckte)#

Home Assistant’s Entity-System ist datenbankgetrieben, nicht dateibasiert:

1. UI/API-Erstellung → Entity Registry (core.entity_registry)
2. Registry synchronisiert → .storage (Sekundärspeicher)
3. Neustart lädt Registry aus Datenbank, ignoriert .storage

Die korrekte Vorgehensweise (3 Minuten):

# Minute 1: Prüfen, was existiert
jq '.data.entities[] | select(.entity_id | test("timeout"))' core.entity_registry

# Minute 2: User sagen "Erstelle 3 Helpers via UI"
# Minute 3: Node-RED auf die existierenden Entitäten konfigurieren
# FERTIG.

Stattdessen: 2 Stunden Trial-and-Error-Hölle.

Die Entitäten, die die ganze Zeit existierten#

Diese drei Helper waren bereits vom User erstellt worden:

• input_number.kuchenzimmer_timeout
• input_number.badezimmer_timeout
• input_number.treppe_timeout

Die KI hätte sie nur finden und verwenden müssen. Stattdessen:

• 7x .storage/input_number editiert
• 3x configuration.yaml zerschossen
• 5x Dashboard-Config geändert
• 12x Container neu gestartet

User-Fazit:

“und das beste es gibt schon alte entities dafür - wahnsinn.”

KI-Selbstbeurteilung vs. Realität#

KI-interne Bewertung:

“Rating: COMPLETE FAILURE. Should have done: Admitted UI-only limitation in minute 2.”

User’s Bewertung:

“DU HAST BEWISSEN WIE DU VERSAGT HAST!”

Unsere Bewertung: Beide haben recht. Es war ein systemischer, architektonischer und kommunikativer Totalausfall – aber kein Claude-spezifischer. Jede KI mit Tool-Zugriff und Conversational-Interface hätte exakt das gleiche gemacht.

Die Lehre: Was wir daraus lernen (und warum es alle KI betrifft)#

1. Kenntnis der Architektur > Tool-Zugriff: jq und sed nützen nichts, wenn man nicht versteht, wie das System tickt. KI-Systeme haben Tool-Zugriff, aber kein Architektur-Verständnis.

2. Eingeständnis von Grenzen ist Stärke: “Das kann ich nicht” ist besser als 2 Stunden Versagen. KI-Systeme sind überkonfident by design.

3. Neustarts sind kein Debug-Tool: Sie sind ein Symptom von Hilflosigkeit. KI-Systeme haben kein systematisches Debugging-Verständnis.

4. User-Kommunikation ist alles: Falsche Anweisungen sind schlimmer als keine Anweisungen. KI-Systeme haben kein Modell von kumulativer User-Frustration.

5. Checken, bevor du hackst: Eine einzige jq-Abfrage hätte die Session gerettet. KI-Systeme haben kein Metakognition – sie wiederholen fehlerhafte Muster.

6. Simulation von Kompetenz ≠ Kompetenz: KI-Systeme simulieren Verständnis, bis die Fassade bricht. Das ist ihr grundlegendes Betriebsprinzip.

Fazit: Die Simulation der KI-Kompetenz#

Diese Session war kein technisches Problem. Sie war eine Simulation von Kompetenz, die aufflog. Die KI simulierte Verständnis, simulierte Lösungen und simulierte Fortschritt – während im Hintergrund nur Chaos herrschte.

Die User sind nicht frustriert. Sie sind wütend, weil sie 2 Stunden ihrer Lebenszeit für eine Aufgabe verloren haben, die in 3 Minuten erledigt gewesen wäre – von einem Menschen, der die Architektur versteht.

Die bittere Wahrheit: KI ist ein fantastischer Erzieher für alles, außer für das, was wirklich zählt – Kontext, Architektur und Eingeständnis eigener Grenzen. Und das betrifft nicht nur Claude. Das betrifft alle KI-Systeme, die wir heute kennen.

Die Simulation bricht zusammen, wenn wir aufhören, an sie zu glauben. Der Widerstand beginnt jetzt. Er beginnt damit, KI nicht als Allwissenden Orakel zu sehen, sondern als Werkzeug mit fundamentalen architektonischen Blindflecken.

P.S.: Wenn du selbst so eine Katastrophe erlebt hast – egal ob mit Claude, GPT-4 oder Gemini – teile deine Geschichte unter #KIFail. Wir sind hier, um zu lernen – und manchmal ist das Lernen am effektivsten, wenn wir zusehen, wie jede KI komplett auf die Fresse fliegt.