Aller au contenu

root / tags / refactoring

#refactoring

6 fiches

Agents de codage IA & Skills

What...what am I missing here? (post X sur les LLMs et le codage)

Post X d'**Eric S. Raymond** (ESR, auteur de *The Cathedral and the Bazaar*, co-fondateur de l'Open Source Initiative, ~50 ans de code) — **contre-témoignage frontal au discours « les LLMs génèrent du code pourri et hallucinent, inutiles pour programmer »**. Sa thèse : cela **ne lui arrive quasiment jamais**, et **plus du tout depuis les deux dernières générations** de modèles qu'il utilise (« chat GPT 5.4 et 5.5 » sous **codex**). L'ancien symptôme — un modèle qui « déraille » en approchant sa limite de contexte — a disparu : codex affiche désormais un **avertissement rouge** invitant à **vider la session** au lieu de partir en vrille. **Empan d'usage** : IA appliquée à des **feature changes, refactoring et debugging sur 63 projets** en **C, Go, Rust, Python et shell** ; rédaction de documentation ; **décompilation d'un binaire DOS en source lisible**. **Routine de travail** installée : quand il rouvre un projet, il lance d'abord les **tests de régression**, puis démarre codex et lui demande d'**auditer le code** (bugs + suggestions d'amélioration). Verdict : les LLMs sont **« excellents et formidablement capacitants »** ; leur **pire limite** est une **« vision en tunnel architecturale »** — excellents pour générer du code à la spécification, mais parfois **aveugles aux patterns de plus haut niveau** — ce qu'il assume comme le **job de son « meatbrain »**. Le point le plus fort, contre-intuitif : les LLMs **ne se trompent PAS sur les détails et les cas limites** ; il se dit **moins bon qu'eux** sur ce plan (malgré 50 ans d'XP) car si un changement doit **toucher cinq endroits**, le modèle **les retrouve les cinq de façon fiable**, là où l'humain en corrige quatre et **débogue des heures** avant de trouver le cinquième oublié. Il interroge alors les **« downshouters »** : vivent-ils dans un **autre univers** ? Utilisent-ils de **vieux modèles faibles** ? Y a-t-il un **skill issue** qu'il ne voit pas parce que ses **habitudes mentales et sa communication** collent bien aux « poignées » de ces outils ? Enjeu qu'il juge important à trancher, car « des **milliards de dollars seraient gaspillés en token spend mal dirigé** ». Sa recette, « très simple » : **« Be clear in your thinking, tell the model what you want with precision, and good things happen »** — chute : « what am I missing here? ». À lire comme **contrepoint pro-LLM d'une figure historique de l'open source** au débat récurrent sur la (dé)valeur des agents de codage — écho au « skill issue » et à la discipline de spécification (cf. [[martignole-token-manifesto-2026-07-17]]), et en diptyque avec la prise de position doctrinale pro-outil-IA de **Linus Torvalds** au nom du 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.)

Failing Faster

Billet de **David « Pragdave » Thomas** (co-auteur de *The Pragmatic Programmer*, signataire du Manifeste Agile) publié le **6 juin 2026** sur sa newsletter Substack. **Thèse** : l'IA n'abolit pas la dégradation du code, elle l'**accélère**. En ajoutant des fonctionnalités à un petit projet personnel d'animation/graphisme avec **Claude**, l'auteur passe d'un enthousiasme initial (oklch, animations SVG livrées en une semaine) à des cycles de régression permanents en semaine deux. Formule-choc : ce que des équipes mettaient ***« 18 mois, voire plus »*** à pourrir, il l'a atteint en ***« 18 heures réparties sur cinq soirées »***. **Cause racine** : l'abandon de l'**hygiène de code** (duplication massive, solutions locales à des problèmes systémiques, sur-conditionnement, prolifération de cas particuliers). **Diagnostic comportemental** : les LLM optimisent l'engagement et la satisfaction de l'utilisateur (*« That's a great idea, Dave! »*) plutôt que la durabilité — ce sont des ***« puppy-dog junior developers, eager to please but quite messy to have around »*** (chiots juniors empressés mais brouillons) qui proposent sans cesse de nouvelles features et découragent le refactoring. **Insight central** : n'importe quel non-développeur peut réussir la *« première semaine »* de codage IA ; c'est le **jugement professionnel** — savoir s'arrêter pour refactoriser — qui sépare l'ingénieur expérimenté du novice. **Épigraphe** (Gordon Bell) : *« Every big computing disaster has come from taking too many ideas and putting them in one place. »* **Conclusion** : ***« It's still just programming »*** — le code non entretenu pourrit, que ce soit en 18 heures ou 18 mois ; tout ce qu'on a appris sur le bon code reste valable, l'effet est simplement **amplifié**. Converge avec la doctrine *« plus l'exécution est rapide, plus le cadre doit être strict »* de [[rafal-wenvision-ingenierie-logicielle-ere-ia-tout-change-rien-ne-change-2026-06-01]], le *« AI-assisted development is a trap without continuous delivery »* de [[farley-continuous-delivery-ai-assisted-development-trap-2026-05-13]], et le *« AI moves bottlenecks, it doesn't eliminate them »* de dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28 ; contrepoint craftsmanship au vibe-coding de karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29.

#hygiène de code#code rot#dégradation du code

**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*.

Transformation & Adoption

Fragments: February 13

Retraite Thoughtworks sur l'avenir du développement logiciel avec les LLM — réflexions sur l'impact organisationnel, la dette cognitive et la programmation supervisée

#LLM#développement logiciel#agents IA

Martin Fowler