Snippet plugins are the wrong home for AI-generated code

Snippet plugins are useful. I have used them for years. If you know exactly what code you are adding, understand the hook it runs on, and want a quick way to avoid creating a tiny plugin, a snippet manager is a perfectly reasonable tool.

AI-generated code changes the risk profile.

The problem is not that AI code is uniquely bad. Human code is bad all the time. The problem is that AI makes it easy for a non-developer to produce code that looks plausible, then paste it into a place where it runs with full WordPress privileges.

That is the dangerous part. Not “AI.” Privilege.

What a snippet can touch

A PHP snippet runs inside WordPress. That is the whole point. It can hook init, register shortcodes, alter queries, enqueue scripts, change output, call plugin functions, read options, update options, create users, delete posts, send email, and talk to the database.

Sometimes that is exactly what you need.

But when the code came from a chat window, the person installing it often cannot evaluate what those capabilities imply. They see “add this to your site” and a block of PHP. The site sees code running with the same broad process-level access as the plugin system itself.

JavaScript snippets inside the page have a different but still broad risk shape. A script pasted into a page can read and alter the DOM around it. It can conflict with theme scripts. It can grab form values. It can fetch to undeclared endpoints. It can break a page outside the little widget it was meant to power.

The failure mode is not theoretical. It is the default shape of the web: code on the page can affect the page. Code in WordPress can affect WordPress.

What AI makes easier

Before AI, most site owners did not write arbitrary code. They installed plugins. That was not risk-free, but there was at least a distribution surface: reviews, active installs, support threads, update history, a named author, a plugin team review process.

Now a site owner can ask:

Make me a mortgage calculator for my real-estate site.

And the model will happily produce HTML, CSS, JavaScript, maybe a PHP shortcode wrapper, maybe a REST endpoint, maybe a bit of code that stores submissions. It will look complete. It might even work.

The site owner then has to answer questions they are not equipped to answer:

• Is this code safe to paste into a Custom HTML block?
• Does the JavaScript leak data?
• Does the PHP sanitize inputs?
• Does it escape outputs?
• Does it run on every page?
• Does it create a public endpoint?
• Can it be used for spam?
• What happens if it throws a fatal error?

That is too much to ask of someone who wanted a calculator.

The DSGo trade

DesignSetGo Apps makes a different trade:

1. The app runs as a static bundle.
2. The default runtime is a sandboxed iframe.
3. The app cannot touch the parent DOM.
4. The app cannot see WordPress cookies or REST tokens.
5. The app talks to WordPress only through named bridge methods.
6. The manifest declares what the app wants.
7. The install dialog shows those permissions in plain English.

This is more constrained than a snippet. That is the point.

If an AI-generated app has a runaway loop, it can freeze its iframe. It does not take down PHP. If its CSS is sloppy, it styles its own document. It does not rewrite the site’s theme. If it tries to fetch from an undeclared origin, CSP blocks it. If it tries to read posts without asking for the posts permission, the bridge returns permission_denied.

The app can still be wrong. It can still be ugly. It can still fail. But the failure is contained.

Connection without privilege

The obvious objection is that snippet code is powerful because it can actually use the site. A sandboxed iframe sounds safer, but also isolated.

That is why the bridge exists.

The bridge gives the app task-shaped access to WordPress:

• dsgo.posts.list()
• dsgo.pages.get()
• dsgo.user.current()
• dsgo.user.can()
• dsgo.storage.app.get()
• dsgo.ai.prompt()
• dsgo.abilities.invoke()

Those calls are not raw privilege. They are mediated access. The parent runtime checks the manifest, checks the current visitor’s WordPress permissions, calls the right WordPress API, normalizes the response, and sends data back to the app.

That is the difference between “the code runs inside WordPress” and “the code can ask WordPress for specific things.”

For AI-generated apps, the second model is healthier. The model can build the UI fast. The runtime keeps the dangerous parts boring.

What snippet plugins are still good for

This is not a “never use snippets” post.

Use a snippet when the desired behavior is inherently WordPress-side:

• Registering a custom post type
• Changing an admin column
• Adding a small filter to alter plugin output
• Tweaking query behavior
• Disabling a theme feature
• Adding a short hook-based behavior you understand

Those are WordPress modifications. They belong in WordPress. A DSGo App is not a replacement for a tiny plugin when the thing you want is a tiny plugin.

Use a DSGo App when the desired behavior is an interface:

• A calculator
• A quiz
• A product configurator
• A dashboard
• A lead magnet
• A pricing tool
• A content browser
• A member portal
• A small app that reads site data

Those are app surfaces. They deserve app isolation.

The trust question

The core question is not “can this code run?” It is “what happens if this code is wrong?”

In a snippet manager, wrong code can become a site problem. In a DSGo App, wrong code should remain an app problem.

That distinction is what makes AI-generated code practical for WordPress. The output does not have to be perfect before you try it. It has to be contained, inspectable, and permissioned. The site owner needs a way to approve “this app reads posts and sends email” without also approving “this code can execute arbitrary PHP inside my site.”

That is the category line.

Snippet plugins are excellent for trusted WordPress modifications. They are the wrong home for untrusted, AI-generated app code. Put the interface in a sandbox. Give it a bridge. Make the permissions legible. Let WordPress stay WordPress.

Nealey