Nunca foi tão fácil tirar uma ideia do papel. Você descreve o que quer para uma IA, ela escreve o código, você testa, pede ajustes e, em uma tarde, tem algo funcionando na tela. Esse jeito de programar ganhou nome: vibe coding.
A gente acha isso ótimo. Mais gente testando ideias significa mais problemas sendo resolvidos. Mas existe uma diferença grande entre um protótipo que funciona na sua máquina e um produto em que clientes, funcionários ou dinheiro dependem dele todos os dias. Este guia é sobre essa diferença.
O que é vibe coding
O termo foi popularizado pelo pesquisador Andrej Karpathy no começo de 2025. A ideia é programar "pela vibe": você conversa com a IA em linguagem natural, aceita o código que ela propõe e vai ajustando pelo resultado, sem necessariamente ler ou entender cada linha.
Ferramentas como Cursor, Lovable, Bolt, Replit e o próprio Claude tornaram isso acessível para quem nunca programou. Hoje um dono de negócio monta sozinho um app de agendamento, um painel de vendas ou um sistema de pedidos.
Onde ele brilha
Vibe coding é uma ferramenta excelente quando o objetivo é aprender rápido:
- Validar uma ideia antes de investir nela de verdade.
- Mostrar para clientes ou sócios algo concreto, em vez de um slide.
- Ferramentas internas pequenas, usadas por poucas pessoas e sem dados sensíveis.
- Descobrir o que você realmente precisa. Muitas vezes, o protótipo mostra que o problema era outro.
Nesses casos, velocidade vale mais que robustez. E tudo bem.
Quando o protótipo vira produto
O ponto de virada raramente é anunciado. Ele acontece aos poucos: um cliente começa a usar, depois dez. A planilha antiga é desligada. A equipe passa a depender do sistema para trabalhar. Um dia alguém pergunta "e se isso sair do ar?" e ninguém sabe responder.
Algumas perguntas ajudam a saber se você já passou desse ponto:
- Pessoas fora da sua equipe usam o sistema?
- Ele guarda dados de clientes, como nome, telefone, CPF ou endereço?
- Passa dinheiro por ele, como pedidos, pagamentos ou cobranças?
- Se ele parar por um dia, a operação para junto?
Se você respondeu sim a qualquer uma, o seu protótipo já é um produto. E produto pede outro tipo de cuidado.
Os riscos que não aparecem na demonstração
Um protótipo feito por IA costuma funcionar bem no caminho feliz, aquele em que tudo dá certo. Os problemas moram nos outros caminhos.
Segurança
É comum encontrar chaves de acesso a serviços (APIs, banco de dados, pagamentos) escritas direto no código que vai para o navegador, onde qualquer pessoa consegue ler. Também é comum um banco de dados acessível pela internet sem regras que digam quem pode ler o quê. A IA escreve o que você pediu, e "proteja isso" raramente estava no pedido.
Dados pessoais e LGPD
Guardou dado de cliente, entrou na LGPD. Isso envolve saber onde os dados ficam, quem acessa, por quanto tempo são guardados e como apagar quando pedirem. Um vazamento não é só um problema técnico. É um problema jurídico e de reputação.
Código que ninguém entende
Quando o código é aceito sem ser lido, ele cresce sem um desenho por trás. Cada novo pedido para a IA resolve um problema e cria dois. Chega um momento em que corrigir um botão quebra o login, e ninguém sabe por quê. Esse é o sinal mais claro de que o projeto precisa de engenharia.
Dependências inventadas ou abandonadas
Modelos de IA às vezes sugerem bibliotecas que não existem, ou que existem mas estão abandonadas. Já há gente mal-intencionada publicando pacotes com esses nomes "inventados" justamente para ser instalada por engano.
Escala e custo
O que funciona para cinco usuários pode travar com quinhentos. E serviços cobrados por uso, como hospedagem, banco de dados e chamadas de IA, podem gerar uma conta surpresa quando o volume cresce sem controle.
Sem rede de proteção
Muitos protótipos não têm histórico de versões, cópia de segurança (backup), ambiente de testes separado do de produção, nem alerta quando algo quebra. Tudo funciona até o dia em que não funciona, e aí não há como voltar.
O que é "fazer engenharia" na prática
Engenharia de software não é burocracia nem jogar fora o que você construiu. É colocar o mínimo de estrutura para o sistema ser confiável, seguro e fácil de mudar. Na prática, costuma ser assim:
- Diagnóstico. Ler o código, entender o que ele faz e listar os riscos por gravidade. Às vezes o estado é melhor do que parece. Às vezes é pior.
- Proteger o básico. Tirar segredos do código, revisar login e permissões, travar o acesso ao banco de dados.
- Rede de proteção. Controle de versões (Git), backup automático, um ambiente para testar antes de publicar e alertas quando algo falha.
- Testes no que importa. Não precisa testar tudo. Precisa testar o que dá prejuízo se quebrar: pagamento, cálculo, cadastro.
- Organizar para crescer. Separar as partes do sistema, documentar as decisões e deixar o código legível para a próxima pessoa, seja ela humana ou IA.
Reescrever ou consertar?
Nem sempre é preciso começar do zero. Se o protótipo tem uma base razoável, dá para evoluir em etapas, mantendo o sistema no ar. Se a base não se sustenta, o protótipo continua tendo enorme valor: ele já validou a ideia, mostrou o que os usuários querem e serve de especificação viva para a versão definitiva.
A decisão certa depende do diagnóstico, não de opinião. Por isso ele vem primeiro.
Para resumir
- Vibe coding é ótimo para aprender rápido e validar ideias.
- Quando pessoas, dados ou dinheiro passam a depender do sistema, ele virou produto.
- Produto pede segurança, rede de proteção e código que alguém entende.
- Engenharia não é recomeçar do zero. É dar ao que você já construiu condições de crescer sem quebrar.
Se você tem um sistema que nasceu assim e está começando a ficar importante demais para dar errado, vale uma conversa.