The line going around now is that vibe coding is over and spec-driven development is what professionals do instead. Mariya Mansurova ran that experiment on Towards Data Science, building a working fitness app in about four and a half hours by writing a constitution first, then steering the agents against it.
I agree with the direction. My problem with the writeups, hers included, is that they are greenfield demos. Client WordPress work is almost never greenfield. It is a WooCommerce store with eleven plugins, a page builder, and order data living somewhere the agent never checked. On that kind of codebase the spec does a different job. A new project spec says what to build. A spec for an existing site has to say what is already true.
What breaks when the spec lives in chat
You fix a checkout totals bug by iterating in chat for an afternoon. It works, you deploy. Six weeks later something else needs to change in the same area, and the reason you rewrote that meta lookup is gone, because agents are stateless and the chat scrolled away. The source article calls this context decay, and it is a real limitation of the vibe coding loop.
On WooCommerce sites there is a second failure that costs real money: agents write plausible code against a stack that does not exist. They invent functions, or query wp_posts directly for order data on a store where HPOS moved orders into custom tables. That code can pass a quick diff review, and the store quietly reports wrong numbers.
The usual fix is a longer context window or a more careful prompt. That doesn’t hold up, because chat history isn’t durable storage. The repo is. So write the decisions into the repo.
What spec-driven development pins down on a store you inherited
The workflow from the article is a specs directory with mission.md, tech-stack.md and roadmap.md, committed next to the code and updated as the project moves. On an existing site, tech-stack.md does most of the work, and it should be written from facts you checked, not from memory. Run wp plugin list –status=active, confirm the WordPress and WooCommerce versions, and check whether HPOS is on (I have not tried this on multisite yet, where the table layout question gets messier). Then pin the constraints:
# specs/tech-stack.md (excerpt)
- WordPress 6.7+, PHP 8.2, WooCommerce 9.4+
- HPOS is enabled. Order data lives in custom tables, never wp_posts.
- Read orders with wc_get_orders() or the Orders REST controller.
- Custom code goes in the bbioon_-prefixed plugin, not the theme.
- No direct SQL without a documented reason in the spec.
- Totals shown to the client come from WooCommerce APIs, not hand-rolled queries.Now any agent that opens the repo gets the same ground truth, and the file doubles as documentation for the client. Treating guidelines as plain-text agent memory rests on the same idea, that text in the repo outlasts history in a chat. If you want the scaffolding done for you, GitHub’s Spec Kit packages this whole loop as slash commands.
Write the validation checks down too
Each feature phase in the source ends with validation.md, a written definition of done. For store work that is where you force the boring checks into text: guest checkout still completes, cached product pages still update, admin order totals match what the new code reports. Then let a second agent with fresh context verify the implementation against the plan before you merge.
The article gets one warning right. When something breaks, the tempting move is to explain the bug to the agent and grab the patch. Update the spec first, then fix. Skip that and the specs drift until they describe a project that no longer exists.
And the advice is wrong for some jobs. A one-line CSS fix or a small template tweak does not need a plan, requirements and validation documents. The source admits this too. Run the full process for features, skip it for tweaks.
This week on a client site I would add specs/tech-stack.md with verified stack facts and nothing else, then rewrite the next change request as validation checks before an agent touches code. It is a short setup that pays off on the second feature. If you want a specs folder set up for your store, or a review of what an agent already shipped, that is work I do.
