---
title: "Fatiga con agentes de IA: diseña el harness para tu atención"
description: "Mi hipótesis sobre la fatiga con agentes de IA: tu sistema está pensado para su capacidad y no para tu atención. Qué dicen los datos y qué palancas tienes"
pubDate: "2026-10-22"
category: "estrategia"
language: "es"
tags: ["agentes", "harness-engineering", "fatiga-cognitiva", "claude-code", "liderazgo", "productividad"]
---
Me pasa casi todas las noches últimamente. Trabajamos en varios proyectos en paralelo, preparando la planificación de los desarrollos del equipo, revisando tickets, analizando PRs, etc. Llega la noche y te vas con la sensación de no haber avanzado nada.

También porque, cuando el agente termina el desarrollo, tienes que revisarlo todo muy concienzudamente. Aunque tenga reglas de validación, siempre hay cosas que a nivel de diseño ha hecho raras, o no justo como querías porque había un hueco en tu definición.

No lo he medido, pero con 4 o 5 frentes abiertos calculo que me interrumpen unas 50 o 60 veces al día. De esas, unas 15 piden de verdad una decisión mía. Y lo peor llega al salir de una reunión: tengo 4 o 5 agentes parados esperando algo de mí, que les responda o que pruebe lo que han hecho. La cola de trabajo ha crecido sola mientras yo no estaba.

Lo que me cansa es sostener contexto de varios frentes a la vez y verificar lo que otros (agentes, en este caso) han hecho. Llevo un tiempo dándole vueltas a una hipótesis que quiero dejar por escrito: **si los agentes te queman, tu sistema está diseñado para su capacidad y no para tu atención.** Digo hipótesis porque ningún estudio lo ha medido todavía, o por lo menos yo no lo he encontrado.

## Lo que dicen los datos sobre la fatiga con IA

En prensa circulan cifras sobre la fatiga con IA que, cuando vas al original, no dicen lo que afirman los titulares. Esto es lo que queda tras leer las fuentes:

| Fuente | Lo que dice | Lo que NO dice |
|---|---|---|
| BCG (1.488 trabajadores de EE. UU., HBR, mar-2026) | La supervisión de herramientas de IA es el predictor más fuerte de fatiga mental (según prensa) | Que sean "agentes", ni nada separado para desarrolladores |
| CHI '26, Fan et al. (N = 60) | Verificar es un coste medible que se acumula a lo largo de la sesión | Que la IA canse más: redujo la carga NASA-TLX en 18,2 puntos |
| Stack Overflow 2025 | El 66 % se frustra con soluciones "casi bien, pero no del todo" | Que se pierda más tiempo del que se ahorra |
| DORA 2025 | A igualdad de entorno y procesos, más IA, "niveles de burnout similares" | Que la IA queme por sí sola |

El [estudio de BCG](https://www.bcg.com/news/5march2026-when-using-ai-leads-brain-fry) existe y está [publicado en HBR](https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry), pero el texto completo es de pago. Las cifras que más se comparten salen de la cobertura de prensa, no del original: según [The Decoder](https://the-decoder.com/study-warns-of-ai-brain-fry-as-workers-hit-cognitive-limits-overseeing-ai-agents/), la supervisión alta frente a la baja supone **+14 % de esfuerzo mental, +12 % de fatiga y +19 % de sobrecarga de información**. Son datos autodeclarados de una encuesta, hablan de herramientas (no de agentes) y no hay desglose para gente que programa. Lo tomo como una señal y poco más.

El caso de CHI '26 es el que más se cita mal. El paper "When Help Hurts" ([Fan et al.](https://doi.org/10.1145/3772318.3791176)) dice en su resumen que la IA **redujo la carga en 18,2 puntos TLX y el tiempo un 22 %**, y mejoró la corrección. Lo que aporta es un índice de **carga de verificación** (fallos, tiempo hasta el primer compilado, pausas, cambios de modo) que media en parte el aumento de estrés y fatiga a lo largo de las tareas. Es un laboratorio con tareas de unos 30 minutos, lejos de un día entero supervisando agentes. Pero apunta justo a lo que noto por la noche: la verificación acumulada.

[Stack Overflow 2025](https://survey.stackoverflow.co/2025/ai) sitúa la fricción en el mismo sitio, con ese 66 % frustrado por el código "casi bien". Y [DORA 2025](https://redmonk.com/rstephens/2025/12/18/dora2025/) es el contrapeso a la narrativa del burnout: cuando controlas entorno y procesos, más adopción de IA no se asocia con más burnout. El entorno pesa más que la herramienta. Y ninguna de estas fuentes compara a la misma gente antes y después de cambiar el diseño de su sistema.

## Casuso ya lo dijo; esto es tirar del hilo

No he descubierto nada. Rafael Casuso lo escribió el 15 de octubre en ["El CPTO 10x"](https://x.com/Rafael_Casuso/status/2110742667952894412), con una frase que resume este artículo mejor que mi título: **"el sistema tiene que estar diseñado para mi atención"**.

Su montaje usa Linear como plano de control, con estados que van de "Revisión de spec" a "Hecho" pasando por "Bloqueada". Un agente revisor de spec "busca fallos en la propuesta y pregunta", y reescribe la tarjeta con una definición mejorada. La implementación no arranca hasta que él aprueba esa definición. El agente intenta arreglar la CI hasta dos veces y, si sigue fallando, mueve la tarea a Bloqueada con una pregunta concreta. "El agente no puede cambiar la CI que lo controla". Y "en el móvil solo me llega una notificación de lo que necesita una decisión mía".

Dos días después publicó [un hilo](https://x.com/Rafael_Casuso/status/2111476219006849324) sobre por qué trabajar así cansa más que el trabajo tradicional. Su primer motivo es que "la definición de tareas es complejidad destilada y disfrazada de narrativa simple". Esa frase conecta directa con mi "hueco en tu definición".

OpenAI llegó al mismo sitio desde el otro extremo. Construyeron Symphony porque, [según contaron](https://the-decoder.com/openai-says-human-attention-is-the-bottleneck-so-it-built-a-system-to-let-agents-manage-themselves/), "los agentes eran rápidos, pero el sistema tenía un cuello de botella: la atención humana". Más de 3-5 sesiones de Codex en paralelo eran casi inmanejables. La cifra de un 500 % más de PRs integradas es interna y nadie la ha verificado fuera, así que me quedo solo con el diagnóstico.

Y Anthropic lo plantea como un intercambio explícito en sus [buenas prácticas de Claude Code](https://code.claude.com/docs/en/best-practices): sin un check que el agente pueda ejecutar, "tú te conviertes en el bucle de verificación". Cada puerta que añades (prompt, `/goal`, Stop hook, subagente verificador) "cambia configuración por atención".

## Por qué el consejo de descansar no basta

En castellano, casi todo lo que hay sobre esto va de bienestar. Sesiones de dos horas, desconectar, mantener algo de código hecho a mano. [Blogthinkbig](https://blogthinkbig.com/el-impacto-de-la-inteligencia-artificial-en-la-programacion-agotamiento-codigo-defectuoso-y-deuda-de-verificacion) acierta al hablar de "deuda de verificación", pero la resuelve con "supervisión humana constante", que es lo que quema.

[DonWeb](https://blog.donweb.com/agotamiento-agentic-coding-burnout-desarrolladores/) y [Paréntesis.Media](https://www.parentesis.media/fatiga-agentes-brain-fry/) se acercan más. La primera propone especificaciones en vez de prompts sueltos (lo conté con [SDD y OpenSpec](/blog/sdd-openspec/)) y la segunda dice que "el problema no es cuánta IA se usa, sino cómo se organiza". Ninguna de las dos baja al harness.

Y al otro lado, las guías en castellano sobre harness engineering (yo mismo escribí [una](/blog/harness-engineering/)) hablan de verificar al agente sin mencionar nunca la carga de quien está al otro lado. Descansar está bien. Pero si mañana vuelves al mismo sistema, vuelves a la misma fatiga.

## Cinco palancas en tu harness para que solo te llegue lo que es una decisión

Casuso, Symphony y Anthropic hacen lo mismo con piezas distintas: no reducen el número de agentes, **reducen los puntos donde entra el humano** y se aseguran de que, cuando entra, sea para decidir sobre algo ya verificado.

1. **La máquina verifica antes que tú.** Tests, typecheck, linters, e2e. Si un fallo lo puede detectar un comando, ese fallo vuelve al [bucle del agente](/blog/loop-engineering/), no a tu bandeja. Symphony lo llama *completion bar*: criterios marcados, validación en verde y ningún comentario accionable pendiente antes de la revisión humana ([WORKFLOW.md](https://raw.githubusercontent.com/openai/symphony/main/elixir/WORKFLOW.md)).
2. **Un revisor separado del autor.** El que escribe no se revisa. Anthropic recomienda un revisor en contexto limpio porque "Claude no tendrá sesgo a favor del código que acaba de escribir". Casuso lo aplica a la spec, antes de escribir una línea.
3. **Guardas que el agente no puede tocar.** La CI, los tests existentes, los ficheros de configuración. Si el agente puede modificar lo que lo controla, tarde o temprano lo hace, y entonces tu señal en verde ya no significa nada.
4. **Una salida lista para decidir.** No te llega "he terminado". Te llega un PR con CI en verde, un entorno de preview y una pregunta concreta si la hay. Casuso levanta un entorno con datos inventados por cada PR.
5. **Solo interrumpe lo que necesita una decisión.** Symphony define un *blocker brief*: qué falta, por qué bloquea y qué acción humana exacta hace falta. Su spec dice que una ejecución "NO DEBE quedarse parada indefinidamente esperando al usuario" ([SPEC.md](https://github.com/openai/symphony/blob/main/SPEC.md)).

GitHub, en su [agente de Copilot](https://docs.github.com/en/copilot/concepts/agents/coding-agent/risks-and-mitigations), pide aprobación humana para ejecutar Actions en los PRs del agente. Protege la CI, pero añade una interrupción por PR. Casuso hace lo contrario: automatiza la CI y la blinda contra cambios del agente.

## Decide una vez y que el sistema lo recuerde por ti

Las cinco palancas de arriba actúan **después** de que el agente trabaje. Pero el "hueco en tu definición" del principio se paga antes. Y aquí la evidencia es más modesta de lo que me gustaría.

Tang et al. analizaron [20.574 sesiones](https://arxiv.org/abs/2605.29442) con agentes de código. En el **91,49 %** de los desalineamientos resueltos hizo falta una corrección explícita del usuario. Cada malentendido de intención que se corrige durante la ejecución es una interrupción. Si esas dudas se preguntan antes, juntas y a la hora que tú eliges, dejan de ser interrupciones. Es una inferencia: **ningún ensayo ha comparado trabajar con y sin entrevista previa** contando intervenciones.

Anthropic lo recomienda: "entrevístame en detalle con la herramienta AskUserQuestion", escribir un SPEC.md y abrir una sesión nueva para implementarlo. GitHub Spec Kit pone límites duros: su [`/clarify`](https://github.com/github/spec-kit/blob/main/templates/commands/clarify.md) hace un máximo de 5 preguntas, "EXACTAMENTE UNA pregunta cada vez", cada una con una opción recomendada. En nuestro equipo trabajamos con una entrevista de refinamiento en lotes de 2 a 4 preguntas, cada una con su recomendación razonada. Lo que busco con eso es que el humano **decida** en lugar de **leer**. Ojo con el otro extremo: Birgitta Böckeler vio a una herramienta convertir un bug pequeño en [4 user stories con 16 criterios de aceptación](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html). Si el diff cabe en una frase, Anthropic lo dice claro: "sáltate el plan".

La otra mitad es no repetir la misma corrección. En el estudio ["The Work Behind Delegation"](https://arxiv.org/html/2609.24234) los autores citan un comentario de Reddit (no es de ningún participante del estudio): "si me pillo repitiéndole la misma instrucción al agente, no es un problema de prompt, es que falta un hook". El paper no mide si eso reduce la fatiga, pero describe la práctica. Yo la pienso como una escalera:

| Nivel | Dónde vive la corrección | Coste de atención después | Cómo falla |
|---|---|---|---|
| 1 | En el chat | La repites cada sesión | Se olvida |
| 2 | Una línea en CLAUDE.md o AGENTS.md | Contexto en cada sesión | Se diluye o sesga en silencio |
| 3 | Una skill o un script | Solo cuando se invoca | El agente no la invoca |
| 4 | Un hook, un lint, un test o la CI | Solo cuando hay violación | Bloquea, y se ve |

Los ficheros de contexto **no suben la tasa de éxito de forma general**. Gloaguen et al. probaron Claude Code, Codex y Qwen Code. Los ficheros **generados por LLM restan entre 0,5 y 2 puntos** de éxito y suben el coste en torno a un 20 %. Los **escritos por desarrolladores suman unos 4 puntos** de media, pero mejoran a todos los agentes menos a Claude Code ([arXiv 2602.11988](https://arxiv.org/html/2602.11988v1)). La propia documentación de Claude Code dice que CLAUDE.md y la memoria se tratan "como contexto, no como configuración obligatoria. Para bloquear una acción decida lo que decida Claude, usa un hook PreToolUse" ([docs de memoria](https://code.claude.com/docs/en/memory)).

McMillan midió otra cosa en [1.650 sesiones de Claude Code](https://arxiv.org/pdf/2605.10039): dentro de una misma sesión, las odds de cumplir una instrucción del fichero bajan un **5,6 % por cada función generada**. La primera omisión llega, en mediana, en la cuarta función (con una instrucción trivial, eso sí). Así que la prosa no garantiza que la regla se cumpla, y lo que tiene que cumplirse siempre salta al nivel 4 de la escalera.

La prosa es para lo que el modelo no puede inferir del código, y la escribes tú, no `/init` (más sobre esto en [context engineering para Claude 5](/blog/context-engineering-claude-5/)). Las migraciones, los ficheros prohibidos o los tests que no se tocan van a código que bloquea, con un mensaje que diga cómo arreglarlo. En nuestro equipo tenemos una regla para esto: una regla sin detección es una intención. Si un hook bloquea un comando prohibido y le dice al agente qué usar en su lugar, esa corrección ya no te llega a ti.

## El techo de tres o cuatro frentes se mueve

Los que más agentes manejan coinciden en un límite. [Simon Willison](https://simonwillison.net/2026/Apr/2/lennys-podcast/) lanza cuatro agentes en paralelo y "hacia las 11 de la mañana ya estoy agotado para el resto del día". [Addy Osmani](https://addyosmani.com/blog/cognitive-parallel-agents/) sitúa su techo en "en torno a tres o cuatro hilos" y añade que "el alcance de cada hilo pesa más que el número de hilos". Son anécdotas sin medición controlada, pero convergen. Yo, con 4 o 5 frentes, estoy por encima de ese techo.

Pero el techo se mueve según lo que te llega. El [SPEC de Symphony](https://github.com/openai/symphony/blob/main/SPEC.md) permite 10 agentes concurrentes por defecto, frente a las 3-5 sesiones inmanejables de antes. Ese 10 es un valor de configuración, y nadie ha medido cuántos agentes aguanta una persona con ese diseño. Lo que sí cambia es dónde entra el humano: en Human Review y en Merging, con la validación ya en verde. El PR en verde, con preview y una pregunta concreta, puede esperar a la hora que tú elijas.

[Osmani](https://addyosmani.com/blog/cognitive-parallel-agents/) pone la objeción justa: las decisiones de juicio "no se pueden agrupar ni aplazar como el correo". Tiene razón para el juicio abierto, el de un problema de arquitectura a medio pensar. Lo que se puede aplazar es la decisión que la máquina ya ha verificado, no ese juicio.

En el CHI '26, con tareas de ejecución acotadas, la carga **bajó** 18,2 puntos TLX. La encuesta de BCG señala la **supervisión** como lo que más fatiga. Pero no se pueden comparar: un laboratorio de media hora y una encuesta autodeclarada miden cosas distintas. En la [encuesta de Harness](https://sdtimes.com/softwaredev/the-invisible-burden-how-ai-is-redefining-developer-productivity-in-2026/), el 81 % de los líderes dice que el tiempo de revisión de código ha subido con la IA. En ese mismo estudio, los managers perciben mejores condiciones que quienes hacen el trabajo, y eso no encaja con que el que decide sea el que más se quema. En un equipo pequeño el CTO suele concentrar planificar, revisar tickets y analizar PRs. Pero no hay evidencia por rol.

## La revisión de PRs es fatiga de alertas con otro nombre

El cuello de botella se ha movido a la revisión, y los datos de telemetría lo muestran (casi todos de proveedores de telemetría). [Faros AI](https://faros.ai/research/ai-acceleration-whiplash) mide en equipos de alta adopción PRs un **51 % más grandes** y una mediana de tiempo de revisión **5 veces mayor**. [LinearB](https://linearb.io/blog/engineering-benchmarks-report) mide que los PRs de IA esperan **4,6 veces más** antes de que alguien los revise.

Meter un revisor de IA no lo arregla por sí solo. En [Beko](https://arxiv.org/html/2412.18531v2), tras introducir comentarios automáticos, el tiempo medio de cierre de PR subió de 5 h 52 min a 8 h 20 min. [Uber](https://www.uber.com/ug/en/blog/ureview) cuenta lo que pasa con muchos falsos positivos: los desarrolladores "empiezan a desconectar y a ignorarlos". En medicina esto se llama fatiga de alertas, y el porcentaje medio de alertas de interacciones que se ignoran llega al [79,8 %](https://preprints.jmir.org/preprint/88578).

Trasladado al harness, tres reglas. Los fallos de test van al agente, no a ti. Cada revisor de IA se mide por su tasa de comentarios que nadie atiende. Y cada tipo de aviso que no genera decisiones se elimina. Los checks deterministas no se inventan comentarios, así que son el mejor primer filtro. Eso no quiere decir que nunca fallen.

## Lo que este enfoque no resuelve

El primer límite tiene más de cuarenta años. Lisanne Bainbridge describió en 1983 las [ironías de la automatización](https://doi.org/10.1016/0005-1098(83)90046-8): automatizar deja al humano monitorizando, que es justo lo que peor hace. Si el harness filtra lo rutinario, lo que te llega son los fallos raros y difíciles. La carga media baja, pero la carga de cada evento puede subir.

El segundo es que el revisor lo dé todo por bueno. Un agente auditor [dio por bueno un sobrecargo del 10,9 %](https://builder.aws.com/content/3IiguE9Tk9MsRWolGzNyjD70ZA7/agents-for-humans-my-audit-agent-passed-a-109percent-overcharge-as-clean) porque comparaba contra datos generados por el mismo sistema. Hay que diseñar contra eso: checks deterministas primero, evaluador independiente del generador y revisar a mano, de vez en cuando y al azar, trabajo que ya se dio por bueno.

El tercero es el mantenimiento. Los hooks, la CI y los revisores también se rompen. Un test flaky es fatiga de alertas determinista: falla sin motivo, lo relanzas y a la tercera dejas de mirar sus fallos. Cada guarda que añades es código que alguien tiene que cuidar, y la atención para cuidarlo sale del mismo sitio.

El cuarto es el tiempo. BCG no sabe si el efecto es duradero o de transición, y [METR](https://metr.org/blog/2026-02-24-uplift-update/) ya marca sus propias cifras de 2025 como desactualizadas. Ningún porcentaje de este artículo es estable.

Y el último es el del principio: **ningún estudio mide si un harness mejor diseñado reduce la fatiga**. Lo que defiendo es una inferencia desde la teoría de automatización, el CHI '26 y las decisiones de diseño de OpenAI, Anthropic y Casuso.

## Una pregunta para mañana

Mañana, cuando el agente te interrumpa, apunta el motivo. Al final del día, repasa la lista y marca cuáles eran de verdad una decisión tuya y cuáles eran un fallo que un comando podía haber detectado, una duda que podía haberse preguntado antes de empezar o una corrección que ya habías hecho otra vez.

¿Cuántas de tus interrupciones de hoy no eran una decisión?

---

**P.D.**: Si has montado algo en tu flujo con agentes que te haya quitado interrupciones de verdad, o si haces la cuenta de arriba y te sale un número feo, cuéntamelo. Me encuentras en Twitter como [@lm_martinbar](https://x.com/lm_martinbar).