Asignas la incidencia al agente y el desarrollo arranca solo.
Basta con asignar la incidencia al agente: la analiza, abre la rama y la petición de fusión en borrador, y la implementa. Una persona revisa y fusiona.
El problema
«La incidencia lleva ahí desde que se abrió y nadie la ha leído.» «Antes de escribir una línea hay que analizarla y abrir la rama.» «Lo pequeño nunca llega a empezarse.»
Le pasa a cualquier equipo de desarrollo con más incidencias que manos: cada una espera a que alguien tenga un hueco para arrancarla, y ese arranque es trabajo que no se ve.
Cómo se hace hoy
Cada incidencia espera a que alguien la lea, la analice y abra la rama. Hasta entonces no pasa nada. Y quien la coge dedica el principio a preparar el terreno antes de poder programar.
Cómo lo resolvemos
- Asignas la incidencia al agente, igual que se la asignarías a una persona del equipo. No hay que pedírselo en ningún otro sitio.
- El agente hace el análisis funcional de lo que se pide.
- Crea la rama de trabajo de esa incidencia.
- Abre la petición de fusión en borrador, para que el trabajo se vea desde el principio.
- Implementa el cambio en esa rama y lo deja en la petición de fusión para que una persona lo revise.
Resultado
Es como trabajamos nosotros cada día: una incidencia asignada al agente deja de esperar a que alguien la arranque.
Qué hace falta
Tu repositorio y tus incidencias
Un usuario agente en tu plataforma de código, con permiso para crear ramas y abrir peticiones de fusión. Sin permiso para fusionar.
Incidencias bien descritas
El agente parte de lo que dice la incidencia: qué se quiere y cómo se sabe que está hecho. Si falta, el análisis lo deja a la vista.
Normas del proyecto, por escrito
Cómo se trabaja en el repositorio: ramas, convenciones, qué no se toca. Si no están escritas, las escribimos contigo.
Una persona que revisa y fusiona
Alguien de tu equipo con criterio para aceptar o rechazar el cambio. El agente prepara; la persona decide.
Cómo está hecho
El disparador es la propia asignación: la incidencia se asigna a un usuario agente de la plataforma de código (GitLab en nuestro caso). No hay otra orden que dar ni otra herramienta que abrir.
El agente escribe el análisis funcional, crea la rama feature/ con el número de la incidencia, abre la petición de fusión en borrador y la implementa ahí. Lo que hace queda escrito en la incidencia y en la petición.
El agente no fusiona ni publica. Trabaja en su propia copia aislada del código y las contraseñas no llegan nunca al modelo. Antes de producción, el cambio pasa por la misma revisión que cualquier otro.
Preguntas frecuentes
¿Qué tengo que hacer para que el agente empiece?
Asignarle la incidencia. A partir de ahí hace el análisis funcional, crea la rama, abre la petición de fusión en borrador y la implementa.
¿Puede el agente fusionar su propio cambio?
No. Una persona revisa la petición de fusión y la fusión la hace siempre una persona.
¿Qué pasa si la incidencia está mal descrita?
El agente parte de lo que está escrito. Por eso el análisis funcional va primero y a la vista: quien revisa ve qué ha entendido antes de mirar el código.
Automatizaciones relacionadas
Orquestador de agentes
Un director reparte cada objetivo entre varios agentes que trabajan en paralelo. Una persona aprueba.
Revisión de código
Cuatro agentes revisan cada cambio antes de producción. Una persona decide si entra.
Forma parte de Desarrollo con agentes de IA
El siguiente paso
Cuéntanos cómo trabaja hoy tu empresa y te decimos por dónde empezar.