Decomposition
Turn a large idea into changes small enough for AI to complete and for you to test. One main task per prompt keeps the work understandable.
Vibe Coding Curriculum
Direct the AI. Check the work. Ship something real.
Work through seven lessons in order—from a browser-based workspace to a public product your team can demonstrate and explain.
What You Are Learning
Good Vibe Coding is a thinking process.
AI can write syntax quickly. Students remain responsible for deciding what to build, giving useful direction, and checking what comes back.
Context
Provide the PRD, CONTEXT.md, relevant files, and full error messages. Better context is often more valuable than switching tools.
Verification
Read the changes, run the product, test the live result, and ask for explanations. Do not accept work you cannot describe.
Seven Lessons
Build knowledge in the same order as the product.
Complete each checkpoint before moving forward. Small working states are easier to understand, test, and recover.
-
00 Foundation
Set up the workspace
Open the verified starter repositoryLearn
GitHub Codespaces is the standard club development environment. It lets you copy, run, edit, preview, and save the starter project in a browser.
Why it matters
A shared environment makes help easier and proves that your setup works before the project becomes complicated.
Do
- Copy the approved starter into your own repository.
- Open it in Codespaces and follow its current README.
- Run the preview, make one visible change, and ask AI to explain the file structure.
- Create
CONTEXT.mdand save the first working checkpoint.
Checkpoint
Your copy of the starter opens in Codespaces, the preview runs, one visible edit appears, and the working state is saved.
-
01 Focus
Sharpen the idea
Learn
A buildable idea names a specific user, a specific problem, the kind of product, and one main action.
Why it matters
If another person cannot predict what the user clicks and what happens, the idea is still too broad to build well.
Do
- Start with a real frustration you or someone you know experiences.
- Write: “For [user], who struggles with [problem], we are building [product]. The one thing it does is [verb + noun].”
- Say it to someone outside the club and ask what they expect to happen.
Output
One sentence that an outside listener can understand and connect to one visible product action.
-
02 Scope
Write the PRD
Learn
A one-page Product Requirements Document gives the AI useful context and protects the project from uncontrolled scope.
Why it matters
The “not building” list is how a beginner team stays focused on a version it can finish and demonstrate.
Do
- Keep the one-liner from lesson one.
- Write three user stories and list no more than four main screens.
- Describe only the data the product truly needs.
- Name the core feature and at least five features excluded from version one.
Checkpoint
A focused
PRD.mdexists in the repository. The final PRD approver has not yet been finalized. -
03 Starting point
Start from the scaffold
Learn
The club starter provides a shared project structure so teams can spend their time solving the problem instead of choosing a new setup.
Why it matters
A consistent scaffold makes technical help, AI context, and recovery from mistakes more practical across teams.
Do
- Run your copied starter and change its visible name.
- Ask AI where pages, reusable components, and styling live.
- Add the PRD and current project state to
CONTEXT.md. - Save the working version and give it a public URL before major features.
Output
A running starter with the project name, a useful context file, a saved checkpoint, and an early public URL.
-
04 Build method
Prompt in layers
01ContextPRD, context file, relevant files→02TaskOne specific change→03ConstraintsWhat may and may not change→04CheckExplain, run, and verifyLearn
The fix for a bad giant prompt is not one cleverer prompt. It is a sequence of smaller prompts with enough context and a clear check.
Why it matters
Smaller changes are easier to read, test, explain, commit, and replace when something breaks.
Do
- Ask for one main change at a time.
- Review the change and ask about anything unclear.
- Test and save every working state.
- After repeated failure, make the task smaller or start a fresh conversation.
Checkpoint
The main product works, is deployed, and the team can explain the important changes.
Build and deploy each layer before the next:
- 1SkeletonPages, navigation, fake data
- 2PagesLayout and clarity
- 3DataSimplest necessary storage
- 4InteractionCore action works
- 5PolishMobile, states, accessibility
-
05 Publish early
Deploy
Learn
A public URL is a working checkpoint, not a final ceremony. Deploy the starter and continue publishing after each build layer.
Why it matters
Early deployment exposes publishing problems, enables real-device testing, and makes progress shareable.
Do
- Use the current deployment instructions included with the project.
- Put the public URL in the project README.
- Open the live site on another device and test the main action.
- Keep secrets out of public code and browser-side code; use secure environment variables.
Output
A tested public URL in the repository README, updated after every working layer.
-
06 Show the work
Demo and submit
Open competition preparationLearn
A strong 60–90 second demo proves the problem is real, shows the core action from start to finish, and explains learning and next steps.
Why it matters
A small finished product that the team understands is stronger than an ambitious product that must be imagined.
Do
- Record the core action and keep the live site ready.
- Use realistic sample data and show only features that work.
- Prepare the URL, repository README, video, screenshots, roles, and contribution record.
- Disclose AI use fully and honestly whenever required.
Output
A working demo and honest submission package, adjusted to the verified rules of the specific opportunity.
Ready to practice?