Lunga intervista (**25 minuti di lettura**) a **David Heinemeier Hansson**, creatore di **Ruby on Rails** e co-proprietario di **37signals**, condotta da **Vikas Shah** su *Thought Economics*, pubblicata il **28 settembre 2026**, cinque giorni dopo il keynote di apertura di **Rails World** ad Austin in cui ha annunciato che 37signals passava al *"pencils down"* sul codice scritto a mano. **(A)** La svolta, datata: nell'estate 2025 dichiarava a **Lex Fridman** che non avrebbe lasciato scrivere il proprio codice all'IA; ciò che gli ha fatto cambiare idea è stato l'arrivo degli agenti di coding a fine 2025, e *"il cambiamento è diventato davvero verticale, a mio parere, negli ultimi tre o quattro mesi"*. **(B)** L'argomento di fondo non è tecnico ma politico: i programmatori erano diventati *"una classe clericale"* che mediava l'accesso alla macchina, e l'agente gioca il ruolo di Lutero — *"Agent Luther"* — eliminando l'intermediario. Ne trae una conseguenza per sé stesso: le sue competenze di coding non sono più *"economicamente valide come leva indipendente"*. **(C)** La selezione dei modelli di business: il client-side è *"già sparito"* (Adobe), il client-server resiste ancora perché *"le persone non hanno alcun desiderio di gestire i propri server"*, i moat di plumbing resistono (Shopify, *"sistemi di pagamento, spedizione e fiscalità"*), e **Salesforce** e **SAP** sono *"in seri guai"* poiché *"non c'è più valore nel codice, solo nelle intuizioni di processo"*. **(D)** **Omarchy**, la sua distribuzione Linux con agenti integrati: la versione **Quattro** scritta esclusivamente da agenti, **200.000 download in 18 giorni**, **4.000 plugin** in quattro settimane, **21,7 milioni di dollari** in promesse di donazione. **(E)** La chiusura prospettica: AGI raggiunta, *"sacche di ASI"*, robot, e *"cosa fai quando non hai più niente da fare?"*. Da leggere in rapporto a [[lecun-still-far-from-human-level-ai-llm-2026-09-25]] dello stesso mese.
#fine del codice scritto a mano#pencils down#agenti di coding
David Heinemeier Hansson · créateur de Ruby on Rails et copropriétaire de 37signals · interrogé par Vikas Shah dans *Thought Economics*.
Lo sviluppo software come mestiere, trasparenza e fiducia, open-source autentico, impatto dell'IA sulle competenze fondamentali - Gilles Chehade - Plakar - OpenSMTPD
#sviluppo software#artigianato del software#open-source
**Mathieu Eveillard** pubblica sul suo blog personale il **7 dicembre 2022** (ultimo aggiornamento 17 marzo 2025) una **controargomentazione punto per punto** al celebre saggio di **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Articolo classificato **craft / best-of**, una posizione da **artigiano del software** che difende il **Test-Driven Development** senza dogmatismo. **Distinzione cruciale** che secondo Eveillard sfugge a DHH: ***"Test-first"*** (scrivere tutti i test prima di qualsiasi codice) vs ***"Test-Driven Development"*** (i test mi **guidano** nella scrittura del codice, per cui ogni volta scrivo un po' di codice *"in reazione"* a un nuovo test). DHH in realtà critica il *Test-first* chiamandolo TDD — una confusione che **nasconde un modo di programmare completamente diverso**. **Risposte punto per punto**: (1) *"TDD come martello per abbattere i non credenti"* — Eveillard concede il punto deontologico ma ridefinisce il *"buon codice"*: non solo l'assenza di bug ma **unit test a grana fine** che documentano il comportamento al livello più basso, collocati insieme al codice, una **rete di sicurezza**; (2) *"Riequilibrare dallo unit al system"* — il TDD **non dice nulla** sui test di sistema e **non afferma** che non esista nulla al di fuori del TDD; i test di sistema **non sostituiscono** gli unit test (una dichiarazione dei redditi testata end-to-end non ha senso); **piramide dei test** — ogni tipo contribuisce con la propria parte, gli unit test per un feedback in **millisecondi** + individuazione precoce dei bug; (3) *"Mostruosità architetturali orrende (service object, command pattern)"* — Eveillard risponde di **non riscontrare questi effetti nella programmazione funzionale**, quindi l'effetto è probabilmente dovuto all'**OOP**, non al TDD; ma concede che un'iniezione di dipendenze eccessiva può accoppiare test e implementazione. **Conclusione equilibrata**: *"Il TDD non è una religione, è uno strumento"*. Il TDD è particolarmente adatto al **codice di dominio** (il nucleo funzionale di un *bounded context*, il *cuore dell'esagono*) — motori di calcolo, regole di business a grana fine, casi limite ovunque — ***"al massimo il 30% della codebase"***. Cita la **Legge dello Strumento** (se lo strumento non aiuta, è perché ci si è caduti dentro). **Rilevanza per il corpus**: un **articolo di craft esterno al corpus IA** ma da archiviare per collocare gli attuali dibattiti sugli agenti di codifica (l'*Augmented Coding Beyond Vibes* di Beck, 2025-06-25, Vibe Coding vs TDD, l'*atrofia del muscolo della scrittura* di Frizzo) nella linea storica dei dibattiti craft sul TDD. Da utilizzare come **base di libreria** per sessioni di formazione.
#Mathieu Eveillard#TDD#Test-Driven Development
**Mathieu Eveillard** — développeur / coach craft / formateur (blog personnel mathieueveillard.com, services *Accompagnement* et *Office hours*). Identité publique : *artisan logiciel* avec une pratique pédagogique autour du TDD · du DDD et du craft. Newsletter hebdomadaire (*"Chaque mercredi, une idée pour démarrer la journée"*).