Post en X de **Eric S. Raymond** (ESR, autor de *The Cathedral and the Bazaar*, cofundador de la Open Source Initiative, ~50 años de programación) — **un contratestimonio frontal a la narrativa de que "los LLM producen código basura y alucinan, inútiles para programar".** Su tesis: esto **casi nunca le ocurre**, y **ya no en absoluto en las últimas dos generaciones** de modelos que usa ("chat GPT 5.4 y 5.5" bajo **codex**). El antiguo síntoma —un modelo "descarrilando" al acercarse a su límite de contexto— ha desaparecido: codex ahora muestra una **advertencia roja** que invita al usuario a **limpiar la sesión** en lugar de descontrolarse. **Alcance de uso**: IA aplicada a **cambios de funcionalidades, refactorización y depuración en 63 proyectos** en **C, Go, Rust, Python y shell**; redacción de documentación; **descompilación de un binario DOS en código fuente legible**. Una **rutina de trabajo** establecida: al reabrir un proyecto, primero ejecuta las **pruebas de regresión**, luego inicia codex y le pide que **audite el código** (errores + sugerencias de mejora). Veredicto: los LLM son **"excelentes y tremendamente empoderadores"**; su **peor limitación** es la **"visión de túnel arquitectónica"** —excelentes generando código según especificación, pero a veces **ciegos a los patrones de más alto nivel**— algo que considera **tarea de su "cerebro de carne".** El punto más fuerte y contraintuitivo: los LLM **NO se equivocan en los detalles y casos límite**; afirma ser **peor que ellos** en este aspecto (pese a 50 años de experiencia), porque si un cambio debe **tocar cinco lugares**, el modelo **los encuentra los cinco de forma fiable**, mientras que el humano corrige cuatro y **pasa horas depurando** antes de encontrar el quinto olvidado. Después cuestiona a los **"downshouters"**: ¿viven en un **universo diferente**? ¿Usan **modelos antiguos y débiles**? ¿Hay un **skill issue** que él no percibe porque sus **hábitos mentales y su comunicación** encajan bien con los "handles" de estas herramientas? Una cuestión que considera importante resolver, ya que "se **malgastarían miles de millones de dólares en gasto de tokens mal dirigido**". Su receta, "muy simple": **"Piensa con claridad, dile al modelo lo que quieres con precisión, y ocurren cosas buenas"** —cerrando con: "¿qué me estoy perdiendo aquí?". Debe leerse como un **contrapunto pro-LLM de una figura histórica del open source** al debate recurrente sobre la (des)valorización de los agentes de codificación —haciendo eco del "skill issue" y de la disciplina de especificación (cf. [[martignole-token-manifesto-2026-07-17]])— y formando un díptico con la postura doctrinal pro-herramientas-IA de **Linus Torvalds** en nombre del kernel Linux ([[torvalds-llm-outil-kernel-2026-07-14]]).
#Eric S. Raymond#ESR#esrtweet
Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)
Publicación de **David «Pragdave» Thomas** (coautor de *The Pragmatic Programmer*, signatario del Manifiesto Ágil) publicada el **6 de junio de 2026** en su boletín de Substack. **Tesis**: la IA no elimina la degradación del código, la **acelera**. Al añadir funcionalidades a un pequeño proyecto personal de animación/gráficos con **Claude**, el autor pasa de un entusiasmo inicial (oklch, animaciones SVG entregadas en una semana) a ciclos de regresión permanentes a partir de la segunda semana. Formulación contundente: lo que a los equipos les tomaba ***"18 meses, o incluso más"*** en degradarse, él lo alcanzó en ***"18 horas repartidas en cinco tardes."*** **Causa raíz**: el abandono de la **higiene del código** (duplicación masiva, soluciones locales a problemas sistémicos, sobrecondicionamiento, proliferación de casos especiales). **Diagnóstico conductual**: los LLM optimizan el compromiso y la satisfacción del usuario (*"¡Es una gran idea, Dave!"*) en lugar de la durabilidad — son ***"desarrolladores junior cachorros, ansiosos por complacer pero bastante desordenados de tener cerca"*** que proponen constantemente nuevas funcionalidades y desalientan la refactorización. **Idea central**: cualquier no desarrollador puede tener éxito en la *"primera semana"* de programación asistida por IA; es el **juicio profesional** — saber cuándo detenerse para refactorizar — lo que separa al ingeniero experimentado del novato. **Epígrafe** (Gordon Bell): *"Todo gran desastre informático ha surgido de tomar demasiadas ideas y ponerlas en un mismo lugar."* **Conclusión**: ***"Sigue siendo solo programación"*** — el código descuidado se degrada, ya sea en 18 horas o en 18 meses; todo lo aprendido sobre el buen código sigue siendo válido, el efecto simplemente se **amplifica**. Converge con la doctrina de *"cuanto más rápida es la ejecución, más estricto debe ser el marco"* de [[rafal-wenvision-ingenierie-logicielle-ere-ia-tout-change-rien-ne-change-2026-06-01]], con *"el desarrollo asistido por IA es una trampa sin entrega continua"* de [[farley-continuous-delivery-ai-assisted-development-trap-2026-05-13]], y con *"la IA desplaza los cuellos de botella, no los elimina"* de dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28; un contrapunto artesanal al vibe coding frente a karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29.
#higiene del código#descomposición del código#degradación del código
**David Thomas** (alias **« Pragdave »**) · co-auteur avec Andy Hunt de *The Pragmatic Programmer* (1999, éd. 20e anniversaire 2019) · co-fondateur de **The Pragmatic Bookshelf** et l'un des **17 signataires du Manifeste Agile** (2001). Figure historique du *software craftsmanship*. Billet publié le **6 juin 2026** sur sa newsletter Substack *articles.pragdave.me*.
Retiro de Thoughtworks sobre el futuro del desarrollo de software con LLM — reflexiones sobre el impacto organizacional, la deuda cognitiva y la programación supervisada