Dev Haskell: cómo programar con IA sin caer en burnout

Por qué el burnout por IA ya es la principal queja del sector

La advertencia llega desde un lugar inesperado: un programador de Haskell —lenguaje funcional usado en banca, fintech y sistemas críticos— publicó en el foro Discourse de la comunidad una guía titulada "How to keep enjoying programming in a world of LLMs", en la que reconoce que durante el último mes temió que programar, su trabajo soñado, dejara de tener sentido. El texto, escrito íntegramente a mano según el autor, no es un manifiesto contra la IA: es una propuesta concreta para seguir disfrutándola sin perder la cabeza.

Y la pregunta ya no es teórica. Según una encuesta de Coddy Tech a 305 desarrolladores recogida por ZDNET, el 80% afirma que el uso de herramientas de IA le resulta más adictivo que útil, el 43% sigue programando con IA después del horario laboral aun cuando había decidido parar, y el 32% ha retrasado el sueño por continuar. El 51% cree que es más probable quemarse, frente al 74% que opina que el uso intensivo aumenta sus opciones de ascenso.

Quentin Rousseau, CTO y cofundador de Rootly, lo describió en LinkedIn según recogió ZDNET: "Son las 2:47 de la madrugada. No estoy depurando una caída. No hay deadline. Solo estoy mirando a Claude Code refactorizar un módulo… y no puedo parar". Terminó consultando a un médico. La Encuesta de Desarrolladores de Stack Overflow 2025, también citada por ZDNET, completó el cuadro: aunque el 80% de los desarrolladores ya usan IA en su flujo, la confianza en la precisión de las respuestas cayó del 40% al 29% interanual, y la favorabilidad general bajó del 72% al 60%.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

La trampa del "vibe coding": cuando el agente programa por ti

El autor parte de una observación incómoda: los LLMs son notablemente peores produciendo código legible para humanos que código que ellos mismos puedan seguir procesando. "Si dejas que todo lo genere el agente, tu codebase se convierte en un páramo por el que solo tus coding agents pueden moverse", escribe. Lo que llama la spec-driven dystopia es claro: que te llegue un spec, lo martilles en el LLM y termines llorando cuando se acaben los tokens porque algún proveedor decidió racionarlos sin avisar.

El argumento central es que la generación de código es la parte que el programador disfruta. El resto —investigar, documentar, agrupar TODOs, redactar actas de reunión entre expertos de dominio— es bookkeeping que los LLMs hacen bien y que a los humanos les aburre. Usar la IA para escribir el código, dice, es usar la herramienta al revés: cedes lo que te gusta a cambio de automatizar lo que ya querías automatizar.

La regla que casi nadie sigue: el humano escribe, la IA planifica

La metodología que propone es directa: que el agente investigue el codebase, arme el TODO actual, identifique todos los puntos a tocar y mencione posibles trampas; luego, que el humano se siente a escribir. La IA como project manager, no como developer.

Tres principios sostienen el sistema:

El plan se hace junto al agente, pero el código lo escribes tú. El humano siempre sabe en qué estado está su codebase.
Los TODOs se materializan en archivos con frontmatter, no solo en el contexto del modelo. Si el contexto se desborda, la información se pierde silenciosamente.
Siempre debe haber trabajo offline posible, igual que en un tren o un avión. Cuando los tokens se acaben, el programador debe poder seguir avanzando sin depender del modelo.

A esto le suma una regla de oro: cuando se delega una investigación, se investiga en paralelo con un buscador tradicional. Al menos hay que conocer aproximadamente todo lo que el agente va a saber, porque aceptar sus resultados como hechos lleva directo a una deuda técnica seria.

Por qué añadir un ciclo de revisión automática (y por qué no es opcional)

El autor rescata la idea de las redes generativas antagónicas (GAN): un modelo que genera, otro que critica. Aplicado al flujo de trabajo, significa que ningún artefacto —ni código ni planes— llega a ojos humanos sin pasar por un agente revisor.

"No aceptes, ni siquiera leas, ningún artefacto producido por un LLM sin un ciclo de revisión automatizada", escribe. Cuando el plan tenga agujeros lógicos —refactorizar en el TODO 2 una función que está programada para escribirse en el TODO 7— el revisor los detecta antes que el humano. El mismo principio se aplica a commits, propuestas de PR y documentación. El resultado, según el autor, es un flujo ágil pero sin la parte burocrática que vuelve locos a los equipos.

También recomienda aplicarse esta disciplina a uno mismo: que un agente revise el código propio, incluso aunque ya esté escrito. Sirve para detectar omisiones, errores reales y para mantener el foco en el TODO actual.

Lo que dicen los datos: +24% en PRs, pero ¿a qué precio?

El argumento del desarrollador Haskell es contraintuitivo en un ecosistema que vive obsesionado con la productividad bruta. ¿Qué dicen los estudios?

Un estudio de Microsoft publicado el 1 de julio de 2026 y recogido por TechRepublic sobre el despliegue de Claude Code y GitHub Copilot CLI midió un aumento del 24,0% en PRs mergeados por ingeniero por día, con un rango probable de +14,5% a +33,7%. Los usuarios que emplearon las herramientas cinco o más días por semana vieron ganancias superiores al 50%, frente a alrededor del 15% para quienes las usaron tres días.

Pero el estudio mide PRs, no calidad de software. Un estudio paralelo publicado el 2 de julio de 2026, también recogido por TechRepublic, siguió a una empresa mediana con mandato explícito de duplicar la productividad ("2x mandate"). Rastreó a 802 desarrolladores y 196.212 pull requests desde enero de 2024 hasta abril de 2026. La métrica subió de 21,2 a 44,3 PRs por desarrollador activo al mes (×2,09). El costo fue claro: la proporción de PRs que recibieron al menos una revisión humana cayó del 89% al 68%, la cobertura de revisión por IA saltó del 19% al 84%, y la carga de trabajo por revisor se duplicó. Los PRs autoría de IA tardaban un 20% más en fusionarse tras la primera revisión humana.

Un tercer estudio, publicado en ACM Transactions on Software Engineering and Methodology y también cubierto por TechRepublic, examinó 567 pull requests de Claude Code en 157 proyectos open source: el 83,8% se fusionó, pero solo el 54,9% lo hizo sin cambios adicionales. El 45,1% requirió revisión humana, sobre todo en corrección de bugs, documentación y estándares específicos del proyecto.

La imagen compuesta: las herramientas de IA entregan más código, pero ese código llega con deuda de verificación incorporada. Más PRs no equivalen a mejor software si el cuello de botella se mueve a revisión.

Qué significa esto para tu startup

La tesis del desarrollador Haskell no es "no uses IA". Es úsala donde aporta y no donde te cuesta. Tres movimientos prácticos para equipos chicos:

Separa el trabajo en dos colas: lo que haces tú (código) y lo que delega al agente (todo lo demás). Investigación, planificación, conversión de conversaciones largas en TODOs, redacción de actas, organización de resultados de tests. El programador nunca pierde la práctica y el codebase nunca se vuelve opaco.
Monta un ciclo de revisión con dos agentes. Uno genera, otro critica. Nadie lee código de IA sin filtro. Como primer experimento concreto, define un agente que solo revise planes antes de pasarlos a código: vas a detectar contradicciones lógicas que hoy te quitan horas de debugging.
Diseña el flujo para poder seguir cuando los tokens se acaben. Mantén una lista de TODOs en archivos con frontmatter, documenta decisiones y deja siempre trabajo que no dependa del LLM activo. Cuando la cuota se agote (y se va a agotar), el equipo sigue produciendo.

El autor resume su enfoque con una metáfora agrícola: "Me veo como un jardinero que adopta fertilizantes orgánicos suaves, mientras los vibe coders inundan sus campos con químicos industriales. Creo que mi camino es más sostenible por ahora". En 2026, sostenibilidad significa también salud mental del equipo —y eso, finalmente, se traduce en retención, calidad y velocidad real.