Vibecoding em produção é onde a conta chega — e quase ninguém tá olhando

Karpathy cunhou o termo vibecoding em fevereiro de 2025: "você se entrega aos vibes, abraça os exponenciais, e esquece que o código existe". Você descreve o que quer, o LLM cospe, você cola, roda, ajusta o prompt, repete. É viciante. Eu uso. Você usa. Todo mundo que entrega software hoje usa, mesmo que finja que não.

E aqui tá a parte que ninguém quer falar: vibecoding é maravilhoso pra protótipo. Em produção, é onde a conta chega.

Esse post é sobre o que muda entre os dois mundos — e por que produção precisa de um profissional que sabe ler código gerado por IA com a desconfiança certa.

A parte boa: vibecoding é o melhor que aconteceu pra prototipação

Antes de criticar, deixa eu ser justo. Eu construí o OverAir (SaaS de memória digital via WhatsApp) e o Studio Kallos (agendamento pra estúdios de beleza) sozinho. Sem cofundador técnico. Sem time. Se eu não usasse vibecoding, esses produtos não existiriam — ou existiriam pela metade.

Onde vibecoding ganha de lavada:

• Validação de hipótese. Você quer saber se "tirar foto da conta e a IA extrair valor + vencimento" funciona? Em 2 horas você tem um MVP rodando, manda pra 5 amigos, descobre que os 5 mandam de manhã e ninguém manda depois das 22h. Insight de produto sem ter escrito teste, sem ter feito CI, sem nada.
• Exploração de stack. Quero saber como o Stripe lida com webhooks de assinatura? Em 30 minutos eu tenho 4 versões, escolho a que parece mais clara, e ganho um modelo mental que o tutorial oficial ia me dar em 3 horas.
• Throwaway scripts. Migrar 200 documentos de uma coleção Firestore pra outra, com transformação no meio? Vibecoding mata em 10 minutos. Não preciso pensar em arquitetura — é descartável.

Nesses três casos, o "código existe" no sentido de Karpathy: pouco importa se está bonito, modular, ou se tem teste. Importa se rodou e provou ou desprovou a hipótese.

Onde a peça começa a quebrar: produção

Produção é outro animal. Em produção, o código fica vivo por anos. Outras pessoas leem. Usuários reais dependem. Dados sensíveis transitam. Falhas custam dinheiro e confiança. E a IA — que é ótima pra "fazer rodar" — é péssima pra "fazer rodar com segurança no tempo".

Vou destrinchar três classes de problema que a IA gera silenciosamente, com exemplos que vi (e cometi) nos meus próprios produtos.

1. Segurança que o LLM escreve confiante e errado

Esse é o pior, porque o código parece correto, passa nos testes que ele mesmo gera, e roda em dev. Aí vai pra produção e alguém competente lê e congela.

Padrão 1: validação client-side com regras server-side faltando.

Pede pro LLM um sistema de agendamento de horários. Ele entrega: tela bonita, lógica de "não permitir agendar fora do horário comercial" no front, e regra do Firestore que basicamente diz request.auth != null. Pronto, "funciona". Em produção, qualquer pessoa autenticada consegue criar agendamento às 3h da manhã via SDK direto, bypassando o front. Cliente real do Kallos pegou isso em duas semanas — não por má fé, foi um app de cliente que estava com cache antigo e gravou em horário inválido.

A IA escreveu duas validações: a do front, que ela viu; e a do back, que ela "achou que tava no front então só protege auth". Sem alguém pra cruzar essas duas, a regra de negócio mora no lugar errado.

Padrão 2: segredos no client.

Pede um SDK que conversa com uma API paga. O LLM, querendo te entregar algo que "roda", coloca a chave em um arquivo config.dart ou em uma env var que o app empacota. Vai pro Play Store. Em uma semana alguém extrai. Eu já achei chaves de OpenAI e Stripe em APKs públicos descompilando em 5 minutos — não eram minhas, mas eu vi.

A IA sabe que é errado se você perguntar. Mas se você não perguntar, ela entrega o caminho mais curto.

Padrão 3: SQL injection / NoSQL injection em camada que ela jurou que era safe.

Em SQL, os LLMs já melhoraram — quase sempre usam parametrização. Em NoSQL (Firestore, Mongo), o cenário é pior: ela monta queries com strings concatenadas em campos que vieram do usuário ("filtre os agendamentos onde o clientName contém ${input}") e em alguns Firestore SDKs isso permite escalar acesso pra documentos que não eram pra estarem na resposta.

Esse tipo de bug passa por code review automático. Não dá warning. Só vaza dado.

2. Lógica que parece pronta mas não tem o que a produção exige

A IA escreve o "happy path" lindo. O resto, ela ignora ou inventa.

Idempotência. Webhook do Stripe entrega o mesmo evento duas vezes em ~0.5% dos casos (a documentação diz isso explicitamente). Se o seu handler vibecodado faz INSERT da assinatura e cobra de novo, o cliente é cobrado em dobro. O LLM não escreve a deduplicação por event.id a não ser que você peça. E o cliente que toma duplo-débito não te avisa, ele só pede chargeback.

Eu peguei isso no OverAir antes de produção — porque desconfio dessa classe de bug por experiência. Quem está vibecodando sem essa cicatriz não pega.

Race conditions. Agendamento de horário com múltiplos clientes tentando o mesmo slot ao mesmo tempo. A IA escreve if (slotLivre) { reservar() }. Em produção, dois requests passam no if no mesmo milissegundo. Dois reservam. Cliente chega e descobre que está overbooked. Solução é transação atômica ou compare-and-swap — a IA sabe, mas não escreve sem prompt explícito.

Retry com exponential backoff e jitter. A IA escreve for (let i = 0; i < 3; i++) { await call(); }. Em produção sob carga, isso vira thundering herd: 1000 clientes falham juntos, 1000 retentam juntos no segundo seguinte, derrubam o servidor. A diferença entre o retry vibecodado e o retry correto não aparece em dev — só aparece quando algo dá errado em escala.

3. Arquitetura que apodrece

Esse é o mais sutil e o mais caro no longo prazo. A IA é boa em escrever uma função. Ela é péssima em manter consistência arquitetural num codebase que cresce.

Sintomas reais que peguei nos meus repos:

• A mesma lógica de "formatar telefone brasileiro" reescrita em 5 arquivos com 5 implementações ligeiramente diferentes (uma trata DDD com zero, outra sem; uma aceita +55, outra não).
• Componente de "card de agendamento" duplicado em 3 lugares porque cada vez que eu pedi "crie a tela X" a IA gerou um do zero ao invés de reusar.
• Camadas misturadas: lógica de Firestore vazando em widget Flutter, regra de negócio dentro de função de UI. A IA não tem um modelo de "onde mora o quê" — ela põe onde for mais rápido escrever.

Em 6 meses, o repo fica com três jeitos de fazer cada coisa. Refatorar custa caro. Bug fix em uma versão não corrige nas outras duas. Onboarding de um novo dev (humano ou agente) demora o triplo porque ele não sabe qual é o jeito canônico.

Isso não é problema do LLM ser ruim. É problema de ninguém estar exercendo o papel de arquiteto.

O ponto cego dos testes

Vibecoding gera teste. Esse é o detalhe traiçoeiro. A IA escreve expect(result).toBe(expected) e dá ✅ verde no terminal, e você sente que está "fazendo certo".

Mas os testes que ela gera, na esmagadora maioria, são:

• Só do caminho feliz. Input válido, retorno válido, fim.
• Testando a implementação, não o comportamento. "Verifica que formatPhone chama replace duas vezes" — quebra a cada refactor, não pega nenhum bug real.
• Mockando o mundo todo. Tudo virou stub. O teste passa em isolamento perfeito. Em produção, o cliente real do Firestore tem rate limit e a query falha — coisa que o mock nunca exercitou.

Em times reais, isso vira falsa confiança. "Tem 87% de cobertura, está testado." Não está. Está parecido com testado. É outra coisa.

Por que produção exige um profissional especializado

Aqui é onde quero ser franco. Existe uma narrativa popular de que "com IA, qualquer um vira dev". Essa narrativa é parcialmente verdadeira pra protótipo e completamente falsa pra produção.

O que muda em produção é que você precisa de alguém que:

Sabe o que perguntar ao agente. Você não pede "crie um endpoint pra criar assinatura". Você pede "crie um endpoint pra criar assinatura idempotente por idempotency_key, com validação Zod no payload, lockando a row do customer pra prevenir corrida, log estruturado sem PII, e retornando o erro semanticamente correto se já existir". A diferença entre os dois prompts é literalmente a diferença entre dev e produção.

Lê o código com desconfiança certa. Não desconfiança paranoica que rejeita tudo. Desconfiança específica: "essa função autentica? Onde valida ownership? O que acontece se o input vier malformado?". Isso requer modelo mental de como esses bugs aparecem — modelo que se constrói com cicatriz, não com curso.

Sabe onde inserir o humano no loop. Algumas decisões não podem ser delegadas ao agente: schema de banco em produção, modelo de permissão, contrato de API público, qualquer coisa que envolve dinheiro real. Não porque o agente erra — porque o custo de errar nessas decisões é assimétrico. O profissional sabe quais são.

Arquiteta pra que erros do agente sejam contidos. Modularidade, boundaries, testes de contrato, feature flags. Tudo isso é "estilo antigo de engenharia" — e é o que faz vibecoding seguro escalar. O profissional configura o tabuleiro pra que mesmo as peças jogadas pelo agente caiam em casas válidas.

Mantém memória do "porquê". Por que escolhemos Firestore e não Postgres? Por que esse webhook não pode ser retry-safe? Por que esse campo é nullable? O agente não tem essa memória entre sessões. O profissional tem — e escreve em ADR, CLAUDE.md, comentário no lugar certo.

Como isso muda na prática

Times que entendem isso reorganizam o workflow assim:

• Protótipo: vibecoding solto, repo descartável, foco em validar hipótese. O agente roda 80% do código.
• Produção: o mesmo profissional (ou time) que prototipou agora vira revisor de IA. O agente continua escrevendo, mas a pessoa lê linha a linha em PR, com mente aguçada pros padrões acima. Tests críticos são escritos à mão. Security review é manual. Arquitetura é decidida fora do agente.
• Manutenção: o agente faz refactor sob supervisão. Lê o ADR antes. Escreve teste de contrato antes. A pessoa aprova a forma da solução antes do agente escrever a implementação.

Esse é o trabalho de quem é especialista em desenvolvimento com IA. Não é "saber digitar prompt". É saber onde a IA mente, onde ela acerta, onde ela precisa de guard rail, e como construir o sistema pra que o resultado seja produção-pronto e não protótipo polido.

Fechando

Vibecoding não vai sumir. Vai ficar mais poderoso. E essa é exatamente a razão pela qual o profissional que sabe a diferença entre rodou em dev e roda em produção vale mais, não menos.

Se você está prototipando: vibecode à vontade. Mostra pro mundo. Valida a hipótese.

Se você está pondo dinheiro de cliente real, dado pessoal real, ou serviço crítico em produção — chama alguém que sabe o que a IA tá escondendo. Esse alguém eventualmente vai ser caro. Mas sempre vai ser mais barato do que descobrir os bugs depois.

Eu construí dois SaaS sozinho com IA. E justamente por isso, sei dos bugs que estão lá dentro. Posso olhar pro OverAir hoje e te apontar três coisas que precisam de hardening antes de eu escalar pra 10k usuários. Vibecoding me trouxe até aqui rápido. Engenharia de verdade é o que me leva daqui pra frente.

Se você tá nesse momento — protótipo validado, precisa de produção que não te queime — me chama. É exatamente o trabalho que faço.