Triage de IA para issues de GitHub/Jira

Un agente de IA basado en un modelo de IA se conecta a su repositorio de GitHub y/o instancia de Jira y procesa cada nuevo issue en el momento de su creación. El sistema extrae el significado del texto no estructurado del título y la descripción, clasifica el ticket según la taxonomía interna del equipo y ejecuta las acciones estándar de triaje sin intervención del ingeniero.

Lo que hace la automatización en la práctica:

1. Recibe el nuevo issue a través de webhook (GitHub Issues API o Jira Webhooks) inmediatamente después de su creación.
2. Extrae las entidades clave de la descripción: tipo (bug/feature/question), componente o módulo afectado, versiones mencionadas, entorno, stacktrace.
3. Determina la prioridad según las reglas del equipo: severity, affected users, business impact.
4. Asigna labels y components de acuerdo con la taxonomía aprobada.
5. Busca duplicados — búsqueda semántica en los issues ya abiertos de los últimos 6-12 meses.
6. Asigna un responsable: por componente, por module ownership, por round-robin dentro del equipo.
7. Deja un comentario con un resumen breve y estructurado para el ingeniero — qué falló, dónde, cómo reproducirlo, tickets similares.
8. Escala al canal de Slack del equipo si el issue está marcado como critical o se parece a un production incident.

Resultado en la práctica de implementación: un ingeniero senior dedicaba 3 horas a la semana al triaje manual — pasó a 20 minutos de revisión rápida de casos límite. El Time-to-label se redujo de 18 horas a 2 horas. Los duplicados se detectan automáticamente — antes se tardaba hasta 1-2 días en que alguien notara la repetición.

Lo que la automatización NO hace

Los límites reales de responsabilidad del agente de IA:

• No toma decisiones de ingeniería. El triaje aplica el etiquetado y asigna un responsable, pero no decide «corregirlo ahora o no» ni «en qué sprint» — eso queda en manos del tech lead.
• No cierra issues. Incluso los duplicados evidentes el agente los marca y enlaza, pero el cierre definitivo lo hace una persona — es una salvaguarda contra falsos positivos.
• No trabaja con arquitectura privada sin contexto. El agente necesita una taxonomía de labels completa, un module ownership map y ejemplos de tickets correctamente etiquetados.

Arquitectónicamente, la automatización se construye como un slim-servicio entre el issue tracker y el LLM: el webhook captura el evento, se recopila el contexto (texto del issue, tickets abiertos similares, module ownership, ejemplos previamente etiquetados), el LLM devuelve un JSON estructurado con la clasificación, la respuesta se aplica al issue a través de la API de la plataforma. Todo está envuelto en lógica de retry y human-in-the-loop para los casos dudosos.

Secuencia técnica

1. El webhook de GitHub o Jira llega al servicio de triaje (FastAPI o Node) ante los eventos issues.opened y issues.edited.
2. El servicio recopila el contexto: título, descripción, autor, labels existentes, lista de posibles duplicados (top-5 por embedding similarity del índice vectorial).
3. El servicio construye el prompt para el modelo de IA: se transmite la taxonomía de labels, el module ownership map, ejemplos few-shot de issues previamente etiquetados correctamente y el propio texto del nuevo ticket.
4. Claude devuelve un JSON: { labels, priority, component, owner, duplicate_candidates, summary, confidence }.
5. El servicio valida el JSON según el esquema: si el nivel de confidence está por debajo del umbral (por ejemplo, 0.75), marca el issue con la etiqueta needs-human-triage y no asigna propietario.
6. Para los casos confident, el servicio aplica labels y assignee a través de la API de GitHub o Jira, deja un comentario con el resumen y los enlaces a tickets similares.
7. Los issues críticos se escalan al canal de Slack del equipo a través de un incoming webhook.
8. Cada acción se registra en el audit log — se puede rastrear qué y por qué modificó el agente.

Componentes de la solución

Por qué custom-code y no no-code listo para usar

Para el triaje de issues son importantes tres cosas que los constructores prefabricados cubren de forma deficiente: control preciso sobre el prompt y los ejemplos few-shot (su taxonomía es específica), el índice vectorial de duplicados con persistent store embeddings y un audit log transparente. Todo esto se resuelve en ~500-800 líneas de Python o TypeScript con un cliente LLM, una BD vectorial (pgvector, Qdrant) y dos integraciones API. Stack típico: FastAPI + PostgreSQL con pgvector + modelo de IA a través de Anthropic SDK + Octokit o Jira REST.

Human-in-the-loop como valor por defecto

El agente no opera con plena confianza. Dos mecanismos garantizan la seguridad:

1. Confidence threshold — cuando el nivel está por debajo del umbral, la decisión se marca como needs-human-triage, no se asignan labels.
2. Weekly review — una vez a la semana el tech lead coteja 20 decisiones aleatorias del agente con la realidad, los ejemplos few-shot se actualizan, la calidad no se degrada.

Conclusión: la mayor parte de los issues se etiqueta sin participación del ingeniero, los casos dudosos pasan al triaje manual — pero ya con un resumen preparado por el agente y candidatos a duplicados, lo que igualmente agiliza el trabajo.

Para iniciar el triaje, el equipo necesita datos preparados, accesos y una preparación organizativa mínima.

Datos y accesos:

• GitHub Personal Access Token (scope repo) o Jira API token con permisos de escritura de labels, assignee y comentarios.
• Taxonomía de labels aprobada — lista de tipos (bug/feature/task), prioridades y componentes. Habitualmente 15-40 categorías.
• Module ownership map: qué persona o equipo es responsable de qué componente o módulo.
• 100-200 issues correctamente etiquetados en los últimos 6-12 meses — para ejemplos few-shot y la construcción del índice vectorial de duplicados.
• Clave API de Anthropic para el modelo de IA.

Infraestructura:

• Servidor o plataforma managed para el servicio de triaje (VPS, Render, Railway, AWS Lambda — cualquier opción es válida).
• PostgreSQL con pgvector o Qdrant/Weaviate para el índice vectorial.
• Slack workspace e incoming webhook si se requiere la escalación de issues críticos.

Preparación del equipo:

• Tech lead o ingeniero senior como owner de la automatización — coordina la taxonomía y verifica la calidad las primeras 2-3 semanas.
• 30-40 minutos por semana del owner para el weekly review de las decisiones del agente en el primer mes, luego 15 minutos.
• El equipo acepta las reglas: los duplicados se enlazan automáticamente, pero los cierra una persona.

Cronograma de implementación:

Para complexity «week», el plazo esperado es de 2-4 semanas. Semana 1 — coordinación de la taxonomía y preparación del dataset few-shot. Semana 2 — implementación del servicio y conexión de webhooks. Semana 3 — shadow mode (el agente registra las decisiones en el log, pero no las aplica), calibración del confidence threshold. Semana 4 — transición a producción con human review.