AI Training Hub
View the slide deck →
Trainer Box Kit · v2 · AI Training Hub

Vibe
Coding
101

Build your first single-page app with AI. A complete teaching package for the 120-minute hands-on session — learners build a working app in Lovable, one prompt, one action, one preservation phrase at a time.

At a Glance
Lessons6 + Hook
Time2 hrs
AudienceBeginners
ToolsLovable
FormatIn-Person
Core RuleOne Prompt, One Action
§ 01 One-Page Snapshot

Course Overview

A trainer should be able to read this single section and know exactly what they're teaching, to whom, and why.

Session Title
Vibe Coding 101: Build Your First Single-Page App With AI
What This Session Is About
Learners use Lovable to build a single-page app one prompt at a time. The session teaches the core principle "One Prompt, One Action."
Why It Matters
Small, scoped prompts reduce ambiguity and protect existing code from accidental AI rewrites. The pattern learned in Lovable transfers directly to Gemini Canvas, Replit, Codex, and GitHub.
Intended Audience
Beginners. No coding background required. No prior AI experience required. Built for learners who have never opened an AI coding tool before. ⚑ TODO · NEEDS INPUT FROM MOEZ — Does the alpha cohort skew high-school students, working adults, or mixed? Vocabulary, examples, and pacing in Sections 03–04 shift depending on audience age.
Skill Level
Absolute beginner. Anyone comfortable typing in a browser can participate.
Tools Used
Lovable, in Chrome or Edge. One computer with reliable internet per learner. ⚑ TODO · NEEDS INPUT FROM MOEZ / HASSAN — Confirm Lovable tier. Free-tier daily prompt limits and project caps may constrain the live build across a cohort. Confirm tier and pre-session signup steps before alpha test.
Total Time
120 minutes (2 hours).
Accessibility
Slides 20pt minimum, high contrast. Every prompt example read aloud in full. Printed Prompt Template Handout for learners without devices. Captions on if recording. Extra practice time for slow typists or assistive-input users — offer to pair them. Demo screen zoomed to 125% so the back row can read.

Learning Objectives

By the end of this session, learners will be able to:

  1. Identify the visual, interaction, and data blocks of a single-page app.
  2. Write a prompt using the Action + Target + Constraint + Preservation Rule formula.
  3. Apply the "One Prompt, One Action" principle to add one feature at a time.
  4. Use the preservation phrases "Do not redesign the page," "Keep existing functionality unchanged," and "Make the smallest change possible" to protect working code.
  5. Build a working single-page app in Lovable, starting from a hero banner.
  6. Run the workflow loop on their app: Prompt → Generate → Inspect → Test → Improve → Commit.
  7. Recognize how the workflow transfers to Gemini Canvas, Replit, Codex, and GitHub.

Core Principle

Small, scoped prompts beat one giant prompt. Every time. Lovable predicts from your prompt plus the current code context — so build features one prompt at a time, tell it what not to touch, and inspect what it generated before writing the next one. One Prompt, One Action — the session's center of gravity
§ 02 Minute-by-Minute

Run of Show

Learner practice is the deliverable — protect it. Never cut Lesson 1 practice or the Lesson 2 demo.

Time Type Topic / Activity Trainer Cues
0–8 min Hook
Welcome + Hook Question
Greet learners. Confirm Lovable is open on every screen before you start. Ask: "How many of you have tried to build an app and ended up with something you couldn't fix?" Quick show of hands, no discussion.		 Transition: "Today we're going to build a real app, one prompt at a time. Let me show you what that means."
8–18 min Lecture
SPA Anatomy + the Prompt Formula
Walk the three block types: visual, interaction, data. Teach the formula: Action + Target + Constraint + Preservation Rule. State the principle "One Prompt, One Action."		 Keep this under 10 min. The demo is where the lesson lives, not here. Transition: "Watch what this looks like in Lovable."
18–28 min Demo
Lesson 1 Live: Hero Banner
"Create a single-page app for a student coding club. Add a hero banner with a headline, subheadline, and one call-to-action button. Do not add any other sections yet."		 Type slowly so learners read along. Don't narrate while Lovable generates. After: "What do you notice?" Point at the constraint and ask why it mattered.
28–45 min Practice
Learners Run Lesson 1
Each learner runs Lesson 1 in their own Lovable project.		 Walk the room. Peek at screens. Ask quietly: "What prompt did you write?" Redirect learners who add extras beyond the hero to the constraint.
45–48 min Discussion
Quick Share-Out + Check for Understanding
Thumbs up if a hero banner appeared. Thumbs sideways if it generated something different. One or two volunteers read their CTA button text aloud.		 Reset energy before the next demo. Transition: "Next we add a navbar AND a second button without breaking the first one."
48–58 min Demo
Lesson 2 Live: Navbar + Second CTA
"Add a navigation bar with a logo on the left and three links on the right: Home, Projects, Contact." Then: "Add a second button in the hero section called 'View Projects.' Keep the existing button unchanged."		 Pause after the second prompt and point at "Keep the existing button unchanged." Show the original CTA is still there — the preservation phrase doing the work.
58–76 min Practice
Lessons 2 + 3
Learners run Lesson 2, then Lesson 3: "Add a three-card section below the hero. Each card should explain one benefit of learning vibe coding: speed, creativity, and iteration."		 If a learner's navbar prompt replaced their hero CTA, that's your teaching moment. Point at the missing preservation phrase out loud so the whole table hears.
76–91 min Practice
Lessons 4 + 5: Form + Display on Submit
"Add a simple contact form with name, email, and message fields. Do not connect it to a database yet." Then: "When the form is submitted, display the submitted message below the form using front-end state only. Do not use a backend or database."		 The two "do not" constraints are the teaching point — call them out as you walk. Many learners will be surprised the form works without any backend.
91–102 min Practice
Lesson 6: Fade-In Animation
"Add a subtle fade-in animation to the feature cards only. Do not change layout, text, or form behavior."		 Before they hit send, ask: "What might Lovable change if you dropped the second sentence?" Let them predict, then run. Pull any rewritten form onto the projector as the live example.
102–112 min Pair Activity
Share Apps With a Neighbor
What worked, what Lovable rewrote, one preservation phrase you'd add next time. Two rotations, ~2.5 minutes each way.		 Listen for "Lovable changed my hero when I added the form" — that comment is gold for the recap. Pull one example onto the projector if you can.
112–120 min Q&A
Recap + Open Q&A
Three things to remember: "One Prompt, One Action," the formula (Action + Target + Constraint + Preservation Rule), and the three preservation phrases.		 If quiet, seed: "A question I get asked a lot is, 'What do you do when Lovable starts redesigning the page on you?'" Close: "Open Lovable tomorrow and add one more feature, one prompt at a time."

If You're Behind

⏰ Cut the Pair Activity first. If still tight, drop Lesson 6 (fade-in animation) and cover it verbally in the recap. Never cut Lesson 1 practice or the Lesson 2 demo — the preservation phrase teaching in Lesson 2 is the whole reason this session exists.

Common New-Trainer Mistake

💡 Don't narrate the demo while Lovable is generating. Stay silent while the AI streams. Learners need to watch the workflow loop happen in real time — that's what makes "One Prompt, One Action" click. Talk only after the output finishes, then ask "What do you notice?" rather than telling them what they saw.

§ 03 Deck Standards

Slide Deck Guide

15 slides, five chapters. The deck is a runway, not a script — speaker notes carry the weight.

Design Requirements

One main point per slide
If a slide has more than one headline, split it. Trainers should never have to choose where to look.
Visual, not text-heavy
Images, icons, and key phrases — not paragraphs. If you wrote a sentence, move it to speaker notes.
Speaker notes work for a trainer who didn't build the deck
Each note block contains: (1) the key concepts to land, (2) a plain-language explanation, (3) one analogy or example, (4) at least one check-in question, (5) the common misconception and how to address it, (6) a timing cue.
Timing cues in speaker notes
Every note ends with minutes to spend (e.g., "Spend no more than 3 mins here"). Use presenter view so cues stay trainer-only.
Flag skippable content explicitly
⏰ TIME CHECK — Skip if running behind. The cut order when time is short: Pair Share slide first, then Lesson 6 (fade-in animation).

Slide Map

Each slide maps to a Run of Show row. Lesson slides carry the prompt verbatim — learners copy from the screen.

# Slide Title Run of Show Row Main Point
1
Vibe Coding 101 (Title)
0–8 · HookBuild a real app, one prompt at a time.
2
Have You Ever Built an App You Couldn't Fix?
0–8 · HookThe hook question; quick show of hands.
3
What Is a Single-Page App?
8–18 · LectureEvery SPA is built from visual, interaction, and data blocks.
4
The Prompt Formula
8–18 · LectureAction + Target + Constraint + Preservation Rule.
5
One Prompt, One Action
8–18 · LectureSmall prompts beat one giant prompt. Every time.
6
Lesson 1: Hero Banner
18–28 Demo · 28–45 PracticeThe Lesson 1 prompt, verbatim.
7
Quick Check: Did Your Hero Appear?
45–48 · DiscussionThumbs check + read your CTA aloud.
8
Lesson 2: Navbar + Second CTA
48–58 Demo · 58–76 PracticeBoth Lesson 2 prompts; preservation phrase highlighted.
9
Lesson 3: Three-Card Section
58–76 · PracticeSpeed, creativity, iteration — one card each.
10
Lesson 4: Contact Form
76–91 · PracticeThe form prompt; "do not connect it to a database yet."
11
Lesson 5: Display on Submit
76–91 · PracticeFront-end state only. No backend.
12
Lesson 6: Fade-In Animation
91–102 · PracticeCards only — "do not change layout, text, or form behavior."
13
Pair Share: What Did Lovable Rewrite?
102–112 · Pair ActivityShare your build; surface preservation gaps.
14
Three Things to Remember
112–120 · Q&AThe principle, the formula, the preservation phrases.
15
Questions / Thank You
112–120 · Q&AOpen Q&A and the closing line.
§ 04 How To Say It

Trainer Talking Points

These are how you say it, not just what to say. Use them verbatim if you're new to teaching this material.

Key Concepts to Emphasize

The five ideas every learner must leave with:

  1. "One Prompt, One Action" is the foundation. Small, scoped prompts beat one giant prompt because Lovable predicts from your prompt plus the current code context.
  2. The prompt formula is Action + Target + Constraint + Preservation Rule — and every prompt should have all four parts.
  3. Preservation phrases protect working code from accidental AI rewrites: "Do not redesign the page," "Keep existing functionality unchanged," "Make the smallest change possible."
  4. Real engineering work runs on the loop Prompt → Generate → Inspect → Test → Improve → Commit — and learners practice it on every prompt, not just at the end.
  5. Every visible app feature maps to specific code Lovable generates. The mystery disappears as soon as learners see the mapping.

The Prompt Formula

Four parts. Answer all four before you hit send on any prompt.

A
Action
What should Lovable do? Add, change, remove.
T
Target
Where on the page? Which section, which element?
C
Constraint
What are the specifics and limits of the change?
P
Preservation
What must Lovable NOT touch?

Worked example: "Add a card section [Action] below the hero [Target] with three cards [Constraint], keep the existing hero unchanged [Preservation Rule]."

Plain-Language Translations

✗ Don't Say

"A single-page app renders client-side without full page reloads."

✓ Say This Instead

"A single-page app is a website that lives on one page. When you click a button, the page updates without reloading."

✗ Don't Say

"Use front-end state to persist the value."

✓ Say This Instead

"Tell Lovable to remember what the user typed, just in the browser. We are not saving it anywhere permanent yet."

✗ Don't Say

"Add a preservation clause to scope the change."

✓ Say This Instead

"End your prompt with a sentence that tells Lovable what NOT to touch, like 'Keep the existing button unchanged.'"

✗ Don't Say

"Iterate the prompt against the current context window."

✓ Say This Instead

"Look at what Lovable just built. Write your next prompt based on what is already on the page, not what you imagined in your head."

✗ Don't Say

"Lovable conditions on existing code context."

✓ Say This Instead

"Lovable reads the code already on your page before it writes anything new. That is why preservation phrases work."

Analogies That Work

"One Prompt, One Action" is like building with Lego, not pouring concrete. One brick at a time, you can move it, swap it, or pull it back. Pour the whole foundation in one go and any change means breaking it up. Use in Lecture · introducing the core principle
Preservation phrases are like leaving sticky notes on furniture before letting movers into your house. "Don't touch this couch." "Don't move this shelf." Without them, the movers reorganize everything to fit the new piece. Use in Lesson 2 demo · the load-bearing moment
The workflow loop is how a chef cooks, not how a microwave heats. You taste, adjust, taste again, and only plate when it's right. You do not press one button and walk away. Use when teaching Prompt → Generate → Inspect → Test → Improve → Commit
The three SPA block types are like the parts of a vending machine. Visual is the glass front and the product labels. Interaction is the buttons you press. Data is the inventory the machine tracks behind the panel. Use in Lecture · SPA anatomy

Key Takeaways

  1. Build features one prompt at a time, not all at once.
  2. Use the formula every time: Action + Target + Constraint + Preservation Rule.
  3. End every prompt with a preservation phrase when you do not want existing code touched.
  4. Inspect what Lovable generated before writing the next prompt. The loop is the work.
  5. Every screen element maps to code you can read, change, or move.

Common Misconceptions

"Longer prompts are better. If I describe everything in one go, Lovable will build all of it correctly."
Say it back to them: "Length is not quality. One giant prompt gives Lovable more places to guess." Tie it to "One Prompt, One Action." Have them rewrite their giant prompt as three small ones on paper before they hit send.
"Lovable will preserve my working code automatically. I don't need to tell it what not to change."
Show it live. Run a prompt with no preservation phrase and let Lovable redesign something. Then add "Keep existing functionality unchanged" and run again. Point at the difference. Say: "If you don't tell it what to protect, it doesn't know."
"If Lovable breaks something, I have to start over."
"You almost never have to start over." Open Lovable's version history together so they see the rollback button before the practice block. Or model a recovery prompt: "Restore the previous version of the hero, then add the navbar."
"Vibe coding means I never need to look at the code."
"You don't have to write the code, but you do have to read it. That is the 'Inspect' step in the workflow loop." Open the code panel during the demo and point at where the hero element lives. They don't need to understand every line, just see the mapping.
"The AI knows what I want."
"Lovable predicts from your prompt and the current code context, nothing else. Vague prompt, vague prediction." When a learner gets a weird output, ask which of the four parts of the formula they left out: Action, Target, Constraint, or Preservation Rule.
§ 05 Step-by-Step

Demo Scripts

Step-by-step instructions so any trainer can run these demos — even if they've never seen them before. Backup screenshots live in /demo-backups/.

Demo 01 · Lesson 1 — Hero Banner

Maps To18–28 min · Demo row
ToolLovable (lovable.dev, Chrome/Edge)
Duration~10 minutes

Goal

Build the hero banner for the student coding club app, modeling "One Prompt, One Action" before learners try it. This is the session's first live demo and the moment that anchors the prompt formula in real output.

Setup

Signed in to Lovable, sitting on a fresh empty project with the prompt input box visible. Browser zoomed to 125% so the back row can read.

Step-by-Step

  1. Set the frame. Get learners to stop typing and look up. Say: "I'm going to write one prompt, hit send, and we're going to watch Lovable build a hero banner together. Just watch. We're not going to talk over it."
  2. Click the prompt input box. Type slowly enough that learners can read along:
    Create a single-page app for a student coding club. Add a hero banner with a headline, subheadline, and one call-to-action button. Do not add any other sections yet.
    While typing the last sentence, say: "Notice the last sentence. That is the constraint — it tells Lovable what NOT to do."
  3. Hit send. Say: "Now we wait silently while Lovable generates. I'm not going to narrate. Watch the preview panel."
  4. Wait silently. Do not click anything. Generation takes 30–60 seconds. If learners start asking questions, hold up a finger: "Hang on, let it finish."
  5. Acknowledge the output. Point at the screen: "What do you notice?" Take 2–3 observations. Watch for learners noticing the constraint held — no extra sections.
  6. Reinforce the principle. "That is 'One Prompt, One Action.' One feature, one prompt, one visible change."
  7. Hand off to practice. "Stop watching me. Open Lovable, hit New Project, and write your version of the same prompt for whatever topic YOU pick. I'll come around."

Expected Output

A live preview showing a single hero section: a headline 2–6 words long related to a student coding club, a 1–2 line subheadline, one CTA button (e.g., "Join the club"), and nothing below the hero — the constraint held.

Backup Plan

Tier 1 — weird output (extra sections, no button, off-topic): don't panic. Say: "Lovable just made a guess we didn't ask for. Watch what one follow-up prompt does." Send a corrective prompt naming the specific deviation: "Remove everything except the hero banner. Keep only the headline, subheadline, and one call-to-action button. Do not add any other sections." Reinforce: "Inspect first, then write your follow-up. That is the loop."

Tier 2 — Lovable fully down (login broken, preview not loading, prompts hanging 2+ minutes): switch to pre-saved screenshots, narrated in the same order. Files needed offline before the session: lesson1-01-empty-project.png · lesson1-02-prompt-typed.png · lesson1-03-generating.png · lesson1-04-hero-rendered.png. Say: "Lovable is having a moment. Session keeps moving. Watch these instead." Do not apologize repeatedly.

Demo 02 · Lesson 2 — Navbar + Second CTA

Maps To48–58 min · Demo row
ToolLovable, same project as Demo 01
Duration~10 minutes

Goal

Add a navigation bar AND a second hero CTA to the existing hero from Demo 01, modeling the preservation phrase "Keep the existing button unchanged" so learners watch preservation work in real time. This is the load-bearing demo of the session — if learners only remember one thing, it should be this pattern.

Setup

Still inside the Demo 01 project, hero banner rendered in the preview, Lesson 1 prompt visible in the history. Browser at 125%.

Step-by-Step

  1. Set the frame. "Demo 1 was one prompt, one action. Now we're going to do TWO prompts back to back, and the second one teaches the most important pattern in this whole session."
  2. Type the first prompt verbatim. Let learners read along — say nothing else yet:
    Add a navigation bar with a logo on the left and three links on the right: Home, Projects, Contact.
  3. Hit send. Wait silently. Watch for the navbar appearing above the existing hero.
  4. Acknowledge. Point at the navbar: "Navbar's in. The hero is still there. Good. Now watch the original CTA button specifically when the next prompt runs."
  5. Type the second prompt:
    Add a second button in the hero section called 'View Projects.' Keep the existing button unchanged.
    While typing the last sentence: "Read this with me out loud. 'Keep the existing button unchanged.' That is the preservation phrase."
  6. Hit send. Wait silently. Watch for the second button appearing next to the original CTA — original text and styling intact.
  7. Acknowledge the preservation. Point at the original CTA: "Look at the original button. Same text, same place, same style. Now look at the new one. Lovable kept what we told it to keep." Take 2–3 observations.
  8. Reinforce. "If I had dropped that last sentence, Lovable might have redesigned the entire hero to fit the new button. Preservation phrases are how you protect working code. You'll feel this in your bones in about 90 seconds when it is your turn."
  9. Hand off. "Same two prompts in your project. Run them in order. Then keep going to Lesson 3, the three cards. I'll come around."

Expected Output

The original hero from Demo 01 intact — same headline, subheadline, and first CTA. A new navbar above it with a logo on the left and Home / Projects / Contact on the right. A second "View Projects" button next to the original CTA, with the original unchanged in text, color, position, and sizing. No other sections added.

Backup Plan

Tier 1 — Lovable ignores the preservation phrase and rewrites the original CTA: treat it as a gift, not a failure. Say: "This is exactly the moment we are here for. Lovable just ignored the preservation phrase. Let's fix it." Type the recovery prompt live: "Restore the original call-to-action button exactly as it was after the first demo. Place the 'View Projects' button next to it. Keep all other parts of the hero unchanged." Reinforce: "This is why you read what Lovable generated before writing the next prompt. That is the Inspect step."

Tier 2 — Lovable fully down: pre-saved screenshots, same narration order: lesson2-01-hero-from-demo1.png · lesson2-02-navbar-prompt-typed.png · lesson2-03-navbar-rendered.png · lesson2-04-cta-prompt-typed.png · lesson2-05-both-ctas-rendered.png. Emphasize the preservation moment on the final screenshot: "Original button. Untouched. That is what 'Keep the existing button unchanged' bought us."

§ 06 From Listening to Doing

Practice Activities

~71 of 120 minutes are hands-on. Learner practice is the deliverable.

Activity 1 · ~61 minutes across four practice windows

The Build — Six Prompts, One App

Objective: Build a working single-page app one prompt at a time, with preservation phrases protecting earlier work. The "One Prompt, One Action" pattern made physical.

Lesson 1 · Hero Banner

Create a single-page app for a student coding club. Add a hero banner with a headline, subheadline, and one call-to-action button. Do not add any other sections yet.

Look for: a hero with headline, subheadline, and one CTA — nothing else on the page. If Lovable added extras: "Remove any sections beyond the hero. Keep the hero as-is."

Lesson 2 · Navigation Bar + Second CTA

Add a navigation bar with a logo on the left and three links on the right: Home, Projects, Contact.
Add a second button in the hero section called 'View Projects.' Keep the existing button unchanged.

Look for: a navbar above the hero; two buttons in the hero with the original CTA exactly as it was. If the original CTA changed: "Restore the original call-to-action button exactly as it was. Keep the 'View Projects' button next to it. Keep all other parts of the hero unchanged."

Lesson 3 · Three-Card Section

Add a three-card section below the hero. Each card should explain one benefit of learning vibe coding: speed, creativity, and iteration.

Look for: three cards in a row below the hero, navbar and hero untouched. If anything above the cards shifts: follow up with "Do not redesign the page."

Lesson 4 · Contact Form

Add a simple contact form with name, email, and message fields. Do not connect it to a database yet.

Look for: a form below the cards with three fields and a submit button; no backend connection.

Lesson 5 · Display on Submit

When the form is submitted, display the submitted message below the form using front-end state only. Do not use a backend or database.

Look for: type into the form, click submit, the message appears below the form.

Lesson 6 · Fade-In Animation

Add a subtle fade-in animation to the feature cards only. Do not change layout, text, or form behavior.

Look for: the three cards fade in on page load; every other section unchanged.

Expected Outcome

A working single-page app: hero banner, navbar plus a second CTA (original preserved), three-card section, contact form, front-end display on submit, and a subtle fade-in on the cards. All six features built one prompt at a time.

Partner / Group Option

If a learner is stuck creating their first Lovable project, pair them with a neighbor for Lessons 1–2. Let them work solo from Lesson 3 once they have momentum.

Challenge Extension

Fast finishers add their own custom prompt (a testimonial section, a pricing card, a footer) using the full formula. Remind them to write the preservation phrase BEFORE they hit send, not after Lovable rewrites something.

Differentiation

Slow typers copy the prompts verbatim from the slide instead of writing variations. Visual learners get a screenshot of the expected output at each lesson break so they have a target to match.

Activity 2 · 10 minutes · two rotations

The Pair Share — What Did Lovable Rewrite?

Objective: Surface at least one moment Lovable rewrote something unexpected, and name the preservation phrase that would have prevented it.

Instructions

  1. Set the frame. "Find a neighbor. You're going to share three things. Your build, what Lovable rewrote that you didn't expect, and one preservation phrase you'd add next time. Two and a half minutes each side."
  2. Rotation 1, Side A shares (2.5 min). Side A shows their app; Side B listens. The three-part share: what the app looks like now, one unexpected rewrite, one preservation phrase for next time.
  3. Rotation 1, Side B shares (2.5 min). Sides swap. Same format.
  4. Switch partners. "Find someone you haven't paired with yet. Same three things, fresh pair."
  5. Rotation 2, both sides share (5 min). New listener, new perspective. Then bring the room back together for the recap.

Expected Outcome

After two rotations, every learner has heard two different stories of unexpected rewrites — which makes the "One Prompt, One Action" pattern feel concrete instead of theoretical.

Partner / Group Option

If the room is quiet, switch from neighbor-pairs to table-of-four discussions. Lower stakes per person, higher chance someone surfaces a good rewrite story.

Challenge Extension

Fast pairs swap projects and write one preservation phrase they'd add to their partner's build — shared verbally or typed into Lovable on their partner's behalf for the next prompt.

Differentiation

Learners uncomfortable speaking in pairs write their share-out on a sticky note and trade. The pair reads each other's notes silently, then follows up in writing if needed.

§ 07 Temperature Reads

Check for Understanding

Use these throughout the session, not just at the end.

Quick Visual Checks

  • "Thumbs up if your hero banner has a headline, a subheadline, and one CTA button. Thumbs sideways if Lovable added anything else." (45–48 min, after Lesson 1 practice.)
  • "Raise your hand if Lovable kept your original CTA button exactly the same after Lesson 2's second prompt. Hand down if it changed." (Midway through 58–76 min practice.)
  • "Hold up 1 to 5 fingers: how confident are you that you could write a preservation phrase right now without looking at the slide?" (Start of 76–91 min practice.)
  • "Thumbs up if your contact form works and the submit message appears below it. Thumbs down if Lovable rebuilt your hero when you added the form." (End of 76–91 min practice.)
  • "Wave your hand if you ran Lesson 6 and the cards faded in WITHOUT anything else changing on the page." (Near the end of 91–102 min practice.)

Mini Challenges

  • "Add 'Keep existing functionality unchanged' to your next prompt before you hit send. Try it now."
  • "Look at your last prompt. Which of the four parts (Action, Target, Constraint, Preservation Rule) is missing? Add it and rerun."
  • "Pick one section of your app you do NOT want Lovable to touch on the next prompt. Say the preservation phrase for that section out loud to your neighbor before you type it."
  • "Take 30 seconds and add 'Do not redesign the page' to the end of your next prompt. Hit send. Watch what changes — and what doesn't."
  • "Find one element Lovable changed that you didn't ask for. Write the corrective prompt that restores it, but don't send it yet — show it to your neighbor."

Reflection Questions

What did Lovable rewrite that you didn't expect? Why do you think that happened? Which preservation phrase would have prevented it? Use after any practice block
Looking at your six prompts side by side, which one is the most precise? Which is the vaguest? What made the difference? Which step of the workflow loop do you skip most often — and what happens when you do? Use in the Pair Share or the recap

When Learners Are Confused

Staring at Lovable's output without typing the next prompt
Walk over. Ask: "What feature is next? What preservation phrase will you add?" Help them verbalize the prompt out loud before they type it.
App looks nothing like the demo — wrong section, missing feature, broken layout
Sit with them. Ask which prompt they typed. Usually one of the four formula parts is missing. Add it together and rerun.
Restarting the whole project after one bad output
Stop them gently. "You don't have to restart. Write a corrective prompt that fixes only the part that broke, and use a preservation phrase to protect the rest." Show the version history option as a second backup.
Copying prompts word for word but the project still looks different
Check three things: (1) they're typing into Lovable, not another tab; (2) they're in the SAME project from Lesson 1, not a new one; (3) they're actually hitting send. Most common cause: they opened a new project midway through.
Finished in three minutes, sitting back with arms crossed
They probably skipped the preservation phrases and Lovable rebuilt large chunks each prompt. Ask: "Show me your prompts. Did you tell Lovable what NOT to touch on each one?" Redirect to the Challenge Extension in Section 06.
"I don't know what to do" — with no specifics
Don't ask "what's confusing?" Instead ask: "Which lesson number are you on?" then "Read me the prompt you wrote." Hearing it out loud usually surfaces the missing piece.
§ 08 Keep the Energy

Engagement Strategies

A dead room kills learning. Especially important for newer trainers.

Think — Pair — Share
60 seconds think, 60 seconds pair, share out. Use after the Lesson 2 demo: "Read your last prompt to your neighbor. Together, identify which of the four formula parts (Action, Target, Constraint, Preservation Rule) is missing." Then take two or three pairs out loud to the room.
Low-Pressure Entry
In the first five minutes, set the tone: "You will get prompts wrong today, and that is the point. You write a prompt, Lovable does something unexpected, you adjust. That is the workflow." Before any practice block: "Take 30 seconds and just try it. Lovable will tell you if you're wrong faster than I will."
Prediction Questions
Before sending a demo prompt: "What do you think Lovable will keep the same? What will it change?" Take two or three predictions, then send and see who was right. Also: "Predict what would happen if you removed the preservation phrase from this prompt."
Calling on Learners
Casual, warm tone — never aggressive cold-calls. "Anyone want to share what Lovable did?" or "Table 2, what did your hero look like?" If silence: "I'll give everyone ten more seconds to think. Just look at your screen." Naming a table lowers the stakes versus naming an individual.
Energy Reset
If energy drops between practice blocks: "Everyone stand up for ten seconds." Then: "Name out loud the preservation phrase you'd add to your next prompt." Resets attention AND reinforces the load-bearing concept. Use sparingly — once or twice per session.
Show and Tell
Mid-session, put a learner's Lovable preview on the projector for thirty seconds while they read their last prompt aloud. Best after Lesson 2 (preservation lands) or Lesson 5 (form-on-submit lands). If no one volunteers, project your own and ask: "Whose hero banner had something different than mine?"
§ 09 Contingency Plans

What Could Go Wrong

Anticipate problems before they happen. The recovery is your job — the plan is ours.

Demo tool crashes
Switch to the backup screenshots from Section 05's Tier 2 recovery. Stay calm: "The tool hiccupped, which is actually a great moment to talk about backup plans." Walk the screenshots in the same narration order. Don't apologize repeatedly — real-world imperfection builds credibility.
Tech / internet / login issues
A learner who can't sign in pairs with a working neighbor: "Sit with them. Watch them prompt. Take notes on their preservation phrases." If the room's internet is fully down, walk the six lesson prompts verbally and have learners write the preservation phrases they'd add to each. The thinking work still happens without Lovable.
Running behind on time
Cut in this exact order: Pair Activity first, then Lesson 6 (cover it verbally in the recap). Never cut Lesson 1 practice or the Lesson 2 demo. Tell the room: "We're going to be efficient on the next section so we can keep the practice time intact."
Finishing too early
Fast finishers add a custom prompt using the full formula. Walk the room: "What is one feature you want that we did not build today? Write the prompt for it." Ending on time or slightly early beats rambling — don't pad with unprepared content.
Learners confused / not following
Use Section 07's confusion table for the specific behavior. If more than half the room is stuck after five minutes, pause and remodel a new example live with a different topic: "Let me try that again a different way." Don't push forward through visible confusion.
Quiet room, no one answering
Seed with a vibe-coding example: "A question I get asked a lot is, what do you do when Lovable starts redesigning the page on you?" Then: "Does that match what you experienced?" Still quiet? Switch to table-of-four discussions — lower stakes per person.
Disruptive or disengaged learner
Give them a role instead of a confrontation: "Can you keep an eye on the preservation phrases as we go? Tell me when I miss one." Or: "You spotted that fast — help me explain it to the table behind you." Engagement beats confrontation.
Lovable rewrites a learner's working code irrecoverably
Treat it as a teaching moment for the whole room. Open version history with the learner and roll back. If unavailable, write a corrective prompt together: "Restore the [feature] to what it was before the last prompt. Keep the rest unchanged." Then point at the original prompt and name the missing preservation phrase: "This is exactly why preservation phrases exist." A live failure recovery is one of the strongest teaching moments of the session.
§ 10 Anticipated Questions

FAQ & Q&A

The ten questions trainers will hear in this session. It's okay to say: "That's a great question — I'll follow up on that."

Basic / Beginner Questions
"How many credits do I use building an app like the one we built today?"
For a build this size (hero, navbar, cards, form, simple animation), expect 500–1,500 credits in Lovable. Light prototyping won't dent the free tier much. Heavy iteration on the same project pushes that number up.
"Will Lovable understand my prompt if I have typos?"
Mostly yes. Lovable's LLM handles typos and natural language well. But if you ask for specific content (a button label, a field name, a city), spelling matters because that exact text ends up in the code. Rule of thumb: typos in your description are fine; typos in the actual content you want shown are not.
"What can't an AI-built app do?"
A few things. Complex custom logic can be misunderstood. Performance tuning isn't automated. Edits applied repeatedly can produce messy state. Scaling considerations like caching and indexes still need human attention. Lovable is excellent for prototypes and MVPs; production apps with complex requirements often need a developer's hand.
"What is Lovable actually doing when I write a prompt?"
It's translating your natural language into code. Behind the scenes, the LLM reads your prompt plus the current code on your page plus patterns it has learned from millions of examples, and it generates the HTML, CSS, and JavaScript that makes the change. That's why preservation phrases work: the LLM can see the existing code, and you're telling it not to touch parts of it.
"Is Lovable a real production tool or just for learning?"
Lovable plus Supabase can absolutely support real production for many use cases. For enterprise-scale apps (millions of users, compliance-heavy projects, large databases), tools like Vercel Enterprise, Next.js on AWS, or Auth0 are better fits. Lovable is best for rapid prototyping and early-stage products — but those can ship to real users.
Advanced / Challenge Questions
"What happens when Lovable doesn't understand my prompt?"
One of three things: it asks a clarifying question, it makes a reasonable default assumption, or it produces something close-but-wrong. If you see something weird, that's usually a signal your prompt is missing one of the four formula parts — Action, Target, Constraint, Preservation Rule. Add it and rerun.
"How do I deal with Lovable making things up that aren't real (hallucinations)?"
Three moves: constrain your prompts (specific named features, not generic descriptions), validate outputs (open the code panel and read what was generated), and add disclaimers in your UI for AI-generated content. In today's session you'll mostly catch these by inspecting the Lovable preview. In production, you'd add validation layers.
"What guardrails should I add to my app?"
For a real app with users: input moderation (block malicious pastes), output filtering (don't render unsafe LLM outputs), role-based restrictions (lock admin features), and rate limits to prevent abuse. For today's session this isn't critical because your app is local to your Lovable project. But it matters the moment your app accepts real users.
"What edge cases break apps like this?"
Empty inputs, extremely long inputs, wrong data types, network timeouts, LLM hallucinations, missing environment variables, Supabase rate limits, and duplicate user data. Best habit: when you add a feature, ask "what happens if the user gives this nothing? Or gives it 10,000 characters?" Then handle those cases explicitly.
"What are embeddings and why does my app care?"
An embedding is a way of turning text into numbers (vectors) that represent its meaning. Lovable uses them internally to match your prompt to relevant code patterns. In your own apps, embeddings power semantic search, similarity matching, and "memory" for AI features. Supabase has built-in support via the pgvector extension.

Need more? The full trainer reference covers 50 questions across development, product scope, technical planning, LLMs, UX, data, performance, and security.

Potential Audience Questions →
§ 11 Plain-Language Definitions

Glossary

Use these definitions when learners ask. Resist the urge to over-explain.

Single-page app (SPA)
A website built on one page that updates in place as you interact with it, without reloading. The hero banner, navbar, cards, and form you built today all live on one SPA.
Hero banner
The big top section of a website with a headline, supporting text, and one main button. It's the first thing a visitor sees.
Navbar
The navigation bar at the top of a website with links (like Home, Projects, Contact) and usually a logo. It lets users jump between sections or pages.
CTA button
A "call-to-action" button — the main thing you want a visitor to click, like "View Projects" or "Sign Up." Most pages have one primary CTA per section.
Front-end state
Information your app remembers temporarily while you're using it, but forgets when you refresh the page. The message displayed after submitting the form in Lesson 5 used front-end state.
Preservation phrase
A short sentence added to a prompt that tells Lovable what NOT to touch. The three covered in this session: "Do not redesign the page," "Keep existing functionality unchanged," and "Make the smallest change possible."
Prompt formula
The four parts every well-scoped prompt should have: Action + Target + Constraint + Preservation Rule. Example: "Add a card section [Action] below the hero [Target] with three cards [Constraint], keep the existing hero unchanged [Preservation Rule]."
One Prompt, One Action
The core teaching principle of this session: each prompt should change one specific thing about the app. Small, scoped prompts beat one giant prompt because Lovable can only see your prompt and the current code, not what you imagined in your head.
Workflow loop
The six-step cycle for building with AI: Prompt → Generate → Inspect → Test → Improve → Commit. Every feature in the session followed this loop, not just the session as a whole.
Lovable
The AI coding tool used in this workshop, accessed at lovable.dev. You write prompts in natural language; it generates working HTML, CSS, JavaScript, and (with Supabase) backend code that runs in your browser.
§ 12 Pre & Post Flight

Before & After

Click each item as you complete it. Saved locally in your browser session.

Before the Session

  • Test Lovable login on the actual presentation machine; create a fresh test project end to end
  • Verify the preview pane is legible on the projector at 125%+ zoom
  • Download both demos' backup screenshots offline
  • Test the room's internet on the actual network, not your hotspot
  • Open all session tabs before learners arrive: lovable.dev, the handout, the recap link
  • Read all speaker notes end-to-end
  • Practice both demos with a timer, at least twice
  • Know the cut order: Pair Activity first, then Lesson 6
  • Review the "What Could Go Wrong" scenarios, especially the irrecoverable-rewrite recovery
  • Arrange seating for collaboration — clusters of 4 or pairs, not auditorium rows
  • Print or share the Prompt Template Handout
  • Turn captions on if recording
  • Confirm accessibility needs from Section 01

After the Session

  • Share the recap with the six lesson prompts so learners keep building
  • Send the post-session feedback form within 10 minutes of close
  • Share next-step links: lovable.dev, Replit, Gemini Canvas, Codex, GitHub
  • Complete the trainer reflection within 24 hours
  • Share the screen recording if one was promised
  • Note Box Kit improvements — confusing slides, broken demos, missing FAQs — for the curriculum team

Trainer Reflection

Complete after every session.

  1. What worked well?
  2. Where did learners struggle?
  3. Timing adjustments needed?
  4. What would you change?
  5. Feedback form link / results.