The warning before writing a single line

Before touching any code, I noticed something: right next to the automation that starts the vacuum sits a second one — the security alarm. And the two are coupled through a duplicated piece of logic. The alarm sequence contains a variable that predicts whether the vacuum is about to start, in order to decide: arm upstairs immediately, or wait until the vacuum finishes (a motion sensor would otherwise flag the moving robot as an intruder)?

Two independent conditions, deliberately kept identical, deciding two different things.

That’s exactly the kind of coupling that had already caused two real false alarms in the past.

If I extended the vacuum’s start condition with the new geofence logic without updating the alarm’s copy of that logic in lockstep, I’d introduce a fresh race condition in the single most safety-critical corner of the config. So: flagged the risk, got the go-ahead (“do it, but be extra careful”), and synchronized both conditions word-for-word:

The synced condition

# Both the vacuum-start condition AND the alarm's prediction variable
# use this exact same expression:
value_template: >-
  {{ (trigger.id == 'home_away' and is_state('person.dennis', 'not_home')
  and is_state('person.anni', 'not_home')) or trigger.id ==
  'home_away_sauger_fallback' }}

Escalating to three opinions instead of one

Changes to safety-critical areas don’t just get a single code review in my setup. There’s a standing rule: a dedicated review agent, plus two independent opinions from different model providers — genuine diversity, not the same blind spots twice.

Roughly, invoking the second and third opinions looks like this — one default call, one escalated to a stronger model on the same run:

scripts/external_review.py "geofence change to vacuum-start condition"
scripts/external_review.py --model <stronger-model> "same change, second pass"

All three came back with the same verdict: critical.

• Model one claimed the prediction formula in the alarm sequence and the actual vacuum-start condition weren’t identical.
• Model two made the same claim, backed by a different (also wrong) detail.
• The internal review agent claimed something else entirely: that the zone check only recognized the small 75-meter zone, not the new, larger one — and separately, that a safety property of the automation (mode: parallel, allowing two trigger instances to run concurrently without blocking each other) didn’t actually exist in the code.

Three independent sources, one converging “critical” alarm.

Three different companies, three different training runs, one shared hallucination — either impressively bad luck or a surprisingly efficient way to be wrong in stereo.

That’s exactly the moment where it’s tempting to either trust blindly (“three out of three can’t all be wrong”) or dismiss blindly (“the AI is exaggerating again, back to my coffee”).

Checking instead of believing

Neither. Line-by-line comparison instead.

What each claim actually turned out to be

All three “critical” findings: false positives. A clean sweep, in the wrong direction.

The one real finding

But while doing that line-by-line comparison myself, I noticed something none of the three AI opinions had flagged: a comment directly above the automation’s triggers claimed the alarm sequence was “exclusively gated to the 10-minute trigger” — the opposite of what was actually intended and implemented (the alarm sequence has to react to both triggers, or it reintroduces the exact race condition I’d warned about in the first place). A stale, misleading comment, not a logic bug — but exactly the kind of detail that misleads whoever (human or AI) trusts the comment over the code six months from now.

# Before (misleading):
# Light/Cover/Lock stay exclusively gated on home_away (10 min).
# Alarm too.  <-- this part was simply no longer true

# After:
# Light/Cover/Lock stay exclusively gated on home_away (10 min).
# The alarm sequence is deliberately NOT gated — it must react to
# BOTH trigger IDs (see the synced prediction formula above) to
# correctly decide immediate-arm vs. wait-for-vacuum.

What I took away from it

Three AI reviews, three false “critical” alarms, one real (if minor) finding that none of them caught. That’s not an argument against getting second opinions — it’s an argument for treating them as what they are: extra scrutiny, not proof. The value wasn’t in trusting the three opinions; it was in the process forcing me to verify every single claim against the actual code — and it was precisely while disproving the false positives that the real issue surfaced, not because any review tool found it.

The lesson I’m keeping: for safety-critical code, verifying against ground truth — actual code, actual documented system behavior — always pays off, independent of how many AI voices agree on something. Trust doesn’t substitute for checking, no matter how many opinions you stack.

If you want the backstory on why changes like this get three opinions instead of one in the first place, the introduction post has the full picture. Next up: the time a subagent I explicitly told to stay read-only pushed a commit to main anyway.

I haven’t found much writing that treats this setup as the real, load-bearing infrastructure it actually is, instead of a novelty demo where someone asks a chatbot to turn on a lightbulb and calls it a day.

So I’m writing it down as it happens — the wins and the “why is the alarm system arguing with the vacuum cleaner” moments alike.

Who this is for

Two groups, deliberately: people who live in the smart home / home automation world and want to see what “AI-managed” actually looks like day to day, not just in a demo video — and people who work with AI agents generally (coding agents, autonomous workflows, anything with real write access to something that matters) and want concrete, specific stories rather than abstract best-practice advice. If you only care about one of the two, you’ll still get something out of the other half — the failure modes turn out to be mostly the same regardless of whether the agent is touching a door lock or a production database.

What this actually is

Home Assistant, self-hosted, fully version-controlled, running on real hardware sitting on a shelf in my house — not a cloud instance, not a demo VM. An AI coding agent with real write access to that configuration, a self-hosted issue tracker, and a set of deliberately scoped permissions — some things it does freely, some things need my sign-off, a few things it’s not allowed to touch at all, on pain of a stern chat.

It’s not a toy. It arms and disarms a real alarm system, controls real door locks, and decides when a robot vacuum should or shouldn’t start based on whether anyone’s home. Bugs here aren’t failed unit tests you shrug off with a red CI badge — they’re a door that doesn’t lock, or an alarm that goes off because a vacuum cleaner committed the crime of existing.

The stack, roughly

Home Assistant (self-hosted)  ──┐
Git repo, full config in it     ├── AI coding agent, scoped read/write
Self-hosted issue tracker       │   + a dedicated review pass +
CI on every change              ├── external second opinions before
Static status dashboard         │   anything safety-critical ships
Nightly/weekly unattended jobs ─┘

Two physical boxes underneath all of it — a low-power mini-PC running Home Assistant itself, and a NAS doing double duty as the Git server and CI runner. The daily workflow post has the actual make/model/spec sheet, and the architecture deep-dive covers how the agent process stays alive across all of it.

A rough sketch of what a normal day looks like

• The agent starts each session by reading a running log and a backlog of open work, and checks whether I’ve flagged anything specifically for it via a small dashboard on my phone.
• Every piece of real work — feature, bug fix, even a documentation change — gets a short ID and a tracked issue. The open issues are the project status; there’s no separate document to keep in sync.
• Nothing risky ships on one opinion. Changes to anything safety-critical get reviewed by a dedicated review pass plus two independent second opinions from different model providers — and even then, as you’ll see in the first real post, all three can be confidently wrong at the same time.
• A handful of unattended jobs run overnight — light audits, health checks, security log reviews — and file findings for me to triage when I’m back, never acting unsupervised on anything non-trivial.
• Long sessions eventually hit a context limit and get cleared; a handoff step writes down exactly what was mid-flight so the next session doesn’t have to reconstruct it from git history. A separate, longer-lived memory keeps track of preferences and hard lessons across all of that — not “what were we doing,” but “what should never happen again.”

That last part is where most of the interesting content on this blog will come from: not the features that worked, but the specific, dated moments where the process caught something — or didn’t, and had to grow a new guardrail afterward, usually accompanied by me staring at a diff at an unreasonable hour wondering how a robot vacuum nearly got my house burgled by itself.

What you’ll find here

Mostly two kinds of posts. Incident write-ups — something broke, here’s the actual root cause, here’s the fix, here’s the guardrail added so the same class of bug can’t recur silently. And pattern posts — a piece of reusable design that came out of one of those incidents, generalized enough to apply outside my specific setup (state persistence across restarts, how to avoid an agent racing itself, why timeouts are often the wrong signal for “a process is done”).

I’ll keep every post technical and specific — real config snippets, real reasoning, not a sanitized case study. The one thing I’ll deliberately leave out or generalize is anything that would tell someone exactly how my house’s security setup behaves — the pattern is the point, not the exact parameters of my alarm system.

If you’re running something similar, or thinking about it, I’d genuinely like to hear what’s broken for you too — that’s a big part of why this is public instead of a private notebook.

First real post is up next: three independent AI code reviews unanimously flagged the same change as critical. All three were wrong, and the actual bug was something none of them found.