🎯 Problem Before Solution
The biggest trap for beginners is rushing to the code. There’s a simple rule to avoid this: 55-5 rule. For every 60 minutes, invest about 55 understanding the problem and only 5 on rushing the solution. Most tutorials do the opposite — and produce apps no one uses.
⏱️ The 55-5 rule
Think of a time budget. Where you spend it determines the quality of what you build:
- •55 min on the problem — who it’s for, what hurts, which result matters.
- •5 min on the solution — when the problem is clear, the solution almost writes itself.
- •Don’t skip the code before knowing what it’s solving.
✓ Start with the problem
- ✓Define who has the problem and why
- ✓Write the desired outcome in one sentence
- ✓Only then think about the screen and the features
✗ The trap of coding too early
- ✗"I'll just start coding and figure it out as I go"
- ✗Tutorials that open the editor in the first minute
- ✗A beautiful app that solves the wrong problem
💡 Practical tip
Before opening the editor, complete the sentence: "This app exists so [who] can achieve [result] without [today's pain point]." If you can't fill it in, you're still within the 55 minutes.
problem × solution
feels the pain
in one sentence
the code early
🥊 AI as a sparring partner → SOP
AI isn’t just for writing code — it’s a great training partner. Instead of asking for a ready-made answer, ask it to challenge your reasoning. After refining the problem, ask for a SOP (operating procedure) that’s short, with a maximum of 800 characters.
Describe the desired result
"This is the result I want: […]." Give the destination, not the route.
Ask for a counterargument
"Challenge my reasoning and help me define the problem clearly." Let the AI find the gaps.
Generate the SOP
"Create an SOP for this, with no more than 800 characters." This short procedure becomes the build plan.
💡 Why limit it to 800 characters
A short SOP forces clarity: it includes only the essentials. It’s easy to paste into a context file and for the agent to reread without “blowing” its memory.
training, not an answer
find gaps
procedure
characters
🎨 Design inspiration
AI is great at design, but it works much better with specificity. Instead of asking "make it look nice," give the agent visual references: screenshots of sites you like. An image communicates intent in seconds.
🎯 Build a curated list
Save a short list of reference websites — Awwwards, Dribbble, Mobbin, Land-book are good starting points. When you build, choose 1 or 2 screenshots that represent the desired visual "feel" and give them to the agent.
screenshot
not “pretty”
curated
clear visual
⚡ Agent Manager & parallel agents
O Agent Manager lets you manage multiple agents and projects at the same time. The rule is simple: each workspace = one project. With agents working in parallel, you move much faster — while one works, you review or start another.
🗂️ One workspace per project
Separating projects into workspaces keeps each context clean and prevents one agent from messing up another's work.
- •Workspace A: the price tracker
- •Workspace B: a personal website
- •Each one with its own agent, context, and history.
| Mode | How it works | Speed |
|---|---|---|
| One agent at a time | you wait for each task | slow |
| Parallel agents | several work together | fast |
| Workspace per project | isolated context | organized |
you see them all
= 1 project
several at once
more production
👥 Agents = Employees
Treat each agent like an employee on your team. The golden rule: give separate jobs. Never assign two agents to the same task — they collide, overwrite each other’s work, and create confusion. It’s like a team where no one does anyone else’s work.
✓ Separate jobs
- ✓Agent A handles the front end
- ✓Agent B handles the database
- ✓Each one with a clear responsibility
✗ Two on the same task
- ✗Edit the same files at the same time
- ✗One undoes what the other did
- ✗Result: conflict and rework
🧠 Think like a manager
Before releasing the agents, make a small “org chart”: list the tasks and assign each one to an agent. If two tasks touch the same file, do them in sequence, not in parallel.
with function
separate jobs
separate files
each to their own
📋 Planning Mode & Inbox
Before letting the agent run, put it in planning mode. It proposes a plan; you review and approve, exactly as you would with an employee. The actions wait for your approval in the inbox.
The agent plans
In planning mode, it describes the steps before touching any files.
You review
Read the plan like a manager: does it make sense? Is anything missing? Is it in the right order?
Approve in the inbox
Sensitive actions require approval. Only then does the agent carry out what was agreed.
🛡️ Why approve first
Approving the plan keeps the agent from spending hours building the wrong thing. Five minutes of review can save a whole round of rework.
before acting
as a manager
approves actions
only after approval
📝 Context File (Gemini.md)
An agent’s context window is limited — on long projects, it “overflows” and it forgets what you agreed on. The solution is a context file (e.g., Gemini.md): a .md with the project rules that the agent always reread.
| File | Saves | What for |
|---|---|---|
| Gemini.md | rules: source, colors, purpose | maintain the project's standard |
| research.md | reusable research | not research the same thing twice |
# Projeto: rastreador de preços Propósito: acompanhar 5 produtos e mostrar a variação de preço de forma calma. Fonte: Inter. Cores: fundo escuro, acento azul. Regra: nada de alertas barulhentos; UI sóbria. Banco: Supabase (tabela "produtos").
💡 Long-term memory
The context file survives the window filling up: even when the agent "forgets" the conversation, it rereads the Gemini.md and gets back on track. It’s the project’s durable memory.
project rules
don’t forget
when it overflows
saved research
🔌 MCP + Supabase
For the app to store real data, it needs a database. The MCP (Model Context Protocol) is the “universal language” that lets apps and services talk to each other. Connect a database (Supabase) via token, and the agent creates the project and writes the SQL alone.
🔗 The path to the data
- 1.Enable the Supabase MCP and paste the token of access.
- 2.Ask the agent: “create a project called [name].”
- 3.It creates the tables and writes the SQL — you don’t type database code by hand.
universal language
the database
the connection
the agent writes
🔬 Practical example
Let’s build an app that tracks 5 products and shows price changes calmly and beautifully. The path follows the module’s exact order:
- Define the problem — “I want to know when it’s worth buying, without anxiously getting an alert for every cent.”
- Generate the SOP (≤ 800 characters) with AI as a sparring partner.
- Visual inspiration — choose 1 screenshot of a sober dashboard you admire.
- Build locally — agent in planning mode, database in Supabase via MCP, app running on localhost.
Notice: 4 of the 5 steps happen before "building the app." That’s where quality comes from.
🏋️ Exercise
Take one of your ideas and take it from problem to localhost:
- Define the problem with AI — ask it to challenge your reasoning.
- Generate an SOP of no more than 800 characters.
- Build a simple app running on localhost — start small, with just one screen.
In Track 2.2, we'll publish this same app to the world.
⚡ Ready-made prompts
Copy, paste into your AI assistant, and adapt to your use case.
This is the desired outcome: "[describe the outcome you want]". Challenge my reasoning and help me clearly define the problem. Ask any questions you need before proposing a solution.
Create an SOP for this, with no more than 800 characters. List the steps in order and the expected result of each one.
Pesquise o que os melhores [tipo de app] têm em comum (estrutura, telas, padrões de uso) e salve num arquivo research.md que eu possa reusar nos próximos projetos.
Usando o MCP do Supabase, crie um projeto chamado [nome]. Crie as tabelas necessárias e escreva o SQL você mesmo.
✅ Module summary
Next module:
2.2 — Publish and maintain your app