Graphify a prueba: Un índice de grafo de conocimiento para Claude Code
Casi descarto Graphify como otro juguete con sabor a npx.
La propuesta sonaba demasiado perfecta: "apúntalo a cualquier carpeta, obtén un grafo de conocimiento, consulta el grafo en vez de releer archivos, y observa cómo tu consumo de tokens se desploma." Tengo un reflejo saludable ante cualquier cosa que promete una reducción de costes de un orden de magnitud con un solo comando. La mayoría de las veces, las cuentas cuadran para la demo y se desmoronan en una codebase real.
Entonces lo ejecuté en un proyecto con el que llevaba un mes peleando — un repositorio de agencia con siete módulos de aplicación, una maraña de servicios compartidos y una carpeta docs/ que había estado evitando silenciosamente. La primera compilación tardó menos de tres minutos en mi MacBook. El grafo que generó me reveló algo sobre mi propia arquitectura que había pasado por alto durante medio año — una dependencia circular entre la lógica de facturación y un servicio de notificaciones que nunca deberían haberse conocido.
Ese fue el momento en que dejé de tratar Graphify como un truco para ahorrar tokens y empecé a tratarlo como una herramienta de revisión de código que, además, ahorra tokens.
Este artículo resume lo que aprendí al ejecutarlo en tres codebases reales — qué hace realmente, cómo es la instalación de verdad, dónde las cuentas de tokens son honestas, dónde son marketing, y qué workflows cambió para mí. Un análisis honesto, no un comunicado de prensa. Si eres un usuario de Claude Code que ve constantemente cómo /cost sube cada vez que preguntas sobre un repositorio desconocido, los próximos veinte minutos podrían ser lo más útil que leas esta semana.
El problema que Graphify realmente resuelve
Este es el workflow en el que la mayoría estamos atrapados.
Abres Claude Code dentro de un repositorio que no conoces de memoria. Haces una pregunta — "¿dónde se valida este user_id?" o "¿qué servicios tocan el módulo de facturación?" o simplemente "explícame cómo está estructurada esta app." Claude empieza a leer archivos. Lee el archivo que mencionaste. Luego el archivo que ese archivo importa. Luego el archivo que importa el archivo que importa el archivo. Veinte llamadas a herramientas después, tienes una respuesta y una ventana de contexto al 70% de capacidad antes de haber escrito una sola línea de código.
Esto es el impuesto de tokens. Cada conversación lo paga. Cada vez que inicias una nueva sesión, lo pagas de nuevo. Cada vez que compactas el contexto, lo pagas de nuevo. La codebase no cambia entre martes y jueves, pero tu agente la relee desde cero cada vez.
La búsqueda semántica — grep, ripgrep, embeddings vectoriales — araña el problema pero no lo resuelve. grep encuentra cadenas de texto, no conceptos. Los embeddings encuentran párrafos que se parecen a tu consulta, no las relaciones estructurales que tu código realmente tiene. Ninguno captura la respuesta a "¿qué funciones acaba llamando RateLimiter, tres niveles de profundidad?" porque esa respuesta no está en ningún archivo individual. Vive en el grafo entre archivos.
La apuesta de Graphify es que deberías construir ese grafo una vez, almacenarlo junto a tu repositorio, y dejar que tu agente consulte el grafo en lugar de rastrear el código fuente cada vez. El grafo ocupa aproximadamente dos megabytes de JSON. Tu carpeta de código fuente puede ocupar cientos de megabytes. El agente lee el grafo y recurre a archivos sin procesar solo cuando realmente necesita escribir o modificar código.
Si ya has hecho investigación asistida por IA en codebases grandes, ya sabes por qué esta apuesta es interesante. El resto de este artículo trata sobre si rinde en la práctica.
La idea central: Un grafo como índice
Antes del tutorial de instalación, quiero asegurarme de que tienes el modelo mental correcto. La mayoría de los artículos sobre Graphify saltan esta parte, y es la parte que determina si la herramienta será útil para tu repositorio.
Un grafo de conocimiento son solo dos cosas: nodos (las entidades — funciones, clases, módulos, secciones de documentación, conceptos) y aristas (las relaciones — llama a, importa, hereda de, depende de, referencia, es similar a). Graphify construye ambos: de forma determinista para el código y semántica para la documentación.
Para el código, usa tree-sitter para parsear tu código fuente en ASTs y extraer las relaciones estructurales sin enviar jamás un solo token a un LLM. Esa parte es rápida, gratuita y exacta. Tree-sitter sabe que función A llama a función B porque la sintaxis lo dice — no se requiere inferencia.
Para documentación, PDFs, markdown e imágenes, Graphify usa un LLM (a tu elección — Claude, GPT, Gemini, Kimi, DeepSeek, Ollama local) para extraer entidades e inferir relaciones. Esa parte es más lenta y cuesta tokens por adelantado — una vez, durante la compilación. Después, el grafo persiste. Pagas el coste de extracción la primera vez y lo amortizas a lo largo de cada consulta durante semanas.
Luego ejecuta Leiden community detection en el grafo combinado. Leiden es un algoritmo de clustering que agrupa nodos densamente conectados en comunidades — básicamente preguntando "¿qué partes de este grafo se juntan?" El resultado es la estructura modular natural de tu repositorio, derivada de cómo el código realmente se conecta, no de cómo las carpetas resultan estar organizadas. A veces esas dos estructuras coinciden. A veces se contradicen violentamente, y esa contradicción es la señal más interesante de toda la compilación.
Cuando consultas el grafo, tu agente recorre aristas en lugar de leer archivos fuente. "Muéstrame el flujo de autenticación" se convierte en un recorrido del grafo que devuelve quizás tres mil tokens de nodos y aristas estructurados, en lugar de cincuenta mil tokens de código fuente en bruto. Esa es la compresión. Ahí es donde viven los ahorros.
La trampa — y volveremos a esto — es que las consultas al grafo son geniales para leer tu codebase y terribles para escribir en ella. Cuando necesitas modificar código, sigues necesitando el archivo sin procesar. Graphify no reemplaza tu carpeta de código fuente; reemplaza tu exploración de tu carpeta de código fuente.
Instalación: Cómo se ve realmente en 2026
El repositorio está en github.com/safishamsi/graphify. Hay una peculiaridad que conviene conocer de antemano: el nombre del paquete en PyPI es graphifyy con doble y mientras se reclama el nombre original, pero el comando CLI sigue siendo graphify. El README lo explica abiertamente — no dejes que te confunda.
Graphify necesita Python 3.10 o superior. Si ya estás en un stack moderno, no hay problema. Si sigues en 3.9, este es tu empujón para actualizar.
Yo instalo herramientas Python con uv hoy en día porque es la única herramienta de Python que no me hace querer escribirlo todo en Rust. El único comando que te da una instalación funcional es:
uv tool install graphifyy
Eso pone graphify en tu PATH automáticamente — sin malabares con venvs, sin ceremonias con pipx. Si prefieres pipx, también funciona:
pipx install graphifyy
Y si eres un masoquista y quieres pip puro:
pip install graphifyy
…necesitarás asegurarte de que ~/.local/bin (Linux) o ~/Library/Python/3.x/bin (Mac) está en tu PATH, o invocarlo como python -m graphify. Recomiendo uv o pipx — no hay ventaja en pelear con PATH para una herramienta CLI.
Verifica que está ahí:
graphify --version
Si obtienes una cadena de versión, has terminado con la instalación. Tiempo total en mi máquina: menos de treinta segundos.
Registrar Graphify como un skill de Claude Code
Esta es la parte que realmente hace que Graphify sea útil dentro de tu agente. El CLI está bien. El registro del skill es el momento en que Claude Code deja de pedirte que ejecutes graphify manualmente y empieza a usarlo por sí mismo cuando necesita explorar un repositorio.
Ejecuta:
graphify install
Ese único comando hace tres cosas. Copia el manifiesto de skill específico de la plataforma en ~/.claude/skills/graphify/ para que Claude Code pueda descubrirlo. Actualiza (o crea) tu CLAUDE.md del proyecto con instrucciones para que el asistente recurra a graphify query antes de caer en la lectura de archivos sin procesar. Y registra los comandos slash — /graphify query, /graphify path, /graphify explain — que invocarás directamente cuando quieras dirigir las consultas tú mismo.
Si estás usando Codex, OpenCode, Cursor, Gemini CLI o cualquiera de los otros diez-plus asistentes que Graphify soporta, el mismo comando graphify install autodetecta la mayoría de ellos y escribe el manifiesto correcto en el lugar correcto. El README tiene una matriz completa. Si estás en Windows o quieres ser explícito, puedes pasar --platform claude o --platform codex y forzar el objetivo.
Después de ejecutar graphify install, la prueba de cordura correcta es abrir Claude Code, escribir / y buscar los comandos graphify en el selector. Si están ahí, el skill se registró correctamente. Si no, verifica que ~/.claude/skills/graphify/ existe y tiene un SKILL.md dentro — ese es el archivo que Claude Code lee al inicio.
Este es el mismo patrón de carga de skills que cubrí en mi guía de skills avanzados de Claude Code, y se está convirtiendo en el patrón de integración dominante en el ecosistema. Los skills, no los servidores MCP, son lo que la mayoría del tooling valioso está distribuyendo en 2026.
Construir tu primer grafo
Ahora viene la parte interesante. Desde dentro del repositorio que quieres indexar, ejecuta:
graphify build
Eso es todo. La configuración por defecto te dará un grafo funcional. Graphify escanea la carpeta, pasa los archivos de código a tree-sitter para extracción de AST, pasa la documentación y otros archivos a tu LLM configurado para extracción semántica, ejecuta Leiden community detection y escribe el resultado en un directorio graphify-out/.
Pero casi siempre querrás ser más deliberado que los valores por defecto. Los flags que más uso:
--mode deep— ejecuta una pasada de extracción semántica más agresiva sobre documentación y comentarios. Cuesta más tokens por adelantado, pero encuentra más aristas conceptuales (las que no aparecen en el AST).--update— reconstrucción incremental. Solo reprocesa archivos cuyo SHA256 cambió desde la última ejecución. Este es el flag que usarás el 95% del tiempo después de la compilación inicial.--cluster-only— re-ejecuta Leiden community detection en el grafo existente sin re-extraer nada. Útil cuando has añadido nuevas aristas manuales o ajustado parámetros de clustering y quieres ver el efecto.--no-viz— omite la salida HTML interactiva. Compilaciones más rápidas, salida más ligera. Úsalo cuando solo necesitasgraph.jsonpara un agente y no quieres ver la visualización.--watch— mantiene Graphify ejecutándose y re-extrae archivos modificados al guardar. No uso esto en desarrollo normal porque quiero un grafo estable, pero es útil cuando estás remodelando activamente la arquitectura y quieres ver el clustering cambiar en tiempo real.
Para el repositorio de agencia que mencioné, la primera compilación fue un graphify build --mode deep y tardó unos dos minutos y cuarenta segundos en una codebase de diez mil archivos. El coste de tokens para la extracción semántica con LLM fue modesto — menos de un dólar de gasto en API al precio de Sonnet — porque tree-sitter manejó la mayor parte del trabajo estructural sin intervención de LLM. Las ejecuciones subsiguientes de graphify build --update después de commits pequeños terminaron en menos de quince segundos.
Una nota sobre el alcance de la extracción. Graphify soporta modos de solo-código, código+documentación y multimodal completo (el modo multimodal accede a PDFs, imágenes e incluso transcripciones de video si has instalado las dependencias opcionales). Para un repositorio de aplicación típico lo mantengo en código+documentación. El modo multimodal completo es genuinamente útil cuando tu carpeta docs/ tiene diagramas de arquitectura como PNGs y quieres extraer el contenido visual — pero cuesta tokens y tiempo, así que actívalo solo cuando realmente tengas ese tipo de material.
Qué es realmente la salida
Cuando graphify build termina, tendrás un directorio graphify-out/ con tres archivos principales importantes:
graph.html — una visualización interactiva que abres en tu navegador. Los nodos están dimensionados por pertenencia a comunidad y conectividad. Las aristas están coloreadas por tipo de relación. Puedes filtrar por comunidad, por tipo de archivo, por tipo de relación, y puedes hacer clic en cualquier nodo para ver sus vecinos y leer el código fuente original. Este es el archivo que muestras a tu equipo en una reunión. También es el archivo que reveló mi dependencia circular — literalmente podía ver el bucle dibujado en la pantalla.
graph.json — el grafo legible por máquinas. Esto es lo que tu agente lee cuando responde preguntas. Aproximadamente dos megabytes para un repositorio mediano. JSON estructurado de nodos y aristas que cualquier herramienta puede parsear. Este es el archivo que hace el verdadero trabajo de ahorro de tokens.
GRAPH_REPORT.md — un informe de auditoría en texto plano. Lista tus "nodos dios" (los archivos altamente conectados que tocan todo — usualmente una señal de que tienes un olor arquitectónico), conexiones inesperadas que el LLM notó y que no aparecen en ningún archivo individual, y un conjunto de preguntas sugeridas que podrías querer hacerle al grafo. La primera vez que leí uno de estos, fue como recibir las notas de incorporación de un ingeniero senior sobre mi propia codebase.
También hay un directorio cache/ con hashes SHA256 por archivo. Así es como --update sabe qué archivos realmente cambiaron — es un hash de contenido, no una marca de tiempo, por lo que los archivos renombrados-pero-sin-cambios no activan re-extracción.
Una consulta real, con formato de salida real
La forma más limpia de mostrar cómo se sienten las consultas es ejecutar una. Desde el CLI:
graphify query "¿qué conecta la capa de autenticación con la base de datos?"
O, si has registrado el skill, lo mismo dentro de Claude Code:
/graphify query "¿qué conecta la capa de autenticación con la base de datos?"
Lo que vuelve es un subgrafo — una respuesta estructurada que lista los nodos relevantes (el middleware de autenticación, el servicio de sesión de usuario, el pool de conexiones, el repositorio de usuario) y las aristas entre ellos (qué funciones llaman a cuáles, qué módulos importan cuáles, qué documentación referencia qué concepto). En un corpus de quinientas mil palabras, una consulta así típicamente devuelve unos miles de tokens, donde leer los mismos archivos en bruto habría costado cientos de miles.
Los otros dos comandos que vale la pena memorizar:
graphify path "UserService" "DatabasePool"
Eso devuelve el camino más corto entre dos entidades nombradas — la cadena real de llamadas a funciones o imports de módulos que las conecta. Esta es la consulta que te da análisis de impacto gratis. "Si cambio UserService, ¿por qué caminos se propaga ese cambio?" Tres comandos, una respuesta.
Y:
graphify explain "RateLimiter"
Eso devuelve un resumen en lenguaje natural de un nodo — qué hace, qué lo llama, qué llama él, con qué conceptos está agrupado en la salida de Leiden. Es la consulta "¿qué es esta cosa?". Lo primero que ejecuto cuando me dejan en un repositorio desconocido.
Hay patrones de consulta más ricos — expansión de vecindario, consultas con alcance de comunidad, búsqueda semántica en el subgrafo de documentación — y el README los recorre. Pero estos tres (query, path, explain) son los que uso a diario.
Actualizaciones incrementales: Mantener el grafo actualizado
El problema de la actualización es la objeción obvia: "mi código cambia todos los días, ¿voy a reconstruir esto cada mañana?"
No. Vas a ejecutar:
graphify build --update
…y solo re-extraerá los archivos cuyo hash de contenido cambió desde la última compilación, los fusionará en el grafo existente y re-ejecutará el clustering. En un repositorio de diez mil archivos con un puñado de archivos cambiados, esto tarda segundos, no minutos.
Mejor aún, Graphify puede instalar hooks de git que activan una actualización incremental automáticamente al hacer commit o checkout. Tengo esto habilitado en mi repositorio principal de trabajo. Cada vez que hago push, el grafo se actualiza. Cada vez que cambio de rama, el grafo refleja la estructura de la nueva rama. Ya no pienso en la actualización.
Si has seguido mi serie de optimización de tokens, reconocerás este patrón: adelantar el trabajo costoso, cachearlo y recurrir al caché durante las sesiones interactivas. Graphify es simplemente una implementación inusualmente limpia de esa idea.
Extensiones que vale la pena conocer
Algunos flags de extensión llevan a Graphify más allá de "herramienta de inteligencia de código" hacia algo más interesante.
--obsidian genera un vault completo de Obsidian desde tu grafo. Cada nodo se convierte en una nota markdown. Cada arista se convierte en un backlink. Abres Obsidian, lo apuntas al vault generado, y tienes un wiki navegable de tu codebase que se actualiza cada vez que re-extraes. Este es el workflow que mapea directamente a la idea del Wiki LLM de Karpathy — profundicé en ese patrón en mi análisis del Karpathy Obsidian RAG, y Graphify es la implementación más limpia que he usado específicamente para codebases.
--neo4j exporta un archivo cypher.txt que puedes reproducir en una instancia de Neo4j. Si estás construyendo un pipeline RAG que necesita recorrido real de grafos — razonamiento multi-hop, caminos ponderados, consultas Cypher reales — esta es tu conexión. Construye el grafo con Graphify, persístelo en Neo4j, consúltalo desde tu aplicación. Lo he usado exactamente una vez, para un cliente que necesitaba un almacén de grafos de nivel empresarial, y funcionó a la primera.
--mcp inicia Graphify como servidor MCP stdio. Si tienes un setup donde múltiples agentes necesitan compartir el mismo índice de grafos, MCP es el límite correcto — tu grafo se convierte en un servicio, y cualquier cliente compatible con MCP puede consultarlo. Cubrí la tensión más amplia entre MCP y skills en mi artículo sobre si MCP está muriendo; el modo MCP de Graphify es uno de los casos donde MCP todavía tiene sentido, porque el grafo genuinamente es un recurso compartido.
La exportación a Obsidian es la que más me sorprendió. El grafo se convierte en un artefacto navegable — algo que lees, algo a lo que enlazas, algo que commiteas en un repositorio wiki. Deja de ser una táctica de optimización de tokens y empieza a ser documentación que se mantiene sola.
Las cuentas honestas de tokens
Esta es la parte donde la mayoría de los artículos se quedan callados. Déjame ser específico.
El gran número que circula en el material de marketing es "71,5 veces menos tokens por consulta." Ese número es real — proviene de una ejecución de benchmark en un corpus mixto que incluye PDFs, imágenes y transcripciones de video. Los corpus multimodales inflan dramáticamente el recuento de tokens de la línea base en bruto (no lees PDFs barato; pagas por convertirlos y reconvertirlos). La compresión que Graphify proporciona en ese tipo de corpus es genuinamente enorme.
En un repositorio de código puro — que es lo que la mayoría de vosotros realmente tiene — la compresión realista es más cercana a 5x a 10x para consultas típicas de "explora esta codebase". Eso sigue siendo sustancial. Una consulta que habría consumido cincuenta mil tokens de lecturas de archivos en bruto podría consumir de cinco a diez mil contra el grafo. A lo largo de un día de trabajo, eso es dinero real. A lo largo de un mes de trabajo en un plan de API de pago, es la diferencia entre quedarte en Sonnet para todo y preocuparte constantemente por los costes de Opus.
Pero los ahorros no son uniformes. Aquí es donde Graphify realmente gana y donde no.
Donde gana a lo grande: Incorporación a un repositorio que nunca has visto. Análisis de impacto en un refactoring. Preguntas transversales como "cada lugar donde llamamos a Stripe." Revisión de arquitectura. Cualquier cosa donde intentas entender relaciones estructurales en lugar de leer código específico.
Donde no ayuda: Escribir código nuevo. Modificar funciones existentes. Depurar un mensaje de error específico. Cualquier cosa donde necesitas el contenido fuente real, no el resumen estructural. Para esos workflows, tu agente sigue necesitando leer archivos sin procesar — el grafo le dice qué archivos leer, pero no reemplaza la lectura en sí.
Esta es la parte donde quiero ser enfático porque veo gente exagerando. Graphify no es un reemplazo para tu codebase. Es un índice sobre tu codebase. Los índices son increíbles para consultas. No son lo que editas. Trátalo en consecuencia y obtendrás mucho valor. Trátalo como una bala de plata y te confundirás cuando tu sesión de refactoring siga quemando tokens.
Qué cambió en mi workflow
Después de tres semanas ejecutándolo en mis propios repositorios y dos codebases de clientes, aquí es donde Graphify terminó en mi kit de herramientas real.
Incorporación a un nuevo repositorio. El primer comando en un clone fresco ahora es graphify build --mode deep. En tres minutos tengo un grafo y un GRAPH_REPORT.md. Leo el informe. Abro el HTML. Le pido a mi agente /graphify explain para los tres nodos más conectados. Al final de quince minutos tengo un mejor modelo mental del que obtendría con una hora de exploración basada en grep. Solo este workflow ya ha amortizado el tiempo que invertí aprendiendo Graphify.
Auditorías cross-repositorio. Cuando un cliente pregunta "¿esto realmente usa la biblioteca por la que estamos pagando?" — ejecuto Graphify, consulto el grafo por los puntos de entrada principales de la biblioteca y leo la respuesta. Antes esto era una revisión de código manual de cuarenta minutos. Ahora son cinco minutos.
Análisis de impacto pre-refactoring. Antes de tocar una función que espero que sea de carga, ejecuto graphify path "<nombre-función>" "<cosa-distante>" para ver qué depende de qué. La salida de camino más corto captura las dependencias que habría pasado por alto.
Frescura de la documentación. Genero el vault de Obsidian desde el grafo y lo commiteo. La documentación ahora es un derivado del código, no un artefacto separado que se desvía. Cuando el código cambia, el vault cambia. Cuando abro Obsidian para escribir un nuevo artículo, puedo enlazar directamente a los nodos de la codebase que estoy describiendo.
Donde sigo recurriendo a grep. Cuando sé exactamente lo que busco — una cadena específica, un mensaje de error, una clave de configuración — grep sigue siendo más rápido que cualquier consulta al grafo. Graphify se gana su lugar en preguntas donde aún no sé qué greppear. Es la herramienta de qué debería estar buscando, no la herramienta de ya sé lo que busco.
Donde sigo recurriendo a un sub-agente. Cuando la pregunta es abierta y creativa — "¿hay una mejor arquitectura para esto?" — un sub-agente de planificación con una ventana de contexto larga sigue ganando. Graphify le da al sub-agente mejor contexto inicial (más pequeño, más denso, consciente de la estructura), pero el razonamiento tiene que ocurrir a nivel del modelo.
Esta combinación — grafo para estructura, grep para cadenas, sub-agentes para razonamiento — se ha potenciado de una forma que no esperaba. No son herramientas que compiten. Son un stack. El grafo le dice al sub-agente qué archivos importan. Grep le dice al agente dónde en esos archivos mirar. El agente hace el razonamiento. Cada capa alimenta la siguiente.
Si quieres el patrón más amplio sobre apilar herramientas así, mi recorrido por el stack de skills de Claude Code cubre la meta-arquitectura que ahora uso por defecto.
Donde Graphify falla
Te debo la lista honesta de modos de fallo, porque los que he experimentado no son teóricos.
Los repositorios muy pequeños no lo necesitan. Si tu codebase cabe cómodamente en la ventana de contexto de Claude, construir un grafo es excesivo. El punto de equilibrio en mis pruebas estaba en algún lugar alrededor de veinte mil líneas de código o cincuenta-plus documentos markdown. Más pequeño que eso, los costes de compilación superan los ahorros en consultas.
Lenguajes con cobertura débil de tree-sitter. La extracción estructural es tan buena como la gramática de tree-sitter para tu lenguaje. Los principales — Python, TypeScript, JavaScript, Go, Rust, Java, PHP — son excelentes. Lenguajes más exóticos pueden producir grafos más delgados, con menos aristas de llamada capturadas. Prueba con tu stack antes de depender de ello.
Repositorios pesados en documentación con prosa no estructurada. La extracción con LLM para documentación es sensible a cómo está estructurada la prosa. Encabezados limpios, nombres de entidad claros y terminología consistente producen grafos excelentes. Volcados de wiki tipo flujo de consciencia producen unos más ruidosos. Esto es solucionable — reestructura la documentación, ejecútalo de nuevo — pero no es magia.
Costes de tokens en la compilación inicial para corpus multimodales muy grandes. Si apuntas Graphify a una carpeta de cincuenta gigabytes de PDFs y videos, la primera compilación no será gratuita. Será de una sola vez, pero no será gratuita. Planifica para eso. Para repositorios de código puro, esto no es un problema.
La precisión semántica depende del modelo. La calidad de las aristas generadas por LLM depende de qué modelo hayas configurado. Claude Sonnet, GPT y Gemini producen resultados sólidos en mis pruebas. Modelos locales más pequeños producen grafos más delgados y ruidosos. No hay benchmarks publicados de precisión-recall para la extracción semántica — trata las aristas inferidas como sugerencias, no como verdad absoluta.
Ninguno de estos es un factor decisivo. Pero todos valen la pena conocerlos antes de apostar un workflow en la herramienta.
¿Deberías instalarlo?
Aquí está mi árbol de decisión, destilado de tres semanas de uso diario.
Instala Graphify hoy si: Eres un usuario de Claude Code, Codex o Cursor. Trabajas en codebases de más de diez mil líneas. Frecuentemente te dejan en repositorios desconocidos. Observas cómo tu consumo de tokens sube durante sesiones de exploración. Mantienes una carpeta docs/ que querrías que un LLM realmente leyera.
Espera unos releases si: Solo trabajas en proyectos pequeños. Tu stack usa un lenguaje de nicho con cobertura débil de tree-sitter. No tienes un entorno local con Python 3.10+ y no quieres configurar uno.
No lo instales si: Buscas una herramienta mágica de refactoring. Graphify no escribe código. No arregla tu arquitectura. Te dice lo que tu arquitectura es — lo que hagas con esa información sigue siendo cosa tuya.
Para mí, esta es la implementación más limpia de la idea de Karpathy de "el LLM es el programador, el wiki es la codebase" que he usado en código real (no solo en notas). Se integra naturalmente con la forma en que ya uso Claude Code, sobrevive al uso diario sin romperse, y el mantenedor está publicando releases lo suficientemente rápido como para que las asperezas que señalaría esta semana podrían desaparecer la próxima.
El grafo del repositorio con el que empecé este artículo ahora está commiteado junto al código fuente. Cada PR lo reconstruye. Cada documento de incorporación lo referencia. La pregunta "¿cómo se ve esta codebase?" que antes tomaba una hora, ahora toma noventa segundos. Ese es el cambio de workflow, y es la razón por la que escribo sobre Graphify en vez de pasar al siguiente objeto brillante en mi feed.
Si solo haces una cosa después de leer esto: abre una terminal, ejecuta uv tool install graphifyy, luego graphify install, luego graphify build dentro del repositorio que has estado evitando silenciosamente. El grafo que construya probablemente te sorprenderá — y posiblemente te avergonzará, de la manera más útil. Ese es el punto.
Preguntas frecuentes
¿Qué hace Graphify realmente?
Graphify convierte una carpeta de código, documentación y otros archivos en un grafo de conocimiento consultable para que tu asistente de IA pueda responder preguntas sobre la estructura sin releer archivos fuente. Usa tree-sitter para el parsing determinista de código y un LLM para extracción semántica sobre documentación, luego agrupa el resultado con Leiden community detection. La salida es un graph.json que tu agente consulta en lugar de rastrear tu codebase.
¿Cómo se instala Graphify en Claude Code?
Ejecuta uv tool install graphifyy (o pipx install graphifyy) para instalar el CLI, luego graphify install para registrarlo como un skill de Claude Code. El comando de instalación escribe el manifiesto del skill en ~/.claude/skills/graphify/ y actualiza CLAUDE.md para que Claude Code recurra al grafo antes de rastrear archivos sin procesar. El tiempo total de instalación es menos de un minuto en una máquina moderna.
¿Es real la reducción de 70x en tokens?
La cifra de 71,5x es real pero depende del corpus — proviene de un benchmark multimodal mixto donde PDFs e imágenes inflan la línea base en bruto. En repositorios de código puro, espera aproximadamente 5x a 10x de compresión de tokens en consultas estructurales. Eso sigue siendo sustancial, pero no es la cifra del titular. Los ahorros se concentran en workflows de exploración e incorporación, no en escritura de código.
¿Graphify reemplaza a grep o la búsqueda vectorial?
No — los complementa. Graphify gana en preguntas estructurales ("qué llama a qué", "camino más corto entre dos módulos"). Grep sigue ganando cuando sabes la cadena exacta que buscas. La búsqueda vectorial sigue ganando para similitud semántica difusa sobre texto largo. La configuración más fuerte apila las tres, con el grafo como la capa de índice estructural.
¿Puede el grafo mantenerse actualizado a medida que cambia el código?
Sí. Ejecuta graphify build --update para re-extraer solo archivos cambiados (detectados via hashes SHA256) y fusionarlos en el grafo existente. También puedes instalar hooks de git que activan actualizaciones incrementales al hacer commit o checkout, para que el grafo se mantenga sincronizado con tu repositorio sin intervención manual.
Trabajemos juntos
¿Quieres construir sistemas de IA, automatizar workflows o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
