# raymond-llm-coding-empowering-2026-07-08

## Veille

Post X di **Eric S. Raymond** (ESR, autore di *The Cathedral and the Bazaar*, co-fondatore della Open Source Initiative, ~50 anni di programmazione) — **una controtestimonianza frontale alla narrazione secondo cui "gli LLM producono codice pessimo e hanno allucinazioni, inutili per la programmazione".** La sua tesi: questo **non gli accade quasi mai**, e **per nulla più negli ultimi due generazioni** di modelli che usa ("chat GPT 5.4 e 5.5" sotto **codex**). Il sintomo precedente — un modello che "esce dai binari" avvicinandosi al proprio limite di contesto — è scomparso: codex ora mostra un **avviso rosso** che invita l'utente a **svuotare la sessione** invece di degenerare. **Ambito d'uso**: IA applicata a **modifiche di funzionalità, refactoring e debugging su 63 progetti** in **C, Go, Rust, Python e shell**; scrittura di documentazione; **decompilazione di un binario DOS in codice sorgente leggibile**. Una **routine di lavoro** consolidata: quando riapre un progetto, esegue prima i **test di regressione**, poi avvia codex e gli chiede di **verificare il codice** (bug + suggerimenti di miglioramento). Verdetto: gli LLM sono **"eccellenti e straordinariamente responsabilizzanti"**; il loro **limite peggiore** è la **"visione a tunnel architetturale"** — eccellenti nel generare codice a partire da specifiche, ma talvolta **ciechi ai pattern di livello superiore** — cosa che considera il **compito del suo "meatbrain".** Il punto più forte, controintuitivo: gli LLM **NON sbagliano i dettagli e i casi limite**; dichiara di essere **peggiore di loro** su questo fronte (nonostante 50 anni di esperienza), perché se una modifica deve **toccare cinque punti**, il modello **li trova tutti e cinque in modo affidabile**, mentre l'essere umano ne corregge quattro e **passa ore a fare debugging** prima di trovare il quinto dimenticato. Interroga poi i **"downshouters"**: vivono in un **universo diverso**? Usano **modelli vecchi e deboli**? C'è uno **skill issue** che lui non vede perché le sue **abitudini mentali e la sua comunicazione** si adattano bene agli "handle" di questi strumenti? Una questione che considera importante da chiarire, poiché "**miliardi di dollari verrebbero sprecati in una spesa di token mal indirizzata**". La sua ricetta, "molto semplice": **"Sii chiaro nel pensiero, di' al modello ciò che vuoi con precisione, e succedono cose buone"** — chiudendo con: "cosa mi sto perdendo qui?" Da leggere come un **contrappunto pro-LLM da parte di una figura storica dell'open source** al dibattito ricorrente sulla (s)valutazione degli agenti di codifica — facendo eco allo "skill issue" e alla disciplina delle specifiche (cfr. [[martignole-token-manifesto-2026-07-17]]), e formando un dittico con la posizione dottrinale pro-strumenti-IA di **Linus Torvalds** a nome del kernel Linux ([[torvalds-llm-outil-kernel-2026-07-14]]).

## Titre Article

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

## Date

2026-07-08

## URL

https://x.com/esrtweet/status/2074889702381953222

## Keywords

Eric S. Raymond, ESR, esrtweet, The Cathedral and the Bazaar, Open Source Initiative, OSI, open source, Fetchmail, The Art of Unix Programming, Jargon File, LLM, coding agents, codex, OpenAI Codex, ChatGPT 5.4, ChatGPT 5.5, allucinazione, codice pessimo, crap code, skill issue, downshouters, refactoring, debugging, modifiche di funzionalità, test di regressione, verifica del codice, decompilazione, binario DOS, C, Go, Rust, Python, shell, visione a tunnel architetturale, visione a tunnel architetturale, pattern di livello superiore, dettagli e casi limite, casi limite, meatbrain, limite di contesto, limite di contesto, svuotare la sessione, spesa di token, miliardi sprecati, specifica, precisione, responsabilizzazione, empowering, controtestimonianza, adozione dell'IA, sviluppatore esperto

## Authors

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

## Ton

**Profilo**: una testimonianza personale argomentativa in un registro **franco e leggermente polemico**, pubblicata su X da un praticante veterano. Non un resoconto né una dimostrazione quantificata: un'**esperienza vissuta** contrapposta a una **narrazione dominante** (i "downshouters" che denigrano gli LLM), con una **domanda sincera** — "cosa mi sto perdendo?"

**Stile**: diretto, colloquiale ("bitching", "meatbrain", "downshouters"), rivendicando la propria competenza senza falsa modestia ("sono un programmatore molto, molto bravo... ma gli LLM sono migliori di me"). Una retorica dello **stupore** ("sempre più sconcertante", "vivono in un universo diverso?") più che di accusa: ESR non conclude che i suoi oppositori abbiano uno "skill issue", lo **ipotizza** tra altre possibilità (modelli vecchi, un universo diverso) e rivolge la domanda a se stesso. Formulazioni memorabili e una **ricetta minimalista** in chiusura ("Sii chiaro nel pensiero, di' al modello ciò che vuoi con precisione"). La sostanza è **decisamente pro-LLM**, ma sfumata dall'ammissione di un **limite reale** (la "visione a tunnel architetturale"), il che conferisce credibilità al testo.

## Pense-betes

- **La controintuizione centrale: gli LLM eccellono esattamente dove gli umani falliscono — dettagli e casi limite.** L'argomento più forte di ESR, da conservare così com'è: se una modifica deve **toccare cinque punti** nel codice, il modello **li trova tutti e cinque in modo affidabile**, mentre l'essere umano "ne corregge quattro poi passa ore a fare debugging prima di scoprire il quinto". Un ribaltamento del cliché "l'IA ha allucinazioni sui dettagli": per lui, è l'IA a **fornire una copertura esaustiva**, l'essere umano a dimenticare.
- **Il limite vero e onesto: la "visione a tunnel architetturale".** Gli LLM eccellono nel **programmare secondo specifiche** ma sono **talvolta ciechi ai pattern di livello superiore** → la progettazione architetturale resta il **"compito del meatbrain".** Una netta divisione del lavoro: **umano = quota/architettura; modello = esecuzione esaustiva/casi limite.** (Una sfumatura che rende la testimonianza credibile piuttosto che ingenua.)
- **"Non accade quasi mai" — e per nulla nelle ultime 2 generazioni.** Il "codice pessimo / le allucinazioni" che non osserva, in particolare sotto **codex** con "ChatGPT 5.4 e 5.5". Il deragliamento vicino al **limite di contesto** è stato **sostituito da una protezione a livello di prodotto**: un avviso rosso + invito a **svuotare la sessione** invece di lasciare che il modello "esca dai binari". (Lo strumento che disciplina il contesto fa parte della spiegazione.)
- **Ambito d'uso reale (non un giocattolo).** 63 progetti, 5 linguaggi (**C, Go, Rust, Python, shell**), che coprono **modifiche di funzionalità, refactoring, debugging**; **documentazione**; **decompilazione di un binario DOS** in codice sorgente leggibile. Segnale: un uso **ampio e impegnativo** da parte di un esperto, non una demo.
- **La routine ripetibile.** Ogni volta che un progetto viene riaperto: **(1)** eseguire i **test di regressione**, **(2)** avviare codex e chiedergli di **verificare** il codice (bug + miglioramenti). Un pattern applicabile: "prima la batteria di test, poi la verifica LLM".
- **L'ipotesi "skill issue" — sollevata, non affermata.** ESR ribalta la domanda: i detrattori usano **modelli vecchi e deboli**? Vivono in un **universo diverso**? Oppure hanno uno **skill issue** che lui non percepisce perché le sue **abitudini mentali e la sua comunicazione** si adattano bene agli "handle" dello strumento? **Include la propria soggettività** tra le variabili. Ricetta proposta: **chiarezza di pensiero + precisione della richiesta** (da collegare con la disciplina delle specifiche del Token Manifesto, [[martignole-token-manifesto-2026-07-17]]).
- **La cifra in gioco (dichiarata): "miliardi sprecati in una spesa di token mal indirizzata".** ESR lega il dibattito sulla competenza/valore degli LLM a uno **spreco economico** — da qui, a suo avviso, l'importanza di capire perché alcuni falliscono dove lui riesce. Angolo di osservazione: la varianza d'uso (non lo strumento) come fattore di ROI.
- **Uso per tech-watch**: un contenuto di **opinione / testimonianza**, non una misurazione — da trattare come tale (un campione di un praticante estremamente esperto, con un bias di selezione riconosciuto). Il suo valore: un **contrappunto pro-LLM credibile** firmato da una **figura dell'open source**, utile per bilanciare il corpus rispetto alle critiche ("codice pessimo", disillusione) e per la tesi "il valore dipende dalla chiarezza della specifica e dalla maturità degli strumenti, non solo dal modello".

## RésuméDe400mots

**Eric S. Raymond** (ESR) — autore di *The Cathedral and the Bazaar*, co-fondatore della Open Source Initiative, ~50 anni di programmazione — pubblica su X una **controtestimonianza** alla narrazione secondo cui "gli LLM producono codice pessimo, hanno allucinazioni, sono inutili per la programmazione". Una narrazione che trova **"sempre più sconcertante"**, poiché questo **non gli accade quasi mai**.

**L'esperienza.** Da **due generazioni di modelli** ("ChatGPT 5.4 e 5.5" sotto **codex**), non osserva più alcun deragliamento. Il sintomo precedente — un modello che "esce dai binari" vicino al proprio **limite di contesto** — ha lasciato il posto a un **avviso rosso** che lo invita a **svuotare la sessione**. Il suo ambito è ampio: IA applicata a **modifiche di funzionalità, refactoring e debugging su 63 progetti** in **C, Go, Rust, Python e shell**, scrittura di **documentazione**, e persino **decompilazione di un binario DOS** in codice sorgente leggibile. La sua **routine**: ogni volta che riapre un progetto, esegue i **test di regressione**, poi chiede a codex di **verificare** il codice (bug + miglioramenti).

**Il verdetto.** Gli LLM sono **"eccellenti e straordinariamente responsabilizzanti".** Il loro **limite peggiore** è la **"visione a tunnel architetturale"**: eccellenti nel programmare **secondo specifiche**, ma talvolta **ciechi ai pattern di livello superiore** — cosa che, dice, resta il **compito del suo "meatbrain".** Il punto più forte, controintuitivo: gli LLM **non sbagliano i dettagli e i casi limite**. Si dichiara **peggiore di loro** su questo fronte: se una modifica deve **toccare cinque punti** nel codice, il modello **li trova tutti e cinque**, mentre l'essere umano ne corregge quattro e **passa ore a fare debugging** prima di individuare il quinto.

**La domanda.** ESR interroga i **"downshouters"**: vivono in un **universo diverso**? Usano **modelli vecchi e deboli**? Hanno uno **skill issue** che lui non percepisce, perché le sue **abitudini mentali e la sua comunicazione** si adattano bene agli "handle" di questi strumenti? Ritiene la domanda **importante**, poiché "**miliardi di dollari**" verrebbero sprecati in una **spesa di token mal indirizzata**. La sua ricetta, "molto semplice": **"Sii chiaro nel pensiero, di' al modello ciò che vuoi con precisione, e succedono cose buone"** — prima della battuta finale: "cosa... cosa mi sto perdendo qui?"

Da leggere come un **contrappunto pro-LLM credibile**, firmato da una figura storica dell'open source, al dibattito ricorrente sul valore degli agenti di codifica — in risonanza con la disciplina delle specifiche difesa altrove (cfr. Token Manifesto).

## GrapheDeConnaissance

- Eric S. Raymond —a_créé→ The Cathedral and the Bazaar (DOCUMENT, 0.98)
- Eric S. Raymond —a_créé→ Open Source Initiative (ORGANISATION, 0.9)
- Eric S. Raymond —utilise→ Codex (TECHNOLOGIE, 0.95)
- Eric S. Raymond —affirme_que→ les LLMs sont d'excellents outils, formidablement capacitants pour la programmation (AFFIRMATION, 0.9)
- Eric S. Raymond —affirme_que→ le code pourri et les hallucinations ne lui arrivent quasiment jamais, et plus du tout depuis les deux dernières générations de modèles (AFFIRMATION, 0.85)
- Eric S. Raymond —affirme_que→ les LLMs ne se trompent pas sur les détails et les cas limites : ils retrouvent de façon fiable les cinq endroits à modifier là où l'humain en oublie un (AFFIRMATION, 0.85)
- Eric S. Raymond —affirme_que→ la pire limite des LLMs est une vision en tunnel architecturale : bons à coder à la spécification, parfois aveugles aux patterns de haut niveau (AFFIRMATION, 0.85)
- Eric S. Raymond —recommande→ être clair dans sa pensée et dire au modèle ce qu'on veut avec précision (AFFIRMATION, 0.85)
- Eric S. Raymond —utilise→ tests de régression (METHODOLOGIE, 0.9)
- Codex —permet→ auditer le code d'un projet pour détecter des bugs et suggérer des améliorations (AFFIRMATION, 0.85)
- Codex —résout→ le dérapage du modèle à l'approche de la limite de contexte (avertissement + vidage de session) (AFFIRMATION, 0.75)
- Eric S. Raymond —affirme_que→ des milliards de dollars sont gaspillés en token spend mal dirigé (AFFIRMATION, 0.7)
- clarté de la spécification —améliore→ la qualité du code produit par les LLMs (AFFIRMATION, 0.75)
- skill issue —observé_dans→ l'écart entre praticiens satisfaits et détracteurs des LLMs de codage (AFFIRMATION, 0.7)

---
Canonical: https://www.thekb.eu/it/fiches/raymond-llm-coding-empowering-2026-07-08/