O que é vibe coding
O termo se popularizou em 2025 e descreve um jeito de programar em que você diz a um modelo o que quer, testa o resultado e aceita sem ler todo o código que ele escreveu. A graça está na velocidade: em uma tarde já existe algo funcionando e demonstrável.
Isso não é um problema em si. Vira um quando esse código sai da demonstração e vai para produção sem que alguém com experiência tenha olhado que dados ele toca, o que deixa aberto e o que acontece quando entram mil pessoas em vez de três.
Vibe coding é bom ou ruim?
Nem uma coisa nem outra: é uma ferramenta, e serve conforme o uso. Para um protótipo, uma prova de conceito ou uma ferramenta interna, é das formas mais rápidas que existem. Para algo que guarda dados de clientes, cobra ou recebe tráfego real, essa velocidade vira risco se ninguém revisar o que foi escrito.
As vantagens são reais: uma ideia é testada em horas, quem não programa consegue mostrar o que quer e a equipe técnica parte de algo que já funciona. Os riscos também: código que ninguém entende por inteiro, permissões abertas por padrão, dependências escolhidas ao acaso e erros que não avisam. A diferença está no que acontece entre a demonstração e a produção.
Onde falha o código que a IA escreve
A IA escreve código que funciona no caminho feliz, que é o que a demonstração testa. O que falta costuma ser o que não se vê: a checagem do dado que chega errado, a permissão que ninguém revisou, a consulta que trava quando a tabela cresce e o segredo que ficou dentro do repositório.
Isso está medido. 45% do código gerado por IA em laboratório trazia vulnerabilidades conhecidas quando não recebia instruções de segurança.
Ferramentas de vibe coding e o que muda entre elas
Há duas famílias. Os editores e assistentes que trabalham dentro do código, como Cursor, GitHub Copilot ou Claude Code, e as plataformas que geram um aplicativo inteiro a partir de uma descrição, como Lovable, Bolt, Replit ou Google AI Studio. Os primeiros deixam o código à vista de uma equipe técnica; as segundas o escondem mais e muitas vezes o publicam sozinhas.
Na revisão, a ferramenta muda onde se olha primeiro, não o que precisa ser olhado. Nas plataformas que publicam sozinhas, o primeiro são as chaves e as permissões do banco de dados; nos editores, as dependências e as rotas que foram adicionadas sem que ninguém pedisse.
O que revisar antes de publicar
Seis coisas, nesta ordem: segredos e credenciais fora do código; rotas e permissões, para ninguém ver o que não é seu; dados pessoais, nas respostas e nos logs; desempenho com o volume real, não com três linhas de teste; dependências e versões; e o que acontece quando algo falha, que é onde se vê se o sistema avisa ou fica calado.
Nenhuma das seis se comprova lendo o código por cima: elas se medem. Por isso uma revisão serve e uma lida rápida não.
Como nós revisamos
Com ferramentas de IA que se adaptam ao seu desenvolvimento e olham primeiro os pontos onde sabemos que a IA falha, e com uma pessoa experiente revisando cada achado. Nunca deixamos uma ferramenta trabalhando sozinha: o que entregamos leva evidência de cada ponto, com a medição ao lado.
Se o desenvolvimento é um site, essa revisão é a de sites; se é um app, a de aplicativos móveis; se é a parte de servidor, a do backend e da sua API.