Code Health Score: Repowise Coloca Números na Dívida Técnica do Seu Repo
Já mencionamos o Repowise de passagem quando cobrimos a tendência de knowledge graphs para código — apareceu como mais um em uma lista de cinco. Fico pequeno para ele. Repowise não é apenas outra ferramenta que monta um grafo sobre seu repo. É a única dessa lista que faz uma afirmação que as outras nem tentam: que consegue pontuar seu código de 1 a 10 e que essa pontuação realmente prevê onde vão aparecer os bugs.
Vale a pena olhar com detalhes.
O que é Repowise concretamente
pip install repowise, rode repowise init no seu projeto, e constrói cinco coisas ao mesmo tempo:
- Graph — grafo de dependências via tree-sitter em 15 linguagens, resolução de calls, PageRank/centrality
- Git — hotspots (churn × complexidade), % de ownership, coupling oculto via co-change pairs, bus factor
- Docs — uma wiki gerada por LLM por módulo, regenerada incrementalmente em cada commit
- Decisions — architectural decision records extraídos de oito fontes, etiquetados como verified/fuzzy/unverified
- Code Health — 25 biomarkers determinísticos, zero chamadas a LLM, menos de 30 segundos em um repo de 3.000 arquivos
Depois expõe tudo isso para Claude Code, Codex ou qualquer cliente MCP através de nove tools. Essa parte — graph, git, docs, decisions — é em espírito bem parecida com o que já vimos com codebase-memory-mcp e Context7. A camada de Code Health é onde Repowise está fazendo algo que ninguém mais nesse espaço está fazendo.
A parte que sim é nova: um score validado contra defeitos reais
A maioria das ferramentas de “code quality score” — e tem muitas — ajustam seus pesos manualmente, conforme o que lhes parece razoável. A proposta do Repowise é distinta: os pesos por trás de seus 25 biomarkers (McCabe complexity, deep nesting, brain methods, coesão LCOM4, god classes, clone detection, untested hotspots, churn, ownership dispersion, e mais) estão calibrados contra um corpus histórico real de defeitos, não escolhidos manualmente.
Para ser claro sobre o que isso significa: é um benchmark próprio do Repowise, publicado em seu repo repowise-bench com metodologia e intervalos de confiança inclusos — não uma auditoria independente de terceiros. Vale a pena testar no seu próprio repo antes de tomar os números como verdade revelada, mas pelo menos a metodologia é transparente o suficiente para poder revisá-la.
Isso é o que reportam, medido sobre os mesmos 2.770 arquivos em 9 linguagens, no mesmo commit, contra as mesmas tags de defeitos, comparado cara a cara contra uma “ferramenta comercial líder” que não nomeiam:
| Eixo (paired tests) | Repowise | Ferramenta comercial |
|---|---|---|
| Recall @ 20% do orçamento de linhas | 0,173 | 0,074 |
| Ranking effort-aware (Popt) | 0,607 | 0,462 |
| Densidade de defeitos (ratio Alert:Healthy) | 2,18× | 0,56× |
| Discriminação (ROC AUC) | 0,731 | 0,705 |
Separadamente, em 21 repos open-source que cobrem as nove linguagens “Full tier”, reportam um ROC AUC médio cross-project de 0,74 (IC 95%: 0,68–0,79) para identificar quais arquivos terminam recebendo bug fixes nos seis meses seguintes — sem data leakage, já que os health scores ficam fixados em um commit histórico e os resultados são medidos depois. Também reportam que o score se sustenta mesmo quando controlam por tamanho de arquivo (não é só “marque os arquivos maiores”) e que aguenta em um dataset externo publicado (PROMISE/jEdit) sobre o qual nunca foi ajustado.
Auto-reportado, sim. Mas é o tipo de afirmação auto-reportada que vem com um documento de metodologia em anexo, o que já o coloca um degrau acima do típico gráfico de marketing.
Colocando em funcionamento
pip install repowise # ou: uv tool install repowise
cd seu-projeto
repowise init # constrói as cinco camadas — uma única vez
repowise serve # levanta o MCP server + dashboard local
As camadas de graph, git, dead-code e health são construídas em minutos sem nenhuma chamada a LLM — com repowise init --index-only você tem um índice consultável quase instantaneamente. O único lento é a camada de geração de docs, que você pode deixar rodando em background. Depois do índice inicial, cada atualização disparada por um commit leva menos de 30 segundos.
Se você trabalha especificamente com Claude Code, pode pular a configuração manual:
/plugin marketplace add repowise-dev/repowise
/plugin install repowise@repowise
Isso registra o MCP server, instala o hook, e adiciona os slash commands /repowise:* (init, health, risk, dead-code, decision, …).
Para o health score especificamente, uma vez indexado:
repowise health # KPIs + arquivos com pior pontuação
repowise health --coverage cov.lcov # ingestão LCOV/Cobertura/Clover → detecção de untested-hotspots
repowise health --refactoring-targets # ranking por impacto/esforço
repowise health --trend # snapshots + alertas de declínio/declínio previsto
As nove MCP tools
A maioria das tools de código para MCP estão montadas em torno de entidades individuais — um arquivo, um símbolo — o que força seu agente a encadear uma dúzia de chamadas. As tools do Repowise estão montadas em torno de tarefas: você passa múltiplos targets e recebe contexto completo em um único round-trip.
| Tool | Para quê serve |
|---|---|
get_overview() |
Resumo de arquitetura, mapa de módulos, entry points — a primeira chamada em qualquer repo desconhecido |
get_answer(question) |
Retrieval híbrido + expansão de grafo → uma resposta citada com score de confiança |
get_context(targets, include?) |
Ficha de contexto por arquivo/módulo/símbolo — lote de vários targets ao mesmo tempo |
get_symbol("file.py::Name") |
Código-fonte bruto de um símbolo, com limites de linha exatos |
search_codebase(query, kind?) |
Busca semântica filtrável por implementation/test/config/doc |
get_risk(targets, changed_files?) |
Hotspot scores, dependentes, co-change partners — com modo PR incluído |
get_why(query?, targets?) |
Architectural decision records + cadeia de supersession |
get_dead_code(...) |
Código inalcançável por nível de confiança |
get_health(targets?, include?) |
O score de 25 biomarkers, por arquivo ou em nível de dashboard |
Seu exemplo de referência — adicionar rate limiting a todos os endpoints de uma API — afirma 5 chamadas de tool em vez de uns 30 greps-e-reads. Isso está alinhado com o padrão geral de “índice estruturado vence a exploração arquivo por arquivo” que vimos em quase todas essas ferramentas, incluindo a redução de ~70% em tool calls e ~89% menos file reads que Repowise reporta em seus próprios benchmarks de eficiência de agente.
Onde fica posicionado frente às alternativas
Repowise é self-hostable (AGPL-3.0), não precisa de nuvem, e é BYOK para as chamadas a LLM que sim faz (a geração de docs). Comparado com DeepWiki, Swimm e CodeScene — os pontos de comparação mais próximos — é o único que combina inteligência de comportamento via git, um health score validado contra defeitos, docs auto-geradas, tools MCP-native e rastreamento de decisões arquitetônicas em um único pacote self-hosted. CodeScene é o análogo mais próximo do lado do health score, mas não é MCP-native e não faz decisões arquitetônicas nem docs auto-geradas.
Também há uma versão hosted (repowise.dev) para times que não querem rodá-lo eles mesmos, mais um PR bot gratuito do GitHub que comenta hotspots e declínio de health por PR sem nenhuma chamada a LLM.
Vale a pena?
Se você já está convencido da proposta de “dar ao seu agente um mapa persistente em vez de fazer com que ele reexplore seu repositório a cada sessão” que vimos com codebase-memory-mcp, o Repowise faz o mesmo e adiciona uma camada genuinamente diferenciada em cima — uma que tenta responder “quais arquivos realmente vão quebrar” em vez de apenas “quais arquivos estão relacionados”. Essa é uma afirmação mais difícil de sustentar e mais difícil de fingir. Vale a pena apontá-lo para seu próprio repositório e comparar os arquivos com pior pontuação de repowise health contra seus últimos seis meses de commits de correções de bugs — esse é o teste que realmente importa aqui, mais do que qualquer gráfico em seu README.
Você já testou no seu próprio repositório, ou fica com o knowledge graph puro por enquanto? Conte-nos como o health score previu bem seus problemas reais ![]()