Review de Graft: ¿puede el mapa del repo ser un activo de equipo?

Graft resuelve un problema real, y la versión viral de su discurso se equivoca justo en la parte que más importa a quien dirige ingeniería. El problema existe: un agente de programación empieza casi todas las tareas a ciegas, rastrea tu repositorio con grep, reconstruye una imagen que ya construyó ayer y te factura el redescubrimiento. Graft escribe esa imagen en disco como nodos de markdown enlazados, para que la siguiente tarea arranque orientada.

La afirmación que circula en las redes dice que el mapa viaja luego por Git y que todo el equipo lo hereda. La propia documentación de Graft dice lo contrario. En el repositorio oficial de Graft, el README afirma que el grafo es "a local, regenerable cache (like node_modules), not something you commit". graft build añade graft/ a tu .gitignore de forma automática, y cada persona del equipo ejecuta graft build para generar su propia copia.

No es un defecto. Es el comportamiento por defecto correcto, y cambia lo que realmente estás implantando: una convención compartida y una reconstrucción barata, no un documento compartido. Nuestro veredicto tras revisar el proyecto el 18 de agosto de 2026: conecta Graft en un repositorio y mídelo, pero plantea la historia de equipo alrededor de lo que sí pertenece al control de versiones. Esta página es la propietaria de la intención específica de producto "review de Graft" y "mapa del repo en Git". Nuestro review de Graphify es dueño de la decisión sobre un grafo de conocimiento consultable, y la guía de ingeniería de grafos es dueña de cuándo un grafo se paga a sí mismo.

¿Qué es Graft?

Graft es una CLI en TypeScript con licencia MIT que convierte un repositorio en una carpeta de nodos de markdown enlazados más un grafo de código por símbolo, y conecta esa salida con los agentes que ya usas. La instalación son dos comandos, npm install -g @nanonets/graft y graft init. Construye en dos capas, y la diferencia entre ellas decide tanto tu coste como tu revisión de privacidad.

Dos decisiones de diseño merecen nombrarse, porque son lo que hace interesante la herramienta más que su tabla de benchmarks. Primera, no hay almacén vectorial: la descripción del propio proyecto habla de archivos que tu agente lee, sin servidor, base de datos ni embeddings. Segunda, la frescura es un bucle y no un índice: cada consulta compara el árbol de trabajo con la huella del último build y reconstruye solo lo que se movió, de forma estructural y sin coste en tokens, así que las respuestas describen también los cambios sin commitear.

Esa segunda decisión es la ingeniería de fondo. Un mapa obsoleto es peor que ningún mapa, porque el agente confía en él. Aquí importa el precedente: Aider ya publicó en octubre de 2023 un mapa de repositorio con tree-sitter ordenado por PageRank. El mapa ordenado no es nuevo. La novedad es el bucle de refresco y la conexión con varios agentes.

¿Graft commitea el mapa del repositorio en Git?

No, y tampoco deberías querer eso. Lo que viaja por el control de versiones es el wiring: los archivos que graft init deja en .claude/, la sección delimitada de Graft en AGENTS.md y la configuración MCP. El grafo generado en graft/ queda en gitignore y se reconstruye en cada clon.

Llegamos a la misma conclusión por el camino difícil en el repositorio de esta propia web. Ejecutamos agentes de programación en worktrees de git paralelos, y allí la salida generada del grafo está excluida del control de versiones a propósito, porque los nombres de archivo generados colisionan entre ramas simultáneas y un conflicto en un archivo escrito por una máquina cuesta tiempo de revisión sin aportar valor de revisión. Un mapa commiteado además envejece al ritmo de la rama en la que estés, que es justo cuando un agente es más propenso a actuar sobre él.

Así que la formulación honesta del beneficio de equipo es más estrecha que la viral, y más útil. Graft no le da a tu compañero el conocimiento que construyó tu agente. Le da un comando de dos segundos que reconstruye un mapa equivalente desde la misma fuente de verdad: el código. Es una garantía mejor que un archivo compartido, porque no puede derivar. También es una tarea de despliegue, no de documentación.

¿Qué debería vivir en Git entonces?

La regla útil es corta: commitea aquello de lo que responde una persona y regenera lo que un parser puede deducir. La estructura generada es barata y se autocorrige. La intención no es ninguna de las dos cosas.

1. Decisiones y restricciones. Comandos de build y test, límites que el agente no debe cruzar, por qué el módulo feo sigue siendo feo, qué interfaz es un contrato. Para eso existe AGENTS.md, un formato que usan más de 60.000 proyectos de código abierto y que hoy mantiene la Agentic AI Foundation bajo la Linux Foundation. Se escribe a mano, se revisa en pull requests y merece el mantenimiento.
2. Estructura derivada. Grafos de llamadas, mapas de símbolos, listas de archivos ordenadas. Es reconstruible, así que ponla en gitignore y haz que la reconstrucción sea rápida y automática.
3. Conocimiento institucional que no es código. Runbooks, reglas de dominio, decisiones con responsable y fecha de revisión. Eso pertenece a un almacén gobernado, que es otro proyecto con otras reglas. Nuestra arquitectura de wiki corporativa lista para IA lo cubre.

Los equipos que fallan aquí suelen hacerlo en una de dos direcciones. Commitean la salida generada y heredan ruido de merge más respuestas obsoletas dichas con seguridad. O no escriben nada y esperan que la herramienta infiera una intención que nunca se registró en ningún sitio. Un mapa del repo no puede decirle a un agente que una tabla está en migración y no debe ganar columnas. Eso solo lo puede hacer una persona. La misma disciplina aparece en nuestra checklist de traspaso de software, escrita para la versión humana del mismo problema: qué hay que dejar por escrito antes de que se vaya quien lo sabe.

¿Qué solidez tienen las cifras de Graft?

El mecanismo es creíble y todas las cifras publicadas las produce el proveedor. Esa combinación merece un piloto, no una decisión de compra. Graft publica tres mediciones separadas, y no son igual de fuertes.

El brazo de SWE-bench es el más fuerte porque la evaluación es determinista. También es el que conviene leer con más cuidado. El SWE-bench Verified completo contiene 500 instancias validadas por personas; 50 son una décima parte, y el informe no dice qué décima. Las dos instancias que menciona por su nombre son de Django, y un subconjunto de 50 muy usado, SWE-bench-verified-mini, solo toma de Django y Sphinx. Ninguno de los dos hechos dice qué muestreó Graft en realidad, y ese hueco es la limitación que conviene nombrar: sin la lista de instancias, la cobertura de proyectos y lenguajes detrás de la cifra es desconocida. Seis instancias extra sobre una muestra de 50 no divulgada, ejecutada una vez, es una señal de dirección. No es una posición de leaderboard ni una prueba sobre tu servicio en Kotlin.

El hallazgo más accionable no es el que abre el marketing. La medición incluía una tercera variante: pull, donde el agente recibe las herramientas de Graft pero no se le inyecta nada por adelantado, así que el contexto solo se paga cuando se pide. Pull cedió casi toda la ganancia de velocidad y alcanzó un 98% de corrección frente al 93% de un agente en frío. Si acertar importa más que ir rápido, esa es la configuración que hay que probar primero, y es lo contrario del bundle inyectado que produce la cifra de latencia del titular.

¿Qué cuesta Graft de verdad?

No hay cuota de licencia. Ahí acaba la parte gratis, y el presupuesto real tiene cuatro líneas.

• Los builds estructurales son gratis de verdad. El parseo con tree-sitter, el bucle de refresco y las consultas estructurales nunca llaman a un modelo. En un repositorio grande ahí está la mayor parte del valor con coste marginal cero.
• La capa de conceptos es una partida de tokens. graft build --deep resume archivos y símbolos con tu clave, con caché por hash del cuerpo, así que el coste depende de la rotación del código. Presupuéstalo por persona activa y clon, no una vez por repositorio.
• La madurez cuesta. El proyecto se creó el 3 de julio de 2026 y su tag más reciente es v0.9.0, con unas 3.500 estrellas y decenas de issues abiertos en el momento de escribir esto. Una dependencia pre-1.0 en la ruta de contexto de tu agente merece versión fijada y una ruta de actualización probada, igual que cualquier otra herramienta de build.
• El tiempo de revisión es la línea que se olvida. Los resúmenes escritos por una máquina son texto sin revisar sobre tu arquitectura. Cuando un agente actúa sobre un resumen equivocado, alguien senior lo paga en revisión. Nuestro marco de coste por acción da el denominador correcto: coste por cambio aceptado, incluidos minutos de revisión y retrabajo, no tokens ahorrados por consulta.

Los tokens son lo más fácil de medir y lo menos interesante de optimizar. La versión sistemática de ese argumento está en nuestro manual de presupuesto de tokens, que trata caché, enrutado y compresión en el orden que protege la calidad.

¿Qué deben revisar los equipos europeos antes del despliegue?

La separación entre capas encaja de forma cómoda con la pregunta de cumplimiento.

Un graft build normal es local y determinista, y el proyecto declara que no envía telemetría: las únicas llamadas de red son las peticiones al modelo que tú configuras. Para trabajo regulado esa es una posición fuerte: obtienes orientación, mapas de símbolos y grafos de llamadas sin que el código salga de la máquina.

graft build --deep es otra decisión. Envía contenido de archivos y símbolos al proveedor al que lo apuntes, lo que convierte a ese proveedor en encargado del tratamiento de tu código fuente. Cierra el contrato de encargado, la región, el plazo de conservación y las condiciones de uso para entrenamiento antes del primer build profundo, no después de que alguien lo lance sobre el servicio de pagos. Nuestra guía de residencia de datos en la UE cubre el lado del proveedor, y la redacción antes del prompt cubre los repositorios donde fixtures y logs llevan datos personales.

Un control más que conviene fijar pronto: el grafo generado es una descripción compacta y legible de cómo encaja tu sistema. Trátalo como código fuente. No debería acabar en un paquete de soporte, en un artefacto público de CI ni en una captura dentro de un ticket.

Graft, mapa del repo o grafo de conocimiento: ¿qué problema resuelves?

La mayoría de equipos que buscan una herramienta así tienen uno de cinco problemas distintos, y solo dos se resuelven con un mapa del repositorio.

Si aún estás decidiendo si algo de esto se paga solo, empieza un nivel más arriba. Nuestro análisis del contexto como cuello de botella real explica por qué existe la categoría, y el informe de campo sobre compresión de contexto muestra cómo se ven los ahorros medidos en nuestro propio trabajo de entrega y no en una tabla de proveedor.

Un piloto de dos semanas que produce una decisión

1. Elige un repositorio que duela. Grande, multilenguaje, mal documentado, con trabajo activo. Un servicio limpio de 40 archivos no mostrará diferencia.
2. Congela el conjunto de tareas antes de instalar nada. Diez preguntas reales de orientación y localización más cinco cambios que ya hayas fusionado, reseteados a su commit base.
3. Ejecuta tres brazos, no dos. En frío, push (bundle por adelantado) y pull (herramientas a demanda). Los datos del propio proveedor dicen que se comportan distinto en corrección.
4. Evalúa los cambios con tests, no con solape de archivos. Tocar los archivos correctos es un proxy débil. Tu suite de tests es el evaluador en el que ya confías.
5. Cuenta el coste por cambio aceptado. Tokens, tiempo de reloj, reintentos y minutos de revisión, divididos por los cambios que sobrevivieron a la revisión.
6. Ataca la frescura. Lanza consultas con el árbol sucio, en medio de un rebase, tras un renombrado grande y en una rama que borró un subsistema. Un mapa que miente con seguridad es el riesgo principal de esta categoría.
7. Decide el proveedor del build profundo a conciencia. Enrútalo por tu camino de modelos ya aprobado, o deja la capa de conceptos apagada durante el piloto y mide solo la capa estructural gratuita.
8. Revisa qué acaba en Git. Revisa el diff del wiring, confirma que graft/ está ignorado y que nada generado se haya colado en un commit.
9. Fija la versión. Y luego actualiza una vez durante el piloto a propósito, para ver lo que cuesta la actualización.
10. Define el criterio de escalado por adelantado. Adopta solo si la corrección verificada o el coste por cambio aceptado mejoran lo suficiente para pagar la reconstrucción, la revisión y una dependencia pre-1.0.

Dos semanas bastan porque la medición es mecánica, siempre que alguien la asuma. El servicio de habilitación de IA de Wavect ejecuta esta comparación dentro de tu repositorio y entrega el arnés de medición, para que el resultado sobreviva a la consultoría. El caso de Twinsoft AI muestra cómo tratamos la trazabilidad de la salida de IA y el control del revisor en trabajo de producción. Si estás pesando implementación contra documento de estrategia, compara primero habilitación de IA frente a consultoría de IA genérica y luego cuéntanos cuál es el repositorio que duele.

Límites de esta investigación

Estado verificado el 18 de agosto de 2026 contra el repositorio público y el sitio del proyecto Graft. Es un review independiente de arquitectura y de compra, no un post patrocinado, ni una auditoría de seguridad, ni un benchmark controlado propio de la herramienta. Cada cifra de rendimiento citada aquí la publica el proveedor y la evalúa su propio arnés, con el brazo de SWE-bench usando el grader oficial. El proyecto es pre-1.0 y se mueve rápido, así que fija una versión y relee la documentación actual antes de estandarizar sobre ella.