Parte II. El equipo: personas y agentes
Un agente no es un compañero: es capacidad
El equipo híbrido y las specs como idioma común (Spec-Driven Development)
Tres agentes y un registro de fallos
En ITNOVE desarrollamos nuestra web con agentes de IA. Tres de ellos trabajan solos cada día. Uno revisa por la noche los cambios que han entrado y busca fallos, y solo me cuenta lo que puede demostrar. Otro me prepara cada mañana un correo con lo que pide mi atención. Otro vigila el embudo de marketing y propone mejoras. Ninguno cambia el comportamiento de la web sin que yo lo apruebe.
Funciona, pero no salió así a la primera. Cuando analizamos los 134 arreglos que hicimos entre finales de agosto y mediados de octubre de 2026, uno de cada cuatro cambios de código arreglaba algo anterior. Casi el 70 % de los fallos los encontré yo, mirando la web, y ninguno lo encontró una prueba automática. El código salía rápido; lo que fallaba era todo lo que tenía que comprobarlo.
En GymApp, mientras tanto, Germán le dio al primer agente una tarea pequeña: añadir a la reserva de clases un aviso cuando quedan menos de tres plazas. Escribió la tarea en dos líneas. El agente la terminó en veinte minutos, tocó cuatro ficheros y rompió el cálculo de plazas de las clases dobles, que nadie le había mencionado.
Qué es un agente
Un agente es un modelo de IA con herramientas y permisos que hace una tarea de varios pasos: lee código, lo cambia, ejecuta pruebas, consulta datos y vuelve a intentarlo si algo falla. Es capacidad del equipo, como lo es un servidor de integración continua. No es un miembro: no responde de nada.
De ahí sale la regla práctica. A un agente se le da trabajo acotado, con una especificación clara y con forma de comprobar el resultado. No se le da lo que exige decidir valor, negociar con personas o asumir un riesgo.
La spec, el idioma común
En un equipo híbrido, la especificación (la spec) es el elemento de backlog refinado. El recorrido es este: una historia de usuario describe el valor; la spec describe con precisión qué tiene que pasar, con ejemplos y casos límite; el agente propone el cambio; una persona lo revisa contra la spec y contra la Definition of Done.
La tarea de Germán falló por falta de spec, no por el agente. Dos líneas no dicen nada de las clases dobles. Una spec habría llevado ejemplos así:
- Dada una clase con 20 plazas y 18 reservas, cuando un socio la abre, entonces ve "Quedan 2 plazas".
- Dada una clase doble, el aviso cuenta las plazas de cada sesión por separado.
- Si la clase está llena, no aparece el aviso de plazas: aparece "Clase completa".
Escribirlo cuesta diez minutos. Revisar un cambio sin eso cuesta mucho más.
Trabajar así se llama Spec-Driven Development. La objeción habitual es que suena a cascada: primero especificar todo, luego construir. No lo es si la spec es pequeña, de un solo elemento, y sale de lo que el equipo ha aprendido. El capítulo 7 explica por qué.
Permisos y fronteras
Antes de dar trabajo a un agente se decide qué puede tocar, qué no y dónde se para a pedir permiso. Un agente que puede cambiar la base de datos de producción sin que nadie lo vea no es capacidad: es un riesgo.
La frontera natural es la revisión del cambio. El agente propone; una persona lo lee, lo prueba y lo integra. En nuestra web, ninguna propuesta del agente de calidad cambia cómo se comporta la web sin un "sí" mío.
Rutinas mejor que compañeros
Hay una tentación de tratar a los agentes como compañeros a los que se les habla en el chat del equipo. Funciona peor que tratarlos como rutinas: tareas que se ejecutan a una hora, con una entrada y una salida conocidas, que alguien revisa. Un guardián de calidad que pasa cada noche. Un agente que prepara cada mañana el resumen de lo pendiente. Un agente que, cuando se aprueba una spec, abre el cambio.
Las rutinas se pueden medir, mejorar y apagar. Los "compañeros" se convierten en una conversación más.
Es lo que más aprendimos de nuestro registro de fallos: el agente que más valor aporta no es el que más código escribe, sino el que cada noche comprueba lo que ha entrado y deja por escrito lo que puede demostrar. El mismo día que di de alta este libro en la web, uno de ellos descubrió que varios botones del editor de capítulos no hacían nada. Nadie lo había notado. Lo arregló y dejó una prueba para que no volviera a pasar.
En resumen
Un agente es capacidad, no un miembro del equipo. Se le da trabajo acotado, con spec y verificable, dentro de unos permisos decididos antes. La spec es el idioma común entre personas y agentes, y la revisión humana es la frontera.
Pruébalo esta semana
Escribe la spec de un elemento pequeño de tu backlog, con tres o cuatro ejemplos de "dado, cuando, entonces", y dásela a un agente. Cuenta cuántas cosas tienes que corregir. Después haz lo mismo con dos líneas de descripción y compara.
Para escribir la spec tienes el Kit de Spec-Driven Development, y para decidir qué hará tu primer agente y qué no, el canvas del primer agente.