El 3 de abril de 2026, Andrej Karpathy publicó algo que llamó «LLM Knowledge Bases» (bases de conocimiento para modelos de lenguaje), y en cuestión de horas la idea comenzó a difundirse por toda la comunidad de inteligencia artificial.
La propuesta central era sorprendentemente sencilla: en lugar de utilizar RAG para recuperar fragmentos de archivos originales cada vez que haces una pregunta, puedes hacer que un modelo de lenguaje convierta esos archivos en una wiki estructurada, interconectada y escrita en Markdown.
Esta wiki permanece disponible entre sesiones, acumula conocimiento con el tiempo y permite que cada consulta futura sea más económica.
Karpathy explicó que su método consistía en colocar artículos científicos, capturas de pantalla, repositorios y otros documentos dentro de una carpeta llamada /raw. Después, un modelo de lenguaje procesaba todo ese contenido para crear una wiki con resúmenes, enlaces entre documentos, mapas conceptuales y un archivo índice que el propio modelo podía recorrer de forma autónoma.
Sin embeddings vectoriales, sin sistemas complejos de recuperación de información. Simplemente archivos Markdown cuyo conocimiento se va acumulando.
La publicación se volvió viral, al igual que el GitHub Gist que compartió posteriormente. De repente, todo el mundo hablaba de utilizar conocimiento previamente estructurado como alternativa a los sistemas tradicionales de recuperación de información.
Mi primera reacción fue una mezcla de interés y cierta frustración, porque llevaba tiempo explorando ideas similares mientras trabajaba con Claude Code en repositorios grandes.
Me encontraba con el mismo problema que muchas personas: el modelo vuelve a descubrir toda la estructura de tu código desde cero en cada sesión, y la ventana de contexto se llena mucho antes de que consiga comprender realmente la arquitectura del proyecto.
La explicación de Karpathy hizo que todo encajara. Sin embargo, él mismo reconocía que su implementación era una colección improvisada de scripts, y yo no tenía ninguna intención de construir desde cero mi propio compilador de wikis.
Entonces, apenas 48 horas después, alguien lanzó una herramienta que hacía precisamente eso.
Qué es Graphify y qué no es
Un desarrollador llamado Safi Shamsi publicó Graphify, una herramienta de código abierto que lleva a la práctica el enfoque propuesto por Karpathy, pero orientado específicamente a bases de código.
Solo necesitas indicarle una carpeta y la herramienta analiza todo su contenido: código escrito en 19 lenguajes de programación, documentos PDF, archivos Markdown e imágenes, incluidas fotografías de pizarras y diagramas mediante Claude Vision.
A partir de esa información, construye un grafo de conocimiento completo que incluye detección de comunidades, una visualización HTML interactiva, una bóveda de Obsidian con enlaces inteligentes entre documentos y una wiki.
Cualquier agente puede comenzar desde index.md y recorrer el conocimiento sin necesidad de interpretar archivos JSON.
La instalación requiere una sola línea:
pip install graphifyy && graphify installDespués, escribes /graphify dentro de Claude Code, Codex, OpenCode u OpenClaw y señalas el directorio de tu proyecto.
El resultado se guarda en una carpeta llamada graphify-out/, que contiene varios elementos:
graph.html: permite explorar el grafo de forma interactiva.
GRAPH_REPORT.md: destaca los nodos centrales, también llamados god nodes, y las conexiones inesperadas.
graph.json: almacena el grafo persistente que puede consultarse posteriormente.
Una caché incremental: evita tener que procesar nuevamente todos los archivos en futuras actualizaciones.
Ahora bien, también es importante entender lo que Graphify no es.
No es un sistema RAG, no es una base de datos vectorial y tampoco es una interfaz de chatbot construida sobre otro modelo.
Es una etapa de compilación, exactamente como la describió Karpathy, que transforma un directorio desorganizado en un recurso de conocimiento estructurado.
Gracias a ello, cualquier agente de IA puede razonar sobre el proyecto sin tener que leer todos sus archivos.
La cifra de 71,5 veces: primero el escepticismo, después las matemáticas
La afirmación principal es que Graphify puede reducir hasta 71,5 veces la cantidad de tokens necesarios por consulta en comparación con la lectura de los archivos originales.
La cifra parecía demasiado buena para ser cierta, así que decidí revisar cómo estaban diseñadas realmente las pruebas de rendimiento.
A pequeña escala, con seis archivos Python que representan una capa de transporte HTTP, la compresión es marginal y, en realidad, tampoco es lo más importante.
Esos archivos ya caben dentro de una ventana de contexto. En ese escenario, el verdadero valor está en la claridad estructural.
Puedes identificar que Client, AsyncClient, Response y Request son los nodos centrales del proyecto, y también visualizar los grupos o comunidades que reúnen módulos relacionados.
Eso resulta útil, pero está lejos de representar una mejora de 71 veces.
La situación cambia cuando analizamos un conjunto de 52 archivos compuesto por código, artículos de investigación e imágenes.
En ese caso, la reducción de tokens sí alcanza aproximadamente las 71 veces.
El repositorio incluye ejemplos completos, con los archivos de entrada originales y los resultados reales, de manera que cualquier persona puede comprobar las cifras por su cuenta.
Ese nivel de transparencia es algo que me gustaría encontrar con mayor frecuencia en los proyectos de código abierto.
La razón por la que la compresión mejora a medida que aumenta el tamaño del proyecto es bastante sencilla.
El grafo sintetiza toda la información en nodos, conexiones, resúmenes de comunidades y un informe que el modelo de lenguaje puede recorrer utilizando una fracción de los tokens que necesitaría para leer el contenido original.
Esto es especialmente importante en los flujos de trabajo basados en agentes de inteligencia artificial.
Si tienes varios agentes escribiendo código en paralelo, o estás trabajando durante una sesión prolongada de Claude Code que abarca varios commits, cargar 52 archivos originales en el contexto en cada interacción representa un desperdicio de recursos.
En cambio, proporcionar un informe del grafo que contiene la misma información estructural utilizando aproximadamente una septuagésima primera parte de los tokens cambia por completo el perfil de costos.
Cómo funciona internamente: no hay magia, solo buena ingeniería
La arquitectura es sorprendentemente transparente.
Los archivos de código se procesan mediante el análisis de árboles de sintaxis abstracta (AST) con tree-sitter, compatible con 19 lenguajes:
Python, JavaScript, TypeScript, Go, Rust, Java, C, C++, Ruby, C#, Kotlin, Scala, PHP, Swift, Lua, Zig, PowerShell, Elixir y Objective-C.
Todo este procesamiento se realiza de forma local.
En el caso del código, el contenido de los archivos no sale de tu computadora.
Los documentos y las imágenes, por su parte, se procesan mediante la API del modelo que ya utiliza tu plataforma para realizar la extracción semántica.
Por ejemplo, Claude si trabajas con Claude Code, o GPT-4 si utilizas Codex.
NetworkX se encarga de construir el grafo.
El algoritmo Leiden, a través de graspologic, realiza la detección de comunidades.
Y vis.js genera la visualización interactiva.
No necesitas Neo4j ni un servidor externo. Todo funciona localmente.
Además, cada conexión del grafo recibe una etiqueta que indica su nivel de confianza:
EXTRACTED (extraída): la relación se encontró directamente en el material original.
INFERRED (inferida): la relación fue deducida por el modelo a partir del contexto.
AMBIGUOUS (ambigua): la relación no puede determinarse con suficiente certeza.
Esto permite distinguir qué información procede realmente de los archivos y qué parte ha sido interpretada o deducida por la inteligencia artificial.
Donde realmente se aprecia la calidad de la ingeniería es en el sistema de actualizaciones incrementales.
El modo --watch funciona en una terminal en segundo plano y mantiene actualizado el grafo a medida que cambia el código del proyecto.
Cuando guardas un archivo de código, se reconstruye inmediatamente su estructura AST sin realizar ninguna llamada a un modelo de lenguaje.
En cambio, cuando modificas documentos o imágenes, el sistema te indica que ejecutes --update para repetir el análisis semántico.
Los hooks de Git, que se instalan mediante graphify hook install, reconstruyen el grafo después de cada commit y de cada cambio de rama.
Y si una reconstrucción falla, el hook termina con un código de error distinto de cero, lo que permite que Git muestre el problema en lugar de continuar silenciosamente con un grafo desactualizado.
Este último detalle puede parecer menor, pero antes el sistema terminaba con código cero incluso cuando se producía un error.
Eso significaba que el grafo podía quedar desactualizado sin mostrar ninguna advertencia.
Y precisamente ese tipo de errores silenciosos es el que termina debilitando la confianza en las herramientas de desarrollo.
Cómo se ve en la práctica: probando Graphify en mi propio repositorio
Leer pruebas de rendimiento está muy bien, pero quería comprobar cómo funcionaba Graphify en un proyecto real.
Así que decidí ejecutarlo sobre un repositorio propio.
El proyecto era un generador de códigos QR que había construido con Claude Code.
Tenía un total de 27 archivos, distribuidos de la siguiente manera:
18 archivos de código repartidos entre src/, test/ y carpetas de configuración.
4 documentos, entre ellos AGENTS.md, CLAUDE.md y FLOW.md.
5 imágenes, incluidas capturas de pantalla de la interfaz, el logotipo de Towards Deep Learning y un par de archivos PNG utilizados en las pruebas.
El proceso se ejecutó en cuatro etapas.
Primera etapa: exploración y clasificación.
Graphify recorrió la carpeta y clasificó todos los archivos según su tipo.
Segunda etapa: análisis del código.
Procesó los 18 archivos de código utilizando tree-sitter AST de forma local.
No intervino ningún modelo de lenguaje, por lo que esta parte no generó costos de uso de IA.
Solo esta etapa permitió extraer todas las funciones, clases, importaciones y relaciones de llamadas.
El resultado inicial fue de 162 nodos y 240 conexiones.
Por ejemplo, relaciones como:
src_main → calls → selectPalette()
Tercera etapa: interpretación de documentos e imágenes.
El sistema ejecutó seis subagentes de Claude en paralelo para analizar los documentos y las imágenes.
Esta fue la parte que utilizó el modelo de lenguaje y consumió aproximadamente 193.000 tokens.
Los agentes de visión examinaron las capturas de pantalla de la interfaz y consiguieron interpretarlas como elementos funcionales.
Por ejemplo, identificaron una relación que indicaba que la zona donde se arrastra el logotipo comparte datos con el panel de vista previa del código QR.
También reconocieron que la opción de corrección de errores de nivel H en la interfaz estaba relacionada con la justificación del indicador de verificación de decodificación.
Por su parte, el agente encargado de los documentos extrajo conceptos arquitectónicos presentes en AGENTS.md y FLOW.md.
Entre ellos:
Scan Verification Gate: mecanismo de verificación del escaneo.
Darken-and-Retry Loop: ciclo de oscurecimiento y nuevo intento.
Yellow Pitfall: problema o riesgo asociado al color amarillo.
Cuarta etapa: construcción del grafo completo.
Graphify combinó toda la información en un único grafo.
El resultado final fue:
229Nodos 296Conexiones 26Comunidades
El sistema ejecutó el algoritmo Leiden para detectar las comunidades, calculó cuáles eran los nodos centrales y cuáles funcionaban como puentes entre distintas comunidades.
También clasificó todas las relaciones como EXTRACTED, INFERRED o AMBIGUOUS.
La visualización interactiva del grafo, que aparece a continuación, es la que se genera en graphify-out/graph.html.
Puedes hacer clic sobre cualquier nodo para consultar su tipo, la comunidad a la que pertenece, el archivo de origen, su grado de conectividad y sus nodos vecinos.
La barra lateral muestra las 26 comunidades junto con la cantidad de nodos que contiene cada una.
También puedes activar o desactivar comunidades para aislar determinados grupos y analizarlos con mayor facilidad.
Junto con la visualización, Graphify dejó varios archivos almacenados en el disco.
El archivo graph.json contiene el grafo consultable que utiliza el comando graphify query.
El documento GRAPH_REPORT.md incluye un informe de auditoría con los nodos centrales, los hallazgos inesperados y algunas preguntas sugeridas.
Además, las carpetas cache/ y el archivo manifest.json permiten que una futura ejecución de --update procese únicamente los archivos que hayan cambiado.
Sin embargo, lo que más me sorprendió fue descubrir información que no resultaba evidente simplemente ejecutando ls o leyendo el código.
El verdadero centro de gravedad del repositorio no era la generación de códigos QR, sino la ciencia del color.
La parte más densamente conectada del grafo estaba formada por las matemáticas relacionadas con el contraste, las paletas y la extracción de colores.
Mientras tanto, la generación de códigos QR aparecía como dos dependencias de bibliotecas situadas en la periferia.
Los módulos src_main, src_palette y src_verify resultaron ser los principales centros estructurales.
El mecanismo de verificación de escaneo también ocupaba una posición central dentro de la arquitectura.
Eso era exactamente lo que exigía AGENTS.md, pero no habría sido tan evidente sin comparar, una al lado de la otra, la especificación y la implementación.
Las pruebas estaban conectadas directamente con los módulos que verificaban, en lugar de aparecer como elementos aislados.
En otras palabras, el grafo hacía visible una buena decisión de arquitectura.
Los conceptos presentes en AGENTS.md y FLOW.md formaban su propia comunidad independiente.
La especificación coincidía conceptualmente con el código, pero no existían conexiones estructurales directas entre ambos.
Ahí fue donde aparecieron 19 conexiones colgantes.
Además, las capturas de pantalla de la interfaz contenían afirmaciones sobre el producto, como «nunca sale de tu navegador» y «corrección de errores H».
El sistema las convirtió en nodos del grafo y las relacionó con los elementos visuales de la interfaz que justificaban esas afirmaciones.
Ese fue uno de los resultados más interesantes del análisis visual.
Era algo que jamás se me habría ocurrido hacer manualmente.
Después de la ejecución, Graphify también registró la habilidad /graphify.
Eso significa que, en cualquier sesión futura de Claude Code, puedo ejecutar una consulta como esta:
graphify query "why does the download button start disabled?"Es decir: «¿Por qué el botón de descarga aparece deshabilitado inicialmente?».
Y obtener una respuesta directamente desde el grafo, sin necesidad de volver a leer todo el repositorio desde cero.
Así es como funciona, en la práctica, el concepto de conocimiento compilado.
Pagas una vez el costo de extraer la información y después puedes consultarla sin repetir ese procesamiento.
Las limitaciones que debes conocer
Graphify se encuentra en la versión 0.3.1 y evoluciona rápidamente.
Eso significa que todavía debes esperar algunas imperfecciones.
La calidad de la extracción semántica depende por completo del modelo de lenguaje que utilices.
En mi experiencia, Claude Vision interpreta bien los diagramas y las fotografías de pizarras.
Sin embargo, los resultados pueden variar con otros modelos.
Si tu proyecto depende mucho de la documentación visual, la precisión del grafo estará limitada por la capacidad del modelo de visión para interpretar correctamente esas imágenes.
La cifra de compresión de 71,5 veces también depende del conjunto de archivos analizado.
Si tu proyecto contiene diez archivos Python y un README claro, probablemente no necesitas un grafo de conocimiento.
Lo que necesitas es leer el README.
La herramienta destaca especialmente en repositorios medianos y grandes, donde la complejidad estructural supera lo que una persona desarrolladora, o incluso un modelo de lenguaje, puede mantener en su memoria de trabajo.
También aporta mucho valor cuando el proyecto combina código, documentación y artículos de investigación.
En esos casos, pueden existir conexiones entre diferentes áreas que resultan difíciles de descubrir leyendo los archivos de forma secuencial.
En la versión más reciente se incorporaron parches de seguridad para vulnerabilidades relacionadas con SSRF y la inyección de YAML en la visualización HTML.
El proyecto es joven, recibe mantenimiento activo y está siendo revisado por miembros de la comunidad.
Aun así, si vas a utilizarlo sobre repositorios que contienen información sensible, conviene que revises personalmente los posibles riesgos de seguridad.
No deberías asumir que ya cuenta con el nivel de protección de una herramienta ampliamente consolidada para entornos de producción.
Y existe una limitación todavía más importante.
Un grafo de conocimiento puede mostrarte qué elementos están conectados entre sí.
Pero no necesariamente puede explicarte por qué la persona responsable de la arquitectura tomó una determinada decisión, qué restricciones condicionaron el diseño o qué intentos fallidos llevaron a elegir la solución actual.
Esa información sigue estando en la experiencia y la memoria del equipo, en las conversaciones de las solicitudes de cambios (pull requests) y en los mensajes de los commits.
Graphify te proporciona el mapa estructural.
Pero el conocimiento acumulado por las personas de tu organización sigue siendo responsabilidad de tu equipo.
Por qué esto importa más allá de la propia herramienta
Lo que más me interesa es el cambio de enfoque que representa.
Karpathy describió una transición desde «tokens utilizados para generar código» hacia «tokens utilizados para compilar conocimiento».
Y Graphify es la primera herramienta convincente que lleva ese enfoque a la práctica dentro de bases de código.
El hecho de que apareciera apenas 48 horas después de la publicación original, que ya contara con 1.500 estrellas en GitHub y una versión para .NET, y que comenzara a instalarse como una habilidad en diferentes plataformas de programación con agentes, demuestra que existía una demanda esperando una solución.
Estamos pasando de una inteligencia artificial que lee tu código a una inteligencia artificial que comprende la estructura de tu proyecto.
Y son dos capacidades fundamentalmente distintas.
Leer es un proceso lineal.
El modelo analiza los archivos uno por uno e intenta conservar toda la información posible dentro de su ventana de contexto.
Comprender es un proceso estructural.
El modelo identifica qué módulos dependen de otros, dónde están los nodos centrales, qué componentes forman comunidades relacionadas y cuáles son las conexiones inesperadas entre diferentes áreas del proyecto.
Todavía no sabemos si Graphify terminará convirtiéndose en el estándar a largo plazo.
De hecho, sería sorprendente que este sector se mantuviera tan sencillo durante mucho tiempo.
Lo que sí parece claro es que el enfoque de convertir el código en representaciones persistentes y consultables del conocimiento tiene mucho futuro.
Porque la alternativa consiste en volver a cargar los archivos originales en el contexto durante cada sesión y confiar en que el modelo recuerde lo que aprendió anteriormente.
Y ese enfoque ya está mostrando sus límites.
Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.
