Vibe coding é gerar software a partir de prompts em linguagem natural, sem revisar arquitetura, sem escrever testes e sem entender em detalhe o que o modelo está produzindo. Para validar uma ideia em dias, funciona. Para sustentar um produto em produção, não. Os riscos de vibe coding em produção são previsíveis, mensuráveis e caros — e a conta chega quando o produto começa a crescer.
Este texto não é contra IA. Usamos IA todo dia, em código que vai pra produção. É contra a confusão entre usar IA como ferramenta de produtividade e entregar IA sem engenharia. São coisas diferentes, com consequências diferentes.
O que o vibe coding entrega de verdade
Há valor real no vibe coding e ignorar isso é dogma. Em mãos de quem sabe ler código, Cursor, Claude Code, GitHub Copilot e v0 derrubam o tempo de um MVP de semanas para dias. Para uma startup testando hipótese, isso é a diferença entre validar agora e validar nunca.
Onde entrega bem:
- Protótipo navegável em 48 horas para pitch ou pesquisa com cliente.
- Landing com formulário e backend mínimo capturando lead.
- Endpoint de API que conversa com um serviço externo conhecido.
- Feature isolada, sem dependência crítica de segurança ou de outros módulos.
Em todos esses cenários, o código não precisa durar. Ele precisa provar uma tese. Se a tese for falsa, joga fora. Se for verdade, você sabe que vai reescrever — e o tempo poupado na validação compensa a reescrita.
O problema é confundir esse contexto com produto em produção atendendo cliente pagante.
Onde o código gerado por IA quebra em produção
Em outubro de 2025, a CodeRabbit publicou análise de mais de 2 milhões de pull requests com código gerado por IA. Os números são incômodos: 1,7x mais bugs críticos e 2,74x mais vulnerabilidades de segurança em relação a código escrito por desenvolvedor sem assistência de IA. Não é teoria, é dado de produção.
Os padrões de falha se repetem:
- Arquitetura inconsistente. O modelo gera o que pareceu melhor naquele prompt, não o que cabe na arquitetura existente. Cada feature vira uma ilha. Em três meses, o codebase tem quatro jeitos de fazer autenticação, cinco padrões de erro e dois ORMs concorrentes.
- Zero testes reais. O modelo gera testes que validam o caminho feliz e nada mais. Edge case, concorrência, race condition, falha de rede — descobertos em produção pelo cliente.
- Vulnerabilidades OWASP em série. SQL injection mascarado em query que "parece parametrizada", XSS em renderização de markdown vindo do usuário, IDOR em endpoint que confia em ID do front. Todas geradas com convicção.
- Dependências fantasma. A IA puxa pacote que parece o oficial mas é typo squatting. Já houve casos documentados de modelos sugerindo bibliotecas que não existem — e atacantes registrando esses nomes depois.
- Decisões irreversíveis embutidas. Estrutura de banco, modelo de permissões, sistema de eventos — tudo decidido pelo modelo sem revisão. Reverter depois custa migrações longas, downtime e dor de cliente.
Nenhum desses problemas aparece na demo. Aparecem quando o produto tem 200 usuários, alguém faz penetration test, ou o time tenta adicionar uma feature que cruza áreas geradas por prompts diferentes.
O que acontece quando você tenta escalar um produto vibe-coded
A história se repete. Por aqui, recebemos projetos onde duas software houses e uma consultoria tinham falhado antes da gente entrar. Em parte desses casos, o ponto de partida foi um produto inteiro gerado por IA, sem revisão, que rodou enquanto a base era pequena e implodiu quando o tráfego ou a complexidade subiram.
Os sintomas clássicos:
- Bug em produção que ninguém consegue reproduzir. Não há teste. Não há log estruturado. Não há quem tenha lido o código antes do incidente.
- Custo de infra absurdo. O modelo gerou queries N+1, sem paginação, com payloads gigantes — porque ninguém pediu performance no prompt.
- Onboarding de dev novo demora seis semanas, porque não há padrão, não há doc, não há lógica reutilizável.
- Cada feature nova quebra duas antigas. Não há limites entre módulos. Mudança em um lugar afeta dependências invisíveis.
- Segurança comprometida e auditoria impossível. Quando o cliente B2B pede SOC 2 ou um relatório LGPD, a resposta é silêncio.
Quando isso bate, a empresa tem duas opções: reescrever do zero ou contratar um time que faça refatoração agressiva mantendo o produto rodando. As duas saem mais caras do que se o desenvolvimento tivesse começado certo. Mas reescrever sobre validação real já feita ainda é melhor do que ter gastado seis meses construindo o produto errado da forma certa.
O que vem depois do vibe coding: revisão humana, arquitetura, squad
A pergunta certa não é "uso vibe coding ou não". É "em que ponto eu paro de tratar o produto como protótipo e começo a tratar como produto".
O critério prático que usamos por aqui: na hora em que o produto tem cliente pagante, dado real em produção ou roadmap de evolução de mais de 90 dias, vibe coding sem revisão precisa parar. O que vem no lugar:
| Dimensão | Modo validação | Modo produção |
|---|---|---|
| Revisão de código | Opcional | Obrigatória, humano com conhecimento de segurança |
| Arquitetura | Emergente, por prompt | Definida antes de gerar, com padrões de erro, contratos entre módulos, cache |
| Testes | Caminho feliz | Unitário, integração, regressão e teste de borda escrito por humano |
| Time | 1 dev generalista | Squad multidisciplinar: dev, tech lead, segurança, QA |
| CI/CD | Deploy manual | Pipeline com SAST, dependency scan, secrets detection, license check |
| Documentação | Nenhuma | ADR, README por módulo, runbook de incidente |
Esse é o desenho que separa produto que escala de protótipo que sobreviveu por sorte. IA continua presente — mas dentro da estrutura, não no lugar dela.
Como a Skala entra nesse processo
A Skala Code não vende validação rápida. Vende squad dedicado para empresas que já validaram e precisam transformar produto experimental em produto sustentável. Quando o cliente chega com base vibe-coded, o caminho típico é:
- Auditoria técnica completa. Em até duas semanas mapeamos arquitetura real, dívida acumulada, riscos de segurança, gargalos de performance e custo atual de manutenção. Documento entregue antes de qualquer linha de código.
- Plano de remediação por prioridade. O que é crítico (segurança, perda de dado), o que é estrutural (arquitetura), o que é cosmético (UX, refactor). Não tentamos consertar tudo de uma vez.
- Squad assume desenvolvimento contínuo. Refatoração incremental rodando em paralelo com features novas. Cliente não para de evoluir o produto enquanto a base é arrumada.
- Governança em contrato. Escopo fechado por sprint, SLA de bug crítico, propriedade 100% do código com o cliente, DPO formal para LGPD e cláusula de compensação por atraso.
O time entende que vibe coding é parte do toolkit moderno — não inimigo. O que muda é onde, quando e com qual revisão. Engenharia continua sendo engenharia: arquitetura, leitura crítica, teste, observabilidade, segurança. IA acelera o que está dentro dessa estrutura. Não substitui a estrutura.
Perguntas frequentes
Vibe coding é seguro para sistema com dados de cliente?
Não, sem revisão humana e auditoria. A análise da CodeRabbit em mais de 2 milhões de pull requests mostrou 2,74x mais vulnerabilidades de segurança em código gerado por IA. Para sistema com dados de cliente, a regra mínima é code review por engenheiro com experiência em segurança, SAST automatizado e teste de penetração antes do deploy.
Em que momento eu paro de usar vibe coding e contrato um squad?
No momento em que o produto deixa de ser protótipo. Critérios práticos: cliente pagante, dado real em produção, roadmap de mais de 90 dias ou compliance obrigatório como LGPD ou auditoria fiscal. Se qualquer um desses se aplica, vibe coding sem governança vira passivo financeiro e técnico.
Quanto custa refatorar um produto vibe-coded?
Depende do estado. Em projetos que assumimos, a refatoração estrutural custa entre 30% e 80% do que custaria reescrever do zero, com a vantagem de não parar o produto. O cálculo certo exige auditoria técnica antes — sem ela qualquer estimativa é chute.
Como escalar após o MVP sem perder a velocidade que o vibe coding deu?
Mantendo a IA como ferramenta de produtividade dentro de uma engenharia com governança. Squad multidisciplinar, revisão humana de cada PR, arquitetura definida por humano, testes reais e CI/CD com gates de segurança. Velocidade real não vem de gerar mais código por hora, vem de gerar código que não precisa ser refeito.
Tem produto validado, base bagunçada e meta de escalar nos próximos 12 meses? Manda o contexto pelo WhatsApp. Em uma conversa rápida dá para apontar se a auditoria técnica resolve, ou se o melhor caminho é reconstruir parte da base com squad dedicado.
Conversar sobre meu produto →