Para fazer vibe coding, você descreve o que quer a um agente de código em linguagem simples, deixa que ele escreva e rode o código, confere o resultado você mesmo e segue conduzindo com mensagens curtas. Fazer isso com segurança significa adicionar um pouco de estrutura em volta desse ciclo: uma spec curta, passos pequenos, testes, um commit no git depois de cada passo que funciona e um review antes de qualquer coisa ir ao ar.
O termo vem de um post de Andrej Karpathy de fevereiro de 2025 sobre deixar a IA escrever o código enquanto você “esquece que o código sequer existe”; o Collins Dictionary depois o escolheu como Palavra do Ano de 2025. Para a definição, a história e os riscos, veja o que é vibe coding. Este post é sobre o como.
O fluxo num relance
| Passo | O que você faz | O que você ganha |
|---|---|---|
| 1. Ideia | Escreve um parágrafo: para quem é, o que faz | Um escopo ao qual você pode dizer não |
| 2. Spec | Pede ao agente para transformar isso num plano curto | Uma lista de tarefas pequenas e ordenadas |
| 3. Passos pequenos | Uma tarefa por prompt | Mudanças pequenas o bastante para conferir |
| 4. Testes | Pede testes para tudo que importa | Um jeito de saber que ainda funciona |
| 5. Commit | git commit depois de cada passo que funciona | Um ponto seguro para onde voltar |
| 6. Review | Lê o diff ou pede a outro modelo que leia | Menos surpresas depois |
| 7. Deploy | Publica numa hospedagem com builds de preview | Um link ao vivo para compartilhar |
Os passos parecem óbvios no papel. Pulá-los é o que transforma uma tarde divertida num fim de semana de “há uma hora funcionava”.
Passo 1: Comece com uma ideia pequena
Escreva a ideia em poucas frases antes de abrir qualquer ferramenta. Diga quem é o usuário, a única coisa que o app precisa fazer e o que fica fora do escopo da primeira versão.
Uma página onde meu clube de corrida registra as distâncias semanais. Os membros entram com um magic link, adicionam uma corrida e veem um ranking do mês. Sem pagamentos, sem app de celular, sem painel de admin na v1.
Essa última frase é a que mais importa. Os agentes adoram construir funcionalidades que você não pediu; uma lista clara do que “não entra na v1” mantém o projeto pequeno o bastante para terminar.
Passo 2: Transforme numa spec curta
Não peça o app ainda. Peça um plano:
Leia esta ideia. Proponha uma stack, uma estrutura de pastas e uma lista numerada de 6 a 10 tarefas pequenas para construir a v1. Cada tarefa deve caber numa sessão e ser testável sozinha. Não escreva código ainda.
Leia o plano e conteste. A stack é algo que você consegue hospedar de graça? Alguma tarefa na verdade são três? Salve a versão final como SPEC.md (ou PLAN.md) no repositório para que toda sessão futura possa lê-la. Se você usa mais de um agente, um CLAUDE.md ou AGENTS.md curto com os comandos e as regras também ajuda; o agentic coding funciona melhor quando o agente tem o mesmo contexto toda vez.
Passo 3: Construa em passos pequenos
Agora pegue a tarefa 1 e só a tarefa 1:
Faça a tarefa 1 do SPEC.md: configure o projeto e uma página inicial que diga “Hello”. Rode e me diga a URL.
Depois abra, confira e passe para a tarefa 2. Um bom ritmo é uma tarefa, uma conferência, um commit. Se um passo gera mais do que algumas centenas de linhas de mudança, provavelmente era grande demais; da próxima vez, peça ao agente para dividi-lo.
Quando algo quebrar, cole o erro exato, não uma descrição dele. “Não funciona” faz o agente adivinhar; o stack trace completo geralmente não.
Passo 4: Peça testes para o que importa
Você não precisa de 100% de cobertura num projeto paralelo. Precisa de testes nas partes que machucariam se quebrassem em silêncio: a matemática do ranking, o fluxo de login, tudo que toca dinheiro ou dados.
Adicione testes para o ranking mensal: empates, um membro sem corridas, corridas no último dia do mês. Rode e me mostre a saída.
Peça ao agente para rodar os testes e mostrar a saída, não só escrevê-los. Assim, quando você mudar algo depois, “rode os testes” vira sua verificação de segurança de uma linha.
Passo 5: Faça commit depois de cada passo que funciona
O git é o botão de desfazer do vibe coding. Depois de cada passo que funciona:
git add -A
git commit -m "Add monthly leaderboard with tests"Ou apenas diga ao agente: “Faça commit disso com uma mensagem curta.” Quando uma mudança posterior der errado, git diff mostra o que mudou e git restore . (ou um reset para o último commit) leva você de volta. Isso é melhor do que pedir ao agente pela quarta vez que conserte o próprio conserto, o que tende a empilhar um remendo sobre outro.
Passo 6: Revise antes de ir ao ar
O vibe coding funciona porque você não lê cada linha enquanto constrói. Antes do deploy, alguém precisa ler. No mínimo:
- Passe os olhos no diff de tudo desde o último deploy.
- Peça a um segundo agente ou modelo que revise em busca de bugs e problemas de segurança, sem o histórico de chat do primeiro agente. Um leitor novo pega o que o autor não vê.
- Navegue pelo app você mesmo num celular e num notebook.
O guia de code review com IA se aprofunda no que procurar e em como configurar.
Passo 7: Deploy
Para a maioria dos projetos web feitos com vibe coding, uma hospedagem que faz o build a partir de um repositório do GitHub é o caminho fácil: Vercel, Netlify ou Cloudflare Pages para sites estáticos e frameworks como Next.js ou Astro. Faça push para uma branch, receba um link de preview, confira e faça merge para o deploy. Guarde os segredos nas configurações de ambiente da hospedagem, nunca no repositório.
Escolhendo uma ferramenta
| Tipo | Exemplos | Bom para |
|---|---|---|
| Agentes de terminal | Claude Code, Codex, Gemini CLI | Projetos completos na sua máquina, rodar comandos, repositórios reais |
| Agentes de editor | Cursor | Ficar perto do código enquanto a IA edita |
| Construtores de apps no navegador | Vários construtores hospedados | Uma demo rápida com hospedagem incluída |
Agentes de terminal e de editor deixam você com um repositório de código normal que é seu; construtores hospedados são mais rápidos para começar, mas mantêm o código na plataforma deles. Se estiver em dúvida, comece com um agente de terminal, como o Claude Code, e use-o num projeto pequeno inteiro antes de testar outros.
Prompts que funcionam
Bons prompts de vibe coding têm o mesmo formato: um objetivo, as restrições e como verificar.
| Em vez de | Tente |
|---|---|
| “Faça um app de hábitos para mim” | “Faça a tarefa 3 do SPEC.md: o formulário de adicionar hábito. Valide que o nome não está vazio. Rode os testes ao terminar.” |
| “Quebrou, conserta” | “Clicar em Save mostra este erro: (cole). Encontre a causa antes de mudar o código e depois explique a correção em duas frases.” |
| “Deixa mais bonito” | “Siga o espaçamento e os tamanhos de fonte desta captura de tela. Não mude o layout no celular.” |
| “Adiciona login” | “Adicione login por magic link com a biblioteca de autenticação do SPEC.md. Não guarde senhas. Liste todos os arquivos que você mudou.” |
Três frases valem ser reutilizadas:
- “Não escreva código ainda.” Para planos e investigações.
- “Rode e me mostre a saída.” Para você ver evidências, não afirmações.
- “Liste os arquivos que você mudou.” Para o diff não ter surpresas.
Quando parar com o vibe coding
Vibe coding é ótimo para protótipos, ferramentas internas e projetos pessoais. Desacelere e leia o código você mesmo, ou chame alguém que saiba, quando o trabalho tocar em:
- Logins e permissões. Uma verificação esquecida expõe os dados de todo mundo.
- Pagamentos. Webhooks, reembolsos e casos extremos precisam de testes reais.
- Dados pessoais. A lei de privacidade não se importa com quem escreveu o código.
- Migrações de banco de dados. Um
DROPou umUPDATEsemWHEREé difícil de desfazer em produção. - Qualquer coisa pública com usuários reais. Rate limits, validação de entrada, tratamento de segredos.
Outro sinal: se você já pediu ao agente para corrigir o mesmo bug três vezes e ele continua voltando, pare. Volte ao último commit bom, descreva o problema do zero ou leia essa parte do código você mesmo.
Construa algo
Cada um destes guias segue o mesmo fluxo num projeto concreto:
- Criar um site com IA
- Criar um MVP de SaaS com IA
- Criar um app de celular com IA
- Criar uma extensão do Chrome com IA
- Criar um bot do Telegram com IA
- Criar uma automação ou scraper com IA
- Criar um dashboard de dados com IA
- Criar uma loja virtual com IA
- Fazer um jogo com IA
Fazendo isso com o AgentVera
Tudo acima funciona com um terminal e o git. O AgentVera roda seus agentes de código (Claude Code, Codex, Gemini CLI e outros, com os seus próprios logins) lado a lado em terminais reais e adiciona algumas redes de segurança em volta do mesmo ciclo:
- Desfazer por turno. Os checkpoints tiram um snapshot da pasta de trabalho no início de cada turno, então você pode desfazer um turno pelo menu do painel, e desfazer o desfazer. É um passo atrás mais rápido que um git reset, não um substituto para commits.
- Review automático. Com o code review ativado nas configurações do projeto, um modelo Claude que você escolhe lê as mudanças quando um turno termina e relata os achados com severidade e links arquivo:linha; você pode mandá-los de volta ao agente.
- Conferência contra o que você pediu. O AgentVera Verify (Pro e Team) extrai os critérios de aceitação da sua mensagem e, quando o turno termina, um verificador separado roda testes e marca cada critério como aprovado ou reprovado, com evidências.
- Verificação de migrações. O DB Guard analisa as novas migrações ao fim de um turno em busca de instruções arriscadas como
DROPouUPDATEsemWHERE. - Previews. Os ambientes de preview dão a cada branch seu próprio endereço local e podem capturar telas de celular, tablet e desktop.
- Um só lugar para aprovar. A caixa de revisão reúne o trabalho concluído de todos os agentes para você aprovar ou mandar de volta com uma observação.
Checklist
- A ideia cabe num parágrafo, com uma lista do que “não entra na v1”.
- Um SPEC.md curto com tarefas numeradas fica no repositório.
- Uma tarefa por prompt; cada uma conferida antes da próxima.
- Existem testes para as partes que machucariam se quebrassem.
- Um commit depois de cada passo que funciona.
- O diff foi revisado antes do deploy, de preferência por um modelo novo e por uma pessoa.
- Os segredos estão em variáveis de ambiente, não no repositório.
- Logins, pagamentos, dados pessoais e migrações passaram por uma leitura humana cuidadosa.
Concluindo
Vibe coding hoje é um jeito real de construir software, não só uma piada sobre isso. A diferença entre um protótipo que você mantém e um que você joga fora raramente é o modelo; é se você trabalhou em passos pequenos, fez commits com frequência, testou o que importava e revisou antes de publicar. Guarde a vibe para a construção e a disciplina para as bordas.