Desenvolver sem ler o código gerado pela IA, apenas pressionando Accept All, é o que hoje chamamos de “vibe coding”. O início é surpreendentemente rápido, e muita gente diz que, depois de experimentar, é difícil voltar atrás. Ainda assim, é melhor saber de antemão onde e como será cobrado o preço de não ler o código.
Neste artigo, organizo a definição exata e as vantagens do vibe coding, três problemas que surgem quando você não lê o código e três soluções para reduzir incidentes sem ler tudo.
Vamos começar pela conclusão.
Vibe coding deixa o início dez vezes mais rápido, mas, se você não ler o código, essa velocidade volta na forma de custo de manutenção.
Para um protótipo ou uma ferramenta que só você usa, vale muito a pena experimentar. Mas, se o serviço será oferecido a outras pessoas ou o código precisará ser mantido por muito tempo, a história muda. Vamos entender por quê.
O que exatamente é vibe coding?
Vamos começar pelo termo. “Vibe coding” surgiu de uma publicação que Andrey Karpathy fez no Twitter em fevereiro de 2025.
A ideia central é simples: você diz à IA o que quer em linguagem natural, a IA escreve o código e a pessoa não lê esse código com atenção.
O próprio Karpathy disse: “Eu sempre pressiono Accept All e não leio mais o diff”. Quando ocorre um erro, ele copia a mensagem sem alterá-la e a envia novamente para a IA.
Vale mencionar que o Collins Dictionary também escolheu esse termo como a “palavra do ano” de 2025.
A essência do vibe coding está mais em “não ler o código” do que em “codificar com IA”. Mesmo usando IA, se você lê todo o diff, isso é apenas desenvolvimento assistido por IA, não vibe coding.
As vantagens são claras
Existe um motivo para o vibe coding ter se tornado popular.
Primeiro, a velocidade para começar. A configuração inicial de um projeto, que antes levava dias, cai para dezenas de minutos. O tempo até algo aparecer na tela fica drasticamente menor.
Segundo, compensar pontos fracos. A barreira de entrada em áreas pouco conhecidas diminui muito; por exemplo, um desenvolvedor backend pode descrever um layout em CSS com palavras e pedir que ele seja gerado.
Terceiro, o bloqueio psicológico. A vontade de “vamos construir primeiro” aumenta, e você finalmente mexe em ideias que vinha adiando.
O problema é que essa satisfação normalmente dura apenas no começo do projeto, enquanto o código ainda é pequeno.
O que realmente acontece quando você não lê o código
Quando a base de código cresce até certo ponto, três problemas comuns aparecem.
1. Você deixa de conseguir corrigir bugs. Se entregar cada erro diretamente à IA, você trava quando ela não consegue corrigi-lo. Como nunca leu o código, nem consegue imaginar onde está o problema.
2. A mesma funcionalidade aparece em vários lugares. A IA muitas vezes esquece o código anterior e continua criando funções parecidas. Depois, você corrige uma e as outras continuam iguais.
3. Brechas de segurança silenciosas são abertas. Um caso clássico é uma chave de API ficar embutida diretamente no código do cliente. A IA apenas segue as instruções, e a pessoa não verifica.
O terceiro é o mais assustador. Por exemplo, um código assim.
// AICódigo escrito pela IA — chave exposta no cliente
let apiKey = "sk-live-abc123" // Incluída diretamente no binário do app
let url = URL(string: "https://api.example.com?key=\(apiKey)")!
URLSession.shared.dataTask(with: url).resume()Com um código desses, qualquer pessoa pode ver a chave assim que o app é publicado. Se você não lê o diff, deixa isso passar.
Então, o que fazer? Três soluções
Felizmente, há maneiras de reduzir bastante os incidentes sem voltar a “ler tudo”.
Solução 1. Leia pessoalmente as três áreas críticas. Mesmo sem ler tudo, defina e verifique as partes em que um incidente seria difícil de reverter.
// No mínimo, verifique pessoalmente estas três coisas
// 1) Código relacionado a autenticação e chaves
// 2) Lógica relacionada a pagamentos e dinheiro
// 3) Partes que excluem ou alteram dados de usuáriosCuidar apenas dessas três áreas já reduz bastante a chance de um incidente crítico.
Solução 2. Leia o resumo da IA em vez do código. Se você não quer ler o código, pelo menos peça mais uma vez: “Resuma apenas os riscos de segurança, dinheiro e exclusão de dados no código que você acabou de escrever”, e leia esse resumo. Faça a revisão em uma nova sessão, de preferência com outra IA, e não na sessão que escreveu o código; assim, você também reduz o viés de defender o próprio código.
Solução 3. Se as pessoas não vão ler, faça as máquinas lerem. Adicione um scanner de secrets como o gitleaks a um hook pre-commit, e a exposição de chave de API mostrada acima será detectada automaticamente no commit. Colocar linter e testes na CI segue o mesmo princípio.
As três soluções têm algo em comum: reduzir o custo de leitura sem reduzir a verificação a zero.
Então, você deve usar vibe coding ou não?
A conclusão é: “depende da situação”.
| Situação | Recomendação | Motivo |
|---|---|---|
| Protótipo/demo | Altamente recomendado | Faça rápido e descarte se necessário |
| Ferramenta de uso pessoal | Recomendado | Se quebrar, só eu terei problemas |
| Projeto paralelo | Condicional | Leia a lógica central |
| Serviço em produção/colaboração em equipe | Não recomendado | O custo de manutenção consome o ganho de velocidade |
A diferença fundamental é não ler código algum ou ler apenas as partes importantes.
P. Iniciantes também podem aprender desenvolvimento com vibe coding? R. É ótimo para sentir o prazer de criar. Mas, se você nunca ler o código, suas habilidades não vão evoluir muito. Depois de criar algo, pergunte à IA “por que você escreveu este código assim?” e cultive o hábito de ler.
P. Até que ponto posso confiar no código escrito pela IA? R. Funcionar e ser seguro são coisas diferentes. Você pode confiar na IA para fazê-lo funcionar, mas uma pessoa ou um mecanismo independente de verificação precisa confirmar se ele é seguro e sustentável.
Em resumo: “a velocidade fica com a IA; o julgamento, comigo”. Você não precisa ler tudo, mas, se não ler nada, um dia pagará o preço. Adicionar ao projeto de hoje pelo menos uma das três soluções acima pode reduzir muito esse preço.
Indo um passo além, existe também uma metodologia chamada desenvolvimento orientado por especificações (SDD), que primeiro define os requisitos em um documento antes de pedir à IA para escrever código. É uma abordagem oposta ao vibe coding, e vou tratá-la em detalhes no próximo artigo.
Referências
- Vibe coding - Wikipedia
- Not all AI-assisted programming is vibe coding (but vibe coding rocks) - Simon Willison