Jeremy Theocharis, CTO de UMH, publicó un post que pone en palabras una sensación generalizada: los críticos de los LLM tienen razón en casi todo, y él los usa de todas formas. El artículo recibió más de 300 puntos en Hacker News, y los comentarios muestran que la disonancia descrita es compartida por muchos.

Theocharis cuenta que estuvo en la Local-First Conf en Berlín, donde los ponentes criticaban los LLM recibiendo aplausos cerrados, mientras la audiencia tenía Claude Code abierto en la laptop. Armin Ronacher, creador de Flask, admitió desde el escenario que auto-cierra casi todos los PR e issues en su proyecto Pi.dev, porque están inundados de contribuciones generadas por modelos.

Por qué te importa. Si usas IA en tu trabajo, probablemente ya conoces esta tensión. Los problemas son reales: la inundación de contribuciones de baja calidad está erosionando la confianza en el open source, y quienes deberían aprender del trabajo tedioso delegado por los seniors se encuentran sin camino de crecimiento. Pero la herramienta, usada con criterio, ahorra horas reales. Como contábamos cuando el creador de Zig y George Hotz convergían en la misma posición, los LLM son útiles y el hype sobre la singularidad es vacío (/es/radar/zig-geohot-anti-hype-convergence).

La conversación útil está entre quienes usan la herramienta y quieren usarla mejor, sabiendo exactamente dónde falla.

En detalle

Theocharis estructura el post en tres partes: las críticas válidas, por qué usa los LLM de todas formas, y los patrones concretos que ha encontrado.

Las críticas que comparte. El entrenamiento con materiales protegidos por derechos de autor, el impacto ambiental, la burbuja financiera alrededor de NVIDIA y OpenAI: Theocharis dice estar de acuerdo en casi todo. El punto que profundiza más es la calidad de las contribuciones open source. Antes de los LLM, crear un pull request decente requería tiempo humano, y ese tiempo funcionaba como filtro natural. Ahora cualquiera puede abrir una cuenta GitHub y lanzar un modelo en un repositorio, y el maintainer no puede distinguir la contribución pensada de la generada en masa. Proyectos como Zig y Gentoo ya intentaron rechazar PR generadas por IA, pero Theocharis nota que es imposible verificarlo de manera confiable.

El segundo punto trata sobre los junior developers. Un senior siempre ha corregido el código de los junior, pero antes sabía que el junior había pasado horas en esa tarea. Ahora no lo sabe. Y dado que las tareas repetitivas, aquellas que servían como cantera de aprendizaje, pueden delegarse a un LLM, el senior tiene menos incentivo para tomar junior developers y enseñarles el oficio.

Por qué usa los LLM de todas formas. Theocharis no ofrece una defensa filosófica. Dice que la herramienta funciona para su trabajo, y que negarlo sería negar la evidencia. La posición converge con otras voces técnicas de la comunidad: reconocer los defectos significa usar la herramienta con los ojos abiertos, no renunciar al beneficio.

Los comentarios en Hacker News muestran la misma escisión. Muchos confirman el problema de la confianza en las contribuciones. Otros subrayan que el modelo de negocio del open source basado en voluntariado ya era frágil antes de los LLM. Algunos notan que la solución está en construir sistemas de verificación y confianza diferentes, quizá basados en identidad verificada fuera de línea, en lugar de prohibir outputs que no se pueden distinguir.

Qué queda abierto. El post no resuelve la tensión, la nombra. Para quien trabaja con IA, el takeaway práctico es el que el curso trata en la lección sobre confianza calibrada: no todos los errores pesan igual, y saber dónde mirar antes de usar un resultado importa más que controlar todo o no controlar nada.