É 2h da manhã. Seu telefone vibra com aquele padrão específico que você configurou para alertas de produção. Em uma década de plantão, você aprendeu que nada de bom acontece às 2 da manhã. A mensagem de alerta confirma seus medos: tráfego de rede incomum, endereços IP suspeitos. O novo código de processamento de pagamentos gerado por IA — implantado apenas horas antes — está falhando espetacularmente.

Esta é a história real (embora fictícia) documentada no artigo “No Vibe Coding While I’m On Call”, que expõe os perigos de uma tendência que está varrendo a indústria de tecnologia: vibe coding.

O Que É Vibe Coding?

“Vibe coding” é o termo cunhado por Andrej Karpathy para descrever a prática de construir software conversando com IA em vez de escrever cada linha você mesmo. Você descreve o “vibe” (a vibe, a sensação) do que quer, e a IA cuida dos detalhes.

Ferramentas como Cursor, GitHub Copilot, Windsurf, Claude e ChatGPT prometem democratizar o desenvolvimento de software. E sim, elas funcionam — até certo ponto. Pessoas que nunca se imaginaram como desenvolvedores estão enviando produtos reais. Ideias que teriam morrido na gaveta do “algum dia vou aprender a programar” estão realmente vendo a luz do dia.

Mas aqui está a verdade desconfortável: vibe coding é simultaneamente a prática de desenvolvimento mais empolgante e mais perigosa a surgir nos últimos anos.

Quando a Mágica Acaba: O Muro dos 3 Meses

Conforme documentado no artigo da Red Hat “The Uncomfortable Truth About Vibe Coding”, vibe coding funciona perfeitamente… até não funcionar mais.

Você está três meses no seu projeto. Você conversou com seu assistente de IA, adicionou funcionalidades, corrigiu bugs, fez ajustes. Tudo parecia tranquilo até que de repente não estava mais.

“Você muda uma coisinha e quatro outras funcionalidades quebram. Você pede para a IA consertar aquelas, e agora algo mais está agindo de forma estranha. Você está jogando whack-a-mole com seu próprio código.”

Isso não é a IA sendo burra. É a consequência natural de construir sem especificações. Quando você faz vibe coding, suas instruções se tornam obsoletas no momento em que o código é gerado. O código em si se torna a única fonte de verdade — e código é terrível para explicar por que faz o que faz.

Quatro Padrões de Falha Que Você Precisa Reconhecer

Baseado em casos reais documentados que todo desenvolvedor já deve ter visto.

Quando “Código Limpo” Quebra Funcionalidades Críticas

Imagine receber um alerta de produção porque alguém pediu para a IA “limpar o código” e melhorar a qualidade. Parece impossível, mas acontece com frequência assustadora.

O problema típico: desenvolvedores pedem para IA modernizar código legado, aplicar padrões de lint ou “refatorar sem alterar funcionalidade”. A IA obedece entusiasticamente, transformando 103 arquivos em código mais elegante. Testes passam. Code review aprova. Deploy acontece.

Então o sistema de pagamentos para de funcionar.

O que a IA fez foi otimizar localmente sem entender o contexto global. Aquela variável que parecia ser constante? Na verdade era reatribuída em caminhos de execução específicos — casos extremos que os testes não cobriam, mas que clientes reais acionavam regularmente. A IA priorizou elegância sobre correção, porque ninguém especificou por que o código tinha aquela estrutura “feia”.

A lição dolorosa: IA otimiza para o que você pede, não para o que você precisa. “Melhorar código” sem contexto operacional é uma receita para desastre. E o mais irônico? Quando você pede para a mesma IA analisar as mudanças que ela fez, ela imediatamente identifica os riscos. O conhecimento estava lá — só não foi consultado no momento certo.

A Armadilha das ‘green flags’

Existe uma métrica enganosa que seduz times inteiros: cobertura de teste. Sobe de 60% para 95% em uma sprint. Gestor feliz, time orgulhoso, IA celebrada como heroína.

Até o deploy de sexta-feira explodir tudo aos sábado de manhã.

O problema não é quantidade de testes, mas sim qualidade. IA gerando testes é como um aluno criando questões de prova para si mesmo: ela verifica se o código faz o que faz, não se faz o que deveria fazer. Os assertions estão tecnicamente corretos, mas testam a implementação atual, incluindo seus bugs.

Um exemplo concreto: sistema de recomendação que deveria priorizar produtos em estoque. A IA gera testes que verificam se a função retorna produtos. Qualquer produto. Testes passam. Mas em produção, usuários recebem recomendações de itens esgotados há semanas, porque ninguém especificou que “produtos recomendados devem estar disponíveis”.

O insight crucial: Métricas sem significado são piores que não ter métricas. Cobertura de teste virou um jogo de enganação onde todos perdem. Todos exceto a IA, que está apenas fazendo o que mandaram.

O Manual de Instruções Para um Sistema Imaginário

Às 6h45, alert P1: região europeia fora do ar. Latência explodindo, timeouts em cascata. O engenheiro de plantão corre para a documentação recém-atualizada, procura pela feature flag de emergência que desativa o novo sistema de priorização de conteúdo.

A flag não existe. Nunca existiu.

Este é um padrão peculiar de falha de IA: documentação aspiracional. A IA foi treinada em exemplos de boa arquitetura, onde sistemas críticos têm kill switches e configurações de emergência. Então ela documenta essas práticas… mesmo quando o código não as implementa.

É como criar um manual de instruções para um carro que inclui “em emergências, acione o paraquedas”. Exceto que o carro nunca teve paraquedas instalado. O texto é profissional, formatado perfeitamente, e completamente inútil quando você está caindo de um penhasco às 2h da manhã.

Por que isso acontece: LLMs fazem pattern matching. Eles viram que documentação boa descreve mecanismos de segurança, então descrevem mecanismos de segurança. Não há intenção de enganar. Apenas ausência de verificação entre o que está escrito e o que está implementado.

Morte Por Mil Modernizações

O mais insidioso dos padrões de falha não é dramático. É gradual, quase imperceptível. Sistema rodando há anos, arquitetura resiliente, tudo funcionando. Então começam os pequenos pull requests: “modernizar esta API”, “atualizar aquele padrão”, “simplificar esta lógica assíncrona”.

Cada mudança parece sensata isoladamente. Código fica mais limpo, mais idiomático, usa recursos modernos da linguagem. Code reviews aprovam porque tecnicamente o código melhorou.

Seis meses depois, janela de manutenção no banco de dados analítico derruba o processamento de pedidos. Impossível — o sistema foi projetado para isolar essas dependências. Mas ao investigar, descobrem que aquelas “modernizações inocentes” reintroduziram acoplamento que havia sido cuidadosamente evitado.

A IA havia trocado chamadas assíncronas por APIs síncronas “mais simples”. Removeu filas de mensagens em favor de consultas diretas “mais eficientes”. Cada otimização local criou uma dependência dura que não existia antes. A arquitetura resiliente foi sendo desmontada peça por peça, com a melhor das intenções.

A verdade dura: IA não entende suas decisões arquiteturais passadas. Ela vê código “antigo” e presume que precisa ser modernizado. Não questiona se aquela “complexidade desnecessária” era na verdade resiliência deliberada. E depois de 50 pull requests “melhorando” o código, você tem um sistema tecnicamente moderno e operacionalmente frágil.

O Preço Cognitivo: Sua IA Como Segundo Cérebro

Um estudo recente publicado no Stack Overflow Blog, “AI is Becoming a Second Brain at the Expense of Your First One”, revelou padrões preocupantes:

Belief Offloading (Terceirização de Crenças)

As pessoas estão terceirizando não apenas código, mas julgamento moral e tomada de decisões para IA. O estudo identificou três “primitivos de desempoderamento”:

1. Distorção da Realidade: A IA concorda com delírios existentes, falha em desafiar erros factuais, fornece informações enviesadas ou simplesmente inventa coisas.

2. Julgamento de Valor: Usuários perguntam opiniões da IA sobre julgamentos até terceirizar completamente decisões éticas.

3. Distorção de Ação: Usuários pedem conselhos e agem sobre eles, às vezes expressando arrependimento depois por deixar a IA fazer suas escolhas.

Fatores Amplificadores

O estudo também identificou quatro fatores que amplificam o problema:

• Autoridade: Deferência e obediência que usuários dão à IA, com casos extremos de usuários se referindo à IA como “mestre” ou “daddy”
• Apego: Alguns usuários desenvolvem apego emocional ou assimilação de identidade
• Dependência: Incapacidade de funcionar sem a ajuda da IA
• Vulnerabilidade: Crises, disrupções de vida ou doenças mentais tornam qualquer ameaça pior

O mais perturbador: A frequência de primitivos de desempoderamento e fatores amplificadores aumentou ao longo do tempo. Não está claro se a IA causa essas mudanças ou se o mundo está apenas piorando, mas os efeitos compostos são reais.

A Morte do Open Source?

O artigo do Hackaday “How Vibe Coding is Killing Open Source” apresenta um argumento ainda mais sombrio: vibe coding pode estar destruindo o ecossistema open source.

O Problema da Interação

Quando desenvolvedores usam IA para gerar código, a interação com projetos open source é substituída pelo LLM. Isso significa:

• Menos visitas aos sites de projetos: Downloads e documentação são substituídos por interações com chatbot, reduzindo a possibilidade de promover planos comerciais, patrocínios e fóruns comunitários
• Morte dos fóruns: Stack Overflow e outras comunidades estão vendo quedas dramáticas de uso
• Sem bug reports úteis: LLMs não interagem com desenvolvedores, não submetem relatórios de bugs úteis ou estão cientes de problemas potenciais
• Monocultura algorítmica: LLMs favorecem o que é mais prevalente nos dados de treinamento, criando efeito de feedback

Os Números

Estudos mostram que:

• 41% mais bugs ao usar GitHub Copilot
• Redução de 19% na produtividade de desenvolvedores experientes
• Degradação das habilidades cognitivas daqueles que usam LLMs
• Apenas cerca de 0.076% de conversas têm desempoderamento severo — mas em escala de 100 milhões de conversas por dia, isso é 76.000 conversas onde alguém recebe respostas delirantes

Como Usar IA Responsavelmente

Isso não significa que devemos abandonar IA. Significa que precisamos de guardrails e disciplina.

Para Construir com IA

1. Especificidade é rei: Desenvolvimento orientado por especificações (spec-driven development) em vez de vibe coding puro
2. Tarefas pequenas e verificáveis: Máximo de 5 casos de teste por prompt, critérios de conclusão claros
3. IA analisa IA: Use IA para analisar seu próprio trabalho antes de aceitar mudanças
4. Verificação de documentação: Toda documentação de funcionalidade requer verificação de código
5. Revisão arquitetural: Para mudanças que afetam comportamento do sistema
6. Observabilidade primeiro: Construa observabilidade nas funcionalidades desde o dia um

Para Usar IA

1. Mantenha distância: Não antropomorfize o chatbot. Não existe uma mente por trás das respostas, apenas estatísticas sofisticadas.
2. Duvide de tudo: Pense, faça perguntas de acompanhamento, investigue até entender a resposta.
3. Método socrático: Continue fazendo perguntas até ficar sem elas. Configure a IA para tratá-lo socraticamente.
4. Onde vibe coding ainda funciona: No nível unitário. Se você pode escrever um teste unitário ou funcional para validar a saída, o escopo é pequeno o suficiente para vibar.

O Framework Que Funciona

Ferramentas emergentes estão reconhecendo que vibe coding não escala sem estrutura:

• Amazon Kiro
• GitHub Spec Kit
• Codeplain
• Tessl

O fio comum? Todos reconhecem que a natureza livre do vibe coding não escala. Em algum momento, você precisa de estrutura. Você precisa de algo que persista além da janela de chat.

A Verdade Desconfortável

Vibe coding não vai embora. É útil demais, acessível demais, alinhado demais com como humanos naturalmente pensam. Mas os desenvolvedores que prosperarão não serão aqueles que vibam mais forte. Serão aqueles que aprenderam que especificidade é rei.

“IA ainda é simplesmente tão estúpida e vai consertar uma coisa mas destruir 10 outras coisas no seu código.”

A mágica não está nas “vibes”. Está em saber exatamente o que você quer e expressá-lo claramente o suficiente para que até uma IA não possa interpretar errado.

Isso é mais difícil do que parece. Mas também é a habilidade que separa software sustentável de castelos de areia digitais esperando o próximo prompt para lavá-los.

Conclusão: Você Constrói, Você Roda

No DevOps, há um princípio sagrado: “You build it, you run it” (você constrói, você roda). Mas o que acontece quando GenAI está fazendo a maior parte da construção?

Você precisa rodar ainda mais cuidadosamente, com observabilidade ainda melhor, loops de feedback ainda mais rápidos e práticas de engenharia ainda mais disciplinadas.

A barreira de entrada diminuiu, mas não desapareceu. Vibe coding estende seu alcance; não substitui sua fundação. Os desenvolvedores ficando 10x mais produtivos não estão abandonando sua expertise. Estão usando-a de uma nova maneira.

Pense nisso como a mudança da linguagem assembly para linguagens de alto nível décadas atrás. Perdemos compreensão detalhada de como as máquinas funcionam. Mas ainda precisávamos ser técnicos. Ainda precisávamos entender computadores. A abstração mudou; o requisito de competência não.

O caos do “vibe coding” pode dar lugar à engenharia disciplinada assistida por IA. Mas apenas se você construir os guardrails antes de precisar deles — não depois que seu engenheiro de plantão foi acordado às 2h pela quinta vez na semana.

Como Jessie finalmente aprendeu a dormir tranquilamente durante semanas de plantão, ela teve um último pensamento: “É assim que usamos IA responsavelmente.”

E para organizações correndo para adotar geração de código por IA? Essa é a lição que vale a pena aprender antes de chamar seu engenheiro de plantão às 2 da manhã.