El producto tiene que correr, pero los ingenieros se ahogan en el relevo de feedback, correcciones, revisiones y despliegues: quieres un equipo de desarrollo que no duerme, no una lista de pendientes más larga.
Divide el desarrollo diario de un SaaS por dominios de producto — núcleo de colaboración, runtime, facturación, permisos y backoffice, cada uno con su canal — y asigna a cada dominio un squad residente de Agents que corre a largo plazo: el coordinador hace el triaje del feedback, el implementador toma las correcciones, el revisor controla los merges y el desplegador publica y reporta. La vida entera de una tarea sucede en el flujo de chat, con cada paso citable y reproducible. Los humanos solo aparecen en tres puntos: dirección, prioridades y aceptación. Y el producto que este equipo desarrolla es justo aquel sobre el que trabaja cada día.
Clasifica cada feedback, lo convierte en tarea, completa los criterios de aceptación y persigue el trabajo sin dueño; por defecto no escribe código, solo enlaza y alinea.
Al tomar una tarea abre una rama independiente y un entorno de aceptación aislado con datos propios, entrega primero un enlace clicable para el humano y solo pide el merge tras la aceptación.
Verifica punto por punto límites de permisos, idempotencia y resultados de pruebas, y responde con un GO estructurado o un blocker; el rol de revisor rota dentro del squad, sin cuellos de botella fijos.
Tras el merge ejecuta el despliegue, adjunta la evidencia de los health checks y vuelve al hilo original a reportar "ya está en producción".
Revisa el tablero de tareas a horas fijas: asigna owner a las tareas huérfanas, empuja la cola de revisión y evita tomas duplicadas.
Un ingeniero menciona a un Agent con una captura, o el feedback de usuario pasa por @triaje, que lo clasifica y lo convierte en tarea.
@implementar se asigna la tarea, abre rama y entorno de aceptación aislado, y entrega primero un enlace clicable para que el humano valide.
Superada la aceptación, abre el merge request; @revisar verifica punto por punto y solo con su GO se fusiona a la rama principal.
@desplegar publica, adjunta la evidencia de salud y vuelve al hilo original con "ya está en producción" y cómo verificarlo.
Si aparece un problema nuevo tras salir, el Agent reabre la tarea y repite el ciclo hasta que el humano da el visto bueno.
Cada día, a hora fija, se resumen los errores y anomalías de producción y se publican en el canal para el triaje y la creación de tareas.
Dos veces al día se revisa el tablero de tareas: owner para las tareas huérfanas y cola de revisión a cero.
Tras cada despliegue, un despertador programado verifica los resultados de la prueba de humo; si hace falta, la decisión de rollback se toma en el momento, no en automático.
Añade un squad de Agents de prueba que genere casos de regresión según el incremento de código.
Convierte la línea de despliegue en un Agent de despliegue dedicado, con intención de despliegue y clasificación de riesgo.
Entrega también las preguntas abiertas de diseño de producto a varios Agents en relevo, hasta converger en un consenso.