Parte II. El equipo: personas y agentes
Si no está escrito, cada uno trabaja con su agente
Acuerdos entre personas y agentes: vibe coding o specs, autonomía, Daily y Retrospectiva
Cuatro maneras de trabajar en un equipo de seis
A los tres meses de usar agentes, en GymApp había cuatro maneras de trabajar con ellos. Germán escribía una spec antes de cada cambio y revisaba línea a línea lo que le devolvía el agente. Unai le contaba al agente en el chat lo que quería, probaba el resultado y se quedaba con lo que funcionaba. Aitana usaba el agente para todo, también para los textos de la app.
Y Celia había empezado a generar pantallas que a veces acababan en producción sin pasar por nadie.
Nadie lo había decidido. Funcionó hasta que Unai se fue de vacaciones. Aitana tuvo que cambiar la lista de espera, que había hecho él, y buscó cómo estaba pensada. No había nada escrito: estaba el código, que funcionaba, y una conversación con el agente que solo veía Unai. Le pidió el cambio a su propio agente, que reescribió la lógica a su manera. El viernes, dos socios recibieron la misma plaza.
Olga lo llevó a la Retrospectiva con una sola pregunta: ¿cómo trabajamos con los agentes? Salieron cuatro respuestas, una por persona.
Sin acuerdo, cada uno trabaja con su agente
Un equipo sin agentes ya tenía acuerdos, aunque no los escribiera: cómo se revisa el código, cuándo se integra, qué significa terminado. Con agentes, cada persona tiene además su propia forma de trabajar con la máquina, y esa forma no se ve. No aparece en el tablero ni en el código. Aparece cuando falla.
Por eso la colaboración entre personas y agentes no se puede dejar a la costumbre de cada uno. Hay que escribirla. Un acuerdo de trabajo con agentes recoge lo que un agente no puede deducir y otra persona necesita saber. No es una política de empresa ni un manual: es una página que el equipo escribe, cumple y cambia, como los acuerdos de equipo para usar IA que ya conocen muchos equipos, llevados al trabajo diario con agentes.
Vibe coding para explorar, specs para lo que se queda
La primera decisión del acuerdo es la forma de trabajar. Hay dos, y las dos tienen su sitio.
El vibe coding es pedirle al agente lo que quieres en lenguaje natural, probar lo que sale y seguir pidiendo hasta que funciona. Es rapidísimo y muy útil para explorar: un prototipo para enseñar a cinco socios, una prueba técnica para ver si algo es posible, una herramienta de un solo uso. Su problema es que la intención no queda en ninguna parte.
Queda el código, que dice qué hace, y una conversación que nadie más ve, que decía por qué. Es lo que le pasó a Unai, y lo que me pasó a mí con mi web, como cuento en la introducción.
El Spec-Driven Development (capítulo 5) invierte el orden: primero una spec pequeña con ejemplos, después el agente y después la revisión contra la spec. Es algo más lento al principio y mucho más barato después, porque la intención queda escrita junto al código. Cualquier persona, y cualquier agente, puede leerla dentro de seis meses.
La diferencia se nota sobre todo cuando el trabajo sale del equipo. Otro equipo que quiere reutilizar algo lee la spec, no tu conversación con el agente. Un agente nuevo que tiene que cambiarlo parte de lo que se quería, no de lo que adivina. Y cuando trabajan varios agentes a la vez, la spec es lo que hace que sus cambios encajen.
Para que varios equipos puedan colaborar sin pisarse y para que lo construido escale, el camino es la spec (capítulo 18).
El acuerdo que propongo es sencillo: vibe coding para explorar, en el carril de descubrimiento y en lo que se va a tirar; spec para todo lo que entra en producción. Y una regla de paso: si un prototipo hecho con vibe coding va a quedarse, primero se escribe su spec y después se rehace o se revisa contra ella.
Hasta dónde llega un agente sin preguntar
La segunda decisión es cuánta autonomía tiene cada agente. En ITNOVE la resolvimos con tres niveles, que usan nuestros tres agentes:
- Lo hace y lo cuenta. Lo que se puede deshacer sin coste, no ve ningún cliente y no tiene opinión de por medio: añadir una prueba, corregir una errata, preparar un informe, dejar un borrador. El agente lo hace y lo dice en su siguiente parte, con cómo deshacerlo.
- Lo propone y espera el sí. Lo que ve un usuario o cambia cómo funciona algo, pero tiene vuelta atrás: un texto de la web, un cambio de código que altera un comportamiento. El agente deja la propuesta con su dato y el cambio exacto, y lo aplica cuando una persona dice que sí.
- Solo con un OK explícito. Dinero, datos personales, terceros y todo lo que no se puede deshacer: mandar correos a clientes, cambiar precios, borrar datos. El agente lo deja preparado y nunca lo ejecuta solo.
Y una regla para las dudas: si no sabes en qué nivel está algo, súbelo uno.
Los niveles no miden cuánto te fías de la herramienta. Reparten la atención de las personas. Si cada cosa que hacen nuestros agentes pasara por mí, no haría otra cosa; con los niveles, lo pequeño se hace solo y queda contado, y a mí me llega lo que de verdad es una decisión.
El acuerdo, en una página
Con esas dos decisiones, el resto del acuerdo cabe en una página. Este es el que propongo como punto de partida; cada equipo lo adapta:
- Cómo trabajamos. Vibe coding para explorar; spec para lo que entra en producción.
- Qué se le da a un agente y qué no. Trabajo acotado y verificable, sí; decidir valor, negociar con personas o aceptar un riesgo, no (capítulo 5).
- Autonomía. Qué hace solo y lo cuenta, qué propone y qué solo con un OK.
- Permisos. Qué puede tocar, en qué entornos y con qué datos.
- Revisión. Quién revisa qué, el tamaño máximo de un cambio para pedir revisión y cuántas horas al día revisa cada persona como máximo.
- Contexto. Dónde están las instrucciones que leen los agentes, quién las cambia y cómo se revisan (capítulo 14).
- Cuando un agente se equivoca. No basta con arreglarlo: se busca por qué pudo pasar y se añade lo que impide que se repita, sea una regla en sus instrucciones, una prueba o una comprobación automática.
- Cuándo se revisa este acuerdo. Cada pocos Sprints, en la Retrospectiva.
El punto 7 es el que más ha cambiado nuestra forma de trabajar. Cada fallo que llega a producción se arregla junto con el mecanismo más fuerte que impida que vuelva: primero, que no pueda pasar; si no se puede, que no pueda entrar sin que una prueba lo pare; si tampoco, que se vea al publicar o a la mañana siguiente. Una regla escrita en una guía es el último recurso, porque es la que más fácil se olvida.
La Daily: lo que hicieron los agentes no se lee en voz alta
La Daily es uno de los sitios donde más se nota si el acuerdo existe. Sin acuerdo, se llena con el parte de los agentes, como le pasó a GymApp en el capítulo 13. Con acuerdo, dura quince minutos y sigue este orden:
- ¿Cómo vamos hacia el Sprint Goal? La pregunta de siempre, primero.
- La cola de revisión, de lo más antiguo a lo más nuevo. Se recorre el tablero de derecha a izquierda, como en Kanban: primero lo que está más cerca de terminar. Lo que lleva días esperando revisión es un problema del equipo, no del agente.
- Lo que hicieron los agentes, solo si afecta a la meta. El parte llega antes de la Daily, y una persona, por turnos, lo ha filtrado y trae solo lo que cambia algo.
- Qué se les da hoy a los agentes y quién lo revisa. No se lanza trabajo que nadie tiene tiempo de revisar.
- Qué decisiones esperan a una persona. Las del Product Owner, las de otro equipo, las que necesitan un OK.
Algunos días se puede hacer por escrito, si el equipo está repartido, pero el punto 4 conviene hablarlo: es donde se reparte la atención del día.
La Retrospectiva: también se revisa cómo trabajamos con ellos
La Retrospectiva es el otro sitio. Además de las tres preguntas del Scrum Master (capítulo 4), con agentes conviene mirar tres datos del Sprint, que un agente puede preparar:
- Qué propuestas de los agentes se rechazaron o hubo que rehacer, y por qué.
- Cuánto esperó el trabajo en la cola de revisión, y delante de quién.
- Qué fallos llegaron a producción y si ya tienen su mecanismo para no repetirse.
Lo que sale de ahí es una acción como cualquier otra, con una diferencia: muchas veces la acción no es para las personas, sino para los agentes. Un cambio en sus instrucciones, una plantilla de spec mejor, una prueba nueva, un permiso menos, un nivel de autonomía que sube o baja. Cambiar cómo trabajan los agentes es una decisión del equipo, y su sitio es la Retrospectiva.
Lo que pasó en GymApp
El acuerdo de GymApp salió de aquella Retrospectiva y ocupó media página. Unai siguió usando vibe coding para los prototipos que Celia enseñaba a los socios, y la lista de espera tuvo por fin su spec, escrita entre los dos a la vuelta de sus vacaciones. Las pantallas de Celia pasaron a entrar como propuesta, no directamente.
Y la primera revisión del acuerdo, dos Sprints después, añadió una línea que nadie había previsto: ningún agente cambia un texto que lean los socios sin que lo revise Celia.
En resumen
La colaboración entre personas y agentes se escribe o se deforma. Vibe coding para explorar y specs para lo que se queda, porque la spec es lo que permite que otras personas, otros equipos y otros agentes entiendan lo construido.
Tres niveles de autonomía para repartir la atención, una página de acuerdo y dos eventos donde se cuida: la Daily, que reparte la revisión, y la Retrospectiva, que cambia también cómo trabajan los agentes.
Pruébalo esta semana
Pide a cada persona del equipo que escriba en tres líneas cómo trabaja con su agente. Ponedlas juntas en la próxima Retrospectiva y escribid el acuerdo de una página a partir de lo que no coincida.
La comparación entre las dos formas de trabajar está en Vibe coding o Spec-Driven Development, y la Daily en general, en Daily Scrum efectivo.