🗺️ O workflow EPIV
O maior problema do vibe coding não é a qualidade do código gerado — é a falta de processo. Sem estrutura, as sessões se tornam caóticas: a IA muda coisas que não deveria, você perde o fio da meada, arquivos ficam inconsistentes. O EPIV (Explore, Plan, Implement, Verify) resolve isso com um workflow deliberado de 4 fases.
🔄 As 4 fases do EPIV
📊 Por que um workflow importa
Times que adotam um workflow estruturado para vibe coding reportam:
- 70% menos retrabalho causado por mudanças não intencionais
- 3x menos bugs chegando à branch principal
- Histórico de git compreensível — qualquer membro do time entende o que foi feito
- Onboarding mais rápido — novos membros entendem o projeto pela documentação gerada pelo agente
🔍 Fase Explore — entenda antes de mudar
Antes de qualquer modificação, instrua o agente a entender o codebase sem modificar nada. Essa fase é especialmente crítica em projetos existentes, mas essencial mesmo em projetos novos maiores de 3 arquivos. O agente que entende o contexto gera código mais consistente.
📝 Prompts de Explore (sem modificar código)
O que você ganha com Explore
- ✓Entendimento do que já existe antes de duplicar
- ✓Identificação de onde adicionar sem quebrar
- ✓Mapeamento de dependências ocultas
- ✓Padrões existentes para o agente replicar
💡 Dica: o modo exploração
No início de cada sessão com um projeto existente, sempre comece com: "Quais foram as últimas mudanças feitas nesse projeto? Onde estava sendo desenvolvido?" O agente vai ler o histórico do git e reconstruir o contexto da sessão anterior.
📋 Fase Plan — planeje antes de escrever
O erro mais caro em vibe coding: deixar a IA implementar sem ter um plano aprovado. A fase Plan força o agente a pensar antes de escrever. Você revisa o plano, identifica problemas na abordagem, e só então dá o sinal verde.
📝 O prompt de planejamento
📊 O que revisar no plano
- → A abordagem faz sentido? A IA pode propor uma solução tecnicamente correta mas desnecessariamente complexa para o seu contexto
- → Arquivos corretos? Às vezes a IA planeja modificar arquivos que você prefere não tocar
- → Dependências esperadas? Se o plano inclui instalar 5 novos pacotes para algo simples, há algo errado
💡 "Aguarde aprovação" como instrução padrão
Adicione "aguarde minha aprovação" em todo pedido de planejamento. Isso impede que o agente, em alguns editores, comece a implementar enquanto ainda está planejando. A separação entre plano e execução é o coração do EPIV.
⚙️ Fase Implement — execução em partes testáveis
Com o plano aprovado, a implementação começa — mas ainda em partes. A regra da fase Implement: cada passo deve ser testável antes de avançar para o próximo. Não implemente tudo de uma vez, mesmo que o plano cubra a feature completa.
✗ Implement errado
"Implemente todos os 5 passos do plano de uma vez"
Resultado: Uma PR gigante com 30 arquivos alterados. Um bug em qualquer parte é difícil de localizar. Testes falham por razões desconhecidas. Rollback é impossível sem perder tudo.
✓ Implement correto
"Implemente apenas o passo 1 do plano. Vou testar e confirmar antes de continuar."
Resultado: Cada passo é verificável. Bugs são isolados. Commits são pequenos e descritivos. Rollback de qualquer passo é simples.
🔧 Controle de escopo durante a implementação
Durante a implementação, o agente frequentemente "ajuda" além do pedido — refatora código não relacionado, adiciona features não solicitadas, reorganiza arquivos. Use essas instruções para manter o escopo:
💡 A granularidade ideal de um passo
Um bom passo de implementação pode ser testado em menos de 5 minutos. Se levar mais de 10 minutos para testar, o passo está grande demais. Divida. A granularidade fina pode parecer lenta, mas elimina o tempo gasto em debugging de múltiplos problemas sobrepostos.
✅ Fase Verify — valide antes de aceitar
A fase Verify é onde o julgamento humano é insubstituível. O agente pode ter gerado código que compila, passa nos testes e parece correto — mas que tem comportamento indesejado em edge cases, viola requisitos de negócio ou introduz vulnerabilidades. Verificar é diferente de testar.
Verificação funcional
O básico — "funciona?"
Abra o browser, execute o fluxo completo do usuário, clique em cada botão, preencha cada formulário. Não se baseie apenas em "compilou sem erro".
Verificação de edge cases
O que acontece quando algo dá errado?
Teste com dados vazios, dados inválidos, campos com caracteres especiais, conexão lenta (simule no DevTools). O agente raramente implementa tratamento de erro adequado sem ser explicitamente pedido.
Verificação de regressão
O que estava funcionando ainda funciona?
Teste as funcionalidades que existiam antes da mudança. O agente pode ter quebrado algo não relacionado ao mexer em arquivos compartilhados (utils, hooks, stores).
💡 Peça ao agente para criar o checklist de verificação
Antes de implementar, peça: "Qual seria o checklist de verificação que eu deveria usar para confirmar que esse passo funcionou corretamente?". O agente vai listar os casos de teste relevantes — então use essa lista na fase Verify.
🌿 Branches para cada feature
Uma das regras mais importantes do vibe coding profissional: nunca vibe code diretamente na branch main. Cada feature, cada experimento, cada refatoração significativa começa em uma branch dedicada. Isso permite descartar trabalho problemático sem conseqüências.
🌿 Workflow de branches para vibe coding
git checkout -b feat/sistema-de-habitos
git commit -m "feat: formulário de criação de hábito"
git commit -m "feat: lista de hábitos com filtro"
git checkout main
git merge feat/sistema-de-habitos
git checkout main
git branch -D feat/sistema-de-habitos
# Começa de novo sem prejuízo na main
⚠️ O risco de codificar na main
Vibe coding na main sem branches é como fazer experimentos químicos sem óculos de proteção — geralmente fica tudo bem, até o dia que não fica. Quando a IA faz uma mudança que quebra tudo e você não tem commit anterior nem branch de segurança, a única saída pode ser reescrever.
Regra prática: Se você não se sente à vontade para descartar tudo que foi feito nos últimos 30 minutos, você está atrasado em criar uma branch.
📄 Documentação automática
Um dos maiores benefícios subutilizados do vibe coding: pedir ao agente que documente o que fez e por quê. Documentação gerada pela IA é mais fácil de manter, mais consistente em estilo e — surpreendentemente — muitas vezes mais clara do que a escrita por humanos sob pressão de deadline.
📝 Prompts de documentação por tipo
Para funções e componentes:
Para decisões de arquitetura:
Para o CLAUDE.md / .cursorrules:
Para README:
💡 Documentação como parte do Definition of Done
Inclua no seu processo: uma feature só está "pronta" quando a documentação está atualizada. Como o agente escreve documentação rapidamente, esse critério extra adiciona quase zero tempo ao processo — mas transforma projetos vibe coding de caixas-pretas em projetos mantíveis.
✅ Resumo do Módulo 1.6
Próximo Módulo:
1.7 — 🔐 Controle, Qualidade e Segurança Básica — os riscos reais do código gerado por IA e como mitigá-los