Over the last two years I have watched people with no engineering background ship real products. Small SaaS tools, internal dashboards, automations that a company now runs on. AI handed a lot of people the exact part they were missing, and in plenty of fields the result has been good. More things exist now, and some of them are things a trained developer would never have bothered to build.
I want that on the record first, because the rest of this is going to read like the opposite.
WordPress themes and plugins went the other way. The same shift that opened doors elsewhere made this particular market worse, for a reason that has nothing to do with the model and everything to do with where the market already was.
The floor here was already low
The theme and plugin market has never been known for engineering standards. I say that from about ten years inside it, shipping items myself and leading teams that shipped a great many more.
There are reasons for it, and I mean them as explanation rather than defense. The market is enormous, so anything that sells at all gets copied within a month. The entry bar was always the lowest in commercial web development. And the stack gives you very few places where architecture even becomes visible: procedural PHP, a pile of hooks, one template file per view, some jQuery on top. You can build and sell a complete product without making a single structural decision, so nobody is ever forced to learn how to make one.
Before AI, getting in took something like six months. You needed some PHP, some JavaScript, HTML and CSS, and enough design sense to not embarrass yourself in a preview image. That was the whole filter. It was a weak one, but six months is long enough that most people who cleared it had watched their own code break and had to work out why.
Those six months are now about two days. AI did not create the problem in this market. It removed the last thing standing between the problem and the shelf.
What it looks like on ThemeForest
I still work on ThemeForest, partly, so this is not a view from the outside.
Every other theme that lands now carries the standard markers of AI design, the ones most people learned to spot over the past year: a gradient mesh behind the hero, a grid of rounded cards, feature rows with icons that would fit any product in any category, and demo content nobody would run a business on. You can tell within four seconds of opening the preview.
Two questions come out of that, and almost nobody in the market asks either one. The first is how these get approved. I wrote about the review process separately, and the short version is that it filters on whether the design happens to suit the person looking at it that day, not on what is under it.
The second is what the author gets out of it. Usually two or three sales. The item ranks nowhere, nobody needed it, and there is no version two because there was never a version one worth maintaining. Support tickets sit unanswered, since the person who shipped it cannot answer them. Nothing gets developed, because there is nothing there to develop.
- Typical sales
- Two or three
- Support
- Not possible
- Code review
- Never happened
It is a lot of tokens burned by people who were not careful before and can now be careless at industrial speed.
The description is the part it does best
So far this is an author problem. The part that makes it a buyer problem is the listing itself.
The same model that wrote the code writes the sales page, and of those two jobs the marketing copy is the one it is actually good at. So the item page reads well. The feature list is long, confident and correctly formatted. The description talks about the architecture in the voice of someone who understands architecture. The FAQ answers objections you had not thought of yet. Under all of it sits code that no human has read.
You can click through a demo, which shows you the design, and read a description, which shows you the writing. Neither of those is the product.
The product is the code, and the code is the one part of the listing a buyer cannot see.
Where this stops being about taste
Everything above is an aesthetic complaint until it reaches the code, and that is the point where I stop finding it funny. These are the categories that come up most often when I open one of these items. I am naming categories, not writing instructions for anyone.
- Input taken from a form or a URL and used without validation or escaping, which is SQL injection at the database and stored cross-site scripting in the admin.
- Admin actions and AJAX endpoints with no capability check and no nonce, so anything a subscriber account can reach, it can also trigger.
- Functions that are deprecated, or that do not exist at all because the model invented them, sitting beside patterns copied out of tutorials written in 2013.
- Scripts, fonts and libraries pulled at runtime from third-party CDNs, unpinned, with nobody watching what is served on the other end.
- File uploads, file writes and directory permissions handled loosely, on the assumption that only an administrator will ever reach that code.
None of that is exotic, and none of it is new. Patchstack counted 7,966 new WordPress vulnerabilities in 2024: 96 percent of them in plugins, 4 percent in themes, and seven in core itself. Cross-site scripting was almost half the list. 43 percent needed no login at all to exploit, and a third still had no patch on the day they were disclosed. WordPress is not the soft part. Whatever you installed on top of it is.
The rules that prevent most of this are published, short and free to read: sanitize what comes in, escape what goes out, and check a capability before doing anything on somebody’s behalf. A model will follow all three when it is told to. In this workflow nobody tells it to, because nobody knows the rules exist.
Why the code comes out this way
Two things stack here, and it takes both of them.
The first is the training data. There is a mountain of WordPress code in public and a lot of it is old: tutorials from a decade ago, plugins abandoned in 2015, forum answers that were wrong when they were posted and have been copied a few thousand times since. A model trained on that corpus reproduces the middle of it, and the middle of WordPress code is not safe. Ask for a settings page and there is a fair chance you get one that saves whatever it is handed.
The second is that nobody checks. Spotting the hole requires knowing what to look for, and that knowledge is precisely what got skipped on the way in. So the code is generated from an unsafe average and then reviewed by someone with no way to review it. Both halves have to fail before a vulnerability ships, and in this workflow both halves fail by default.
The people who pay for it
My sympathy in all of this sits with the buyers.
Somebody buys a $59 theme for a small business site. They do not know what a nonce is, and there is no reason they should. What they get is a site that works on launch day and, some months later, spam links in every post. Sometimes it is a defaced homepage instead. Sometimes the install starts sending mail, the domain reputation goes with it, and the host suspends the account. Then they pay a developer several times the price of the theme to find out what happened. That cost is never on the item page.
If you are inside the refund window when you work out what you bought, use it. That is what it is for.
What you can check before you buy
You cannot read the code before you buy it. You can read around it, and two things carry signal.
One is the changelog. A product somebody actually maintains has a boring history: small fixes, dated, spread over a long period, naming specific things. A single entry that says Initial release from eight months ago tells you what you are looking at, and so does a changelog written in the same confident marketing voice as the description.
The other is the comments. Ask something before you buy that cannot be answered out of the description: whether the theme loads anything from an external CDN, how the demo import treats content that is already on the site, which PHP version it is tested against. A specific answer means somebody knows the code. A warm, general answer means nobody does.
| Somebody is home | Walk away | |
|---|---|---|
| Changelog | Small fixes over months | One line, or none |
| Comments | Specific, sometimes no | Warm, vague, always yes |
| Author page | Few items, kept current | Nine themes, five months |
| Documentation | About this product | Generic WordPress help |
The longer version, the one you can work through item by item before checkout, is its own post.
This is not an argument against AI
I use these tools every day. This site is built with them in the loop and so is everything I ship. The tool is fine, and so are the people using it to build things that were out of reach for them before.
What changed is the distance between the person and the output. Building something used to take long enough that you learned a little about what you were building, and a rough kind of review happened by accident along the way. Now it does not, so the review has to be done on purpose, by someone able to do it. In this corner of the market almost nobody is doing that, and the sales page is polished enough that hardly anyone notices.
Last updated
