There’s a moment in every AI project where the demo works and the system doesn’t. The demo runs on one clean input, in one environment, with the model you picked, and it looks great. Then a real document arrives — the one with the weird format, the field that’s blank when it shouldn’t be, the edge case nobody wrote down — and the whole thing quietly falls over.
I’ve spent the last while on both sides of that gap: building agentic AI systems for clients, and building learning software my own family uses every day. And the single habit I keep coming back to is the one I’m writing down here: build it, then verify the output, then trust it. In that order, every time.
What “verify” actually means
Verifying doesn’t mean running it once and seeing it not crash. It means checking that the output is correct — that the agent extracted the right field, that the classification landed in the right bucket, that the thing the model said it did is the thing that actually happened. That’s a different bar, and it’s the bar customers actually care about.
I learned this the hard way on a document-processing pipeline I built for a client. The agents were fast. Too fast, honestly — they’d chew through a stack of documents and hand back structured data that looked right. But “looks right” is not a verification strategy. The fix wasn’t a better model. It was a human-in-the-loop gateway: anything below a confidence threshold stops being auto-approved and lands in a review queue instead. The pipeline got slower on paper and faster in practice, because the team stopped re-checking everything and only looked at the hard cases. Speed came from trust, and trust came from verification.
Why I self-host
The other half of “build and verify” is “build it somewhere you can actually inspect.” I run a homelab — Proxmox, a GPU node, a fleet of services in LXC containers — not because self-hosting is the most efficient way to do anything, but because it removes the excuses. When the thing runs on hardware I own, I can’t hand-wave about “production.” I deal with backups and TLS and resource limits and the 3 a.m. failure, or they deal with me. There’s no cloud dashboard between me and the reality of the system.
The same applies to the AI side. If I’ve never run a model locally, I don’t actually know what local inference costs, how it degrades under load, or when it’s worth it versus a cloud API. So I built a multi-model chat that routes between a local GPU and cloud models, and logs the tradeoffs per request. Now I can have an opinion grounded in measurement instead of a guess.
Where this shows up in real work
Client delivery is the obvious version of this loop: you sit next to a real customer problem, build something that solves it, verify it against their actual data — not the happy path — and keep going until it’s genuinely working. The prototype is the easy 20%. The delivery is the 80% where the value lives.
But it’s the same loop at home. The chore system only became trustworthy when the scanner stopped silently failing and the dashboard started telling the truth about what worked and what didn’t. Verification is not a client-work ritual; it’s how any system earns the right to be relied on.
What I’m building next
This site is the public end of the loop. The multi-model chat is coming along, the study platform is live, and I’ll keep writing about each thing the same way I built it: build it, verify it, then tell you what I found. The write-ups on this site are the verification — the demos are the proof.
In short
Build it, run it, verify it, then trust it — in that order, every time. That habit is the closest thing I have to a methodology, and it’s why this site exists: not to show a portfolio of demos, but to show work I built, ran, and verified, and the loop that produces it.