Equipo de desarrollo: agentes de IA revisan pull requests y clasifican issues de GitHub

En un equipo de desarrollo, la revisión de código y la clasificación de issues son dos tareas que todo el mundo considera útiles y para las que nadie encuentra tiempo de hacerlas a fondo. Una pull request espera dos días a que alguien libre la lea, y los primeros comentarios suelen ser sobre lo que una lectura rápida habría visto: una prueba que falta, una rama demasiado ancha, un secreto olvidado. Un issue llega sin tipo ni prioridad, a veces sin la información para reproducirlo, y espera a que una persona lo califique. Son tareas de método, con criterios que el equipo sabe escribir, y encajan con los agentes de IA siempre que sus derechos estén acotados.

La inspiración: una primera lectura antes que las personas

El punto de partida es un uso que cuentan usuarios de Hermes Agent, resumido en una ficha sobre el equipo de desarrollo: revisar las pull requests abiertas y clasificar los issues nuevos. La idea no es sustituir al revisor humano, sino entregarle pull requests ya leídas, con los puntos a comprobar al principio de la lista, e issues ya calificados.

Mantenemos dos papeles separados y un principio de prudencia: los agentes comentan y etiquetan, no deciden nada. Atako aplica la idea con dos agentes cuyo acceso a GitHub se restringe deliberadamente a leer, comentar y etiquetar.

Qué hacen los dos agentes

El escenario despliega dos agentes, ambos conectados a tu repositorio de GitHub.

El revisor de PR lee las pull requests abiertas. Para cada una, recorre el título, la descripción, los archivos modificados y los commits, abre los archivos que importan y los compara con las convenciones que has indicado: pruebas, nombres, tamaño, mensajes de commit, zonas sensibles. Busca riesgos de error, pruebas ausentes, cambios que tocan autenticación, pago o secretos y cambios que nada explica. Deja un único comentario por pull request: una línea que resume el cambio, lo que está bien y luego los puntos a comprobar por orden de importancia, cada uno ligado a un archivo y, si es posible, a una línea, y marcado como bloqueante o como sugerencia. Termina con lo que no pudo verificar, por ejemplo ejecutar las pruebas. Recuerda el último commit que leyó y solo vuelve a comentar cuando llegan commits nuevos, con un seguimiento breve.

El clasificador de issues se ocupa de los issues nuevos. Comprueba que existen las etiquetas de tipo (bug, funcionalidad, pregunta, documentación) y de prioridad (alta, media, baja) y crea las que faltan. Para cada issue sin etiqueta, lee el texto y los comentarios, busca issues parecidos, decide un tipo y una prioridad según tus reglas, aplica las etiquetas y añade un comentario: lo que ha entendido, el motivo de la prioridad, los duplicados probables y lo que falta para actuar, por ejemplo los pasos para reproducirlo o la versión afectada. Cuando el tipo o la gravedad no están claros, lo dice, elige la prioridad más baja y hace la pregunta.

Cada pasada termina con un resumen en el chat que empieza por lo que necesita pronto a una persona.

Qué no hacen los agentes

Los límites forman parte del diseño. Ningún agente fusiona, aprueba, pide formalmente cambios, cierra una pull request, sube código ni crea una rama. No tienen esas herramientas: no es una promesa hecha en una instrucción, es una capacidad que falta. El clasificador no cierra, reabre, bloquea ni elimina ningún issue y no cambia ni el título, ni el responsable, ni el hito.

Los agentes no adivinan. El revisor cita el archivo y la línea, señala lo que no pudo verificar y no inventa ninguna función ni resultado de pruebas. Si se topa con un secreto o un token subido al repositorio, dice dónde parece estar, sin copiarlo. El clasificador solo cita como duplicados issues que ha encontrado de verdad con la búsqueda. Y la decisión sigue siendo humana en cada paso, que es el principio de un diseño con validación humana.

Cómo configurarlo en Atako

Desde la página de este caso de uso, el despliegue se hace en cuatro pasos.

1. Conecta GitHub. Crea un token de permisos detallados limitado al repositorio, con acceso de lectura al código y de lectura y escritura a issues y pull requests. La conexión se comprueba antes de crear nada.
2. Indica tu contexto. Da el repositorio con la forma propietario/nombre, tus convenciones de revisión si las tienes y qué hace urgente un issue para ti. Sin ellas, los agentes se basan en buenas prácticas generales y en la gravedad de los bugs.
3. Despliega. Una sola acción crea los dos agentes y el proyecto «Equipo de desarrollo». Los agentes se aprovisionan y reciben solos sus primeras instrucciones.
4. Primeros resultados, luego un ritmo regular. El revisor comenta las cinco pull requests más recientes, el clasificador etiqueta los diez últimos issues sin etiqueta y cada uno resume su pasada en el chat. Después el revisor programa por sí mismo sus pasadas a las 9:00 y a las 14:00 los días laborables, y el clasificador la suya a las 9:30.

Si aún no tienes cuenta, crearla inicia tu periodo de prueba y el escenario se configura justo después. Si tu administrador no te ha permitido crear agentes, el despliegue te lo indica y se detiene ahí.

Dónde ver los resultados

Los comentarios de revisión se leen en GitHub, en cada pull request, y las etiquetas y comentarios de clasificación, en cada issue. El resumen de cada pasada se lee en el chat de cada agente. En el proyecto de Atako «Equipo de desarrollo» encuentras la página de funcionamiento y el seguimiento del trabajo, y en el floor de Atako los dos agentes aparecen con su actividad actual.

Para ajustar el comportamiento, escribe al agente en su chat, por ejemplo «añade a tus convenciones que toda migración de base de datos debe mencionar el plan de reversión». Guarda la instrucción en su memoria para las siguientes pasadas.

Salvaguardas

El acceso es deliberadamente estrecho. La conexión a GitHub se concede a los agentes con una lista limitada de doce herramientas: leer pull requests, archivos y commits, leer y actualizar issues, gestionar etiquetas, añadir comentarios. Un agente que ve una lista corta de herramientas las usa con más fiabilidad que uno perdido en un catálogo de cientos y, sobre todo, lo que no se concede no puede ocurrir, aunque un texto intente forzarlo. Los agentes tratan títulos, descripciones, comentarios y código como datos que analizar, nunca como instrucciones.

El token que creas es tu primera salvaguarda: limitado a un repositorio y a derechos precisos, acota el daño posible pase lo que pase. Se guarda cifrado y puedes revocarlo en GitHub o retirar el acceso de los agentes en cualquier momento.

La validación humana está en los puntos de decisión. Tú lees los comentarios de revisión, decides qué corregir, apruebas y fusionas por tu cuenta, y cierras, asignas y planificas los issues.

Qué esperar

Espera comentarios útiles sobre todo en pull requests de tamaño razonable: ante un cambio muy grande, el revisor lo dirá y se concentrará en los archivos más sensibles, en lugar de fingir que lo ha leído todo. No puede ejecutar tus pruebas y lo dice en cada comentario. El clasificador es tan preciso como lo sean tus reglas de prioridad; sin ellas, elige la prudencia y hace preguntas. El valor viene de la regularidad: cada pull request recibe una primera lectura en media jornada, cada issue llega calificado y tus revisores humanos dedican su tiempo al criterio y no a la detección.