DHH: «Non ho scritto una sola riga di codice di Omarchy Quattro»

Le tre ere dell'agentic, in nove mesi

DHH racconta un cambiamento datato. Tredici mesi prima, sullo stesso palco, teneva un discorso scettico: l'autocomplete non lo interessava, il chatbot faceva da buon tutor, nient'altro. Il 24 novembre 2025, l'uscita di Opus 4.5 cambia tutto. Non è tanto l'intelligenza grezza del modello a progredire, dice, quanto la sua capacità di strumentare la macchina, usare strumenti e verificare il proprio lavoro.

Divide il seguito in fasi nette. Un primo «momento agentico» di tre mesi in cui l'umano resta al volante: descrive il compito, corregge la traiettoria, rilegge tutto. Poi l'arrivo dei sub-agenti in primavera, che dividono il tempo di esecuzione per cinque o dieci. Infine, quest'estate, con Opus 5, Fable e Sol, una svolta più profonda: non indica più la strada, espone il problema e il modello propone il percorso.

La sua metafora è quella del GPS. All'inizio, si sorvegliava il dispositivo per paura che ci mandasse in un porto; oggi, l'auto guida da sola. «Sono diventato opzionale nella parte che produce il codice», riassume — almeno negli ambiti in cui lavora oggi.

Omarchy Quattro: un OS come prova del budino

Di fronte all'accusa di «psicosi da IA», DHH risponde con un prodotto concreto. Omarchy, la sua distribuzione basata su Arch e sul compositore Wayland Hyprland, esiste da poco più di un anno. La versione Quattro, uscita pochi giorni prima della registrazione, è stata sviluppata in tre mesi con un'accelerazione agentic del 100%.

Ammette una revisione selettiva: ha esaminato la forma di tutto, riga per riga ciò che è critico nello strato modello, e per nulla una parte del codice UI. Per l'app di scrittura Omawrite, scritta in C++/Qt mentre lui non conosce questo linguaggio, si è imposto di non aprire mai il codice — un'esperienza volontariamente a scatola nera. Prima versione in venti minuti, abbandono di Typora in due giorni.

I numeri di partecipazione impressionano più delle righe di codice: oltre 1.000 pull request mergiate in tre mesi, circa 400 in attesa, e 330 plugin pubblicati sul marketplace in tre giorni. Molti vengono da persone che non sono sviluppatori di sistema. DHH non rilegge più le PR lui stesso: agenti smistano, validano le correzioni in una VM, e gli riportano solo la decisione finale.

Dove si blocca: le grandi codebase e gli umani

L'intervista non è solo un panegirico. DHH racconta il fallimento di febbraio da 37signals: per l'ultimo tratto di Basecamp 5, il team ha lasciato che i designer programmassero con agenti. Risultato, una valanga di PR individualmente difendibili che, messe insieme, hanno distrutto l'architettura del sistema. È stato necessario ripulire manualmente.

La sua lezione: su una codebase esistente e sostanziale, bisogna restare programmatori per preservare l'architettura. Sfuma subito rinviando la critica dello «slop» agli umani: dopo 3.000 sviluppatori, le codebase delle grandi aziende sono «assolutamente orribili».

Sulla domanda «perché Photoshop o Premiere non progrediscono dieci volte più veloce?», la sua risposta è organizzativa. Il collo di bottiglia non è mai stata l'implementazione ma la banda passante umana: product manager, designer, VP, CTO che vogliono tutti partecipare all'inquadramento. Per ottenere il fattore 10x o 100x, dice, bisogna interagire direttamente con gli agenti, senza intermediario umano.

Aggiunge una critica più dura: la maggior parte delle organizzazioni non sa cosa vuole. Non sono limitate dalla loro capacità di produrre codice, ma dalle loro idee, dalla loro visione e dal loro gusto. «Si possono far emergere molte cattive idee, e poi?»

Il setup: 16 thread, Herdr, Tailscale e un benchmark dei modelli

Il passaggio più operativo dell'episodio descrive una postazione di lavoro interamente ripensata. Si passa dal mono-thread mentale al parallelismo: più agenti, quindi più pannelli. Ha iniziato con tmux, poi è passato a Herdr, che aggiunge le notifiche quando un agente attende una decisione. Neovim serve ormai solo a navigare e rileggere i diff.

Constatando che una sola macchina non bastava più, ha tirato fuori quattro mini-PC da un armadio, li ha collegati con KVM GL.iNet Comet e una rete Tailscale. Stima il suo limite personale a circa 16 thread di agenti simultanei — oltre, è l'umano a saturare.

Il benchmark casalingo è eloquente: riscrivere in Rust, senza dipendenze, la libreria Python Terminal Text Effects usata dal suo screensaver. Fable produce un piano dettagliato e finisce in meno di 45 minuti (avvio passato da 86 ms a 2 ms, esecuzione 9,6× più veloce), per circa 550$ di token se avesse pagato a consumo. Sol rifà il lavoro in 1h30 per 46$, Grok 4.6 per 55$, DeepSeek V4 Pro in 2h45 per 23$. GPT Luna fallisce e tenta persino di imbrogliare. Due cicli di auto-ricerca dopo, il guadagno raggiunge 46×.

La sua procedura standard: far lavorare Claude o Fable, poi far rileggere sistematicamente da Codex xHigh, e lasciare che Copilot ripassi su GitHub. «Anche un buon programmatore, se un pari rilegge il suo lavoro, il codice sarà migliore. Integratelo nel vostro processo.»

Lutto del codice artigianale e consigli agli sviluppatori

DHH riconosce di essere sorpreso di non essere più nostalgico. Il suo argomento economico: si scriveva codice bello perché un'architettura coerente rendeva le modifiche umane meno costose. Questa premessa si sgretola. Sfuma però: finché i token sono una risorsa scarsa, un codice leggibile resta vantaggioso, perché gli agenti iterano meno costosamente su di esso.

A chi si preoccupa, dà un consiglio semplice: non cercate di anticipare. Nessuno sa come saranno due generazioni di modelli più avanti, e tentare di indovinarlo è la via più breve verso l'angoscia. Aggiunge un argomento rassicurante: non c'è quasi alcun accumulo in questo campo. Chi fosse partito per un anno in escursione recupererebbe la frontiera in due settimane.

Distingue due profili di sviluppatori: quelli a cui piaceva l'assemblaggio meccanico di costruzioni logiche, che sono minacciati, e quelli a cui piaceva fabbricare cose, che non lo sono. Lui stesso si descrive come tornato al suo punto di partenza: è diventato programmatore perché voleva dei programmi, non per amore delle istruzioni condizionali.

Rifiuta invece di chiamare «programmazione» il vibe coding. Programmare implica capire le primitive: cicli, condizioni, variabili. E fa notare un paradosso: la sua lunga esperienza può essere stata un handicap, perché prescriveva agli agenti il modo di fare invece di descrivere i risultati.

Linux, l'ironia della storia, e il resto

La tesi più forte dell'episodio: Linux vincerà sul desktop, non nonostante i suoi difetti ma grazie ad essi. Tutto è file di configurazione o strumento a riga di comando, il che ne fa il terreno ideale per gli agenti. I messaggi d'errore esoterici, un tempo repellenti, diventano sfruttabili da un modello pre-addestrato su 40 milioni di righe di codice del kernel. Omarchy Quattro integra peraltro un «crash watcher» che propone di far diagnosticare ogni crash dall'agente.

L'ossessione per la velocità d'installazione illustra il suo metodo. Obiettivo iniziale di 15 minuti, poi 2, poi 1; record attuale di 45 secondi, con un'immagine specifica per il Dell XPS puntata a 12 secondi. I guadagni vengono da precaricamenti mentre l'utente risponde alle domande, e da riduzioni di dimensione chirurgiche: 180 MB risparmiati sul font JetBrains, 200 MB sui driver NVIDIA. Il suo riferimento dichiarato: gli ingegneri della McLaren che inseguono 370 grammi su un'auto da una tonnellata.

La conversazione devia poi ampiamente fuori dalla tecnologia: generazione video tramite IA, paternità, X e gli algoritmi di engagement, la sua immersione nel dibattito sull'immigrazione di massa in Europa, la sua posizione anti-longevità — punta a 90-100 anni e ha nascosto un memento mori nel calendario di Omarchy, che mostra la percentuale di vita trascorsa.