O Abismo Entre "Vibe Coding" e Software de Verdade

Semana passada, uma founders me mostrou um web app funcionando que ela criou num fim de semana usando ferramentas de IA. Sem diploma de Ciência da Computação, sem bootcamp. Só uma ideia clara e um prompt bem escrito. Impressionante, de verdade. Sistema de login, dashboard, persistência de dados — tudo em menos de 72 horas.

Aí ela me pediu ajuda para colocar isso nas mãos de usuários reais.

E foi aí que as coisas ficaram interessantes.

O Prototype Funciona Quando Você É o Único Usuário

O protótipo dela rodava lisinha. Só que ela era a única pessoa usando. No momento em que tentamos adicionar um segundo usuário, bugs de concorrência apareceram do nada. O banco de dados não tinha schema migrations, então um rollback destruiria dados. Não existiam testes, o que transformava qualquer refatoração em uma operação de alto risco. E o deployment era um processo manual, sem qualquer documentação.

O projeto de fim de semana dela era uma prova de conceito excelente. Não era software pronto para produção.

É esse o ponto que a conversa sobre "vibe coding" insiste em ignorar. As ferramentas são reais. A velocidade é real. A democratização da criação de software é empolgante. Mas existe uma diferença enorme entre gerar código e fazer engenharia de software. E essa diferença importa mais do que a maioria das pessoas imagina — até estarem lidando com um incidente às 3 da manhã.

A Métrica Que Realmente Importa

Quando vejo código gerado por IA, sempre faço a mesma pergunta: isso pode ser mesclado com segurança no codebase compartilhado?

Não estou perguntando "funciona?". Não estou perguntando "a demo rodou?". Quero saber se pode ser mesclado com segurança. Essa palavra "seguro" carrega muito peso. Significa que o código pode ser revisado por alguém que não escreveu. Significa que os testes verificam comportamento, não apenas que o programa não crasha. Significa que rollback é possível sem perda de dados. Significa que a mudança é pequena o suficiente para ser entendida e explicada.

Quando um vibe coder mede sucesso, geralmente está medindo tempo até a primeira versão funcionando. É uma métrica útil para descoberta e prototipagem. Mas quando o software entra num ambiente compartilhado, essa métrica para de ser útil. Agora você está medindo tempo até merge seguro — e isso inclui custo de revisão, qualidade dos testes, risco de deployment, overhead de coordenação e dívida de manutenção futura.

Um engenheiro de software pensa no ciclo inteiro desde o início. Um vibe coder frequentemente descobre essas preocupações depois, quando custam mais para resolver.

Geração de Código vs. Propriedade de Código

Há uma mudança sutil mas crítica que acontece quando a IA gera seu código. A saída não é ainda seu trabalho. É um ponto de partida que precisa ser transformado em algo que você realmente possui.

Propriedade significa algumas coisas. Você consegue explicar cada decisão significativa da mudança. Entende por que cada arquivo existe e o que faz. Contraint a mudança ao exatamente o necessário, sem boilerplate extra ou limpeza não relacionada. Escreveu ou verificou testes que capturam bugs reais, não apenas números de cobertura. Considerou o caminho de rollback.

Esse é o trabalho que a IA não pode fazer por você. A IA gera. Você decide. E "decidir" implica que você pensou em alternativas, ponderou tradeoffs e entendeu as consequências.

Quando olho para código gerado por IA que não foi devidamente transformado em propriedade, vejo os mesmos problemas. Mudanças grandes demais porque o modelo gerou mais do que o necessário. Pacotes adicionados sem justificativa clara. Testes que parecem escritos só para satisfazer uma ferramenta de cobertura, não para pegar bugs de verdade. Boilerplate que existe porque o modelo Defaults para scaffolding em vez de simplicidade.

Nada disso é culpa da IA. É resultado de um autor que tratou a saída gerada como progresso, em vez de matéria-prima.

O Problema de Revisão Que Ninguém Comenta

Algo que me tira o sono: código gerado por IA muda a equação da revisão.

Quando um desenvolvedor humano escreve código, geralmente existe um rastro de decisões. Você pode discordar das escolhas, mas pelo menos existem escolhas. Pode perguntar por que ele usou aquela abstração, por que a validação está ali, por que escolheu aquela library. As respostas podem ser "não pensei nisso" ou "pareceu razoável na hora", mas pelo menos tem uma pessoa para perguntar.

Com código gerado por IA, algumas dessas "decisões" não são decisões de verdade. São completions. O modelo escolheu um padrão porque era estatisticamente provável, não porque era o ajuste certo para seu problema. E se o autor não transformou essa completion em trabalho próprio, a revisão se torna um problema muito mais difícil.

Você não pode perguntar ao modelo por que escolheu aquela abordagem. Não pode perguntar ao autor por que fez aquela decisão se ele realmente não sabe. Então a revisão ou Surface problemas através de tentativa e erro dolorosa, ou não acontece de jeito nenhum.

Por isso acredito que a habilidade mais importante na era do desenvolvimento assistido por IA não é fazer prompts. É a capacidade de pegar a saída gerada e transformar em código que você entende profundamente o suficiente para possuir, explicar e manter.

O Que Isso Significa Para Sua Equipe

Se você está construindo um protótipo para testar uma ideia, vibe coding é uma abordagem legítima. Velocidade de aprendizado importa quando você ainda está validando premissas. Use as ferramentas, se mova rápido, construa algo para mostrar para as pessoas.

Mas se esse protótipo vai virar um produto real, em algum momento o código gerado precisa passar pelo filtro de alguém que pensa como engenheiro. Não para fazer gatekeeping. Não para deixar as coisas mais lentas. Mas para garantir que o que é shipped é código que pode ser entendido, mantido e confiável por uma equipe.

Aqui na NameOcean, vemos esse padrão o tempo todo. Startups que se movem rápido com ferramentas de IA para validar ideias, e depois batem de cara na parede quando precisam escalar. As boas trazem ajuda de engenharia nesse ponto. As ruins continuam empilhando features num codebase que ninguém realmente entende.

O objetivo não é evitar desenvolvimento assistido por IA. O objetivo é ser honesto sobre onde o trabalho começa e onde termina. A IA pode gerar código. Você precisa fazer engenharia de software.

O Final da História

Vibe coding é um ponto de partida fantástico. É uma forma de testar ideias rapidamente, aprender o que é possível e ir de conceito para algo tangível sem meses de desenvolvimento tradicional.

Mas engenharia de software é sobre o ciclo completo. É sobre código que sua equipe pode revisar, manter e confiar quando as coisas dão errado às 2 da manhã. É sobre mudanças pequenas o suficiente para entender e fazer rollback se necessário. É sobre assumir responsabilidade por decisões, mesmo quando essas decisões foram informadas por sugestões de IA.

Os melhores desenvolvedores que conheço usam ferramentas de IA extensivamente. Só fazem isso com os olhos abertos. Sabem que código gerado é matéria-prima, não produto acabado. E sabem que em algum momento, alguém precisa fazer o trabalho de engenharia que faz a diferença entre uma demo legal e software que você realmente pode shippar.

Então sim, vá em frente com o vibe coding. Construa rápido, experimente livremente, use todas as ferramentas disponíveis. Só saiba reconhecer quando é hora de mudar de vibe para engenharia. Seu eu do futuro, e sua equipe do futuro, vão agradecer.