The Golden Rules of Full Stack Vibe Coding
Ready to jump into full stack? Congratulations! Beware!
Coding with AI (aka vibe coding) is tremendous fun. It is extraordinary that non-coders like me can spin up almost any application nowadays—we are only constrained by the abilities of increasingly powerful models and our resilience, determination, and willingness to learn how everything fits together.
Thus far I have built ClassForge, a platform that allows teachers to safely share AI tools with students—different types of chatbot that can be monitored by teachers and that will alert them if students use the tools in inappropriate or concerning ways—and am currently rebuilding our company website into a Kajabi-style membership site. This will cost around £40 a month to run, rather than the basic Kajabi plan of £118 a month (with the pro plan coming in at a whopping £236 a month). The chatbot site will cost more, as I will be paying inference costs for the various AI models that sit at the heart of the site. The plan is that I offer it to schools at a reasonable cost, to ensure that anyone who wants their students to explore AI has a safe and cost-effective place to do so. More on this in due course.
During the last few months, necessity dictated I up my game when it came to how I approached AI coding. I was simply not able to take things where I wanted to go with the haphazard workflow I’d developed. Most of the time I was inching forward, building a feature in fifteen minutes then spending three days unpicking the errors. I lost track of the build, had no idea whether it was secure, and at one point had to almost begin again when the project became so messy that AI was digging itself an even bigger hole trying to work out where it went wrong.
My starter stack
A while back, I published my golden rules of vibe coding, the ‘3-Ps’ of patience, persistence, and planning. Below I get a little more practical - non-negotiables when you start using tools like Claude Code and GPT-5 inside an integrated development environment (IDE) like Cursor or VS Code. These don’t relate to working with apps like Lovable, Manus or Replit: we are focusing now on working with files locally and pushing to an external repository. My preferred ‘stack’ is to use Github for cloud file storage (industry standard) and Vercel to deploy the site (again quite standard). I know of some who use Netlify and Cloudflare for the deployment side, but it’s safe to say Github is the standard for cloud storage.
In terms of an IDE, I use Cursor. I began with VS Code, but prefer its newer fork. They look pretty much the same, but Cursor feels a little cleaner and better organised. However, I don’t use the AI that Cursor provides, but rather bring Claude Code into the command line interface (CLI). This is quite simple - you open up a Terminal inside Cursor, ensure you have already imported node package manager (npm install -g npm), and add this command: npm install -g @anthropic-ai/claude-code. You then link to your Claude account (paid) and you’re good to go. Do not choose the pay-as-you-go API option - this will result in huge bills as Claude is expensive. You then simply type claude into the CLI and Claude appears!
When it comes to a backend, you have a choice. Google’s Firebase is where many begin but I soon moved away from it as I didn’t find it as flexible as third party databases. ClassForge has a Supabase backend, which is a good place to start. However, I know of an increasing number of vibe coders who use Neon and Railway: I am using Railway for my company site’s backend, with Prisma as a sort of go-between, simplifying the link between complex code and the database. However, I’d recommend starting with a database like Supabase or Neon, as AI coding tools seem to know them well (and I am having a few challenges with Prisma).
The final part of the starter stack is authentication, or auth. If you want people to sign into your website, I only have one piece of advice. Use Clerk. That’s it. Just use Clerk. It is so simple and eliminates so much faff using native auth add-ons like Supabase auth. Trust me on this one: if you want to quickly bring sign in with email or Google auth, Clerk will have you set up in no time. There is Better Auth as well, which is open source, but I couldn’t get that to work - I have a feeling that Claude doesn’t know it so well.
Let me now give you my golden rules. These are just those I have found work well in a vibe coding workflow: developers may disagree with me and I am always open to be told how to do things even more efficiently. But you can’t go far wrong if you follow these from the start. It will save you a lot of headaches.
Rule # 1: commit, commit, commit
This is by far and away the most important. Every time you make a change to your project, you commit (save) to Github. This is your checkpoint, a place you can come back to if/when AI messes up. And it will. You’d better believe it will. It will confidently lead you down the path of no return, and you will have no choice but to hit reset and start again from the last point saved. Without committing to git you are in big trouble. Early on in my first build I spent several days working on a major feature, only to find that it would not deploy. On investigation, Claude had brought in a major breaking change, but there was no way to revert it as it was too far gone. I had to almost begin the entire project again, losing over a month’s worth of work. It was sickening, but I learnt my lesson. ALWAYS commit.
The best way to do this is to begin a new branch of your project before you make a change. You can ask Claude to create a feature branch when working on a new feature, or a fix branch when fixing an error. When it commits this branch to Github you can then test it before promoting it to production. This is godsend as it means you can check online before making the switch. You want as many testing steps as possible (working with the dev/local server, then a preview version online) before the world sees your updated website.
You can also create a new branch, and navigate to an existing branch, via the branch explorer on the bottom left toolbar in Cursor. This will save you tokens by not asking Claude to do things you can actually do yourself.
The final reason you want to commit to a new branch is that, when things go tits up, and AI cannot find the reason why, you can ask it to do a ‘git diff’, to check the broken build with the last working version. It’s then more likely to work out where it messed up.
Rule #2: define the project scope
Consider working with AI coders like working with a human team. You wouldn’t give a full stack developer a vague, half idea of what you sort of wanted. You’d take the time to work with a project manager in advance to articulate the project scope and create a Product Requirements Document, or PRD. Make sure you do this before you write the first prompt to get coding.
I go further - I now use what is called the BMAD approach to agile AI development which you can find here. You drop the master prompt into an AI (Claude projects and Gemini Gems works well) and now have a full project planning team at your disposal. It’s a brilliant way to work interactively with AI to plan out your project in full before beginning to code. Agile uses something called stories, which is a neat way to map out the different user journeys and technically plan how they can be realised. I highly recommend this approach.
Rule #3: define your rules before you begin
If you’re just spinning up a one page microsite it’s less important, but if you want to build anything with any degree of complexity you must define your rules before you begin. These will begin with things like the length of each file (no components above 150 lines, strict design system rules, and the correct naming conventions for the database), and will become more granular depending on whether the AI is working inside your component files (the building blocks of each page), or api endpoints (files that talk to other services) for example.
Claude handles this well. When you first set up your project (I use next.js for all my platform building, which is the standard for web applications) you type /init in the Claude CLI and it creates a CLAUDE.md file with the project structure. However, this isn’t hugely useful. Where it becomes very useful is when you both add to this file (by adding #memories with a hash tag) and create further nested CLAUDE.md files inside each sub directory. For example, a CLAUDE.md file that gives the rules for API endpoints, or one that outlines the design rules. This is vital, as before every new feature or debug you can ask Claude to read the relevant file. It’s like having a series of user manuals ready to go.
You must do this. If you don’t, you will get into so much hot water. I am currently in the middle of massive debugging drama with my company site as I asked Claude to rewrite all the CLAUDE.md files and in process of doing so it actually deleted them. I hadn’t noticed, asked Claude to read the non-existent files before it began a major additional feature, then by the time it was built none of it would compile or deploy. It has taken me a day to fix: and all because Claude went rogue and brought in hundreds of breaking changes. So you need rules.
Rule #4: take the time to understand how it all fits together
You’ll likely never become a coding genius yourself, but you must understand how the various code functions work together. Learning the flow from front to back is critical - how the database schema and front end code speak to one another, the naming conventions for the different types of file, the critical importance of root files like package.json. At first it will all seem a mess of confusing tech jargon, but the more you work with AI, the more it makes sense. You can ask AI at any time to explain things and it will stop its coding and do just that. Most of what I’ve learnt about full stack has come from AI teaching me as it goes.
This is important because the more you understand how things should work, the more likely you are to spot when AI goes down the wrong path. I have found this particularly with things like hard coding style values like colours, and coding the wrong schema column names (like using id instead of user_id). Getting the rules written in advance will go a long way to solve this, but it’s also worth keeping an eye yourself. Never trust AI blindly.
Rule #5: always run your checks before committing and deploying
This one you learn early on. Before deploying your code to Github and Vercel, ask the AI to run a full build (npm run build). It will check and fix any errors. You can also ask it to run a type check (if you’re working in typescript, which is the standard nowadays) and a lint check (to check the quality of your code). This will stop 95% of the build errors and save you time.
There are a bunch of others, like how to use agents to save time and tokens, and how to bring in MCPs to connect to other services and allow AI to ‘see’ things like your Github repo, Vercel logs and even the pages its working on. But those are for another time and a series of courses I’ll be recording soon. I just need to get these last build errors fixed…..