Linty, un agente autónomo que atiende Jira 24/7: 81 tickets en 5 días sin intervención humana

El contexto: 16 tickets al día que alguien tiene que atender

El equipo de desarrollo del que te voy a hablar mueve decenas de tickets de Jira al día. Bugs reportados por Customer Success, mejoras planteadas por producto, tareas técnicas internas, épicas complejas descompuestas en historias. Cada uno necesita una primera pasada: entender qué se pide, mirar el código donde ocurre, decidir si hay que pedir más información, si se puede resolver ya, o si entra al backlog con un plan.

Esa primera pasada cuesta tiempo. Y muchas veces es la que se atasca: el ticket entra un lunes y nadie lo mira hasta el jueves porque el equipo está en sprint.

La decisión: dejar que un agente haga la primera pasada — en el repo correcto

Teníamos varios repos internos (producto principal, plataforma de IA interna, app factory, analytics). Cada uno con su código, sus convenciones, su historial. Un LLM suelto sin contexto de repo se inventa medio ticket. Un LLM con el repo equivocado es todavía peor.

La decisión clave: no un agente, sino un sistema que distribuye tickets a la instancia de agente con el contexto correcto. Cada ticket tiene que caer en el repo adecuado antes de que ningún modelo empiece a razonar.

Qué construí: Linty, un empleado digital con contexto de repo

Linty es el usuario de Jira detrás del sistema. Por fuera, un miembro más del equipo: se le asigna un ticket, comenta, transiciona estados, responde menciones. Por dentro, un sistema de orquestación que:

• Sondea Jira cada 5 minutos buscando eventos (nuevos tickets, comentarios, menciones, cambios de estado)
• Enruta cada evento al repo correcto usando un router con keywords y labels por repo
• Lanza una instancia de Claude Code en ese repo con el contexto del ticket y el prompt adecuado
• Usa un mecanismo de locks para que dos instancias no pisen el mismo ticket
• Persiste estado para no reprocesar eventos ya atendidos
• Si un ticket no encaja en ningún repo, lo deja marcado para revisión humana en vez de inventar una respuesta

Los cuatro tipos de evento que dispara Linty

1. Nuevos tickets — Linty los lee, identifica el repo implicado, hace una pasada inicial: comenta con preguntas si falta información, propone un plan si el problema está claro, o abre una rama y empieza a trabajar si es un bug bien acotado.
2. Comentarios — Si alguien comenta un ticket mencionando a Linty o pidiendo una acción, Linty responde en contexto con lo que ya sabe del ticket + el estado actual del código.
3. Cambios de estado — Transiciones como “en pruebas” o “bloqueado” disparan validaciones. Linty verifica que el código está donde corresponde y que no falta nada antes de seguir adelante.
4. Menciones — Cualquier @linty en un comentario dispara una atención específica. Es la forma de pedirle al agente una intervención puntual sin crear un ticket nuevo.

La arquitectura: un watcher que distribuye a agentes especializados

Lo que lo hace funcionar en producción no es el modelo. Es la capa de orquestación:

• Loop cada 5 minutos: suficiente para que el equipo perciba el agente “presente” sin saturar la API de Jira
• Router por repo: un JSON de configuración que define qué keywords, labels y proyectos le pertenecen a cada repo. Si un ticket encaja en dos repos, se elige el que tenga más peso semántico
• Locks por ticket: un directorio de ficheros <KEY>.lock evita que dos instancias trabajen el mismo ticket simultáneamente. Auto-purga a las 24h
• Estado persistente: keys de tickets ya disparados guardadas en disco para que un reinicio no rehaga trabajo
• Log de tickets ignorados: cualquier ticket que no encaje en ningún repo se registra para revisión manual — no se pierde, pero tampoco se inventa

Cada instancia de Claude corre en un contexto aislado: su repo, su historial, sus convenciones. No hay mezcla de contextos entre repos. Eso es lo que hace que las respuestas sean útiles y no genéricas.

Resultados en los primeros 5 días

Desde el 17 de abril de 2026:

• 81 tickets tocados por Linty (como assignee o reporter) en 5 días calendario
• 16 tickets/día de media
• 30 tickets cerrados (FINALIZADO OK, Finalizada o CANCELADO) — un 37% del total
• 51 tickets activos en distintas fases del flujo: en curso, planificables, en pruebas, desarrollo, despliegue
• Cobertura completa de la escala de prioridades: 2 críticos, 12 altos, 26 medios, 40 bajos, 1 mínima
• Dos proyectos atendidos simultáneamente: infraestructura interna (43 tickets) y producto principal (38 tickets)

Ejemplos de lo que atendió Linty estos días:

• Un bug crítico de seguridad: SAS tokens filtrados en URLs públicas
• Un bug contable: transacciones con error de impuestos generando balances negativos
• Una historia compleja: agente SQL agéntico con self-verification sobre Gemini
• Una epic multi-fase: rellenado automático de ficha Play Console descompuesto en 8 historias
• Mejoras pequeñas de UX: redimensionar imágenes en un modal, ordenar listados

Toda la escala, de un riesgo crítico a una mejora trivial, en el mismo sistema.

Lección: un empleado digital que atiende a otros empleados digitales

La parte que más me gusta es la meta-idea. Linty no resuelve tickets él — distribuye el trabajo a otros agentes (instancias de Claude Code) que ya tienen el contexto del repo donde hay que actuar. Es un empleado digital que gestiona a otros empleados digitales.

El valor no está en que un LLM “sea listo”. Está en que cada ticket aterrice en la instancia con el contexto adecuado, con el lock activado, con el estado correcto, y que el resultado vuelva a Jira sin perderse por el camino. Ingeniería clásica alrededor de un modelo inteligente.

Y lo que sostiene todo esto es lo de siempre: la IA acelera, la cabeza decide. Linty no decide qué tickets son importantes ni cuál es la estrategia técnica. Hace la primera pasada rápida sobre todo lo que entra, y deja que el equipo humano mantenga el criterio sobre lo que importa.