Entrás a un equipo nuevo. El codebase tiene 200.000 líneas. La gente que lo escribió está ocupada, la documentación está desactualizada o directamente no existe, y la arquitectura vive más que nada en la cabeza de alguien. ¿Por dónde empezás?
Vi esta escena repetirse durante veinte años, y la respuesta casi no cambió: leés archivos de a uno, le preguntás a quien te tenga paciencia, y de a poco armás un modelo mental que está equivocado en tres lugares que no vas a descubrir hasta que estés en producción. El costo de ese ramp-up es enorme, y en general hacemos como que no existe porque es difícil ponerlo en una planilla.
Lo interesante es que ahora tenemos agentes de IA en el medio, y tienen exactamente el mismo problema — solo que más rápido. Dale a un agente una función puntual para arreglar y lo hace bien. Preguntale “¿cómo fluye la autenticación a través de este sistema?” y arranca a abrir archivos de a uno, quemando contexto, perdiendo el hilo a mitad de camino. El agente no es malo con el código. Es malo con los codebases. No tiene un mapa.
Understand-Anything es un intento de darles a ambos — al humano y al agente — ese mapa.
Qué hace en concreto
Es un plugin de Claude Code que corre un pipeline multi-agente sobre tu proyecto y construye un knowledge graph de cada archivo, función, clase y dependencia. Después te entrega un dashboard interactivo para explorar todo visualmente. Cada nodo trae un resumen en lenguaje claro de qué hace, qué depende de él, y dónde se ubica en la arquitectura.
La filosofía de diseño está planteada sin vueltas en el proyecto: el objetivo no es un grafo que te impresione con lo complejo que es tu sistema — es uno que te enseñe, sin ruido, cómo encajan las piezas. Esa distinción importa. La mayoría de las herramientas de visualización de código producen una madeja que confirma que el codebase es complicado sin ayudarte a entenderlo. Esta está construida alrededor de la comprensión, no del espectáculo.
El pipeline hace el parsing estructural obvio, pero le suma significado semántico encima: asignación de capas arquitectónicas (API, Service, Data, UI, Utility), descripciones en lenguaje natural, y un set de guided tours — recorridos autogenerados ordenados por dependencia, así aprendés el sistema en el orden que tiene sentido en lugar de alfabéticamente.
Algunas capacidades que vale la pena destacar para quien lo piensa desde una óptica de operación de equipos:
- Onboarding tours. Un grafo commiteado significa que alguien que entra abre un mapa visual de la arquitectura el día uno y hace un recorrido ordenado por dependencias, en vez de grepear a ciegas durante una semana.
- Búsqueda semántica. Preguntás “¿qué partes manejan auth?” en lenguaje natural y obtenés nodos relevantes y rankeados a través del grafo — no una lista de archivos que casualmente contienen el string
auth. - Diff impact analysis. Antes de commitear, ves a qué partes del sistema impactan tus cambios. Esta es la feature que más querría que usaran mis equipos.
- Detalle adaptado al perfil. El dashboard ajusta cuánto te muestra según si te describís como junior dev, PM, o senior engineer.
Corre como plugin nativo de Claude Code pero funciona con Cursor, Codex, GitHub Copilot, Gemini CLI, y una docena de runtimes más — autodetectado a través de archivos de configuración de plugin en la mayoría de los casos. Es MIT-licensed, y a esta altura juntó más de 51.000 stars, con la mayor parte de esa subida ocurriendo hace poco. Ese tipo de curva suele significar que la herramienta tocó un nervio que mucha gente venía sintiendo en silencio.
La trampa que conviene nombrar
Un knowledge graph es una foto. A menos que actives el post-commit hook de auto-update, se desfasa del codebase en el momento en que la gente empieza a mergear. Un equipo que arma un grafo de onboarding y se olvida de regenerarlo antes de un release grande le va a entregar a los nuevos un mapa confiadamente equivocado — que posiblemente sea peor que no tener mapa. Esto no es tanto una falla como una cuestión de disciplina operativa: el grafo es infraestructura, y la infraestructura que nadie mantiene se pudre.
Por qué creo que esto importa
El encuadre que me queda dando vueltas es que la comprensión se está volviendo una capa compartida entre humanos y agentes. Pasamos dos años optimizando cómo los agentes escriben código. Dedicamos mucho menos a cómo entienden el código que ya existe — que, para cualquier empresa más vieja que un fin de semana, es donde vive el trabajo real.
Un mapa persistente, consultable y semánticamente rico de tu sistema no es solo una comodidad de onboarding. Es el sustrato que le permite a un agente responder preguntas arquitectónicas en lugar de estructurales, y es lo que convierte “el conocimiento está en la cabeza de Carlos” en algo que todo el equipo — y sus herramientas — puede consultar. Para una organización de ingeniería que carga con un codebase legacy grande, eso no es un juguete. Es un costo que venís pagando en horas perdidas hace años.
Todavía es temprano. La comunidad está activa, la herramienta evoluciona, y la licencia es lo suficientemente permisiva como para que probarla no te cueste casi nada. Dado hacia dónde apunta, es un experimento fácil de correr.