In Part 1, I wrote about the week that turned a routine WordPress task into something unexpected. By Friday evening I had a working local development setup for Caleb’s site, a Git repository with a clean child theme, and a SETUP.md document that described how to reproduce the whole thing. Claude Code had done the heavy lifting, and I was genuinely impressed.
That was on my desktop machine. Today — Monday — I’m on my laptop, and the question is: does any of it actually work when you take it to a different machine?
The Short Answer
Yes. The local site is running on this laptop. Theme, uploads, database — all copied across using the instructions we wrote on Friday. It took minutes, not hours. That part went well.
But the more interesting story is what happened before I got to that point, and what it taught me about the way I’d been working.
Claude Goes Offline
Today, I sat down to try the setup on my laptop. I opened a terminal, pulled the latest code from GitHub, created a fresh LocalWP site, and reached for SETUP.md.
The document was clear about what needed to happen — copy the child theme here, copy the uploads there, drop the database and reimport. But the actual commands? They were written as descriptions of what Claude would do, not as things I could run myself. Step 2 was literally “Claude does this (automated)”.
And Claude Code’s service was offline.
I knew I needed to copy directories. I knew roughly where they needed to go. But I wasn’t quite sure about the syntax — trailing slashes, recursive flags, the kind of thing you get wrong once and then spend twenty minutes figuring out what went where. So I ended up asking a completely separate Claude (via my SiteGround hosting subscription) for help with the copy commands. It suggested using `rsync` instead of `cp`, which turned out to be the better tool anyway.
I got through it. But the experience left a mark.
The Over-Delegation Problem
Here’s the thing I hadn’t fully appreciated: when you let an AI agent handle all the mechanical work, you end up with documentation that describes a collaboration, not a procedure. The SETUP.md from Friday was written for a world where Claude is always available. It was a briefing document, not a manual.
That’s fine when the service is up but, like any technology, it only works when it’s working.
This isn’t a complaint about Claude Code — the tool is remarkable and I’m still getting my head around what it can do. It’s more of a realisation about my own habits. I’d been so focused on the efficiency of the human-AI workflow that I’d forgotten to ask: could I do this on my own if I had to?
The answer was “sort of, with help from another AI chat.” Which is better than nothing, but not where I want to be.
Fixing the Documentation
So later today, with Claude Code back online, the first thing we did was rewrite SETUP.md. Every step now has copy-pasteable commands — `rsync` for the file operations, the full MySQL incantation for the database import, and the `find` commands you need to locate LocalWP’s bundled MySQL paths (which are buried in Application Support and change with every version).
The document still works as a Claude briefing — there’s a prompt at the bottom you can paste into a new session. But it also works as a standalone guide. If the service goes down again, or if I’m on a machine without Claude Code, I can follow the steps myself.
It sounds like a small change. Rewrite some documentation. But it represents a shift in how I’m thinking about this workflow. The AI isn’t a replacement for understanding — it’s a multiplier. And multipliers are only useful if the thing they’re multiplying isn’t zero.
Tidying Up
While we were at it, we also did some housekeeping:
The repo had a redundant theme directory — `twentytwentyfive-child-caleb` sitting alongside the real one, `twenty-twenty-five-child-caleb`. (The difference is hyphens. WordPress naming conventions are a joy.) It was an empty skeleton left over from earlier experimentation. Deleted.
There was no README at the top of the repository. I’m absent-minded at the best of times and so, for a project I might not touch for weeks, that felt like a gap. So we added one — project overview, links to the live site and staging, directory structure, pointer to SETUP.md. The kind of thing that makes you grateful to your past self when you come back to a project cold.
Everything committed, pushed to GitHub. The repository is now in a state where I could hand it to someone (or to future me) and they’d know what they were looking at.
What I’m Taking Away
Friday was about building something. Today was about stress-testing it — moving it to a different machine, discovering the gaps, and making it more robust.
The local setup works. The documentation now stands on its own. The repo is clean. I can leave this project for a while and come back without having to reconstruct the context from memory.
But the bigger lesson is about the relationship between automation and understanding. It’s tempting to let the agent do everything — it’s fast, it’s capable, and it gets things right more often than not. But if you can’t retrace the steps yourself, you haven’t really learned anything. You’ve just watched someone else work.
I’m still figuring out where that line sits. But at least now I know to look for it.
Leave a Reply