Fatiga de decisiones con 3 IDEs de IA abiertos: el experimento de Vohs traducido a nuestro trabajo
Hay dos experimentos clásicos de psicología que se enseñan en el primer año de una carrera de comportamiento. Vohs et al. (2008) sobre cómo elegir agota el autocontrol, y Danziger et al. (2011) sobre cómo la tasa de aprobación de los jueces israelíes cae a casi 0% justo antes del receso para comer. Los dos aparecen en libros de productividad como una advertencia para ejecutivos que toman “decisiones importantes.”
Yo quiero hacer algo distinto en este texto. Quiero traducir esos dos experimentos al idioma del desarrollo con asistentes de IA. Porque cuando abres Claude Code, Cursor y Codex al mismo tiempo, entras a un régimen de decisiones que ni Vohs ni Danziger anticiparon, y sus resultados encajan de una manera que me sorprendió cuando hice la cuenta.
Este texto es un ejercicio de traducción entre disciplinas, con una tabla al final que quizás te haga cambiar cómo configuras tu día. No pretende motivarte.
El experimento de Vohs, en 3 minutos
Vohs y sus coautores publicaron en 2008 un artículo llamado Making choices impairs subsequent self-control (artículo). El diseño es simple. Dividieron a estudiantes universitarios en dos grupos:
- Grupo A: los pusieron a tomar decisiones de consumo durante un rato. “¿Prefieres este producto o este otro? ¿Este color o el otro?” Muchas elecciones seguidas.
- Grupo B: les mostraron los mismos productos y les pidieron solo evaluarlos. Sin elegir, solo describir preferencias.
Después les pusieron a ambos grupos una prueba de matemáticas y una tarea de aguantar bebidas amargas. Resultado: el grupo A, el que había estado eligiendo, rindió peor en las dos. La cantidad de información procesada fue similar; lo único distinto era si tuvieron que decidir o solo observar.
La interpretación original se llamó ego depletion (agotamiento del yo): decidir consume un recurso cognitivo. Con los años, el efecto exacto ha estado bajo revisión de replicabilidad, y hoy conviene leerlo en su versión débil: una cadena de decisiones deteriora el autocontrol posterior, sin necesidad de comprometerse con un “recurso” físico que se agota como una batería.
Esa versión débil basta para lo que sigue.
El experimento de Danziger, en otros 3 minutos
Tres años después, en 2011, Danziger, Levav y Avnaim-Pesso publicaron un análisis de más de mil decisiones tomadas por ocho jueces israelíes de libertad condicional a lo largo de 50 días (PNAS).
Lo que encontraron fue lo siguiente. Al inicio de cada sesión (mañana, después del receso para el desayuno, después del almuerzo), la tasa de aprobación de libertad condicional rondaba el 65%. A medida que la sesión avanzaba, la tasa bajaba de manera monótona hasta acercarse al 0% justo antes del próximo receso. Después del receso, volvía a subir al 65%.
Hay críticas al estudio. Weinshall-Margel y Shapard señalaron que el orden en que los casos llegaban al juez no era aleatorio (respuesta técnica). El tamaño exacto del efecto está en discusión. Pero el núcleo del hallazgo, que un mismo juez produce resultados distintos según el momento del día, ha sido reproducido en contextos diferentes.
En términos prácticos: el mismo decisor, decidiendo el mismo tipo de caso, dos horas después decide diferente.
La traducción al dev
El ejercicio se vuelve interesante cuando abres tu IDE con tres asistentes de IA activos. El escenario que Vohs imaginó queda lejos: lo que tienes en pantalla es algo bastante más denso.
Conté micro-decisiones por hora durante una semana entera, con un contador clicker sobre la mesa. Cada vez que aceptaba, rechazaba, editaba manualmente después de aceptar, o cambiaba de modelo, marcaba una.
En una hora normal de trabajo, con las tres herramientas abiertas, mi conteo llegó a un rango de 140 a 180 micro-decisiones por hora. En una jornada de 6 horas activas, entre 840 y 1.080 decisiones. Vamos a redondear a 1.000 decisiones por día, para no complicarnos.
Los estudiantes del grupo A de Vohs, que ya rindieron peor en la prueba posterior, tomaron alrededor de 60 decisiones seguidas en su bloque experimental. Los jueces de Danziger tomaron entre 14 y 35 decisiones antes de un receso.
Tú y yo, con tres IDEs abiertos, estamos en un régimen que multiplica esos números por 15 a 60 veces al día. Sin recesos que reseteen el sistema como el juez tiene su receso para el almuerzo.
¿La cadena de decisiones que Vohs midió sigue funcionando a esta escala?
Aquí hay que ser honesto. No existe un experimento controlado que compare “dev con 3 IDEs de IA” contra “dev con 1 IDE” contra “dev sin IA” bajo condiciones de laboratorio. Lo que tenemos es una analogía razonable y observaciones de campo.
Un estudio de 2025 en arXiv, “Towards Decoding Developer Cognition in the Age of AI Assistants” (artículo), sostiene que leer una sugerencia de IA no es una decisión simple. El desarrollador tiene que hacer una tarea que los estudios de decisión de consumo no incluyen: rebobinar la lógica de otra mente (la del modelo) y remapearla contra su propio modelo mental del código.
Esa operación multiplica el costo cognitivo por decisión. Aceptar una sugerencia se parece más a leer código escrito por otro programador que no está presente: verificas que la intención coincide con la tuya, y lo haces en segundos. Elegir entre dos colores de un producto queda muy lejos.
Si Vohs midió deterioro después de 60 decisiones simples de consumo, es razonable esperar que 1.000 decisiones complejas de código produzcan un efecto proporcionalmente mayor. Vale como hipótesis del ejercicio, no como conclusión cerrada.
La tabla de micro-decisiones por herramienta
La tabla cuenta, por herramienta, cuántas decisiones típicas te fuerza a tomar por hora si la dejas abierta y activa.
| Herramienta | Tipo de decisión | Frecuencia típica por hora |
|---|---|---|
| Cursor | Aceptar o rechazar autocompletado (Tab) | 60-90 |
| Cursor | Elegir modelo (Auto vs Sonnet vs Opus) | 3-5 |
| Cursor | Aceptar la respuesta del chat lateral | 15-25 |
| Claude Code | Aceptar o rechazar diff propuesto | 30-45 |
| Claude Code | Aprobar ejecución de herramienta (Bash, Read) | 20-30 |
| Claude Code | Rebobinar y reintentar con otro prompt | 5-8 |
| Codex (dentro de ChatGPT) | Aceptar o descartar código sugerido | 15-25 |
| Codex | Copiar y pegar al editor, con edición manual | 10-15 |
| Interoperación | Elegir cuál herramienta usar en la próxima tarea | 8-12 |
Si sumas los rangos medios, el total va de 166 a 245 decisiones por hora con las tres activas. Consistente con mi conteo de campo, aunque yo estaba en el rango bajo porque acumulé experiencia en apagar las que no necesitaba.
Qué hacer con esto sin caer en consejos vacíos
No voy a decirte “usa menos herramientas y ya.” Cada persona tiene un ritmo distinto. Lo que sí funciona, medido en mi caso y consistente con la lógica de los dos experimentos, son tres movimientos.
Primero, imita el receso del juez. Danziger midió que los jueces se recuperaban después de comer. La versión práctica para nosotros: bloquea 30 minutos de tarea sin IA, con revisión manual de código o lectura de documentación, en la mitad del día. Funciona como cambio de tipo de decisión. El descanso pasivo importa menos que cambiar el músculo que estabas usando. Tu tasa de aceptación tras el bloque vuelve más cerca del rango del que empezaste la mañana.
Segundo, elimina decisiones que no aportan. La decisión “¿qué modelo usar para este archivo?” se elimina con una regla del tipo “TypeScript → Auto de Cursor, Python → Claude Code, explicación de stack trace → Codex.” La decisión no desaparece del universo, se desplaza al día en que escribes la regla. Vohs fue claro en esto: lo que agota es la cadena de decisiones consecutivas, y esa parte del efecto se sostiene incluso con el conteo total controlado.
Tercero, aleja las decisiones importantes de las últimas horas del día. El juez de Danziger tomaba peores decisiones antes del receso. Yo, en mi conteo, aceptaba sugerencias de IA con 40% más frecuencia después de las 3 pm que en la mañana. Los code reviews de PR de otros compañeros los hago antes del mediodía. Los tickets que requieren juicio arquitectónico también.
Lo que este artículo no dice
Es fácil salirse del cauce con un tema así. Un par de aclaraciones honestas para que no me cites diciendo cosas que no dije.
- No estoy diciendo que uses menos IA. La variable relevante es la cantidad de decisiones que la IA te fuerza a tomar, más allá de cuánto código llegue a producir.
- No estoy diciendo que ego depletion es un modelo físico correcto. La literatura del 2016 en adelante ha refinado la interpretación. Uso la versión débil: cadenas largas de decisiones deterioran el rendimiento posterior.
- No estoy diciendo que los jueces israelíes y los devs somos comparables. Digo que la estructura de “decisor único, decisiones consecutivas, sin reset” aparece en los dos escenarios.
La analogía tiene sus límites. Sirve como lente para mirar el día laboral, y ahí termina su alcance.
Cierre
Vohs midió el costo de elegir. Danziger midió el costo de decidir todo el día sin descanso. La combinación de ambos, aplicada al día laboral de un dev con tres asistentes de IA activos, produce una imagen inquietante: llegamos a 1.000 decisiones diarias en un régimen que ninguno de los dos estudios probó, sin la infraestructura de recesos que tenían sus sujetos.
La respuesta pasa por diseñar tu día como si supieras que la fatiga es real, aunque el mecanismo exacto siga en debate. Dejar de usar IA no está en la mesa.
Referencias
- Vohs, K. D., Baumeister, R. F., Schmeichel, B. J., Twenge, J. M., Nelson, N. M., & Tice, D. M. (2008). Making choices impairs subsequent self-control. PubMed Central.
- Danziger, S., Levav, J., & Avnaim-Pesso, L. (2011). Extraneous factors in judicial decisions. PNAS. Enlace.
- Weinshall-Margel, K., & Shapard, J. (2011). Respuesta técnica al artículo anterior. Enlace.
- Towards Decoding Developer Cognition in the Age of AI Assistants (2025). arXiv.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev
¿Te resultó útil este artículo?