Pourquoi Rails est devenu, par accident, le framework parfait pour l'IA

L’autre soir, j’ai demandé à Claude Code d’ajouter un champ au modèle Politician de touslesmemes.fr, un quiz politique que je construis seul depuis quelques mois. La machine a touché le modèle, créé la migration, mis à jour les vues admin, corrigé les tests. Sans que je lui explique où était quoi. Sans que je lui dessine l’architecture.

Je me suis levé pour me faire un café.

En revenant, le diff était propre. Et je me suis demandé si j’avais encore codé quoi que ce soit ce soir-là, ou si j’avais simplement supervisé.

Ce qui s’est passé, techniquement, c’est que la machine connaissait le sentier. app/models/, app/controllers/, app/views/, db/schema.rb. Tous les projets Rails du monde sont organisés pareil. Un projet de 2015 et un de 2026 se ressemblent. La machine a vu des milliers de codebases Rails dans son training data, et elles suivent toutes les mêmes conventions.

C’est la force du Convention over Configuration. Le LLM n’a pas besoin d’apprendre l’architecture de ton projet. Il la connaît déjà.

Et il y a schema.rb. Un seul fichier, auto-généré, qui décrit toutes les tables, colonnes et index. La machine le lit et comprend 100% du modèle de données. Là où d’autres stacks éparpillent la vérité sur la structure dans une galaxie de fichiers d’interfaces, Rails centralise tout dans un sentier unique.

Simon Willison a proposé le terme vibe engineering pour distinguer l’usage professionnel de ces outils du vibe coding :

Amplify existing expertise. Les conventions de Rails sont justement une forme d’expertise collective déjà encodée. Des milliers de développeur·ices qui ont convergé, sur des années, par friction et consensus, vers les mêmes chemins. La machine amplifie ça. Elle amplifie le fait que tout le monde a rangé ses modèles au même endroit.

Ruby a été pensé pour coller au langage naturel. Matz voulait un langage pour les humains d’abord. Résultat, le code se lit presque comme de la prose :

class Politician < ApplicationRecord
  has_many :quotes, dependent: :destroy

  enum :status, { draft: 0, published: 1 }, default: :draft
  enum :ideology, { far_left: 0, left: 1, center: 2, right: 3, far_right: 4 }

  validates :name, presence: true
  validates :slug, presence: true, uniqueness: true
end

has_many :quotes. validates :name, presence: true. C’est déclaratif. C’est dense. La machine génère ça correctement du premier coup 9 fois sur 10. Elle a vu des millions d’exemples identiques, et il y a peu d’espace pour halluciner quand la syntaxe ne laisse pas de place au doute.

Moins de tokens pour décrire la même logique, c’est moins de risques que la machine perde le fil. Plus de signal, moins de bruit. Un ratio qui compte quand la fenêtre de contexte est ta ressource la plus précieuse.

(Et mon fichier CLAUDE.md ? Il ne documente que la logique métier. Pas l’architecture. Rails l’a déjà fait.)

Avec Hotwire (Turbo + Stimulus), toute l’interactivité tient côté serveur. Le serveur renvoie un fragment HTML qui remplace un bout de page. Pas de JSON, de sérialisation, de state management côté client. La machine ne fait pas d’erreurs de state. Parce qu’il n’y en a pas.

C’est de la cuisine maison. Un plat, une assiette, pas de chaîne d’intermédiation. Rails 8 avec Propshaft et Importmap bypasse complètement Node.js. Cinq lignes de config pour tout le JavaScript. Moins il y a de config, moins il y a de casse.

Coder 80% d’un projet avec un LLM. Le One-Person Framework tient sa promesse : une seule personne qui gère front, back, base de données, infra. Du VibeArtisanat, en quelque sorte. Ça marche. Ça ship. Mais qu’est-ce que je maîtrise encore, en tant qu’artisan·e, exactement ?

Charity Majors :

Et plus loin :

La machine écrit le code. Mais qui maintient ? Qui comprend le pourquoi derrière le comment ? Mon CLAUDE.md sert de cerveau externalisé entre les sessions, mais c’est un cerveau qui ne retient que ce qu’on lui dit de retenir.

Je remarque que je lis les diffs de moins en moins attentivement. Que j’accepte des implémentations dont je comprends l’intention mais pas toujours le détail. Que parfois un test passe et je ne saurais pas expliquer exactement pourquoi il passe.

Je délègue ma compréhension. Chaque prompt est un petit pacte faustien : je ship plus vite, mais j’habite de moins en moins ma propre maison technique.

C’est là que ça me gratte. Pas dans l’abstraction, dans ces gestes-là.

Cassidy Williams a écrit quelque chose qui m’est resté en travers :

Et pourtant. Et pourtant on continue. Parce que le résultat est là, l’app tourne, les features sortent, le quiz fonctionne. Mais ce petit “YES” intérieur quand le test passe après une heure de debug, ce moment où tu comprends enfin pourquoi ça marchait pas. Ça, la machine ne te le donne pas.

Rails bouge peu. Un has_many, un before_action, un turbo_stream.replace, ça fonctionne pareil en 2020 et en 2026. Les patterns n’ont pas bougé depuis des années, le code que génère la machine reste valide longtemps. Pas de mélange de versions, pas de paradigmes qui changent entre deux minor releases.

C’est un avantage concret pour le code assisté : la machine ne mélange pas Rails 7 et Rails 8 parce qu’il n’y a presque rien à mélanger. Avec d’autres stacks, le LLM génère du code pour la mauvaise API, le mauvais pattern, la mauvaise version du framework. Pas par incompétence, mais parce que les paradigmes changent souvent et que son training data contient toutes les versions en même temps.

Rester sur un sentier connu plutôt que courir après le dernier framework. Une forme de sagesse. Ou de paresse (probablement les deux).

Il y a un contre-argument légitime. Ruby n’a pas de types statiques. Si la machine se trompe, ça pète au runtime. Le refactoring à grande échelle, c’est grep et espoir. C’est réel.

Mais pour un projet solo assisté par la machine, la vitesse d’itération prime. La machine lit ta codebase entière en quelques secondes, elle n’a pas besoin du compilateur pour tracer les appels à travers les fichiers. Pour une équipe de 20 sur un monolithe, je comprendrais le choix inverse. Pour touslesmemes.fr, fait seul dans mon salon avec du café, je prends la vitesse.

La boucle de feedback par les tests compense une partie de ce manque. Tu décris le comportement attendu dans un test, la machine écrit le code qui passe. Rouge, vert, rouge, vert, en boucle fermée. Le test est devenu le langage dans lequel on parle à la machine.

Le test, c’est la laisse. Sans rails test, je ne pilote rien du tout, je regarde dériver.

Simon Willison (encore lui) a résumé le truc :

Des stagiaires numériques bizarres qui tricheront si on leur en donne l’occasion. 🙃

Le résultat chez moi : touslesmemes.fr. Design, algorithme de scoring, back-office, pipeline de sourcing de citations, le tout fait en solo avec Claude Code et Rails 8. Et cette question qui revient, chaque soir où je lance un prompt au lieu d’ouvrir un fichier. Pendant combien de temps est-ce qu’on continue à appeler ça coder ?