Brightmind Academy
Vibe Coding Course
Vibe Coding — Build Real Software by Talking to AI
6 modules · 24 lessons · ~3 hours

Vibe Coding FULL COURSE
Build by Talking to AI

Build real software by describing what you want in plain English — from your first page to a deployed app. No computer science degree required.

6 Modules 24 Lessons ~3 Hours Beginner → Advanced
Filter: ● Beginner ● Intermediate ● Advanced ● Professional click to filter
01
What Vibe Coding Actually Is Beginner
4 lessons · ~25 min · The mindset shift
1.1 From Writing Code to Directing It
Beginner
Vibe coding means building software by describing what you want in plain English and letting an AI write the actual code. You become the director, not the typist. This single shift is what lets non-engineers ship real tools.
● Beginner — The big idea
  1. Old way: you learn a programming language, then type every line yourself. Slow, and a steep wall for beginners.
  2. Vibe coding way: you describe the outcome ("a page that shows my services with a contact form"), and the AI writes the code.
  3. Your job becomes direction and judgment: deciding what to build, reviewing what comes back, and asking for changes.
  4. You still need taste and clarity — but you no longer need to memorise syntax.
  5. Think of it like working with a very fast junior developer who never gets tired and works for pennies.
Tip: You do not need to "understand the code" line-by-line to start. You need to understand what you want and be able to tell when it is working.
1.2 What You Can (and Can't) Build This Way
Beginner
Vibe coding is genuinely powerful, but it has a sweet spot. Knowing where it shines — and where you should be cautious — saves you weeks of frustration.
● Beginner — Pick the right projects
  1. Great fits: landing pages, internal tools, calculators, dashboards, simple booking or quote forms, automations, prototypes.
  2. Good fits: small web apps with a database, content sites, MVPs you want to test with real users.
  3. Be cautious with: anything handling payments, medical, legal, or large amounts of personal data — get a professional review before going live.
  4. Not yet ideal: huge complex systems, anything safety-critical, or apps needing deep specialist engineering.
  5. Rule of thumb: if you could explain it to a smart friend in two minutes, you can probably vibe code a first version.
Tip: Start with something real but low-stakes — a tool you would actually use yourself. Motivation matters more than ambition at the start.
1.3 The Vibe Coding Toolkit
Beginner
There is a small set of tools that do most of the heavy lifting. You do not need all of them — you need to pick one and get comfortable.
● Beginner — Know your options
  1. Browser tools (easiest start): Lovable, v0, Bolt and Replit let you build by chatting, with no install — your app appears live as you type.
  2. Editor tools (more control): Cursor and Claude Code work on real files on your computer — more powerful once you are comfortable.
  3. All of them work the same way underneath: you describe, the AI builds, you review, you refine.
  4. You can move between them later. Skills transfer — prompting is prompting.
  5. For your first project, a browser tool removes every setup hurdle.
Tip: Do not tool-shop for a week. Pick one browser tool today and build something small. You learn 10× faster by doing.
1.4 Your Mindset: Taste, Judgment & Iteration
Beginner
The people who get the most out of vibe coding are not the best typists — they have clear taste and they iterate calmly. Here is the mental model that makes it click.
● Beginner — Think like a director
  1. Expect the first version to be 70% right. That is normal and good — you refine from there.
  2. Iterate in small loops: ask → look → react → ask again. Tiny changes are easier to check than huge ones.
  3. Be specific about what is wrong: "the button is too small and the wrong colour" beats "make it better".
  4. Keep your goal in view. The AI will happily build the wrong thing very well if you are vague.
  5. Celebrate working over perfect. A live, slightly rough tool beats a perfect idea in your head.
Tip: When something breaks, do not panic and do not start over. Describe what you see and what you expected — the AI fixes it from there.
02
Setting Up Your Studio Beginner
4 lessons · ~30 min · First project + the safety net
2.1 Choosing Your Tool: Browser vs. Local
Beginner
The single decision that shapes your early experience: build in the browser (zero setup) or on your computer (more power). Here is how to choose without overthinking it.
● Beginner — Make the call
  1. If you have never coded: start in the browser (Lovable, Bolt, v0, Replit). Nothing to install, your app is live instantly.
  2. If you want full control and to keep files on your machine: use Cursor or Claude Code (a little setup).
  3. Browser tools are perfect for landing pages, simple apps and prototypes.
  4. Local tools shine for bigger projects, custom workflows and connecting to your own systems.
  5. You can always graduate from browser to local later — the concepts are identical.
Tip: For this course, a browser tool is recommended so we focus on building, not configuring.
2.2 Your First Project in 15 Minutes
Beginner
Nothing builds confidence like seeing your own idea appear on screen. Let's ship a simple, real page from a single description.
● Beginner — Build something live
  1. Open your chosen browser tool and start a new project.
  2. Type a clear first prompt: "Build a one-page site for my business [NAME]. Sections: hero with tagline, three services, an about paragraph, and a contact form. Clean, modern, dark theme."
  3. Watch it build. When it appears, read it like a visitor would.
  4. Ask for one change at a time: "Make the hero headline bigger" → look → "Change the accent colour to teal" → look.
  5. When you like it, use the tool's Publish / Deploy button to get a live link.
Tip: Keep your first prompt to one screen. You will refine in follow-ups — you do not have to describe everything upfront.
2.3 Git: Your Undo Button for Everything
Intermediate
Git is a "save point" system for your project. It feels technical, but the one thing it gives you — the ability to roll back to any earlier version — is what lets you experiment fearlessly.
● Beginner — The safety net (browser tools)
  1. Most browser tools save versions automatically — look for "History" or "Versions" and learn where it is.
  2. Before a big change, note the current version so you can return to it.
  3. If a change makes things worse, restore the previous version — no harm done.
  4. This is the mindset: experiment boldly because you can always go back.
Tip: The fear of "breaking it" is what stops beginners. A reliable undo removes that fear entirely.
● Intermediate — Real Git (local tools)
  1. In your project, run git init once to start tracking.
  2. Save a snapshot any time with git add -A then git commit -m "what changed".
  3. Made a mess? Return to your last good snapshot — your AI tool can do this for you on request.
  4. Push to GitHub for an off-machine backup: create a repo, then git push.
  5. Always commit before a big AI-assisted change so you have a clean restore point.
Tip: You do not need to master Git. Learn exactly two moves: save a snapshot and go back to one.
2.4 Understanding Context: How the AI "Sees" Your Project
Intermediate
The AI can only work with what it can "see" at that moment — its context. Understanding this explains why it sometimes forgets things, and how to keep it sharp.
● Beginner — Keep the AI oriented
  1. The AI reads your project and your conversation — that is its memory for the task.
  2. Long, rambling chats can crowd out important details. Keep requests focused.
  3. Remind it of key facts when needed: "Remember, this is for dog groomers, tone should be friendly."
  4. If it starts behaving oddly or forgetting, start a fresh chat and restate the goal.
  5. Give it references: paste a link, a screenshot, or example text so it builds the right thing.
Tip: A short, clear, well-fed context beats a long messy one every time. Treat the AI like a brilliant assistant who just joined today.
03
The Craft of Prompting Intermediate
4 lessons · ~30 min · Describe, spec, iterate, debug
3.1 Describe the Outcome, Not the Code
Intermediate
The biggest beginner mistake is trying to describe the code. You should describe the result you want and let the AI choose how to build it.
● Intermediate — Outcome-first prompting
  1. Weak: "add a div with flexbox". Strong: "put the three services side by side on desktop, stacked on mobile".
  2. Describe what the user sees and does, not the technical implementation.
  3. Include the why when it helps: "make the CTA stand out because sign-ups are the goal".
  4. Give concrete details: exact text, numbers, colours, behaviour on click.
  5. Trust the AI on the "how" — review the result, not the syntax.
Tip: If you find yourself googling code terms to write a prompt, stop — just describe what you want to happen in plain words.
3.2 Spec-First: Plan Before You Build
Intermediate
A two-minute plan dramatically improves what the AI builds. A short spec gives it everything upfront, cutting the endless back-and-forth.
● Intermediate — Write a mini-spec
  1. Before building, write 5 lines: who it is for, what it does, the main screens, the key action, the style.
  2. Paste that as your first message: "Here is the spec for what we are building. Confirm you understand, then build screen 1."
  3. Ask the AI to restate the plan back to you — catch misunderstandings before any code exists.
  4. Build one screen / feature at a time against the spec.
  5. Keep the spec handy; paste it again if the AI drifts off course.
Tip: Ten minutes of spec saves hours of "no, not like that". This is the single highest-leverage habit in vibe coding.
3.3 Small Steps Beat Big Leaps
Intermediate
Asking for everything at once produces a tangled result that's hard to check. Small, verifiable steps keep you in control and make problems easy to spot.
● Intermediate — Work in loops
  1. Break the build into bite-size requests: layout → content → styling → interactivity → polish.
  2. After each step, look at the result before asking for the next thing.
  3. If a step works, mentally "lock it in" (or commit it) before moving on.
  4. If a step breaks something, you know exactly what caused it — the last change.
  5. Resist "while you're at it, also..." — one change per loop.
Tip: Big-bang prompts feel efficient but cost you later. Small steps feel slower but are far faster overall.
3.4 Debugging by Conversation
Intermediate
When something breaks — and it will — you fix it by describing it, not by reading code. This is a learnable skill and it is mostly about good observation.
● Intermediate — Fix it by talking
  1. Describe three things: what you did, what you expected, what actually happened.
  2. Copy any error message and paste it in full — errors are clues, not failures.
  3. If there is no error but it looks wrong, describe the visual: "the form submits but nothing happens".
  4. Ask the AI to explain the cause before fixing, so you learn: "why did that happen?"
  5. If one fix does not work, say so plainly — "that did not change anything" — and it will try another angle.
Tip: You are the eyes; the AI is the hands. Your job is to observe and describe accurately. Vague reports get vague fixes.
04
Idea to Working App Intermediate
4 lessons · ~35 min · Build a real tool end-to-end
4.1 Plan a Real Project: A Booking Tool
Intermediate
We'll plan a genuinely useful small app — a simple booking/enquiry tool a service business could use — so the next lessons build something real.
● Intermediate — Scope it tight
  1. Define the one job: "let a visitor request a booking for a service and a date, and notify me".
  2. List the screens: a form page, a thank-you page. That is enough for v1.
  3. List the fields: name, email, service, preferred date, message.
  4. Decide the action: on submit, send the details to your email (we will use a no-backend form service).
  5. Write this as a 6-line spec — that is your build brief.
Tip: Ruthlessly cut v1. "Accounts", "calendars", "payments" can all come later. Ship the smallest useful thing first.
4.2 Build the Interface
Intermediate
Turn the spec into a clean, on-brand interface. The goal is something that looks trustworthy and is obvious to use.
● Intermediate — Build the screens
  1. Prompt with your spec: "Build the booking form page from this spec. Clean, professional, mobile-friendly."
  2. Refine the layout one step at a time until it feels right.
  3. Add the fields exactly as specified; mark required ones.
  4. Build the thank-you state: "after submit, show a friendly confirmation message".
  5. Check it on a phone-size screen — most visitors will be on mobile.
Tip: Ask for sensible defaults: clear labels, helpful placeholder text, and big tap targets. Good forms feel effortless.
4.3 Add Data and Logic
Intermediate
Make the app actually do something: validate input, react to the user, and prepare the data to be sent somewhere useful.
● Intermediate — Make it smart
  1. Add validation: "require a valid email and a date that is not in the past; show a friendly error if missing".
  2. Add a loading state: "while submitting, disable the button and show 'Sending…'".
  3. Handle success and failure clearly so the user is never confused.
  4. Format the data nicely so when it reaches you, it is easy to read.
  5. Test the unhappy paths: empty fields, bad email, double-click submit.
Tip: Most "bugs" users hit are missing edge cases. Ask the AI directly: "what edge cases am I missing here?"
4.4 Connect the Real World
Intermediate
A form that goes nowhere is useless. Wire it up to send you the enquiry — without needing to build a backend server.
● Intermediate — Make it deliver
  1. Use a no-backend form service (e.g. Web3Forms or Formspree) — they give you a key and an email endpoint.
  2. Tell the AI: "send the form submission to this form endpoint and email me the result".
  3. Test it end-to-end: fill the form, submit, and confirm the email arrives.
  4. Add a fallback message in case sending fails so visitors are not left hanging.
  5. For richer needs later (saving to a database, payments) the same pattern applies — connect a service, describe the goal.
Tip: You rarely need to "build a backend" for small tools. A form service or a ready-made API does the heavy lifting.
05
Shipping It Advanced
4 lessons · ~30 min · Deploy, secure, review
5.1 Deploy to the Web
Intermediate
Getting your app onto a real, shareable web address is easier than it sounds — and it is the moment your work becomes useful to others.
● Beginner — One-click publish (browser tools)
  1. Most browser tools have a Publish button that gives you a live URL instantly.
  2. Share that link to test with real people.
  3. You can connect a custom domain (yourname.com) in the tool's settings later.
● Intermediate — Deploy a local project
  1. Push your project to GitHub.
  2. Connect the repo to Vercel or Netlify (both have generous free tiers) — they deploy automatically.
  3. Every time you push a change, your live site updates by itself.
  4. Add your custom domain in the host's dashboard and follow the DNS steps.
  5. Ask your AI tool to walk you through any step you get stuck on.
Tip: Vercel and Netlify connect to GitHub and redeploy on every change — set it up once, forget about it.
5.2 Keep Your Secrets Safe (The Real Lesson)
Advanced
The most common — and most damaging — mistake in vibe coding is leaking a secret key. This one lesson can save you from a real bill or a real breach.
● Intermediate — Why keys leak
  1. An API key is like a password that lets your app use a paid service (email, AI, payments).
  2. If you paste a key directly into your app's code, anyone viewing the page can find and abuse it.
  3. Real consequence: a leaked key can run up huge bills or expose your data.
  4. The golden rule: secret keys live on the server, never in the browser.
Tip: If a tool ever asks you to put a key with the word secret in your front-end code, stop and get it moved server-side.
● Advanced — Do it right
  1. Store secrets as environment variables on your host (Vercel/Netlify settings), not in code.
  2. Use a tiny serverless function as a middleman so the browser never sees the key.
  3. Never commit a key to GitHub — if you do, rotate (regenerate) it immediately.
  4. Ask your AI explicitly: "make sure no secret keys are exposed in the browser bundle".
  5. When in doubt, have a developer review anything that touches keys, payments, or personal data.
Tip: A "VITE_" or "PUBLIC_" prefix usually means a value WILL be visible in the browser. Never give those a real secret.
5.3 Reviewing Code You Don't Fully Understand
Advanced
You will ship code you did not write line-by-line. That is fine — but you need a lightweight way to sanity-check it so you stay in control.
● Advanced — Review without being an engineer
  1. Ask the AI to explain its work in plain English: "summarise what this code does and any risks".
  2. Ask the safety questions: "does this expose any secrets? does it handle errors? what could break?"
  3. Get a second opinion: paste the code into a fresh AI chat and ask "review this for problems".
  4. Test the behaviour, not the syntax — does it do the right thing across normal and weird inputs?
  5. For anything important (payments, data, security), pay a developer for an hour to review. Cheap insurance.
Tip: You do not need to understand every line. You need to know what it does, what it touches, and how it can fail.
5.4 Security Basics for Non-Engineers
Advanced
A handful of simple habits cover the majority of real-world risks for small apps. You do not need to be a security expert — you need these basics.
● Advanced — The essentials
  1. Keep secret keys server-side (Lesson 5.2) — this is number one.
  2. Validate user input — never trust what comes from a form; the AI can add this for you.
  3. Use HTTPS (every modern host does this automatically) so data is encrypted in transit.
  4. Collect only the data you actually need, and tell users what you store.
  5. Keep dependencies updated; ask your tool "are there any known vulnerabilities here?"
Tip: For anything involving payments, health, or large amounts of personal data, get a professional security review before launch. No exceptions.
06
Vibe Coding for Your Business Advanced
4 lessons · ~30 min · Turn skills into results
6.1 Automate Your Own Admin
Intermediate
The fastest payback from vibe coding is building little tools that erase your own repetitive work — quotes, reports, follow-ups, calculators.
● Intermediate — Find the wins
  1. List the boring tasks you repeat weekly — that list is your build backlog.
  2. Start with the simplest, most repeated one (e.g. a quote calculator or an invoice generator).
  3. Build a tiny internal tool just for you — it does not need to be pretty.
  4. Connect it to what you already use (email, a spreadsheet, a form).
  5. Measure the time saved; reinvest it into the next tool.
Tip: Internal tools have no marketing, no design pressure, no users to please but you. They are the perfect place to practise.
6.2 Build Client-Facing Tools
Intermediate
Once you are confident, client-facing tools — calculators, quizzes, mini-apps — become powerful lead magnets and differentiators for your business.
● Intermediate — Tools that win clients
  1. Pick a tool that gives a prospect instant value (a pricing estimator, a readiness quiz, a savings calculator).
  2. Keep it focused on one helpful result.
  3. Capture interest: offer to email the result in exchange for an address (with consent).
  4. Make it on-brand so it builds trust, not just utility.
  5. Promote it — a genuinely useful free tool is shareable and memorable.
Tip: A free tool that solves one real problem outperforms a brochure. It shows competence instead of claiming it.
6.3 When to Bring In a Real Developer
Advanced
Knowing the limits of vibe coding is a strength, not a weakness. Some work genuinely needs a professional — recognising when protects you and your clients.
● Advanced — Draw the line
  1. Bring in a developer for: payments at scale, sensitive personal/health/financial data, or anything safety-critical.
  2. Also for: complex systems, heavy traffic, integrations with serious business systems, or anything you will sell as a product.
  3. Use vibe coding to build the prototype, then hand a developer something concrete to harden.
  4. A clear working prototype makes hiring cheaper and faster — they fix and scale rather than start from zero.
  5. Budget an hour of professional review for anything that touches money, data, or security.
Tip: Vibe coding and professional development are partners, not rivals. The prototype you build makes the pro's job easier and cheaper.
6.4 Your 30-Day Vibe Coding Plan
Intermediate
A simple month-long plan to turn everything here into a habit and a real, shipped tool. Momentum beats intensity.
● Intermediate — The plan
  1. Week 1: Pick one browser tool. Build and publish a simple one-page site. Just ship it.
  2. Week 2: Build an internal tool that saves you real time (a calculator or generator).
  3. Week 3: Build the booking/enquiry app from Module 4, connected to your email, and put it live.
  4. Week 4: Build a client-facing tool as a lead magnet and share it publicly.
  5. Each week: commit before big changes, keep secrets server-side, and review anything important.
Tip: Ship something small every week. Four rough-but-live tools in a month will teach you more than any tutorial — including this one.
Vibe Coding Toolkit
The tools used throughout this course — pick one and start building.