La tormenta perfecta: burnout y desarrollo con IA
Cómo la combinación de expectativas irreales, presión de la industria y herramientas que cambian cada semana está quemando equipos de desarrollo.
Me tomé cuatro meses libres a fines de 2025. Nada de código, nada de side projects, simplemente un corte antes de buscar nuevo trabajo. Cuando volví a principios de 2026 y arranqué en un puesto nuevo, dos cosas me golpearon al mismo tiempo: las herramientas de IA habían pegado un salto enorme, y la industria estaba en un lugar muy diferente al que había dejado.
Cómo cambió mi flujo de trabajo
Antes del corte, usaba Cursor con Sonnet para autocompletado y algún que otro prompt con contexto acotado para cosas simples. Servía, pero la mayoría de las veces armar el prompt e iterar era más trabajo que escribir el código yo mismo.
Cuando arranqué en el nuevo trabajo, ponerme al día con herramientas de IA no era opcional. El equipo ya las estaba usando. Empecé a probar Claude Code con Opus 4.5 (ahora 4.6), y la diferencia fue enorme. Describo lo que quiero, reviso lo que sale, itero. La IA implementa features mientras yo dirijo y reviso.
El flujo de desarrollo era algo como:
sequenceDiagram
participant Product as Product
participant Dev as Developer
participant Review as Developer Review
loop Análisis técnico
Product->>Dev: Propuesta / Requisitos
Dev-->>Product: Feedback técnico
end
Dev->>Dev: Desarrollar feature
Dev->>Review: Crear PR
Review-->>Dev: Cambios requeridos
Dev->>Dev: Aplicar cambios
Dev->>Review: Actualizar PR
Review-->>Dev: Aprobado
Note over Dev,Review: MergedDonde el mayor consumo de tiempo era en la etapa de desarrollar el feature y en algunos casos el análisis técnico del producto y diseño
Ahora con el nuevo flujo con IA comprime algunas etapas no sólo el desarrollo, al ser tan fácil prototipar a veces incluso es mejor hacer un prototipado rápido y capturar el análisis con producto de una forma más rápida y real
sequenceDiagram
participant Product
participant Dev as Developer (Owner)
participant AIDev as AI Agent Dev (Claude Code)
participant Tools as Linter/Tests
participant AIRev as AI Reviewer (CodeRabbit)
participant DevRev as Dev Reviewer
loop Análisis técnico
Product->>Dev: Requisitos
Dev->>AIDev: Plan + contexto
AIDev-->>Dev: Propuesta técnica
opt Prototipo rápido
AIDev->>Dev: Demo / mock
Dev-->>Product: Validación temprana
end
Dev-->>Product: Alineación
end
AIDev->>Tools: Implementar + validar
Tools-->>AIDev: Checks OK
AIDev-->>Dev: Implementación lista
Dev->>Dev: Revisar cambios
alt Ajustes necesarios
Dev-->>AIDev: Solicitar cambios
AIDev->>Tools: Actualizar + validar
Tools-->>AIDev: OK
AIDev-->>Dev: Listo para PR
else OK para PR
AIDev-->>Dev: PR listo
end
Dev->>AIRev: Abrir PR
AIRev-->>AIDev: Comentarios automáticos
AIDev->>Tools: Re-validar
Tools-->>AIDev: OK
Dev->>DevRev: Review técnico
DevRev-->>Dev: Aprobado
Note over Product,DevRev: Merge (PR aprobado + checks OK + AI review + dev review)El cambio real no fue la velocidad. Fue cuáles habilidades importan: code review pasó a ser el trabajo principal, planificar se volvió más crítico que implementar, y armar un entorno con guardrails estrictos (linter rápido, types fuertes, tests sólidos) es lo que mantiene honesto al output de la IA.
Hace poco más de un año, cuando herramientas como Cursor empezaron a ganar tracción, estaba trabajando como tech lead y recomendé al equipo que empezara a experimentar, con un mensaje claro: el output es tu responsabilidad. Nunca fuimos code-monkeys que traducían requerimientos a código antes de la IA, y no deberíamos convertirnos en prompt-monkeys ahora. Esa mentalidad no cambió. Si acaso, es más relevante que antes.
Pero el cambio de workflow es solo una parte de la historia. Lo que me preocupa más es cómo la industria está manejando esta transición.
Las tres caras de la empresa
No todas las empresas están respondiendo igual a esta ola. Lo que vi, tanto en mi experiencia directa como en conversaciones con otros developers, se agrupa en tres patrones claros.
Las que todavía no arrancaron
Empresas donde la adopción de herramientas de IA no es una prioridad. No hay suscripciones, no hay políticas, no hay directivas. Los developers más curiosos las usan por su cuenta, muchas veces pagándolas de su bolsillo o usando versiones gratuitas.
La cuenta del ROI es absurda: herramientas de $20-200/mes por developer en equipos con salarios altos. Pero se traban en "tenemos que evaluar vendors" o "seguridad no lo aprobó" y pierden meses de productividad mientras la competencia shippea más rápido.
Lo paradójico es que en estos equipos, los developers que usan IA por su cuenta terminan con una ventaja silenciosa. Pero esa ventaja es individual, no del equipo. No hay un enfoque coordinado, no hay aprendizaje compartido, y cuando alguien se va, esa productividad se va con esa persona.
Las pragmáticas
Estas son las que lo están haciendo bien. Entienden que la tecnología tiene fortalezas y limitaciones reales. Invierten en herramientas, dan tiempo para experimentar, y lo más importante: ajustan expectativas de forma realista.
Un equipo pragmático invierte en el stack completo de feedback: linters rápidos como oxlint, type checking estricto, buena cobertura de tests. Pero también invierte en la configuración del proyecto para los agentes: archivos como AGENTS.md o CLAUDE.md que definen convenciones, restricciones y contexto del codebase para que la IA genere código consistente sin que tengas que repetirlo en cada prompt. Comandos personalizados y skills que codifican workflows del equipo y los hacen reproducibles. Entiende que más output del agente significa más carga de review, y lo planifica. Crea espacio para que el equipo evalúe herramientas, comparta lo que funciona y lo que no.
flowchart LR
A([Agente IA]) --> B[Código generado]
B --> C{"Lint - Types - Tests"}
C -.->|Fallan| A
C -->|Pasan| D{Review humano}
D -.->|Cambios| A
D -->|Aprobado| E([Enviar])Estas empresas tratan la IA como lo que es: una herramienta poderosa que requiere infraestructura alrededor para funcionar bien. No un botón mágico de productividad.
Las que compraron el hype
Y acá es donde la cosa se pone fea. Management que lee los titulares ("¡30% de nuestro código ya es generado por IA!", "¡productividad 2x con Copilot!") y traduce eso en expectativas inmediatas de output sin invertir en nada más.
No hay tiempo para entrenamiento. No hay ajuste de procesos. Solo la directiva de shippear más, más rápido, con la misma gente. La premisa es que la IA debería hacer todo más fácil, entonces ¿por qué no estamos entregando el doble?
El resultado es predecible: equipos presionados con métricas irreales, sin las herramientas adecuadas ni el tiempo para aprender a usarlas bien. La IA se usa mal, el output es mediocre, el code review se vuelve un cuello de botella y la calidad cae. Los developers terminan trabajando más horas, no menos, tratando de cumplir con expectativas que nadie validó contra la realidad.
Un estudio de UC Berkeley publicado este mes analizó una empresa de tecnología de 200 personas durante ocho meses. El hallazgo central: la IA no reduce el trabajo, lo intensifica. Los trabajadores que usaban IA no trabajaban menos. Trabajaban más rápido, asumían proyectos más amplios, y terminaban extendiendo su jornada. El 77% de los empleados reportaron que la IA les aumentó la carga de trabajo, no que la redujo.
Como dijo uno de los participantes del estudio: "Pensabas que, como podías ser más productivo con IA, ibas a ahorrar tiempo, a trabajar menos. Pero no trabajás menos. Trabajás la misma cantidad o incluso más."
El lado del developer
La industria del software está acostumbrada a los cambios. Nuevo framework cada año, nueva herramienta de build, nuevo paradigma. Pero esta transición es diferente: no cambia con qué herramientas trabajás, cambia qué es el trabajo en sí.
Y agarró a mucha gente desprevenida.
Los que se tiraron de cabeza
Hay developers que adoptaron estas herramientas desde el primer día. Experimentan, optimizan su workflow, empujan los límites de lo que se puede hacer. Son los que después comparten tips en Slack y ayudan al equipo a ponerse al día.
Pero acá hay una paradoja que no esperaba. Según TechCrunch, los primeros signos de burnout están viniendo de las personas que más abrazan la IA. No de los que se resisten. De los que la usan más.
¿Por qué? Porque la IA expande lo que parece posible. Antes, un developer tenía un límite natural de cuánto código podía escribir en un día. Ese límite ya no existe de la misma manera, y sin límites claros, el trabajo se expande hasta llenarlo todo. Más tareas, más scope, más contexto que manejar. El estudio de Berkeley lo confirma: la productividad crece, pero a costa de fatiga cognitiva y límites cada vez más difusos entre trabajo y vida personal.
Los que necesitan guía
Muchos developers no se resisten a la IA, simplemente no saben por dónde arrancar. O arrancaron y no vieron resultados porque nadie les mostró cómo usar las herramientas efectivamente. El 47% de los trabajadores que usan IA no saben cómo usarla para ser más productivos.
Este grupo necesita liderazgo técnico que cree el espacio y la estructura para aprender. No mandatos de "usá IA", sino acompañamiento real: sesiones de pair programming con herramientas de IA, compartir workflows que funcionan, iterar juntos.
Los que la usan sin entender las consecuencias
Y después está el grupo que acepta todo lo que genera la IA sin cuestionarlo. Copy-paste del output del agente directo al PR, sin revisar, sin entender qué hace el código, sin verificar edge cases. Shippean rápido, pero shippean deuda técnica.
El 96% de los developers no confían plenamente en la precisión funcional del código generado por IA. El 76% cree que necesita refactoring. Pero si la presión es shippear rápido y la IA genera código que "funciona", la tentación de no revisarlo a fondo es enorme.
La presión que antes no existía
Todo esto pasa en un contexto de industria que cambió radicalmente. En 2020-2021, la barrera de entrada era baja, la demanda de developers era altísima y las empresas competían por talento. Hoy el escenario es otro: más de 245.000 despidos en tech en 2025, el empleo de programadores en Estados Unidos cayó un 27,5% entre 2023 y 2025, y las posiciones de entry-level requieren cada vez más experiencia.
Los developers hoy cargan una presión que hace tres años no existía. Menos puestos, más exigencia, expectativas infladas por el hype de la IA y la sensación constante de que si no adoptás estas herramientas te quedás afuera. Esa combinación es la tormenta perfecta para el burnout.
La carrera de herramientas que nadie puede ganar
Hay un factor que pocas veces se menciona: la velocidad a la que cambian las herramientas. Claude Code, Codex, OpenCode, Cursor, Windsurf. Modelos nuevos cada pocas semanas: Opus 4.5, luego 4.6, Codex 5.2/5.3, Gemini 3. Cada actualización cambia lo que es posible y lo que conviene hacer.
Un developer que quiere estar al día necesita evaluar herramientas constantemente, probar nuevos workflows, ajustar su setup. Eso lleva tiempo. Tiempo que muchas empresas no están dispuestas a dar porque la directiva es "ship ship ship".
El resultado: developers que evalúan herramientas en su tiempo libre, que se quedan fuera de horario probando el último modelo, que sienten que si no lo hacen se quedan atrás. Otro factor de burnout disfrazado de "desarrollo profesional".
Las empresas pragmáticas crean espacio explícito para esto: tiempo asignado para experimentar, compartir findings, decidir en equipo qué herramientas adoptar. Las que compraron el hype esperan que eso pase mágicamente entre sprints.
Qué funciona de verdad
Si hay algo que tengo claro después de estos meses, es que la solución no es resistirse al cambio ni tirarse de cabeza sin pensar.
Más guardrails, no menos. Linters estrictos, tipos fuertes, tests sólidos. Dejá que la IA vuele dentro de esas boundaries. Conseguís la mayor parte de la velocidad sin el riesgo de calidad.
Expectativas realistas desde management. La IA no duplica la productividad de un día para el otro. Aumenta el output en ciertas tareas, pero genera nueva carga en otras (especialmente review). Si management no entiende este trade-off, va a presionar basándose en una fantasía.
Tiempo para aprender. Las herramientas cambian rápido. Si no creás espacio para que tu equipo las evalúe y aprenda a usarlas bien, van a usarlas mal o no las van a usar.
Feedback loops conectados. Herramientas CLI como psql, Chrome DevTools MCP, test runners rápidos. Cuantos más loops de feedback automáticos tenga el agente, menos verificación manual necesitás y mejor es el resultado.
Los investigadores de Berkeley recomiendan lo que llaman una "AI practice": normas intencionales sobre el uso de IA que incluyen pausas estructuradas antes de decisiones importantes, secuenciar el trabajo para reducir context-switching, y proteger tiempo para conexión humana.
Esto no es el fin, es una transición
El trabajo de un developer sigue siendo entender cómo funciona el software. Eso no cambió y no va a cambiar pronto. Lo que cambió es que ahora dirigís una herramienta en vez de hacer todo a mano, y eso requiere habilidades diferentes.
Los modelos van a seguir mejorando. La distancia entre "describo un feature" y "código funcionando con tests" se achica cada pocos meses. Pero la tecnología por sí sola no resuelve nada si las empresas no ajustan expectativas y los developers no ponen límites.
Las empresas y los equipos que manejen esta transición con intención, no solo con velocidad, son los que van a salir del otro lado sin haber quemado a su gente en el camino.