O fluxo de trabalho de vibe coding: da ideia ao deploy com Claude Code (2026)

O que é vibe coding? (recapitulando rápido)

Vibe coding é um jeito de construir software em que você descreve o que quer em linguagem simples, deixa a IA gerar o código e então julga o resultado por ele rodar do jeito que você esperava, em vez de digitar cada linha à mão. Andrej Karpathy cunhou o termo no começo de 2025, e ele virou rapidamente uma forma comum de trabalhar tanto para indie hackers quanto para desenvolvedores profissionais. Resumindo: você é quem decide e revisa, e a IA é quem faz o trabalho.

A única coisa que impede o vibe coding de virar uma bagunça é um fluxo de trabalho — não disparar prompts por impulso. Se você ainda não está firme no básico, leia primeiro o que é vibe coding e depois volte aqui para aprender um processo repetível. Este artigo foca no "como" da programação assistida por IA do início ao fim.

Visão geral do fluxo de vibe coding: 6 passos da ideia ao deploy

O fluxo de trabalho de vibe coding inteiro cabe em seis passos, cada um com uma saída clara e um "portão de decisão" — o ponto em que você para e decide se segue em frente ou volta e conserta algo. Esses portões de decisão são exatamente o que mantém a IA na linha, em vez de ela sair à deriva no "clima".

Esses seis passos se encaixam em um modelo mental mais enxuto — o framework brainstorm -> plan -> cook -> ship. O brainstorm cobre os passos 1-2, o plan é o passo 3, o cook é o passo 4 e o ship fecha os passos 5-6. Eu ilustro o fluxo com o Claude Code — uma CLI agêntica que consegue ler um repositório, editar vários arquivos e rodar comandos numa única passada (documentação do Claude Code, Anthropic) — mas os mesmos princípios valem para o Cursor ou o Copilot.

Passo 1 — Clarear a ideia e fazer brainstorm

O erro mais comum é abrir um terminal e sair digitando um prompt na hora. O resultado é que a IA adivinha o que você quis dizer, adivinha errado, e você passa meio dia consertando coisas que nunca deviam ter existido. O Passo 1 barra o AI slop na raiz: você precisa saber o que quer antes de dizer à IA o que fazer.

Antes de digitar um único prompt, responda quatro perguntas:

• Resultado (Outcome): quem este produto ajuda, e a fazer o quê? Diga em uma frase.
• Restrições (Constraints): qual linguagem/stack, onde roda, se precisa funcionar offline, o seu orçamento de tempo.
• Não-objetivos (Non-goals): o que você deliberadamente não vai fazer nesta versão (crucial para a IA não "inventar" extras).
• Critérios de "pronto": onde você olha para saber que chegou lá — por exemplo, "o usuário consegue adicionar uma despesa e ver o total atualizar".

Exemplo ilustrativo: a ideia "um controle de despesas pessoal". Resultado: ajudar uma pessoa a registrar gastos do dia a dia rapidamente e ver um total mensal. Restrições: página web estática, roda no navegador, guarda os dados localmente, dá para construir em uma tarde. Não-objetivos: sem login, sem sincronização na nuvem, sem gráficos sofisticados. Critérios de pronto: você consegue adicionar uma despesa e ver a lista e o total mensal. Essas quatro respostas são a "constituição" que todo prompt seguinte tem que seguir.

Passo 2 — Escrever um spec/briefing para a IA (não só um "prompt vago")

Este é o passo que faz a maior diferença na qualidade. Um prompt vago como "me faz um app de despesas" te dá um resultado aleatório. Um spec estruturado te dá um resultado que fica perto do que você quis dizer. Você escreve o spec uma vez e reutiliza tanto no planejamento quanto no cook.

Aqui está um template de spec/briefing que você pode copiar e colar e preencher (coloque em um arquivo SPEC.md ou CLAUDE.md na raiz do repositório para o Claude Code ler automaticamente):

# SPEC - Expense tracker

## Goal
A single-page web app that lets an individual quickly log expenses and view a monthly total.

## User flow
1. The user enters an amount + category + date, then clicks "Add".
2. The expense appears in the list, newest on top.
3. The current month's total shows at the top of the page and updates automatically.

## Sample data
- { amount: 12.50, category: "Food", date: "2026-08-09" }
- { amount: 30.00, category: "Transit", date: "2026-08-08" }

## Technical constraints
- Plain HTML + CSS + JavaScript, no framework.
- Persist with localStorage, no backend.
- Works when you open index.html directly.

## Test criteria (definition of "done")
- Add an expense -> it appears in the list.
- Reload the page -> the data is still there.
- The monthly total matches the entered expenses.

## Non-goals
- No login, no cloud sync, no charts.

Quando o risco é baixo (um protótipo, uma ferramenta interna, uma página estática) você pode fazer vibe com bastante liberdade. Mas quando o risco é alto — dados de usuário, lógica que mexe com dinheiro, integrações de terceiros — mude para desenvolvimento guiado por spec: um spec mais detalhado, critérios de aceitação apertados e uma IA que precisa segui-los em vez de improvisar. Quanto mais claro o spec, menos AI slop você recebe.

Passo 3 — Planejar e dividir

Não peça para a IA "escrever o app inteiro de uma vez". Quanto mais o modelo tem que segurar na cabeça de uma só vez, maior a chance de ele pular coisas, se contradizer ou inventar APIs que não existem. Em vez disso, peça para a IA planejar antes de codar, e então você revisa esse plano.

No Claude Code, um bom prompt de planejamento fica assim:

Read SPEC.md. DO NOT write code yet.
Propose a plan: list the modules to build,
the order to implement them, and for each module
spell out its input/output. Then stop and wait for my approval.

Para o app de exemplo, um plano razoável o divide em módulos pequenos para você conferir o "clima" de cada pedaço:

1. Estrutura HTML + formulário de entrada — construir a interface, ainda sem lógica.
2. Salvar e ler o localStorage — adicionar/ler dados, ainda sem totais.
3. Renderizar a lista — mostrar as despesas salvas.
4. Calcular o total mensal — a lógica de soma + atualizar a cada adição.

Quebrar o trabalho tem três benefícios: você pode aprovar cada passo, quando algo quebra o espaço de busca é estreito, e você mantém o controle em cada portão de decisão em vez de receber de volta um blocão de código difícil de revisar.

Passo 4 — Cook: deixe a IA escrever código um módulo por vez

"Cook" é quando a IA de fato escreve código conforme o plano aprovado. Com o Claude Code, uma sessão típica de cook segue assim: o agente lê o repositório e o SPEC.md -> edita ou cria arquivos para o módulo atual -> roda comandos/testes -> reporta o resultado -> espera você aprovar seguir para o próximo módulo. Você trabalha um módulo por vez; você nunca "solta" o app inteiro.

O prompt de cook para o primeiro módulo, amarrado ao plano:

Implement module 1 from the plan: the HTML shell + input form
(amount, category, date, Add button). No save logic yet.
When you're done, briefly describe what you created.

Algumas dicas de checkpoint enquanto você faz o cook:

• Rode na hora depois de cada módulo em vez de esperar até o fim — pegar o desvio cedo é muito mais barato.
• Leia o diff que a IA acabou de produzir. Se ela mexeu num arquivo fora do escopo do módulo, pergunte por quê.
• Meta a mão quando a IA repetir o mesmo erro duas vezes seguidas: consertar um pontinho diretamente costuma ser mais rápido do que reexplicar em palavras.
• Mantenha os commits pequenos, um por módulo, para ser fácil reverter se um módulo posterior quebrar um anterior.

Passo 5 — Testar, revisar e evitar o AI slop

Código que roda não é a mesma coisa que código bom. Este passo é onde você separa um produto de uma pilha de "AI slop" — código que parece ok mas é inchado, difícil de manter ou silenciosamente errado. A regra de ouro: não publique o que você não entende.

Um checklist rápido de revisão depois de cada sessão de cook:

• Rode os testes contra os critérios de "pronto" que você escreveu no spec. Para o app de exemplo: adicione uma despesa, recarregue a página, confira o total mensal.
• Leia e entenda o código, não só passe o olho. Se houver um trecho que você não consegue explicar, peça para a IA explicar ou reescrever de forma mais simples.
• Cace código morto: funções que ninguém chama, bibliotecas instaladas mas não usadas, tratamento de casos que não podem acontecer.
• Confira as bordas: entrada vazia, números negativos, datas mal formatadas — a IA costuma esquecer esses casos.

Para se aprofundar nos "cheiros" que a IA tende a produzir e em como barrá-los, veja como evitar o AI slop. Quando os testes ficam vermelhos ou o código se comporta de forma estranha, um processo metódico de depuração está em depurando com IA — não cole só o erro e diga "conserta", dê contexto à IA e faça ela diagnosticar a causa primeiro.

Passo 6 — Ship: publique um produto que funciona

Muitos artigos de vibe coding param no protótipo. Mas o "ship" é quando a ideia vira um produto que outras pessoas conseguem realmente usar. Ir do protótipo a um deploy de verdade envolve algumas coisas:

1. Build: se há uma etapa de empacotamento (bundler, framework), rode o build e corrija os avisos antes de levar para qualquer lugar.
2. Configurar env: tire chaves/variáveis de ambiente de dentro do código; não faça commit de segredos no repositório.
3. Hospedagem: escolha o lugar certo para rodar — uma página estática sobe em uma hospedagem estática em poucos minutos; um app com backend precisa de uma plataforma que suporte um servidor.
4. Docs: peça para a IA escrever um README a partir do próprio spec + código — como rodar, como configurar, limitações atuais.

Uma observação honesta para você não se enganar: um bom protótipo é uma ferramenta de decisão, não uma versão de produção em miniatura. Ele ajuda você a confirmar se a ideia vale a pena. Depois que tiver certeza de que vale, invista tempo endurecendo o núcleo (segurança, tratamento de erros, testes) antes de abri-lo para muitos usuários reais.

Um exemplo real: construindo um app pequeno pelos 6 passos

Juntando tudo, veja como o controle de despesas percorre o fluxo inteiro. Este é um passo a passo que eu rodei com o Claude Code, apresentado etapa por etapa para você imaginar o ritmo do trabalho.

• Passo 1 (ideia): fechar resultado/restrições/não-objetivos/critérios de pronto como acima — web estática, localStorage, uma tarde.
• Passo 2 (spec): salvar o mesmo template SPEC.md acima na raiz do projeto.
• Passo 3 (plan): pedir ao Claude Code para ler o spec e propor 4 módulos; aprovar a ordem de implementação.
• Passo 4 (cook): fazer um módulo por vez. Depois do módulo do "total mensal", rodar e ver o total atualizar corretamente quando uma nova despesa é adicionada.
• Passo 5 (testar e revisar): rodar os três critérios de "pronto"; pegar um bug de caso extremo — digitar um número com vírgula bagunça o total — e pedir para a IA normalizar a entrada antes de somar.
• Passo 6 (ship): como é uma página estática, é só subir a pasta para uma hospedagem estática; pedir para a IA gerar um README com instruções de execução.

O resultado: um app de uma página que adiciona, mostra e soma despesas, com dados que sobrevivem a um reload — construído tranquilamente em uma tarde. O que importa não é o app ser "impressionante", mas o fluxo ser repetível para o próximo projeto.

Quando o vibe coding falha (uma seção honesta sobre limites)

Vibe coding não é um martelo para todo prego. Há áreas em que você deveria desacelerar, mudar para um trabalho mais rígido guiado por spec, ou escrever você mesmo:

• Autenticação e autorização: um buguinho pode escancarar seus dados. Não faça "vibe" na parte de login/controle de acesso.
• Pagamentos e cobrança: um erro aqui significa dinheiro de verdade perdido ou confiança perdida. Isso precisa de um spec apertado, testes minuciosos e uma revisão manual.
• Dados sensíveis: informações pessoais, médicas, financeiras — erros trazem consequências legais.
• Sistemas grandes e fortemente acoplados: quando mudar um ponto afeta muitos outros, a IA quebra facilmente coisas que não consegue "enxergar".
• Quando você não consegue ler o código gerado: se você não consegue revisar, não consegue se responsabilizar por ele — é sinal de parar.

Dois riscos silenciosos que vale lembrar: alucinação (a IA inventa APIs, funções ou resultados que não existem) e dívida técnica (código que roda hoje mas acumula emaranhados que tornam o amanhã mais difícil). Os dois são mantidos sob controle por esses mesmos portões de decisão em cada passo — não por confiança cega na saída.

Acelerando o fluxo com um kit pronto (AgentKit)

Os seis passos acima rodam mais rápido e com mais confiabilidade quando cada um tem uma ferramenta feita sob medida à mão — em vez de você inventar um prompt de brainstorm, montar um template de spec na unha e cutucar a IA para planejar toda vez. É aí que kits prontos de skill/subagent/workflow para o Claude Code mostram o seu valor.

Obs.: AgentKit aqui significa o kit para o Claude Code (agentkit.best, a CLI ak), que é diferente do AgentKit da OpenAI. O Engineer Kit — 20% de desconto, agora $79.20 reúne mais de 60 skills e mais de 30 workflows que cobrem exatamente os passos deste processo (brainstorm, plan, cook, test, code review) por $79.20 — a página não lista nenhuma mensalidade, além de garantia de reembolso e atualizações vitalícias. Se você quiser ver qual skill se encaixa em qual passo, leia a análise do Engineer Kit antes de decidir. Um kit não roda o fluxo por você — ele só tira o andaime repetitivo que você teria que reconstruir toda vez.

Perguntas frequentes (FAQ)

Quantos passos tem o fluxo de trabalho de vibe coding?

O fluxo tem 6 passos repetíveis: clarear a ideia e fazer brainstorm, escrever um spec/briefing para a IA, planejar e dividir o trabalho, cook (deixar a IA codar um módulo por vez), testar e revisar para evitar o AI slop, e ship (publicar o produto). Cada passo tem um portão de decisão para você conferir antes de seguir.

Precisa saber programar para fazer vibe coding?

Você pode começar sem ser um programador forte, mas para publicar um produto confiável precisa conseguir ler e entender o código que a IA gera. A regra é: não publique o que você não entende. Quanto mais código você consegue ler, melhor você revisa e mais bugs silenciosos você evita.

Como o vibe coding difere da programação tradicional?

Na programação tradicional você digita cada linha; no vibe coding você descreve o que quer em linguagem simples para a IA gerar, enquanto você conduz e dá o aval. Seu papel muda de "quem escreve" para "quem decide e revisa".

Qual ferramenta usar para vibe coding?

O Claude Code combina com um fluxo agêntico de ponta a ponta porque lê o repositório, edita vários arquivos e roda comandos numa passada. O Cursor e o GitHub Copilot também dão conta, e são fortes nas sugestões dentro do editor. Escolha pelos seus hábitos; o fluxo de 6 passos vale para os três.

Um protótipo feito com vibe coding pode ir para produção?

Sim, para produtos pequenos e de baixo risco. Mas um bom protótipo é uma ferramenta de decisão, não uma versão de produção em miniatura. Antes de abri-lo para muitos usuários, endureça segurança, tratamento de erros e testes no núcleo.

Como evitar o AI slop ao fazer vibe coding?

Escreva um spec claro logo de cara, quebre o trabalho em pedaços pequenos e revise cada módulo: rode testes contra os critérios de "pronto", leia e entenda o código em vez de passar o olho, apague código morto e confira os casos extremos. Não publique nada que você não consiga explicar.

Conclusão + próximos passos

O fluxo de trabalho de vibe coding não é mágica — é uma disciplina de seis passos que deixa você usar IA mantendo o controle: ideia -> spec -> plan -> cook -> test -> ship, com um portão de decisão em cada etapa para barrar o AI slop. Seu próximo passo depende do que você precisa: se quer um spec mais apertado para um projeto de alto risco, leia desenvolvimento guiado por spec; se quer o modelo mental enxuto, veja brainstorm -> plan -> cook -> ship; e para manter seu código limpo, aprenda como evitar o AI slop.