IA no time não reduz o bus factor do seu projeto — pode aumentar
A confiança na IA não começa no modelo, começa no processo.
Esta é a nona parte de uma série sobre a metodologia que uso para continuar sendo, de fato, o responsável pelo que um agente de IA produz: o caso aplicado do artigo anterior, sobre ADRs em lote.
Se a pessoa que mais entende esse sistema saísse de férias amanhã, sem aviso, sem handoff, sem tempo de preparar ninguém, quanto do que está em produção continuaria fazendo sentido para o resto do time?
Disclaimer: este texto reflete minha visão prática sobre o tema, construída em projetos pessoais e profissionais. Não representa, necessariamente, a posição oficial de nenhuma organização à qual eu esteja afiliado.
Essa pergunta tem nome técnico: bus factor. O número mínimo de pessoas que, se “atropeladas por um ônibus”, travariam o projeto. Não é só uma brincadeira macabra: é uma forma de medir uma coisa muito real e muito mal medida, o quanto o conhecimento crítico de um sistema mora só na cabeça de alguém, em vez de em algum lugar que sobrevive a essa pessoa.
Um estudo de 2015 de Cosentino, Izquierdo e Cabot, apresentado na IEEE SANER, formalizou essa métrica a partir de dados reais de repositórios Git: simulando a saída de um ou mais desenvolvedores, o quanto de código fica “órfão”, sem ninguém que tenha tocado nele o suficiente para entender por que está do jeito que está. O achado incômodo foi que boa parte dos projetos open source estudados tinha um bus factor perigosamente baixo, mesmo com times aparentemente ativos.
A tentação, com um agente de IA no time, é assumir que esse problema ficou menor. Afinal, a IA “leu” o código inteiro, entende a base, pode explicar qualquer trecho sob pedido. Por que o bus factor ainda importaria?
O agente não reduz o bus factor. Ele quebra a própria métrica
A resposta ficou mais concreta do que eu esperava quando encontrei um estudo de 2025, de Otávio Cury e Guilherme Avelino, da Universidade Federal do Piauí, especificamente sobre isso: como um agente generativo afeta os modelos de conhecimento que o Truck Factor (a versão algorítmica do bus factor) usa por baixo dos panos.
Simulando diferentes graus de contribuição de IA em projetos reais do GitHub, os autores encontraram que a maioria dos cenários testados produzia impacto mensurável na métrica. É evidência simulada, mas ainda assim reveladora, de que ela é sensível o suficiente para ser afetada quando IA generativa entra na equação. Os próprios autores sugerem que essa confiabilidade pode piorar, não melhorar, conforme a IA se integra mais ao fluxo de trabalho.
O motivo é simples de nomear e fácil de subestimar: bus factor, calculado da forma tradicional, é uma métrica baseada em autoria. O Git ainda atribui uma mudança à pessoa que fez o commit, e mapas de propriedade de código ainda mostram essa pessoa como “especialista” naquele trecho. O problema é que, quando um agente de IA escreve o código e a pessoa só revisa e aprova, a autoria registrada no Git não corresponde mais ao entendimento real, e a ferramenta não tem como saber disso.
O bus factor não desaparece com IA no time. Ele migra para quem sabe fazer a pergunta certa ao agente, quem consegue reconhecer quando a resposta dele está sutilmente errada, quem tem contexto suficiente do histórico do projeto para notar que uma sugestão “razoável” na verdade contradiz uma decisão deliberada de três meses atrás.
Em times pequenos, ou em projetos mantidos por uma única pessoa, esse ponto único de falha nunca deixou de existir. Só mudou de forma: de “só uma pessoa entende o sistema” para “só uma pessoa sabe verificar se o que a IA disse sobre o sistema está certo”.
Em times maiores, o risco é sutilmente diferente e, de certa forma, pior: quando todo mundo pode pedir ao agente uma explicação plausível sobre qualquer parte do código, a pressão social para efetivamente entender aquele código antes de mexer nele cai. É mais fácil aceitar a explicação da IA do que investigar por conta própria. O bus factor real (quantas pessoas entendem de verdade, não quantas conseguem obter uma explicação sob demanda) pode estar caindo exatamente enquanto a sensação de cobertura de conhecimento sobe.
O ADR existe exatamente para isso, só que a régua mudou
A prática que resolve isso de forma mais direta é a mesma que descrevi no artigo anterior desta série, sobre registro de decisão em lote: um ADR não é sobre documentar tecnologia. É sobre registrar, de forma que sobreviva a quem escreveu, o “por quê” que normalmente só existe na cabeça de quem tomou a decisão.
O que muda com um agente de IA no time não é a necessidade do ADR, é a urgência dela. Um engenheiro novo, sem essa documentação, ainda tem um caminho, ainda que lento: perguntar para quem sabe, arqueologia de commits, tentativa e erro supervisionado.
Um agente de IA sem essa documentação não tem esse caminho de jeito nenhum. Ele produz uma resposta de qualquer forma, só que sem sinalizar que está adivinhando. A ausência de memória tácita, que num humano se manifesta como “não sei, vou perguntar”, num agente se manifesta como uma resposta articulada e potencialmente errada: o mesmo overclaiming que descrevi no artigo Disciplina em rajada.
Isso muda a régua do que conta como “documentação suficiente”. Não é mais suficiente que o conhecimento esteja disponível para quem souber procurar. Precisa estar escrito de um jeito que feche a lacuna que seria, de outra forma, preenchida por inferência (humana ou de agente) sem verificação.
Já contei, em ADRs em lote, e a regra da visibilidade, como uso o Adrpy/Adrpy-tui, ferramenta própria de código aberto para ADRs, com uma integração de agente de IA que audita a cadeia de decisões e sinaliza registros esquecidos em status inicial. O que importa reforçar aqui: o agente não decide nada, só devolve um relatório — quem confirma se aquilo é conhecimento real, e não só uma resposta articulada, continua sendo eu.
Na prática
Trate a saída de um ADR como parte do trabalho, não como documentação posterior. Se a decisão só existe na sua cabeça até você “ter tempo de documentar depois”, o bus factor do projeto é 1, mesmo com um agente de IA no time, porque o agente, sem o ADR, só reproduz sua ausência de contexto com mais confiança do que deveria ter.
Meça o bus factor de verdade, não a sensação de cobertura. A pergunta certa não é “o agente consegue explicar esse trecho?” (quase sempre consegue, com ou sem razão). É “quantas pessoas no time confirmariam, de forma independente, que essa explicação está certa?” Se a resposta é uma, o problema antigo continua exatamente onde estava.
Trate decisões relevantes tomadas em conversa com o agente como decisões que precisam do mesmo registro que uma decisão tomada em reunião. Um trade-off aceito numa sessão de trabalho com IA que nunca vira ADR desaparece tão silenciosamente quanto um combinado verbal numa reunião sem ata. Só que, dessa vez, ninguém nem lembra que a conversa aconteceu.
Audite periodicamente o que só o agente “sabe”. Se uma explicação técnica importante só existe como resposta de um agente, e não como documento que um humano pode conferir de forma independente, isso é bus factor não resolvido disfarçado de produtividade. E agora existe evidência, ainda que simulada, de que a métrica tradicional não vai capturar isso sozinha.
Conclusão
A promessa implícita de ter um agente de IA no time é que ele preenche lacunas, inclusive lacunas de conhecimento que antes só uma pessoa tinha. No fim das contas, ele só preenche as lacunas que já foram deliberadamente registradas em algum lugar legível.
Onde não há registro, ele não reduz o bus factor do seu projeto. Ele produz a aparência de tê-lo reduzido, e o estudo de 2025 indica que a própria métrica de autoria fica menos confiável, não mais, à medida que a contribuição de IA generativa aumenta.
A pergunta que abriu este texto continua sendo a pergunta certa, com ou sem IA: se essa pessoa sumisse amanhã, o que pararia de fazer sentido? A diferença é que agora você tem uma ferramenta capaz de mascarar a resposta, ou de ajudar a registrá-la de verdade, dependendo inteiramente de como você decide usá-la.
No próximo artigo desta série, mudo de nível outra vez: como calibrar quanto desse rigor todo realmente vale a pena, projeto a projeto, em vez de aplicar a mesma intensidade a tudo.
Tenham um excelente dia!
Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável. Como arquiteto sênior, aproveito meus mais de 30 anos de experiência em arquitetura e desenvolvimento de software para projetar e implementar soluções baseadas em nuvem que ajudam os clientes a transformar seus negócios com tecnologia.
Este texto foi escrito com apoio do Claude Code, a partir da minha experiência, minhas decisões e revisão: o próprio processo que a série descreve.
Nesta série
- Metodologia de Desenvolvimento Assistido por IA Centrada na Decisão Humana
- Disciplina em rajada: por que o rigor não nasce junto com o código
- O código duplicado que a IA cria enquanto parece produtiva
- As três práticas que nunca esperam gatilho
- Quem autorizou essa atualização de dependência? Pode ter sido sua IA
- Os quatro eventos de risco e a auditoria multi-frente
- Seu agente de IA resolve a issue de verdade, ou só parece resolver?
- ADRs em lote, e a regra da visibilidade
- IA no time não reduz o bus factor do seu projeto — pode aumentar (este artigo)
- Calibrando a intensidade ao risco real
- O alinhamento entre produto e engenharia começa onde a decisão fica registrada
- Segurança psicológica também vale para o time formado por você e sua IA
- Releitura: o papel do humano, os sinais que funcionam, e onde a metodologia ainda é fraca
Referências citadas
-
- Valerio Cosentino, Javier Luis Cánovas Izquierdo, Jordi Cabot, “Assessing the Bus Factor of Git Repositories”, IEEE SANER 2015: DOI 10.1109/SANER.2015.7081864
- Otávio Cury & Guilherme Avelino (Universidade Federal do Piauí), “The Impact of Generative AI on Code Expertise Models: An Exploratory Study” (arXiv, 2025): https://arxiv.org/abs/2507.08160
- Brett Wheeler, “The Substrate Collapse: AI Code Generation Invalidates Authorship-Based Knowledge Metrics” (arXiv, junho de 2026): https://arxiv.org/abs/2606.20882. Preprint mais recente e mais direto na mesma tese, ainda sem revisão por pares; tratado aqui como complemento ao achado de Cury & Avelino, não como substituto.
- Fernando Cerqueira, Adrpy/Adrpy-tui — ferramenta CLI de código aberto para Architecture Decision Records: adrpy-ai e adrpy-tui.
