A tese numa frase: gerar uma app «a vibrações» —descreves o que queres e a IA escreve o código— é maravilhoso para prototipar e um desastre para governar em produção. Não porque o código saia mau: hoje sai surpreendentemente bem. É porque uma app viva não é o código que se vê na demo; é tudo o que não se vê —os testes que avisam quando algo se parte, a observabilidade que te diz porquê, a segurança que impede um cliente de ver os dados de outro, e uma pessoa que responde quando cai às três da manhã. É o 70% aborrecido, e é precisamente o que o vibe coding não te dá com o mesmo gesto com que te dá o ecrã bonito.
O que é o vibe coding em produção e porque engana tanto
O termo foi popularizado por Andrej Karpathy no início de 2025 para descrever algo que já fazíamos todos: deixarmo-nos levar, descrever à IA o que queremos e aceitar o código que devolve sem o ler linha a linha. E funciona: numa tarde tens uma aplicação que arranca, que faz login, que guarda coisas numa base de dados e que mostras numa reunião com aplausos. O problema não é essa tarde. O problema é a conclusão que quase toda a gente tira dela: «se montei isto numa tarde, o sistema inteiro está a uma semana». Não está. O que montaste é a parte que se vê, e a parte que se vê é a barata.
É a mesma miragem de sempre, com roupa nova. Uma demo que funciona com dados limpos, um só utilizador e zero tráfego real não diz nada sobre o que acontece quando entram mil pessoas, metade dos dados vêm a meio e alguém tenta entrar onde não deve. A demo é uma promessa; a produção é a cobrança dessa promessa. E entre uma e outra está o trabalho de que ninguém fala na chamada de vendas, porque não luz num ecrã.
O que o vibe coding não gera (e é o que separa a demo do sistema)
Não é que a IA escreva código fraco. É que um sistema em produção é muito mais do que código, e essas outras camadas não saem de um prompt bonito. Estas são as que faltam quase sempre:
- Testes que avisam antes do cliente. O código gerado faz o que pediste no dia em que pediste. Ninguém garante que continue a fazê-lo quando mexeres noutra coisa daqui a três semanas. Sem uma rede de testes, cada alteração é uma aposta e quem descobre que partiste algo é o teu utilizador.
- Observabilidade: saber o que se passa quando se passa. Na demo, se algo falha, vês no teu ecrã. Em produção falha no telemóvel de um cliente a 800 km e não dás conta, a não ser que tenhas montado logs, métricas e alertas. Sem isso, a tua primeira fonte de monitorização é um email irritado.
- Segurança e isolamento de dados. O vibe coding monta-te o login; o que raramente te monta bem é que o utilizador A não possa, mexendo no URL, ver os dados do utilizador B. As permissões, o isolamento entre clientes e o tratamento de dados pessoais são precisamente onde uma app improvisada se torna uma fuga.
- Um responsável e um processo. Um sistema vivo precisa de quem o implante com critério, de quem decida o que se toca e o que não, e de quem esteja lá quando cai. Código sem responsável não é um sistema: é uma bomba-relógio que funciona até deixar de funcionar e ninguém sabe porquê.
Cada um destes pontos é invisível na demo e determinante em produção. E nenhum se resolve com um prompt melhor: constrói-se com ofício, que é precisamente o que o vibe coding te tenta a saltar porque «já funciona».
Então, o vibe coding não serve para nada? Pelo contrário
Serve, e muito, se o puseres no sítio certo. Como ferramenta de prototipagem é das melhores que chegaram em anos: valida uma ideia numa tarde em vez de duas semanas, deixa-te mostrar algo tangível numa reunião, e descarta o que não faz sentido antes de gastares um euro a construí-lo bem. O erro não é usar vibe coding; o erro é confundir o protótipo com o produto e mandar para produção o que nasceu para deitar fora.
| O vibe coding é ótimo para | E perigoso para |
|---|---|
| Validar uma ideia antes de investir | Guardar dados reais de clientes |
| Protótipos internos e demos | Qualquer coisa com utilizadores externos |
| Explorar como se sentiria uma função | Processos de que o negócio depende |
| Aprender e fazer provas rápidas | Nada que tenha de aguentar uma segunda de manhã |
A regra é simples: usa o vibe coding para decidir o que construir, não para o construir. O protótipo diz-te se a ideia vale a pena; a partir daí, o que aguenta em produção levanta-se com o aborrecido —o mesmo ofício que é preciso para automatizar um processo do negócio sem que se parta à primeira ou para pôr um agente de IA a trabalhar a sério dentro de uma empresa. Esse trabalho não é mais lento por capricho: é o que separa uma demo aplaudida de um sistema ainda de pé na terça-feira.
O que fazer com um protótipo que funciona
Se geraste algo «a vibrações» e resolve mesmo uma dor, a boa notícia é que já tens o mais difícil: a certeza de que a ideia vale. O que vem depois não é reescrevê-lo por gosto, é dar-lhe o que lhe falta para viver fora do teu ecrã —rede de testes, monitorização, segurança, implantação com critério e alguém que responde. É a parte que tratamos como o que é, infraestrutura, na infraestrutura de IA para empresa: pegar no que o protótipo valida e deixá-lo a funcionar sem depender de que alguém o vigie.
Por isso, sim ao vibe coding —para prototipar, para validar, para descartar depressa. E não ao vibe coding em produção, não porque a IA escreva mal, mas porque produção é o 70% que a IA não gera com o prompt: os testes, a observabilidade, a segurança e o responsável. A IA não se apresenta numa demo com dados de mentira. Implementa-se sobre o real, e o real exige o aborrecido. É esse o trabalho, e é precisamente a parte que não se vê.