We’ve now inherited enough AI-built WordPress sites, including plenty running WooCommerce, to see the pattern clearly: the surface looks fine, and the code underneath usually doesn’t. There’s a term for this now: code slop, work that passes the eye test without reflecting any real understanding of why it’s built the way it is. This isn’t a case against using AI in development. It’s an honest account of what we actually find when we open the hood: the specific problems, why they happen, and what they cost to fix.
Why this is worth writing about
We’re not writing this to argue that AI can’t be useful in development. It can. We use it ourselves. We’re writing it because there’s a real gap between what an AI-assisted build looks like from the outside and what it looks like once someone who knows WordPress and WooCommerce deeply actually opens it up.
Business owners who had a site built through AI tools, or by a developer who leaned heavily on AI code generation, often don’t know what they’re sitting on until something breaks, someone tries to extend the site, or a new developer runs a proper audit. By that point, fixing the foundation usually costs more than building it correctly the first time would have.
Pattern 1: Security basics are missing
The most consistent finding across AI-built WordPress sites is missing or incomplete security work. Three things come up over and over: data isn’t being checked and cleaned before the site processes it (input sanitization), data isn’t being made safe before it’s shown back to a visitor (output escaping), and there’s no check confirming that a form submission or button click actually came from a real action on your own site rather than something pretending to be one (nonce verification).
These are basic, foundational WordPress security practices, not optional extras. Skipping them creates real, exploitable weaknesses. AI models tend to write code that works when everything goes as planned: it handles clean, well-behaved input correctly, the way a store might only ever check IDs at the front door and never notice the back door is unlocked. Security is specifically about what happens when input isn’t clean, whether that’s an honest mistake or someone deliberately trying to break in, and catching that takes deliberate work that AI doesn’t do on its own.
Fixing this means going through every custom function, every form, and every background request on the site and adding the missing checks properly. On a site with a meaningful amount of custom code, that’s a real project, not a quick patch.
Pattern 2: Reaching around WordPress and WooCommerce’s own APIs
WordPress and WooCommerce both provide an official, supported way for code to read and write data: posts and users on the WordPress side, orders, products, and customers on the WooCommerce side. That’s how code is supposed to talk to your site’s information.
AI-generated code often skips this and reaches directly into the underlying database instead, essentially going around the front door. That approach happened to work for years, back when the data lived in one predictable place. But both WordPress and WooCommerce keep evolving how they store things internally. WooCommerce, for instance, has moved much of its order data to a newer, faster storage system (HPOS, which we’ve covered in detail separately), and code that was built to reach directly into the old structure now runs into reliability problems and can even lose or mismatch data.
It also leaves that code fragile in a way that isn’t obvious from the outside: it only keeps working as long as the internal structure never changes, and it does change. A routine update, to WordPress core or to WooCommerce, can silently break code built this way, often with no warning until something stops working.
Pattern 3: Plugin conflicts nobody tested for
AI-generated code doesn’t get tested against your actual site. It’s written and checked in isolation, or against whatever plugins the AI happened to be trained on. A real WordPress site runs dozens of plugins at once, and how they interact with each other only shows up through real testing.
We routinely find custom code that quietly conflicts with the SEO plugin, JavaScript that breaks because of a page builder, or, on stores running WooCommerce, custom order-status logic that silently breaks the built-in email system. None of that shows up in a demo. All of it shows up once the site is live and real visitors are using it.
Pattern 4: Performance decisions that were easy to build and slow to run
AI tools tend to solve a problem in whatever way is quickest to build, not necessarily the way that runs fastest. That usually shows up as: re-checking the database on every single page load instead of remembering the answer from last time (caching), loading every image, script, and style on every page instead of only the ones that page actually needs, and writing page styling directly into the code instead of into one shared, reusable file.
Each of those choices is reasonable on its own. Put together across a whole site, they add up to something that technically works but runs slower than it should, sometimes a lot slower. On a store, that slowdown starts to actually cost you money once it affects how many people finish checking out. On any WordPress site, it shows up as visitors leaving before the page even finishes loading.
Pattern 5: No error handling
A live WordPress site runs into errors constantly. A third-party service you depend on times out. A form submission arrives malformed. On a store, a payment processor sends back something unexpected, or a notification from a payment provider arrives out of order. Well-written code handles all of this gracefully: it records what went wrong, gives a useful response instead of a blank failure, and keeps one small problem from cascading into a broken experience for the visitor.
AI-generated code tends to handle the normal, expected situation well and everything else poorly. Code that talks to outside services often has no real plan for what happens if that service fails or responds strangely. On a store specifically, code that receives payment-provider notifications often fails silently, or with a vague error that’s hard to actually track down. On a small site, that’s manageable. On a busy site or store, it turns into a recurring problem that costs real time to chase down.
Pattern 6: Content generated outside the site’s design system
This last one isn’t about how a site got built originally. It’s about what keeps happening to a site afterward, even a well-built one, once someone starts generating pages or content blocks with AI on their own and pasting the resulting code straight into the site.
We see this constantly, and it’s usually not a developer doing it. A business owner asks an AI tool to build a landing page or a content section, and drops the code straight into a custom HTML block. The result usually looks fine sitting there on its own.
The problem is that it was built with no awareness of what the rest of the site already has, a lot like adding a room onto a house with its own mismatched paint and trim instead of matching the plans already in place. Whatever the AI generated, its own buttons, its own spacing, its own colors, exists as a one-off, disconnected from the design system (the shared set of colors, fonts, buttons, and components every other page on the site draws from). That means duplicate work today: a button or layout pattern the site’s theme almost certainly already has, rebuilt from scratch for this one page. It also means real trouble later. When the brand’s colors, fonts, or button styles get updated site-wide, that page doesn’t inherit any of it, because it was never built to. It quietly drifts further from the rest of the site every time anything else changes.
What doesn’t show up in a quick look is usually worse. Accessibility, which matters both for real visitors and for ADA compliance, tends to get skipped almost entirely: proper heading structure, color contrast, keyboard navigation, alt text on images. A well-built WordPress theme handles this consistently across the whole site. A one-off block generated by AI usually doesn’t account for any of it. The technical SEO fundamentals a real WordPress page normally gets close to automatically, like structured data (schema) that helps Google understand what the page actually is, tend to be missing too. None of this shows up when the page first goes live. It shows up gradually, as an accessibility complaint, or as a page that quietly never ranks the way the rest of the site does, and nobody connects it back to how the page was actually built.
It’s the same core problem as everything else in this piece, just showing up in content instead of code: something that looks fine on a first look without reflecting any real understanding of the system it’s dropping into.
What this means for AI in WordPress development
Used well, AI is a genuine productivity tool in WordPress and WooCommerce development. It speeds up the repetitive, common parts of a build and helps developers work through unfamiliar parts of a codebase faster. But the output still needs to be reviewed, tested, and reinforced by someone who actually understands what production-quality code requires, on either side.
The problem isn’t AI assistance itself. It’s AI used as a replacement for that expertise instead of a tool that expertise directs. A developer who doesn’t already understand the concepts covered above, why data needs checking, why database access matters, why error handling matters, won’t catch those problems showing up in AI-generated code. They’ll simply ship them to your live site. That’s the entire difference between a fast build and code slop: not the tool, but whether anyone with real expertise was actually steering it.
The same logic applies just as much when it’s not a developer at all. A business owner generating a page or a content block on their own runs into the exact same gap, just showing up as inconsistent design, missing accessibility, and quiet SEO damage instead of a security hole. The tool isn’t the problem there either. What’s missing is someone who understands the system well enough to know what the AI didn’t account for.
If a developer you’re evaluating mentions using AI in their process, that’s fine on its own. The better follow-up question is how they review and test what AI produces, not whether they use it at all.
| WORKING WITH BRIOFORGE Inherited a site you’re not sure about? If you didn’t build the site you’re running, whether it came from an AI-assisted developer, a previous agency, or a DIY effort, it’s worth knowing what’s actually underneath before something breaks or you need to extend it. We do this kind of audit regularly on WordPress and WooCommerce alike: what’s solid, what’s fragile, and what it would actually take to fix the parts that need it. If you’re not sure what you’re sitting on, get in touch. |
Frequently Asked Questions
How do I know if my WordPress site has security vulnerabilities in custom code?
A code audit by a developer who knows WordPress security practices is the most reliable way to find out. A security plugin like Wordfence can scan for known vulnerability patterns, but it won’t catch problems specific to your site’s custom code, whether that’s core WordPress functionality or WooCommerce-specific code. If your site has a meaningful amount of custom development, a focused security review is worth the cost.
Can AI-generated WordPress code be fixed, or does it need to be rewritten?
It depends on how much custom code exists and how deep the problems run. Adding proper security checks to existing code is usually doable without a rebuild. Replacing direct database access with proper API use is usually straightforward if those queries are contained in a few places. Fixing deeper architectural choices, like loading everything globally or having no error handling at all, tends to require more real rework.
Is it safe to add AI-generated content to my WordPress site myself?
It can be, if you keep it inside the tools your site already provides rather than pasting in raw code. Using AI to draft the text for a new page, then building that page with your theme’s existing blocks and styles, keeps you inside the design system and inheriting the accessibility and SEO groundwork already in place. The risk is specifically in generating a full HTML block independently and dropping the code in as-is. If you’re not sure which one you’re doing, that’s worth a quick check with whoever manages your site.
What should I ask a developer who built my site with AI tools?
Ask about their testing process, and whether they have a staging environment where they test against your actual plugin list. Ask specifically about security practices by name: input sanitization, output escaping, nonce verification. If the site runs WooCommerce, ask whether their custom code works correctly with HPOS. The answers tell you far more than whether they used AI in the first place.
