During Class · Everyone Can Code

§ 01 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:

"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.
The prompt formula is Action + Target + Constraint + Preservation Rule — and every prompt should have all four parts.
Preservation phrases protect working code from accidental AI rewrites: "Do not redesign the page," "Keep existing functionality unchanged," "Make the smallest change possible."
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.
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.

Action

What should Lovable do? Add, change, remove.

Target

Where on the page? Which section, which element?

Constraint

What are the specifics and limits of the change?

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

Build features one prompt at a time, not all at once.
Use the formula every time: Action + Target + Constraint + Preservation Rule.
End every prompt with a preservation phrase when you do not want existing code touched.
Inspect what Lovable generated before writing the next prompt. The loop is the work.
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.

§ 02Lesson-by-Lesson

Build Flow

The six-lesson build and its live demos, in the order you'll actually run them.

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.

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

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."
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."
Hit send. Say: "Now we wait silently while Lovable generates. I'm not going to narrate. Watch the preview panel."
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."
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.
Reinforce the principle. "That is 'One Prompt, One Action.' One feature, one prompt, one visible change."
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.

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."

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

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."
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.
Hit send. Wait silently. Watch for the navbar appearing above the existing hero.
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."
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."
Hit send. Wait silently. Watch for the second button appearing next to the original CTA — original text and styling intact.
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.
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."
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."

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

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."
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.
Rotation 1, Side B shares (2.5 min). Sides swap. Same format.
Switch partners. "Find someone you haven't paired with yet. Same three things, fresh pair."
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.

§ 03 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.

§ 04 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?"

§ 05 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.

§ 06 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 →

§ 07 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.