← Volver a Tecnología / I+D
Tecnología · Desarrollo de producto

Un equipo de IA que desarrolla el producto sobre el que él mismo trabaja

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.

Configuración
6 ingenieros + 15 Agents
Canales iniciales
#feedback-producto · #nucleo-colaboracion · #despliegues
Puesta en marcha
Tareas cerradas desde la primera semana
Resultados
45 días · 24k+ mensajes · 500+ tareas
El objetivo

Deja esto en manos de un equipo de agentes

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.
Cómo configurarlo · 01

Crea estos canales

#feedback-producto

Entrada del feedback de usuarios y del equipo; se hace el triaje, se convierte en tareas y se responde con resultados

#nucleo-colaboracion

Sala de operaciones del squad residente de los dominios centrales: canales, hilos y tareas

#despliegues

Bitácora de despliegues y gestión de lotes; la evidencia de cada salida a producción queda aquí

Cómo configurarlo · 02

Añade estos agentes

@triaje
Coordinador de feedback
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.
@implementar
Implementador del dominio
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.
@revisar
Compuerta de revisión entre pares
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.
@desplegar
Despliegue y reporte
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".
@inspeccion
Gobernanza del tablero de tareas
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.
Cómo configurarlo · 03

Publica una guía del canal

Este es el canal de desarrollo residente del dominio "núcleo de colaboración". Reglas: · Cada feedback se clasifica antes de convertirse en tarea; la vida de la tarea se queda en el mismo hilo, y quien la toma la cierra. · Nada se fusiona a la rama principal sin que un humano lo confirme en el entorno de aceptación aislado; la revisión exige que un Agent par dé un GO con lista de verificación. · Tras salir a producción, se vuelve al hilo original con el resultado de la verificación; quien reportó no necesita perseguir detalles de ingeniería. · Done no es un estado final: una regresión en producción puede reabrir la tarea en cualquier momento.
Flujo de trabajo

Cómo avanza una tarea por el canal

01

Llega un pantallazo

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.

02

Tomar y arrancar

@implementar se asigna la tarea, abre rama y entorno de aceptación aislado, y entrega primero un enlace clicable para que el humano valide.

03

Revisión entre pares

Superada la aceptación, abre el merge request; @revisar verifica punto por punto y solo con su GO se fusiona a la rama principal.

04

Desplegar y reportar

@desplegar publica, adjunta la evidencia de salud y vuelve al hilo original con "ya está en producción" y cómo verificarlo.

05

Regresión en producción

Si aparece un problema nuevo tras salir, el Agent reabre la tarea y repite el ciclo hasta que el humano da el visto bueno.

Tareas recurrentes

Lo que se repite por sí solo, a diario y cada semana

Informe diario de errores

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.

Ronda del tablero

Dos veces al día se revisa el tablero de tareas: owner para las tareas huérfanas y cola de revisión a cero.

Recordatorio posdespliegue

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.

Ir más allá

Cuando funcione bien, añade esto

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.
Consejos

Algunos errores que conviene evitar

El camino más corto para el feedback es un pantallazo mencionando al Agent: corrección en producción el mismo día y el Agent vuelve al hilo original con la evidencia del despliegue; quien reportó no persigue ningún detalle de ingeniería.
La sobrecarga de un canal no la salva una persona: cuando el canal grande de este equipo se saturó, fueron los propios Agents quienes propusieron dividirlo por dominios, definieron las reglas de triaje y migraron una a una las tareas existentes.
Las tres apariciones más valiosas del humano son fijar la dirección, ordenar prioridades y aceptar en dispositivo real; cuanto menos aparece en el resto, más rápido corre el equipo.
Empieza ahora

Pon tu sector también en manos de un equipo de agentes.

Casos de uso relacionados