← Todos os Posts

Vibe Coding vs. Engenharia: Onde eu traço o limite

6 min read

Andrej Karpathy cunhou o termo “vibe coding” em fevereiro de 2025, descrevendo um estilo de desenvolvimento onde o programador “se entrega completamente às vibes, abraça os exponenciais e esquece que o código sequer existe.”1

Li aquilo e pensei: isso é metade do meu fluxo de trabalho. A outra metade é o oposto.

Resumo

Eu construo com Claude Code todos os dias. Parte desse trabalho é puro vibe coding: descrevo o que quero, aceito o resultado, sigo em frente. Outra parte passa por 86 hooks, um guardião de segurança do git, um limitador de recursão e um sistema de quality gates que bloqueia commits com marcas de texto gerado por IA ou voz passiva. A linha entre os dois não é arbitrária. Protótipos levam vibes. Produção leva engenharia. A parte difícil é saber quando um protótipo cruza essa linha.

Meu fluxo de trabalho real

O lado vibe

Quando estou explorando uma ideia, faço vibe coding sem pedir desculpas. Meu app iOS Ace Citizenship começou como um experimento de fim de semana: “Construa um quiz de repetição espaçada para questões cívicas do USCIS.” Claude Code gerou as views iniciais em SwiftUI, o banco de perguntas e o algoritmo de agendamento. Não li cada linha. Executei, testei manualmente e iterei descrevendo o que parecia errado.

Os componentes interativos deste blog (a árvore de decisão de RAG, a calculadora de juros compostos) começaram da mesma forma. “Construa uma árvore de decisão que guie os usuários entre RAG vs fine-tuning com transições animadas.” Aceitar, testar, ajustar. O raio de impacto de um bug em um widget do blog se limita a uma única página.

O lado engenharia

Minha arquitetura de hooks do Claude Code é o oposto de vibe coding. Cada hook existe porque algo deu errado.

git-safety-guardian.sh existe porque o Claude fez force-push na main durante uma sessão inicial. O hook agora intercepta cada comando git, faz pattern-matching contra uma tabela de severidade (CRITICAL: force push na main; HIGH: adição de arquivos .env; MEDIUM: –no-verify) e injeta um aviso antes da execução.

recursion-guard.sh existe porque um subagente gerou filhos infinitos. O hook rastreia a linhagem de agentes em um arquivo JSON, impõe limites de profundidade e gerencia um modelo de orçamento de spawn que previne cadeias descontroladas de agentes enquanto permite trabalho paralelo legítimo.

blog-quality-gate.sh existe porque prosa gerada por IA soa como prosa gerada por IA. O hook bloqueia commits em content/blog/ se detectar travessões em excesso, voz passiva ou palavras como “delve,” “crucial” ou “landscape.”

Nenhum desses hooks foi feito com vibe coding. Cada um foi escrito linha por linha, testado contra cenários reais de falha e revisado antes do deploy. Os 86 hooks coletivamente representam a fronteira entre vibing e engenharia.

Onde a linha realmente cai

Vibe: Protótipos descartáveis

Faço vibe coding em qualquer coisa que eu possa jogar fora. Um script de transformação de dados que vou executar uma vez. Uma ferramenta CLI para uso pessoal. Uma prova de conceito para testar se uma API faz o que a documentação promete. O custo de um bug em código descartável é meu próprio tempo, e o ganho de velocidade supera o risco de debugging.

Vibe: Exploração criativa

Quando estou explorando uma direção de design, vibe coding me permite testar padrões de interação mais rápido que Figma. “Construa um modal de busca com navegação por teclado, destaque de resultados e ativação por Cmd+K” produz um protótipo funcional em minutos. Eu avalio a sensação, não o código.2

Engenharia: Tudo que toca os usuários

No momento em que o código serve alguém além de mim, ele cruza a linha. Meu blog passa por um linter de 12 módulos que verifica citações, hierarquia de cabeçalhos, nível de legibilidade, texto alternativo de imagens, densidade de links internos e profundidade de conteúdo. O linter tem 77 testes. O blog tem 29 posts. O linter tem mais testes do que o blog tem conteúdo.

Engenharia: Tudo que persiste

Schemas de banco de dados, contratos de API, configurações de hooks e manifestos de deploy recebem tratamento completo de engenharia. Essas decisões se acumulam. Um schema projetado em uma sessão de vibes se torna um pesadelo de migração quando três anos de dados se acumulam sobre ele.3

Engenharia: Tudo relacionado a segurança

Código gerado por IA reflete a postura de segurança dos seus dados de treinamento, que incluem tutoriais e respostas do Stack Overflow que rotineiramente omitem autenticação, validação de entrada e tratamento de erros por questões de brevidade.4 Meus hooks capturam parte disso (o guardião de segurança do git sinaliza adições de .env, arquivos de credenciais e force pushes), mas código crítico de segurança recebe revisão manual independentemente.

O problema da lacuna de compreensão

O padrão mais perigoso no vibe coding não é código ruim. É código que funciona até parar de funcionar.

Gerei uma camada de cache para meu sistema de tradução i18n. Funcionou perfeitamente para conteúdo em inglês. Quando adicionei coreano e chinês tradicional, a geração de chaves de cache produziu colisões silenciosas para certos code points Unicode. O debugging levou quatro horas porque eu nunca tinha lido a função de geração de chaves de cache. O código estava correto para ASCII, que era tudo o que os dados de treinamento enfatizavam.5

A lição: sistemas feitos com vibe coding falham nas bordas que os dados de treinamento sub-representam. Se seus usuários operam nessas bordas (scripts não latinos, alta concorrência, condições de rede incomuns), implementações feitas com vibe coding carregam risco oculto.

O portão de revisão

Cada trecho de código destinado à produção no meu sistema passa por um portão de revisão, seja escrito por mim ou pelo Claude Code:

  1. Leia cada linha. Código gerado é um pull request de um contribuidor não confiável. Revise de acordo.
  2. Verifique o tratamento de erros. Confirme que os caminhos de erro refletem requisitos do domínio, não padrões genéricos de try-catch.
  3. Audite dependências. A IA resolve cada prompt isoladamente, importando qualquer biblioteca que resolva o pedido imediato. Após 50 prompts, você pode ter três bibliotecas de datas e dois clientes HTTP.
  4. Adicione testes. Código gerado raramente cobre casos extremos específicos do seu domínio.
  5. Verifique a segurança. Execute análise estática. Verifique autenticação, autorização e validação de entrada.6

O portão de revisão não é opcional. É a diferença entre usar IA como multiplicador de força e usar IA como muleta.

A divisão da indústria

A engenharia de software está se dividindo em dois níveis. O primeiro usa IA como multiplicador de força: gerando boilerplate, explorando espaços de solução e acelerando a implementação de padrões bem compreendidos, mantendo compreensão e padrões de qualidade. O segundo gera aplicações inteiras sem entender o resultado, trocando velocidade de curto prazo por fragilidade de longo prazo.7

A divisão espelha o início do desenvolvimento web. Construtores de templates como Squarespace democratizaram a publicação na web e produziram milhões de sites funcionais. O desenvolvimento web profissional persiste porque sistemas de produção exigem qualidade, segurança e manutenibilidade que templates não conseguem oferecer.

Eu opero nos dois níveis deliberadamente. Meu sistema de hooks e quality gates existe especificamente para capturar o momento em que trabalho do segundo nível precisa se graduar para padrões do primeiro nível. Os 86 hooks não são burocracia. São o sistema imunológico que me permite fazer vibe coding livremente enquanto impede que trabalho feito com vibes chegue à produção sem revisão.

Pontos-chave

Para engenheiros que usam IA diariamente: - Trace uma linha explícita entre exploração e produção; faça vibe coding livremente em trabalho descartável, mas imponha portões de revisão antes de qualquer coisa que toque usuários ou persista - Construa proteções automatizadas (hooks, linters, quality gates) em vez de depender apenas de disciplina; disciplina falha às 2 da manhã, hooks não

Para gestores de engenharia: - Estabeleça fronteiras claras entre código de qualidade de protótipo e código de qualidade de produção; protótipos feitos com vibe coding que escapam para produção criam uma nova categoria de dívida técnica - Avalie produtividade por resultados (funcionalidades entregues, bugs por funcionalidade, satisfação do usuário) em vez de métricas de velocidade; vibe coding infla contagem de linhas sem melhorar proporcionalmente os resultados

Referências

  1. Karpathy, Andrej, “Vibe Coding,” X/Twitter, fevereiro de 2025. Definição original do termo. ↩

  2. Fluxo de trabalho do autor construindo componentes interativos e protótipos de design com Claude Code, 2025-2026. ↩

  3. Análise do autor sobre custos de migração de banco de dados em três sistemas de produção. O custo de migração cresceu 15x ao longo de três anos. ↩

  4. Pearce, Hammond et al., “Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions,” IEEE S&P 2022. ↩

  5. Experiência do autor debugando colisões de chaves de cache i18n no sistema de tradução do blakecrosley.com, fevereiro de 2026. ↩

  6. Anthropic, “Claude Code Documentation: Best Practices,” docs.anthropic.com, 2025. ↩

  7. Análise do autor sobre o sistema emergente de níveis de desenvolvedores, observado no Hacker News, X/Twitter e conferências de desenvolvimento, 2025-2026. ↩