Everyone is losing their minds over agentic AI right now. If you have been doing WordPress work as long as I have, though, you know that speed without a spec is just a faster route to legacy code. The pitch is that you can Build an MVP with Claude Code over a weekend, and you can, but without someone watching the architecture you are mostly automating the creation of technical debt.
Claude Code is not another chat window, it is a terminal agent. It reads your files, runs your tests, and will happily execute wp-cli commands. It is still only as good as the developer holding the terminal. If you do not know the WordPress lifecycle, meaning the difference between a plugins_loaded hook and init, you will build something that falls over the first time a real user logs in.
Why build an MVP with Claude Code in 2026
The reason to Build an MVP with Claude Code at all is that speccing a product out fully by hand takes too long. Early in a startup, or early in a custom WooCommerce feature, you do not have weeks to spend on a clean codebase. You need to know whether anyone wants the thing. An agent lets you iterate at a pace that was not possible five years ago.
I have watched dozens of projects die after the owner spent $20k on a perfect build for a feature nobody wanted. Agents let you fail faster, and occasionally succeed faster. For how this fits the wider ecosystem, see my breakdown of the Essential WordPress 7.0 AI Client.
How I actually run it
I never open the terminal and ask it to “make a plugin.” That is how you get a security nightmare. I use three steps instead, and all three exist to keep stability ahead of vibe coding.
Step 1: the spec, written by hand
Before I touch the terminal I write a CLAUDE.md in the project root. That file is the project’s memory. It holds the tech stack, the coding standards (PSR-12, in my case), and the hooks I want the agent to use. Skipping it is not an option. If you do not set the constraints, the model invents its own.
Step 2: let the agent scaffold
This is the part that earns its keep. Rather than copy-pasting code out of a browser tab, I let Claude Code build the directory structure. For a custom REST endpoint on a WooCommerce MVP, the prompt looks like this:
/edit Create a new WP plugin directory 'bbioon-mvp-api'.
Add a main plugin file that registers a REST route at 'bbioon/v1/data'.
Ensure the callback uses wp_handle_sideload for security.
Include a basic PHPUnit test for the endpoint.Claude then uses the Claude Code CLI to write the files and, if you let it, run the tests. It keeps the context of what it just created, which closes a lot of the hallucination gap.
Step 3: the reality check
Testing is the slow part. I have had agents reach for $_POST directly with no sanitization. You are the gatekeeper, so go looking for bottlenecks. Is it calling get_posts where WP_Query belongs? Is it ignoring transients? Unsupervised agents also leave a codebase that smells, which I went into in why AI codebases smell sour.
Mistakes that kill a WordPress MVP
Scope creep gets people first. Claude Code makes adding a feature so cheap that you will want just one more thing. Don’t. Every line an agent writes is a line you maintain, and more code means more race conditions and longer debugging sessions later.
The other one is skipping human feedback. Claude is a strong coder and a useless product manager. It has no idea whether your checkout flow confuses people. Let the agent build the engine; work out the dashboard yourself, with your customers.
If this Build an MVP with Claude Code stuff is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days, and I know how to steer these agents toward something you can actually run in production.
What to take away
To Build an MVP with Claude Code without regretting it, treat the agent as a junior dev with infinite speed and no judgement. You supply the architecture, you name the hooks, and you never ship code you have not read. The official Anthropic documentation is worth reading alongside a strict spec of your own.
