Foundations · Studio 01
AvailableFrom Idea to App
Turn an idea into a small first build.
Duration: Two 60-minute meetings
Levels: Starter • Builder • Extension
In this Studio
Big Question
How do you turn a vague idea into something specific enough to build?
AI can build a first version quickly. You need to decide what it should do first.
What You'll Learn
In this Studio, you'll learn to:
- describe who your project is for
- state the goal clearly
- choose a small first version and the features it needs
- decide what to leave out
- give AI clear instructions
- test whether what AI produced matches what you intended
- change AI-generated work instead of simply accepting it
By the end of this Studio
By the end, you will have:
- a completed Build Brief
- a working first version
- at least three meaningful changes you made
- feedback from another student
- at least one improvement based on testing
- an explanation of what you decided, what AI helped with, and how you know it works
Set up Replit
We use Replit for AI4Makers. Set up your account before the Studio if you can. Students under 18 need parent or guardian permission.
Before the Studio:
- Create or sign in to Replit with your school email.
- Have a parent or guardian’s phone number available for verification during signup. If Replit asks for parent verification, complete it with them.
- Make sure Replit Agent opens.
- Make sure you can run an app in Preview.
Our Studio workflow:
Decide → Direct Agent → Inspect → Run → Test → Revise
Today's Plan
- 0–5 min Warm up
- 5–15 min Live build
- 15–40 min Build time
- 40–50 min Test
- 50–60 min Share
How to use AI here
Decide what you want before asking AI to build it.
Tell Agent what you want and ask it to summarize before building. Inspect the result, then run and test it. Make one change at a time.
Notice anything Agent added on its own. You can keep it, change it, or remove it.
Before asking for help with a bug, describe what you expected and what actually happened. Ask Agent what it changed and how to test it.
Before changing anything, briefly summarize my request.
Keep version 1 small. Do not add features I did not request.
Do not rewrite unrelated parts.
After each change, explain what changed and how I should test it.Warm Up
Make me an escape-room game.
What is missing?
- Who is playing?
- What is the goal?
- What can the player do?
- What counts as winning?
- What should the first version include?
- What should we deliberately leave out?
Make those decisions before asking AI to build.
Reference Build
Escape the Space Station
Turn “I want to make an escape-room game” into a small Build Brief.
PLAYER Someone who wants a short puzzle game.
GOAL Escape from a space station.
MUST-HAVE FEATURES One room. Three objects to investigate. One useful clue. One way to escape.
SUCCESS The player discovers the clue and unlocks the exit.
CONSTRAINT The first version has only one room.
A constraint is not a weakness. It prevents version 1 from becoming version 20.
Example: a strong first build request
The locker holds a clue to a four-digit emergency code. The correct code opens the exit.
Build a simple browser-based escape game called "Escape the Space Station."
The player is trapped in one room.
Show three things the player can investigate:
- a computer
- a locker
- an exit door
The locker should reveal a clue to a four-digit emergency code.
The player should be able to enter the correct code to unlock the exit and win.
Keep the first version simple, responsive, and easy to understand.
Do not add:
- additional rooms
- accounts
- multiplayer
- a backend
- external APIs
- AI characters
- an inventory system
- extra features I did not request
Before writing any code, summarize:
1. the player
2. the goal
3. the must-have features
4. the success condition
5. the constraints
After I confirm the plan, build the smallest working version.Build Brief
- Make your Build Brief. Decide before using AI.
- Build the smallest version. Follow your build instructions.
- Make three meaningful changes. Use the examples below.
PROJECT NAME
What are you calling it for now?
PLAYER / USER
Who is this for?
GOAL
What is the player or user trying to accomplish?
MUST-HAVE FEATURES
Choose no more than three to five.
SUCCESS
How will you know the first version works?
CONSTRAINT
Name at least one thing you are deliberately not building yet.
Build Your First Version
- Give your Build Brief to Replit Agent.
- Ask Agent to summarize what it understood before building.
- Confirm the plan.
- Build the smallest working version.
- Run it before asking for more changes.
I want to build:
[ONE-SENTENCE PROJECT IDEA]
Here is my Build Brief:
PLAYER / USER:
[YOUR ANSWER]
GOAL:
[YOUR ANSWER]
MUST-HAVE FEATURES:
[YOUR ANSWER]
SUCCESS:
[YOUR ANSWER]
CONSTRAINTS:
[YOUR ANSWER]
Before coding, summarize what you understood and identify anything that is still unclear.
Do not add features outside this brief.
After I confirm, build the smallest working version.After the first version works
Before adding anything else, compare the app with your Build Brief.
Ask:
- What did I decide?
- What did Agent decide for me?
- Did Agent add anything I did not ask for?
- Do I want to keep it, change it, or remove it?
An extra feature might be useful. You decide whether it belongs.
Look at the current app and compare it with my original Build Brief.
Identify anything you added that was not required by the brief.
Do not change anything yet. Just list those additions.Choose Your Build
Choose a level based on your experience and what you want to try, not your age.
Starter
Build one small complete experience.
For the escape-room reference:
- one room
- three things to investigate
- one useful clue
- one way to win
Make it work from beginning to end.
Builder
Add one new challenge.
Examples:
- a second clue
- an object the player must find first
- an attempt counter
- a simple timer
- a second step before the exit opens
Keep the original game working.
Extension
Change the structure of the experience.
Examples:
- a second room
- two possible endings
- a branching path
- a more complex sequence of clues
- a stronger accessibility option
Change how the game works, not just how it looks.
Do not introduce runtime AI features in Studio 1.
Three Meaningful Changes
Before testing, make at least THREE meaningful choices or changes that make the project yours.
0 / 3 → 1 / 3 → 2 / 3 → 3 / 3
Meaningful examples:
- change a puzzle or interaction
- change a rule
- add or remove a feature
- change how a clue works
- change the success condition
- remove something unnecessary that AI added
Changing only the title, colors, or fonts does NOT count.
Must Do
Complete these before the end of the meeting:
-
Complete a Build Brief before generating the first version.
-
Build or customize a working first version.
-
Make at least three meaningful choices or changes.
-
Be able to explain the goal and success condition.
-
Test the project with another student.
-
Make at least one improvement based on what happened during testing.
A small working project is better than a large unfinished one.
Test
Give your project to another student. Do not explain it first.
Tester questions
- What do you think the goal is?
- Could you tell what to do?
- Could you reach the end/success condition?
- Where did you hesitate?
- Did anything surprise you or behave unexpectedly?
Watch. Don’t defend the project.
Choose one problem to improve. Make the improvement before Share if you can.
FINISH · IMPROVE · EXTEND
Use the same 60-minute rhythm to work on your existing project.
Open your project. Write down one thing that works and one thing that needs work.
Choose: FINISH · IMPROVE · EXTEND
Watch a targeted change to the Space Station project.
Do NOT ask AI to rebuild the project.
Example Replit request:
The game already works.
Make ONE change only:
When the player enters an incorrect emergency code, show this message:
“Code rejected. Check the clues and try again.”
Do not change the layout, visual design, puzzle, correct code, or any other behavior.
Before making the change, tell me briefly what you plan to change.
After making the change, tell me exactly what changed and how I should test it.Choose:
FINISH Get the Starter version working completely.
IMPROVE Fix the most important problem discovered during testing.
EXTEND Add one Builder or Extension challenge.
Do not start over.
Test the change with another student. Did it fix the problem? Does the old behavior still work?
For the example, try an incorrect code, then the correct code.
Maker Check
Before you finish, can you answer these?
- What did you decide? Name your player or user, the goal, and the smallest version you chose to build.
- What did AI help with?
- What did you change or reject? Include any changes you made after testing.
- How did you know the result worked? Describe what happened when another student tried it.
Can you point to one part of the app and explain what it does? Name one decision Agent made on its own.
You do not need to explain every line of generated code in Studio 1.
Level Up
If you finish early, choose one improvement instead of simply adding more features:
- Make one interaction clearer.
- Remove something unnecessary.
- Make one confusing part easier for a new user.
- Improve one part based on peer testing.
- Add one Builder-level challenge only after the Starter version works reliably.