SINTOMA 03
Três pessoas sabem como o sistema realmente funciona
Existe um grupo pequeno sem o qual nada anda: um incidente sério, uma decisão de arquitetura, uma dúvida sobre por que aquele serviço faz aquilo. Todo mundo sabe quem são. É o risco que não aparece em nenhum painel até o dia em que aparece.
atualizado em
Como isso aparece no dia a dia
- pull requests param esperando a revisão de uma pessoa específica
- incidentes escalam sempre para os mesmos nomes, em qualquer horário
- o onboarding de um desenvolvedor sênior leva mais de dois meses
- férias e saídas são tratadas como risco operacional, não como rotina
- a resposta para "por que isso é assim?" é "pergunta para o fulano"
Por que acontece
O conhecimento não está faltando: ele está em lugares que não são consultáveis. Em conversas de chat, em decisões tomadas numa call, em convenções que a pessoa aprendeu apanhando e nunca escreveu, em comentários de pull requests de dois anos atrás.
Nenhum desses lugares sobrevive à rotatividade, e nenhum deles é legível por um agente. Uma IA que poderia responder metade das perguntas do time não tem onde procurar — e acaba reproduzindo a mesma pergunta para o mesmo especialista.
A concentração se agrava sozinha: como perguntar é mais rápido que documentar, o especialista vira o caminho de menor resistência, e cada resposta dada oralmente reforça a dependência.
Por que a correção óbvia não resolve
Abrir uma wiki e pedir para o time documentar.
Documentação que vive longe do código e fora do ciclo de revisão apodrece por construção. Em três meses ela descreve um sistema que não existe mais, e a partir daí ninguém confia — o que faz todo mundo voltar a perguntar para o especialista.
O que muda o quadro
Isso não se resolve com mais uma ferramenta. Resolve-se instalando, no repositório, o sistema que a IA precisa ler — o que chamamos de Sistema Operacional de Engenharia.
O conhecimento precisa morar junto do código que descreve e passar pela mesma revisão. Decisão técnica vira arquivo versionado com contexto e alternativas descartadas; rotina operacional vira runbook; domínio vira glossário. Quando muda o código, muda no mesmo pull request.
Nesse formato, o conteúdo serve às pessoas e aos agentes ao mesmo tempo. A pergunta que ia para o especialista passa a ter uma fonte, e o onboarding deixa de depender da agenda de quem sabe.
No framework de transformação, isso é o pilar AI Knowledge Layer. A definição completa da categoria está em Sistema Operacional de Engenharia.
Como saber se melhorou
Nenhuma dessas métricas significa alguma coisa sem o valor de partida. O baseline é levantado antes de qualquer mudança, com a janela e a fórmula registradas junto — o método está em métricas.
- Tempo de onboarding
- da entrada ao primeiro pull request aceito em produção
- Tempo para localizar informação
- medido em sessões observadas, por tipo de pergunta
- Tempo médio de revisão de pull request
- medido por revisor — concentração aparece na dispersão, não na média
- Documentação atualizada
- proporção de domínios revisados no trimestre
Por onde se começa
Para este problema, o degrau adequado costuma ser AI-Native Repository Foundation — 4 a 8 semanas, time que já sabe onde dói e quer o sistema instalado em um produto antes de escalar para os outros.
Antes disso, o diagnóstico gratuito já indica se o gargalo é mesmo este. Os outros quatro sintomas estão em problemas.