Le rôle prépondérant de Claude Fable 5

Le billet détaille amplement les méthodes utilisées. Par exemple, le choix d’une réécriture complète (plutôt qu’incrémentale) a été motivé par la propre expérience de Jarred Summer dans ce type d’opération, et par la disponibilité d’une suite de tests indépendante du langage d’implémentation. Selon Summer, elle a permis de garder un filet de sécurité comportemental identique pour l’avant/après. On apprend en outre que la « revue adversariale » a été faite par deux instances Claude en contexte séparé, chargées de débusquer les bugs et présentées comme le mécanisme central de contrôle qualité. Et c’est justement la présence de Fable 5 au cœur du mécanisme qui rend l’annonce si visible.

La version de test a été produite en 11 jours. Les chiffres associés sont impressionnants : 5,9 milliards de tokens d’entrée non mis en cache, 690 millions de tokens de sortie, et 72 milliards de tokens d’entrée lus en cache. Soit environ 165 000 dollars au tarif de l’API, contre une estimation d’environ un an de travail pour trois ingénieurs à temps plein sur le code existant pour les 535 496 lignes de code, selon Jarred Summer. Cette performance – en moyenne 1 300 lignes de code à la minute – concerne cependant la phase de génération brute, pas le code fonctionnel. Le billet précise qu’à ce stade, « absolument rien ne fonctionnait encore ».

Une performance à relativiser également sur l’utilisation du LLM, car elle n’avait rien de « naïf ». L’orchestration humaine a été lourde, avec environ 50 flux de travail dynamiques et jusqu’à 64 instances de Claude en parallèle, réparties en quatre arbres de travail (worktrees). Summer dit avoir lui-même surveillé manuellement les sorties pendant l’essentiel des 11 jours de travail.