How AI Changed the Way I Do WordPress Development

I've been building WordPress and WooCommerce sites for a long time — the last 15+ years running a specialist WordPress and WooCommerce company, and the work predates even that. So when people ask what AI "did" to my development work, the honest answer isn't a number. It didn't make me ten times faster, and it didn't put me out of a job. What it changed was the shape of the day.

The repetitive parts got quicker. The judgement parts got heavier. I review more code than I used to, not less, and a fair amount of it I didn't write. This post is the straight version of what that looks like on a real WordPress project — where the leverage is real, where it's an illusion, and why the human in the review seat matters more now than it did before. I'm not selling a method here. I'm describing what actually happened to the work, including the parts that got harder.

What a client job looked like then, and what it looks like now

A typical piece of client work used to have a predictable rhythm. I'd read the brief, sketch the data model, write the plugin or theme code by hand, test it against the staging site, and hand it over. The slow parts were the ones everyone knows: the scaffolding WordPress demands before anything interesting happens, the escaping boilerplate, and the documentation I'd promise to write and then write last.

Now the rhythm is different. The agent and I start from the same brief, but the first hour is no longer mine — it's the harness producing the frame, the escaping boilerplate, the first pass of a function, and a diff I get to argue with. What that bought me wasn't less work. It was a different kind of work. The mechanical hour became a review hour, and the review hour is where the actual decisions live.

[OPERATOR INPUT — needed before publish]: One anonymised client example, before and after — what a specific piece of client work looked like before AI was in the loop versus what it looks like now. No client names, domains, logos, or data (redaction rules apply). (2–4 sentences)

The point of that slot is the lived version of the argument: the shape changed, not the size. A job that used to be "write it" is now "direct it, then read what came back carefully." Staging still gets tested by hand, the same as before — the agent doesn't get the final say on whether a thing is shippable, only on how fast the first version appears.

Where AI is genuinely good at WordPress

This is the part worth being honest about, because the honest version is actually useful. AI is strong at the parts of WordPress work where the shape is known and the job is to fill it in: the registration boilerplate for a custom post type, the repetitive escaping, a refactor that touches forty files the same way, the first draft of documentation, and the PHPUnit scaffold for a class.

It's also genuinely good at the "I know what I want but I don't want to type it" cases — generating the second implementation of a pattern you've already written once, or proposing the diff for a change that's mechanical but spread across the codebase. On a WordPress site with a known convention, that speed is real and I use it daily.

What it is not is a replacement for knowing the platform. It's a fast pair of hands that has read a lot of WordPress code. That's a real thing to have on a team. It is not the thing that decides whether the change is correct for the site it's landing on, and pretending otherwise is how sites ship broken. When a convention is ambiguous, the model picks the one it has seen most, which is not always the one the site needs; that gap is mine to close, and closing it is real work, not a formality.

Where it falls over: platform conventions and the word "why"

The weakness shows up in a consistent place. Anything that depends on why — why a given site runs a particular configuration, why a legacy pattern exists, what a real client will actually do with a setting they don't fully understand — is exactly where the output gets plausible and wrong.

Multilingual WordPress is the cleanest example, and I know it from the inside. Getting multilingual right is a systems problem, not a strings problem: it touches the database, the permalink structure, the way meta is stored, and the translation plugins' own opinions about all of the above. I work on MSC Translation Health (anom-010), a WPML/Polylang integrity scanner, for exactly this reason — because this is where WordPress gets hard and where a generated answer that "looks right" most often isn't. The scanner exists because the multilingual layer is a real discipline, not a translation lookup.

So when the brief is "make this multilingual," AI can produce something that renders. Whether it holds up when a client switches a locale or a plugin updates is the part that still needs the person who has shipped for multilingual clients. The agent can't know the site's actual history, and it can't know the client.

Security review is its own discipline

I'll be blunt: "the agent wrote it" is not a security review. A first pass that looks clean can still carry a subtle issue — an escaped-but-wrong context, a capability granted where it shouldn't be, a nonce check that's present but in the wrong place. The judgement load went up here, not down, because I'm now reviewing code I didn't author, and authored-by-me used to be the thing that made review fast.

This isn't only about WordPress plugins. The same principle shows up in how I let agents touch WordPress data at all. In the Bishop harness, the bishop-memory MCP adapter exposes exactly 8 tools, with agent identity composed as <BISHOP_HARNESS>:<agent>, and it deliberately exposes no raw SQL and no arbitrary file-write tools. The service remains the policy boundary and audit point — the agent can ask, within a narrow surface, but it can't rewrite the database or the filesystem on its own say-so. That's the shape of the discipline: the tool is built so the safe path is the only path, and the human remains the one who can widen it.

If you take one thing from this section, take that: the review gate isn't a step you add after the agent writes code. It's the reason you can let the agent write code in the first place.

Performance when the first pass isn't yours

Performance work has a particular flavour now. When the first pass is generated, I don't get to assume the author knew the site's hot paths. So the first move is to measure before touching anything — profile the query, check the autoloaded options, look for the N+1 that a plausible-looking loop hides.

The risk with generated WordPress code is that it's usually correct enough to ship and slow enough to hurt. A meta query that works on a dev site with twelve posts can fall over on a production site with forty thousand. The reviewer's job is to catch the regression before the client does, which means treating performance as a first-class review item, not a thing you'll "look at later."

This is another place the load went up. I'm not reviewing my own careful code; I'm reviewing someone's first draft who happens to be very fast and has no stake in the site's uptime. The standard I hold it to is the same standard I'd hold my own work to — which is the whole point of keeping the human in the loop. Caching layers deserve the same suspicion: a generated object cache that returns the wrong key under concurrency is the kind of bug a quick read misses and a client finds first.

The new technical debt is code nobody wrote

There's a specific kind of debt you collect from generated code, and it's different from the old kind. The old debt was code someone wrote under pressure and meant to clean up. The new debt is code that is plausible and unexplained — it landed, it passed review on a quick read, and now nobody on the team can fully say why it does what it does.

It's tempting to treat a green check as understanding. It isn't. A review gate helps, but it doesn't eliminate the problem, because the gate is also a human reading fast. The mitigation I trust is boring: keep the surface small, keep the diffs reviewable, and treat "I'm not sure what this does" as a failing grade, not a TODO. Generated code earns its place by being explainable, not by being present. A diff I can explain to a colleague in one sentence is worth more than three I can't, and that bar hasn't moved just because the code arrived quickly.

The multilingual case comes back here too. A generated multilingual layer that "works in testing" can accrete debt faster than almost anything, because the failure modes are subtle and the person who'd catch them is the same person the agent was supposed to spare.

Talking to clients about it honestly

This is the section people will actually share, so I'll be direct. Clients don't care, mostly, whether a function was written by a human or an agent. They care whether the site is correct, fast, secure, and delivered. So the honest framing is not "I used AI" or "I didn't" — it's that the work is reviewed to the same standard either way, and the person responsible for the outcome is the same person it always was.

[OPERATOR INPUT — needed before publish]: A straight answer on how you handle disclosure with clients — what you tell them about AI-assisted work, and where you draw the line. This is the shareable section; keep it plain. (2–4 sentences)

The reason to be straight about this is also commercial. The agencies that will get burned are the ones that let "the agent did it" stand in for "a qualified person checked it." I'd rather a client know the workflow and trust the reviewer than be sold a mystery. Where I draw the line is simple: an agent never becomes the accountable party, and I don't bill AI-assisted work as anything other than work I stand behind.

Where I think this goes for WordPress professionals

My read, and it's a forecast not a promise: the WordPress professionals who do well in the AI era won't be the ones who generate the most code. They'll be the ones who built the review discipline, the scaffolding, and the policy boundary that let an agent be useful without being unchecked.

The leverage is real but it lives upstream of the code — in the bootstrap, the guidelines treated as build-time instructions, the security gate, and the honest conversation with clients. The catalogue and harness work I've written about in the other milestones is the same idea from different angles. AI changed the shape of the work more than the amount, and the people who thrive are the ones who noticed that the shape, not the volume, was the thing worth getting right. The agencies that treat the agent as a cost centre and the reviewer as the product will look very different in two years from the ones that treated the agent as the product.

Get in touch

If you want help setting this up for your team, get in touch.

The next milestone in the writing queue is M5 — What AI Gave Me, on the things AI gave me that weren't code. It's on the list, not yet published, so I won't point you to it as if it exists.

If you want the groundwork first, M1 — How I Actually Work With AI — and M2 — Building Bishop: an AI agent harness for real development work — are both live. The Building Plugins With AI milestone (M3) and the six posts in the WordPress in the AI Era series — security review with agents, Performance Work When the AI Writes the First Pass, MCP and the WordPress Abilities API, Explaining AI-Assisted Work to Clients Honestly, technical debt in AI-generated codebases, and Why Multilingual WordPress Is Still Hard for AI — will link in once they're published.