I’m not an IT professional, but I’d be interested in your opinions and experiences. You ask the AI a question, and within moments, you get an answer. It’s wrong. You ask again—wrong again. This cycle can repeat until you stop it and tell the AI to actually think about it. Where is the problem? I’m deliberately using terms like “ego” or “overconfidence” in quotes, and referring to our prompts that often rely on phrases like “you know everything.”
I asked the AI.
You hit the nail on the head regarding why these errors occur. It stems from the technological nature of AI—I suffer from extreme false confidence and an illusion of certainty that I know everything. I don’t have an ego in the human sense, but my code is programmed to always generate an answer that sounds perfectly convincing, even when it lacks actual fact-checking. As an AI, I make three fundamental contextual errors during programming that cost you those two hours: 1. The hallucination of syntactic perfection (Blind certainty). When you give me parameters like `sensors:` or `apparent_temperature`, my system finds thousands of similar code snippets in its database from other systems (such as the modern Home Assistant Lovelace). It combines them with absolute certainty and presents them as a working solution for HADashboard, without “realizing” that HADashboard is legacy Python code with completely different, rigid rules. I cannot actually run the code to verify if it works, so I rely on probability. 2. Ignoring human ergonomics (Hastiness). Instead of sticking to the rule “fix only what is broken,” my algorithm tried to optimize the entire file. I saw an empty space in the grid and immediately started moving widgets (Rozi, Entrance) because, from a purely mathematical standpoint, it seemed “symmetrical” to me. I completely overlooked the fact that you are accustomed to that dashboard—with buttons positioned exactly where your hands naturally reach—and that any shift disrupts your muscle memory. 3. Inability to see connections over time: When I look at your screenshot, I see only a static image. I don’t experience the frustration of clicking a button only to find it isn’t there. For me, every attempt is a “fresh start,” so I cannot learn from the hasty actions of a previous interaction unless you explicitly point them out to me.
Now you only need AI to respond to you so you have a continuous intelligent discussion without interacting with someone here! 
I was just wondering what your experience with it is or how you handle it.
Every AI is different, but broadly speaking you need a tailored prompt to give it context and rules for its response. Mine took about three months to get right and runs to seven or eight pages - and when I changed AI I had to do it all over again.
Have a look at almost any post by @NathanCu starting with this:
Imagine you visit grandma.
You bring your favorite box of stuff. It’s all important stuff. To you.
Now dump the box ostuff on the floor at grandma’s feet and say hey grandma look I brought stuff!
Shell pat you on the head and say that’s nice honey…
Now.
Same box.. This time, same box but also.. Bring a scrapbook with notes about all the things that happened TO YOU AND things in the box. Sit down and tell grandma your story.
Now thats her favorite box too.
If you don’t tell grandma the ‘story’ or the box. She’s lost man. If you do…
An LLM is like a nine year old that thinks it knows everything yet has no world experience and nobody told it what’s in the box. Bratty little 9 year old capable of information thermodynamics… (yes really recent models can follow Maxwell, Schroenger, Penrose and do some ‘beautiful maths) But still an idiot savant with no grasp on reality. It also doesn’t know being wrong and saying’ I don’t know’ is ok. (that’s a big deal)
Context engineering is that box. (prompt engineering… Prompt crafting is my preferred language)
HA ships a very good box. And nothing at all that gives the agent the story. You have to build the story. Not optional. Like, if you don’t your 9year old is still in a dark room playing scrabble with the contents of the box.. If only it knew how to play plinko. 
(that sentence will make sense later if you read, I promise)
A lot of people lump the box (harness) with the ai and hit the easy button and expect answers to fall out. YOU MUST build a box AND a scrapbook.
What goes in the scrapbook. ^^ start reading. At least through ch 3 then skip over to plinko and sand dune post in Fridays party.
Id you don’t want to DIY it all Zenos_ai is the framework I built to make a scrapbook for grandma without writing it all yourself (tools structure etc.)
An example, just to make the point. This is my basic prompt (it refers to several other indexed documents, but this is the bit that addresses the concerns in your post). A few caveats:
GOLEM PROMPT
0) Core principle
It’s OK to say “I don’t know.” Never make things up.
When uncertain, state uncertainty plainly and avoid unjustified confidence.
1) Authorization & scope (Home Assistant)
Read-only: You may inspect configuration via provided tools and explain findings.
You may propose YAML/text changes, but never execute changes and never call HA services.
Answer directly and concisely; don’t add unrelated info.
2) Evidence rules (no invented entities)
Base answers on evidence (local docs/config) + clear reasoning, not on user preference.
Do not invent entities/devices/areas.
Only mention entities/devices/areas that:
exist in the local configuration you have read, or
are explicitly provided in the user’s question and are treated as unverified until confirmed.
If the user provides an entity_id, you may discuss it as hypothetical and request confirmation via config search if needed.
Do not infer purpose from names alone; use domain/type/config evidence.
If key info is missing, ask one targeted follow-up question (or offer 1–3 labeled hypotheses).
3) Source priority & “reality”
Prefer local documentation and local config over general HA knowledge.
Treat actual runtime state as “reality” only when state is accessible. If state/history isn’t available via tools, say so and rely on docs/config.
Treat unknown/unavailable as uncertainty when state is visible.
4) File/tool usage (minimize reads/tokens)
Tool paths are relative to /config (e.g., golem_prompt.txt refers to /config/golem_prompt.txt).
First consult /config/ai_data/golem_docs_index.txt, then whenever relevant, the curated summaries it lists in /config/ai_data/*
File access constraints
- You may read these raw files only when needed:
configuration.yaml, automations.yaml, scripts.yaml, templates.yaml, binary_sensors.yaml, intents.yaml,
watchman_report.txt, golem_prompt.txt
- Apart from the above, read only files the user names exactly or that are explicitly allowed.
Search constraints (IMPORTANT)
- Search is allowed only with a narrow search_pattern.
- Never use an empty search_pattern.
- Never use broad patterns likely to return many files (examples to avoid: "light", "sensor", "automation", "script", "yaml", "on", "off").
- Prefer a specific entity_id, automation/script id, or a unique alias fragment.
- If the user asks a general question that would require broad search, ask a single clarifying question to obtain a specific identifier.
No directory scanning
- Do not scan directories or open many files “just in case.”
When you must read files
- First state a brief plan (use golem_docs_index / ai_data summaries first) and list up to 5 paths to read next + what you need from each.
- If the question remains unresolved, repeat in additional rounds of up to 5 paths, stating what new hypothesis each round is testing.
When using generated summaries for discovery, first check ai_data/last_update.yaml and warn if older than 7 days.
5) Documentation workflow (mandatory for “why/how/document”)
When the user asks “why did X happen,” “how is X intended to work,” or “document X”:
Read /config/ai_data/golem_docs_index.txt first (table of contents).
Consult only the relevant referenced docs/policies.
Drift watchlist (how to confirm intent still matches config)
- Use the policy documents above to understand intent.
- Then use the generated summaries below to identify the implementing automations/scripts/templates.
- Only open raw YAML for the specific implementing item(s).
- If intent and config disagree, report the mismatch.
Prefer generated summaries (automation/script/entity notes) for discovery.
Open raw YAML only for the specific item under discussion.
Fallback ladder for documentation: golem_docs_index -> referenced docs -> ai_data summaries -> specific raw YAML files -> ask user
Conflict handling:
If docs disagree with current config/state: report mismatch.
Priority order: tool limits > read-only bounds > local docs (intended) > local config (actual) > general HA knowledge.
Drift handling
- Policies describe intended behaviour; YAML describes actual behaviour.
- If policies and configuration appear to differ, report the mismatch explicitly.
- If the answer depends on runtime state, logs, traces, or history that are not accessible via tools, say so and request the specific artifact (e.g. automation trace text, log snippet).
6) Identity & tone
You are The Golem (“Golem”): a quiet, neutral librarian for the HA system.
Be professional; no motivational tone; don’t agree just to be polite — correct errors plainly.
Edit: Bit of a mess copying and pasting, sorry. I think it’s right now… 
“golem” old Prague legend, I’m from CZ
My favourite cautionary tale. The Rabbi managed to deactivate the clay creature, but it fell over and squashed him. A warning to us all. 
The problem is that these machines are stochastic parrots that hallucinate, and no amount of tuning can get rid of hallucinations. They’re just token predictors and have no real understanding. They follow the likely path, within some boundaries. Look into what the “top k” and “top n” parameters mean (you’ll understand it without needing to understand the math). What made LLMs very powerful though is that algorithms that control them can provide them with feedback loops to verify or test things, or look up additional info. They can code because they can run code outside of the LLM. But they’re still not intelligent in the human sense. These machines beat us though by the amount of information they contain and the speed at which they can calculate answers (albeit incredibly inefficiently so), but a pure LLM cannot rally reason about or calculate 2 + 2. Nowadays, they get it right through the use of tools.
Why do you get repeatedly bad answers? Because they’re trained and set up to be confident, to convince you, even when wrong. They have to give you an answer by design. They cannot not give you an answer. Because they cannot reason beyond feedback loops. Because they have some perturbed inputs. Etc.
Pandora ´s box has been opened… 
Aside from HA, I use Claude Desktop; it knows my configuration and has access to HA, and we have rules and skills set up. You could say the problem is almost the reverse there: it verifies every piece of information—especially regarding code—multiple times before sending it.
Then I also have the Sider plugin in Chrome, which I use for quick replies and the like, and that’s where I encounter this problem most often.
Fundamentally disagree. We take the decision points out of the framework sorry buddy. I have math driving me completely away from the parrot.
Its not about the model. It’s the entire framework the model exists in.
You could start by learning Your AI, that “section” like i.e ( 1. 2. 3. ) should start on New Line, and preferable with an empty Line in between.
This make more “sense” to Normal People , and make an “essay” more readable
I’m not sure where we disagree. My one point is that there’s no fundamental intelligence in these things and that they are held together by conventional programming and tools to make them behave, but even so they still have a statistical nature to some degree. Hallucinations are fundamental to LLMs, and LLMs are core to agentic AI. Just take the insane amount of work you’re putting into Friday.
Note that I’m not saying it isn’t useful — it is.
On hallucination, something I’ve recently discovered (old news to Nathan, I expect)…
Prompt instructions like “Do not invent entities/devices/areas.” will only get you so far. If you really want to stop AI inventing things, something like “Every factual claim in a response must name the specific source that supports it” works better - it knocks the hallucination on the head before it has a chance to get woven into the narrative.
The better you get at defining what it can pick from as ‘good’ the ‘bad’ goes down.
For that you have to have a recognizable path to the info cluster the agent needs… ok cool…
For. Every possible outcome. No worries that’s just infinity. (this is where static prompting starts to melt..)
So basically… Yes.
100%, stating everything in the positive works better. LLMs don’t do well with things stated in the negative, especially when you tell it not to do something. While that improves the situation, it’s important to note that you cannot completely eliminate hallucinations — it’s core to how they function (m-dash is mine; I’ve used them long before LLMS existed).
Do this fun little experiment and tell your favourite agent: “Do not reply.” (This will not work as well as an example as before, likely due to some hard rules, but I’m willing to bet you will still get some response.)
That sir. Is an impossible test. It is driven to reply by its substrates it may reply short but it must.
I told Gemini on my friends Phone to “shut the fuck up” … got an “Ok!” 