"Vibe coding" virou quase um xingamento em comitê técnico. O termo que Andrej Karpathy cunhou no começo de 2025 pra descrever programar "no feeling" — e que, na versão sem freio, vira deixar a IA gerar, aceitar sem ler e seguir em frente — hoje aparece no board como sinônimo de gambiarra que não sustenta. E aí acontece o erro caro: o decisor ouve "vibe coding não aguenta produção", concorda, e joga fora, no mesmo movimento, o ganho de velocidade que a IA trouxe pra engenharia. Como se a única forma de usar IA pra escrever código fosse a versão sem freio.
O problema nunca foi usar IA pra codar. É não saber usar: mandar pra produção o que ela gera sem método, sem especificação, sem revisão humana, sem auditoria e sem ninguém encarregado do suporte e da sustentação no Dia 2. Isso não é "vibe coding demais" — é ausência de governança. E governança, ao contrário do que o estigma sugere, não anula velocidade: é justamente o que permite colher a velocidade da IA sem herdar o passivo. Este texto separa o estigma do problema real e mostra a que régua o decisor deveria estar prestando atenção.
Principais pontos
- Vibe coding é uma faixa, não um veredito. Programar no feeling é ótimo pra explorar e prototipar — o erro é confundir a faixa de exploração com a de produção e tratar as duas com o mesmo rigor (ou a mesma ausência dele).
- Existe um espectro de maturidade no desenvolvimento com IA. Do protótipo gerado no feeling até a especificação versionada como fonte de verdade, há degraus intermediários. Amadurecer é subir a régua conforme o software exige, não trocar de ferramenta.
- O muro dos três meses é onde o protótipo puro quebra. Enquanto é código isolado, o vibe coding voa. Quando vira sistema integrado, multiusuário e regulado, a mesma velocidade que ajudou passa a esconder dívida.
- Governança é camada, não etapa final. Contexto estruturado, limites definidos, aprovação humana em pontos críticos, auditoria e observabilidade não são "fase 2" — são o que transforma geração assistida em software operável.
- O passivo mora no Dia 2. Quem não define, antes de assinar, quem sustenta o que a IA gerou, herda o custo quando o sistema cai numa sexta à noite.
Pra quem decide, a pergunta parou de ser "usamos IA pra codar ou não". Essa discussão acabou — muitos times já usam, mesmo que de maneira informal e sem admitir no comitê. A pergunta que importa é outra: o que exigir pra que o código gerado por IA aguente operação real, integração com o legado e a régua regulatória do seu setor. É nesse ponto que entra um parceiro que constrói os próprios produtos com esse rigor — como a Vertis Tech, que opera agentes de IA com aprovação humana em pontos críticos e auditoria append-only dentro dos seus próprios sistemas internos, antes de propor qualquer coisa parecida a um cliente.
O espectro de maturidade do desenvolvimento com IA
O debate público costuma ser binário: vibe coding contra "engenharia de verdade". Na prática, existe um espectro, e cada projeto vive em algum ponto dele — às vezes em pontos diferentes ao mesmo tempo, dependendo do módulo. Enxergar esse espectro é o que evita transformar uma prática útil numa proibição genérica.
Faixa 1 — geração no feeling
É o vibe coding em estado puro. O desenvolvedor (ou o próprio dono do negócio) descreve o que quer, a IA gera, ele aceita sem inspecionar a fundo e itera pela reação — "não é isso, tenta de novo". Não há especificação escrita, o contexto do sistema que a IA recebe é mínimo, e o critério de pronto é "parece funcionar na tela".
Essa faixa é legítima e poderosa pra uma coisa: reduzir o custo de descobrir. Protótipo pra validar hipótese, prova de conceito pra mostrar ao sócio, script interno que roda uma vez. Aqui, exigir especificação versionada seria burocracia que mata a velocidade sem entregar valor. O problema não é usar a faixa 1 — é ela vazar pra produção sem ninguém decidir que vazou.
Faixa 2 — geração assistida com revisão
Um degrau acima, a IA continua gerando a maior parte do código, mas entra revisão humana estruturada. Alguém com senioridade lê o que a IA produziu, procurando o que a máquina não vê: decisão de arquitetura ruim, falha de segurança sutil, acoplamento que vai cobrar caro depois. O prompt já carrega contexto — padrões do projeto, convenções, restrições —, mas a fonte de verdade ainda é frágil, muitas vezes na cabeça de quem revisa.
Essa é a faixa onde vive boa parte dos times que já usam IA com algum cuidado hoje. Funciona bem enquanto o revisor tem contexto e tempo. Degrada rápido quando o volume de código gerado ultrapassa a capacidade humana de revisar com atenção — momento em que a revisão vira carimbo e a dívida volta a se acumular em silêncio.
Faixa 3 — especificação versionada como fonte de verdade
No topo do espectro, a especificação sai da cabeça e vira artefato versionado, do qual implementação, teste e documentação são derivados. É o que o mercado chama de spec-driven development. A IA não recebe um prompt maior; recebe requisito estruturado, limites explícitos e critério de aceite verificável. O código gerado passa a ser consequência de um contrato, não de uma conversa.
Não é coincidência que, depois da explosão do vibe coding, o mercado tenha passado a falar em engenharia agêntica: orquestrar agentes de IA contra especificações detalhadas, com supervisão humana. A indústria não está abandonando a IA na engenharia; está subindo a régua de como a usa. Vale um alerta honesto: a faixa 3 tem custo. Escrever e manter especificação exige disciplina, e aplicá-la a um protótipo descartável é desperdício. O ponto não é estar sempre no topo — é saber em que faixa cada parte do sistema precisa estar.
O muro dos três meses
Existe um momento previsível em que o vibe coding puro deixa de ser atalho e vira armadilha. Costuma aparecer algumas semanas ou meses depois do primeiro sucesso — daí a imagem do "muro dos três meses". Não é uma data exata; é uma transição de natureza. Vale enxergá-la como referência qualitativa, não como cronômetro.
No começo, o protótipo gerado no feeling é código relativamente isolado. Um usuário, um fluxo, poucos dados, nenhuma integração séria. Nesse território, a velocidade da IA é quase pura vantagem: o que levava dias sai em horas, e o custo de errar é baixo porque quase nada depende daquilo ainda.
O muro aparece quando o mesmo código precisa virar sistema. Passa a ter vários usuários simultâneos, precisa conversar com o ERP legado, guardar dado pessoal sob a LGPD, sobreviver a picos, e continuar funcionando quando quem o gerou já esqueceu por que aquela função existe. A mesma ausência de estrutura que dava velocidade agora esconde dívida: ninguém sabe ao certo o que o sistema faz, não há teste que trave uma regressão, e cada mudança gerada no feeling tem chance real de quebrar algo distante em silêncio.
O sintoma clássico é o time desacelerar bruscamente depois de ter voado. A cada nova funcionalidade, mais tempo é gasto entendendo e consertando o que já existe do que construindo o novo. Não é que a IA "parou de funcionar" — é que o sistema cruzou a fronteira onde faixa 1 não basta, e ninguém subiu a régua a tempo. É aqui que nasce o custo de negócio que a percepção genérica de que "vibe coding não sustenta" tenta capturar. Só que a lição correta não é abandonar a IA. É reconhecer o muro antes de bater nele e planejar a graduação de maturidade como parte do projeto, não como resgate emergencial.
As camadas que transformam geração em software operável
Se o problema não é a IA gerar código, e sim gerar sem freio, então a solução é um conjunto de camadas de governança aplicadas ao processo de desenvolvimento — não à ferramenta. Elas não desaceleram o time competente; canalizam a velocidade pra um resultado que aguenta operação.
Contexto estruturado. A IA gera na qualidade do contexto que recebe. Convenções do projeto, arquitetura, restrições de domínio e exemplos do que é código bom ali dentro precisam estar disponíveis de forma consistente — não improvisados a cada prompt. Contexto pobre produz código plausível e errado, que é o pior tipo, porque passa na primeira olhada.
Limites definidos. O agente precisa saber o que pode e o que não pode tocar. Quais partes do sistema são fronteira, que operações exigem cuidado especial, onde alterar estado é irreversível. Sem limite explícito, a geração assistida é rápida e imprudente na mesma medida.
Aprovação humana em pontos críticos. Nem toda ação gerada por IA merece o mesmo nível de confiança. Mudança cosmética pode fluir; alteração que mexe em dado sensível, dinheiro ou infraestrutura de produção deveria exigir um humano no circuito antes de efetivar. O desenho de onde fica esse portão é decisão de risco, não detalhe técnico.
Auditoria. Todo software sério precisa responder "quem fez o quê, quando e por quê". Quando parte das mudanças é gerada por IA, isso deixa de ser opcional: sem registro imutável do que foi gerado, aprovado e aplicado, não há como investigar um incidente nem provar conformidade a um regulador. Auditoria append-only — em que registros são acrescentados, nunca sobrescritos — é o padrão que sustenta essa rastreabilidade.
Observabilidade. Sistema em produção precisa dizer quando está mal antes do cliente perceber. Métricas, logs e alertas que revelem falha silenciosa são o que separa "caiu na sexta e ninguém viu até segunda" de "o time foi avisado no minuto seguinte". Código gerado rápido sem observabilidade é uma caixa-preta que só fala quando já é tarde.
Repare que nenhuma dessas camadas é sobre proibir IA. Todas são sobre dar a ela um lugar governado pra operar. É a diferença entre a demo que impressiona e o sistema que sustenta. É governança aplicada na origem do desenvolvimento: em como o código nasce, é revisado e é promovido, não só no que roda depois.
Como a Vertis Tech ajuda em desenvolvimento com IA governado
A Vertis Tech desenvolve software sob medida com foco em CRM, automação e IA aplicada — e usa IA na própria engenharia, com a governança que defende. Cada projeto é dimensionado conforme a maturidade do código já existente, o grau de regulação do domínio, a criticidade do que a IA vai gerar e a necessidade de sustentação no Dia 2. A depender do escopo, a implantação pode contemplar:
- Discovery técnico que define a faixa de maturidade certa por módulo, pra não aplicar rigor de produção a protótipo descartável nem tratar sistema crítico com liberdade de rascunho.
- Especificação como artefato versionado quando o software precisa durar anos, servindo de fonte de verdade que tanto o time quanto os agentes de IA seguem.
- Aprovação humana desenhada nos pontos críticos, com portões onde ação sensível — dado pessoal, dinheiro, infraestrutura — passa por revisão antes de efetivar. É como a própria Vertis Tech opera seus agentes internos com Claude Code SDK e auditoria append-only.
- Observabilidade e sustentação como parte do escopo, com métricas, alertas e resposta a incidente pensados desde o desenho, não vendidos como extra depois que o sistema já caiu.
- Integração com o legado sem reescrever o que funciona, tratando a fronteira com o ERP ou sistema antigo como decisão de risco antes de escolher o padrão técnico.
Os itens acima são dimensões de desenho, não promessas universais de entrega — o que entra em cada projeto depende do que ele realmente exige.
Perguntas frequentes
Vibe coding serve pra alguma coisa ou é só um problema?
Serve, e muito, na faixa certa. Pra prototipar, validar hipótese e explorar, programar no feeling reduz drasticamente o custo de descobrir. O problema aparece quando esse mesmo código vaza pra produção sem ninguém decidir que a faixa mudou. A questão não é banir a prática — é não confundir a faixa de exploração com a de operação.
Usar spec-driven development significa perder a velocidade da IA?
Não necessariamente. A especificação bem-feita costuma dar à IA contexto melhor do que um prompt improvisado, o que tende a reduzir retrabalho. O custo real está na disciplina de manter a spec — que compensa em software feito pra durar e é desperdício em protótipo descartável. Por isso a decisão é por módulo, não uma regra única pro projeto inteiro.
Como sei se meu sistema já bateu no muro dos três meses?
O sinal mais confiável é o time desacelerar depois de ter voado: cada funcionalidade nova exige cada vez mais tempo entendendo e consertando o que já existe. Somam-se a isso bugs que aparecem em partes distantes da mudança feita, medo de mexer em certos trechos, e ausência de teste que trave uma regressão. Quando esses sinais se acumulam, a graduação de maturidade deixou de ser opcional.
Dá pra herdar um sistema feito no feeling e colocar governança depois?
Dá, e é um pedido comum. O caminho costuma começar por observabilidade e auditoria — enxergar o que o sistema faz e registrar mudanças — antes de reorganizar o código em si. Não é reescrever tudo do zero; é estabilizar, mapear o que existe e subir a régua nas partes críticas primeiro, com um plano em vez de um mutirão de emergência.
Vibe coding não é o inimigo, e nem é a solução completa. É uma faixa num espectro de maturidade que todo desenvolvimento assistido por IA percorre. A empresa que entende isso para de escolher entre "velocidade da IA" e "software que aguenta produção" como se fossem opostos — e passa a exigir a governança que permite ter os dois. O decisor que sai desta leitura sabe o que perguntar antes de aprovar o próximo projeto: em que faixa cada parte precisa estar, onde fica o muro, e quem cuida depois.
