¿"Programar está resuelto"? El bug parpadeante dice que no
Esto es lo que nadie que empuja la línea de "programar está resuelto" quiere poner junto a su presentación: la herramienta de codificación con IA más comentada del planeta se lanzó con un bug de parpadeo de pantalla, y tomó aproximadamente un año de parches, un rollback, y finalmente un workaround-que-todavía-está-detrás-de-un-feature-flag antes de que alguien pudiera considerarlo resuelto.
No fue un problema de hardware. No fue un problema de infraestructura. No fue alguna enrevesada race condition de sistemas distribuidos que necesitara un equipo de investigación. Un bug de redibujo de terminal. El tipo de cosa que un ingeniero competente arregla en una tarde — excepto que este sobrevivió a dos generaciones de modelo.
Quiero detenerme en esa brecha un momento, porque es todo el argumento.
La historia que sigo escuchando — en X, en podcasts, en esos hilos sin aliento de "la era del ingeniero de software está terminando" — va así: el prompting manual está muerto, programar es básicamente un problema resuelto, y la jugada inteligente ahora es dejar de escribir código y empezar a escribir loops que ejecuten una IA a través de ciclos de prompts hasta que se alcance alguna condición de victoria. Lo difícil que queda, dice la historia, es infraestructura, feedback de usuarios y hardware. ¿Programar? Esa es la parte fácil. Eso ya está hecho.
Uso herramientas de codificación con IA todos los días. No estoy aquí para decirte que no funcionan — absolutamente funcionan, y te mostraré exactamente dónde. Pero "programar está resuelto" es el tipo de afirmación que suena inteligente en una keynote y se desmorona en el momento en que señalas los recibos. Y el recibo más limpio que tengo es un bug tan aburrido que casi hace el punto por sí solo.
Vamos a ello.
Qué afirma realmente "programar está resuelto" (y quién lo dice)
Antes de discutir una posición, quiero formularla tan fuerte como las personas que la sostienen lo harían. Primero steelmanning. Es la única forma honesta de hacer esto.
La versión más completa del argumento viene del interior de Anthropic mismo. Boris Cherny — el creador de Claude Code — dijo en entrevistas a mediados de 2026 que la IA ha prácticamente resuelto la programación, y que no había escrito una línea de código a mano en ocho meses (Fortune, junio 2026). El encuadre que creció alrededor de eso es aún más afilado: deja de hacer prompts a Claude un mensaje a la vez, dice el argumento — construye loops. Construye un arnés que deje al modelo observar, planificar, actuar y reflexionar durante horas, a veces días, iterando contra tests y métricas de aceptación hasta que converja en un estado de aprobación (la explicación de explainx.ai sobre la tesis de harness engineering).
En esa visión del mundo, el trabajo del humano cambia. No escribes funciones. Escribes la función de puntuación — la condición de victoria — y el loop avanza hacia ella. Elegir un mejor modelo es optimizar la variable equivocada; construir mejor infraestructura de feedback es el verdadero juego. De hecho, he escrito sobre la mecánica de este enfoque en mi propio análisis de arneses de agentes de larga duración, y lo digo claramente: como técnica, es real y es poderosa.
Luego está el número que todos citan. Anthropic reportó que las líneas de código mergeadas por contribuidor activo alcanzaron aproximadamente 8x la línea base pre-2025 para Q2 2026 — enmarcado en algunos recuentos como "dos años de output de codificación, cada trimestre, por persona" (OfficeChai). Para mayo de 2026, Claude supuestamente estaba escribiendo más del 80% del código de producción mergeado internamente (VentureBeat).
Esa es una serie de afirmaciones genuinamente asombrosa. Si parara aquí, cerrarías la pestaña convencido de que programar había terminado.
Entonces, ¿por qué no estoy convencido? Por un detalle enterrado en el propio anuncio de Anthropic — y por un bug. Tomemos primero el detalle.
La advertencia que Anthropic puso en su propia nota al pie
Aquí hay algo que los hilos de hype casi nunca incluyen, y es la frase más honesta de toda la conversación.
Cuando Anthropic publicó la cifra de 8x, el propio blog post de la empresa advirtió que el número era "casi con certeza una exageración", porque contar líneas de código premia volumen, no calidad — y los conteos de líneas por PR tuvieron que limitarse al percentil 99 solo para filtrar commits atípicos (como se reportó en la cobertura de productividad).
Lee eso de nuevo. La organización que hace el argumento más fuerte de "programar está resuelto" adjuntó una etiqueta de advertencia a su propia métrica de titular. Las líneas de código son un proxy notoriamente roto — todo ingeniero que lleva tiempo en esto sabe que más código a menudo es peor, no mejor. Una herramienta que te deja generar ocho veces el diff no es evidentemente una herramienta que resolvió la programación. Podría ser simplemente una herramienta que resolvió teclear.
Y esa es la costura de la que quiero tirar. Porque hay una diferencia entre tres afirmaciones que se difuminan cuando la gente dice "programar está resuelto":
- La IA acelera la producción de código. Verdad. Obviamente, mediblemente verdad.
- La IA mejora la calidad del código cuando se usa bien. A menudo verdad, con advertencias reales.
- Programar, como problema humano difícil, está terminado. Este es el salto. Y no sobrevive al contacto con la evidencia.
Las dos primeras son avances reales. Pelearía con cualquiera que le dijera a un dev junior que ignorara estas herramientas. Pero la tercera afirmación — la de terminado — es donde el marketing adelanta a la máquina. Y la prueba no es alguna objeción filosófica sobre creatividad o artesanía. Es mucho más vergonzoso que eso. Es un parpadeo.
El bug de parpadeo que nadie pudo arreglar en silencio
Si programar estuviera resuelto — si pudieras simplemente apuntar un loop a un problema y dejarlo avanzar hacia una condición de victoria — entonces el equipo de codificación con IA mejor equipado del planeta, haciendo dogfooding de su propia herramienta, escribiendo el 80% de su código con el mismísimo modelo en cuestión, debería poder aplastar un bug de renderizado de terminal sin tropezar.
Eso no es lo que pasó.
Claude Code es una app de terminal — codificación con IA agéntica que vive en tu línea de comandos, lanzada en febrero de 2025. Desde el principio, tenía un notorio problema de parpadeo de pantalla. El contenido del terminal se desplazaba rápidamente, temblaba y mostraba flashes de texto de antes en la sesión — causado porque el renderer redibujaba todo el buffer del terminal en cada actualización de streaming en vez de hacer actualizaciones incrementales por línea. Puedes rastrear el rastro tú mismo a través de un cementerio de issues en GitHub: #769, y una larga cola de seguimientos como #16939, #18084, y #18827, abarcando Windows Terminal, VS Code, Cursor, y los terminales integrados de Android Studio.
Ahora observa la línea temporal, porque la línea temporal es el argumento:
- Principios de 2025 en adelante: Parpadeo reportado repetidamente. Especialmente brutal en terminales basados en xterm.js (VS Code, Cursor), donde el redibujo completo del buffer 2–3 veces por segundo hacía que la pantalla estroboscópica.
- Alrededor de diciembre 2025: Anthropic lo aborda públicamente, supuestamente afirmando una gran reducción del parpadeo con un renderer diferencial reescrito — aproximadamente un tercio de las sesiones aún veían al menos un parpadeo, según informes de la comunidad del despliegue.
- Poco después: Inestabilidad. Un cambio de renderizado sin parpadeo se desplegó, y siguió una regresión — issue #41965 documenta cómo el renderizado "sin parpadeo" de pantalla alternativa de v2.1.89 destruía el scrollback del terminal por defecto. La corrección creó un nuevo problema. Las cosas se revirtieron. Finales de 2025: aún no resuelto limpiamente.
- Alrededor del 1 de abril de 2026: Llega un "no flicker mode" —
CLAUDE_CODE_NO_FLICKER=1— usando un enfoque de alternate-screen-buffer, el mismo truco que usa Vim cuando toma control de tu terminal y lo devuelve intacto al salir (piunikaweb). Funciona. Pero es una evasión, no una corrección de causa raíz: esquiva el problema de redibujo renderizando en otro lugar completamente. Y se lanzó como un research preview, detrás de un feature flag, con un flag complementario para deshabilitar la captura de ratón porque eso introducía su propia fricción. - Finales de mayo 2026: Una interfaz de terminal más nueva aún mostraba mensajes de error poco informativos, "misteriosos" — el manejo de errores en sí mismo sin pulir.
Un ingeniero independiente tituló su análisis "La corrección que tardó un año en llegar." Alguien más lanzó un parche de terceros llamado Claude Chill solo para lidiar con el parpadeo, y llegó a la portada de Hacker News. Cuando los usuarios construyen herramientas externas para arreglar tu renderizado, el renderizado no está resuelto.
Aquí está por qué este único bug lleva tanto peso: no hay excusa de hardware. No hay excusa de infraestructura. No hay escapatoria de "la parte realmente difícil está en otro lado". El parpadeo de pantalla en un terminal es un problema de software puro y autocontenido — exactamente la categoría que la narrativa de "programar está resuelto" dice que es la parte fácil, la parte terminada. Y tomó un año, un rollback, y un workaround controlado por flag en la empresa mejor posicionada de la Tierra para arreglarlo.
Si programar estuviera resuelto, este bug habría muerto en un fin de semana. No lo hizo. Eso no es un gotcha. Son datos.
"Solo escribe loops" funciona — hasta que se encuentra con el bug sin glamour
Quiero ser justo con la tesis del loop, porque genuinamente me gusta. Ejecuto automatización basada en loops en mi propio trabajo — he escrito sobre programar Claude Code en cron loops y sobre el cambio más amplio de un SDLC manual a un ciclo de vida de desarrollo agéntico. Cuando el problema tiene una condición de victoria clara y verificable por máquina — los tests pasan, los tipos verifican, el benchmark se pone verde — un loop bien construido es algo hermoso de ver. Converge. Es lo más cercano a "establece la función de puntuación y vete" que he experimentado en quince años escribiendo software.
Pero nota la forma de los problemas donde los loops brillan: todos tienen una condición de victoria clara.
Un terminal parpadeante no la tiene. ¿Cuál es el test que se pone verde? "Se ve menos tembloroso para un ojo humano a través de cuarenta emuladores de terminal diferentes, cada uno con su propio renderer, en tres sistemas operativos, a frecuencias de actualización variables"? No hay aserción para eso. No hay expect(screen).not.toFlicker(). La condición de victoria es difusa, dependiente del entorno y parcialmente subjetiva — que es precisamente por qué un año de loops no pudo resolverlo. El loop es solo tan inteligente como la función de puntuación que puedas escribir, y algunos de los problemas de software más importantes son exactamente los que no puedes puntuar limpiamente.
Esa es la parte que el encuadre de "programar está resuelto" se salta. Asume silenciosamente que cada problema restante se ve como un test unitario. La mayoría de los difíciles no. Se ven como parpadeo. Se ven como "el mensaje de error es técnicamente correcto pero no le dice nada al usuario." Se ven como la vulnerabilidad de carga de proyecto que los investigadores encontraron en la filtración de código fuente, donde las solicitudes API se disparaban antes de que apareciera el prompt de confianza — un descuido de diseño que ningún test detectó porque nadie pensó en puntuarlo.
Si prefieres que alguien construya y mantenga estos loops agénticos correctamente — con las barandillas y el manejo de errores aburrido-pero-crítico que las demos se saltan — eso es gran parte de lo que asumo. Puedes ver lo que he entregado en fiverr.com/s/EgxYmWD.
Así que el loop no está equivocado. Es estrecho. Es una herramienta fantástica para el medio bien especificado del espacio del problema e inútil en los bordes difusos — y los bordes difusos son donde el software realmente se rompe en producción. Llamar a eso "resuelto" es tomar la parte que puedes medir por todo el trabajo.
El costo humano de pretender que la parte difícil terminó
Ahora quiero hablar de la parte que realmente me molesta, porque el bug es solo la evidencia — esto son las consecuencias.
La narrativa de "programar está resuelto, simplemente haz deploy a prod, escribe el loop, alcanza la condición de victoria" no aterriza en el vacío. Aterriza sobre desarrolladores que, ahora mismo, están más quemados y más ansiosos por sus trabajos de lo que los he visto en mucho tiempo. Y el mensaje está empeorando ambas cosas.
Aquí está el mecanismo cruel, y está bien documentado. Cuando las organizaciones deciden que la IA hizo la programación trivial, no guardan el tiempo ahorrado como holgura — tratan cada minuto ahorrado como un minuto que se debe devolver como más output. El volumen de PR salta 40–60%, y el cuello de botella simplemente se mueve aguas abajo hacia la revisión. Ahora las mismas personas se ahogan en código que no escribieron, en el que no pueden confiar completamente, y están presionados para aprobar rápido. Eso no es menos burnout. Es un nuevo y peor tipo de burnout, y está golpeando a las personas que más abrazaron la IA. Incluso hay todo un género de post-mortems de "la IA se suponía que iba a arreglar el burnout de los desarrolladores" ahora, lo que te dice cómo va el experimento.
Junta las dos mitades y la deshonestidad se agudiza. La gerencia escucha "programar está resuelto" y establece expectativas como si fuera verdad. Los desarrolladores viven en la brecha entre esa afirmación y la realidad parpadeante, que escupe errores, ocasionalmente rota — y se les culpa por la brecha. Te dicen que la parte difícil terminó mientras pasas tu martes depurando por qué el loop desplegó con confianza algo sutilmente incorrecto, con un mensaje de error que no explicaba nada.
Hay una metáfora directa circulando para este tipo de mensajes — que alguien te está haciendo algo en la pierna e insiste en que es el clima. Lo mantendré con buen gusto, pero el sentimiento es correcto. Decirle a ingenieros quemados que su trabajo duro, real, aún necesario es "la parte fácil" — mientras limpian después de las mismas herramientas que se llaman solución — no es optimismo. Es gaslighting disfrazado de estadística de productividad.
Y digo esto como alguien que está abierta, casi vergonzosamente adicto a Claude Code. No soy la resistencia. Soy un usuario intensivo diciéndote que el marketing está firmando cheques que las herramientas aún no pueden cobrar.
Qué está genuinamente resuelto, qué genuinamente no
Déjame ser específico, porque el pesimismo vago es tan inútil como el hype vago. Aquí está mi balance honesto después de usar estas herramientas diariamente durante 2025 y en 2026.
Genuinamente acelerado por IA hoy:
- Boilerplate, scaffolding, código pegamento, configuración — casi instantáneo, casi perfecto.
- Refactors bien especificados con cobertura de tests fuerte — los loops los aplastan.
- Traducir intención a un primer borrador — lo que tomaba 45 minutos toma 6.
- Explorar una codebase o API desconocida — más rápido que la documentación.
Genuinamente mejorado, con advertencias:
- Calidad de código, cuando has construido el arnés (tests, lint, tipos, métricas de aceptación) contra el cual el loop puede puntuar. Sin arnés, sin ganancia de calidad — solo desorden más rápido.
Genuinamente NO resuelto:
- Problemas difusos, no puntuables — renderizado a través de entornos heterogéneos, pulido de UX, "esto es técnicamente correcto pero se siente mal."
- Manejo de errores y diseño de modos de fallo — el 80% sin glamour que las demos nunca muestran, y donde Claude Code mismo aún tropieza.
- Saber qué construir, y si debería existir en absoluto.
- El juicio para anular el loop cuando su condición de victoria es sutilmente el objetivo equivocado.
Nota que la columna "no resuelto" es exactamente donde vive el bug de parpadeo. Eso no es coincidencia. El bug no es un caso atípico — es una muestra representativa del trabajo que el hype declaró terminado.
Entonces, ¿está resuelto programar? No — y la respuesta honesta es más útil que el hype. Programar está acelerado, a veces dramáticamente. Las partes bien especificadas son cada vez más automatizables a través de loops. Pero el núcleo duro, difuso, pesado en juicio — la parte que hace de la ingeniería de software una profesión y no una competencia de velocidad de tecleo — está exactamente tan sin resolver como estaba, y los propios bug trackers de las herramientas lo prueban.
Preguntas frecuentes
¿Está la programación realmente resuelta por IA en 2026?
No — la programación está dramáticamente acelerada, no resuelta. Las herramientas de IA sobresalen en tareas bien especificadas y verificables por máquina (boilerplate, refactors, tests que pasan) pero aún luchan con problemas difusos y no puntuables como renderizado cross-environment, pulido de UX y diseño de modos de fallo. La prueba es que incluso las herramientas de codificación con IA se lanzan con bugs de larga duración que sus propios loops no pueden arreglar.
¿Qué significa "solo escribe loops" en la codificación con IA?
"Solo escribe loops" se refiere a harness engineering — en vez de hacer prompts a una IA un mensaje a la vez, construyes un sistema que ejecuta el modelo a través de ciclos repetidos de observar-planificar-actuar-reflexionar hasta que alcanza una condición de victoria definida como tests que pasan. Es una técnica genuinamente poderosa, pero solo funciona donde puedes escribir una función de puntuación clara, lo que excluye muchos problemas del mundo real.
¿Por qué es significativo el bug de parpadeo de Claude Code?
El bug de parpadeo es un problema de software puro sin excusa de hardware o infraestructura, sin embargo tomó aproximadamente un año, un rollback, y un workaround controlado por flag para abordarlo — en la empresa mejor posicionada para arreglarlo. Eso lo convierte en el contraejemplo más limpio a la afirmación de que "programar es la parte fácil" del software moderno. Para la línea temporal completa, consulta la sección anterior.
¿Está la codificación con IA causando burnout en los desarrolladores?
Los informes y post-mortems de 2026 sugieren que sí — no porque la IA haga menos trabajo, sino porque las organizaciones convierten el tiempo ahorrado en más output, aumentando el volumen de PR un 40–60% y desplazando la carga a la revisión de código abrumada. La narrativa de "programar está resuelto" agrava esto al establecer expectativas que no coinciden con la realidad más desordenada que los desarrolladores realmente enfrentan.
El recibo al que sigo volviendo
Abrí con un terminal parpadeante, así que déjame cerrar ahí.
Cuando alguien te diga que programar está resuelto, hazle una pregunta: si eso es verdad, ¿por qué las personas que lo dicen más fuerte pasaron un año arreglando una pantalla que no dejaba de temblar — y luego lanzaron la corrección detrás de un feature flag? No hay hardware al que culpar. No hay infraestructura detrás de la cual esconderse. Solo un problema de software difícil y sin glamour haciendo lo que los problemas de software difíciles siempre han hecho: resistir a las personas que lo subestimaron.
Usa las herramientas. Construye los loops. Lanza más rápido — yo lo hago, cada día, y soy mejor por ello. Pero mantén la línea en la verdad: programar no está resuelto, está amplificado. La parte difícil no desapareció. Se movió a donde los loops no pueden llegar, y sigue siendo tuya.
Y honestamente? Esas son buenas noticias. Porque significa que el juicio que has pasado años construyendo es la parte que no se automatizó — es la parte que se volvió más valiosa. No dejes que una diapositiva de productividad te convenza de lo contrario.
Esta noche, aquí está lo único que vale la pena hacer: la próxima vez que encuentres un bug que tu IA falló con confianza en arreglar, no te sientas atrasado. Haz una captura de pantalla. Ese bug es la parte del trabajo que sigue siendo tuya — y es la parte que paga.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
