I started where everyone starts. It triaged my email, pulled dates out of messages and put them in my calendar, chased me about the things I'd forgotten. Genuinely useful, and completely surface level. None of it told me whether an agent could be trusted with work that matters.

The question I actually wanted answered was a management one. Could I treat this as a team? Give it deliverables, hold it to a standard, review what came back, and end up with something I hadn't built myself. That's the question my job turns on, and it doesn't change much whether the team is people or agents.

Between a demanding job and a family there isn't a lot of time to find out. So it had to be something small, real, and mine.

Plugins to patch, a theme to keep compatible, and every change copied from test to live by hand. Small enough to hold in my head, real enough that getting it wrong would be visible to anyone who looked.

There was a second thing I wanted out of it. I'd never used git (opens in a new tab) in anger, and I was curious whether the way software teams manage change has anything to teach programme delivery. That turned out to be the more interesting question of the two.

So I rebuilt it. Or rather, I didn't. I vibe coded it with Claude (opens in a new tab) and OpenClaw: describing what I wanted in plain language, reviewing what came back, and learning as I went. Managing rather than delivering. My architecture background did some of the steering. If I'm honest, so did the geek in me.

Rebuilding on Astro (opens in a new tab) removed the admin panel, and that constraint turned out to be the point. No live editor means content lives in the repository. Once it's in the repository it's in git, and git gives you branches, branches give you environments, and environments give you a review gate. One decision about a framework quietly dragged the whole delivery model along with it.

Once I'd used it properly, every piece of git had an equivalent I already knew:

The difference is speed and cost. A software team runs that whole cycle several times a day, and the tooling makes the audit trail a by-product rather than a chore. Programmes run it over months, with the trail assembled afterwards by people who weren't there. That gap is the bit worth thinking about.

Releases are atomic. The whole site swaps at the edge in one operation, so there's no half-deployed state to explain. If one is wrong, an earlier one is promoted back in seconds. That's the entire disaster recovery plan, and unlike most of the DR plans I've inherited, it has actually been tested.

Every page is compiled to HTML before anyone asks for it. No application server, no database, nothing running at request time, so most of the security work a conventional site needs is spent defending things this one simply doesn't have. The trade is that anything dynamic has to be deliberate, which for a personal site is no trade at all.

A chat window is not an agent. The distinction that matters here is between the model and the runtime it lives in. Claude (opens in a new tab) does the reasoning. OpenClaw (opens in a new tab) is the open-source runtime around it: it gives the agent a persistent identity, memory that survives between sessions, a place in Slack, direct access to the repository and the board, scheduled work that runs whether I'm at a keyboard or not, and a written set of rules about what it may do unattended.

That second half is the part I found most interesting, because it isn't a technology problem. Buying model access is trivial. Deciding what a persistent, tool-holding, always-on agent may do on your behalf is governance, and it's the question I'd have to answer at work long before anyone asked me which model we were using.

Scope, gates, trail. Working that out on a website costs me an evening. Working it out for the first time on a programme costs considerably more.

• Everything as code. Content, styling, headers and redirects all live in the repository. There is no admin panel and no unversioned change.
• Test before live. Reviewed on a staging domain, not on a screenshot. No direct pushes to production.
• Versioned builds. The footer stamp is generated from the deployed commit, so what you're looking at can always be traced back to a specific change.
• Security headers on every response. Content Security Policy, HSTS with preload, frame and MIME protections, and a restrictive permissions policy.
• Accessibility as a build rule. WCAG AA contrast across both themes, skip links, landmarks, keyboard-navigable menus, and alternative text that describes rather than labels.
• Documented as it's built. Decisions are written down at the time. Documentation written months later is fiction with footnotes.

I'm not about to start calling myself a developer. What I've got out of this is a working understanding of how agents behave when you give them something real, what they need from you to be useful, and where the human has to stay in the loop. That understanding is very hard to get from a conference talk.

None of it is theoretical any more, which is the point. When the question arrives at work, and it will, I'd rather answer it from something I've actually run than from something I've read about. Maybe not this year. Certainly soon.