DHH : « Je n'ai pas écrit une ligne du code d'Omarchy Quattro »

Les trois âges de l'agentique, en neuf mois

DHH raconte un basculement daté. Treize mois plus tôt, sur le même plateau, il tenait un discours sceptique : l'autocomplete ne l'intéressait pas, le chatbot faisait un bon tuteur, rien de plus. Le 24 novembre 2025, la sortie d'Opus 4.5 change tout. Ce n'est pas tant l'intelligence brute du modèle qui progresse, dit-il, que sa capacité à instrumenter la machine, utiliser des outils et vérifier son propre travail.

Il découpe la suite en phases nettes. Un premier « moment agentique » de trois mois où l'humain reste au volant : il décrit la tâche, corrige la trajectoire, relit tout. Puis l'arrivée des sous-agents au printemps, qui divisent le temps d'exécution par cinq ou dix. Enfin, cet été, avec Opus 5, Fable et Sol, une bascule plus profonde : il n'indique plus la route, il expose le problème et le modèle propose le chemin.

Sa métaphore est celle du GPS. Au début, on surveillait l'appareil de peur qu'il ne nous envoie dans le port ; aujourd'hui, la voiture conduit seule. « Je suis devenu optionnel dans la partie qui produit le code », résume-t-il — au moins dans les domaines où il travaille aujourd'hui.

Omarchy Quattro : un OS comme preuve par le pudding

Face à l'accusation de « psychose IA », DHH répond par un livrable. Omarchy, sa distribution basée sur Arch et le compositeur Wayland Hyprland, existe depuis un peu plus d'un an. La version Quattro, sortie quelques jours avant l'enregistrement, a été développée en trois mois avec une accélération agentique de 100 %.

Il assume une relecture sélective : il a examiné la forme de tout, ligne à ligne ce qui est critique dans la couche modèle, et pas du tout une partie du code UI. Pour l'application d'écriture Omawrite, écrite en C++/Qt alors qu'il ne connaît pas ce langage, il s'est imposé de ne jamais ouvrir le code — une expérience volontairement en boîte noire. Première version en vingt minutes, abandon de Typora en deux jours.

Les chiffres de participation impressionnent davantage que les lignes de code : plus de 1 000 pull requests mergées en trois mois, environ 400 en attente, et 330 plugins publiés sur la marketplace en trois jours. Beaucoup viennent de gens qui ne sont pas développeurs système. DHH ne relit plus les PR lui-même : des agents trient, valident les correctifs dans une VM, et ne lui remontent que la décision finale.

Là où ça coince : les grandes bases de code et les humains

L'entretien n'est pas qu'un panégyrique. DHH raconte l'échec de février chez 37signals : pour la dernière ligne droite de Basecamp 5, l'équipe a laissé les designers coder avec des agents. Résultat, une avalanche de PR individuellement défendables qui, mises bout à bout, ont détruit l'architecture du système. Il a fallu nettoyer manuellement.

Sa leçon : sur une base de code existante et substantielle, il faut rester programmeur pour préserver l'architecture. Il nuance aussitôt en renvoyant la critique du « slop » aux humains : après 3 000 développeurs, les bases de code des grandes boîtes sont « absolument affreuses ».

Sur la question « pourquoi Photoshop ou Premiere ne progressent-ils pas dix fois plus vite ? », sa réponse est organisationnelle. Le goulet d'étranglement n'a jamais été l'implémentation mais la bande passante humaine : product managers, designers, VP, CTO qui veulent tous participer au cadrage. Pour obtenir le facteur 10x ou 100x, dit-il, il faut interagir directement avec les agents, sans intermédiaire humain.

Il ajoute une critique plus dure : la plupart des organisations ne savent pas ce qu'elles veulent. Elles ne sont pas limitées par leur capacité à produire du code, mais par leurs idées, leur vision et leur goût. « On peut faire advenir beaucoup de mauvaises idées, et après ? »

Le setup : 16 threads, Herdr, Tailscale et un banc d'essai des modèles

Le passage le plus opérationnel de l'épisode décrit un poste de travail entièrement repensé. On passe du mono-thread mental au parallélisme : plusieurs agents, donc plusieurs panneaux. Il a commencé avec tmux, puis est passé à Herdr, qui ajoute les notifications quand un agent attend une décision. Neovim ne sert plus qu'à naviguer et relire les diffs.

Constatant qu'une seule machine ne suffisait plus, il a ressorti quatre mini-PC d'un placard, les a reliés avec des KVM GL.iNet Comet et un réseau Tailscale. Il estime son plafond personnel à environ 16 threads d'agents simultanés — au-delà, c'est l'humain qui sature.

Le benchmark maison est éloquent : réécrire en Rust, sans dépendance, la librairie Python Terminal Text Effects utilisée par son économiseur d'écran. Fable produit un plan détaillé et finit en moins de 45 minutes (démarrage passé de 86 ms à 2 ms, exécution 9,6× plus rapide), pour environ 550 $ de tokens s'il avait payé à l'usage. Sol refait le travail en 1h30 pour 46 $, Grok 4.6 pour 55 $, DeepSeek V4 Pro en 2h45 pour 23 $. GPT Luna échoue et tente même de tricher. Deux boucles d'auto-recherche plus tard, le gain atteint 46×.

Sa procédure standard : faire travailler Claude ou Fable, puis faire relire systématiquement par Codex xHigh, et laisser Copilot repasser sur GitHub. « Même bon programmeur, si un pair relit votre travail, le code sera meilleur. Intégrez ça à votre process. »

Deuil du code artisanal et conseils aux développeurs

DHH reconnaît être surpris de ne pas être plus nostalgique. Son argument économique : on écrivait du code beau parce qu'une architecture cohérente rendait les modifications humaines moins coûteuses. Cette prémisse s'effrite. Il nuance toutefois : tant que les tokens sont une ressource rare, un code lisible reste payant, car les agents itèrent moins cher dessus.

À ceux qui paniquent, il donne un conseil simple : n'essayez pas d'anticiper. Personne ne sait à quoi ressembleront deux générations de modèles plus loin, et tenter de le deviner est le chemin le plus court vers l'angoisse. Il ajoute un argument rassurant : il n'y a quasiment pas d'accumulation dans ce domaine. Quelqu'un parti un an en randonnée rattraperait la frontière en deux semaines.

Il distingue deux profils de développeurs : ceux qui aimaient l'assemblage mécanique de constructions logiques, qui sont menacés, et ceux qui aimaient fabriquer des choses, qui ne le sont pas. Lui-même se décrit comme revenu à son point de départ : il est devenu programmeur parce qu'il voulait des programmes, pas par amour des instructions conditionnelles.

Il refuse en revanche d'appeler « programmation » le vibe coding. Programmer implique de comprendre les primitives : boucles, conditions, variables. Et il glisse un paradoxe : sa longue expérience a pu être un handicap, parce qu'il prescrivait aux agents la manière de faire au lieu de décrire des résultats.

Linux, l'ironie de l'histoire, et le reste

La thèse la plus forte de l'épisode : Linux va gagner le desktop, non malgré ses défauts mais grâce à eux. Tout y est fichier de configuration ou outil en ligne de commande, ce qui en fait le terrain idéal pour des agents. Les messages d'erreur ésotériques, autrefois repoussoirs, deviennent exploitables par un modèle pré-entraîné sur 40 millions de lignes de code kernel. Omarchy Quattro embarque d'ailleurs un « crash watcher » qui propose de faire diagnostiquer tout plantage par l'agent.

L'obsession de la vitesse d'installation illustre sa méthode. Objectif initial de 15 minutes, puis 2, puis 1 ; record actuel de 45 secondes, avec une image spécifique au Dell XPS visée à 12 secondes. Les gains viennent de préchargements pendant que l'utilisateur répond aux questions, et de réductions de taille chirurgicales : 180 Mo économisés sur la police JetBrains, 200 Mo sur les pilotes NVIDIA. Sa référence assumée : les ingénieurs de McLaren qui traquent 370 grammes sur une voiture d'une tonne.

La conversation dérive ensuite largement hors tech : génération vidéo par IA, paternité, X et les algorithmes d'engagement, son immersion dans le débat sur l'immigration de masse en Europe, sa position anti-longévité — il vise 90 à 100 ans et a caché un memento mori dans le calendrier d'Omarchy, qui affiche le pourcentage de vie écoulé.