Una cosa a la vez

Fuiste a por salsa de soja y volviste con el carrito lleno

Le dices al agente: «añade autenticación». Empieza a tocar el esquema de la base de datos, escribe rutas, cambia componentes del frontend y, de paso, refactoriza el manejo de errores. Dos horas después: 12 archivos modificados, 800 líneas nuevas y ni una sola función que funcione de principio a fin.

Los agentes tienen un impulso a «hacer un poco más»: ven algo relacionado y lo arreglan de paso. Como quien va al súper a por una botella y sale con el carrito lleno. La diferencia es que un humano que compra de más solo gasta dinero; un agente que hace de más no termina nada. Y no es un problema del modelo: es que el harness no trazó el límite.

La atención es finita

Piensa en el contexto del agente como una cantidad fija de atención. Si reparte esa atención entre una tarea, cada una recibe toda. Si la reparte entre cinco, cada una recibe una quinta parte, y puede que ninguna llegue al mínimo necesario para completarse. Es como cocinar seis platos a la vez: todos en el fuego, ninguno emplatado, todos quemados.

La lección ilustra con una petición de «registro de usuarios»: el agente crea el modelo, escribe la ruta, nota que hace falta verificar el email y añade un servicio de correo, ve que hay que cifrar contraseñas y mete otra librería, detecta que el manejo de errores es inconsistente y lo refactoriza, reorganiza la carpeta de tests. Seis frentes, todos a medias, sin verificación de extremo a extremo.

La regla WIP=1

El WIP (work in progress, trabajo en curso) viene de la metodología Kanban: limitar cuántas cosas están en marcha a la vez. Para agentes, WIP=1 es el valor seguro: una sola tarea activa, y no se empieza la siguiente hasta que la actual pasa su verificación.

## Reglas de trabajo
- Trabaja en una función a la vez
- Empieza la siguiente solo cuando la actual pase la verificación de extremo a extremo
- No «aproveches» para refactorizar la función B mientras haces la A

El ciclo es sencillo: elegir una tarea, trabajarla, verificarla, hacer commit y solo entonces desbloquear la siguiente. Si la verificación falla, la tarea sigue activa.

Evidencia de que está hecho

«Hecho» no es «el código está escrito» sino «el comportamiento pasa su comprobación». Por eso cada tarea necesita un criterio ejecutable:

F01: Registro de usuario
  Verificación: la petición POST /api/register con email y contraseña devuelve 201
  Estado: passing

«Se ve bien» no vale. «Devuelve 201» sí. Lo profundizamos en la lista de funciones.

Un caso comparado

En el ejemplo de la lección, una API con 8 funciones se trabajó de dos formas. Con el agente suelto («modo buffet») se activaron 5 funciones a la vez: ~800 líneas y solo una funcionaba de extremo a extremo; tras tres sesiones, 3 de 8 completadas. Con WIP=1 la primera sesión produjo ~200 líneas, todas verificadas; tras cuatro sesiones había 7 de 8 (la última bloqueada por una dependencia externa). Son números del caso ilustrativo del curso, pero muestran la tendencia: menos código, más funciones terminadas.

Una métrica útil

Puedes seguir la tasa de completitud verificada: tareas verificadas entre tareas activadas. Si baja de 1, no se abren tareas nuevas. Con WIP=1 se mantiene sola cerca de 1.