Commit Briefing: transformando histórico de Git em inteligência de entrega
Como construí um produto que lê commits e PRs de uma equipe e devolve métricas DORA, radar de risco e um resumo executivo escrito por IA — sem a IA inventar um número sequer. A decisão de manter métricas determinísticas e usar LLMs apenas como camada de redação.
Todo time de engenharia já sentou em uma reunião de status onde ninguém sabia responder, com dados, à pergunta mais simples: 'estamos entregando bem?'. O Commit Briefing nasceu dessa lacuna. É uma plataforma de DevOps Intelligence que conecta ao Git da equipe — GitHub ou Azure DevOps — analisa a atividade de commits e PRs de um período e gera um briefing completo: métricas DORA auditáveis, radar de risco operacional, distribuição de esforço e um resumo executivo escrito por um agente de IA.
Mas o produto quase nasceu errado. No primeiro protótipo, cometi o erro mais sedutor de quem começa a programar com LLMs: mandei o log bruto de commits para o modelo e pedi 'calcule o cycle time médio e a frequência de deploy'. O modelo devolveu um texto lindo, com gráficos em markdown e números perfeitamente redondos. Quando fui conferir com uma calculadora, o cycle time real era o dobro do que a IA havia afirmado com tanta certeza. Ela havia simplesmente alucinado uma média plausível para agradar o prompt.
A decisão central: métricas no código, IA na narrativa
LLM é péssimo aritmético e extraordinário redator. Depois do susto da alucinação, inverti a arquitetura por completo: cycle time, tempo de revisão de PR, taxa de falha em deploy e volume de churn são computados de forma puramente determinística em código C# e TypeScript, a partir dos timestamps exatos de commit, abertura de PR e merge. O cálculo é auditável, reproduzível e roda com testes unitários cobrindo cada caso de borda.
O agente de IA só entra no final da esteira. Ele recebe um JSON estruturado com os números já calculados, os deltas em relação à semana anterior e os alertas detectados. O papel dele é contextualizar: transformar números frios em narrativa executiva humana, explicando onde o time encontrou gargalos e sugerindo ações práticas para a próxima sprint. A IA narra o fato; ela é proibida de calcular o dado.
A IA escreve o resumo executivo. Ela nunca calcula o número que vai para a diretoria.
Forge-agnóstico por design: a camada de normalização
Empresas reais não usam apenas uma ferramenta. Uma equipe roda no GitHub, outra no Azure DevOps, e amanhã alguém migra para GitLab. Cada plataforma modela branches, reviews e estados de pull request com estruturas de dados totalmente diferentes. Em vez de espalhar checagens condicionais por toda a aplicação, construí uma camada de normalização.
Essa camada consome a API do forge via webhooks ou polling paginado, traduz tudo para um modelo canônico interno (CommitEvent, PullRequestLifecycle, ReviewThread) e entrega uma interface homogênea para o restante do sistema. O motor de cálculo DORA não faz ideia de onde o commit veio. Se amanhã precisarmos suportar Bitbucket, escrevemos um adaptador de 300 linhas em vez de redesenhar o pipeline.
Radar de risco: o que as métricas de velocidade escondem
Entregar rápido não significa entregar com segurança. Uma equipe pode ter um cycle time invejável de 2 horas simplesmente porque uma única pessoa revisa e aprova tudo sem testes. Por isso, criei o Radar de Risco: três heurísticas determinísticas que cruzam a atividade do Git para acender luzes amarelas antes que virem incidentes.
O primeiro sinal é o Bus Factor: se mais de 60% dos commits de um módulo crítico pertencem a um único desenvolvedor nos últimos 30 dias, o briefing alerta risco de dependência de pessoa-chave. O segundo é o Alerta de Toil: tarefas repetitivas de manutenção e correções manuais de release que deveriam estar automatizadas em esteira. O terceiro é a Concentração em Áreas Sensíveis: arquivos de autenticação, migrações de banco e configurações de segurança recebem pesos maiores e exigem confirmação explícita de cobertura de testes.
n8n e observabilidade da esteira
Para amarrar gatilhos agendados de segunda-feira de manhã, ingestão de dados, chamadas de inferência e disparo de e-mails executivos, adotei o n8n como motor de orquestração. Cada etapa é um nó observável: se a API do GitHub devolver rate limit ou falha temporária, a esteira retenta com backoff exponencial sem travar as análises das outras equipes.
A maior lição que tirei desse produto: a engenharia de um sistema 'com IA' quase nunca é a IA. É a infraestrutura de dados confiável embaixo dela — ingestão normalizada, validação de tipos, métricas matemáticas comprováveis — que faz a inteligência artificial parecer madura em vez de um brinquedo estatístico.