This started as a video I recorded earlier in 2026, rewritten here because the idea behind it keeps coming up and the video buries it under an hour of screen sharing. I rebuilt a client site with AI, start to finish, and the title I gave it was deliberate. This isn't vibe coding. There is a version of building with AI that is just typing a vague wish into a chat box and accepting whatever falls out. What I did was almost the opposite of that, and the difference is the whole point.

What the build actually was

The job was a real agency project. An existing site built in Elementor, which is not fun to work with, and a fresh design sitting in Figma. The task was to get the old content into a new WordPress build with the new design, without copy and pasting a single page by hand. So the workflow went like this. Scrape the live site for its content. Pull the components out of Figma through its API. Merge the two with Claude and have it produce proper ACF components, backend first, then the front end in a later pass.

Notice there is no point in that where I asked a model to build me a website and hoped. Every step was a defined job with a defined output that I could check before moving on. The content scrape produced a file I could read. The component scaffold produced ACF field definitions I could open in the admin. I seeded the data and looked at it in WordPress before I let it touch a single template.

Why this isn't vibe coding

Vibe coding is fine for a weekend toy. It falls apart the moment you have to maintain the thing, or hand it to a client, or come back to it in six months and remember how it works. The trap is that the model will happily generate something that looks finished and is quietly held together with string. You do not find out until it breaks in production, and by then you have no idea why, because you never understood it in the first place.

The way you avoid that is not by prompting more cleverly. It is by building structure around the AI so it works inside rails you set. A few things made the real difference on this build:

• Documentation as you go. If you pair with AI to build your own tooling, make it write down what it built. The worst position is coming back in a month to something neither you nor the model remembers. Claude will not remember itself. You have to make it write things down.
• Skills and markdown files over loose prompts. I keep MD files that tell it how I want components built, how I want things formatted, the specialisms to call on for a given task. That is what gives consistent output across a project. Prompting from scratch every time gives you a different answer every time.
• A structured ACF setup. This only works with ACF Pro and a code-first builder like Stout Logic. The point of that is to take the UI clicking out of the loop entirely, so a component is something the AI can define in code and I can review in a pull request, not something assembled by hand in the admin.
• Permission, not blank access. I stepped through it. I did not hand it the keys and walk off. It scaffolds, I look, it proceeds. That is slower than letting it run wild, and it is the reason the output was usable.

The part that genuinely surprised me

When the seeder ran and I refreshed the page, the old content was there, in the new component structure, with the internal links intact. A home page I had not built by hand, populated with real content, ready for the front end pass. The first time you watch that happen it does feel like magic. But it only worked because the scaffolding underneath it was deliberate. The magic is downstream of the boring structural work, not a replacement for it.

What this means if you build for clients

The skill that matters now is not typing speed and it is not prompt wording. It is knowing how to set up the rails. What to let the model do, where to put a checkpoint, what to write down so the thing is still maintainable after you have moved on. That is senior work, and it does not show up in a demo where someone types one sentence and a site appears. It shows up six months later when the site is still standing and someone can actually change it.

This was the first time I had run this exact workflow end to end, and it will get better with each project. That is the other half of doing it properly. You keep a change log, you port the improvements back into your tooling, and the next build starts further ahead than the last. I wrote more about how the day to day of the job has shifted in this piece on how I write code now, and if you want to talk about a build like this, the about page explains how I work.