37signals n’écrit plus de code à la main : ce que j’en retiens

Dans sa keynote d’ouverture de Rails World 2026, DHH a annoncé que 37signals avait arrêté d’écrire du code à la main. Je développe en Ruby on Rails depuis 2015 et je travaille tous les jours avec des agents (Claude Code, OpenCode). Voici ce que j’en retiens, et ce qui reste à démontrer.

Ce qu’il a dit

Chez 37signals, écrire du code à la main est devenu une exception, traitée comme un bug remonté dans Sentry. Quand l’agent échoue, on corrige à la main une fois, puis on répare « l’usine » qui produit le code. DHH se dit « retraité de la programmation professionnelle » depuis mars environ. Il place le basculement au 24 novembre 2025, avec la sortie d’Opus 4.5, qu’il compare au Kodak Brownie : le moment où une technique réservée à quelques-uns devient accessible à tous.

Ses chiffres personnels : cette année, le Ruby représente environ 3 % de son travail, alors qu’il en occupait plus de la moitié sur 21 ans. Il dit avoir produit 150 000 lignes en août, soit une soixantaine de fois sa moyenne, en reconnaissant que la verbosité du Rust gonfle ce total.

Les choix concrets

HEY passe au natif. Six applications natives remplacent l’application web, écrites par des agents.
Le backend est réécrit en Rust, toujours par des agents, et DHH dit ne jamais lire ce code. Estimation interne : 99 % de CPU et 95 % de mémoire en moins.
Rails reste pour le web, quand on ne peut pas demander d’installer quoi que ce soit, par exemple un invité qui vient récupérer un fichier dans Basecamp. Les conventions de Rails réduisent le nombre de tokens nécessaires, et les évaluations d’agents menées par Evil Martians pour la Rails Foundation ont dû être durcies après avoir atteint environ 95 % de réussite.
Les abstractions perdent du sens. Elles servaient à ne pas se répéter. Si répéter ne coûte presque plus rien, elles peuvent devenir des goulets d’étranglement. DHH reconnaît que personne n’a encore de modèle de remplacement.
« Bring your own agent ». Chaque application devrait fournir une CLI pour que l’agent de l’utilisateur puisse la piloter, plutôt que d’intégrer un chatbot partout.

Le contrepoint

Sur Basecamp 5, des designers ont codé les dernières fonctionnalités avec des agents. Chaque pull request semblait correcte seule, mais au bout de 20 ou 30, l’architecture ressemblait à un gruyère, et l’équipe est revenue à la relecture manuelle. DHH juge aujourd’hui que c’était la mauvaise conclusion, parce que les modèles suivants auraient réglé le problème. Le problème, lui, a bien existé.

Tenderlove lui a répondu en clôture qu’il continuerait à lire son code, et qu’il espérait que les autres feraient de même. Gergely Orosz note de son côté qu’en août 2026, GitHub a reçu plus de pull requests écrites par des agents que par des humains.

Ce que j’en retiens

Les conventions sont un argument vérifiable. L’idée que Rails reste pertinent parce qu’un agent a moins de choix à deviner dans un framework conventionnel est la plus solide à mes yeux, parce qu’elle se teste. Les évaluations d’Evil Martians vont dans ce sens. Les pourcentages viennent de DHH et d’estimations internes, et je ne les ai pas vérifiés.

Lire le code dépend du projet. Sur un projet simple, fait une fois (un script, un petit outil, un site qui ne bouge presque plus), je n’ai pas besoin de lire le code : s’il marche et qu’il est testé, ça me suffit. Sur un projet complexe qui vit depuis des années, avec des règles métier et des données qu’on ne peut pas perdre, quelqu’un doit comprendre le système, et ça passe par lire le code. DHH ne lit pas son backend Rust, mais il le juge comme une boîte noire sur un produit déjà mûr. Plusieurs ingénieurs décrivent le vrai risque de la même façon : le jour où plus personne ne comprend l’architecture ni l’intention derrière, le code généré devient un problème.

Quand l’agent se trompe, on répare ce qui le guide. L’idée la plus utile pour moi est de traiter l’erreur de l’agent comme un défaut de l’usine. Le contexte, c’est bien plus qu’un fichier AGENTS.md : les règles du projet, des skills qui décrivent comment faire une tâche, des tests et des linters qui attrapent l’erreur avant moi, des notes de décisions et d’état pour que l’agent reparte du bon endroit. Quand une erreur se répète, je cherche quelle couche manque, au lieu de corriger à la main et d’oublier.

Je ne sais pas si « retraité de la programmation » restera vrai dans un an, ni si tout le monde peut en faire autant. Ma règle : plus un projet est complexe et ancien, plus je lis son code.

Sources : la keynote d’ouverture de Rails World 2026, The Pragmatic Engineer sur la prise de position de DHH, The state of the tech industry in 2026, Ruby Weekly n° 819. Texte rédigé avec l’aide d’une IA à partir de mes idées, puis relu par moi.