Vibe coding é maravilhoso até o dia em que o código passa a dever dinheiro para alguém. Enquanto o protótipo está na sua máquina, tudo bem pedir para a IA “faz isso funcionar” e comemorar quando a tela acende. O problema começa quando aquilo passa a cobrar cartão, guardar dado de cliente, acionar uma API cara ou virar dependência de uma equipe inteira.
Código abundante muda o gargalo
Com IA, produzir código ficou mais barato. Revisar decisão ruim, entender dependência, testar comportamento e responder por incidente não ficou. Em muitos times, o gargalo saiu da implementação e foi para o julgamento. Isso é bom, desde que alguém aceite que julgamento também precisa de processo. A regra prática é simples: quanto maior o impacto de uma falha, menor pode ser a tolerância ao “parece certo”. Autenticação, cobrança, permissão, exclusão de dados, integrações críticas e operações irreversíveis merecem revisão humana, testes e logs. Uma tela administrativa interna pode aceitar muito mais improviso.
O perigo é o código que ninguém entende
O pior cenário não é a IA errar. É ela acertar de um jeito que o time não consegue explicar. Se ninguém sabe por que funciona, ninguém sabe o que vai quebrar quando a próxima mudança chegar. Código gerado precisa entrar no mesmo contrato do resto: dono, revisão, teste, observabilidade e caminho de rollback.
Use a IA para comprimir trabalho, não responsabilidade
Uma boa política não proíbe vibe coding. Ela define fronteiras. Protótipo? Solta. Ferramenta interna reversível? Quase solta. Produção com dinheiro ou dado sensível? Cinto, airbag e alguém habilitado no banco da frente. A IA pode escrever metade do sistema. Ótimo. A outra metade continua sendo saber se esse sistema merece existir desse jeito. Essa parte, infelizmente, ainda não vem no autocomplete.