How I Use AI on WordPress Projects — Where It Helps and Where It Hallucinates

The short version

AI is great at the parts of WordPress that are small, isolated, and well-documented: a functions.php snippet, a custom block, a WP_Query, a stubborn regex. By default it's also blind to your site, the theme, the plugin stack, the data, the client's actual goal, so it will confidently invent hooks and functions that have never existed.

That blindness, though, is a choice, not a law. Give it the whole codebase and a local copy of the database and a lot of the gap closes: it can read your theme, see exactly which plugins and versions you run, and query real data instead of guessing. Hallucinations become much less frequent, because the model can verify its assumptions against the actual project. (That setup is the local site plus a custom MCP server I get into later.) That local DB copy still needs to be sanitized first, with customer emails, names, and order data stripped or anonymized, because “local” describes where the data lives, not whether it's safe to hand to a third-party tool.

It doesn't close the whole gap, though. A database and a file tree don't explain custom business logic, third-party API credentials, cron behavior, or deployment-specific config. A wp_get_environment_type() branch or a $crm->sync_customer() call means something the AI can't infer from the data alone. And the real ceiling is still judgment: the client's actual goal, and which of several working approaches is the right one here.

So I use it the way I'd use a quick, sharp junior dev. Hand it the contained tasks, give it as much real context as I safely can, read everything it gives back, and keep the decisions that need judgment for myself.

Where it genuinely saves me time

These are the jobs I reach for it on without thinking twice, because they're self-contained and I can verify the output in seconds.

• functions.php snippets. “Add a body class for logged-in users,” “dequeue this script on the checkout page,” “register an image size.” These are the same five lines of boilerplate I half-remember every time, and AI writes them faster than I can look up the hook name.
• Custom Gutenberg blocks. Scaffolding a block (the block.json, the edit and save functions, the attributes) is repetitive and easy to get slightly wrong. AI gets me a working skeleton I can then shape, which is exactly the kind of clean, block-first work I'd rather be doing than fighting a page builder.
• WP_Query and the loop. Meta queries and tax queries have a verbose array syntax that's easy to fat-finger. Describing what I want in a sentence and getting the argument array back is a real time save.
• The annoying small stuff. Regex for a redirect, an .htaccess rule, a one-off SQL query to fix a column in the database, a shell command I use twice a year. AI is good at the things I'd otherwise spend ten minutes searching for.
• Reading unfamiliar code. Inheriting a client's 4,000-line theme nobody documented? Pasting a function in and asking “what does this do and what calls it” is faster than tracing it by hand.

The more dangerous failure: missing security

A made-up hook fails loudly enough that you catch it. The more dangerous habit is the code that runs perfectly while leaving a security hole wide open. AI-generated WordPress code skips the safety rails constantly, because the unsafe version is shorter and the model is pattern-matching toward short. Four things I check on every snippet:

• Escaping on output. echo $_GET['name'] should be echo esc_html( $_GET['name'] ). Any value going into the page gets escaped for its context.
• Sanitizing on input. update_option( 'title', $_POST['title'] ) should wrap the value in sanitize_text_field() first.
• Nonce checks. AI-generated admin forms routinely forget wp_verify_nonce(), which is what stops a request from being forged.
• Capability checks. A privileged action with no current_user_can() in front of it will happily run for someone who shouldn't be able to trigger it.

These omissions show up far more often than a fully invented hook, and they cost a lot more when they ship. If you read AI WordPress code for one thing, read it for this.

The other quiet one: code that works but doesn't scale

AI writes code that passes on your test data and falls over on the client's real database. The two patterns I see most:

• N+1 queries. A query inside the loop, like a get_posts() or a fresh WP_Query per row, fires one database hit per iteration: fine for ten rows, a problem at ten thousand. (Plain get_post_meta() in a standard WP_Query loop is usually fine, because the query primes the meta cache up front. The trap is the extra query you add inside the loop.)
• Unbounded queries. new WP_Query([ 'posts_per_page' => -1 ]) loads every matching row into memory. On a big dataset that alone can take a page down.

The code is correct; it just doesn't scale. A senior dev spots this on sight. AI usually won't, unless you ask it to think about the query count and the row count up front. So I do ask, every time the snippet touches the database in a loop.

The AI content trap

Clients ask about this constantly: can we just generate the blog with AI? Google doesn't penalize content for being AI-assisted. It penalizes content that's unhelpful, no matter who or what wrote it. The damage comes from volume: spinning up forty thin, interchangeable pages that say nothing a reader couldn't get faster somewhere else.

A first draft or an outline from AI is fine. But a human still has to add the specifics, the real experience, and the point. Those are the things that actually earn a ranking. And thin pages do more damage than just not ranking: they bury the few pages that matter under a pile of filler. If you want the search side done properly, that's a separate job, and I wrote about it in SEO for WordPress with Yoast.

AI won't fix a bad foundation

The biggest misread I see is treating AI as a shortcut around doing the build properly. If a site is a tangle of page-builder shortcodes and twelve overlapping plugins, asking AI to “make it faster” gets you a band-aid instead of a fix, and often a snippet that conflicts with one of those plugins. The performance and structure problems were architectural before AI showed up, and they're still architectural after.

AI makes good foundations faster to build. It does not rescue bad ones. That's a big part of why I avoid page builders in the first place, and why the real WordPress performance wins come from the stack you choose, not a plugin you bolt on at the end.

Going further: a local site and a custom MCP server

Everything above is the AI working blind, guessing about a site it can't see. The next step is to let it see. Two pieces make that safe and surprisingly powerful.

Run the project locally first. Before AI gets anywhere near a client's install, I spin up a local copy with wp-env, LocalWP, or plain Docker. A local site is a throwaway sandbox: the AI can break it, I reset it, and production never feels a thing. This is non-negotiable for me. I don't point AI tooling at a live site.

Wire it up with a custom MCP server. MCP is a standard way to hand an AI assistant a set of tools it can call. A small MCP server wrapping WP-CLI or the REST API on that local install changes the whole game: instead of guessing whether a hook exists, the assistant runs wp eval and checks. It can run wp post-type list, wp plugin list, and wp option get for real context. Instead of guessing get_field('event_date'), it inspects the ACF field groups and confirms the field is actually event_start_date. The hallucinated-hook problem from earlier shrinks fast once the model is grounded in your actual site instead of a statistical guess about WordPress in general.

You can build that server in an afternoon: expose a few read-only commands first (run WP-CLI, query posts, describe a table), keep write access behind an explicit flag, and only ever point it at local or staging. Grounding plus a sandbox is the combination that turns AI from a confident guesser into a tool that's checking its work.

And it runs the other direction too. You can build AI into WordPress as a custom plugin: a server-side call to an LLM API for things like draft alt text, content summaries, or an internal editorial assistant. Keep the API key in wp-config.php, never in the browser, watch the per-request cost, and cache what you can. A focused plugin like that is a world away from bolting a generic “AI” add-on onto a page builder and hoping.

How I actually prompt it

Most “the AI gave me broken code” moments come down to a prompt that left out everything the model couldn't guess. So I front-load the context:

• Versions. WordPress version, PHP version, and the exact plugin and its version. A hook that exists in WooCommerce 9 may not in 7.
• Real data. A snippet of the actual markup, the real custom field name, the real post type, not a placeholder. It writes against what you give it.
• The constraint. “In a child theme, not the core files,” “without adding a plugin,” “has to work on PHP 8.”
• A doubt check. I literally ask it to flag any hook or function it isn't sure exists. It won't catch all of them, but it catches some.

And then I read it. A twenty-line snippet I understand is worth more than a two-hundred-line one I paste on faith — because when it breaks at 9pm before a launch, I'm the one who has to know why.