Vibe coding é legítimo em exatamente um contexto: quando você está construindo um protótipo que pretende descartar.
O problema é que a maioria dos sistemas construídos com vibe coding não são descartados. Eles rodam. Acumulam usuários. Tornam-se o sistema que deve ser mantido, estendido e depurado por pessoas que não o escreveram e não podem pedir à IA para explicar suas decisões em contexto. A codebase não sabe que deveria ser temporária.
Isso não é uma crítica ao uso de IA para gerar código rapidamente. É uma descrição do que acontece quando você aplica uma estratégia de protótipo a um ambiente de produção.
O Que Vibe Coding Realmente É
Vibe coding é gerar código descrevendo intenção, aceitando o que parece certo, iterando até algo funcionar, sem ler cada linha ou entender cada decisão. O loop de feedback é: funciona, parece certo, a funcionalidade funciona no happy path. Quando a resposta é sim, o código é enviado.
Essa abordagem é genuinamente útil para propósitos específicos. Uma prova de conceito para alinhamento com stakeholders. Um spike de design para testar se uma API é utilizável antes de comprometer com integração. Uma exploração descartável de um framework que você nunca tocou. Gerando boilerplate que será revisado linha por linha antes de qualquer parte chegar à produção.
Em todos esses casos, o artefato é uma ferramenta de comunicação ou um dispositivo de aprendizagem, não um sistema de produção. A condição de saída é “isso é bom o suficiente para ter a conversa,” não “isso está pronto para usuários.”
Quando sistemas construídos com vibe coding entram em produção sem essa distinção ser feita explicitamente, carregam dívida que compõe. As decisões que nunca foram tomadas conscientemente se tornam restrições que o próximo engenheiro herda. Os casos extremos que nunca foram considerados se tornam os bugs que aparecem às 2 da manhã.
O Problema da Borda Irregular em Escala
Agentes de codificação com IA não são uniformemente capazes. Excelentes em padrões bem trilhados: endpoints CRUD, componentes de UI, transformação de dados, configuração de boilerplate. Falham de forma imprevisível em decisões de arquitetura novas, gerenciamento de estado entre sistemas, casos extremos de segurança, características de desempenho em escala e correção específica de domínio.
Essa irregularidade é a borda irregular. A confiança do agente é uniforme mesmo quando sua confiabilidade não é. Escreve código adjacente à segurança com o mesmo tom que usa para escrever uma função utilitária. Lida com um padrão de concorrência novo com a mesma certeza aparente que traz para escrever um for-loop.
Vibe coding amplifica a borda irregular em escala. Um sistema cresce nas direções que o agente lida bem, que são também as direções que parecem suaves e rápidas, até atingir um limite que o agente não consegue navegar. Nesse ponto, o limite está incorporado em produção, cercado de código que construiu sobre as suposições confiantes mas incorretas do agente.
A borda irregular não é motivo para evitar ferramentas de codificação com IA. É motivo para manter supervisão humana nos pontos específicos onde a confiabilidade do agente cai: decisões de segurança, caminhos críticos de desempenho, lógica de domínio nova, estado entre sistemas.
O Paradigma Agêntico e Sua Disciplina
Software tem sido descrito em termos de paradigmas de programação sucessivos. O primeiro: instruções explícitas escritas por humanos para execução determinística. O segundo, descrito por Karpathy como Software 2.0: comportamento compilado em pesos de rede neural a partir de dados e objetivos, onde o programa está nos pesos, não em código escrito por humanos.
O terceiro, o que tem sido chamado de paradigma agêntico, estende isso ainda mais: sistemas onde o programa está cada vez mais no prompt, no contexto e nas ferramentas, com um modelo de linguagem como runtime. A codebase ainda é código, mas o comportamento do sistema é moldado por contexto tanto quanto por instruções.
Vibe coding é esse paradigma sem disciplina. O prompt substitui a especificação. O LLM substitui o arquiteto. O feeling de “funciona” substitui a suite de testes.
Engenharia agêntica aplica disciplina ao mesmo paradigma: spec explícito antes da geração, critérios de aceitação verificáveis, cobertura de testes de propriedade dos humanos não delegada ao julgamento do agente, observabilidade antes do go-live, gates de revisão humana em pontos de decisão arquitetural.
A disciplina não desacelera o paradigma. É o que torna o paradigma confiável em escala de produção.
O Que a Engenharia Agêntica Adiciona
Engenharia agêntica não é vibe coding mais rápido. É a mesma geração de código assistida por IA com os elementos que o vibe coding pula aplicados deliberadamente.
Definição de escopo: o que o agente construirá, o que não construirá, quais arquivos tocará e não tocará. Esse limite previne o espalhamento que torna sistemas com vibe coding impossíveis de manter.
Superfície de suposições: o agente declara sua interpretação antes de implementá-la. Um esclarecimento de trinta segundos antes do primeiro bloco de código previne duas horas de retrabalho depois.
Isolamento em worktree: o agente trabalha em uma branch, não na main. O diff é visível e revisável antes de qualquer humano aceitá-lo.
Disciplina test-first: o teste de aceitação é definido antes de a implementação começar. O teste é o contrato entre o que foi solicitado e o que foi entregue.
Revisão adversarial antes do merge: uma segunda passagem, antes de a mudança chegar à produção, sobre o que pode dar errado. Não um gate burocrático. Uma busca estruturada pelo modo de falha que ninguém pensou na fase de planejamento.
Observabilidade desde o dia um: logs e alertas são instrumentados antes de a funcionalidade ir ao vivo, não adicionados quando o primeiro relatório de bug chega.
Plano de rollback: antes do deploy, há uma resposta explícita para “o que fazemos se isso falhar em produção?”
Equipes praticando engenharia agêntica entregam mais rápido do que praticantes de vibe coding no mês dois, três e além. Não porque engenharia agêntica produz mais código por hora. Porque produz menos retrabalho por mês.
Quando Vibe Coding É a Ferramenta Certa
Os usos legítimos são reais e valem nomear.
Spike de design: você precisa saber se uma abordagem técnica é viável antes de investir nela. Construa um protótipo com vibe coding, observe o resultado, descarte ou extraia os aprendizados.
Demo descartável: você precisa mostrar a um stakeholder como uma funcionalidade poderia ser. A demo não é o produto.
Exploração de aprendizado: você está se familiarizando com uma API, um framework ou um domínio no qual nunca trabalhou. O output é conhecimento, não software de produção.
Scaffolding de boilerplate: o código gerado será revisado linha por linha antes de qualquer parte tocar produção.
A condição de saída para código com vibe coding entrar em produção é explícita: revisão de arquitetura para confirmar que corresponde às convenções do sistema, verificação de segurança para pontos de injeção ou credenciais expostas ou gaps de autenticação, cobertura de testes de uma suite escrita por humanos que valida o comportamento, observabilidade para confirmar que o que o código faz em produção é visível.
Uma heurística prática: se você não consegue descrever a um colega o que uma função com vibe coding faz e por que funciona da forma que funciona, ela não está pronta para produção. A incapacidade de explicá-la não é um sinal de que o código é muito complexo. É um sinal de que decisões foram tomadas sem ser entendidas.
O Ganho Real de Produtividade Está na Qualidade da Especificação
As equipes que vencem com codificação assistida por IA não são as que escrevem menos código. São as que escrevem as melhores especificações.
Ferramentas de codificação com IA comprimem o gap entre especificação e código rodando. Não eliminam o requisito de uma boa especificação. Uma tarefa bem especificada, entregue a um agente operando com guardrails, produz código pronto para produção rapidamente. Uma tarefa mal especificada, entregue ao mesmo agente, produz código confiante que precisa ser reescrito.
A especificação inclui o que o componente faz, o que não faz, quais inputs lida, quais modos de falha existem e como o sucesso é medido. Não é overhead de documentação. É a informação que o agente precisa para produzir output correto na primeira vez em vez da terceira.
Equipes investindo em qualidade de especificação obtêm retornos compostos de codificação com IA. Equipes fazendo vibe coding obtêm dívida composta. Ambos parecem produtividade no mês um. No mês seis, a diferença é visível no cycle time entre requisito e produção, no tamanho do backlog que é na verdade retrabalho, e na confiança dos engenheiros que trabalham na codebase.
A mudança no papel do engenheiro é real: de digitador a especificador, revisor e especialista de domínio que sabe quando sobrepor o agente. Os engenheiros que fazem essa mudança são mais rápidos. Os que tratam codificação com IA como digitação mais rápida estão trabalhando mais para ficar no lugar.
A questão não é se usar IA para gerar código. É se a especificação existe, os testes são de propriedade dos humanos e o checklist de produção roda antes do deploy.
Relacionados: Claude Code Não É um Copiloto. É um Sistema de Entrega. e Os Quatro Guardrails que Separam Codificação com IA de Entrega com IA