The Build Room

Vibe Coding 101 · Pavilion AI in GTM School · August 26, 2026

Sponsored by

Base44

Take the room with you

Everything from today, plus the parts we did not get to. No login, no drip sequence.

All the prompts

The template

GRACE

Five parts. Most first prompts fail because one of them is missing.

GOAL: [what you want to be able to do, and how fast]
ROLE: [who this is for, and what team or company they work in]
ACTION: [what I put in, and exactly what comes out]
CONTEXT: [what your company does, and anything the app needs to know]
EXAMPLE: [paste a sample of the output you want, or describe its shape]

Build this as a clean web app. Keep it to one screen. Ask me questions
if anything above is unclear before you start building.

Exercise 1

Watch this

One prompt, about two minutes. This is the whole idea.

Build me a fully playable snake game in the browser. Make it look
polished with a score counter and increasing speed.

Exercise 1

Now make it work for your job

Same skill as the snake game. Useful on Monday morning.

Build me a discovery call prep tool for B2B SaaS sales reps.
I give it a company name and it generates a one-pager with: a company
overview, likely pain points, and 3 discovery questions I should ask.
Make it a clean page I can review before every call.

Stuck

Start here

No idea what to build? Paste this and go.

Build me a simple app: I enter a company name and it returns a 5-bullet
summary of what they do, who they sell to, and their likely top pain point.

When it breaks

The debug loop

Errors are feedback. Do not try to decode them yourself.

Here is what I am seeing: [paste the error, or describe what looks wrong].
What went wrong, and how do I fix it? Explain it in plain English first,
then make the change.

Iteration

Constrain the change

The single highest-leverage sentence in this whole class.

Change only [the one thing]. Do not touch any other code.

Exercise 2, pick one

Take what you built and add one meaningful feature. One. Not four.

Add a second input

Also let me enter the contact's job title, and personalize the output for
that role. Change nothing else.

Save your outputs

Save every result to the app's database so I can come back and see past
ones. Add a simple list view of everything saved.

Add a follow-up step

After the brief is generated, add a button that writes a short personalized
cold email based on it.

Make it shareable

Get this ready to publish. Tell me anything I need to fix or fill in first.

What makes a good first project

Small scope

Something you could build in about ten minutes.

Clear inputs and outputs

You can say exactly what goes in and exactly what comes out.

Solves a real annoyance

Annoying enough that you will actually use it tomorrow.

Good first project

Meeting note summarizer

Takes raw notes, returns three bullets. One feature. Works immediately.

Too ambitious

A full CRM platform

Dashboards, email integration, analytics. Ten features, API keys, weeks of work.

When not to vibe code

Use it for

  • Internal tools and prototypes.
  • Low-risk, high-repetition tasks.
  • Proof-of-concept builds to show engineers.
  • Personal productivity tools.

Avoid it for

  • Your primary source of truth, like your CRM or data warehouse.
  • Customer-facing tools with security implications.
  • Regulated industries without proper review.
  • Anything where a mistake is critical and unrecoverable.

Vibe coding is a prototype machine, not a production system. Know the difference.

When you are ready for more

What you used today is a no-code builder. You and an AI in one chat, and you walk out with a published, shareable app. The next tier up is a coding agent that runs in your own file system, writes files, runs code, and fixes its own errors. Claude Code, Codex, and Cursor all work this way. Same prompting skills you used today. More power, more setup. You do not need any of it tomorrow.

If you do one thing this week

Open the thing you built today and use it once, for real. Not a demo, and not to show someone. An actual task on your actual list. That is the whole difference between something you made and something you use.

Show me what you built

Send it to me on LinkedIn. Half-broken is fine, most of mine start that way. I read every message and I answer them myself.

While you are there, here is what you would actually be signing up for: things I build and what broke while I was building them, notes from workshops like this one, and the occasional piece for Colorado AI News about the messy middle where AI meets real jobs. No hype, no fear-mongering, no posts about how AI is coming for your job. I post when I have something real, which is less often than the algorithm would like.

Find me on LinkedIn