La habilidad que falta no es el prompting. No es saber qué modelo usar, ni cómo estructurar un CLAUDE.md, ni cuándo recurrir a un MCP tool.
La habilidad que falta es saber cuándo parar.
El Humano Async
Hay un marco mental al que vuelvo constantemente: los humanos somos procesos async de un solo hilo.
Tenemos threads en segundo plano — hábitos, reconocimiento de patrones, el tipo de procesamiento de bajo nivel que ocurre sin que nos demos cuenta. Pero nuestra función ejecutiva consciente, la parte que lee código y toma decisiones arquitectónicas y evalúa si un agente se ha descarrilado, es estrictamente single-threaded. No puede ejecutar genuinamente dos tareas de razonamiento complejo en paralelo.
Lo que llamamos “multitarea” es en realidad cambio de contexto. Y el cambio de contexto tiene overhead — exactamente como un scheduler de SO ejecutando múltiples procesos en un solo core. La CPU no los corre en paralelo; crea la ilusión de paralelismo cambiando rápidamente entre ellos, cargando y descargando estado cada vez.
Nosotros hacemos lo mismo. Y pagamos el mismo precio: cada cambio cuesta algo, y cuantos más cambios hagas, menos ejecución real obtienes por unidad de tiempo.
Esta es la base sobre la que descansa todo lo demás.
Dos Problemas de Parada
Con ese modelo en mente, hay dos formas distintas en que las cosas salen mal cuando orquestas agentes de IA — y operan en ejes diferentes.
El Problema Vertical: Construir sobre Terreno No Verificado
Estás en una sesión. El agente acaba de terminar el módulo de autenticación. Se ve sólido. Haces un repaso del output, parece correcto, hay momentum — así que le dices que empiece el dashboard.
Pero no has verificado el módulo de auth en profundidad. Lo has visto. No lo has testado.
Ahora el dashboard se está construyendo sobre asunciones que pueden estar equivocadas. Y cuanto más continúas antes de parar a verificar, más caro se vuelve cualquier error de base. Si auth tiene un bug sutil, puede que no aflore hasta que el dashboard esté a medias — momento en el que no estás arreglando una cosa, estás desenredando dos.
Este es el problema de parada dentro de una sesión. No se trata de cambiar entre agentes. Se trata del tirón del momentum dentro de un solo hilo de trabajo. El agente sigue, tú sigues con él, y la transición de “modo construir” a “modo verificar” nunca ocurre porque nunca se planificó explícitamente.
La disciplina: antes de que empiece la sesión, redefine qué significa “terminado”. Que el agente haya parado no es terminado. Terminado significa que has confirmado que funciona y que las asunciones sobre las que construyó son sólidas. Ninguna feature nueva empieza hasta que hayas alcanzado ese nivel.
El Problema Horizontal: ¿Cuántos Procesos Puedes Planificar Realmente?
Ahora añade sesiones paralelas. El Agente A construye la API. El Agente B refactoriza el modelo de datos. El Agente C escribe tests.
Cada uno de esos es un proceso que tu atención single-threaded tiene que servir. Compruebas A, cambias a B, cambias a C, vuelves a A — y con cada cambio, cargas un contexto, haces algo de trabajo, y lo descargas. Excepto que no lo descargas del todo. La investigación sobre residuo de atención muestra que cuando cambias el foco de una tarea a otra, parte de tu atención se queda en la anterior. Ese residuo consume memoria de trabajo, degradando la calidad de tu engagement con lo que hayas cambiado.
Tres sesiones de agente solapadas significa que potencialmente cargas tres contextos parciales simultáneamente, sin estar nunca plenamente presente en ninguno de ellos. No se siente así — se siente como productividad. Pero la calidad de tu supervisión se degrada silenciosamente, y las regresiones y las malas decisiones arquitectónicas se cuelan porque no estabas leyendo lo suficientemente profundo cuando importaba.
El límite práctico, en mi experiencia: dos o tres sesiones activas por bloque de trabajo concentrado, y solo cuando las tareas son genuinamente aislables. Más allá de eso, no estás supervisando — estás hojeando. Y el hojeo es donde las cosas se rompen.
Qué Significa Parar Bien en la Práctica
Ambos problemas tienen la misma solución raíz: hacer de la parada un elemento de primera clase en el plan, no un añadido.
Algunas heurísticas que han cambiado cómo trabajo:
Antes de lanzar cualquier sesión, responde dos preguntas: ¿cómo es “terminado”, y cómo es “verificado”? Si no puedes responder ambas, la tarea no está suficientemente acotada para ejecutarla todavía.
Resiste la siguiente feature hasta que la anterior esté verificada. El momentum es el enemigo aquí. El agente termina algo, te sientes bien con ello, y el instinto natural es seguir. Para. Comprueba. Testa. Confirma que la base es sólida antes de construir encima.
Trata los límites de sesión como paradas duras, no como sugerencias. Decide de antemano: después de que estos agentes reporten, reviso, mergeo lo que esté listo, y paro. El drift de contexto — donde las sesiones siguen generando nuevas sesiones sin una pausa real — es cómo desaparecen seis horas y acabas con un codebase difícil de razonar y un cerebro completamente agotado.
Clasifica las tareas antes de paralelizarlas. No todo el trabajo de agente tiene el mismo coste cognitivo de supervisar. Documentación, boilerplate, tests aislados — estos son baratos de supervisar en paralelo. Decisiones arquitectónicas, refactors transversales, cualquier cosa con estado compartido — estos merecen tu atención plena y secuencial.
La Condición de Cierre
Un proceso de un solo hilo que intenta planificar demasiadas tareas no se vuelve más rápido — simplemente pasa más tiempo cambiando de contexto que ejecutando. El sistema más eficiente no es el que más procesos lanza. Es el que más trabajo real hace entre cambio y cambio.
Eso aplica a los CPUs. Y resulta que también aplica a nosotros.
¿Qué límites has establecido tú en la práctica? Me interesa comparar notas. Escríbeme.