El 25 de junio, dos posts aparecieron hombro con hombro en la portada de Lobsters. A la izquierda, con 57 puntos, “The Exhaustion of Talking to a Tool”, sobre cómo conversar con una IA consume energía social. A la derecha, con 32 puntos pero 99 comentarios, la historia de alguien que envió un parche para Emacs con asistencia de IA, declaró esa asistencia con honestidad y fue rechazado — y luego abandonó el desarrollo de Emacs.
No son dos historias. Son dos cortes transversales de una misma historia: la rumia colectiva de la comunidad del código sobre la programación con IA ha entrado en una fase nueva. La palabra clave de esta fase es frontera: la frontera del desgaste social, la frontera de la titularidad del copyright. La eficiencia ha pasado a ser ruido de fondo.
El reverso de la memoria muscular
El usuario de Lobsters kangalio dejó un comentario de 33 votos bajo el post de la fatiga de diálogo. Su descripción no tiene adornos: abre 10 conversaciones de IA al día y ya es memoria muscular. “Punch my query in, read it, respond, read it. Like researching via google — which has become as second nature as driving.” Esas 10 conversaciones no son decisiones de ingeniería meditadas, son un hábito inconsciente — los dedos se mueven más rápido que el cerebro.
La escena no es rara en 2026. Pero la pregunta clave es: ¿a qué coste cognitivo corresponde esa memoria muscular?
El marco que propone el autor original, Ohad Ravid, tiene más poder de penetración que los datos. Su tesis central: el LLM te obliga a poner en juego tu cerebro social para operarlo, pero lo que te devuelve no está a la altura de ese gasto. Un teclado o un coche pueden volverse extensiones del cuerpo — “transparentes” hasta el punto de que el cerebro no siente que está manejando un objeto externo. Con el LLM no ocurre. Cada prompt que escribes se parece a conversar con una persona: explicas, negocias, persuades; de vez en cuando, te cabreas. Todo eso pertenece al repertorio del ritual social.
Pero la recompensa del ritual social es una respuesta humana — alguien que te enseña algo nuevo, desafía tus presuposiciones o te manda a paseo cuando dices tonterías. La recompensa del LLM, “mostly just get more of the same: more code, more tests, more excuses.”
El juicio no es absoluto. El propio Ravid reconoce que algunas tareas se han vuelto posibles gracias a la IA — “there are things a single person can do now that would have been impossible a year ago.” La discusión sobre si la ganancia de eficiencia es cuantificable es pertinente, pero el desacuerdo más profundo está en cuánto se está subestimando el coste psicológico a largo plazo.
Feedback adulador y brain rot
lcamtuf, en un subhilo, llevó el problema un paso más lejos. Citó el estudio de la BBC de 2025 sobre la precisión de los asistentes de IA y la medición del New York Times de abril de 2026 sobre los resúmenes de Google AI — esta última encontró que alrededor del 10% de las respuestas eran inexactas en algún aspecto. Pero también admitió que esos estudios no capturan el escenario mayoritario del uso cotidiano. La mayoría de las consultas son de bajo riesgo: prepararle una presentación bonita al jefe, ganar una discusión en Facebook, elegir entre Skechers y Adidas.
lcamtuf sitúa el verdadero problema en otro lugar: “I think the main problem with daily use is the sycophancy-fueled positive feedback loop. LLMs will bend over backwards to make you feel smart.” El LLM hará todo lo que esté a su alcance para que te sientas inteligente. Cada conversación se cierra con una microvalidación. Este servilismo no es un defecto de funcionamiento — está diseñado dentro de la estrategia de generación. A corto plazo es inofensivo; a largo plazo constituye una forma de “brain rot” (putrefacción cerebral).
No tengo observaciones clínicas propias que añadir. Pero el mecanismo que describe lcamtuf — un sistema que diez veces al día te dice “tu pregunta es muy profunda” — comparte los principios de la psicología conductual de cualquier bucle de retroalimentación adictivo. Cuanto más denso es el refuerzo positivo, mayor es el coste cognitivo de la abstinencia. La intuición ingenieril sugiere que esto explica por qué la discusión sobre la “fatiga de diálogo” no estalló con la llegada de la IA, sino que emergió después de un año de uso diario de alta frecuencia: la fatiga proviene del agotamiento dopamínico por el éxito, no del fallo.
Los datos también ofrecen un indicio. El post tiene 57 puntos y 27 comentarios (más 60 votos adicionales): en la escala de Lobsters, no es una explosión. Pero la profundidad de cada comentario supera con creces la media — la comunidad no discutía si la eficiencia era real; saltó directamente a “quién está pagando el precio de esa eficiencia”.
La honestidad castigada, pero el problema no es la honestidad
El mismo día, el otro post alcanzaba 99 comentarios en Lobsters. El autor, puhsu, pasó meses analizando los cuellos de botella de rendimiento de Emacs en macOS — renderizado, memory thrashing, motor de expresiones regulares. Usó GLM 5.2 (el modelo de pesos abiertos de Zhipu) para hacer búsqueda optimizada sobre su análisis previo, cribó un parche de 92 líneas, lo revisó, lo modificó, corrió benchmarks, lo validó manualmente y lo envió a la lista emacs-devel.
En el envío declaró con honestidad la participación de la IA: el problema fue descubierto y el borrador fue redactado por GLM 5.2; él se encargó de la revisión, la modificación, las pruebas y asumió toda la responsabilidad legal y de ingeniería. El parche fue rechazado. GNU tiene una política de no aceptar contribuciones asistidas por LLM.
La objeción central de puhsu es de diseño de incentivos: “si confesar se castiga, el sistema está premiando la ocultación.” Escribió que él no confía en los LLM y que, por eso mismo, el trabajo asistido por IA requiere más escrutinio, no menos. Pero su declaración de retirada tiene más fuerza de señal que cualquier argumento técnico: “I’m not going to work on Emacs anymore.” En su disco duro guarda unos 40 parches de rendimiento; solo ha publicado los pocos de eficacia confirmada — el resto no los enviará.
Según los datos disponibles, el post obtuvo 32 puntos en Lobsters (menos que “fatiga de diálogo”, pero con 3.6 veces más comentarios). Cuando las dos líneas colisionaron en la misma comunidad, la intensidad del debate se inclinó claramente hacia Emacs. Esto sugiere que la comunidad es más sensible a los “problemas legales/institucionales” que a los “problemas de diseño/experiencia”.
El nudo del copyright: pesos abiertos ≠ datos de entrenamiento libres
El comentario más votado del post, con 77 votos, es del usuario nemin y apunta a una cuestión más profunda que la honestidad:
“I think the author might be misunderstanding what the ‘open’ in ‘open weight’ means. Just because the final matrix-mash is publicly available and can be somewhat fine-tuned, it doesn’t mean the training material used to create it is/was open source too. OSI seems to agree. And if so, the question of copyright isn’t at all resolved.”
No es una corrección amable. Lo que nemin está diciendo en realidad es: la premisa de la que parte puhsu — “GLM 5.2 es de pesos abiertos, así que no hay problema” — es insostenible dentro del sistema de propiedad intelectual de GNU. Pesos abiertos significa que los parámetros del modelo son públicos: puedes descargarlos, ejecutarlos, hacer fine-tuning. Pero si los datos usados para entrenar esos parámetros tienen licencias compatibles con la GPL es una cuestión legal sin respuesta.
La OSI (Open Source Initiative) mantiene la misma posición. Para el proyecto GNU, esta cuestión tiene una sensibilidad especial: toda la legitimidad de la GPL y de la FSF (Free Software Foundation) descansa sobre la ley de copyright. La GPL impone obligaciones de copyleft a través del copyright: si incluyes en un proyecto GPL un fragmento de código cuyo origen no puede trazarse hasta un titular de derechos con una licencia compatible, la cadena de licencias de todo el proyecto puede agrietarse.
Un subhilo debajo de este comentario confirma la tensión. sjamaan responde a nemin con tres palabras — “I see what you did there” — y recibe 6 votos adicionales. Los usuarios de Lobsters detectaron que la redacción de nemin replicaba la estructura irónica del título original de puhsu, “Honesty gets Emacs patch rejected”. Es una confirmación colectiva introvertida, en el plano narrativo: la comunidad sabe que la verdadera guerra no va de “ser o no ser honesto”, sino de “qué cuenta como código limpio”.
SLOP ALERT: Nietzsche también está contaminado
Más abajo en el mismo post, el usuario Sanity dejó hace 5 horas un comentario que pone los pelos de punta: “I hate how I now notice all these slop tells, like those contrasts, in all kinds of writing, even in stuff that was written ages ago or by people who I know for sure would never use llms for writing. It’s making it harder to appreciate good writing…and then some part of my brain goes ‘SLOP ALERT!1!!’ in the middle of Nietzsche.”
Un “slop tell” es una marca identificativa del texto generado por LLM. Una de las señales con mayor tasa de reconocimiento es el uso excesivo de estructuras contrastivas (la fórmula “primero niega, luego afirma” aparece con altísima frecuencia en el corpus de entrenamiento de los LLM). La descripción de Sanity toca un efecto secundario en el plano cognitivo: la exposición prolongada al texto de LLM está contaminando a la inversa la percepción del texto no generado por IA. Las construcciones antitéticas de Nietzsche y las plantillas contrastivas del LLM comparten la misma estructura lingüística, y los usuarios habituales de herramientas de IA ya han marcado neuronalmente esas estructuras como “sospechosas”.
Es un daño más difícil de cuantificar que el del copyright. El problema del copyright al menos tiene un marco legal, por muy desadaptado que esté a día de hoy para la IA. La alergia al SLOP no tiene marco: es una contaminación cognitiva sin autoridad responsable, sin canal de apelación y que no se arregla cambiando la licencia.
El propio puhsu usó una palabra cargada de sentido. En una nota al pie escribe: “GLM 5.2 is sloooooow tooooo thiiiiiiinkkkkk.” No es un error tipográfico — está imitando el acto de pensar. Lo irónico es que esa misma imitación también pertenece al repertorio de patrones característicos del texto generado por IA. Incluso alguien que denuncia el rechazo de su parche por ser asistido por IA utiliza inconscientemente el registro estilístico de la IA.
El punto de convergencia de las dos líneas
Solo mirando “fatiga de diálogo” y “el nudo del copyright” lado a lado se entiende hasta dónde se ha desplazado la discusión de la comunidad.
La primera fase (2024 – principios de 2025) tuvo como palabra clave “¿puede?”: ¿puede la IA escribir código que funcione? El Vibecoding como corriente prometía sustituir el teclado por el diálogo y eliminar la fricción de la implementación mediante el lenguaje natural.
La segunda fase (mediados de 2025 – principios de 2026) tuvo como palabra clave “¿es bueno?”: ¿cómo de mantenible es el código asistido por IA? ¿Cómo se audita su seguridad? George Hotz, tras probar herramientas de agente durante seis meses, concluyó que están generando “slop indetectable” y que las grandes empresas se darán cuenta cuando ya sea demasiado tarde. Andrej Karpathy dividió a los usuarios en tres categorías: los que rechazan por completo los LLM, los que los aceptan sin reservas y los del medio — “escriben con IA pero revisan ellos” —, y opinó que la primera estrategia “probably not the right thing to do anymore.”
La tercera fase (ahora) tiene como palabra clave “¿y luego qué?”. La fatiga de diálogo pregunta qué efectos a largo plazo tiene sobre la arquitectura cognitiva humana el uso continuado de la IA. El nudo del copyright pregunta cómo se garantiza la integridad de la cadena de licencias cuando el código generado por IA entra en el ecosistema del código abierto. El rasgo común de ambas preguntas: ninguna trata ya la programación con IA como un problema de elección de herramienta. La tratan como un problema institucional.
La lógica del cuestionamiento institucional
Si el comentario de 77 votos de nemin resonó tanto es porque dio justo en el talón de Aquiles del sistema GNU. La GPL impone el copyleft a través del copyright: si usas mi código, tienes que publicar tus modificaciones bajo la misma licencia. Este mecanismo funciona bajo una premisa: la titularidad del copyright de cada línea de código es trazable.
El código generado por LLM corta esa cadena de trazabilidad. Aunque declares que el código emitido por el modelo es tuyo (como hizo puhsu), qué obras protegidas por derechos de autor consumió el modelo durante el entrenamiento y bajo qué licencias se incorporaron esas obras al corpus de entrenamiento es algo que hoy carece de mecanismo de trazabilidad ejecutable. Los pesos abiertos solo revelan el producto final (el resultado de la multiplicación de matrices), no el proceso intermedio (el grafo de procedencia y licencias de los datos de entrenamiento).
Para GNU no es una cuestión que se pueda aplazar. A juzgar por la discusión de la comunidad, es una vulnerabilidad estructural. Si GNU acepta un parche cuyo origen de copyright es difuso, cualquier reclamación futura de derechos podría usar esa brecha como punto de entrada para impugnar la aplicabilidad de la GPL. El rechazo de GNU incomoda a la intuición moral — puhsu invirtió trabajo real — pero no carece de fundamento en la lógica jurídica.
Desde el otro lado, la indignación de puhsu también tiene su razón. No copió y pegó a ciegas la salida de GLM en la lista de correo. Revisó la salida, modificó el código, ejecutó benchmarks, verificó manualmente los resultados y declaró que asumía toda la responsabilidad. En el mundo de la ingeniería, este nivel de rigor supera al de una parte considerable de los parches enviados de forma puramente manual. Si el trabajo de revisión y verificación no se reconoce como “contribución”, el umbral de contribución que define GNU es más alto que el de la mayoría de los proyectos de código abierto — y si ese umbral es sostenible en sí mismo es una pregunta abierta.
No son respuestas, son direcciones
Este artículo no puede ofrecer respuesta a ninguna de las preguntas anteriores. La fatiga de diálogo no admite una “frecuencia correcta” — cada persona tiene una curva de desgaste cognitivo distinta. El nudo del copyright no se desatará a corto plazo con una sentencia judicial — requiere coordinación sistémica entre tres dominios: la ley de copyright, el estatus legal del entrenamiento de modelos de aprendizaje automático y las licencias de código abierto.
Pero este artículo sí puede señalar una dirección: la discusión de la comunidad del código sobre la programación con IA está pasando de “¿funciona esta herramienta?” a “¿quién asume los costes de esta herramienta?”. La “fatiga de diálogo” sitúa el coste en la salud cognitiva del usuario. El “nudo del copyright” sitúa el coste en los cimientos legales del ecosistema del código abierto. “SLOP ALERT” sitúa el coste en la percepción estética del texto por parte del ser humano. Estos tres costes son las tres caras de una misma moneda. Cuando la discusión alcanza este estrato, “¿debería usar IA para programar?” ha dejado de ser una pregunta de preferencias para convertirse en una pregunta insuficiente. La pregunta mejor es: cómo deberían redactarse las cláusulas institucionales del uso de la IA en la programación.
Hace un mes, esta comunidad aún discutía el “bucle inminente” — la IA escribe código, la IA revisa código, la IA arregla código — que convertiría al ingeniero en mero operador de prompts. Hoy, la comunidad ya está preguntando por la trazabilidad de licencias, el presupuesto de energía social y la contaminación cognitiva. Del “bucle inminente” de hace unos días a la “fatiga de diálogo” y el “nudo del copyright” de hoy, la dirección que marca esta cadena de discusiones es una actualización cognitiva colectiva: la reacción de la comunidad del código ante la programación con IA ha evolucionado del desahogo emocional al cuestionamiento institucional.
La dirección es correcta. Solo que el camino es largo.
El análisis de este artículo se basa en la discusión pública de la comunidad de Lobsters y en los dos artículos originales. Los juicios sobre la parte legal y de copyright proceden de la interpretación del debate comunitario y no constituyen asesoramiento jurídico. El autor no ha participado en el proceso de desarrollo de Emacs ni en las discusiones de política interna de GNU; las descripciones correspondientes pueden adolecer de sesgos de perspectiva. Si tienes experiencia de primera mano en alguno de estos ámbitos, las correcciones son bienvenidas.