Revisión de código con IA: auto-revisión anclada al ticket y un grafo local del código
Dos proyectos abiertos proponen que el autor revise su propio diff con un modelo antes de abrir el PR, y que ese modelo consulte un grafo de código indexado en local en vez de recorrer el repo con grep.
El código se escribe más rápido de lo que se revisa. Un flujo con asistencia de IA genera más pull requests y diffs más grandes, y la lectura línea a línea deja de escalar. La respuesta que se está proponiendo en foros de desarrollo no es sustituir al revisor humano, sino darle un punto de partida mejor: que el autor revise su propio cambio con un modelo anclado al ticket y a un grafo del código.
Separar contexto de sintaxis
Dentro de "revisar código" conviven varias cosas: conocimiento del lenguaje y sus librerías, convenciones del equipo, corrección, seguridad y rendimiento, y encaje en la aplicación. Las dos primeras las cubre un linter o un modelo sin despeinarse. La última es la difícil: un cambio puede ser impecable en aislamiento y aun así duplicar lógica que ya existe o romper una suposición de la que depende otro módulo. Eso es lo que se pierde cuando alguien abre un diff sin la historia detrás.
De ahí el flujo que se describe: dar al asistente el ticket o la descripción de lo que se quería construir, apuntarlo al diff entre la rama y main, y pedirle que evalúe el cambio contra esa intención. La skill de revisión de Superpowers parte de un commit base, un commit cabeza, una descripción y el plan contra el que se construyó, y lanza un subagente revisor para que el diff y la evaluación vivan en su contexto y al hilo principal solo vuelvan los hallazgos. Las funciones de revisión de GitHub Copilot siguen el mismo principio.
Un grafo en vez de grep
El segundo componente es CodeGraph, un grafo de conocimiento del código preindexado que se resincroniza cuando se crea, modifica o borra un fichero y se ejecuta en local, sin sacar el código de la máquina. En lugar de que el agente recorra el repositorio con grep y find, consulta relaciones entre símbolos, call graphs y estructura. Para una revisión eso responde justo lo que importa: quién llama a esta función, de qué depende este módulo y cuál es el radio de impacto del cambio, incluyendo saltos por callbacks o implementaciones de interfaz que un grep no sigue.
Los números que se citan para defenderlo —un 62% menos de llamadas a herramientas y un 57% menos de tokens de media— son del propio proyecto, no de una medición independiente, así que conviene tomarlos como dirección y no como resultado.
Lo que queda por ver es si el grafo aguanta en monorepos grandes y con cambios rápidos, y si el coste de indexar compensa en equipos pequeños. Los dos repositorios están publicados en GitHub y son de código abierto. El revisor humano sigue decidiendo qué se acepta; lo que cambia es lo que le llega a la mesa.
