🧭 From first draft to real project
Carry-over from Module 5: keep the build you already made. Module 5 is about taking the next few steps like a steadier builder, not chasing a brand-new idea every ten minutes.
The first draft is the spark, not the finish line. This is where vibe coding becomes more useful: smaller changes, better checking, and less random flailing every time the AI does something odd.
Before you ask for the next pass, decide what kind of job this project needs next.
- Name the next job clearly: add one feature, fix one bug, tidy one section, or make one flow clearer.
- Protect what already works: if the hero is fine, say so. If the layout is mostly right, say so. Preservation matters.
- Choose the visible win: go for the change that makes the project more usable, clearer, or easier to trust.
- Stop restarting: stronger vibe coding usually means better iteration, not bigger prompts.
Open the project from Module 5. Don't ask the AI anything yet — just look at it. You're doing one lap as a builder, not a first-timer.
- Look at it fresh. Open the preview and scroll through it slowly. Imagine it belongs to someone else and you've been asked to keep improving it.
- Write down three things — one to protect, one to improve, one to leave alone for now. Example: Keep the hero · Improve the booking section · Leave the footer alone for now.
- Name the next move in one sentence — specific enough that the AI knows exactly what not to touch. Like:
Make the booking section clearer. Keep the hero and footer exactly as they are. - Only then open the AI panel. Paste your sentence as the first message of the session.
🎯 Ask for smaller, smarter changes
Better vibe coding usually sounds less magical and more precise. The aim is to make the next change easy for the tool to attempt and easy for you to judge afterwards.
If the structure is mostly right, say so. If one section is already strong, protect it instead of accidentally inviting a full rewrite.
Example: Keep the current layout and hero structure. Focus only on the booking section.Name the exact section, behaviour, or page part you want touched. Small targets are easier to steer than sprawling wish lists.
Example: Rewrite the call to action and price block, but leave the rest of the page alone.Get the tool to tell you what it changed. That helps you judge the result instead of staring at the page wondering what moved.
Example: After the edit, list the files you changed and give me a short bullet summary.When a change has a few moving parts, ask for the plan first. Planning prompts often stop the AI from charging off in the wrong direction.
Example: First give me a three-step plan. Do not edit anything until I approve the direction.Try this pattern: keep the parts that already work, focus on one area only, explain the change in plain language, and ask the tool to tell you exactly what it touched.
- Start with the sentence from your builder's audit.
- Add what should stay unchanged.
- Name the exact section to work on.
- End by asking for a short summary of what changed and which files were touched.
🖥️ Use the IDE like a real workspace
In Module 5 you recognised the panes. Now use them together. Stronger vibe coding comes from checking the result in more than one place instead of just trusting the last AI message.
Look at the actual result on screen. Did the change help or make the page weirder?
Check what got touched. Did it only edit the section you asked for, or did it wander further?
Make sure the project still runs. If the page breaks or the app fails to start, the clue usually lands here.
Use the next prompt to tighten, not restart. This is where you explain the drift and point the tool back at the right target.
Adult builder habit: one change, one check, one next decision. That loop is what stops vibe coding from turning into random chaos.
- Ask for one change only.
- Check the preview before reading the AI's victory speech.
- Open the files or ask which files changed.
- Check the terminal if anything looks broken.
- Then decide whether to keep the direction, tighten it, or undo part of it.
🐙 Put the project on GitHub
GitHub matters because it turns your workshop build into something you can keep, share, and return to. It is the easiest way to stop a project living in one mysterious folder on one laptop.
- Repository: the home for the project and its history.
- Commit: a named checkpoint, like
Initial workshop buildorFix booking section layout. - Push: sending those checkpoints up to GitHub so the work exists somewhere safer than your Downloads folder.
This is what the Source Control panel looks like in Antigravity and VS Code once your project has files. Changed files appear here with a letter: M = modified, U = untracked (new). You type a short commit message and push.
- Sign in at github.com or create a free account if you don't have one yet.
- Create a new repository: click New, give it a clear name like
raglan-surf-school, set it to Public, and click Create repository. - Connect your project:
GitHub Desktop route: Open Desktop → File → Add Local Repository → choose your project folder → Publish.
IDE route (Antigravity / VS Code): Open the Source Control panel (the branch icon in the left sidebar) → click Publish to GitHub. - Write a commit message that names the actual thing:
Initial build — Raglan surf school landing pagebeats "first commit" every time. - Push. Your project now lives at github.com/your-username/your-repo-name — safer and easier to return to than a Downloads folder.
🔑 Getting your own API key
At some point you will want to call AI models directly from your code — not through a chat interface, but via an API. That means getting a key. Same rule everywhere: copy it immediately, store it safely, never commit it to GitHub.
- Never put an API key directly in code you push to GitHub. Use environment variables (
.envfiles) and add.envto your.gitignore. - Never share a key in a screenshot, a Slack message, or a forum post. Bots scrape these.
- If a key leaks — revoke it immediately in the console and generate a new one. It takes 30 seconds.
.env file the tool creates for you. The IDE handles the rest — you don't write the API call yourself.
🚀 Do one more serious vibe-coding loop
This is the point where the project starts feeling real: you choose one meaningful next move, the AI makes a pass, you inspect the result properly, and you save the checkpoint.
A booking form, FAQ accordion, filtering control, contact flow, or one extra page section that actually helps the user.
Tidy layout spacing, broken mobile behaviour, unclear call to action, or a section that feels too busy or too vague.
Ask for one cleaner layout pass, clearer hierarchy, or simpler content flow without turning it into a total redesign.
- Pick one meaningful next move for the project.
- If it has a few moving parts, ask the AI for a short plan first.
- Let it make the change, then check preview, files, and terminal.
- If the direction is better, commit the change to GitHub.
- If it drifted, ask for a targeted fix instead of restarting the whole project.
Ka pai. That is starting to feel like a real project.
You now have a stronger build loop, a safer place to keep the work, and a better sense of how to keep pushing a project forward without starting from scratch each time.
Want to dig deeper before Module 7?