CXCAP, un CLI en Rust que audita la complejidad del repo antes del cambio
La herramienta es local, de solo lectura y con licencia MIT: mapea hotspots y acoplamiento antes de que un agente de código toque el siguiente cambio.
El agente de código pasó todos los tests. Y aun así hizo más difícil el siguiente cambio. Esa es la tesis de CXCAP, un CLI local y de solo lectura que audita la complejidad estructural de un repositorio antes de que nadie lo toque. Está en el repositorio con licencia MIT y se instala con un cargo install cxcap. No usa índice, fichero de configuración, demonio, modelo ni cuenta en la nube.
La pregunta que intenta responder no es la de los tests. Un bucle de agente habitual —tarea, inspección del contexto local, implementar, probar, corregir, entregar, siguiente tarea— puede encadenar éxitos en cada paso mientras el repositorio acumula acoplamiento, ramas, comportamiento duplicado, módulos más grandes y exposición transitiva. Cada cambio parece razonable por separado; el problema es la suma.
Qué hace
Tres comandos cubren el flujo:
cxcap audit .
cxcap audit . --intent "add session expiry"
cxcap audit . --focus src/auth
El primero localiza complejidad, hotspots y ciclos. El segundo admite una tarea descrita en lenguaje natural cuando aún no sabes qué ficheros vas a tocar. El tercero parte de un fichero o directorio concreto y calcula quién depende de él y hasta dónde llega. Con --json el informe se puede pasar a un agente como evidencia estructurada.
Cada ejecución devuelve un veredicto: LOW, MODERATE, HIGH o SEVERE. El autor insiste en que no es una nota de calidad: un sistema maduro y bien diseñado puede salir SEVERE sin problema. N/A aparece cuando el repo está dominado por lenguajes que la herramienta no puntúa.
Las limitaciones están escritas de entrada. El análisis estático es incompleto por construcción: imports en tiempo de ejecución, reflexión, registros, inyección de dependencias y sistemas de plugins pueden ser invisibles, y la propia herramienta marca esos casos como [dynamic-lookup]. --intent es descubrimiento, no omnisciencia, y no predice esfuerzo. Como calibración, el README cita una validación histórica sobre 31 cambios completados en 7 repositorios: Recall@10 de 0,70 y MRR de 0,47.
El ejemplo y el contexto
Sobre un repositorio sintético de 83 ficheros en Python y TypeScript, la tarea "change currency rounding" devolvió 3 puntos de contacto probables y una superficie de razonamiento de 15 ficheros repartidos en 5 componentes. El fichero que sorprendía era core/money.py, un helper de 42 líneas que resulta ser el segundo hotspot del repo: con el 2,6% de su complejidad, lo importan 23 ficheros externos y alcanza otros 19 de forma transitiva, 42 ficheros expuestos entre auth, billing, notifications, API y workers. Todos esos números salen de ejecuciones reales de la versión 1.0.2, según el autor.
El respaldo externo que cita apunta en la misma dirección. GitClear, sobre 623 millones de cambios de código del periodo de adopción de IA, reporta subidas de duplicación de bloques (+81%), copia/pega dentro de un commit (+41%) y construcciones que enmascaran errores (+47%), junto a caídas del movimiento de líneas por refactorización (−70%) y del mantenimiento de legado a largo plazo (−74%). Son sus cifras.
El argumento económico está acotado a propósito: no promete un ahorro porcentual en la factura de IA. Lo que sostiene es un mecanismo. Un repositorio más enrevesado obliga al agente a inspeccionar más ficheros, ingerir más contexto, hacer más llamadas a herramientas y reintentar más enfoques. Como las plataformas cobran por tokens, modelo y contexto, esa complejidad acaba siendo coste recurrente. La frase con la que el autor lo resume: la salida del agente de hoy es el contexto del agente de mañana.
