My theme rebuild is functionally done and I still will not deploy it. That sentence sounds backward until you understand what “done” actually meant here, and if you have ever shipped anything built partly by AI, you already know the gap I am talking about.
The original plan was a reskin. Claude Design came back with a UI different enough from the existing theme that a reskin stopped being honest. What I actually had was a full rebuild, new templates, new component structure, a picks system rebuilt from scratch to run off a table parser instead of a manual block pattern. That reclassification was correct. A reskin and a rebuild carry different risk profiles, and pretending one was the other would have meant testing it like the smaller job it was never going to be.
So here is where testing a vibe coded app actually gets interesting. This build was not AI writes it, human reviews it after. Claude Design produced the mockup. The theme got vibe coded from that mockup. I hand coded the parts that needed a real decision instead of a plausible guess. QA ran through all of it, not as a final gate but as something happening the entire time, three people’s worth of judgment compressed into one build cycle with nobody but me actually accountable for the result.
Why “It’s Built” and “It’s Ready” Are Different Claims
Picture a site pulling in a few dollars a day from ads and a handful of affiliate orders. Not much. Also not nothing. Now picture a UI bug in the one component that renders every product pick on the page. That’s not a rounding error anymore. That’s the entire mechanism the site depends on, dead on arrival, and nobody notices until the numbers just don’t move.
That is the actual stakes of the question I asked myself midway through this build: if the code is already in place, is it ready to deploy? The honest answer split everything into three tiers, and this is the part every generic “AI QA” post skips because they are writing about vibe coding QA testing in the abstract instead of against a real build.
Tier one was confirmed working, the stuff I had actually tested and watched behave correctly. Tier two was wired but never verified, code that exists, gets called, looks right, and has simply never been run against a real post. The Grid Picks table parser lived here for longer than I am comfortable admitting. It is the affiliate product placement mechanism for the entire site, fully built, fully wired into the single post template, and I had never once actually built a real table block and looked at what it rendered. Tier three was the scariest one: unknowns entirely outside the theme itself, things like whether view counter logic lived in a plugin or in the old theme I was about to replace, and whether any of my live posts used shortcodes this new theme did not know how to handle.
Code existing in the repo and code being verified against a real post are not the same claim, and conflating them is exactly how a wired-but-untested feature ships broken on day one.
What Generic Advice About Vibe Coding QA Gets Wrong
Most of what gets written about QA for vibe coding falls into one of two camps. Either it treats AI-generated code review as sufficient on its own, which ignores that the model reviewing its own output has the same blind spots as the model that wrote it. Or it tells you to just test it like normal, which ignores that normal QA assumes someone actually understands the code they are testing, and in a vibe coded build that understanding is distributed across a design tool, a model, and whatever you personally chose to hand code.
Neither camp accounts for what actually happens when review is concurrent instead of sequential. When you are building and testing in the same pass, the temptation is to trust that code you just watched get generated must be fine because you were paying attention while it happened. That temptation is exactly how tier two bugs survive. Watching code get written is not the same as testing what it does.
The Actual Bug List
Here is what QA on this build actually caught, grouped by the kind of failure each one represents, because the pattern matters more than any single bug.
Scope bugs showed up first. Category tab filtering broke because a variable never made it into the template’s scope through get_template_part, which meant the filter logic was correct and completely inert at the same time. Environment and packaging bugs came next, a Windows zip double nesting the theme folder in a way that made the WordPress installer reject it outright, nothing to do with the code inside, everything to do with how it got packaged.
CMS editability regressions were sneakier. One template got hardcoded tightly enough that it silently blocked editing through wp-admin, the kind of bug that stays invisible until someone who is not a developer tries to change a line of copy and cannot. Content drift showed up too, leftover text from an earlier rename that nobody caught because it read fine in isolation. Routing bugs meant the wrong template rendered the wrong view until the actual template hierarchy got traced properly.
The CSS bug is the one I keep coming back to. A missing alignment property caused row stretch artifacts on short posts in one card grid. Instead of patching that single instance, I went looking for the same vulnerable pattern elsewhere in the theme, and found it in two more places, one of them the highest traffic archive grid on the entire site, the one cycling through every post with wildly varying title and excerpt lengths. One bug found by accident, three bugs found by deliberately hunting for its siblings.
The framework specific gotcha was the strangest to diagnose. Gutenberg regenerates a block’s HTML from its stored attributes on every single edit, which means any class you hand inject into the markup gets silently stripped the next time someone edits that block. A button’s styling would revert after a content edit with no error, no warning, nothing in the console, just a component quietly reverting to a previous visual state. Understanding that Gutenberg’s attrs system owns the HTML, not the other way around, was the only way that bug stopped looking random.
Where the Line Actually Sits
I do not deploy a build like this to a monetized site under 85 percent confidence that Local is clean. That number is not arbitrary, it comes from weighing exactly the kind of tier two and tier three unknowns this build surfaced against what it costs to find them after launch instead of before. A bug on a site that is already earning is a loss. A bug on a site that has not started earning yet is the difference between starting and not, because the first real posts and the first real product picks go live running on a mechanism nobody actually confirmed works.
If you want the deeper mechanics of reviewing AI generated output specifically, testing AI generated code as part of a hybrid QA workflow covers that ground directly. Sorting which of these bugs actually blocked deployment versus which ones were annoying but survivable came down to the same logic in severity versus priority as a QA rubric. None of this happened through a formal test plan either, it happened through structured poking, the same approach covered in how to structure an exploratory testing session. Once this theme is actually stable enough to protect against regressions going forward, the next step is turning these findings into real coverage, which is exactly what generating a Playwright script from a bug report is for.
The build side of this same project, the Claude Design mockup and the vibe coding pipeline itself, is worth its own read if you want the other half of this story, covered from the development angle in building with AI as a developer over on EngineeredAI.
Vibe coding did not remove the need for QA judgment. It moved when that judgment gets applied, from a review phase at the end to a running decision made throughout the entire build. The apps that fail in production are not the ones that had bugs. Every build has bugs. They are the ones where nobody was checking which tier each piece of code actually belonged to before someone hit deploy.
