Tratando el backlog como una cola de tareas pequeñas y bien descritas. Los agentes de IA pueden tomar los tickets de un backlog de Jira uno a uno, hacer cada cambio en su propia rama y abrir un pull request, mientras las personas conservan las decisiones importantes. El trabajo depende menos del agente y más de lo preparados que estén tus tickets.
Empieza por ordenar el backlog
Los agentes no necesitan un backlog perfecto, pero sí tickets que puedan terminar. Ordenar el backlog en cuatro grupos antes de empezar evita la mayoría de las ejecuciones en vano.
| Tipo de ticket | ¿Dárselo a un agente? | Qué hacer primero |
|---|---|---|
| Resultado claro, alcance pequeño, forma de comprobarlo | Sí | Entrégalo tal cual. |
| Buena idea, descripción vaga | Aún no | Añade cómo se ve terminado e indica la zona del código. |
| Dos tareas en un ticket | No | Divídelo en dos tickets. |
| Requiere una decisión de diseño o de producto | No | Que una persona decida primero y escribe la decisión en el ticket. |
Jira puede ayudarte a encontrar los primeros candidatos. Su lenguaje de consulta, JQL, te permite guardar un filtro que lista tickets por estado, etiqueta o antigüedad, como explica la guía de JQL de Atlassian. Empieza con un filtro de tickets pequeños que ya tengan una descripción clara.
Cómo es un ticket que un agente puede terminar
Aquí tienes un ejemplo, escrito como lo escribiría un product owner en Jira. Es pequeño, dice qué significa "terminado" y nombra dónde está el trabajo.
PAY-214: añadir exportación a CSV en la página de facturas
Resultado: un usuario de finanzas puede descargar como archivo CSV la lista de facturas filtrada.
Terminado cuando: el archivo tiene las mismas columnas que la tabla, respeta el filtro en pantalla y una prueba cubre el caso de lista vacía.
Área: la página de facturas y su API. Fuera de alcance: exportación a PDF.
Escribirlo lleva más o menos un minuto. Sin las tres últimas líneas, es el tipo de ticket en el que un agente tiene que adivinar, y de las suposiciones sale el retrabajo.
Un ticket, paso a paso
Así recorre PAY-214 las nueve etapas del pipeline de Dutopilot: architect, planner, implementer, control, tres revisores, autofixer y QA. Antes de la primera etapa, las personas definen una vez por proyecto los puntos de aprobación humana y se recoge el ticket. Después de la última, una persona hace el lanzamiento a producción.
| Paso | Qué hace el agente | Qué ves tú |
|---|---|---|
| Antes de las etapas: recoger | Lee PAY-214 y la página de diseño que enlaza, y confirma que el ticket está listo. | Un comentario que dice que el ticket se recogió y está listo. |
| 1. Architect | Propone qué archivos cambian (la página de facturas y el endpoint de exportación), cómo fluyen los datos y qué pruebas añadir. | El plan como comentario. Una persona designada lo aprueba antes de escribir código. |
| 2. Planner | Convierte el plan aprobado en una lista ordenada de tareas para el implementer. | La lista de tareas en el ticket. |
| 3. Implementer | Escribe el cambio en su propia rama dentro de un entorno aislado y abre un pull request. | Una rama con el nombre del ticket y un pull request enlazado a PAY-214. |
| 4. Control | Ejecuta lint, build y pruebas y devuelve un único veredicto. | Un solo resultado de verificación en el pull request, en lugar de señales dispersas. |
| 5 a 7. Tres revisores | Tres miembros virtuales del equipo de Dutopilot independientes leen el cambio por su cuenta. Uno nota que la exportación ignora el filtro en pantalla. | Comentarios de revisión en el pull request, escritos como lo haría una persona de tu equipo. |
| 8. Autofixer | Un agente corrector recibe el comentario o el log que falló, repara el código y el control se ejecuta de nuevo. | Un commit nuevo y un resultado de verificación actualizado. |
| 9. QA | Con todas las verificaciones en verde, el pull request se fusiona respetando la protección de tu rama y llega a tu entorno de pruebas, donde QA prueba el resultado. | El ticket pasa a tu estado de pruebas. |
| Después de las etapas: lanzamiento | Espera a una persona y luego despliega por el mismo pipeline. | Una solicitud de aprobación del lanzamiento. |
Dos puntos esperan a una persona por defecto: el plan y el lanzamiento a producción. Todo lo que hay entre ambos corre sin que nadie mire, y cada etapa escribe en el ticket, así que lees la historia después en lugar de asistir a ella.
Mantén muchos tickets en marcha sin choques
Lo difícil de un backlog grande no es un ticket, sino muchos a la vez. Dale a cada ticket su propia rama, haz que los tickets que dependen de otros esperen al que necesitan y limita cuántos se ejecutan a la vez a lo que tu equipo puede revisar. Si dos tickets tocan los mismos archivos, ejecútalos uno tras otro.
Imagina que PAY-215 es un botón de exportar en el panel que necesita el endpoint de PAY-214. Márcalo en Jira como bloqueado por PAY-214 y espera, y luego arranca con código que ya incluye el endpoint. Dos tickets sin relación, como un cambio de texto y un informe nuevo, corren en paralelo sin enterarse el uno del otro. Antes de empezar, cada ticket trae por sí mismo el código más reciente de tu rama principal, así que ningún ticket espera a que alguien actualice una rama a mano.
Lo que configuras
- Conecta tu proyecto de Jira y tu plataforma de código (GitHub, GitLab, Bitbucket o Azure DevOps).
- Elige con qué parte del backlog empezar, por ejemplo una etiqueta o un filtro guardado.
- Indica quién aprueba el plan y el lanzamiento a producción, y qué partes del código necesitan un revisor concreto.
- Conecta tu propia suscripción de Claude o Codex, o una clave de API.
La mayoría de los equipos ejecuta su primer ticket en una semana.
Qué hace tu Forward Deployed Engineer
Cada cliente de Dutopilot tiene un Forward Deployed Engineer: un ingeniero de Dutopilot que trabaja con tu equipo, no una cola de soporte. No escribe el código de tu producto. Hace que el pipeline encaje con tu forma de trabajar actual.
- Puesta en marcha: conecta tus herramientas contigo y elige la primera parte del backlog.
- Tickets listos: repasa los primeros tickets con tu product owner y acordáis una plantilla corta como la de arriba.
- Aprobaciones y controles: define qué planes y qué partes del código necesitan a una persona y cuáles no, según cómo revisa de verdad tu equipo.
- Primeras ejecuciones: acompaña los primeros tickets contigo y arregla lo que frene una ejecución.
- Día a día: revisa contigo los tickets atascados y los hallazgos de revisión, y afloja o aprieta los controles según lo que muestre el historial.
Cómo lo hace Dutopilot
Dutopilot se conecta a tu backlog de Jira y lo recorre con su pipeline de nueve etapas: planifica el cambio, lo construye en un entorno aislado, ejecuta las pruebas y las comprobaciones de calidad, lo somete a la revisión de tres revisores distintos, corrige lo que falla y fusiona cuando están las aprobaciones que elegiste. Cada etapa se escribe de vuelta en el ticket, así que el backlog siempre muestra en qué punto está cada uno.
Tu protección de ramas y las revisiones obligatorias siguen aplicándose, y nunca guardamos una copia de tu repositorio. Además de Jira, Dutopilot funciona con Linear, Notion, GitHub Issues y Azure DevOps para el backlog, y con Slack. La guía sobre cómo pasar de un ticket de Jira a un pull request fusionado muestra un ticket de principio a fin.
Motivos habituales por los que una ejecución se detiene
- La descripción no tiene criterios de aceptación, así que el agente debe adivinar qué significa terminado.
- El ticket mezcla dos tareas y el pull request crece demasiado para revisarlo.
- Las pruebas son lentas o inestables y nadie sabe si el cambio funciona.
- No hay un aprobador asignado, así que un pull request terminado se queda esperando.
Corrige esto en el backlog y la tasa de éxito sube sin tocar nada del agente.
Dónde siguen al mando las personas
- Antes de escribir código: una persona decide la arquitectura de lo nuevo o arriesgado.
- En la fusión: una persona designada aprueba los cambios en las áreas más críticas.
- En el lanzamiento: la salida a producción sigue tu propio proceso.
Añade aprobaciones donde quieras y quítalas a medida que crezca la confianza. La guía sobre cómo elegir qué pasos necesitan aprobación explica cómo decidirlo.
Preguntas frecuentes
¿Los agentes de IA necesitan un backlog ordenado?
No, pero cada ticket que toma un agente necesita un resultado claro, un alcance pequeño y una forma de comprobarlo. Deja los tickets confusos en el backlog y ordénalos antes.
¿Qué pasa cuando un agente se atasca?
Una buena configuración hace que el agente lo diga en el ticket y se detenga, en lugar de adivinar. En Dutopilot el ticket muestra qué lo bloquea y qué puede hacer una persona, y una respuesta suya permite que el trabajo continúe.
¿Podemos usar nuestra propia suscripción de IA?
Sí. Dutopilot funciona con tu propia cuenta de Claude o ChatGPT (Codex), o una clave de API, con Claude Code, Codex, OpenCode u Oh My Pi como agente de programación, así que los miembros virtuales del equipo de Dutopilot trabajan bajo las condiciones y los límites que ya tienes.
¿Cuánto tarda en ejecutarse el primer ticket?
La mayoría de los equipos ejecuta su primer ticket en una semana: conectas el backlog y el proyecto, apuntas Dutopilot a una parte del backlog y luego amplías poco a poco.