Sobrealcance y subcompletitud

Dos nombres para un mismo desorden

Seguro que has vivido esto en casa: empiezas a ordenar el armario, sacas todo, te pones con el cajón de al lado y a media tarde tienes la habitación peor que al principio. Hiciste mucho y no terminaste nada.

En agentes tiene dos nombres:

• Sobrealcance (overreach): el agente abre más tareas de las que puede cerrar en una sesión. Es medible: cinco funciones iniciadas y cero funcionando de extremo a extremo.
• Subcompletitud (under-finish): de las tareas iniciadas, pocas llegan a pasar la verificación. Código escrito, pruebas sin pasar.

El círculo vicioso

Las dos se refuerzan:

1. El sobrealcance reparte la atención entre muchas cosas.
2. Con la atención repartida, nada se termina (subcompletitud).
3. El código a medias deja el sistema más complejo y frágil.
4. Con un sistema más enredado, la siguiente tarea invita a tocar aún más cosas (más sobrealcance).

La lección lo conecta con una idea clásica de las colas de trabajo (la ley de Little): cuanto más trabajo hay en marcha a la vez, más tarda cada pieza en salir. Para un agente, cada función tarda más en llegar a verificada y aumenta la probabilidad de que falle por el camino.

Por qué los agentes caen más que las personas

Una persona suele tener intuición de «ya he hecho bastante». El agente no la tiene. Escribir «ya que estoy, arreglo también esto» le cuesta prácticamente cero tokens, pero cada añadido le resta atención a lo que sí importaba. Es como un buffet libre: cada plato extra parece gratis, pero tu estómago tiene un límite.

Cómo se ve en un repo

Una señal clara de sobrealcance es un cambio enorme que mezcla temas: esquema, rutas, frontend, refactor y reorganización de tests en la misma tanda. Una señal de subcompletitud es una lista de «hecho» donde nadie puede decir qué comando lo demuestra. Si te ocurre, la lección propone una auditoría sencilla de la salida del agente: clasifica cada cambio como:

Cada «comportamiento incompleto» necesita su comando de verificación antes de seguir.

Cómo romper el círculo

Dos palancas, ambas del harness, no del modelo:

1. Limitar el alcance: una tarea activa a la vez (WIP=1).
2. Exigir evidencia de cierre: una tarea solo pasa de «en curso» a «hecha» con una comprobación ejecutable.

Con esas dos reglas, resolver una de las caras resuelve la otra: si solo hay una cosa abierta, la atención se concentra, y si cerrar exige evidencia, no se acumulan restos a medias.

La lección habla también de una superficie de alcance: la lista de unidades de trabajo con sus dependencias y estados (no empezada, activa, bloqueada, aprobada). La idea práctica: que esa superficie viva en un archivo del repo, no en la conversación, para que cualquier sesión sepa qué hay abierto.