La inteligencia artificial (IA) ya no solo destaca en la codificación, sino que además ha demostrado ser más rápida y eficiente en casi todas las demás áreas relacionadas con el desarrollo de software: planificación, aseguramiento de calidad (QA) o manejo de herramientas dentro del ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés).
A pesar de ello, en la mayoría de los entornos de trabajo actuales no se permite que los agentes de IA lleven a cabo de forma autónoma todo el proceso que va desde la creación del ticket hasta el despliegue en producción. ¿Por qué? Principalmente porque las metodologías vigentes dependen en gran medida de procesos manuales como aprobaciones, revisiones y entregas que, aunque generan sensación de control, son en muchos casos innecesarias y limitan la efectividad real de la automatización.
«Los SDLC actuales son manuales. Las aprobaciones, revisiones y entregas son teatro para los agentes, que solo quieren avanzar.»
Para superar esta limitación urge replantear cómo se estructura la entrega de software, priorizando a los agentes de IA para que puedan desarrollar su potencial. Esto requiere que se implementen tres componentes clave en la infraestructura:
- Contexto: el agente debe partir de una visión completa del trabajo, no solo del título del ticket.
- Guardarraíles: delimitaciones claras sobre qué acciones están permitidas para el agente, qué debe evitar y cuándo debe solicitar intervención humana.
- Visibilidad: que los ingenieros puedan supervisar el progreso sin necesidad de monitorear manualmente los registros de los agentes durante todo el día.
El flujo de trabajo: de ticket a producción
El proceso completo consta de cinco fases alternadas entre fases de trabajo del agente y controles humanos:
- Fase 1: Planificación. Se transforma el ticket inicial en un elemento enriquecido con contexto, documento de requisitos (PRD) y especificación técnica completa.
- Fase 2: Revisión. Un scorecard automático valida si el trabajo está listo para que lo aborde un agente. Un gestor de producto (PM) y un ingeniero validan la especificación y el PRD antes de delegar al agente de desarrollo.
- Fase 3: Desarrollo. Un agente especializado en codificación, como Claude Code o Cursor, toma el ticket y desarrolla el código manteniendo actualizada la entidad de trabajo.
- Fase 4: Previsualización. Una vez abierto el pull request (PR) y desplegado en un entorno en la nube, un ingeniero y el PM revisan el avance y lo preparan para despliegue.
- Fase 5: Despliegue. Validaciones en tiempo real contra incidentes y ventanas de congelación aseguran condiciones óptimas, se generan notas de versión y se realiza el despliegue.
Contexto rico para los agentes: el “context lake”
Para que los agentes puedan operar eficazmente necesitan acceder a un repositorio vivo y actualizado de información sobre los sistemas de ingeniería, denominado “context lake”. Este debe incluir datos como:
- Catálogo de servicios con su nivel de criticidad (T1, T2, T3), equipo responsable y repositorios asociados.
- Datos sincronizados automáticamente de GitHub: repositorios, PRs abiertos, commits recientes y propietarios de código.
- Tickets, issues o tareas de Jira, Linear o GitHub Issues relacionados con los servicios afectados.
Además, el canal de información puede enriquecerse solicitando datos a sistemas externos como runbooks, documentos ADR, o notas históricas almacenadas en plataformas como Notion o Confluence. También es posible conectar con herramientas de soporte al cliente para incorporar problemas reales que ayudan a mejorar los PRD.
Fase 1: Planificación detallada
La activación del flujo comienza con la creación de un ticket. A partir de este, se enriquece el registro con datos completos del contexto y se elaboran los documentos que detallan qué construir y cómo, en dos etapas:
- Enriquecimiento automático: el sistema recupera información del context lake, rellena el alcance, el equipo y otros datos relevantes, así como calcula el “blast radius” (radio de impacto del cambio) y verifica incidentes abiertos o PRs relacionados.
- Borrador de PRD: la IA crea una primera versión del documento de requisitos basado en el ticket y casos similares previos. Luego el PM revisa y puede interactuar con la IA para aclarar dudas y ampliar detalles, ajustando el PRD hasta considerarlo listo.
- Borrador de especificación técnica: a continuación, se genera un documento técnico usando datos del código y decisiones previas, que el ingeniero revisa y ajusta con soporte interactivo de la IA para garantizar precisión y coherencia.
Fase 2: Revisión y validación
Antes de delegar el trabajo a un agente de codificación, un scorecard automatizado evalúa si el ticket cumple criterios estrictos de seguridad y alcance para la automatización. Algunas reglas son:
- Los servicios críticos (Tier 1) quedan excluidos y exigen trabajo manual.
- Tickets con radio de impacto alto o sin valoración quedan bloqueados para evitar riesgos.
- No se permite trabajar sobre servicios con incidentes activos.
- Prioridades críticas como P0 o P1 se atienden directamente por humanos.
- Documentación incompleta bloquea la automatización.
Paralelamente, se propone una visualización de Kanban integral donde se muestra el estado de cada ticket, permitiendo supervisar fácilmente el avance del trabajo delegado a agentes sin perder visibilidad, incluso con múltiples agentes trabajando en paralelo.
Fase 3: Desarrollo automático
Una vez aprobado, el ticket se delega al agente de código con toda la información recopilada. Se implementa un botón “Delegar a Claude Code/Cursor” que lanza al agente con un briefing detallado. Al mismo tiempo, se configuran automatizaciones que monitorizan el estado del código en GitHub:
- Apertura de PR: actualiza la entidad y cambia su estado a “delegado”.
- Fusión del PR: marca la tarea como completada con fecha y hora.
- Fallos en integración continua (CI): marcan el ticket para revisión.
Esto mantiene una supervisión precisa sin necesidad de consultar los logs del agente o las notificaciones externas.
Fase 4: Previsualización y revisión humana
Cuando el PR está abierto, se despliega en un entorno temporal en la nube para que el PM y el ingeniero puedan revisar visualmente y validar el resultado. Es posible añadir controles automáticos que comparen las modificaciones con la especificación técnica y alerten sobre desviaciones, además de automatizar recordatorios para revisores.
Fase 5: Despliegue seguro
El despliegue solo se ejecuta cuando las condiciones son óptimas y aprobadas. El sistema verifica:
- Ausencia de incidentes activos en zonas de impacto.
- No estar dentro de ventanas de congelación o despliegues simultáneos.
- Si el radio de impacto es alto, se requiere aprobación explícita.
Tras realizar las validaciones, se genera automáticamente la nota de versión con detalles técnicos y de negocio. Si surge algún problema, la reversión es tan sencilla como un clic en la interfaz.
Métricas para evaluar la eficiencia del flujo
Implementar esta automatización implica medir resultados detalladamente para detectar cuellos de botella y monitorizar la evolución. Algunas métricas clave son:
- Tiempo medio hasta producción por servicio: permite identificar qué equipos y servicios tienen mayor autonomía.
- Tiempo invertido en cada fase: para saber dónde se acumula trabajo y ajustar reglas o recursos.
- Tasa de delegación: porcentaje de tickets gestionados por agentes frente a los manuales.
- Intervenciones humanas: fases donde se requiere atención y posibles mejoras en contexto o reglas.
Estos indicadores ofrecen una visión profunda más allá del simple tiempo de ciclo, revelando la eficacia real del sistema y su impacto en la productividad.
En definitiva, este sistema integral permite convertir tickets simples en despliegues monitorizados y controlados, con agentes de IA realizando hasta el 40% del trabajo bajo supervisión estructurada y puntos de control humanos. Aplicar esta metodología abre la puerta a una ingeniería mucho más autónoma, eficiente y escalable.
