Building WordPress themes with Claude Code, honestly
What an AI coding agent is genuinely good at in a theme build, what it is bad at, and the review discipline that keeps the result something you would put your name on.
I build WordPress themes by hand, and I use an AI coding agent every day. Those two statements only look contradictory if you think the agent is writing the site. It is not. It is doing the part of the work that is repetitive, well-specified and boring — which turns out to be a large share of any theme build.
Here is where the line actually falls, after a year of using Claude Code on production work.
What it is genuinely good at
Migration and bulk transformation. Moving four hundred posts out of builder markup into semantic HTML, mapping custom fields, rewriting inline styles into classes. This is hundreds of identical judgements, and an agent stays as careful on item 380 as on item 3.
Audits. Walking every template at four breakpoints and reporting where a rendered heading takes more lines than the author intended. Checking every URL for a unique title and description. Diffing screenshots before and after a change. This is the work that gets skipped under deadline and catches the embarrassing bug.
Scaffolding against an existing pattern. Once one card component exists, the second and third are mechanical. The agent matches the file, the naming and the escaping conventions already in the codebase.
Repetitive edits across many files. “Add this nonce check to every handler”, “convert these six templates to the new helper” — precise, wide, dull.
What it is bad at
Architecture. Deciding what the content model is, where the seam between theme and plugin belongs, which two things are actually one entity. Those decisions have five-year consequences, and the agent has no stake in them.
Knowing when a requirement is wrong. Ask for a sticky form with a minimum viewport height and you will get one — including the version that disables itself on a 1080p screen at 125% Windows scaling, which is a real screen belonging to a real client. That is a judgement call about humans, not a coding task.
Restraint. Left alone it will add an abstraction you did not ask for. A theme with three subclasses where a function would do is worse than a theme with a function.
The review discipline
Three rules make the difference between assistance and slop:
- Nothing ships unread. Every generated line is reviewed by the person whose name is on the invoice. If that is too much code to read, it is too much code to have generated in one step.
- Lint and verify in the loop. Every PHP file gets
php -lbefore it is deployed. Every visual change gets a screenshot at 390, 768, 1440 and 1536×758. The agent runs those checks itself, which means the feedback arrives in seconds rather than at the end. - Write the constraints down first. The colour tokens, the type scale, the accessibility rules, the performance budget. An agent given a written standard holds it far more consistently than one given a vibe — and so, frankly, do I.
What it does not change
It does not change the standard. The same theme structure, the same escaping, the same WordPress coding conventions, the same measured contrast. If anything the standard goes up, because the tedious verification that used to be skipped now actually happens.
And it does not change who is accountable. When a client asks why something is built the way it is, “the AI wrote it” is not an answer anyone should accept — including from me.
The honest summary
An agent makes a one-person studio move like a small team, on the specific tasks that are wide and shallow. It does not make a one-person studio into a better developer. The architecture, the taste and the responsibility are still yours — and clients can tell the difference, usually within one page of reading the code.
