Vibe Coding Came to WordPress — and Brought Its Holes With It
Back to Blog

Vibe Coding Came to WordPress — and Brought Its Holes With It

Projects don’t look like they used to

Something structural has changed in how WordPress work gets done, and Patchstack’s 2026 security whitepaper says it out loud: vibe coding is here to stay, and it’s merging with WordPress fast. Agencies generate plugins on request. Front-ends get written in React by a model responding to a prompt. WordPress itself increasingly plays the role of reliable plumbing behind an application that doesn’t look like classic WordPress at all.

We know this picture from the inside. AI-assisted development has changed our own workflow, and we’ve covered tools like CodeGraph that make coding agents cheaper and faster by handing them an actual map of the codebase. This isn’t a lecture about the good old days of writing PHP by hand.

But the same report attaches a price tag. AI-generated plugin code is introducing fresh vulnerabilities into the ecosystem, and the attack surface of a modern WordPress site has grown well past the familiar core-plugins-themes triangle. Every generated endpoint and every prompt-produced integration is code that someone will eventually have to answer for, usually at an inconvenient time.

How generated code fails

In our experience it doesn’t fail randomly. The same few patterns keep showing up.

The most dangerous one: it fails while looking correct. A model will hand you an upload handler or a database query that reads like it came out of a textbook, and the missing piece is invisible unless you go looking for it. No capability check. No nonce. Input that never got sanitized because the prompt never mentioned attackers, and prompts rarely do. The person asked for “a form that saves to the database” and got exactly that, nothing more.

Then there’s accumulation. One generated component gets reviewed properly. Forty of them, produced across different sessions with no shared context, interact in ways that none of those sessions ever saw. What you get is a set of ordinary integration bugs in code where nobody ever designed the integration.

And a side effect the report singles out: the flood of AI-generated vulnerability reports. Security teams are drowning in machine-written “findings” of dubious quality, which means a genuine report about your genuine bug now has to fight for attention with thousands of hallucinated ones, and the whole disclosure process slows down accordingly.

Our rules for this

They are simple, and we hold them fairly strictly.

Every line that ships has a named developer who reviewed it and can explain what it does. If nobody on the team can walk you through a function, that function doesn’t go to production, regardless of who or what typed it.

Security review happens as its own pass, separate from “does it work” review. Different questions, different reading mode. Generated code goes through both.

Generated code gets no special treatment either way. Sanitize input, escape output, check capabilities, verify nonces. Nothing on that list changes because a model produced the first draft.

And everything the AI produced is on the inventory. Untracked generated code is this decade’s version of the forgotten test plugin from 2019, the one that ends up in the incident report.

The agencies that get burned in this transition won’t be the ones using AI; everyone will be using AI. It’ll be the ones who mistook generation speed for delivery speed and let the review discipline slide.

Author: Valentyn
Share this post
Book a call
Contacts

    Tell us about your project — we'll get back to you within 24 hours.

    replies within 24h

    Thank you!
    Thanks for your email — we will get back to you shortly.