Análisis de la fatiga del “vibe coding” en desarrolladores provocada por una velocidad de la IA más rápida que el pensamiento

Puntos clave:

• El uso de herramientas de IA (Claude Code, Cursor) aumentó la velocidad de desarrollo, pero el ritmo acelerado de trabajo supera los límites de procesamiento del cerebro y provoca fatiga.
• Los cambios frecuentes de contexto, el exceso de dopamina y el paso a un rol de gestión incrementan la carga cognitiva.
• Surge el fenómeno del “tiempo de máquina”, en el que los humanos son arrastrados por la velocidad de la IA, lo que plantea la necesidad de regular el ritmo de manera intencional.

---

Introducción

• Utilidad y efectos secundarios de las herramientas de IA: Un desarrollador con 40 años de experiencia usó Claude Code y Cursor para desarrollar un gestor de paquetes (Marvai), experimentando una mejora en la productividad, pero también una fatiga sin precedentes.
• Planteamiento del problema: Aunque la implementación de funciones y la corrección de errores se aceleraron, apareció un fenómeno de agotamiento incluso tras sesiones cortas de trabajo (alrededor de 1 hora), porque el cerebro no logra seguir el ritmo de la IA.

Desarrollo

1. Aumento abrupto de la carga cognitiva y presión del “tiempo de máquina”

• Aplicación de la teoría de carga cognitiva: Según la teoría de Team Topologies, las responsabilidades excesivas y los cambios de tema elevan la carga cognitiva. La programación con IA empuja esa carga hasta el límite.
• Ritmo dirigido por la máquina: Similar al estrés que antes sufrían los obreros fabriles al tener que adaptarse a la velocidad de las máquinas, los desarrolladores viven el fenómeno de ser perseguidos por la rapidez de la IA (“tiempo de máquina”).
• Desaparición del proceso de pensamiento: En la programación tradicional, la velocidad de trabajo y la velocidad del pensamiento coincidían, dando al cerebro margen para procesar (“Baking time”). En cambio, la programación con IA resuelve en instantes arquitecturas complejas y procesos de decisión, dificultando la sincronización mental.

2. Coexistencia de exceso de dopamina y hormonas del estrés

• Aceleración del bucle de dopamina: El ciclo de recompensa de “programar-error-resolver-éxito” se vuelve extremadamente rápido gracias a la IA.
• Agotamiento emocional: La combinación de liberaciones frecuentes de dopamina y las hormonas del estrés provocadas por la velocidad produce fatiga y sensación de agobio, en lugar del placer habitual de programar.

3. Incremento del costo del cambio de contexto (Context Switching)

• Sobrecarga de la caché mental: Cambiar de contexto es una tarea de alto consumo energético que vacía y vuelve a llenar la caché del cerebro.
• Microcambios de contexto (Micro-Context Switching): La IA obliga a cambios frecuentes y sutiles —por ejemplo, al modificar varios módulos al mismo tiempo o incluso al usar una simple autocompletación con la tecla Tab— pasando constantemente del “modo de escritura” al “modo de revisión”, lo que agota rápidamente la energía mental.

4. Cambio esencial en el rol del desarrollador

• De autor a gestor: El rol deja de ser convertir requisitos en código y se transforma en el de “líder de equipo” o “coordinador de tráfico”, encargado de gestionar y revisar los resultados de un “compañero de equipo veloz” llamado IA.
• Asimetría de responsabilidad: Mientras la IA produce el equivalente al trabajo de cinco personas, el desarrollador sigue cargando con la responsabilidad final sobre la calidad del código, lo que incrementa la carga de gestión.

Conclusión

Sugerencias para una programación con IA sostenible

• Ajuste intencional del ritmo (Pacing): El desarrollador debe controlar de forma deliberada el tempo de trabajo en lugar de dejarse arrastrar por la velocidad de la IA.
• Introducción de nuevas formas de retrospectiva: Se necesitan nuevas rutinas de trabajo, como retrospectivas diarias (Retrospective), para sincronizar la IA con el cerebro.
• Cambio en la percepción del rol: Hace falta reducir el micromanagement sobre la salida de la IA y adoptar un estilo de trabajo basado en confiar más en ella.
• Perspectiva futura: El futuro de la programación podría no estar en acelerar todo sin límites, sino en una “lentitud intencional” y en nuevos límites que tengan en cuenta las capacidades cognitivas humanas.

[aura01]

Yo también he tenido una experiencia similar, así que lo hago de esta manera.

Por ejemplo, si voy a hacer una refactorización,

'pedirle que analice el código existente y proponga alternativas'
'pedirle que resuma y explique las diferencias entre las alternativas y el código existente, así como sus ventajas y desventajas'
'pedirle que sugiera métodos para verificar si la alternativa realmente es mejor'
'validar directamente la alternativa'
'pedirle que aplique la alternativa y redacte la documentación y las pruebas'

El problema es que el uso de tokens se dispara y termina saliendo muy caro...

[dbs0829]

Incluso para trabajos repetitivos simples, al final me deja más tranquilo hacer mejor una macro...

[fantajeon]

Entre las personas también pasa así.

Entre las personas este tipo de problema también ocurre con frecuencia.
Si quien piensa más lento es el gerente,
diría:
"El trabajo va demasiado rápido, es agotador y es difícil trabajar juntos",
y si esa persona fuera el subordinado,
diría:
"No entiende bien lo que se le dice, así que es difícil trabajar juntos".

Al final, para poder trabajar juntos, la química entre ambas partes tiene que encajar.

[bakyeono]

La angustia de tener que limitarse a revisar código y hacer pruebas después de que te quitaron la programación...

[colus001]

Salvo en proyectos personales, uso el vibe coding de forma limitada. Con el autocompletado de Cursor lo uso para ideación y para codificar patrones repetitivos del mismo tipo, nada más. En proyectos de largo plazo, intentar resolverlo todo con vibe coding me parece un acto irresponsable como desarrollador.

[tested]

Parece que quienes entienden y validan/revisan el código del resultado del trabajo sienten más fatiga que quienes solo escriben prompts y se quedan con el resultado.
También aparece en el artículo original.

[onixboox]

Yo nunca he sentido ese tipo de fatiga, porque más bien solo pienso: “qué bueno que, gracias a la IA, tengo menos trabajo”. Yo uso zed + claude, y a veces en medio del proceso cambia el contexto y empieza a funcionar raro, pero en esos casos revierto el código en git y le digo “integra lo anterior y vuelve a escribirlo”, y suele dejarlo más limpio. Al final, no es que ya no estés escribiendo código tecleando directamente, sino que simplemente cambió el proceso de convertir en código lo que tenías en la cabeza, ¿no? De hecho, hasta siento que al escribir prompts mis ideas se ordenan mejor.

[caniel]

¿No hace falta tiempo para sincronizar el código con las ideas que tenías en la cabeza, ahora que el proceso de crear con código se volvió una caja negra?
Con la escritura de código tradicional, está garantizado que el código y lo que tenías en mente coinciden, pero con la programación mediante LLM eso ya no está garantizado.

[onixboox]

Si en la cabeza ya solo está la lógica y lo único que haces es verificar si el código que escribió la IA quedó bien, ¿realmente hace falta armar el código mentalmente? Basta con pensar qué tan precisos son los datos que le pasas en el prompt, así que al contrario, el trabajo se ha vuelto mucho más rápido.

[caniel]

Creo que puede variar según qué tan específico sea el prompting. Si se lo pasas al LLM a nivel de pseudocódigo, entiendo lo que comentas.

[choihyojun]

Antes, aunque pasara todo el día escribiendo código, al terminar la jornada solía sentirme satisfecho; pero ahora, aunque la mayor parte del trabajo del día la resuelvo conversando y hay muchos días en los que no escribo ni una sola línea de código directamente, igual terminé quemándome... Lo entiendo perfectamente.

[ds2ilz]

A mí también me ha aumentado justo por esta razón. Ya lo esperaba, así que el cansancio en sí me parece bien, pero más que eso, desde afuera parece que como ya no paso tanto tiempo tecleando sin parar mientras programo, estoy trabajando con muchísimo margen. Y cuando digo que estoy más cansado que antes, no lo entienden muy bien....

[reagea0]

Ah, siento que por fin alguien explicó con claridad exactamente por qué estoy tan cansado.

[baeba]

1. "La sensación de velocidad es energizante" (postura positiva)

• Postura: Que la IA resuelva rápido las tareas aburridas incluso da más energía, y también es positivo porque reduce el costo de aprender nuevos stacks tecnológicos.
• Caso: Al usar un lenguaje o framework desconocido, gracias a un agente de IA se pudo saltar el tedioso proceso de aprendizaje y concentrarse de inmediato en la implementación.

2. "Debate sobre la definición de vibe coding" (confusión terminológica)

• Debate: No hay consenso sobre si "vibe coding" significa simplemente recibir ayuda de la IA, o si se refiere a usar código generado sin revisarlo y solo verificar el resultado.
• Punto de acuerdo: Originalmente tenía una connotación negativa de "código sin revisar", pero hoy su significado se ha ampliado hasta abarcar la programación asistida por IA en general.

3. "La velocidad sin verificación es deuda técnica" (postura cautelosa)

• Crítica: Confiar solo en lo que genera la IA sin entender el código es riesgoso. Los bugs futuros y el costo de mantenimiento (deuda técnica) probablemente serán mayores.
• Analogía: Es "como subirte a un auto autónomo sin saber a dónde va"; implementar sin comprensión termina debilitando la capacidad de resolver problemas.

4. "La fatiga del cambio de contexto" (postura empática)

• Coincidencia: Mientras la IA genera código, se producen cambios de contexto frecuentes (Context Switching), lo que dispara la carga cognitiva del cerebro.
• Síntomas: Como el proceso de revisar y corregir lo que entrega la IA se repite una y otra vez, el desgaste mental es mayor que al programar directamente. Cuatro horas de trabajo se sienten como haber trabajado todo el día.

5. "Pérdida del placer de programar" (falta de dopamina)

• Experiencia: Desaparece la sensación de logro (dopamina) que se obtiene al resolver un problema por cuenta propia. Se siente como mirar solo el producto terminado en vez de disfrutar armar el Lego uno mismo.
• Resultado: Sacar resultados rápido sin el disfrute del proceso termina agotando a los desarrolladores.

6. "Veneno para principiantes, medicina para expertos" (diferencias según experiencia)

• Análisis: Los desarrolladores experimentados pueden detectar y corregir rápido los errores de la IA, así que su productividad sube; en cambio, los principiantes corren el riesgo de usar código incorrecto tal cual, perder oportunidades de aprendizaje y producir código deficiente en masa.

7. "Cambio forzado al rol de gestor" (transformación del rol)

• Fenómeno: El desarrollador deja de ser un "creador" que escribe código directamente y pasa a ser un "gestor/revisor" obligado a revisar y corregir el código que la IA genera en grandes cantidades.
• Carga: Esto provoca un estrés extremo, como si una sola persona tuviera que revisar en tiempo real el código escrito por cinco desarrolladores junior (IA).

8. "Falta de comprensión de la lógica de negocio" (señalamiento de límites)

• Problema: La IA puede escribir bien el código, pero no entiende el contexto de negocio ni la arquitectura completa.
• Realidad: Al final, ajustar los requisitos del negocio al código y manejar los edge cases sigue siendo trabajo humano, y ahí es donde aparecen los cuellos de botella.

9. "Desaparición del descanso y la holgura" (tiempo de máquina)

• Analogía: Igual que antes los obreros de fábrica trabajaban al ritmo de las máquinas, ahora los humanos quedan atrapados en un "tiempo de máquina" en el que terminan siguiendo la velocidad de generación de la IA.
• Necesidad: Como desaparecen las "pausas forzadas" como el tiempo de espera de compilación, el cerebro ya no tiene espacio para procesar información y descansar. El descanso intencional se vuelve indispensable.

10. "Un problema transitorio de la herramienta" (perspectiva a futuro)

• Diagnóstico: La fatiga actual se debe a un desajuste: las herramientas de verificación (tests, lint, etc.) no han logrado seguir el ritmo de generación de la IA.
• Solución: Si evolucionan herramientas que automaticen la verificación al mismo ritmo de generación, el problema de la fatiga podría resolverse.