2026 is the year I started running AI agents. Not chatting to an assistant, running them: two or three Claude Code sessions most evenings since the end of May, one building, one reviewing, one talking to me. I’ve been a blogger and kept websites going for years, and I’m now far more capable at it than I’ve ever been, at home and at work. We can build almost anything. We are the directors of AI, and we guide it with our ideas and our feedback.
This post is what that looks like in numbers, what it built, how the work is gated so nothing reaches a live site without me, and what went wrong along the way.
Why I Leaned In
Early this year I was told that if I don’t use AI, I’ll lose my job eventually. I believe that’s true for everyone. I wasn’t too worried, because I’d already been ahead of the game through a passion for it and a determination to keep up with the latest technology. I knew it was a game changer.
At work I use AI every single moment, and I have to pause sometimes to make sure I’m still making the right decisions along the way. It saved my bacon when the team’s capacity dropped. I wouldn’t have coped without it, and I wouldn’t have delivered my projects without it. If AI went down now, it would be a priority 1 issue for productivity.
At home it’s the same tools, pointed at my own websites, and it’s also how I learn. Claude writes the SQL or PowerShell and stages the test for me. I run it on my own lab server, watch it work, critique it and take the screenshot along the way. With the setup done for me, my time goes on the new feature itself, and that’s how I keep ahead with the latest features in the software I use at work.
What the Numbers Say
Somewhere in August I stopped being able to say how much of it I was using, so I had a small script built to total the session transcripts: messages and tokens by day, week and model, priced at API list rates. Those dollars are a yardstick for how hard the machine is working, not a bill. I’m on a subscription.
| Period | Messages | Tokens | At API price |
|---|---|---|---|
| 8 Jul to 6 Sep | 29,225 | 10.7 billion | $6,727 |
| 6 Oct to 9 Nov | 21,267 | 5.1 billion | $1,836 |
| Since May, Claude’s estimate | about $11,000 |
The estimate is Claude’s, not a measurement. Claude Code deletes its transcripts after 30 days unless you tell it otherwise, so for the September gap and everything before July, Claude worked from my commit rate and the cost per commit in the two measured windows, and came out between $10,000 and $11,700. Call it $11,000 of compute for a few hundred pounds of subscription.
Two things make numbers like that survivable. 98% of the input is cache reads: the same conversation goes back to the model every turn, and the cache charges a fraction of the full rate for it. And the work has changed shape. August was building, so it was the peak. Since then most of it is checking and improving what exists, which costs less than writing it, and most of it now runs on Claude Opus 5.5.
What We Built
One day this month shows the pace. My West Highland Way series got updated with my maps built from Ordnance Survey terrain data and the national park’s official camping zones, the old photo area of this site was retired behind 20 redirects without a single broken link, and six posts were released, all in one day.
How We Gate the Work
Agents are fast. The speed isn’t the interesting part, the gates are. Everything the agents produce passes through the same path before it reaches a live site, and the last gate is always me.
A Place for Everything
It all lives in one folder on my machine, and every session starts by reading the map of it.
The Dashboard
I run it all from a small local website I call the internals. The files are the truth and WordPress is only the window: tasks for each site, things waiting for my eyes with a before and after, an ideas list and the rulings I’ve made, each a plain file the agents read and write. When I click approve, send back or leave a note, the click lands in an inbox file and the next session acts on it. A work log beside it shows me what to push, what to read and which screenshots to take.
The Release Path
- Staging firstEvery change lands on a copy of the site running locally in Docker. I get a staging link, never a wall of text.
- Checks before I see itA text diff proves my words are unchanged, screenshots at phone and desktop width, every link checked, no placeholders, no hidden notes, and nothing that names my family, friends or colleagues.
- I run it for realFor the technical blog, Claude writes the SQL or PowerShell and a short test plan. I run it on my lab server, watch it work, critique it and take the screenshot that goes on the page.
- I read itApproval means I read it. Small fixes like alt text or spacing are approved in bulk and listed, so nothing slips through unseen.
- Dry runEvery push script runs read-only against the live site first and reports exactly what it would change. The dry run and the real run are never chained in one command.
- I run the commandOne command per release, run by me. The script saves a copy of each live page before writing, reads every write back, and stops at the first failure.
- Purge and verifyI clear the cache, then the agent checks the live site as a visitor: redirects, images, and anything left over from staging.
- Live, with a rollback copy of every page it touched.
The rules that hold it together
- No site-wide changes. Everything goes page by page.
- Count before you change a component. A pattern on one page is a proposal, not a standard.
- Write down what would make a number meaningless before trusting it.
- Nothing is deleted without a look and an explicit yes from me.
- When I say something feels off, check it before explaining why it isn’t.
What Went Wrong
A fair amount, and the record of it is the most useful part of the workspace.
The console on this machine uses an old Windows code page. Any script that prints a character outside plain ASCII, an arrow or an emoji lifted out of a WordPress excerpt, dies with an encoding error and takes the rest of the batch with it. Three separate sessions hit it in one morning, five times between them, before it became a written rule.
A file open for writing is truncated before the write happens. One evening a bad character in the string being written raised an error after the file was already empty, and the main state file for the whole project went from 424 lines to zero. It came back from git in a minute. A file that was not in a repository would have been gone. Every write now goes to a temporary file first and is swapped in afterwards, and that pattern saved a second file the same night.
An agent produced a full findings report on search traffic. Every number in it was computed correctly from the raw exports. It had also been computed over a seven day window taken while both search engines were mid-reindex after a month of renames, and the report’s own caveats said so. It was correct and worthless, and it was thrown out. The lesson that stuck was not about accuracy. It was that nobody had written down what would have to be true for the number to mean anything.
The site migration in July cost about 40% of Bing’s weekday clicks, from 87.7 a day in June to 52.3 in July. That figure gets quoted now before anyone proposes another site-wide change.
One night, eight numbers stored in the planning documents were checked against the live site. All eight were wrong, in both directions. A security scanner ran green over 270 commits in the public repository until someone planted a fake secret to see whether it would fire. It did not. It had been running zero rules.
And writing this post turned up one more. The usage script reads the transcripts, and Claude Code had quietly deleted everything older than 30 days, so everything before October was gone before anyone thought to keep it. The September figures only survived because they were written into the first draft of this post.
The pattern in all of these is the same. The machine did what it was asked, quickly, and the failure was in what it was asked or what it was trusted with. The fix each time was a written rule and a check that can fail, not a better prompt.
If I Started Again
Knowing what I know now, this is the advice I’d give anyone starting the same thing from scratch.
Build the release path first. Staging, a dry run and a final human check before anything else. Every shortcut taken before they existed had to be cleaned up later.
Write every mistake down as a rule. The agents don’t remember last week. A written rule does, and it’s loaded into every session from then on.
Keep a save file. One file that says where things are, what’s waiting and what comes next means any session can pick up the thread, including one that has never seen the work before.
Put everything in git, and make every change reversible. Back up before writing, read every write back, and keep a rollback copy. Mistakes become a minute of work instead of a lost evening.
Measure from day one. Keep the transcripts and log what it costs, before you need the numbers. Most of this post had to be estimated because nobody thought to.
Don’t trust a green check until you’ve seen it fail. A scanner that’s never caught anything might be running no rules at all. Plant a problem and watch it fire.
Go page by page. An agent can change a thousand pages in an evening. That’s exactly the reason not to.
Stay the director. Review the real page, not a wall of text, and keep the decisions that are yours: what’s worth building, what’s good enough, and what sounds like you.
Give yourself something to look at. A staging page, a screenshot or a dashboard, not a scroll of terminal output. If you can see it, you can judge it, and you can tell when something is off.
Directors, Not Typists
One night the last message I sent before bed was a list of things I wanted from a shoutbox for this site, and then two words: impress me. By the morning, the shoutbox was built.
The real bottleneck was never the machine. It’s the ten minutes I have to look at a staged page, take a screenshot on a real server, or answer a question only I can answer. The agents wait on that far more than I wait on them, and that’s how it should be. They build, check and report. I decide what’s worth building, what’s good enough to go live, and what sounds like me.
That’s the job now, at home and at work. We are the directors of AI, and we guide it with our ideas and feedback.
If you’ve got an idea you’ve been sitting on for years, this is the year to build it. You don’t need to type every line any more. You need the idea, the taste to know when it’s right, and the habit of checking the work.
Try it yourself
Everything in this post was built with Claude Code, Anthropic’s coding agent. It runs in your terminal, works on your own files, and starts on the Pro plan.
Leave a Reply