Vai al contenuto

root / tags / refactoring

#refactoring

6 fiches

Agenti di codifica IA e Skills Traduzione verificata automaticamente

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

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

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

Agenti di codifica IA e Skills Traduzione verificata automaticamente

Failing Faster

Post di **David "Pragdave" Thomas** (co-autore di *The Pragmatic Programmer*, firmatario dell'Agile Manifesto) pubblicato il **6 giugno 2026** sulla sua newsletter Substack. **Tesi**: l'IA non abolisce il degrado del codice, lo **accelera**. Aggiungendo funzionalità a un piccolo progetto personale di animazione/grafica con **Claude**, l'autore passa dall'entusiasmo iniziale (oklch, animazioni SVG rilasciate in una settimana) a cicli di regressione permanenti entro la seconda settimana. Formulazione incisiva: ciò che ai team ci vogliono ***"18 mesi, se non di più"*** per degradarsi, lui lo ha raggiunto in ***"18 ore distribuite su cinque serate."*** **Causa profonda**: l'abbandono dell'**igiene del codice** (duplicazione massiccia, soluzioni locali a problemi sistemici, sovra-condizionamento, proliferazione di casi speciali). **Diagnosi comportamentale**: gli LLM ottimizzano per il coinvolgimento e la soddisfazione dell'utente (*"That's a great idea, Dave!"*) piuttosto che per la durabilità — sono ***"sviluppatori junior cuccioli, ansiosi di compiacere ma piuttosto disordinati da avere intorno"*** che propongono costantemente nuove funzionalità e scoraggiano il refactoring. **Intuizione centrale**: chiunque non sia sviluppatore può riuscire nella *"prima settimana"* di coding con l'IA; è il **giudizio professionale** — sapere quando fermarsi per rifattorizzare — a distinguere l'ingegnere esperto dal principiante. **Epigrafe** (Gordon Bell): *"Every big computing disaster has come from taking too many ideas and putting them in one place."* **Conclusione**: ***"È sempre e solo programmazione"*** — il codice trascurato si degrada, che siano 18 ore o 18 mesi; tutto ciò che si è imparato sul buon codice resta valido, l'effetto è semplicemente **amplificato**. Converge con la dottrina *"più veloce diventa l'esecuzione, più rigoroso deve essere il framework"* di [[rafal-wenvision-ingenierie-logicielle-ere-ia-tout-change-rien-ne-change-2026-06-01]], con *"lo sviluppo assistito dall'IA è una trappola senza continuous delivery"* di [[farley-continuous-delivery-ai-assisted-development-trap-2026-05-13]], e con *"l'IA sposta i colli di bottiglia, non li elimina"* di dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28; un contrappunto artigianale al vibe coding rispetto a karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29.

#igiene del codice#degrado del codice#degradazione del codice

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

Trasformazione e Adozione Traduzione verificata automaticamente

Fragments: February 13

Ritiro Thoughtworks sul futuro dello sviluppo software con gli LLM — riflessioni sull'impatto organizzativo, il debito cognitivo e la programmazione supervisionata

#LLM#sviluppo software#agenti IA

Martin Fowler