Vibe coding reduz o Bus Factor a 0
(mindflash.org)- Em desenvolvimento de software, Bus Factor é o conceito que indica quantas pessoas precisam deter determinado conhecimento para que seja possível manter um projeto; tradicionalmente, o pior caso era 1
- Porém, após o lançamento do ChatGPT (30 de novembro de 2022), com a adoção em massa da IA generativa, muitas pessoas passaram a não preservar mais o conhecimento diretamente e a depender da IA, criando na prática uma situação de Bus Factor 0
- No dia a dia da programação, cada vez mais desenvolvedores usam código e funcionalidades gerados por LLMs do jeito que vieram, abandonando o esforço de entender a base de código e migrando para o “vibe coding”
- Com isso, ao corrigir bugs, aplicar patches de segurança ou expandir funcionalidades, pode-se chegar a uma situação em que ninguém sabe por que o código foi escrito daquela forma
- Isso traz riscos graves para a confiabilidade e a segurança do software, e existe uma limitação fundamental até o dia em que a IA conseguir gerar código perfeito de forma perfeita
Conceito e história do Bus Factor
- Bus Factor é um conceito que expressa em números com quantas pessoas um determinado conhecimento é compartilhado
- Exemplo: se 3 pessoas sabem restaurar um backup do banco de dados, o Bus Factor dessa função é 3
- Tradicionalmente, o pior valor era 1; se uma pessoa perdesse esse conhecimento, seria impossível manter o projeto
- Para superar isso, a humanidade difundiu conhecimento por meio de documentação, treinamento, transferência de conhecimento, seminários, escolas e muitos outros métodos
- Isso levou a esforços sistemáticos para transmitir e preservar conhecimento, com grande investimento de tempo e recursos humanos
A adoção de IA e o Bus Factor 0
- O lançamento do ChatGPT em novembro de 2022 abriu a era do “AI First”
- No processo em que a IA gera código e funcionalidades, muitas pessoas deixam de ser protagonistas na preservação do conhecimento e passam a depender dos artefatos gerados pela IA, reduzindo rapidamente a compreensão do projeto
- Como resultado, surge um estado em que não há nenhum detentor do conhecimento, ou seja, uma situação de Bus Factor 0
- Os programadores mostram uma tendência de não escrever nem entender por conta própria o código e as funcionalidades, delegando completamente à IA
- Nesse processo, os desenvolvedores passam a evitar entender a base de código e documentá-la, limitando-se a pedir novas explicações à IA
Problemas da programação baseada em LLM
- Mesmo deixando de lado a questão da qualidade do código, o ponto central é que ler e manter código é, por natureza, mais difícil do que escrevê-lo
- No passado, mentores ou documentação forneciam pelo menos uma ajuda mínima, mas em um ambiente dependente de IA até essa rede de segurança desaparece
- No desenvolvimento baseado em LLM, o processo de geração do código não fica registrado e nem a própria IA consegue se lembrar do contexto do código que gerou
- No fim, os desenvolvedores ficam diante da situação de ter de analisar e modificar código escrito por IA, mas com contexto obscuro
- Isso leva a um estado em que, ao resolver bugs, corrigir vulnerabilidades de segurança ou atualizar dependências, ninguém consegue entender a intenção e a estrutura do código
Riscos do ponto de vista do usuário
- Não são apenas os desenvolvedores que ficam expostos ao risco; os usuários também
- Um software para o qual se enviam documentos pessoais, dados de cartão de crédito, fotos privadas ou pensamentos íntimos pode ter sido criado com código cujo funcionamento interno e propósito ninguém conhece
- Isso envolve riscos graves em termos de proteção de dados e confiabilidade e levanta dúvidas sobre a estabilidade do serviço
Conclusão
- O vibe coding, que leva ao Bus Factor 0, é uma abordagem fundamentalmente falha
- Essa é uma limitação inevitável até que a IA seja capaz de gerar código 100% correto a partir de prompts 100% corretos
- Portanto, na situação atual, além do uso de IA, não se pode negligenciar a preservação do conhecimento e a importância de entender o código, sendo essencial manter práticas de gestão do conhecimento e documentação
3 comentários
Não seria o caso de o fator ônibus ter se tornado infinito?
Se os desenvolvedores da empresa não têm conhecimento, o bus factor converge para zero.
Comentários do Hacker News
Usar LLM para simplesmente despejar uma enorme quantidade de código não revisado é um uso errado da ferramenta; isso significa que o projeto está estruturalmente indo na direção errada ou que, quando surgirem bugs complexos, ele logo se tornará impossível de manter O verdadeiro ponto forte dos LLMs está em situações como estas: quando é preciso aplicar um algoritmo conhecido a uma estrutura de dados complexa já existente, montar dados de teste ou o esqueleto de testes unitários cheios de dependências, criar um editor visual web com uma API de backend e adicionar persistência em sqlite, ou aplicar uma tarefa repetitiva difícil até mesmo com expressões regulares complexas em uma base de código grande Na prática, graças aos LLMs, coisas que levariam meio dia ou 3 dias podem começar em 2 minutos O importante é que, mesmo que o LLM não resolva problemas muito difíceis, ele ainda pode aumentar muito a produtividade Dá para se livrar de tarefas repetitivas e focar em problemas mais interessantes
Achei que o LLM terminaria em 2 minutos mudanças repetitivas numa base de código grande, mas ao testar diretamente com vários modelos grandes, vi que, quanto mais complexo o contexto, mais os erros se acumulavam, e às vezes até surgiam mudanças irrelevantes, então no fim não era confiável Em exemplos pequenos funciona perfeitamente, mas conforme a escala cresce, fica aquém Dá para melhorar com um agentic loop, mas executar e revisar repetidamente acaba consumindo muito mais tempo É muito mais confiável pedir ao LLM para escrever um programa que automatize a mudança
Todos os exemplos apresentados parecem bons, mas na prática existem muito mais casos de uso possíveis Você falou de casos de desenvolvedores experientes, mas mesmo para quem tem pouca habilidade técnica ou está apenas começando, os LLMs ampliaram bastante o que essas pessoas conseguem fazer Algo pelo qual antes você pagaria 100 dólares agora pode ser tentado por conta própria em 3 minutos Se o resultado é perfeito e sustentável ou não deixa até de ser o mais importante; mostrar a possibilidade tem um valor ainda maior
Concordo com sua opinião, mas queria compartilhar uma experiência recente engraçada Pedi ao Claude para escrever testes unitários e, na revisão, descobri que de fato havia um bug no meu código, e o teste encontrou isso Só que, em vez de corrigir o bug, o Claude tentou fazer o teste passar simplesmente deixando de executar o teste que falhava; um episódio divertidamente realista LLMs são fracos em definição de requisitos, projeto de arquitetura e escrita de especificações alinhadas aos requisitos, mas têm força em tarefas de escopo claro e impacto limitado, como escrever código
Apliquei uma etapa intermediária em que a IA faz automaticamente a revisão do PR e depois eu faço a revisão manual A geração de código leva de 5 a 10 minutos, e a revisão com commits adicionais geralmente leva de 1 a 3 horas, mas consegui aplicar esse método com sucesso em vários projetos (10~20k LOC, cerca de 100 arquivos) Se a especificação for boa, muitas funcionalidades são implementadas quase corretamente sem grandes ajustes, e o que mais acontece é refatoração baseada em feedback Claro, quando não funciona direito, às vezes leva quase um dia para resolver, mas no geral o ganho de produtividade é de 3 a 5 vezes Para projetos grandes, parece melhor dividir e modularizar
Expressões como "x dias de trabalho concluídos em 2 minutos com LLM" são um pouco exageradas porque não incluem o tempo de revisão Quando se soma o processo real de revisão e validação, leva bem mais tempo Isso pode até levar justamente ao “jeito errado” mencionado no começo
Este texto apresenta vários problemas da geração de código por IA, mas parece não considerar soluções que já existem ou que ainda podem surgir Mesmo antes, se a equipe tivesse dedicado ao menos um mínimo de esforço à base de código, já dava para ajudar quem chegasse depois a entendê-la Fico em dúvida se falta experiência com código legado, ou se realmente acham impossível corrigir o fato de que a IA "esquece todo o contexto do processo de escrita inicial" Também parece haver um mal-entendido de que o problema do Bus Factor 0 só seria resolvido se a solução fosse 100% perfeitamente precisa, quando na verdade as pessoas também não estão certas 100% do tempo, e ainda assim confiamos nelas
Senti que o texto enxerga o problema de forma excessivamente resumida A realidade de não podermos fazer tudo junto com o autor já existe desde o início Só a existência de um par ou de uma IA que explique já é um avanço enorme Parece imaginar um mundo sem humanos, mas na prática já lidamos com isso com frequência
Eu sou o autor, concordo com a primeira observação e acho que a IA vai reduzir essa lacuna no futuro Mas, até lá, alguns problemas talvez já tenham acontecido Também existe a questão de ficar um código sem contexto lógico ou histórico de decisões Fala-se muito que a IA "está sempre aprendendo", mas na prática ela não aprende até surgir um novo modelo Pessoas também não são 100% precisas, mas não têm Bus Factor 0; é mais fácil entender e resolver o problema Se os outros problemas forem resolvidos, o problema do bus factor também diminui
Ao analisar código legado no passado, eu pensava que gostaria de ter ferramentas de IA Houve mesmo situações absurdas do tipo: "o último autor deste arquivo Perl agora é gerente da filial, vou ter que marcar uma reunião com ele?"
Sobre a pergunta "por que precisa ser 100% preciso?", acho que as pessoas críticas à IA tendem, na verdade, a esperar que a IA seja uma solução magicamente perfeita Tem uma nuance parecida com quem é contra tipagem estática e reclama que "ela nem pega erros lógicos"
Hoje em dia há tantas imagens feitas por IA nos blogs que isso mais atrapalha a concentração do que ajuda, e em muitos casos não acrescenta nada ao conteúdo
Entrei recentemente em uma equipe com uma base de código caótica, em que a maioria dos desenvolvedores antigos já tinha saído, e mesmo os que ficaram conheciam mal o código Era literalmente Bus Factor 0 Surpreendentemente, graças à IA, melhoraram muito a velocidade de entendimento do código, de compreensão da intenção e de depuração Começamos a extrair documentação diretamente do próprio código com IA Documentação e tradição oral podem ser distorcidas, mas o código em si é a verdade Com a ajuda da IA, conseguimos criar um ambiente em que o código se explica sozinho, e senti um grande ganho de produtividade
O Bus Factor já era um problema antes do surgimento dos LLMs A maioria das empresas não estruturava o trabalho de forma que várias pessoas entendessem cada parte Mesmo quando várias pessoas são alocadas em áreas diferentes, o volume de trabalho continua crescendo e no fim a situação se repete: ninguém entende tudo de verdade Para evitar isso por completo, seria necessária uma gestão de engenharia enorme, como rodízio de pessoas dentro da base de código, e normalmente isso não é feito perfeitamente por causa da pressão por velocidade Organizei minhas reflexões sobre isso, com base na minha experiência como CTO, em um livro publicado aqui, disponível independentemente do preço Acho que os princípios de um ambiente em que o sistema foi feito com LLM não são tão diferentes de um ambiente em que se usaram 10 desenvolvedores terceirizados
Bus Factor já era um problema antes dos LLMs, e é um termo técnico que existe há muito tempo O TFA está criticando a tendência de antes o Bus Factor ser 1 e agora estar indo para 0
O volume de trabalho só aumenta, mas na prática isso não faz o trabalho seguir numa direção mais recomendável; só repete o padrão de terminar tudo de qualquer jeito para cumprir prazo Colocar alguns obstáculos de processo não resolve isso
Nosso cérebro tenta economizar energia com informações que não usa com frequência, então quanto mais nos afastamos de algo, pior o entendemos ou mais o esquecemos Mesmo fazendo toda a revisão de código diretamente, no fim a habilidade pode se deteriorar É parecido com quando um engenheiro passa muito tempo em funções de gestão e quase perde a capacidade de resolver problemas técnicos Na automação de carros também é difícil manter o ser humano continuamente envolvido nas etapas intermediárias (level2→5), e se a máquina não for 100% confiável, isso acaba virando um problema
Há um ponto realmente importante nesta discussão: na verdade, essas ferramentas e workflows ainda estão só no começo Estou convencido de que, no futuro, a IA pode resolver esse tipo de problema melhor do que humanos Também fiz experimentos usando LLMs, com alguns sucessos e algumas falhas, mas em áreas específicas eles mostram capacidades claramente excelentes LLMs não ficam com preguiça e podem atualizar cuidadosamente documentação, comentários, README e até ADRs Se houver guia e estrutura suficientes, uma base de código feita com LLM pode até ser mais fácil de abordar no longo prazo, justamente porque tende a ter documentação melhor
Acho que o texto ignora que, só pelo código em si, já é possível ler bastante da intenção Os humanos — e provavelmente os LLMs também — são seres bastante previsíveis Em geral resolvem problemas parecidos de maneiras parecidas Observando como o código foi escrito, dá para encontrar pistas sobre por que, quem e quando resolveu determinado problema Claro que muita informação se perde, mas isso também acontece em organizações onde os membros mudam com frequência
Acho que o processo de pensamento humano acaba mesmo embutido no código, mas ainda assim isso é muito inferior a ter alguém a quem você possa perguntar diretamente Engenharia reversa normalmente só é feita quando realmente necessário, e em código legado todo mundo acaba fazendo isso Mas, em termos de produtividade, não é algo bom E numa base de código gerada por LLM não existe uma intenção única, mas sim uma mistura de intenções de várias pessoas diferentes, então olhar apenas alguns trechos pode tornar ainda mais confuso entender qual era o propósito original Isso pode até levar as pessoas a acreditar, por engano, que código gerado por IA tem exatamente o mesmo significado rigoroso que código escrito por humanos, tornando a interpretação ainda mais difícil
A capacidade de entender a intenção olhando só o código depende do escopo e da escala Se for algo como Arduino, com limite de 32kB, entender é fácil Mas numa plataforma complexa com dezenas de microsserviços emaranhados, especialmente se tudo tiver sido feito no estilo de 'vibe coding', se isso virasse minha responsabilidade eu só teria vontade de desistir
Concordo com o ponto central e a conclusão do texto, mas ao longo de 20 anos passei várias vezes por situações parecidas (ambientes em que não havia ninguém a quem perguntar, e os responsáveis reais já tinham ido embora) Com LLMs isso pode até ficar um pouco mais rápido, mas acho que não é exatamente um problema novo, e sim uma aceleração de um problema antigo Gosto que essa preocupação esteja sendo levantada
Há até o caso oposto Se a base de código for bem documentada, testada e configurada para que a IA a use bem, imagino que, daqui a 1 ano, um agente de IA consiga fazer o mesmo trabalho mais rápido
Tenho curiosidade sobre como uma AI Coding Tool passará a adotar a atitude típica de desenvolvedores antigos de que "todo o código anterior é ruim, então é melhor reescrever tudo" Também acho interessante imaginar se, no futuro, o próprio sistema de CI/CD pode virar algo em que a IA reescreve o projeto inteiro de uma vez
Eu sou o autor, e se for como você disse, então o Bus Factor já estará aumentando Ou seja, o essencial é que a informação não fique só na cabeça das pessoas, mas seja armazenada e preservada em várias formas