⚡ Fundamentos do Vibe Coding

O termo "vibe coding" foi cunhado por Andrej Karpathy em 1 de fevereiro de 2025 num post no X que viralizou. Karpathy é cofundador da OpenAI e ex-diretor de IA da Tesla — uma das vozes mais respeitadas do mundo em deep learning.

Entender a origem ajuda a entender o que o conceito realmente propõe — e o que ele não é. O Collins English Dictionary elegeu "vibe coding" como Palavra do Ano de 2025, confirmando que não é uma moda passageira.

Andrej Karpathy · Post original no X · "Give in to the vibes" · Collins Word of the Year 2025 · A linguagem mais quente é o inglês (e o português).

Desenvolver software descrevendo objetivos em linguagem natural para um LLM, que gera o código automaticamente. Você aceita o resultado e avalia pelo comportamento, não por cada linha de código.

A definição precisa evita dois erros comuns: achar que é só usar ChatGPT para perguntas de código (não é) ou achar que é magia sem método (também não é). Há um processo por trás.

Linguagem natural → código · Avaliação por comportamento · Iteração sobre output · Aceitar sem ler linha a linha · O desenvolvedor como diretor, a IA como executor.

Os LLMs evoluíram ao ponto em que o código gerado é bom o suficiente para ser usado diretamente na maioria dos casos de uso comuns. Não foi sempre assim — versões anteriores eram úteis mas precisavam de muita correção manual.

Entender que é uma janela de oportunidade — e que está evoluindo rápido. O que é possível hoje era impossível há 2 anos. O que será possível em 2 anos está além do que conseguimos imaginar hoje.

GPT-4 como ponto de virada · Claude 3.5+ como salto qualitativo · Context window maior = projetos maiores · Raciocínio melhorado = menos erros lógicos.

Na programação tradicional você escreve cada linha de código. No vibe coding você descreve o resultado desejado e a IA escreve o código. Você ainda precisa entender o que o código faz — mas não precisa saber como escrevê-lo.

Não é substituição — é um novo nível de abstração. Assim como linguagens de alto nível abstraíram assembly, vibe coding abstrai a sintaxe. O raciocínio lógico continua sendo a habilidade central.

Abstração de camadas · Foco no comportamento em vez da implementação · Validação por teste em vez de leitura de código · Velocidade vs. controle fino.

A IA no desenvolvimento evoluiu em camadas: autocomplete (Copilot 2021) → assistente de chat (2022) → editor agentico multi-arquivo (Cursor 2024) → agente autônomo (Devin, Claude Code 2025) → multi-agent workflows (2026).

Entender onde você está no espectro define que ferramenta usar. Para iniciantes, ferramentas de chat e IDEs com IA são o começo ideal. Para projetos complexos, agentes autônomos são o caminho.

Autocomplete → Chat → Agente → Multi-agent · Cada nível requer mais habilidade de orquestração · O futuro segundo Karpathy: "Agentic Engineering".

63% dos usuários de vibe coding não são desenvolvedores. São fundadores, PMs, marketers e executivos. Uma reporter da CNBC construiu um produto funcional em 2 dias de curso. Um fundador economizou $500K em desenvolvimento de MVP.

Os casos reais provam que não é hype. Goldman Sachs, Nubank e Santander usam Devin. 21% das startups do Y Combinator W25 têm 91%+ de código gerado por IA.

63% não-devs · Reporter CNBC em 2 dias · Fundador economizou $500K · Goldman Sachs + Nubank usando Devin · 21% YC W25 com 91%+ de código gerado por IA.

Em menos de um ano, "vibe coding" foi de um tweet viral a Collins Word of the Year — ao lado de termos históricos como "selfie" (2013) e "climate emergency" (2019). A Merriam-Webster listou como expressão de slang em março de 2025.

A velocidade de adoção cultural reflete a velocidade de adoção tecnológica. Quando um dicionário consagrado escolhe um termo técnico como palavra do ano, é sinal de que ultrapassou os limites da comunidade de tecnologia.

Feb 2025 → tweet original · Mar 2025 → Merriam-Webster · Dez 2025 → Collins Word of the Year · Wikipedia com página dedicada · Conferência acadêmica VibeX 2026 no EASE.

Em vez de pensar "preciso usar um loop for com um array", você pensa "o usuário deve conseguir ver todos os pedidos do mês em uma tabela ordenada por data". O foco muda da implementação para o comportamento.

Quem continua pensando em termos de implementação ao usar IA tende a receber respostas mais genéricas e menos úteis. Descrever o comportamento desejado gera resultados muito mais precisos.

Comportamento vs. implementação · "O usuário deve conseguir fazer X" · Critérios de aceite como base do prompt · Resultados observáveis como medida de sucesso.

Vibe coding eficaz não é pedir tudo de uma vez e esperar o produto pronto. É pedir uma parte, testar, ajustar, pedir a próxima parte. Cada iteração é um ciclo completo: prompt → código → teste → feedback.

Blocos grandes de trabalho com IA acumulam erros que se propagam. Iterações curtas permitem corrigir o rumo cedo, antes que um erro se torne a fundação de tudo que vem depois.

Ciclo prompt→código→teste→feedback · MVP mínimo por iteração · Commitar a cada parte funcional · "Red, green, refactor" aplicado ao vibe coding.

A metáfora mais precisa da comunidade: a IA é como um estagiário brilhantíssimo que executa rápido mas precisa de direção e supervisão. Você define a arquitetura, as prioridades e valida cada entrega.

Quem delega tudo e não supervisiona fica com código inconsistente, inseguro e difícil de manter. 16 dos 18 CTOs consultados sobre vibe coding reportaram desastres em produção — todos por falta de supervisão adequada.

Arquiteto vs. executor · Supervisão ativa · Direção clara antes de execução · Review do que foi feito · Você é responsável pelo output, mesmo que não o tenha escrito.

O primeiro resultado raramente é perfeito — e tudo bem. O objetivo do primeiro ciclo é ter algo funcionando para testar a ideia, não ter código de produção. A perfeição vem nas iterações seguintes.

Perfeccionismo na primeira iteração é o maior inimigo da velocidade. Fundadores que economizaram $500K não esperaram o MVP perfeito — testaram rápido e refinaram com feedback real.

MVP como experimento · "Done is better than perfect" em código · Refinar com base em uso real · Custo baixo de mudança no início vs. custo alto depois.

IA é 81% mais rápida em tarefas de boilerplate e CRUD. Mas o estudo METR (jul/2025) mostrou que devs experientes ficaram 19% mais lentos em tarefas complexas — porque o overhead de revisar e corrigir supera o ganho.

Saber quando usar IA e quando não usar é a habilidade mais valiosa. Usar IA para tudo indiscriminadamente pode desacelerar — e a ilusão de ter sido mais rápido é comprovadamente real (os mesmos devs acharam que foram 20% mais rápidos após o teste).

81% mais rápido em boilerplate · 19% mais lento em tarefas complexas (METR 2025) · Ilusão de produtividade · Quando usar vs. quando não usar · O custo oculto do review.

Em fev/2026, o próprio Karpathy declarou que "vibe coding já está ultrapassado". O próximo passo é "agentic engineering": orquestrar múltiplos agentes em paralelo, atuando como arquiteto e gate de qualidade, não como quem escreve prompts.

O mindset que você desenvolve hoje como vibe coder é a fundação para o próximo nível. Quem entende iteração, supervisão e decomposição de problemas se adapta naturalmente ao fluxo agentico.

Agentic engineering · Múltiplos agentes em paralelo · Humano como orquestrador e supervisor · 40% do software enterprise via agentes até 2026 · O desenvolvedor como diretor de orquestra.

A IA erra — especialmente em lógica complexa, segurança e edge cases. Confie no output para tarefas bem definidas, mas questione quando: o resultado parece muito simples, envolve dados sensíveis, ou tem impacto financeiro.

45% do código gerado por IA tem falhas de segurança (Veracode). 40% de devs junior admitem deployar código de IA que não entendem. O senso crítico é o diferencial entre vibe coding responsável e irresponsável.

Confiar em tarefas simples e bem definidas · Questionar em lógica complexa, segurança e dados · 45% de código de IA com falhas (Veracode) · Review antes de commitar · Testar edge cases sempre.

O ecossistema se divide em três categorias: IDEs com IA integrada (para quem já tem um ambiente de desenvolvimento), agentes autônomos (para tarefas complexas e longas), e plataformas prompt-to-app (para quem não tem background técnico).

Escolher a ferramenta errada para o contexto é o erro mais comum de iniciantes. Cada ferramenta tem seus pontos fortes — usar Cursor para um projeto no-code ou Lovable para um sistema backend complexo leva à frustração.

IDEs com IA · Agentes autônomos · Plataformas prompt-to-app · Matching ferramenta-contexto · Custo vs. capacidade.

IDE construído sobre VS Code com IA profundamente integrada. Destaque: arquivo .cursorrules para instruções persistentes de projeto, referenciamento de arquivos com @, modo Composer para edições multi-arquivo. $20/mês.

Considerado o melhor para desenvolvedores. Levantou $900M em jun/2025 (valuation $9,9B) com mais de $100M ARR em 12 meses — a startup de crescimento mais rápido da história. Padrão de mercado para desenvolvimento profissional.

.cursorrules · Modo Composer · Referência @arquivo · $20/mês · Baseado em VS Code · Melhor para devs experientes.

IDE da Codeium com foco em agentes. Mais barato ($15/mês) e com mais uso de agentes inclusos no plano base. Modelos proprietários otimizados para velocidade. Destaque: Codemaps para navegação de código com IA.

Alternativa real ao Cursor para equipes que querem mais uso de agentes sem pagar por token. Excelente para colaboração em equipes, com foco em fluxos de trabalho agentivos desde o início.

$15/mês · Codemaps · .windsurfrules · Modelos SWE proprietários · Ideal para times · Mais agentes inclusos vs. Cursor.

CLI da Anthropic que opera no terminal. Diferencial: o arquivo CLAUDE.md é carregado automaticamente em cada sessão, criando contexto persistente de projeto. Suporta MCP (Model Context Protocol) para conectar a bancos de dados e APIs.

Melhor para desenvolvedores que vivem no terminal e querem automação avançada. Superior em raciocínio complexo e refatorações grandes. O arquivo CLAUDE.md é a técnica individual mais eficaz para melhorar qualidade de output.

CLAUDE.md · Terminal-first · MCP (Model Context Protocol) · Sessões longas e autônomas · Melhor em raciocínio complexo · Ideal para devs experientes.

Plataformas onde você descreve o app e recebe um produto funcional sem instalar nada. Lovable ($1M→$100M ARR em 8 meses): melhor para apps SaaS. Bolt.new: melhor para prototipagem rápida no browser. v0 (Vercel): melhor para UI com Next.js.

Essas plataformas democratizaram o acesso ao desenvolvimento. 63% dos usuários que as usam não são desenvolvedores. São o ponto de entrada ideal para não-técnicos e o mais rápido caminho para validar uma ideia.

Lovable (SaaS, deploy incluído) · Bolt.new (browser, qualquer framework) · v0 (Next.js, UI) · Replit Agent (automação, full-stack) · Deploy com um clique.

A ferramenta mais amplamente adotada — 84% dos desenvolvedores já usam ou planejam usar (Stack Overflow 2025). Integrado ao ecossistema Microsoft/Azure. Presente em praticamente qualquer IDE. Ponto de entrada mais comum para devs que já usam VS Code.

É provavelmente a ferramenta que mais pessoas ao seu redor já usam. Entender seus pontos fortes (autocomplete, chat inline) e limitações (menor capacidade agentica vs. Cursor/Windsurf) permite escolher quando usá-lo.

84% dos devs · Integração Microsoft/Azure · Copilot Chat · Autocomplete avançado · Enterprise compliance · Menor capacidade agentica.

A escolha depende do perfil: não-técnico → Lovable ou Bolt.new; dev iniciante → GitHub Copilot; dev avançado → Cursor ou Windsurf; automação e terminal → Claude Code; equipes enterprise → Copilot ou Windsurf.

Não existe "melhor ferramenta" universal. A melhor é aquela que se encaixa no seu contexto, skill level e caso de uso. Testar antes de pagar é sempre o caminho certo — todas têm plano gratuito ou trial.

Não-técnico → Lovable/Bolt · Dev iniciante → Copilot · Dev avançado → Cursor/Windsurf · Terminal → Claude Code · Enterprise → Copilot/Windsurf · Sempre testar antes de pagar.

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. Cursor gratuito, configuração do modelo padrão e criação do arquivo .cursorrules são os três passos principais.

A barreira de entrada para vibe coding é menor do que parece. Para plataformas prompt-to-app como Lovable ou Bolt.new, o setup é ainda mais simples: basta criar uma conta e abrir o browser.

Cursor gratuito (2.000 completions/mês) · Configuração de modelo padrão · Pasta de projeto indexada · Arquivo .cursorrules · Plataformas prompt-to-app como alternativa.

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 são menos eficazes do que resolver um problema que você realmente tem. O critério do "testável hoje" define bons primeiros projetos.

Escolher o projeto errado é a causa mais comum de desistência no primeiro dia. Projetos grandes demais geram frustração, projetos sem propósito real não geram motivação para continuar.

Dashboard de dados que você já acompanha · Formulário para substituir planilha · Script de automação · Landing page simples · Evitar clones complexos · Testável sem outros usuários.

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.

Listar explicitamente o que você não quer é tão importante quanto listar o que quer. A IA tende a adicionar funcionalidades que "fazem sentido" no contexto, aumentando a complexidade desnecessariamente no primeiro dia.

Contexto do projeto · Stack tecnológica definida · Funcionalidade central apenas · "Não precisa agora" como instrução explícita · Prompt fraco vs. prompt forte.

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.

Se cada ciclo de iteração está levando mais de 15 minutos, o escopo está grande demais. Se está levando menos de 2 minutos, você pode estar iterando em algo trivial. A velocidade do ciclo é um indicador de saúde do processo.

Aceitar → Testar → Ajustar → Repetir · Feedback específico vs. genérico · "Quando clico em X, o resultado Y não acontece" · Velocidade do ciclo como indicador.

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.

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. Esse ciclo resolve ~80% dos bugs de front-end sem precisar entender o código.

Console F12 · Copiar stack trace completo · Cole com contexto mínimo · Tab Console para JS, tab Network para APIs · ~80% dos bugs de front-end resolvidos assim.

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".

16 dos 18 CTOs consultados sobre desastres com vibe coding mencionaram "aceitar mudanças sem commit prévio" como fator contribuinte. O agente pode reescrever um componente e quebrar algo — sem commit, não há como voltar.

Commite após cada funcionalidade funcionando · Mensagens descritivas · Antes de refatorações grandes · Branches para experimentos · git checkout HEAD arquivo.tsx como saída de emergência.

"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 "feature creep" (adicionar funcionalidades infinitamente porque é fácil pedir à IA).

O critério definitivo: você usaria o projeto 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.

Funcionalidade central sem erros · Outro usuário consegue usar sem instrução · Dados persistem · Código commitado · Checklist de conclusão · Mostrar para alguém real como próximo passo.

Dois desenvolvedores, a mesma ferramenta, o mesmo modelo de IA. Um recebe código preciso que funciona na primeira tentativa. O outro recebe código genérico que precisa de 5 rodadas de correção. A diferença quase nunca é a ferramenta — é a qualidade do prompt.

Prompts bem estruturados reduzem as rodadas de iteração em ~60%. Desenvolvedores que aprendem prompt engineering reportam 2-3x mais produtividade com as mesmas ferramentas. O custo de tokens também cai.

Prompt vago vs. prompt específico · ~60% menos iterações com prompts melhores · 2-3x produtividade · Custo de tokens menor · Prompt engineering como habilidade central.

Todo prompt eficaz para código tem quatro componentes: Contexto + Tarefa + Restrições + Resultado Esperado. Você não precisa de todos em todos os prompts — mas quanto mais presentes, mais preciso o resultado.

Você não precisa escrever "Contexto:", "Tarefa:" como cabeçalhos. O importante é que o prompt contenha essas informações de forma natural. O agente extrai a estrutura do texto.

Contexto (onde estamos) · Tarefa (o que fazer, com verbo claro) · Restrições (o que não fazer) · Resultado Esperado (comportamento final) · Estrutura natural, não formal.

Para funções e componentes, o nível de precisão mais eficaz é especificar exatamente o que entra e o que sai. "Faça uma função" é vago. "Função que recebe X e retorna Y" gera código que integra perfeitamente com o resto do sistema.

Para funções: "formatDate(date: Date) → string no formato dd/mm/yyyy". Para APIs: especificar o schema de entrada e saída. Para componentes: definir as props e callbacks. Cada tipo tem seu padrão de especificação ideal.

Funções: nome(param: tipo) → tipo retorno · APIs: schema de entrada e saída com tipos · Componentes: props e callbacks explícitos · Tipos TypeScript como especificação · Exemplos de entrada e saída esperada.

Exemplos são o atalho mais eficaz para resultados precisos. Quando você mostra o que quer, a IA infere o padrão e replica — mais rápido e mais fiel do que qualquer descrição verbal. Isso é chamado de few-shot prompting e é tecnicamente validado em pesquisas sobre LLMs.

No Cursor, use @componente.tsx para incluir um arquivo existente como exemplo. "Crie um componente similar ao @HabitCard.tsx mas para metas semanais" é mais eficaz do que descrever o padrão em palavras.

Few-shot prompting · Zero-shot vs. exemplos concretos · @referências no Cursor · Essencial para estilo de código · Formato de output · Componentes consistentes.

Nunca peça tudo de uma vez. Quanto maior e mais complexo o pedido, maior a probabilidade de a IA "alucinar" partes, gerar inconsistências entre arquivos e produzir código que funciona individualmente mas quebra quando integrado. Decompor o problema é responsabilidade do arquiteto — você.

Para features complexas, comece com "Antes de escrever qualquer código, me dê um plano de como você implementaria [feature]". Revise o plano, ajuste a abordagem, e só então peça a implementação passo a passo. Isso elimina 90% dos retrabalhos.

Pedido monolítico vs. passos sequenciais · Plano antes do código · 90% menos retrabalho · Cada passo verificável antes do próximo · Decomposição como habilidade de arquiteto.

Uma das capacidades mais subutilizadas: usar a IA para melhorar o código que ela mesma gerou. Depois de ter algo funcionando, você pode pedir revisão de segurança, performance, legibilidade e manutenibilidade — tudo em prompts separados.

Quando você pede segurança + performance + legibilidade em um único prompt, a IA faz tudo de forma superficial. Quando você pede um aspecto por vez, ela vai a fundo em cada dimensão. A qualidade do output melhora substancialmente com prompts focados.

Sequência: fazer funcionar → commitar → revisar segurança → revisar performance → refatorar legibilidade · Revisões separadas têm mais profundidade · Prompts focados por dimensão.

Os 5 erros mais comuns: (1) pedir muito de uma vez, (2) não especificar a stack, (3) feedback genérico de erro como "não funcionou, tente de novo", (4) aceitar sem testar, (5) não especificar o que não mudar. Cada um tem uma correção simples e direta.

Depois de analisar centenas de sessões de vibe coding, esses cinco padrões aparecem repetidamente. Conhecê-los antes de cometê-los economiza horas de frustração. Cada erro tem uma anti-solução praticável.

Escopo limitado por pedido · Stack sempre especificada · Erro completo do console no feedback · Testar imediatamente após aceitar · "Não mude X" como instrução explícita · Sempre testar após aceitar mudanças.

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. O EPIV (Explore, Plan, Implement, Verify) resolve isso com um workflow deliberado de 4 fases.

Times que adotam um workflow estruturado reportam: 70% menos retrabalho causado por mudanças não intencionais, 3x menos bugs chegando à branch principal e histórico de git compreensível por qualquer membro do time.

Explore (entenda antes de modificar) · Plan (planeje antes de executar) · Implement (execute em partes testáveis) · Verify (valide antes de aceitar) · 70% menos retrabalho · 3x menos bugs.

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.

No início de cada sessão com um projeto existente, 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.

"Não modifique nada ainda" · "Apenas análise, sem código" · Mapeamento de dependências ocultas · Padrões existentes para replicar · Contexto de sessões anteriores via histórico git.

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.

Adicione "aguarde minha aprovação" em todo pedido de planejamento. Isso impede que o agente comece a implementar enquanto ainda está planejando. A separação entre plano e execução é o coração do EPIV.

Prompt de planejamento estruturado · Arquivos afetados · Estrutura de dados · Sequência de implementação · Dependências externas · Pontos de falha potenciais · "Aguarde aprovação".

Com o plano aprovado, a implementação começa — mas ainda em partes. A regra: 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.

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. Use "anote mas não altere" para manter o escopo controlado.

"Implemente apenas o passo 1" · Cada passo verificável em menos de 5 min · "Se perceber algo a melhorar, anote mas não altere" · Rollback simples de cada passo · Sem refatoração não solicitada.

A fase Verify é onde o julgamento humano é insubstituível. O agente pode ter gerado código que compila e passa nos testes — mas que tem comportamento indesejado em edge cases. Verificar é diferente de testar: inclui verificação funcional, de edge cases e de regressã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 — use essa lista na fase Verify.

Verificação funcional (funciona?) · Verificação de edge cases (dados inválidos, campos vazios) · Verificação de regressão (o que existia ainda funciona?) · Checklist gerado pelo agente antes de implementar.

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 consequências.

Vibe coding na main sem branches é como fazer experimentos sem proteção — geralmente fica tudo bem, até o dia que não fica. Se você não se sente à vontade para descartar tudo que foi feito nos últimos 30 minutos, você está atrasado em criar uma branch.

git checkout -b feat/nome · Commits descritivos ao longo da feature · Merge para main só quando aprovado e testado · git branch -D para descartar sem prejuízo · Branches de backup antes de mudanças grandes.

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 muitas vezes mais clara do que a escrita por humanos sob pressão de deadline.

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 em projetos mantíveis.

JSDoc para funções e componentes · DECISIONS.md para escolhas de arquitetura · CLAUDE.md / .cursorrules atualizado · README gerado pelo agente · Documentação como parte do Definition of Done.

O relatório CodeRabbit 2025 analisou mais de 1 milhão de pull requests: código assistido por IA tem 2,74x mais vulnerabilidades do que código escrito por humanos sem assistência. 45% do código gerado por IA contém pelo menos uma falha de segurança (Veracode).

Esses números não significam que vibe coding é perigoso por natureza — significam que sem processo de revisão, qualquer metodologia de desenvolvimento é perigosa. Os riscos são gerenciáveis com as práticas deste módulo.

2,74x mais vulnerabilidades (CodeRabbit 2025) · 45% com falha de segurança (Veracode) · 16 de 18 CTOs reportaram incidentes · Top: SQL injection, XSS, dados hardcodados, IDOR · Revisão como mitigação principal.

Git não é só controle de versão — é sua apólice de seguro para vibe coding. Commits frequentes criam um histórico de estados funcionais que você pode acessar a qualquer momento. O momento em que você vai precisar de rollback é o pior momento para perceber que não fez commits.

Os comandos de segurança mais importantes: git diff (ver o que mudou), git checkout HEAD -- arquivo.tsx (reverter um arquivo), git checkout abc1234 (voltar a um commit), git log --oneline (histórico rápido).

Commit a cada funcionalidade funcionando · Antes de cada mudança grande · Antes do final do dia (WIP:) · Antes de experimentos · git diff antes de commitar · Branch de backup antes de refatorações.

A vulnerabilidade número 1 em projetos vibe coding: chaves de API, tokens e senhas hardcodadas no código. A IA frequentemente coloca valores diretamente no código para "facilitar o exemplo". O tempo médio entre o commit de uma chave real e seu primeiro uso malicioso é de 4 a 24 horas.

Adicione no seu .cursorrules ou CLAUDE.md: "Nunca coloque valores de chaves de API, tokens ou senhas diretamente no código. Sempre use process.env.NOME_DA_VARIAVEL e adicione a instrução no .env.example."

Arquivo .env local (nunca commitado) · .gitignore com .env, .env.local, .env.production · process.env.NOME_DA_VARIAVEL · Bots escaneiam repositórios GitHub · 4-24h para uso malicioso.

Ler antes de aceitar é o hábito de segurança mais importante do vibe coder. O agente pode ter feito mudanças além do que você pediu, introduzido padrões diferentes ou modificado arquivos que não deveriam ser tocados. O diff é sua última linha de defesa antes do commit.

O que procurar no diff: arquivos não esperados modificados, strings suspeitas (tokens, URLs, senhas), linhas deletadas sem motivo claro, dependências novas em package.json. No Cursor/Windsurf, prefira "Accept individual changes" ao "Accept All".

git diff (unstaged) · git diff --staged (o que vai no commit) · git diff HEAD~1 (vs commit anterior) · Padrões suspeitos: "sk_", "AIza", "Bearer", "postgresql://" · Linhas em vermelho = código removido.

Uma das vulnerabilidades mais comuns em código de IA: ausência de validação de dados de entrada. A IA foca em fazer o fluxo "feliz" funcionar e frequentemente ignora o que acontece quando o usuário envia dados inesperados, maliciosos ou simplesmente incorretos.

SQL Injection, XSS (Cross-Site Scripting) e IDOR (Insecure Direct Object Reference) são preveníveis com práticas básicas: Zod/Yup para validação de schemas, ORMs ao invés de queries manuais, DOMPurify para HTML, e verificação de autorização em cada endpoint.

Zod ou Yup para schemas no servidor · ORMs (Prisma, Drizzle) previnem injection · DOMPurify sanitiza HTML · Verificação de autorização em todo endpoint · Nunca confiar apenas na validação do front-end.

Produção é diferente de desenvolvimento. Em dev, um bug é um aprendizado. Em produção, um bug pode significar dados perdidos, usuários prejudicados e responsabilidade legal. Este checklist representa os bloqueadores críticos — coisas que devem estar resolvidas ANTES de qualquer deploy.

Antes de qualquer deploy de produção: "Faça uma auditoria de segurança básica desse projeto. Liste: chaves hardcodadas, endpoints sem autenticação, inputs sem validação, e console.logs que deveriam ser removidos."

Sem chaves hardcodadas · Backup do banco antes do primeiro deploy · Auth testada com usuários reais · Sem console.log de dados sensíveis · HTTPS obrigatório · Rate limiting nas APIs · Validação no servidor.

Vibe coding democratizou o desenvolvimento, mas não eliminou a necessidade de expertise especializada em contextos críticos. Saber quando pedir ajuda profissional é uma habilidade de maturidade — não uma admissão de fraqueza.

Sinais que indicam necessidade de revisão externa: dados de usuários reais (PII), processamento de pagamentos real, mais de 1.000 usuários ativos, ou código em produção que você não consegue explicar como funciona.

PII exige conformidade LGPD · Pagamentos reais requerem revisão de webhooks · 1.000+ usuários = problemas de escala · Codementor para code review pontual · Freelancer sênior por uma semana · Pentest para dados sensíveis.

Deploy é o processo de mover seu projeto da sua máquina local para um servidor que fica acessível na internet, 24 horas por dia, para qualquer pessoa com o link. Em 2025, deploy ficou tão simples quanto um push no git — a plataforma detecta, constrói e publica automaticamente.

O deploy evoluiu radicalmente: 2010 (SSH manual) → 2015 (Heroku com git push) → 2020 (Vercel em 30 segundos) → 2025 (deploy completo com front + back + banco em menos de 5 minutos com Railway ou Render).

Localhost → GitHub push → Plataforma detecta → Build → URL pública · HTTPS automático · Deploy contínuo (todo push = novo deploy) · Vercel, Render e Railway como plataformas principais.

A Vercel criou o Next.js e é a plataforma de deploy mais otimizada para projetos React/Next.js. O fluxo é: conecte o GitHub, selecione o repositório, clique em Deploy. Em 60 segundos você tem uma URL pública com HTTPS automático e deploy contínuo a cada push.

A Vercel detecta automaticamente o framework e configura o build command correto. Inclui gratuitamente: 100GB de bandwidth/mês, preview deployments por branch, analytics básico e funções serverless sem configuração adicional.

Conectar GitHub → Selecionar repo → Deploy (60s) · Todo push na main = novo deploy · Preview URLs para branches · HTTPS via Let's Encrypt · 100GB bandwidth gratuito · Funções serverless incluídas.

Quando seu projeto tem um backend Node.js, Python, Go ou Ruby que precisa ficar rodando 24/7, o Render é uma das melhores opções. É o Heroku moderno — simples, confiável e com plano gratuito funcional para desenvolvimento.

Use Vercel para front-ends React/Next.js e APIs leves (serverless functions). Use Render para servidores Node.js/Python que precisam ficar rodando, WebSockets, processamento em background e workers de fila.

Web Services (backends sempre rodando) · Static Sites · Background Workers · PostgreSQL gerenciado · Redis gerenciado · Deploy automático via GitHub · Vercel para front, Render para back.

O Railway resolve o problema mais comum de quem está começando: como rodar backend + banco de dados juntos de forma simples. Com alguns cliques, você provisiona um Postgres, um Redis e um serviço Node.js, todos conectados automaticamente com variáveis de ambiente injetadas.

Stack recomendada para iniciantes: Front-end na Vercel + Back-end + Banco no Railway. Essa combinação cobre 95% dos projetos de aprendizado e MVPs. É gratuita até um certo ponto e escala facilmente quando necessário.

Add service → Database → PostgreSQL (provisionado em segundos) · DATABASE_URL injetada automaticamente · $5/mês plano Hobby · 1GB RAM por serviço · Serviços ilimitados por projeto · Vercel front + Railway back+banco.

Domínios custam ~R$50/ano e transformam "projeto" em "produto". A configuração que parece complexa (DNS, SSL, HTTPS) foi simplificada ao ponto de levar menos de 10 minutos nas plataformas modernas. A Vercel provisiona e renova o certificado SSL automaticamente.

DNS (Domain Name System) é a agenda telefônica da internet: transforma "meuapp.com" no endereço IP do servidor. SSL/HTTPS é o cadeado no browser — garante que a comunicação é criptografada. Sem SSL, dados trafegam em texto puro.

Registro.br (domínios .com.br) · Cloudflare (melhor preço, sem taxas surpresa) · Settings → Domains na Vercel · Registros A e CNAME · Propagação 5 min a 48h · SSL automático via Let's Encrypt.

Suas variáveis de ambiente do arquivo .env local não vão para o servidor sozinhas. Você precisa configurá-las na plataforma de deploy antes de fazer o primeiro push. Esse é o passo que mais gera bugs de "funciona local, quebra em produção".

Cada plataforma tem seu caminho: Vercel (Settings → Environment Variables), Render (Dashboard → Environment), Railway (Serviço → Variables com injeção automática dos serviços conectados). Separe sempre chaves de test de chaves de produção.

.env.example no repositório (sem valores) · Valores reais só no painel da plataforma · sk_test_ para dev vs. sk_live_ para produção · Erros comuns: commitar .env, usar prod em dev, esquecer de configurar antes do deploy.

Colocar no ar é o começo — saber quando algo quebra é o que mantém o projeto de pé. Monitoramento básico não precisa ser caro ou complexo. Com três ferramentas gratuitas, você tem visibilidade suficiente: Uptime Robot (uptime a cada 5 min), logs da plataforma e Sentry (tracking de erros).

Para projetos Next.js, peça ao agente: "Integre o Sentry ao projeto seguindo a documentação oficial. Configure para capturar erros de front-end e back-end. Use a variável de ambiente SENTRY_DSN." O agente instala, configura e cria os handlers automaticamente.

Uptime Robot (gratuito, até 50 monitores, a cada 5 min) · Logs da plataforma em tempo real · Sentry (5.000 erros/mês gratuito, stack trace completo) · Verificar logs após cada deploy · Hábito de monitoramento pró-ativo.