Analizador CLI: Optimiza tu Codebase Ahora
Un analizador de dependencias CLI indexa el código fuente y genera un grafo completo de cómo los módulos se llaman entre sí, detecta código muerto (funciones que nadie usa), extrae información de git (quién escribió qué cuándo), y genera documentación automática del codebase. Herramientas como GitNexus, Tibo y Repomix ejecutan todo localmente sin servidor, integrables en CI/CD para auditoría continua.
En 30 segundos
- Un analizador CLI escanea tu codebase, mapea dependencias entre módulos, identifica funciones sin usar y genera reportes visuales
- El código muerto ralentiza builds, aumenta la complejidad y el riesgo de seguridad; un repositorio de 50k líneas puede tener 10-20% de código innecesario
- GitNexus, Repowise, Tibo y Repomix son herramientas zero-server que corren en local; algunas integran con MCP, otras ofrecen web UI
- Existen detectores especializados por lenguaje: Vulture (Python), knip (TypeScript), dead-code-detector (PHP), DeadCode (.NET)
- Combinadas con generadores de wiki como Deep Wiki y Open-Deepwiki, estas herramientas automatizan onboarding y auditoría de proyectos heredados
Qué es un analizador de dependencias de codebase
Un analizador de dependencias CLI es una herramienta que ejecutás en tu terminal, apuntás a un directorio, y te devuelve un mapa completo de cómo está estructurado tu código. No es solo leer archivos; estas herramientas construyen un grafo de llamadas (call graph): qué función llama a cuál, qué módulo depende de cuál otro, dónde hay ciclos de dependencia que podrían romperse.
La diferencia con análisis estático tradicional es que vos no necesitás compilar, configurar un servidor, ni tener dependencias raras instaladas. Corrés el comando, te da el reporte en local. Algunos como Repomix directamente preparan tu codebase para pasarle a un LLM (porque, honestamente, prompts que incluyen el codebase entero funcionan mejor si vos controlás qué entra).
Por qué necesitas detectar código muerto
Ponele que configuraste un deploy de tu app hace dos años, y en ese momento tocás una función que “no sabías si se usaba”. Ahora, cada compilación tarda 30 segundos más porque arrastra esa función innecesaria. El bundle es 200KB más grande. Un colega nuevo lee el código y se pierde en llamadas a funciones que no existen en producción (porque se poda en compilación), pero ve en el código como si estuvieran.
Eso es código muerto, y es un problema que crece exponencialmente. Según análisis en repositorios grandes, entre el 10 y 20% del código en proyectos maduros no se ejecuta nunca. Aumenta deuda técnica, ralentiza refactoring, y crea superficies de ataque.
Herramientas CLI principales para análisis de codebase
El mercado de herramientas se está moviendo rápido. Las que despiertan más interés: Ya lo cubrimos antes en GitHub y sus alternativas principales.
GitNexus es probablemente la más completa en este momento. Corre en local, indexa el codebase, genera un grafo de dependencias interactivo, y exporta a formato estándar. Tiene integración con MCP (Model Context Protocol), lo que significa que podés conectarla directamente con Claude o cualquier herramienta compatible.
Repowise se enfoca en análisis de código + inteligencia git. Te muestra quién escribió cada línea, cuándo, y qué cambios hubo. Es útil para entender por qué existen ciertos patrones raros.
Tibo (Codebase Intelligence) es más liviano, pensado para devs que quieren un análisis rápido sin overhead. Genera reportes sobre complejidad, acoplamiento y partes “calientes” del código.
Repomix hace algo diferente: prepara tu repo en un formato estructurado que podés pasarle a un LLM sin que se ahogue. Algunos equipos lo usan de paso previo antes de hacer refactoring asistido por IA.
| Herramienta | Tipo de análisis | Interfaz | MCP | Costo |
|---|---|---|---|---|
| GitNexus | Grafo de dependencias + git intelligence | CLI + Web UI | Sí | Gratuita |
| Repowise | Dependencias + blame + commits | CLI | No | Gratuita |
| Tibo | Complejidad + acoplamiento | CLI | No | Gratuita |
| Repomix | Preparación para LLM | CLI | No | Gratuita |
Detección de código muerto por lenguaje
Dependiendo de qué lenguaje uses, hay herramientas especializadas:
Python
Vulture es el standard. Busca variables, funciones e importes que no se usan. Lo metés en un pre-commit hook y nunca más alguien va a pushear código muerto sin enterarse.
JavaScript / TypeScript
knip es probablemente la mejor herramienta acá ahora. Detecta exports no usados, imports innecesarios, y archivos huérfanos. Para TypeScript específicamente, ts-prune hace un trabajo limpio. Esto se conecta con lo que analizamos en privacidad al compartir código en línea.
PHP
dead-code-detector (github.com/shipmonk-rnd) analiza PHP y devuelve un reporte detallado. Es especialmente útil si tenés un plugin viejo de WordPress que no sabés si alguien está usando.
.NET / C#
DeadCode te muestra métodos, propiedades y tipos que nunca se invocan. Funciona bien en proyectos grandes.
De análisis a acción: generación automática de documentación
Acá viene lo bueno. Una vez que tenés el análisis, podés usarlo para generar documentación automática. Herramientas como Open-Deepwiki y Deep Wiki generan un wiki del codebase: qué módulos existen, cómo se relacionan, qué hace cada componente, cuál es el flow de datos.
Generan diagramas (Mermaid, PlantUML), extraen docstrings, muestran ejemplos de uso. Ponele que tenés un repositorio nuevo en el equipo y querés que los devs junior se orienten rápido: en vez de dejarlos 3 días leyendo código, les das un wiki auto-generado y listo.
Integración en el workflow DevOps
El lugar donde estas herramientas brillan es en CI/CD (ojo con esto, porque muchos equipos lo ignoran). Podés:
- Correr el analizador en cada PR y rechazar cambios que agreguen código muerto (o generar un warning en el comentario automático)
- Ejecutar análisis de dependencias en pre-commit hooks, así el dev se da cuenta antes de pushear
- Generar reportes semanales que muestren tendencias: ¿el codebase está volviéndose más complejo? ¿Hay módulos que quedaron aislados?
- Auditorías de seguridad asistidas: código muerto = superficies de ataque potenciales que nadie monitorea
Si tu infraestructura está en un proveedor como donweb.com, el análisis corre en tu máquina local antes de pushear, así evitás sorpresas en staging o producción.
Casos de uso reales y buenas prácticas
Refactoring de proyectos heredados: Tenés una app que heredaste de hace 5 años, nadie sabe qué funciona y qué no. Correés un analizador, sacás el código muerto de una, y te ahorás semanas de lectura manual. Te puede servir nuestra cobertura de GitHub en tu flujo de desarrollo.
Onboarding de devs juniors: Nuevo dev llega al equipo, le das el wiki auto-generado del proyecto. En lugar de pasarle 50 documentos o dejarla una semana buscando en el código, entiende la estructura en días.
Auditoría de seguridad: Antes de hacer un security audit, eliminás el código muerto. Reducís la superficie de ataque y los auditores pueden enfocarse en lo que realmente importa.
Mejora de performance: Código muerto = peso innecesario. En proyectos frontend donde el bundle size importa, estos analizadores son oro puro.
Errores comunes
1. Confundir “no se llama directamente” con “código muerto”
Una función que no se llama en el codebase actual podría ser parte de una API pública (por ejemplo, si vendés una librería). El analizador te lo marca como muerto, pero vos sabés que es importante. Siempre revisá los resultados manualmente antes de borrar algo.
2. No configurar excepciones
Herramientas como Vulture permiten marcar excepciones: “esta función se ve muerta pero la queremos así”. Si no configurás excepciones, terminás ignorando los reportes porque hay demasiados falsos positivos.
3. Ejecutar análisis una sola vez y olvidarse
Código muerto crece. Si no metés esto en tu CI/CD, en 6 meses volvés a estar en la misma. Integralo en tus chequeos automáticos de cada PR. Lo explicamos a fondo en IA en herramientas de análisis.
4. No considerar dinámico y reflexión
En lenguajes como Python o JavaScript, podés llamar funciones dinámicamente (con `getattr()`, `eval()`, etc.). Los analizadores estáticos no ven eso. Si tu codebase usa mucha reflexión, los reportes van a estar ruidosos.
Preguntas Frecuentes
¿Qué es exactamente un analizador de dependencias CLI?
Un programa que ejecutás en terminal, apuntás a tu proyecto, y te devuelve un análisis de cómo está estructurado: qué módulos llaman a cuáles, qué se usa y qué no. Corre en tu máquina, no necesita servidor.
¿Cuál es la diferencia entre GitNexus y las otras herramientas?
GitNexus es más completa porque combina análisis de dependencias con información de git (quién escribió qué, cuándo) y tiene MCP integrado. Las otras son más livianas pero más especializadas (algunas solo detectan código muerto, otras solo preparan para LLMs).
¿Cuánto tiempo tarda analizar un codebase grande?
Depende del tamaño. Un proyecto de 10k líneas se analiza en segundos. Uno de 500k líneas puede tardar 1-2 minutos. Nada que sea un cuello de botella para CI/CD.
¿Estos analizadores funcionan con todos los lenguajes?
No. Cada lenguaje necesita su propia herramienta porque el análisis es específico de la sintaxis. Por eso existen Vulture para Python, knip para TypeScript, dead-code-detector para PHP. Herramientas genéricas como GitNexus intentan soportar varios pero con diferentes niveles de precisión.
¿Se pueden integrar en GitHub Actions o GitLab CI?
Sí. Son comandos CLI, así que en cualquier pipeline podés agregarlos como un paso más. Algunos generan reportes que parsean herramientas como Codecov o SonarQube.
Conclusión
Los analizadores de dependencias CLI no son un lujo: son una herramienta fundamental para mantener proyectos grandes. Te ahorran tiempo en auditorías, aceleran onboarding, previenen bugs silenciosos de código obsoleto, y reducen deuda técnica.
Si todavía no usás una, empezá por herramienta específica de tu lenguaje (Vulture si programás Python, knip si es TypeScript). Si querés algo más integral que te dé inteligencia sobre git + dependencias + generación de wiki, GitNexus es la apuesta más completa en 2026. Integralo en tu CI/CD, revisá los resultados con criterio (hay falsos positivos), y en poco tiempo tu codebase va a ser más limpio y más fácil de mantener.
