The first time you vibe code, it feels like magic. You type “build me a website for my business”, and a few minutes later there’s a website. Then you ask for one change, and something else breaks. You ask it to fix that, and the first thing breaks again. An hour later you’re arguing with a chatbot about a menu.
The fix isn’t a better prompt. It’s a better way of working. We build everything on builtnotboosted.com in loops: ask for one thing, check it, fix it, write down what we learnt, move on. This guide is how that works in practice, using Claude Code.
Loops at a glance
- One change at a time. Small asks are easier to check and easier to undo.
- Plan, build, check, fix. Every change goes round that loop, and only moves on when it passes.
- Give the AI a memory. A project file with your rules saves you repeating yourself every session.
- Make it look at its own work. Screenshots, not just “the code looks right”.
- Never build on the live site. Staging copy or a gated site, plus backups.
- Know when to stop. If the same fix fails twice, step back and rethink.
The basic loop
Every piece of work on our site goes through the same four steps.
- Plan. Tell Claude what you want and ask it to plan before it writes anything. “Plan how you’d add a related posts section to the bottom of each post, using the tags. Don’t build it yet.” Read the plan. This is where you catch the bad ideas, and it’s the cheapest place to do it.
- Build. Once the plan makes sense, let it build that one thing.
- Check. Look at the result yourself, on a phone and on a laptop. Ask Claude to check it too, in a specific way (more on that below).
- Fix or move on. If it’s not right, say exactly what’s wrong and go round again. If it is right, save it and write down anything you learnt.
That’s it. It feels slower than one giant prompt. It’s much faster by the end of the week.
Give your AI a memory
Claude Code reads a file called CLAUDE.md in your project folder at the start of every session. Think of it as the briefing note you’d give a new member of staff. Ours covers things like:
- What the site is and who it’s for.
- The stack: WordPress on 20i, Cloudflare, Resend.
- Brand rules: our colours, our fonts, first names only, no em dashes.
- How we release changes: staging first, then live.
- Things that went wrong before and must not happen again.
Every time you correct the AI on something it should have known, add a line to that file. After a few weeks it stops making the same mistakes, because you’ve written them down. We go a step further and keep a full knowledge base of decisions, so even a brand new session can find out why something is the way it is.
Make it check its own work, properly
The most common failure in vibe coding is the AI saying “done” when it isn’t. It wrote the code, the code looks reasonable, so it assumes the page looks right. It often doesn’t.
So we make it look. Claude Code can run a headless browser (Playwright is the usual one), open the page, take a screenshot at phone width and at desktop width, and then look at the screenshot. Ask for that in your loop:
After you make the change, open the page at 390px and 1440px wide, take screenshots, look at them, and tell me what’s wrong before you tell me it’s done.
A real example from our own build. When we launched our Guides section, the topic labels at the top of each post ran together with no gap, so it read “GUIDESSOCIAL MEDIA”. The code was fine. The page wasn’t. Only looking at the rendered page found it.
Other checks worth asking for:
- “Check the page has no console errors.”
- “Run a PageSpeed-style check and tell me the Core Web Vitals.”
- “Click every link on the page and tell me which ones fail.”
- “Read this page as a first-time visitor and tell me what’s confusing.”
Never build on the live site
Your live website is the thing customers see. Don’t let an AI experiment on it.
- A staging copy. Most WordPress hosts, 20i included, let you make a copy of your site to test on. Our custom plugin goes to staging first, and only goes live once it’s been checked there.
- A gated site. If the site isn’t public yet, you can put Cloudflare Access in front of it so only you can see it. We did this on another build: nobody but us could reach it until the day it launched. Remember that tools like PageSpeed Insights can’t get through the gate either, so run your speed checks after you open it up.
- Version control. Ask Claude Code to use git and commit after every change that works. If something goes wrong, you can go back one step instead of starting over.
- Backups. Our host takes a daily backup we can roll back to. Check yours does, and check you know how to restore one before you need to.
Iterations: version your work
We number our plugin releases (0.5, 0.6, 0.8.1 and so on) and keep a short note of what changed in each one. It sounds like overkill for a small site. It isn’t. When something breaks three weeks later, “what changed in 0.8?” is a much easier question than “what did we do in October?”.
Ask Claude to keep a changelog file and add a line every time it changes something. It’s good at that, and it’ll do it without being reminded if you put the rule in CLAUDE.md.
The /loop command, and when to use it
Claude Code has a command called /loop that repeats a prompt on a timer. For example:
/loop 5m check whether the staging deploy has finished and tell me when it has
It runs every five minutes for as long as your Claude Code session is open. A few things to know, from Anthropic’s own docs:
- It only runs while Claude Code is open and idle. Close the terminal and it stops.
- The shortest interval is one minute.
- Recurring loops expire after seven days.
- If your computer was asleep when it should have run, it doesn’t catch up.
That makes /loop good for watching something during a working session: a deploy, a slow import, a fix you’re waiting to go live. It’s not the tool for “check my website every Monday”. That’s a scheduled task, and we cover those in Your website data, read and watched by AI.
Know when to stop the loop
Loops can go wrong too. Signs it’s time to stop and rethink:
- The same fix has failed twice. Ask Claude to explain why it thinks it’s failing before it tries again. Often it’s fixing the symptom, not the cause.
- It’s touching files you didn’t expect. Ask what it changed and why. Undo if it went somewhere it shouldn’t.
- You don’t understand what it’s doing. Ask it to explain in plain English. If you still don’t understand it, don’t ship it.
- The conversation has got very long. Start a fresh session. Your CLAUDE.md and changelog carry the important bits over.
Prompts we use in our loops
- “Plan this first. Don’t write code until I’ve agreed the plan.”
- “Make the smallest change that does this.”
- “Show me what you changed, file by file.”
- “Take screenshots at phone and desktop width and check them before you say it’s done.”
- “What could this break?”
- “Add what we learnt today to CLAUDE.md.”
Mistakes to avoid
- Asking for the whole website in one prompt.
- Accepting “done” without looking.
- Building straight onto the live site.
- No git, no backups.
- Letting a long, confused session run on instead of starting fresh.
- Repeating the same correction every week instead of writing it in CLAUDE.md.
The short version
Work in small loops: plan, build, check, fix. Give your AI a memory file and keep adding to it. Make it look at screenshots of its own work. Build on staging, with git and backups. Use /loop to watch things during a session, and scheduled tasks for anything regular.
This is part 1 of our Vibe coding a website guide. Next: Protecting your vibe-coded website with Cloudflare.
Last checked: 9 November 2026. Claude Code changes often, and we update this guide when it does.
Sources
- Claude Code docs: Run prompts on a schedule (/loop) (opens in a new tab)
- Claude Code docs: Desktop scheduled tasks (opens in a new tab)
- Cloudflare docs: Web performance skill (cloudflare/skills) (opens in a new tab)
