Vibe coding a WordPress site

What is vibe coding a WordPress site?

The phrase came from AI-assisted programming and applies cleanly to a live site. Vibe coding a WordPress site means describing the theme tweak or feature you want in plain language and letting an AI agent write, run, and debug the code for you — you steer with intent instead of typing the PHP or CSS yourself. You stay the author of what the site should do; the agent works out how.

How does it work with Cowboy MCP?

What separates this from a chat assistant that only drafts snippets is that the agent can apply and test its own code on your server. Cowboy MCP gives it roughly the reach a developer has over SSH, expressed as tools it can call in a conversation — write a file, run a command, read the log, try again — so the loop closes without you copying anything by hand.

In practice that loop looks familiar. The agent writes or edits theme and plugin files inside wp-content, runs WP-CLI to flush caches or run migrations, and reads your PHP error log to see what its change actually did. When a change throws a fatal or a warning, the agent reads the trace and fixes what it broke — the same edit, run, check cycle a developer follows, just narrated in plain English. Because file writes are confined to wp-content unless power mode is on, the blast radius stays inside your themes and plugins rather than WordPress core. The work ranges from a one-line CSS fix to a small custom plugin, and for layout it can drive the block editor or Elementor too.

Why isn't this reckless on a live site?

Be honest about this: it can be. Point an agent at a production database with power mode on and no checkpoint, and vibe coding is exactly as reckless as it sounds. What makes it sane on a live site is not the model being careful — it is a safety net you set up first, and it is worth knowing precisely where that net has holes.

The net has two layers. Every file the agent edits is captured in the undo journal as a full before-state snapshot, so a broken theme edit rolls back on its own from the Activity tab — you never have to remember what the file used to say. For anything the journal cannot invert, one-click database checkpoints restore your database tables to an earlier point, and an automatic checkpoint runs before mutating WP-CLI commands; if that auto-checkpoint ever fails, the failure is logged and the command still proceeds, so it never silently blocks your work.

Now the holes, plainly. Undo-journal entries are kept for seven days by default, so a rollback is a same-week option, not a permanent archive. Some actions have no inverse — a cache flush, a sent email, an arbitrary WP-CLI command — and the journal marks those not-undoable rather than pretending it can reverse them. And checkpoints restore database tables, not your uploaded files or code, so the real backstop for the code the agent writes is that file-level undo journal plus your own version control, not the database checkpoint. The security page documents each guardrail and where it stops.

What does a realistic first session look like?

The discipline that keeps vibe coding calm is unglamorous: small steps, verified one at a time. A good first session changes one visible thing, confirms nothing broke, and only then moves on. Here is that rhythm, start to finish, on a site you would rather not break — and it is the same rhythm whether the change is cosmetic or a new feature.

1. Checkpoint first. Ask for a database checkpoint before anything else so you have a clean point to return to: "Take a database checkpoint before we start." Auto-checkpoint already covers WP-CLI and updates, but a manual one costs nothing and buys peace of mind.

2. Ask for one small, visible change. Keep the first edit contained and easy to eyeball: "In the child theme's stylesheet, make the site title about 10% larger and change the link color to a darker green." The agent edits the file in wp-content and tells you what it changed.

3. Verify before moving on. Have the agent check its own work, and glance at the page yourself: "Reload the homepage and read the error log — did anything throw a warning?" A clean log and a page that looks right mean you are safe to continue.

4. Iterate or roll back. If it looks wrong, undo it and try a different instruction; if it looks right, ask for the next small step. "Undo that last change" reverts the file from the journal. Build the feature up one verified edit at a time, and the whole thing stops being a leap of faith.

FAQ