En la tercera semana de junio, una silenciosa reflexión colectiva se extendió por la comunidad del código.
El punto de partida se remonta al breve ensayo The Coming Cycle, publicado por Armin Ronacher. El creador de Flask y Click lanzó a la comunidad una señal casi de advertencia: estamos entrando en un ciclo que empezará con la euforia por la comodidad de programar con IA y continuará, durante el mantenimiento y la depuración, con el enfrentamiento a los costes sistémicos que esos artefactos generados traerán consigo. El breve texto fue como una piedra lanzada a un lago: en los días siguientes, las ondas se expandieron en círculos concéntricos.
Primero fue el autor técnico Igor Roztropiński, cuyo artículo The Joy and Power of Understanding alcanzó 66 puntos de discusión en Lobsters. Casi al mismo tiempo, The Exhaustion of Talking to a Tool, de Ohad Ravid, obtuvo 28 puntos en la misma comunidad y le puso nombre a un malestar que hasta entonces no había sido nombrado. Dos días después, un maintainer de Emacs rechazó un parche cuyo autor había declarado honestamente la asistencia de IA; el artículo de reflexión de xlii, Honesty gets Emacs patch rejected, generó 19 puntos y 35 comentarios en Lobsters. Un día antes, You can’t unit test for taste, de Karl Tryggvason, había alcanzado los 230 puntos en la portada de Hacker News, defendiendo una tesis aparentemente modesta pero oportunísima en esa discusión: lo más importante del código es precisamente lo que no se puede automatizar.
Estos cuatro artículos no forman una serie coordinada. Salieron de autores distintos, abordando problemas distintos y generando discusión en plataformas distintas. Pero al ponerlos uno al lado del otro, emerge una línea narrativa coherente: la historia de cómo la programación con IA está pasando de la euforia a una fase más compleja. Intentaré aquí trazar esa línea, manteniendo una distancia de observación objetiva.
Uno. Cuando empiezas a sentirte cansado
El artículo de Ohad Ravid le dio a esta reflexión un punto de partida emocional. Escribió sobre algo que muchos desarrolladores están experimentando pero que les cuesta expresar: programar dialogando con un LLM, resulta que cansa.
El artículo propone un marco: la relación entre el ser humano y sus herramientas admite dos modos. Uno es la “magia de la herramienta”: cuando usas un buen martillo, un buen teclado o un volante que responde bien, tu cerebro los integra como una extensión del cuerpo, no tienes que “comunicarte”, simplemente “los usas”. El otro es el “cerebro social”: cuando negocias, explicas, persuades o incluso te enfadas, estás activando recursos psicológicos que la evolución reservó para la interacción entre personas.
El problema es que los LLM caen en la intersección de ambos modos. No son lo bastante rápidos ni consistentes para activar la magia de la herramienta, pero usarlos te obliga constantemente a describir necesidades, corregir desviaciones y perseguir omisiones, lo cual es, en esencia, un acto social. Ravid escribe: “Pagas el impuesto social, pero lo único que obtienes a cambio es más código, más tests, más excusas.” Mientras que lo social auténtico —discutir con personas, ser desafiado, ser inspirado— al menos vale la pena.
La fuerza de este artículo está en haber puesto nombre a un agotamiento difuso. Hasta ese momento, el relato dominante era “programar en pareja con IA es muy productivo”. La contribución de Ravid fue hacer una pregunta más personal: más allá de la productividad, ¿cómo te sientes?
Me ha llamado la atención que este artículo toca una dimensión aún insuficientemente discutida: la sustituibilidad de la carga cognitiva. Al escribir código activas el modelado y el razonamiento lógico; al describir requisitos a un LLM activas la expresión verbal y la calibración de intenciones. Son dos sistemas cognitivos distintos. El cambio frecuente entre ellos produce agotamiento por sí mismo, independientemente de la calidad de la herramienta.
Dos. Comprender, como propuesta que pasa de moda
Si Ravid describió el punto de dolor, The Joy and Power of Understanding, de Igor Roztropiński, ofrece una respuesta orientada a la dirección correcta.
El artículo tiene una tesis sencilla: entender de verdad los fundamentos es a la vez una fuente de placer y un foso competitivo. El autor dedica un espacio considerable a explicar por qué los humanos tendemos instintivamente a saltarnos la comprensión: somos organismos que minimizan el gasto energético, y los LLM ofrecen precisamente el camino cognitivo más corto. Un prompt en inglés y sale la consulta SQL: ¿para qué molestarse en aprender la sintaxis?
Pero Roztropiński recuerda al lector: puedes entender hoy la SQL generada, pero “leer” y “escribir” no son lo mismo. La lectura pasiva no basta para mantener la habilidad, y un periodo prolongado sin practicar conduce inevitablemente a la degradación. Si las capacidades centrales se externalizan todas al modelo, los cimientos mismos de la identidad de “ingeniero de software” se erosionarán lentamente.
Uno de los argumentos más potentes del artículo es el concepto de “deuda cognitiva”. Reconoce que, en ciertos escenarios, aceptar una comprensión incompleta es razonable: scripts de un solo uso, experimentos internos, fases de MVP. Pero estas son deudas a corto plazo, y hay que ser consciente de que devengan intereses. Si los sistemas centrales también toman ese camino, “nos encontraremos en el momento equivocado sin poder ni reparar ni modificar.”
La discusión en Lobsters aportó al menos dos complementos clave. Un comentario citó el clásico de Fred Brooks sobre “los placeres de la programación”: crear y aprender son en sí mismos la recompensa intrínseca de programar. Otro comentario, más afilado, del usuario hgrsd, apuntó directamente a la lógica económica: los laboratorios de IA tienen un incentivo económico para que los usuarios pierdan sus habilidades, porque la dependencia es la base de su valoración. Este comentario recibió 15 puntos, convirtiéndose en la observación periférica con más peso en todo el debate.
Necesito detenerme aquí un momento. Esta tesis —“el que te vende la pala quiere que siempre la necesites”— no es una teoría conspirativa, sino la lógica convencional de la economía de plataformas. Las redes sociales quieren que sigas scrolleando, las plataformas de ride-hailing que sigas pidiendo coches, las de comida a domicilio que sigas pidiendo. Si los servicios de programación con IA siguen el mismo modelo de negocio, entonces ese objetivo aparentemente moderado de “usar IA pero no depender de ella” puede ser nadar a contracorriente de fuerzas estructurales.
Al mismo tiempo, observo un espacio en blanco en este artículo: no aborda suficientemente la naturaleza estratificada de la propia “comprensión”. En la práctica de la ingeniería actual, es casi imposible tener una comprensión completa de todas las capas de un sistema —del sistema operativo al framework de aplicación, de los protocolos de red al motor de base de datos—. La verdadera pregunta es en qué capa situamos la línea roja de la comprensión, no una elección binaria de todo o nada.
Tres. Cuando la honestidad se castiga
El tercer artículo traslada la discusión del plano abstracto a un suceso concreto.
xlii pasó varios meses analizando los problemas de rendimiento de Emacs en macOS y fue formando su propio diagnóstico: sobrecarga de renderizado, memory thrashing, cuellos de botella en el procesamiento de expresiones regulares. Utilizó el modelo GLM 5.2 como apoyo en la búsqueda y el análisis, encontró un punto de optimización concreto, verificó el impacto por sí mismo, modificó el parche, ejecutó los benchmarks y lo envió a la lista de correo emacs-devel. Declaró honestamente la participación del LLM.
El resultado fue el rechazo del parche. GNU tiene una política: no acepta trabajos asistidos por LLM. La postura del maintainer fue clara: “Nosotros revisamos tu pensamiento, no la salida del modelo.”
La respuesta de xlii expresó varias capas de emoción sucesivas. Primero, la indignación ante una política que castiga al honesto: si no lo hubiera dicho, ¿quién lo habría descubierto? Segundo, el cuestionamiento de la coherencia lógica de la política: GLM 5.2 es un modelo de pesos abiertos; si se ejecuta localmente sí valdría pero por API no, ¿tiene esa distinción algún fundamento técnico? Tercero, la retirada tras la decepción: decidió no volver a trabajar para Emacs. “No me gusta que me digan cómo sostener el palo, sobre todo cuando estoy trabajando voluntariamente.”
Los 35 comentarios que este artículo generó en Lobsters reflejan una nueva normalidad a la que se enfrenta la comunidad del código abierto: cuando las contribuciones generadas por IA empiecen a llegar de forma inevitable, ¿cómo deben responder los maintainers? Rechazarlo todo puede ahuyentar a contribuyentes serios y responsables como xlii; aceptarlo todo puede abrir las compuertas del slop. No hay una solución intermedia elegante.
Me he fijado en que la estructura profunda de este conflicto es, en realidad, más relevante que la pregunta de “¿es razonable la política de GNU?”. Su esencia es un problema de asignación de confianza: en la revisión de código, ¿confías en la corrección lógica del código (verificable) o en el proceso de pensamiento del autor (que nunca podrá reconstruirse por completo)? El maintainer de Emacs eligió lo segundo, y esta elección va a enfrentar una presión creciente en la era de la IA. Cuando el volumen de contribuciones crezca hasta cierto punto, la tentación de revisar solo el resultado aplastará el apego a revisar la intención.
Cuatro. El gusto, ese paso que no se puede automatizar
El artículo de Karl Tryggvason eleva el debate desde el código mismo hacia dominios más amplios: pipelines de datos, filtrado de puntos de interés, juicio subjetivo.
Había emprendido un proyecto: emparejar automáticamente rutas de running con puntos de interés a lo largo del recorrido. El proceso implicaba limpieza de datos de GeoNames, referencias cruzadas con Wikipedia, puntuación mediante LLM y otros pasos. Durante el experimento, descubrió que el LLM, al generar resúmenes de texto, alucinaba: convertía el Central Park de Decatur, Illinois, en el de Manhattan. Así que eliminó la función generativa del LLM y conservó solo su capacidad de puntuación.
Pero entonces surgió la pregunta: ¿cómo evalúas si la puntuación es buena o no? El número de idiomas en Wikipedia es una señal objetiva, pero si un pequeño pueblo tiene 150 páginas de Wikipedia generadas por traducción automática, la señal está contaminada. La puntuación subjetiva del LLM puede compensar ese sesgo, pero no puedes escribir un test unitario para verificar si la puntuación es “correcta”. Tryggvason escribe: “Donde no existe ground truth, no hay test unitario rojo/verde.”
Esta frase encaja exactamente con el vacío que los dos artículos anteriores no habían llenado. Roztropiński dijo “comprendan los fundamentos”. Ravid dijo “el impuesto social cansa”. Pero Tryggvason añade una observación más sutil: incluso en un proyecto que tú mismo entiendes por completo, la asistencia de la IA se atasca en esa frontera de lo “adecuado pero no del todo correcto”, y ni siquiera puedes describir en el lenguaje lógico del código por qué le falta ese algo.
La discusión en Hacker News profundizó este ángulo. Un comentario dijo: “El gusto es lo que olvidaste escribir en la especificación, más lo que no podrías escribir aunque lo intentaras.” Otro añadió: “No puedes externalizarme por completo; si yo pudiera volcar todo el conocimiento que tengo en la cabeza y dárselo a la máquina, lo haría, pero es imposible.” Alguien aportó una analogía: un jefe de bomberos ordena por instinto la evacuación total de su equipo; no sabe explicar por qué, pero el suelo se derrumba acto seguido. En la ingeniería de software abundan los juicios intuitivos cuya fiabilidad se basa en la experiencia acumulada, no en reglas explícitas que puedan documentarse.
Este es quizá el paso más silencioso pero a la vez más potente de toda la cadena de reflexión. No dice que la IA sea mala. Dice que cuanto más en serio usas la IA, más descubres aquellas partes que no pueden ser sustituidas.
Cinco. La señal de fondo de esta ola de reflexión
Al encadenar los cuatro artículos, observo varias líneas transversales.
Primera: la narrativa está pasando de “¿uso IA o no?” a “¿cómo uso la IA?”. Hace medio año, el debate era aún si la IA podía escribir código utilizable. Ahora la respuesta a esa pregunta está bastante clara: sí puede, pero con costes. El centro de gravedad del debate se ha desplazado hacia la cuantificación y la gestión de esos costes: la fatiga es un coste, la pérdida de habilidades es un coste, la dilución de la confianza de los maintainers es un coste, la erosión del gusto es un coste.
Segunda: los cuatro artículos disparan contra la cultura de “sustituir la comprensión por IA”, no contra la IA en sí. Nadie en estos cuatro textos aboga por volver a una época artesanal sin IA. Roztropiński dice que acepta la generación de scripts de un solo uso; Ravid dice que hay tareas donde la capacidad individual se expande enormemente; xlii dice que el LLM le ayudó a encontrar puntos de optimización que no había detectado; Tryggvason dice que la función de puntuación del LLM sí es útil. Todos se oponen a lo mismo: externalizar la comprensión y luego fingir que sigue siendo propia.
Tercera: la acuñación del concepto de “impuesto social” puede estar marcando la transición de la narrativa sobre la programación con IA de la eficiencia a la experiencia. Antes, el debate era cuánto más rápido te hacía programar la IA. El artículo de Ravid cambió el sistema de coordenadas: vale, y si te hace más rápido, ¿te sientes bien? Esta transición sigue la misma trayectoria de cualquier tecnología que alcanza la madurez: la gente pasa de evaluar lo que hace a evaluar cómo te sientes mientras lo hace.
Cuarta: el desafío de gobernanza al que se enfrentan los maintainers del código abierto y la ansiedad por la pérdida de habilidades de los desarrolladores individuales son las dos caras de la misma moneda. El rechazo del parche de xlii tiene su raíz en la ruptura de la cadena de confianza. El incentivo económico de los laboratorios de IA que señala hgrsd tiene su raíz en el empuje inherente al modelo de negocio. Ambas cosas recuerdan lo mismo: el problema de la programación con IA no es solo técnico; es también un problema de gobernanza, económico y psicológico.
No creo que estas reflexiones anuncien un movimiento “anti-IA”. Que el artículo del “gusto” alcanzara 230 puntos en Hacker News demuestra precisamente la actitud de la comunidad: pasar del abrazo a la contención. El entusiasmo persiste, pero la dirección se ha ajustado: la IA es una herramienta, no debe sustituir la comprensión; la IA es un acelerador, no debe tomar el volante; la IA puede ayudar, pero no debe volverte más tonto.
Quizá esa sea la forma concreta que adopta “el ciclo que se avecina” en esta fase: una calibración, no un colapso. La comunidad ha recorrido en dos o tres días un microciclo entero, de la euforia a la cautela. La pregunta que sigue es: cuando la marea de la reflexión se retire, ¿cambiarán los hábitos cotidianos de desarrollo? No tengo respuesta, pero al menos estos cuatro artículos han dejado la pregunta mucho más clara.
Declaración del autor: las discusiones de comunidad citadas en este artículo se basan en contenido web públicamente accesible. No he participado en la contribución de código ni en la discusión de ninguno de los proyectos mencionados. El análisis de los incentivos económicos de los laboratorios de IA es una paráfrasis del punto de vista del usuario hgrsd, que yo me he limitado a incorporar como un eslabón clave en la cadena narrativa. Todos los juicios de valor quedan reservados al lector. Cualquier lectura errónea o sobreextensión de un artículo concreto es responsabilidad exclusivamente mía.