⚙️ Setup em 10 minutos
A barreira de entrada para vibe coding é menor do que parece. Em 10 minutos você consegue ter um ambiente funcional. O segredo é não instalar mais do que o necessário — adicione ferramentas conforme o projeto exigir, não antes.
Baixe o Cursor (cursor.com)
~2 min
Versão gratuita inclui 2.000 completions por mês — suficiente para começar. Instale como qualquer aplicativo. Ele detecta automaticamente as extensões do VS Code que você já tem.
Configure o modelo padrão
~1 min
Em Settings → Models, selecione claude-sonnet-4-6 como padrão. Para tarefas simples, claude-haiku é mais rápido e barato. Para planejamento complexo, use claude-opus pontualmente.
Crie uma pasta de projeto e abra no Cursor
~1 min
File → Open Folder. Selecione uma pasta vazia ou o projeto existente. O Cursor vai indexar os arquivos — esse índice é o que permite o agente entender o projeto inteiro.
Crie o arquivo .cursorrules
~5 min — mas vale cada segundo
Na raiz do projeto, crie .cursorrules e defina: stack tecnológica, convenções de código, contexto do projeto. Esse arquivo é lido pelo agente em toda sessão.
💡 Para plataformas prompt-to-app
Se você escolheu Lovable ou Bolt.new, o setup é ainda mais simples: crie uma conta e abra o browser. Não é necessário instalar nada. Use essa opção se o objetivo é validar uma ideia antes de se comprometer com um ambiente de desenvolvimento local.
🎯 Escolhendo o projeto certo para começar
O projeto inicial tem que ser pequeno o suficiente para terminar em um dia e real o suficiente para ser útil. Projetos didáticos sem propósito real (um clone do Twitter para aprender) são menos eficazes do que resolver um problema que você realmente tem.
✓ Projetos ideais para começar
- ✓Dashboard para dados que você já acompanha manualmente
- ✓Formulário de coleta que você preenche em planilha hoje
- ✓Script que automatiza uma tarefa repetitiva sua
- ✓Landing page simples para um produto ou serviço
- ✓Lista de tarefas com funcionalidade específica que você precisa
✗ Evite para o primeiro projeto
- ✗Clones de apps complexos (Instagram, Uber, WhatsApp)
- ✗Sistemas de pagamento ou financeiros
- ✗Apps que requerem integrações com 5+ serviços externos
- ✗Sistemas em tempo real (chat ao vivo, colaboração simultânea)
- ✗Qualquer coisa que "vai ser o próximo unicórnio"
📊 O critério do "testável hoje"
Um bom primeiro projeto responde "sim" a todas estas perguntas:
- 1. Consigo descrever o que ele faz em uma frase?
- 2. Existe uma versão mínima que funciona sem backend? (HTML + JavaScript puro)
- 3. Vou conseguir testar se funcionou sem precisar de outros usuários?
- 4. Consigo definir quando ele está "pronto"?
✍️ O primeiro prompt — descrevendo o que você quer
O primeiro prompt define o ritmo do projeto. Um bom primeiro prompt não tenta descrever o app inteiro — ele define o contexto, a stack e a funcionalidade central. Pense nele como um briefing para um desenvolvedor que nunca viu seu projeto.
📝 Anatomia do primeiro prompt
💡 O poder do "não precisa agora"
Listar explicitamente o que você não quer é tão importante quanto listar o que você quer. A IA tende a adicionar funcionalidades que "fazem sentido" no contexto, o que aumenta a complexidade desnecessariamente no primeiro dia.
✗ Prompt fraco
Resultado: A IA vai inventar decisões de stack, incluir autenticação, banco de dados remoto, animações complexas — tudo sem você pedir.
✓ Prompt forte
Resultado: Exatamente o que você pediu, sem surpresas.
🔄 Iteração na prática
Depois do primeiro prompt, entra o ciclo que vai definir sua produtividade: aceitar → testar → ajustar → repetir. Cada rodada do ciclo deve resolver um problema específico e ser pequena o suficiente para testar em minutos, não horas.
🔄 O ciclo em detalhes
📊 Como dar feedback eficaz à IA
Feedback ruim:
Feedback bom:
💡 Velocidade do ciclo como indicador
Se cada ciclo de iteração está levando mais de 15 minutos, o escopo está grande demais. Divida o problema em partes menores. Se está levando menos de 2 minutos, você pode estar iterando em algo muito trivial — vale aumentar o escopo do próximo passo.
🐛 Quando o erro aparece — copiar e colar de volta
A técnica mais subestimada e mais poderosa do vibe coding: quando o código quebra, copie o erro completo e cole diretamente no chat. A maioria das pessoas tenta descrever o erro em palavras — perde tempo e perde contexto. A mensagem de erro é exatamente o que o agente precisa.
🔧 O processo em 3 passos
Tab "Console" para erros de JavaScript, tab "Network" para erros de API. Selecione e copie a mensagem de erro completa, incluindo o stack trace.
[COLE O ERRO AQUI]"
O agente vai diagnosticar a causa raiz e propor a correção. Aplique, teste novamente. Se o erro persistir, repita o processo com o novo erro.
📊 Por que isso funciona tão bem
- • Stack traces contêm o arquivo, linha exata e tipo do erro — informação suficiente para diagnóstico preciso
- • Os LLMs foram treinados em milhões de issues e bug reports — eles reconhecem padrões de erro mais rápido do que humanos
- • Erros de TypeScript, ESLint e testes têm mensagens estruturadas que os modelos decodificam com alta precisão
- • Esse ciclo resolve ~80% dos bugs de front-end sem precisar entender o código
💾 Salvando o progresso — commits estratégicos
Git é a sua rede de segurança. Em vibe coding, onde mudanças podem ser grandes e rápidas, commits frequentes são proteção contra desastres. A regra é simples: se o que está na tela está funcionando, commite agora. Não espere uma versão "perfeita".
📋 Estratégia de commits para vibe coding
⚠️ O cenário de desastre mais comum
O agente reescreve um componente e quebra algo que estava funcionando. Sem commit anterior, não há como voltar. Com commit, é um git checkout HEAD arquivo.tsx.
16 dos 18 CTOs consultados sobre desastres com vibe coding mencionaram "aceitar mudanças sem commit prévio" como fator contribuinte.
🏁 Quando o primeiro projeto está "pronto"
"Pronto" em vibe coding não significa perfeito — significa funcional para o propósito original. Definir critérios de conclusão antes de começar evita o temido "feature creep" (adicionar funcionalidades infinitamente porque é fácil pedir à IA).
✅ Checklist de conclusão do primeiro projeto
📊 O que fazer após o primeiro projeto
- Mostre para alguém real — o feedback externo revela o que você está cego de tanto olhar
- Documente o que aprendeu — qual prompt funcionou melhor? Qual abordagem da IA foi errada?
- Decida: melhorar ou recomeçar — às vezes a V1 serve de aprendizado e a V2 é melhor construída do zero
- Compartilhe — postar o que você fez em 1-2 dias impressiona e gera feedback valioso
💡 O critério definitivo
Seu primeiro projeto está pronto quando você usaria ele ao invés de como resolvia o problema antes. Se ainda prefere a planilha, o post-it ou o processo manual — o projeto não resolve o problema real ainda.
✅ Resumo do Módulo 1.4
Próximo Módulo:
1.5 — 💬 Prompt Engineering Básico — como escrever prompts que geram resultados precisos