Un bot de revisión de solicitudes de integración de código abierto: LangGraph, Node.js y GitHub Webhooks

Las solicitudes de integración se acumulan en casi todos los equipos. Por lo general, solo los ingenieros senior son quienes detectan los problemas sutiles: la consulta N+1, el secreto codificado directamente en el código, los casos límite que nadie ha abordado. También son las personas más ocupadas, por lo que las revisiones se realizan apresuradamente o se posponen, y de cualquier manera algo termina pasando.

Las herramientas comerciales de revisión de IA suelen ser de código cerrado o caras, a menudo ambas cosas. Una alternativa es un bot que un equipo pequeño puede ejecutar en sus propios repositorios, sin tener que enviar código a una “caja negra”. El diseño presentado a continuación es un bot de código abierto que escucha las nuevas solicitudes de integración en GitHub, revisa cada una con un agente LangGraph de múltiples pasos y publica comentarios específicos a nivel de línea como comentario en la solicitud de integración.

Qué ocurre cuando se abre una solicitud de integración

1. Un webhook de GitHub envía el evento.
2. La API de GitHub, a través de Octokit, obtiene la diferencia entre versiones.

Un agente de LangGraph examina la diferencia paso a paso en busca de problemas de seguridad, problemas de rendimiento y cuestiones arquitectónicas.

El bot publica un comentario en la PR con feedback que señala líneas específicas.

La revisión se guarda en una base de datos, por lo que el historial se acumula con el tiempo.

Lo importante es examinarlo paso a paso. Una solicitud que pide a un LLM que “revise este código” suele generar comentarios vagos y genéricos. Dividir la tarea en una revisión de seguridad, una de rendimiento y una arquitectónica produce resultados más precisos, ya que cada etapa tiene una responsabilidad concreta.

La tecnología utilizada

Banco de datos PostgreSQL para el historial de revisiones Integración con GitHub Octokit Webhooks Middleware Express con verificación de firmas

La tecnología utilizada se mantiene cercana a lo que ya usan la mayoría de los equipos de Node.js. El objetivo no era mostrar un nuevo framework, sino algo que un equipo pudiera hospedar y en el que confiar.

Flujo y estructura

El proceso se ejecuta desde la PR abierta, pasando por un webhook verificado hasta el agente, y luego vuelve como un comentario:

GitHub PR opened
        │
        ▼
 Webhook (signed, verified)
        │
        ▼
 Express API ──► Fetch diff (Octokit)
        │
        ▼
 LangGraph Agent
   ├── Security check
   ├── Performance check
   └── Architecture check
        │
        ▼
 Post PR comment + save to PostgreSQL

Cada verificación en el flujo de LangGraph es un nodo por sí mismo. Un equipo puede probar, ajustar o desactivar una verificación sin afectar a las demás, lo cual es útil cuando a la gente solo le importan los hallazgos de seguridad y no desea opiniones sobre la arquitectura en cada PR.

Dos fragmentos de código que vale la pena mostrar

Primero, la verificación de la firma del webhook. Sin ella, cualquiera que descubra la URL del webhook podría enviar eventos falsos y provocar revisiones engañosas:

function verifySignature(payload: string, signature: string) {
  const hmac = crypto.createHmac("sha256", process.env.GITHUB_WEBHOOK_SECRET!);
  const digest = "sha256=" + hmac.update(payload).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(digest), Buffer.from(signature));
}

Es muy pequeño, pero dejarlo de lado es un error común en las herramientas basadas en webhook.

En segundo lugar, el flujo de LangGraph se construye a partir de nodos separados en lugar de una única prompt extensa:

const graph = new StateGraph(ReviewState)
  .addNode("security", securityCheckNode)
  .addNode("performance", performanceCheckNode)
  .addNode("architecture", architectureCheckNode)
  .addEdge("security", "performance")
  .addEdge("performance", "architecture");

Cada nodo recibe la diferencia y devuelve solo sus propios resultados, los cuales se fusionan en un único comentario. De esta manera, depurar se vuelve más sencillo. Si la verificación de rendimiento muestra algo extraño, solo hay un nodo que inspeccionar, en lugar de un mensaje enorme.

Lo que funcionó

• Dividir la revisión en verificaciones separadas de seguridad, rendimiento y arquitectura proporcionó comentarios claramente mejores y más específicos que un mensaje combinado. Fue la mayor mejora en calidad de todo el proyecto.
• Verificar las firmas de los webhook desde el primer día significó que la seguridad formaba parte del diseño, y no algo que se añadió posteriormente.
• Mantener el historial de revisiones en PostgreSQL, aunque de forma simple, permitió identificar patrones posteriormente, como los tipos de problemas que aparecían constantemente en las PRs.

Lo que siguió siendo difícil

• Los falsos positivos forman parte inevitable del proceso. Las revisiones basadas en LLM a veces marcan como problemas cosas que en realidad no lo son, y los documentos deberían indicarlo abiertamente. La confianza es más importante que una lista impresionante de funciones.
• Los costos aumentan con el uso. Tres llamadas a LLM por PR son más precisas que una sola, pero cuestan más y toman más tiempo. Un equipo pequeño necesita encontrar un equilibrio entre la calidad de la revisión y el precio que puede permitirse.
• Hacer que los comentarios parezcan escritos por una persona requirió más iteraciones en las instrucciones que la lógica de LangGraph. Los comentarios deben ser breves, específicos y estar relacionados con un número de línea, ya que nadie lee un ensayo de cinco párrafos escrito por una IA en un hilo de PR.

El bot forma parte de una familia de pequeños experimentos de código abierto que aplican la orquestación de LLM con LangChain y LangGraph a problemas concretos de flujos de trabajo, como preguntas y respuestas sobre documentos mediante RAG, preguntas y respuestas relacionadas con políticas para servicios dirigidos a los ciudadanos y la conversión de notas de voz en historias de usuario Agile, en lugar de crear demos genéricas. No se trata de un producto terminado listo para desplegarse en cualquier lugar; es un punto de partida funcional sobre el cual un equipo puede seguir trabajando y adaptarlo a su propia configuración.

Probándolo localmente

El repositorio se ejecuta rápidamente. Clónelo, instale las dependencias y inicie el servidor de desarrollo:

git clone https://github.com/Srameshgitnow/agentic-code-reviewer.git
cd agentic-code-reviewer
npm install
npm run dev

El README abarca la configuración completa, las variables de entorno y cómo conectar el webhook de GitHub. Los comentarios sobre falsos positivos o ideas para el flujo de LangGraph son los tipos de informes que más ayudan.