# Como fazer vibe coding com segurança: um fluxo prático

URL: https://agentvera.dev/pt/blog/how-to-vibe-code/ · Publicado: 2026-10-22

Como fazer vibe coding sem perder o controle: ideia, spec, passos pequenos, testes, commits, review e deploy, além da escolha de ferramenta, prompts e quando parar.

**Resumo:**

- Vibe coding seguro envolve o ciclo de prompts numa estrutura: uma ideia de um parágrafo com uma lista do que “não entra na v1”, um SPEC.md curto de tarefas numeradas e uma tarefa por prompt.
- Faça commit depois de cada passo que funciona e peça ao agente para rodar os testes e mostrar a saída; voltar atrás é melhor do que pedir de novo que ele conserte o próprio conserto.
- Logins, pagamentos, dados pessoais, migrações de banco de dados e tudo que é público precisam de uma leitura humana do código antes de usuários reais usarem.

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](/pt/glossary/vibe-coding/ "What is 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](/pt/glossary/agentic-coding/ "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:

```bash
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](/pt/blog/ai-code-review/ "AI code review") 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](/pt/agents/claude-code/ "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 `DROP` ou um `UPDATE` sem `WHERE` é 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](/pt/blog/build-website-with-ai/ "Build a website with AI")
- [Criar um MVP de SaaS com IA](/pt/blog/build-saas-mvp-with-ai/ "Build a SaaS MVP with AI")
- [Criar um app de celular com IA](/pt/blog/build-mobile-app-with-ai/ "Build a mobile app with AI")
- [Criar uma extensão do Chrome com IA](/pt/blog/build-chrome-extension-with-ai/ "Build a Chrome extension with AI")
- [Criar um bot do Telegram com IA](/pt/blog/build-telegram-bot-with-ai/ "Build a Telegram bot with AI")
- [Criar uma automação ou scraper com IA](/pt/blog/build-automation-scraper-with-ai/ "Build an automation or scraper with AI")
- [Criar um dashboard de dados com IA](/pt/blog/build-data-dashboard-with-ai/ "Build a data dashboard with AI")
- [Criar uma loja virtual com IA](/pt/blog/build-ecommerce-store-with-ai/ "Build an e-commerce store with AI")
- [Fazer um jogo com IA](/pt/blog/make-a-game-with-ai/ "Make a game with AI")

## Fazendo isso com o AgentVera

Tudo acima funciona com um terminal e o git. O [AgentVera](/pt/download/ "Download 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](/pt/features/checkpoints-and-replay/ "Checkpoints and replay") 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](/pt/features/code-review/ "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](/pt/features/verify/ "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](/pt/features/db-guard/ "DB Guard") analisa as novas migrações ao fim de um turno em busca de instruções arriscadas como `DROP` ou `UPDATE` sem `WHERE`.
- **Previews.** Os [ambientes de preview](/pt/features/preview-environments/ "Preview environments") 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.

## Perguntas frequentes

**Preciso saber programar para fazer vibe coding?** Não para um projeto pessoal pequeno. Você precisa conseguir rodar alguns comandos, repassar uma mensagem de erro ao agente e testar o resultado você mesmo. Quanto mais o projeto importa, mais você precisa de alguém que saiba ler o código.

**Qual é a melhor ferramenta para vibe coding?** Não existe uma única melhor. Agentes de terminal como Claude Code, Codex ou Gemini CLI dão a você um projeto de verdade na sua máquina; agentes de editor como o Cursor deixam você mais perto do código. Escolha um, aprenda os hábitos dele e adicione um segundo só quando precisar de uma segunda opinião.

**Como evito que a IA quebre código que funciona?** Trabalhe em passos pequenos, faça commit depois de cada passo que funciona e peça testes para tudo que for importante. Se uma mudança der errado, volte ao último commit em vez de pedir ao agente que conserte o próprio conserto três vezes seguidas.

**Software feito com vibe coding é seguro para produção?** Só depois que alguém revisar. Logins, pagamentos, dados pessoais, migrações de banco de dados e tudo exposto à internet precisam de uma leitura humana do código, testes reais e uma verificação básica de segurança antes de usuários reais usarem.

**Qual deve ser o tamanho de um prompt de vibe coding?** O suficiente para declarar um objetivo, as restrições e como você vai verificar, geralmente de três a oito linhas. Um único prompt enorme para o app inteiro tende a produzir muito código difícil de revisar.

---

**Sobre o AgentVera.** AgentVera é um app desktop para macOS, Windows e Linux, desenvolvido pela Solviera Teknoloji. Ele roda 18 agentes de programação com IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) lado a lado, por projeto, em terminais reais com as instalações e logins de CLI do próprio usuário. O plano gratuito tem agentes ilimitados. Baixar: https://agentvera.dev/pt/download/ · Preços: https://agentvera.dev/pt/pricing/