Le virage à 180° de DHH vers le Vibe Coding
DHH fait volte-face : l'IA n'est plus un tabou chez Rails
Quand David Heinemeier Hansson parle, la communauté Ruby on Rails écoute. Alors quand DHH — le créateur de Rails et co-propriétaire de 37signals — a annoncé qu'il avait changé d'avis sur les outils de coding assistés par IA, les ondes se sont propagées bien au-delà de l'écosystème Ruby.
Dans un podcast récent avec Robby Russell, DHH n'a pas simplement reconnu le rôle de l'IA dans le développement moderne. Il a qualifié le fait de prendre l'IA au sérieux d'« obligation professionnelle ». Quand on sait qu'il a bâti Rails sur des principes d'artisanat développeur et de code élégant écrit à la main, cette prise de position ne ressemble pas à un simple compromis. C'est un vrai tournant philosophique.
Le « Vibe Coding » selon 37signals
Vous avez peut-être entendu ce terme de « vibe coding » ces derniers mois. C'est devenu le nom courant pour décrire le travail avec des assistants IA pour générer du code rapidement. Mais l'interprétation de DHH va plus loin que le simple copier-coller de sorties IA.
Chez 37signals, le vibe coding est devenu une expérimentation interne. Designers et product managers travaillent désormais directement dans le code aux côtés des développeurs. Le cycle traditionnel de six semaines chez 37signals — longtemps considéré comme intouchable — est même « en cours de révision ». Il ne s'agit pas de remplacer les développeurs. Il s'agit de démocratiser la création et d'accélérer les itérations.
Le mot d'ordre ? « Git reset and try again. » L'expérimentation ne coûte rien, donc un code généré par IA qui ne convient pas n'est pas un échec. C'est simplement le carburant pour la prochaine tentative.
Basecamp 5 : la théorie en action
Ce virage philosophique n'est pas qu'abstrait. Il est en production. Basecamp 5 vient de sortir, et c'est la première version majeure où ces pratiques de développement augmentées par l'IA ont été pleinement intégrées chez 37signals.
Les résultats disent beaucoup sur ce nouveau type de développement logiciel : des itérations plus rapides, des équipes transversales qui cassent les silos traditionnels, et une envie de laisser l'IA gérer le code répétitif pour que les humains se concentrent sur les vrais problèmes intéressants.
Rails : la stabilité comme force
Ce qui rend ce changement remarquable : Rails lui-même n'a pas eu besoin de se transformer radicalement pour l'accompagner. Le backend du framework reste tellement stable qu'un fichier model de 2026 s'intégrerait sans souci à côté d'un de 2013. Cette stabilité est un vrai atout à l'ère de l'IA. Les conventions sont tellement bien établies que les outils IA peuvent générer du code Rails avec un haut niveau de confiance.
Du côté de la roadmap Rails, on note quelques évolutions intéressantes :
- Lexi : un éditeur basé sur Lexical qui arrivera dans ActionText
- Passkeys natifs : authentification moderne sans mot de passe
- Magic links : connexions transparentes et sécurisées
Ces fonctionnalités montrent que Rails ne se contente pas de s'adapter à l'IA. Le framework continue d'évoluer en misant sur l'expérience développeur et des paramètres par défaut pertinents.
Ce que ça veut dire pour vous
Que vous gériez une startup, une équipe de développement, ou que vous construisiez votre premier projet web, le revirement de DHH porte un message clair : les outils importent moins que les résultats. Écrire chaque ligne de code à la main n'a jamais été le but. C'était toujours construire du bon logiciel qui répond à de vrais besoins.
Les outils IA ne diminuent pas le métier de développeur. Ils changent simplement où ce métier s'applique. Les développeurs et équipes qui prospéreront sont ceux qui adaptent leurs méthodes, expérimentent sans crainte, et n'oublient pas que le code n'est qu'un moyen.
Chez NameOcean, nous voyons cette évolution de près. Nos clients construisent de plus en plus de projets autour de workflows assistés par IA, et les plateformes qu'ils choisissent comptent. La stabilité de Rails combinée à son ouverture aux nouveaux paradigmes de développement en fait un excellent choix pour les équipes prêtes à adopter le vibe coding sans lâcher les bonnes pratiques.
L'avenir de Rails ne se joue pas entre artisanat et rapidité. Il se joue dans la capacité à avoir les deux. Et ça, c'est un vibe qui mérite qu'on code dessus.