Testei vibe coding numa feature real de um SaaS que estou desenvolvendo. Economizei horas em alguns lugares e reescrevi tudo em outros. O critério que adotei pra decidir quando deixar a IA dirigir e quando assumir o volante.
Tem uma feature num SaaS que estou desenvolvendo que eu construí em uma tarde descrevendo o que eu queria em português pro agente e aceitando quase tudo que ele cuspia. Funcionou. Subiu pra produção naquela semana. Eu me senti um deus.
Três semanas depois, voltei naquele código pra adicionar um campo. Levei o dobro do tempo que levaria se eu mesmo tivesse escrito do zero. Não porque o código estava errado: ele passava nos testes, fazia o que prometia. Estava errado de um jeito mais sutil, escrito de um jeito que eu não entendia mais. Abstrações que eu não teria criado, nomes que não eram os meus, uma estrutura que fazia sentido pra IA naquele prompt e nenhum sentido pra mim três semanas depois.
Aquela tarde "produtiva" tinha me deixado uma conta pra pagar. E é uma conta que quase ninguém está colocando na planilha quando fala de vibe coding.
Eu já escrevi aqui sobre dívida técnica que vale pagar e a que vale ignorar. A tese daquele post era que dívida técnica é um instrumento, não um erro: você decide conscientemente o que pagar e o que adiar. O problema do vibe coding é que ele cria dívida que você não decidiu contrair. Ela entra escondida, disfarçada de produtividade.
O que vibe coding é, sem o hype
Pra deixar claro do que eu tô falando: vibe coding, no sentido que virou mainstream em 2026, é descrever o que você quer em linguagem natural e deixar o agente construir, aceitando o resultado sem necessariamente ler linha por linha. Você programa pela "vibe": testa, parece que funciona, segue em frente.
Não é a mesma coisa que usar IA como assistente. Quando eu peço pro agente gerar um trecho, leio, ajusto e integro, isso é pair programming com uma máquina rápida. Vibe coding é quando eu paro de revisar e começo a confiar no output como se fosse meu.
A diferença não é o ferramental. É quanto da decisão de design eu terceirizo sem perceber. E é exatamente aí que a dívida nasce.
Onde vibe coding realmente economizou meu tempo
Não quero ser o cara que reclama da ferramenta. Tem casos onde vibe coding foi puro ganho, sem conta escondida nenhuma. Eu reparei um padrão: funciona melhor quanto mais descartável e mais isolado for o código.
Scripts de uso único. Quando precisei migrar uns dados de um formato antigo pra um novo, descrevi a transformação e aceitei o que veio. O script rodou uma vez e foi deletado. Não existe dívida técnica em código que não vai ser mantido: a manutenção é o que cobra a conta, e aqui não havia manutenção.
Boilerplate que eu já sei como deveria ficar. Um CRUD novo, um componente de formulário no padrão que o resto do projeto já segue. Aqui eu já tenho o modelo mental pronto, então quando o agente erra eu vejo na hora. A IA é rápida e eu sou o filtro. O risco de não entender depois é baixo porque a estrutura é a mesma de outros 20 lugares do código.
Prototipar pra jogar fora. Quando eu quero ver se uma ideia de UI faz sentido antes de investir nela. O código é explicitamente provisório. Se a ideia vingar, eu reescrevo com calma. Se não, deletei.
O fio comum: nesses três casos, ou o código morre rápido, ou eu já tenho na cabeça como ele deveria ser. A IA não está tomando decisões de design que eu vou ter que viver depois.
Onde a conta chegou — e doeu
Os casos ruins têm o padrão oposto: código que vai ser mantido por muito tempo e onde eu não tinha um modelo mental forte de como deveria ficar.
A tal feature da tarde mágica era lógica de negócio nova: uma regra de priorização de leads que não existia em lugar nenhum do código pra eu copiar o padrão. Como eu não tinha referência, aceitei a estrutura que a IA propôs. E a estrutura dela era razoável pra alguém que via aquele prompt isolado, mas não conversava com o resto do sistema. Ela criou uma abstração nova pra algo que já tinha um jeito estabelecido de ser feito em outros módulos. Resultado: duas formas de fazer a mesma coisa no mesmo código.
O segundo caso foi pior porque foi silencioso. O agente gerou um trecho que tratava um caso de borda de um jeito que parecia certo e passava no teste que ele mesmo escreveu. Só que o teste validava o comportamento errado. Os dois, código e teste, estavam confiantemente de acordo entre si e errados juntos. Demorei pra pegar porque, quando você não escreveu o código, você não tem aquela desconfiança natural sobre as partes que você sabe que improvisou. Tudo parece igualmente sólido.
Essa é a parte que ninguém mede: vibe coding remove o seu mapa mental do código. E o mapa mental é justamente o que te faz desconfiar do lugar certo quando algo dá errado.
Impacto em números
Contra ~1 dia escrevendo eu mesmo
O dobro do que levaria em código que eu entendia
Teste gerado pela IA validava comportamento errado
O critério que adotei: as mesmas perguntas da dívida técnica
Eu não criei um framework novo. Eu peguei as perguntas que já uso pra decidir o que refatorar e apliquei na decisão de quando deixar a IA dirigir.
A primeira pergunta é esse código vai ser mantido?. Se for descartável (script único, protótipo, experimento), solta a vibe. Não existe dívida em código que morre antes de alguém precisar entendê-lo de novo.
A segunda é eu tenho um modelo mental de como isso deveria ficar?. Se sim, eu consigo ser o filtro: aceito o que está no padrão e rejeito o que foge. Se não, se é lógica nova, território desconhecido, aí eu preciso dirigir, porque a estrutura que eu aceitar vai virar a estrutura que eu vou viver. Aqui a IA gera trechos, mas as decisões de design são minhas.
A terceira é o que acontece quando isso falhar?. Lógica de cobrança, autenticação, regra de negócio que mexe no dinheiro do cliente: aqui o custo de um bug sutil é alto demais pra eu abrir mão de entender cada linha. Vibe coding em código crítico é trocar uma tarde de trabalho por uma madrugada de plantão.
Quando as três respostas apontam pra "código descartável, padrão conhecido, falha barata", eu deixo a IA dirigir sem culpa. Quando apontam pro contrário, eu assumo o volante e uso a IA como copiloto, não como motorista.
O sinal de que você passou do ponto
Tem um momento específico em que eu aprendi a parar. É quando eu vou aceitar uma sugestão do agente e percebo que não saberia explicar por que aquilo funciona.
Não "não li com atenção". É "li, parece certo, mas se alguém me perguntasse por que essa abordagem e não outra, eu não saberia responder". Esse é o ponto exato em que eu deixei de programar e comecei a apenas aprovar. E código que eu apenas aprovei é código que eu não vou conseguir manter, debugar sob pressão, nem explicar pra mais ninguém.
Quando bate esse sinal, eu paro, leio de verdade, e ou entendo a sugestão a ponto de poder defendê-la, ou reescrevo do meu jeito. A regra é simples: eu preciso conseguir defender cada decisão de design do código que entra em produção como se eu a tivesse tomado, porque, do ponto de vista de quem vai manter, eu tomei.
O que mudou na minha cabeça
A pergunta sedutora do vibe coding é "quão rápido eu consigo fazer isso funcionar?". É uma pergunta de velocidade, e a IA responde ela maravilhosamente bem. Quase tudo "funciona" rápido.
A pergunta que eu me faço hoje é "quem vai manter isso, e essa pessoa — provavelmente eu daqui a um mês — vai entender?". É uma pergunta mais chata e mais lenta, mas é a que importa, porque software não se paga no momento em que funciona pela primeira vez. Ele se paga ao longo de todas as vezes que alguém precisa mudá-lo depois.
Vibe coding não é o vilão. Ele é uma alavanca poderosa pra um tipo específico de código: o descartável, o padronizado, o de baixo risco. O erro é usar a mesma alavanca pra código que vai morar no sistema por anos. Aí você não está economizando tempo. Está pegando um empréstimo, sem assinar nada, com juros que só aparecem na próxima vez que você abrir aquele arquivo.
Dívida técnica boa é a que você contrai de olhos abertos. A dívida do vibe coding é perigosa justamente porque parece grátis. E na engenharia, assim como em tudo, o que parece grátis costuma ser o mais caro.