Aller au contenu

Indexation structurelle de codebase : GitNexus vs code-review-graph

Resume

Deux outils open-source attaquent le meme probleme : les agents IA (Claude Code, Cursor) ne connaissent pas la structure du codebase et la devinent depuis le contexte, ce qui cause des regressions quand un fichier a des dependances invisibles. Les deux construisent un graphe de dependances precompile via Tree-sitter et l'exposent via MCP.

Comparaison

GitNexus code-review-graph
Stars 20k non mentionne
Storage LadybugDB (KuzuDB) SQLite
Indexation incrementale non (roadmap) oui (2s / 2900 fichiers)
Blast radius oui, avec scores confiance oui
Outils MCP 7 (query, context, impact, detect_changes, rename, cypher) blast radius + injection contexte
Langages 14 18
Licence PolyForm Noncommercial (bloquant commercial) a verifier
Decorateurs NestJS non (bloquant PV) non mentionne

Analyse critique

L'insight commun est juste : precompiler le graphe de dependances plutot que laisser l'agent le deviner reduit les tokens de 8x et les regressions croisees. C'est l'approche "less reasoning, more knowing".

GitNexus a l'outillage le plus riche (7 outils MCP, detection de communautes Leiden, requetes Cypher directes). Son outil detect_changes (diff git → processus affectes) mappe directement sur l'etape 7 (acceptabilite). Mais la licence PolyForm Noncommercial bloque l'usage commercial sans accord.

code-review-graph a l'avantage de l'indexation incrementale (2s post-commit vs re-indexation complete) et du storage SQLite (zero dependance). Plus leger, plus pragmatique.

Bloquant commun : aucun des deux ne parse les decorateurs NestJS (@Controller, @Injectable). Sans ca, le blast radius sur ProbatioVault-backend est tronque — les injections de dependances sont invisibles au graphe. Un blast radius incomplet est pire qu'aucun blast radius (fausse confiance).

Pertinence ProbatioVault

Impact modere — patterns pertinents, adoption bloquee.

Les agents step 6b travaillent avec uniquement le contexte injecte (spec + plan + contracts). Ils ne savent pas qu'une modification de ProofService.sign() casse AuditService et AnchorWorker. Un graphe structurel donnerait cette visibilite avant generation et reduirait les erreurs TypeScript decouvertes en etape 7.

A reevaluer Q3 2026 quand les decorateurs NestJS seront pris en charge.