Vibe coding é descrever em linguagem natural o que se quer e aceitar o que o modelo produz, sem o ler com atenção. Para um protótipo, um script ou uma ferramenta feita numa noite, é uma forma de trabalhar genuinamente boa. Eu próprio a uso assim.
Os problemas começam quando aquilo que fez em vibe coding entra em produção e passa a guardar dados de outras pessoas. Não porque o código seja mau — é muitas vezes limpo, idiomático e bem nomeado. O problema é aquilo que ninguém escreveu.
Um modelo responde à pergunta que lhe fez
Pede um formulário de marcação e recebe um formulário de marcação. Vai validar o email. Provavelmente ficará melhor do que aquele que eu escreveria à mão.
O que não fará é colocar-lhe as perguntas que decidem se aquilo sobrevive ao contacto com utilizadores reais. O que acontece se duas pessoas marcarem o último horário no mesmo segundo? Se o processador de pagamentos expirar depois de cobrar mas antes de o seu código o saber? Quem pode ver esta marcação: o cliente, qualquer utilizador autenticado, quem tiver o link? Quando o cliente pede a eliminação dos dados, o que mais tem de ser eliminado com eles e o que tem de ser conservado por lei?
Não são perguntas de programação. São decisões sobre o seu negócio, e o modelo não as pode tomar porque nunca lhe contaram os factos de que precisaria. Produz algo plausível para cada uma, em silêncio, e segue em frente. O código compila. O formulário funciona quando o testa. A decisão continua sem ter sido tomada por ninguém.
A demonstração funciona sempre
Esta é a armadilha concreta, e apanha também pessoas experientes.
Uma funcionalidade feita em vibe coding é testada como foi construída: uma pessoa, um navegador, um único caminho feliz, sem carga e sem adversário. Nessas condições passa quase tudo. As falhas vivem exactamente nas condições que não lhe ocorreu criar: concorrência, falha parcial, entrada hostil, o segundo cliente, a décima milésima linha, o utilizador que já não tem sessão mas cujo token ainda funciona.
Assim, o ciclo de retorno mente-lhe. Publica, funciona, publica outra vez mais depressa. A confiança cresce exactamente enquanto cresce a superfície não examinada. Nada o desmente até que algo o faça, publicamente.
Seis coisas que faltam sistematicamente
A autorização, por oposição à autenticação. Os modelos são bons no login. São bastante mais fracos em «este utilizador pode ler exactamente esta linha». A vulnerabilidade mais frequente do vibe coding, de longe, é um endpoint que verifica se está autenticado e nunca verifica quem é.
Tudo o que tem de estar certo em concorrência. Existências, reservas de lugares, números de factura, saldos. Código obviamente correcto lido de cima a baixo está frequentemente errado quando correm duas cópias ao mesmo tempo.
O modo de falha de cada chamada externa. Qualquer terceiro de que dependa estará indisponível a certa altura. Se isso deve parar o seu cliente é uma decisão de negócio. O código gerado toma-a por acidente, normalmente rebentando.
Dados que não pode perder. Migrações que eliminam colunas, eliminações sem soft delete, nenhuma cópia de segurança a partir da qual tenha efectivamente restaurado. Ninguém repara até ao dia em que conta, e nesse dia é irrecuperável, não incómodo.
O back office. O vibe coding produz os ecrãs que descreveu. Descreveu os virados para o cliente, porque são esses que imagina. Depois a sua equipa vive oito horas por dia no que sobrou.
A coerência entre funcionalidades. Cada sessão começa do zero. Dez funcionalidades construídas em dez sessões dão-lhe dez convenções, três formas de tratar datas, dois padrões de autenticação e nenhum vocabulário comum. Isoladamente, aceitáveis. Como sistema, impossível de manter — inclusive pelo modelo seguinte.
Quanto custa isto na realidade
O argumento a favor do vibe coding é a velocidade, e a velocidade é real. O que adia é o custo de compreender, e esse custo não desaparece: é pago mais tarde por quem tiver de alterar o sistema.
Alterar software com segurança exige alguém capaz de prever o que uma alteração vai partir. Essa pessoa constrói o seu modelo do sistema ao tomar as decisões. Se ninguém tomou as decisões, ninguém tem o modelo, e cada alteração seguinte é um palpite com um deploy em anexo.
Sou chamado a estes projectos com regularidade. O salvamento quase nunca é reescrever: o código costuma ser aproveitável. O que demora é reconstruir a intenção — ler cada caminho para deduzir o que o sistema devia fazer, porque ninguém mo consegue dizer, incluindo quem o publicou.
O que penso realmente
A IA é o maior ganho de produtividade que o meu ofício já viu e eu não trabalharia sem ela. É um instrumento excelente nas mãos de quem sabe ler o resultado criticamente e sabe que perguntas não foram feitas.
Não substitui essa pessoa. Torna-a mais rápida. O discernimento sobre o que o seu sistema nunca pode errar não é uma tarefa de programação, e é precisamente a parte que está a pagar.
Use-a para protótipos, scripts internos, coisas descartáveis, o primeiro rascunho de qualquer coisa. Para o sistema de que o seu negócio depende, tenha alguém que o compreenda de uma ponta à outra — quer o tenha escrito, quer o tenha revisto linha a linha.