O culto ao vibe coding é insano
(bramcohen.com)- O incidente do vazamento do código-fonte do Claude expôs como a fé cega em "vibe coding" pode prejudicar de fato a qualidade de projetos reais
- O vibe coding adota como princípio não olhar o interior do código de forma alguma, mas isso não passa de pura superstição; na prática, sempre há estrutura humana envolvida, como arquivos de planejamento, skills e regras
- A IA é de fato muito boa em tarefas como eliminar duplicação de código e organizar dívida técnica, mas, para aproveitar isso, humanos precisam examinar o código, identificar os problemas e explicá-los à IA
- É raro a IA reconhecer por conta própria que "há código espaguete aqui, preciso organizar isso"; resultados de alta qualidade surgem quando humanos fornecem antes a direção e o contexto
- Como diz a frase “software ruim é uma escolha do desenvolvedor”, a queda de qualidade não é culpa da IA, e sim resultado de decisões
- Ou seja, a piora da qualidade de software não é culpa da IA, mas sim uma escolha feita pelos próprios desenvolvedores
O vazamento do código-fonte do Claude e o problema do vibe coding
- O código-fonte do Claude vazou e foi alvo de zombaria de muita gente por causa da baixa qualidade do código
- Como causa do problema, foi apontado o excesso de dogfooding, ou seja, uma cultura de usar o próprio produto de forma cega e exagerada
- Dogfooding em si é uma boa ideia, mas pode se transformar em uma prática quase cultista que ultrapassa qualquer limite razoável
O que o vibe coding realmente é
- Vibe coding é uma abordagem cujo princípio é não fazer nenhuma contribuição ao código e nem mesmo olhar para dentro dele
- Porém, vibe coding puro é um mito — na prática, sempre existem frameworks criados por humanos, como arquivos de planejamento (listas de tarefas), skills e regras, e sem essa estrutura a IA tem desempenho muito fraco
- O código é escrito em inglês e qualquer pessoa pode lê-lo, mas, pela lógica de que "olhar por dentro é trapaça", desenvolvedores se recusam a conferir diretamente
- Quando uma pessoa de fato examinou o código, descobriu-se que havia duplicação em larga escala entre agentes e tools, algo que qualquer um perceberia facilmente com uma rápida inspeção
IA e a organização da dívida técnica
- Projetos de software frequentemente começam carregando dívida técnica, e no passado às vezes levava-se até 1 ano só para organizar isso
- Com IA, esse trabalho de organização pode ser concluído em poucas semanas, ou resolvido gradualmente em paralelo ao desenvolvimento de novos recursos
- A IA é muito boa para organizar código, mas tem pouca capacidade de detectar sozinha os problemas — bons resultados aparecem quando humanos dizem "há código espaguete aqui" e fornecem orientação
A forma correta de usar IA — abordagem baseada em diálogo
- Como forma correta de resolver o problema de duplicação, são sugeridas as seguintes etapas:
- Criar uma lista dos itens que aparecem tanto em agentes quanto em tools
- Revisar exemplos e decidir se cada item é um agente ou uma tool
- Discutir o critério geral e estabelecer diretrizes gerais
- Auditar todos os itens e corrigir os que foram classificados incorretamente
- Para itens que existem dos dois lados, revisar as duas versões e unificá-las em uma só
- O modo Ask existe para esse processo: revisar exemplos juntos e corrigir os pontos errados quando a IA tenta concordar demais é a parte central
- Depois de diálogo suficiente, pode parecer que a IA produziu um resultado one-shot, mas na prática esse resultado pressupõe muitas interações prévias com humanos
- A equipe do Claude, sem passar por esse processo, aplicou o dogfooding de forma extrema e se recusa até ao esforço mínimo de olhar rapidamente o interior do código e explicar o problema
Exemplo de uso real
- Exemplo do próprio fluxo de trabalho: ao iniciar uma conversa, dizer algo como "vamos auditar código inalcançável neste codebase" ou "esta função dói os olhos"
- A conversa continua até surgir uma direção executável; depois, explica-se o que precisa ser feito e a discussão segue até a IA parar de dizer bobagens
- Em seguida, fazer um plano e executar o build é a rotina habitual
Qualidade de software é uma questão de escolha
- Usar IA não significa que seja preciso aceitar software de baixa qualidade
- Bibliotecas feitas por desenvolvedores excessivamente bem pagos, mesmo sem ajuda de IA, também podem ter baixa qualidade
- Software ruim é uma decisão que a própria pessoa toma, e é preciso assumir essa responsabilidade e buscar uma qualidade melhor
9 comentários
Enquanto fazem
FULL AUTO MATIONcomAI AGENT, automatizando completamente geração de código, merge, review e validação, e tratam como se já estivesse tudo resolvido se o código for montado de forma totalmente autônoma e o desenvolvedor só precisar intervir de vez em quando quando os agentes se embolam, acabou se espalhando um clima de considerar anormais os desenvolvedores que não conseguem fazer isso, como se não acompanhassem a tendência... Aí, quando vejo esse pessoal que provavelmente vive espalhando código boilerplate e sequências de padrões repetitivos, recebendo salários altos, e agora fica falando pelos cotovelos que com IA nem precisa mais programar, é algo simplesmente patético.É preciso microgerenciar até os detalhes mais triviais para produzir código com uma qualidade minimamente convincente. Acho que autonomia total simplesmente não faz sentido, exceto talvez para produzir boilerplate de verdade em massa. Quem fala em autonomia total é uma de duas coisas: ou não entende muito do assunto, ou é picareta.
Projetos pela metade estão se espalhando…
E pessoas que só entendem programação pela metade ficam eufóricas…
Acho melhor entender
dogfoodingnão como monopólio, mas como “dog pudding”.dog食...
O título e o conteúdo são diferentes…?
Parece mais uma crítica que conclui que vibe coding é igual a não fazer code review e depois cola justificativas para sustentar isso.
Além disso, também não faz sentido trazer Claude Code para a conversa. Se for cobrar esse nível de qualidade, isto é, princípios de engenharia no nível de manutenção do Linux, não se aborda problema de qualidade de código de forma tão fragmentada. Quase tudo é uma abordagem propagandística, daquele tipo de “ouvi dizer”, sem ter testado diretamente.
É parecido com dizer que o design dos prédios da Samsung é ruim e que ela ainda está longe de alcançar a Sony.
Quando usei o Claude Code pela primeira vez, falei para uns amigos estrangeiros: "acabei de experimentar vibe coding pela primeira vez!". Mas, depois de ouvirem o que eu estava contando, eles responderam: "não, isso não é vibe coding; vibe coding de verdade é programar sem nem olhar o código". Parece que o que costuma ser chamado de "vibe coding" aqui na Coreia é definido de forma muito mais ampla do que no Ocidente. O vibe coding de que se fala no Hacker News é, de fato, definido como "não fazer code review".
Comentários do Hacker News
É estranho ver gente usando a qualidade do código-fonte vazado do Claude Code como exemplo para dizer que o “vibe coding” fracassou
Na verdade, é o oposto. Acho que isso prova que dá para criar produtos populares e bem-sucedidos mesmo violando regras tradicionais de “bom código”
Código improvisado por causa de prazos apertados muitas vezes acaba ficando em produção
Mesmo em projetos pessoais, os primeiros commits são uma bagunça, e só depois a gente cria uma branch de limpeza para arrumar
Mas, nas empresas, quase nunca há tempo para fazer uma segunda ou terceira versão, então a primeira acaba indo para produção
Sinceramente, às vezes me preocupo com a possibilidade de vazarem código com meu nome. Mas essa é a realidade
Se, ao alterar o código, você sente que “isso aqui está meio forçado”, consertar na hora acaba economizando tempo
Sobre LLMs, ainda não tenho experiência suficiente para afirmar com certeza
O Claude Code é, em essência, um produto simples, e o valor real está no próprio modelo
Ou seja, foi possível nesse caso porque é um produto de baixo risco em que a baixa qualidade do código não vira um grande problema
Isso também não viola o conceito de “vibe coding”. A estrutura é dar apenas ideias abstratas de alto nível, e a IA escreve o código de fato
O Claude Code está no nível AI Level 7 (humano faz a spec, bot faz o código), e o autor afirma que o Level 6 é melhor
O nível ideal varia de pessoa para pessoa. Alguns acham que o limite é o Level 5 ou menos, outros consideram perigoso qualquer coisa acima do Level 2
O nível adequado muda conforme a complexidade e a novidade do domínio
Por exemplo, no app que estou fazendo, a parte de algoritmos é Level 0, a UI é Level 7, e o middleware fica em algum ponto no meio
Encontrar o nível certo para cada área do código é a verdadeira habilidade
Em linguagens dinâmicas, passar disso me deixa inseguro. Se eu fosse para Level 7 ou mais, acho melhor migrar completamente para uma linguagem com tipagem estática
Programar vai virar algo como ferraria: só uma parte vai restar, e o resto será automatizado
Mas, em compensação, isso vai permitir que uma pessoa faça o trabalho que antes exigia uma equipe inteira
A tentação de aceitar uma funcionalidade sem entender completamente como ela funciona é grande
O autor deste texto é o criador do BitTorrent. Não é só um blogueiro qualquer
Meu uso favorito do Claude Code é para melhorar a qualidade do código
Coisas que, se feitas por uma pessoa, pareceriam perda de tempo, a IA faz praticamente de graça, então vale a pena
Organizar padrões repetitivos de teste, manter consistência na serialização JSON, remover código duplicado etc.
No fim, o codebase fica menor e mais fácil de manter. É como uma espécie de linting em larga escala
Valido cruzadamente os resultados de cada modelo e, no fim, o Opus monta a lista final e faz as correções
Há bastante mudança desnecessária, mas os problemas que eles encontram são realmente úteis
A perspectiva de “dogfooding” é interessante
O ponto central não é a qualidade do código, e sim se o usuário consegue avaliar criticamente o resultado da IA
Um engenheiro experiente usar IA mantendo o próprio julgamento é algo totalmente diferente de delegar esse julgamento à IA
O problema é que a ferramenta não distingue esses dois casos, e o marketing é voltado para o segundo
Quem defende o “vibe coding” argumenta que, como LLMs conseguem iterar muito mais rápido do que humanos, a qualidade do código não importa
Humanos têm custo alto em cada etapa (escrever–validar–corrigir), enquanto LLMs podem iterar rapidamente pagando só o custo de tokens
Mas sou cético em relação a essa abordagem. Já vi casos demais em que tudo quebra na prática
Ainda assim, se os LLMs melhorarem mais, talvez eles tenham razão
No espectro do “vibe coding” há dois grupos
Um é o de pessoas sem base técnica que gostam disso porque acham incrível; o outro é o dos haters de IA
Entre eles existe uma camada intermediária silenciosa, mas produtiva. São pessoas otimistas e experientes ao mesmo tempo
Nos últimos 6 meses, eu mesmo gastei cerca de US$ 2500 em créditos do Claude Code, e mesmo que a maior parte não tenha ido para produção, obtive um valor enorme com isso
Não concordo com a afirmação de que “Claude Code é inútil”
A maioria dos webapps está no nível simples de CRUD. 99% das empresas nem sequer têm 50 mil usuários
Na empresa em que trabalhei, por causa de código ineficiente, era preciso rodar programas 22 horas por dia
Esse fenômeno lembra a teoria da inovação de Clayton Christensen
Empresas estabelecidas ficam acomodadas em seus produtos atuais, mais lucrativos, e ignoram novas tecnologias de baixa qualidade; mas, no fim, essa tecnologia evolui o bastante para virar o mercado de cabeça para baixo
O Claude Code já está em um nível “bom o suficiente”, e, se a IA continuar avançando, no fim vai superar o código escrito manualmente
As pessoas em torno do “vibe coding” se dividem em alguns grupos
① interessados financeiramente, ② desenvolvedores cansados de programar, ③ iniciantes criando algo pela primeira vez
O grupo ② não quer aprender nada novo, e o ③ está sinceramente experimentando a alegria de criar
Programação com IA pode ser uma boa porta de entrada para essas pessoas
Eu mesmo sou desse tipo. Amo programar há 30 anos, mas o tempo para transformar o que imaginava em algo real era longo demais
Agora essa lacuna desapareceu, e isso me dá uma sensação de libertação. Meu objetivo é aprender a acelerar mantendo a qualidade
Copiando os problemas das grandes empresas, a produtividade caiu e o cansaço só aumentou
Agora, graças à IA, dá para ignorar essa complexidade e ir direto ao resultado
Mesmo que surjam novos frameworks ou formas de deploy, não há necessidade de se preocupar. A IA cuida disso
Esse tipo de conflito se repete sempre que há troca de geração tecnológica