Más de 130.000 estrellas en GitHub a 21 de octubre de 2026: Graphify se ha convertido en una de las herramientas más populares para agentes de código. Su propuesta es que tu agente deje de hacer grep y de leer ficheros uno a uno, y consulte un grafo de conocimiento del proyecto que se construye en local, sin LLM para el código.
Qué es
Graphify es una CLI en Python (paquete graphifyy, con doble y) que viene con una skill para Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot y más de veinte asistentes. Con /graphify . recorre el proyecto y genera tres ficheros en graphify-out/: graph.json con el grafo completo, graph.html para explorarlo en el navegador y GRAPH_REPORT.md con los conceptos clave y las conexiones más llamativas.
Por dentro hay dos pasadas:
- Código: lo analiza con el AST de tree-sitter en unos 40 lenguajes y resuelve
calls,importsy herencia entre ficheros. Es determinista, no usa LLM y no sale nada de tu máquina. - Documentación, PDF, imágenes y vídeo: necesitan un modelo para la extracción semántica, el de tu asistente o el de una API configurada.
No es un índice vectorial: no hay embeddings, es un grafo que se recorre. Cada arista lleva la etiqueta EXTRACTED (está explícita en el código) o INFERRED (la ha resuelto Graphify), y el grafo se divide en comunidades con el algoritmo de Leiden para separar subsistemas. Los comentarios # NOTE: y # WHY: y las referencias a ADR o RFC se convierten en nodos enlazados al código. La licencia es Apache-2.0, y el repositorio incluye también un fichero de licencia MIT.
Cómo se usa
Necesita Python 3.10 o superior y uv (o pipx):
uv tool install graphifyy # la CLI
graphify install # detecta tu asistente y registra la skillDespués, en el asistente, /graphify ., y a partir de ahí se consulta el grafo en lugar de los ficheros:
graphify explain "APIRouter" # un concepto y sus conexiones
graphify path "FastAPI" "ModelField" # cómo se relacionan dos cosas
graphify query "¿dónde se valida el token?"
graphify hook install # reconstruye al hacer commit y cambiar de ramaCon graphify claude install el proyecto queda configurado para que Claude Code use siempre el grafo: un hook se dispara antes de las búsquedas y antes de leer ficheros con Read o Glob y empuja al agente hacia la consulta. En Codex, Cursor y otros se hace con ficheros de instrucciones como AGENTS.md.
Un aviso de instalación: el README insiste en que el paquete oficial es graphifyy, y en PyPI hay otros graphify* que no son suyos. Escribir mal el nombre te puede instalar otra cosa.
Lo que me convence y lo que no
Me convence que la parte de código sea local y determinista: puedes indexar un repositorio privado sin mandarlo a ningún proveedor, y con --code-only o GRAPHIFY_BACKEND=none te aseguras de que no se llame a ningún LLM. También que distinga lo extraído de lo inferido, porque es justo lo que necesitas para fiarte de una respuesta del agente. Y que no envíe telemetría.
Lo que no me convence tanto:
- Los benchmarks son suyos y algunos, pequeños. En LOCOMO (300 preguntas) saca un recall@10 de 0,497, pero en precisión de respuestas queda por detrás de supermemory (45,3 % frente a 49,7 %). En LongMemEval-S empata con RAG denso (76 %), y la mejora frente a
grepy lectura de ficheros (82,0 % frente a 70,8 %) sale de solo 6 tareas. - El selector automático de proveedor. Si
graphify extractencuentra varias API keys en el entorno, elige por prioridad (Gemini primero), y el README avisa de que la de Kimi enruta a servidores en China. Para código con requisitos de residencia, fija--backendu Ollama. - El log de consultas. Cada
query,pathyexplainse registra en~/.cache/graphify-queries.logcon la pregunta. Se desactiva conGRAPHIFY_QUERY_LOG_DISABLE=1. - El empuje comercial. El README dedica bastante espacio a Graphify Cloud, la versión de pago con grafo continuo y multirrepo. La herramienta local funciona sin ella, pero hay que tener claro qué parte es producto.
- El hook intercepta lecturas. Hace bien su trabajo, pero si el grafo está desactualizado el agente responde sobre una foto vieja del código; el hook de commit o un
graphify update .tras cadagit pulles obligatorio.
Graphify frente a grep y RAG con embeddings
Hasta ahora, un agente de código entendía un repositorio de dos formas: leyendo ficheros con grep y Read, o con un índice de embeddings que devuelve fragmentos parecidos a la pregunta.
grep + lectura | RAG con embeddings | Graphify | |
|---|---|---|---|
| Qué devuelve | Líneas que coinciden con un patrón | Fragmentos semánticamente parecidos | Nodos y relaciones (llamadas, imports, herencia) |
| Coste de indexar | Ninguno | Embeddings por cada fragmento | AST local para el código; LLM solo para docs y media |
| Preguntas de estructura ("¿qué llama a X?") | Varias búsquedas encadenadas | Débil | Su punto fuerte |
| Datos fuera de tu máquina | No | Depende del modelo de embeddings | No, para el código |
| Frescura | Siempre al día | Hay que reindexar | Hay que reconstruir (hooks de git) |
Cuándo usar cada uno: grep sigue siendo imbatible para buscar un literal y no se queda nunca desactualizado. RAG va bien para preguntas en lenguaje natural sobre documentación. Graphify gana cuando la pregunta es de estructura (de dónde viene un dato, qué rompe un cambio, cómo se conectan dos módulos) en repositorios grandes, donde leer fichero a fichero gasta el contexto del agente.
Fuentes
- Graphify-Labs/graphify, GitHub
- graphify README, Graphify Labs