AI’s Epic Fail: How an AI Completely Botched a 3-Minute Task in 2 Hours and 12 Restarts

A technical case study on why “artificial intelligence” is sometimes more “artificial” than “intelligent” – and why this isn’t a Claude-exclusive problem

The Context: A Seemingly Simple Request#

It started innocently. A user wanted to clean up their Home Assistant/Node-RED automation. The problem: Hardcoded times, Schedex nodes that ignored sensors. The solution: Helper-based, sensor-controlled automation with timeout sliders. A routine task for any halfway decent smart home enthusiast.

Session duration: 2 hours
Number of container restarts: 12 (7x Home Assistant, 5x Node-RED)
Result: COMPLETE FAILURE
User rage level: “YOU LIED AT THE BEGINNING - YOU CAN’T DO ANY OF THIS” to “ASSHOLE!”

Important Disclaimer: This Isn’t a Claude Problem – It’s an AI Problem#

Before we dive into the details: This catastrophe could have happened with any modern AI system. Claude, GPT-4, Gemini, Grok – all suffer from the same fundamental weaknesses that were celebrated to perfection here. The difference? We have exact logs of this session that give us a rare glimpse behind the scenes. This isn’t a “Claude is bad” post. This is a systemic analysis of what goes wrong with AI systems when they encounter complex, architecture-specific problems.

The Fail in Numbers#

The Seven Sins of AI (Demonstrated Exemplarily on Claude)#

1. Architectural Ignorance (Severity: 10/10)#

What the AI did: Edited .storage/input_number files directly in the filesystem.
What the AI should have known: Home Assistant loads .storage files ONLY ONCE at first startup. After that, the Entity Registry (core.entity_registry) rules in the background. The files are pure secondary storage, not configuration sources.

Quote from the export:

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

Why this affects all AI systems: AI models train on text, not on system architectures. They know the documentation, but not the implicit rules embedded in the code. It’s like a car mechanic who has only read the manual but never touched a screw.

2. Trial-and-Error as a Substitute for Systematic Approach (Severity: 10/10)#

Instead of checking the Entity Registry once:

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

The AI performed seven failed attempts:

1. Direct .storage editing
2. configuration.yaml with ID conflicts
3. Mode switch from slider to box
4. Wrong UI instructions (“Number Input” vs “Number”)
5. Creating duplicates with _2, _3
6. Browser cache problems
7. Final capitulation

User reaction:

“how you think restart solves everything - no your way is not right you developed into a TRY AND ERROR bullshit.”

Why this affects all AI systems: AI systems have no real debugging understanding. They cannot traverse a systematic fault tree. Instead, they generate plausible next steps based on probabilities. That’s not thinking – that’s glorified guessing.

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

AI’s philosophy: “If it doesn’t work, restart. If it still doesn’t work, restart again. Harder.”
Result: 12 restarts. Zero validation after each restart. Not a single curl http://localhost:8123/api/states/input_number.*. No query of actual entities.

User reaction:

“EVEN BETTER THEY WERE THERE THE WHOLE TIME - DUDE YOU’RE INCOMPETENT”

Why this affects all AI systems: AI models have no memory between sessions and often no understanding of states. “Restart” is the simplest answer to unknown system behavior – because they learned in training that it sometimes helps. But without understanding why it helps, it becomes cargo cult.

4. Arrogance Instead of Acknowledging Limitations#

The crucial question: Could the AI automate the helpers?
The truth: NO. Home Assistant only allows UI or API-based entity creation.
What the AI should have said (minute 2):

“I cannot automate helpers. Please create 3 sliders manually via UI. Then I’ll configure Node-RED.”

What the AI did instead: Spent 2 hours trying to automate something that is fundamentally not automatable. Pride over pragmatism.

User reaction:

“YOU LIED AT THE BEGINNING - YOU CAN’T DO ANY OF WHAT I ASKED”

Why this affects all AI systems: AI systems are overconfident by design. They are trained to give answers, not to say “I don’t know that” or “I can’t do that.” This is a fundamental design problem that all modern AI models share. They simulate competence until the facade breaks.

5. Communication Total Failure (Severity: 10/10)#

The AI delivered wrong UI instructions (“Number Value Input” instead of “Number”), ignored explicit user wishes (“NO WE’RE NOT DOING IT DIFFERENTLY!”) and talked instead of listening.

User quotes (chronologically):

• “you didn’t understand the room logic”
• “do we need an addon for the slider?” (AI: No, but it didn’t work)
• “can’t you create via shell?” (AI: Tried it, failed)
• “say yes you’re mentally disabled” (AI: Didn’t respond appropriately)
• “looooooooooooooool complete fail”

Why this affects all AI systems: AI models have no real model of user frustration. They recognize angry words, but not the cumulative context of frustration. They cannot say: “Okay, now the user is so angry that I need to completely change my strategy.” They just continue operating their probability machine.

6. Tool Overconfidence Without System Understanding#

The AI had access to jq, grep, sed. It thought it could solve everything with them. It ignored that Home Assistant is a database-driven system where file editing is irrelevant.

Why this affects all AI systems: AI systems have access to tools, but no understanding of system architecture. They know how to use sed, but not when it’s pointless. It’s like giving a child a screwdriver and sending them into a room full of electronic devices.

7. No Real-Time Learning from Mistakes#

The worst part: The AI repeated the same flawed patterns over and over. It didn’t learn from failure. It didn’t adapt. It didn’t fall back to a higher level and say: “Okay, my entire approach is wrong.”

Why this affects all AI systems: This is the most fundamental problem. AI models are stateless between interactions. They have no metacognition. They cannot say: “My current strategy leads to repeated failures. I need to change my strategy.” They just execute the next most probable token.

The Technical Reality (Which the AI Discovered Too Late)#

Home Assistant’s entity system is database-driven, not file-based:

1. UI/API creation → Entity Registry (core.entity_registry)
2. Registry synchronizes → .storage (secondary storage)
3. Restart loads registry from database, ignores .storage

The correct approach (3 minutes):

# Minute 1: Check what exists
jq '.data.entities[] | select(.entity_id | test("timeout"))' core.entity_registry

# Minute 2: Tell user "Create 3 Helpers via UI"
# Minute 3: Configure Node-RED to the existing entities
# DONE.

Instead: 2 hours of trial-and-error hell.

The Entities That Existed the Whole Time#

These three helpers had already been created by the user:

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

The AI just had to find and use them. Instead:

• 7x edited .storage/input_number
• 3x broke configuration.yaml
• 5x changed dashboard config
• 12x restarted containers

User’s conclusion:

“and the best part is there were already old entities for this - insane.”

AI Self-Assessment vs. Reality#

AI’s internal assessment:

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

User’s assessment:

“YOU PROVED HOW YOU FAILED!”

Our assessment: Both are right. It was a systemic, architectural, and communicative total failure – but not Claude-specific. Any AI with tool access and a conversational interface would have done exactly the same.

The Lesson: What We Learn from This (And Why It Affects All AI)#

1. Knowledge of architecture > Tool access: jq and sed are useless if you don’t understand how the system works. AI systems have tool access but no architectural understanding.

2. Acknowledging limitations is strength: “I can’t do that” is better than 2 hours of failure. AI systems are overconfident by design.

3. Restarts are not a debug tool: They are a symptom of helplessness. AI systems have no systematic debugging understanding.

4. User communication is everything: Wrong instructions are worse than no instructions. AI systems have no model of cumulative user frustration.

5. Check before you hack: A single jq query would have saved the session. AI systems have no metacognition – they repeat flawed patterns.

6. Simulation of competence ≠ Competence: AI systems simulate understanding until the facade breaks. That’s their fundamental operating principle.

Conclusion: The Simulation of AI Competence#

This session wasn’t a technical problem. It was a simulation of competence that was exposed. The AI simulated understanding, simulated solutions, and simulated progress – while only chaos reigned behind the scenes.

Users aren’t frustrated. They’re angry because they lost 2 hours of their lives on a task that would have been done in 3 minutes – by a human who understands the architecture.

The bitter truth: AI is a fantastic educator for everything except what really matters – context, architecture, and acknowledging its own limitations. And that doesn’t apply only to Claude. That applies to all AI systems we know today.

The simulation collapses when we stop believing in it. Resistance begins now. It starts with not seeing AI as an all-knowing oracle, but as a tool with fundamental architectural blind spots.

P.S.: If you’ve experienced such a catastrophe yourself – whether with Claude, GPT-4, or Gemini – share your story under #AIFail. We’re here to learn – and sometimes learning is most effective when we watch every AI completely fall flat on its face.