AI-generated code has gotten good. That’s not really in dispute anymore. Ask a model to build you a comparison table, a lead form, a small internal tool, and it’ll hand you something functional in a few minutes flat.
But functional and deployable are two different things, and the gap between them is where most of the risk actually lives. I’ve watched this play out twice recently in ways that had nothing to do with the AI writing bad code. In both cases, the code was fine. The problem was that nobody, including the AI, had accounted for where it was actually going to live.
The HTML Block
The first case was straightforward: someone pasted an AI-generated page straight into a WordPress HTML block instead of building it through the page builder already running the rest of the site. It looked right on a desktop screen. But it had no relationship to the site’s actual styling system, so the moment anything changed globally, like a font update or a spacing adjustment, that page just sat there, frozen and disconnected from everything around it. It also couldn’t be edited visually by anyone else, which meant the only way to change it later was to open it up and read through markup that nobody had written with a second reader in mind.
The deeper problem is that the site now has two competing styling systems fighting over the same page. The theme already has its own set of styles running underneath everything. The AI-generated page brings its own complete set on top of that, since it has no way of knowing the theme’s styles exist. So instead of one clean set of instructions telling the page how to look, there are now two, and the AI-generated code has to keep overriding the theme just to look the way it’s supposed to. That’s how you end up with a page that’s effectively carrying double the codebase it needs, most of it just there to fight the other half into submission.
None of that is a knock on the AI. Asked to write a webpage, it wrote a webpage. It had no way of knowing it was being dropped into a system that already had its own styling logic, its own update mechanism, its own conventions for how pages get built and maintained.
The Tool
The second case was more interesting. A client wanted a small tool built and had AI generate it, then wanted it dropped directly into their WordPress site. The code itself was reasonable. But it had been written as a standalone script, with no awareness that it was headed for a WordPress environment at all.
That’s the part that matters. A tool like that should have been built as a WordPress plugin from the start; something that hooks into WordPress’s own update and security model, instead of sitting on top of the site as an orphaned piece of code that nobody’s tracking. The difference between those two isn’t visible if you don’t already know what you’re looking at. It just looks like “code that works” either way, right up until it doesn’t.
The Actual Skill Now
This is the part I think gets missed in a lot of the conversation about AI and coding: the hard part was never really writing the code. It’s knowing what environment that code is going to run in, and making sure what gets built actually fits it, before it goes anywhere near a live site.
AI doesn’t know your platform. It doesn’t know your theme, your hosting setup, your plugin architecture, or the fact that the thing you’re asking for has a “right” way to be built for the system it’s landing in. It’ll give you an answer to the question you asked. It won’t tell you that you asked the wrong question, or that the same output needs to be structured completely differently depending on where it’s going.
That’s not a knock on the tools. I use them constantly. It’s just a reminder that “AI wrote it” was never the finish line. Reviewing what comes out, and understanding the context it needs to live in, still requires someone who knows the platform well enough to catch the difference between code that works in a vacuum and code that works on your actual site.