Yet another tech blog

I’m Alex. I live in Sydney with my wife and daughter, I help customers implement and manage their AI and data governance, and I run more infrastructure at home than anyone needs to.

Most of my work comes back to the same question: can this organisation say what its AI agents were allowed to see, and prove what they actually did. Some of that is design and some of it is guardrails, and a good deal of it is making the case that the boring part comes first.

That work stands on distinctly unglamorous foundations: the catalogue, the lineage, the definitions, the permissions. An agent is exactly as trustworthy as its answer to what did I read, where did it come from, and was I allowed to use it — and most large organisations have spent a decade unable to answer that reliably for their analysts, let alone for something that acts on its own at three in the morning.

At home I run a small estate: a container host, a monitoring box, a Mac mini doing the jobs that only macOS can do, a GPU running open-weight models locally, and a knowledge base with a lot of automation built around it. There’s a rough description of it here, and the things I’m building are listed separately — some finished, some very much not.

None of that was ever the goal. The actual motivation is narrower and a lot less impressive: there are things I don’t much enjoy doing, things I’m not particularly good at, and things I reliably forget. Given the choice between getting better at those and making a computer do them, I have picked the computer every single time. Nearly everything I’ve built started as one of those three, and the infrastructure accumulated underneath it.

Some of that is laziness. Some of it isn’t. I have a daughter who is growing up at a rate that makes every hour spent re-doing something by hand feel like a bad trade, and automation is how I buy those hours back. Most of what I write here is the bill that arrives afterwards.

Which is how you acquire the second job. Automate something and you now own it — and it will break, at a moment you aren’t looking, in a way that doesn’t announce itself.

Why the site

Everything I’ve learned in the last two years arrived the same way: something stopped working, and it took me far too long to notice.

Not dramatic failures. Nothing caught fire. The pattern is quieter than that and much worse. A scheduled job that ran every hour, reported success, and wrote nothing for a month. A sync that silently discarded eighteen days of edits when it reconnected. Monitoring that was itself dead for forty days, during which the absence of alerts read, reasonably enough, as everything being fine.

Each of those has a number attached, a date, and a specific mistake I made. That is what I want to write down. Not advice — post-mortems. What broke, how long it ran broken, how it was eventually caught, and what I changed so it couldn’t happen the same way again.

I’m interested in that pattern beyond my own house, because the systems I work with professionally have exactly the same shape and far more at stake. An automation that fails quietly wastes your evening. An agent that fails quietly, with write access, inside a regulated business, is a different category of problem — and the industry’s current answer to how would you know is mostly optimism.

What makes it interesting rather than merely alarming is that the question isn’t really about the model. An agent acts on whatever context it was handed: which tables, whose definitions, how fresh, how trustworthy. Govern that and you can say something defensible about what the agent did. Leave it unexamined and you’re auditing the output of a process whose inputs nobody wrote down.

What to expect

Roughly weekly. Mostly incidents from my own systems, because those are mine to publish with the numbers intact. Occasionally the general argument underneath them, and only when there’s something underneath — an essay with no incident behind it is just an opinion with footnotes.

There will also be hardware, because I like building unreasonably complicated keyboards, and home automation, because a garage door that only works when it feels like it is a genuinely interesting engineering problem.

The name

I drink a lot of coffee, flatwhite.dev was taken, and by the time I’d worked through every espresso term still available I’d developed strong opinions about domain squatting. An extra shot is strictly unnecessary and I order one anyway, which seemed about right for a site documenting infrastructure nobody asked me to run.