O que é vibe coding e quais os riscos de programar só com IA

Vibe coding é programar descrevendo o que você quer para uma IA e aceitando o código que ela gera sem ler linha por linha. Você pede, roda, vê se funciona, cola o erro de volta no chat e repete. O código existe, mas você não olha para ele.

O termo foi cunhado por Andrej Karpathy (ex-diretor de IA da Tesla e cofundador da OpenAI) em fevereiro de 2025, num post em que ele dizia “esquecer que o código existe”. A expressão pegou tão rápido que hoje muita gente chama de vibe coding qualquer uso de IA para programar. O desenvolvedor Simon Willison escreveu um texto importante sobre isso, nem toda programação assistida por IA é vibe coding: se você revisa, testa e entende o que a IA escreveu, você está usando IA como ferramenta, não fazendo vibe coding.

Essa distinção importa porque os riscos aparecem justamente na parte que ninguém leu. Abaixo, os erros que mais custam caro, com o que cada um provoca na prática.

Colocar em produção um protótipo que nasceu para ser descartado

O vibe coding funciona muito bem para coisas descartáveis: um script que renomeia 300 arquivos, uma página de teste para mostrar uma ideia ao chefe, uma ferramenta interna que só você usa. Se quebrar, você joga fora e pede de novo.

O problema começa quando o protótipo dá certo e alguém diz “já está funcionando, sobe assim mesmo”. Aquele código não foi pensado para ter usuários reais, dados de clientes ou picos de acesso. O custo aparece meses depois, quando ninguém no time sabe explicar por que uma função faz o que faz, e mexer em uma parte quebra outras três.

Uma regra útil: se o código vai lidar com dinheiro, dados pessoais ou login, ele sai do modo vibe e entra no modo revisão.

Achar que funcionar no teste manual significa estar seguro

O app abre, o formulário salva, o botão funciona. Mas segurança raramente aparece no teste de clique. Os problemas que a IA costuma deixar passar quando ninguém revisa:

• Chaves de API escritas direto no código, que vão parar no GitHub público.
• Consultas ao banco montadas com texto concatenado, abrindo espaço para SQL injection.
• Rotas sem checagem de permissão: qualquer pessoa que descobre o endereço acessa dados de outros usuários.
• Regras de acesso do banco liberadas em serviços como Firebase ou Supabase, porque “deu erro de permissão e a IA sugeriu abrir”.

Veja um exemplo que um modelo pode gerar se você pedir “busque o usuário pelo nome”:

query = "SELECT * FROM usuarios WHERE nome = '" + nome + "'"
cursor.execute(query)

Funciona em todos os testes normais. Basta alguém digitar ' OR '1'='1 no campo para receber a tabela inteira. A versão correta usa parâmetros:

cursor.execute("SELECT * FROM usuarios WHERE nome = %s", (nome,))

Quem lê o código percebe em dois segundos. Quem não lê, publica. A lista do OWASP Top 10 para aplicações com LLM tem um item específico, “Improper Output Handling”, sobre usar a saída de um modelo sem validar.

Instalar a dependência que a IA inventou

Modelos de linguagem às vezes sugerem pacotes que não existem, com nomes plausíveis. Pesquisadores de segurança notaram que esses nomes se repetem, e criminosos passaram a registrar pacotes com esses nomes no npm e no PyPI contendo código malicioso. A técnica ganhou até apelido: slopsquatting.

No modo vibe, você roda o npm install que a IA mandou sem conferir. Antes de instalar qualquer pacote desconhecido, abra a página dele no registro e veja: há quanto tempo existe, quantos downloads tem, quem mantém, se o repositório é real. O texto sobre o Package Firewall do GitHub para dependências npm mostra como bloquear esse tipo de pacote antes de ele chegar ao projeto.

Deixar o agente com acesso demais à sua máquina

As ferramentas atuais não só escrevem código: executam comandos no terminal, apagam arquivos, fazem commit e push. Quando você aceita tudo sem ler, um comando errado pode apagar uma pasta, sobrescrever o banco de desenvolvimento ou publicar segredos.

O que costuma funcionar:

1. Rodar o agente dentro de um repositório Git com tudo commitado antes, para conseguir voltar atrás.
2. Manter a confirmação manual ligada para comandos que apagam, instalam ou fazem deploy.
3. Nunca deixar arquivos .env com credenciais de produção na pasta em que o agente trabalha.
4. Instalar extensões e plugins só de fontes oficiais. Já houve casos de extensões falsas imitando ferramentas de IA, como a extensão falsa do Claude Code no Cursor.

Pular a parte em que você aprende

Este é o risco mais silencioso para quem está começando.

Um júnior que entrega tudo via vibe coding pode parecer produtivo por alguns meses. Mas na primeira entrevista técnica, na primeira revisão de código com um sênior ou no primeiro bug que a IA não consegue resolver, falta base: ler uma stack trace, entender por que um loop está lento, saber o que é uma referência nula.

A forma de usar IA sem esse custo é pedir explicação junto com o código, reescrever trechos com as próprias mãos e, de vez em quando, tentar resolver sozinho antes de perguntar. Se você não consegue explicar o que uma função faz, ela ainda não é sua.

Medir produtividade pela velocidade da primeira versão

A primeira versão sai em minutos, e isso impressiona. Só que software passa a maior parte da vida sendo mantido, não escrito.

O código gerado sem critério costuma ter duplicação, funções gigantes e nomes vagos. Cada pedido novo à IA vem com mais contexto confuso, e a qualidade das respostas cai. Projetos assim tendem a chegar num ponto em que nem a IA consegue mais mexer sem quebrar algo.

Ignorar o que a lei diz sobre os dados que o app coleta

Se o seu app coleta nome, e-mail, CPF ou localização de brasileiros, ele está sob a Lei Geral de Proteção de Dados, fiscalizada pela Autoridade Nacional de Proteção de Dados. A IA não vai lembrar você de criar política de privacidade, pedir consentimento ou permitir que o usuário apague a conta. Ela faz o que você pede, e quase ninguém pede isso.

Como usar IA para programar sem cair nessas armadilhas

Vibe coding tem lugar: experimentação, ferramentas pessoais, aprendizado de uma biblioteca nova. Fora disso, trate a IA como um colega rápido e um pouco descuidado, cujo código sempre passa por revisão.

Um checklist curto antes de qualquer código gerado ir para produção:

• Eu li e entendi cada função?
• Existem testes automatizados para o que importa?
• Nenhum segredo está no código ou no histórico do Git?
• Todo pacote instalado existe de verdade e tem manutenção?
• As rotas checam quem está pedindo o quê?

Para outros termos que aparecem nessa conversa, como LLM, agente e prompt, o glossário de programação do BuildBase mantém as definições atualizadas. A recomendação direta: use a IA à vontade, mas nunca coloque no ar um código que nenhum humano leu.