Guia
Vibe coding é ruim? O que dá errado e como verificar seu código
Vibe coding não é ruim em si. O risco é publicar código que ninguém leu. Os erros que os assistentes de IA repetem, quando eles importam e como detectá-los.
· 7 min de leitura · Pela equipe do vetkit
A resposta curta
Não, vibe coding não é ruim em si. É um jeito rápido de chegar a um software funcionando e, para protótipos, ferramentas internas e aprendizado, muitas vezes é a escolha certa. Vira um problema em um ponto específico: quando um código que ninguém leu começa a lidar com usuários reais, dados reais ou dinheiro de verdade. O risco não é uma IA ter escrito o código. O risco é ninguém ter verificado.
Então a pergunta útil não é “vibe coding é ruim?”, e sim “o que eu preciso verificar antes de colocar isso no ar?”. O restante deste guia responde a essa pergunta.
O que significa vibe coding
Vibe coding é construir software descrevendo o que você quer para um assistente de IA e aceitando o código que ele escreve, em grande parte sem lê-lo. O termo foi cunhado por Andrej Karpathy no início de 2025 para um jeito de trabalhar em que você se entrega às vibes e esquece que o código sequer existe. Você julga o resultado rodando o app, não revisando as mudanças.
Isso é diferente do desenvolvimento assistido por IA, em que o desenvolvedor usa as mesmas ferramentas, mas continua lendo, testando e assumindo a responsabilidade por cada mudança. A maioria dos projetos reais fica em algum ponto entre os dois e escorrega para o vibe coding quando os prazos apertam.
O que dá errado
Assistentes de IA são bons em produzir código que roda. São menos confiáveis no que não aparece quando você clica pelo app uma vez. Os mesmos erros aparecem de novo e de novo:
| Problema | Como ele aparece | Por que você não percebe |
|---|---|---|
| Segredos no lugar errado | Uma chave de API commitada no repositório ou enviada no bundle do navegador | O app funciona exatamente igual de qualquer jeito |
| Verificações de acesso ausentes | Qualquer usuário logado consegue ler os registros de outro usuário; tabelas do banco sem regras por linha | Você só testa com a sua própria conta |
| Pacotes que não existem | O assistente inventa um nome de pacote plausível, e outra pessoa pode tê-lo registrado | O comando de instalação funciona |
| Código inacabado | Funções placeholder, branches de TODO e erros engolidos deixados no fluxo principal | O caminho feliz continua passando |
| Entrada não confiável usada diretamente | Dados da requisição inseridos em SQL, comandos de shell, caminhos de arquivo ou HTML | Entradas normais se comportam normalmente |
| Nada preparado para falhas | Chamadas HTTP sem timeout, consultas dentro de loops, nenhum relatório de erros | É rápido com dez linhas e um usuário |
Nenhum deles é novo. Desenvolvedores cometiam todos antes de os assistentes de IA existirem. O que muda com o vibe coding é o volume e a etapa de revisão que falta: mais código chega mais rápido, e a pessoa que teria pegado o problema nunca o lê. Três deles são tratados em detalhe em outras páginas deste site: chaves de API no navegador, pacotes inventados e segredos vazados.
Quando importa e quando não importa
Vibe coding é uma escolha razoável quando um erro sai barato:
- Um protótipo ou demo que vai ser descartado ou reescrito.
- Um script pessoal ou uma ferramenta interna sem dados sensíveis.
- Aprender um novo framework ou explorar uma ideia.
Precisa de uma verificação antes do lançamento quando um erro sai caro:
- O app tem contas de usuário, pagamentos ou dados pessoais.
- Ele guarda credenciais de outros serviços, como um provedor de LLM ou um banco de dados.
- Outras pessoas vão depender de ele ficar no ar, ou outra pessoa vai ter de mantê-lo.
A linha não é como o código foi escrito. É o que acontece se o código estiver errado. Muitos projetos cruzam essa linha sem que ninguém tenha decidido isso: a demo ganha os primeiros usuários reais e ninguém volta para lê-la.
Como manter a velocidade e eliminar o risco
Você não precisa abrir mão da velocidade. Precisa trazer de volta a verificação que o vibe coding pula.
- Leia as mudanças que mexem com dinheiro, login e dados. Você pode pular a leitura do código de layout. Não pode pular autenticação, autorização, pagamentos e tudo o que escreve no banco de dados. O checklist de revisão de código gerado por IA lista o que procurar.
- Teste com duas contas. Entre como um usuário e tente ler ou alterar os registros de outro. Esse único teste encontra a classe de bug mais danosa em apps feitos com vibe coding.
- Verifique cada nova dependência. Confirme que o pacote existe, que é o que você queria e que não foi publicado na semana passada.
- Escaneie o repositório antes de publicar. Uma auditoria automatizada encontra os problemas mecânicos mais rápido que uma pessoa: segredos commitados, dependências vulneráveis ou inexistentes, timeouts ausentes e tratamento inseguro de entradas. O catálogo de verificações do vetkit mostra as regras que ele executa, e o Security Quick Scan gratuito cobre segredos, vulnerabilidades conhecidas em dependências e a postura básica.
- Peça ao assistente para corrigir o que o scan encontrar. Conecte o scanner ao seu agente de código para que os achados voltem para a mesma conversa. O guia de MCP mostra como.
Quando estiver pronto para lançar, o checklist de segurança antes de publicar um app feito com vibe coding percorre a decisão de lançamento passo a passo.
Fontes e limitações
A lista de problemas comuns reflete as categorias cobertas pelas regras próprias do vetkit para riscos de código de IA, segurança, resiliência e acesso a dados, verificadas em 10 de novembro de 2026. É uma descrição de padrões recorrentes, não uma medição de com que frequência eles ocorrem. O termo “vibe coding” vem do post de Andrej Karpathy de fevereiro de 2025.
Um scan automatizado é uma evidência a ser revisada, não uma prova de que o app é seguro. Ele lê o código-fonte; não testa as permissões do seu deploy, a configuração da sua hospedagem nem as suas regras de negócio. O teste com duas contas e a revisão manual acima continuam sendo trabalho seu.