Why Two Vibe Coding Attempts Failed the Same Way (And What Finally Fixed It)

Your vibe coded app looks finished. It deploys clean, the UI renders, nothing throws an error, and you move on. Then months later you notice it’s been sitting there quietly broken the whole time, and the worst part is you can’t tell if the problem is the AI, your own instructions, or something you’ll never fully pin down.

That was exactly where I was with a tool I’d built for EngineeredAI called the Visual Sitemap Generator. The idea was simple: paste in a site’s sitemap and get back a visual map of the site’s structure, categories branching into their posts. I built the first version myself, researching the approach and writing the logic by hand. I got stuck on making categories and posts actually connect correctly, so I handed the stuck version to ChatGPT and asked it to vibe code a fix.

It came back looking done. The UI matched, there were patch notes claiming categories now rendered under the root, pan and zoom worked, and I deployed it to cPanel without a second thought. For months, it just sat there. Search Console was quietly showing real impressions for exactly the queries I wanted, visual sitemap generator, visual sitemap builder, visual sitemap creator, but at a position past 80 and with zero clicks. Not a crash. Not a visible error. A tool that looked alive in every way except the one that mattered.

What a Vibe Coded App Not Working Actually Looks Like

When I finally opened it up to see what was going on, the tool loaded fine. The header rendered, the input box worked, the Generate button responded. Then the visualization itself showed a handful of purple category boxes with long parallel lines running straight off the edge of the screen, and nothing underneath any of them. No posts. No hierarchy. Just categories, floating with nothing attached.

The bug was sitting right there in the code, and it wasn’t subtle once you actually read it. The function responsible for matching a post to its category worked by checking whether the category’s slug literally appeared as a substring inside the post’s URL. That’s a reasonable sounding idea for about three seconds, until you remember that normal WordPress permalinks almost never include the category name in the post URL. The match condition was checking for something that structurally could not be true for the vast majority of real posts on a real WordPress site. It wasn’t an edge case bug. It was a function that was functionally guaranteed to fail on the exact data it was written to handle, and it had been failing silently since the day it shipped.

This is the part people miss when they talk about vibe coding what breaks. The failure mode isn’t usually a crash or a visible error. It’s code that passes every check and still breaks in production, while quietly doing nothing useful underneath. Nothing in the console told me this was wrong. I had to actually read the function and ask whether its core assumption held up against real data.

Why the AI Fix Didn’t Fix It Either

Here’s the part that actually reframed how I think about this. My original attempt, the one I researched and wrote myself before ChatGPT ever touched the project, had landed on the same broken approach. Not a similar approach. The same one. Two independent attempts, one human, one AI, converged on identical flawed logic.

That rules out the easy explanation. This wasn’t AI hallucinating garbage code, and it wasn’t me being sloppy either. ChatGPT’s implementation was a competent, clean execution of exactly the plan I’d already reasoned my way into. The mistake wasn’t in how either of us wrote the code. It was one level up, in an assumption neither of us had actually tested before building on top of it: that a category name would show up inside a post’s URL. Nobody checked that against a real permalink before writing a single line that depended on it being true. That lines up with the patterns AI failures actually follow once you stop assuming the AI just hallucinated something random and start looking at what it was actually asked to build on top of.

There was a second, unrelated problem layered on top of this one, and it’s worth naming because it’s the kind of thing that eats hours and teaches you nothing about your actual bug. EngineeredAI runs on Cloudflare, and Cloudflare’s Rocket Loader feature defers and reorders script execution on the page. The original patch notes from the ChatGPT fix already mentioned working around this, which told me it had bitten that version too. When I rebuilt the tool from scratch, I hit the exact same wall again: the Three.js library tag didn’t have the attribute telling Rocket Loader to leave it alone, so the library loaded out of order, the whole script threw silently, and nothing rendered at all, not even the button click registering. Same site, same known gotcha, resurfacing in a completely rewritten tool because I’d forgotten a single attribute. That one wasn’t a planning failure. It was an environment specific trap that has nothing to do with logic and everything to do with knowing your own deployment target.

The Fix Wasn’t Better Code

Here’s the actual turning point, and it’s the whole reason this post exists instead of just a changelog. The thing that finally solved this wasn’t a smarter version of the same fix. It was stepping back before writing anything and asking two questions that neither previous attempt had asked clearly: what do I actually want this tool to do, and what should it actually look like.

Once that was answered specifically, categories and posts pulled directly from the WordPress REST API instead of guessed from URL strings, rendered as an orbital data structure instead of a flat broken tree, the rebuild from scratch resolved in one pass what two separate prior attempts, mine and ChatGPT’s, couldn’t. The rebuild runs on Three.js, loaded straight off a CDN with no build step, since the whole point was a tool that drops into a static cPanel folder and just works, not another dependency to manage. The difference wasn’t code quality. It was that the specification existed this time before the code did. This is the exact idea behind planning before vibe coding: the spec has to exist before the code does, not get reverse engineered from whatever the code happens to produce.

That’s the finding I want out of this whole experiment. This wasn’t AI being unreliable, and it wasn’t vibe coding being inherently risky. Both attempts failed for the same underlying reason, and it had nothing to do with who or what was writing the code. It was skipping the step where you actually define what you’re building before you start building it. Planning was the missing piece both times. That’s not a hedge or a caveat tacked onto the end. It’s the actual lesson, and it’s a more useful one than “AI made a mistake.”

If you’re testing something you or an AI vibe coded and want to know what a real QA pass on that looks like rather than just eyeballing whether it runs, testing a vibe coded app properly walks through exactly that from the QA side, and pairs directly with what happened here.

I’ve spent enough years untangling other people’s broken assumptions as a QA lead to recognize one in my own code when I finally stopped and looked for it.