Un projet qui devait prendre 4 ans, compressé en deux semaines grâce à Claude Code !
Le coût est passé de 3 millions de dollars à une centaine de milliers.
Récemment, Anthropic a pour la première fois dévoilé le « flux complet » de la migration de code à grande échelle avec CC, un cadre en six étapes qui a stupéfié le réseau.
Le héros de cette histoire est Jarred Sumner, le père de Bun.
Il a écrit en un an Bun, un runtime JavaScript plus rapide que Node.js.
Aujourd'hui, en moins de deux semaines, il a écrit frénétiquement un million de lignes de code pour passer de Zig à Rust.
Le père de Bun fait réécrire un million de lignes de code par l'IA
À l'époque, la logique de Jarred Sumner de miser sur Zig était pure : une simplicité extrême pour extraire des performances rivalisant avec le C.
C'était presque l'outil idéal pour un fondateur indépendant.
Pour reprendre ses mots, « avant l'ère des LLM, écrire Bun seul en un an dans un petit appartement à Oakland ».
Cependant, l'envers de la simplicité extrême, ce sont d'innombrables pièges cachés posés très tôt.
Aujourd'hui, le CLI de Bun a franchi la barre des 10 millions de téléchargements mensuels, devenant même une dépendance cruciale au cœur de CC.
Avec l'expansion folle de l'écosystème, cette « dette technique » accumulée est arrivée à échéance, avec les intérêts.
Il a alors fait ce qu'on n'aurait jamais osé imaginer auparavant : utiliser Claude Code pour migrer entièrement Bun de Zig vers Rust, plus sûr pour la mémoire.
Moins de deux semaines, un million de lignes de code produites.
Avant la fusion, tous les tests existants de Bun passaient à 100% en CI. Après la fusion, 19 régressions sont apparues, mais toutes sont maintenant résolues. La version Rust est sortie discrètement en juin avec Claude Code.
Cette migration a brûlé 5,9 milliards de tokens d'entrée, 690 millions de tokens de sortie, ce qui représente environ 165 000 dollars au prix de l'API.
Cela peut sembler cher, mais comparé à l'ancien budget de 4 ans et 3 millions de dollars, c'est une affaire.
Une bibliothèque Python, transformée en 165 000 lignes de TS
Utiliser CC comme moteur d'efficacité n'est pas réservé à Jarred Sumner.
L'histoire de Mike Krieger, co-responsable d'Anthropic Labs et co-fondateur d'Instagram, est encore plus parlante.
En un week-end, il a migré une bibliothèque de code Python en 165 000 lignes de TypeScript, la partie principale consommant environ 27 millions de tokens.
Des centaines d'agents, 8 étapes de contrôle, 3 tours de revue contradictoire, et enfin une vérification de cohérence, comparant une par une les sorties de chaque commande avec la version Python originale, toute divergence étant traitée comme un bug.
Il a même fait concevoir par Claude lui-même une batterie de tests de bout en bout, exécutés pendant quatre nuits d'affilée, pour attraper les problèmes de bordure imprévus.
Pourquoi cette migration était-elle nécessaire ?
Les outils internes de son équipe devaient être livrés aux utilisateurs sous forme d'un seul binaire.
Avec la chaîne d'outils Python, la compilation prenait 8 minutes par plateforme, et la matrice de build complète attendait une demi-heure à chaque release.
Après la migration, la même compilation ne prend que 2 secondes, le démarrage du binaire est 6 fois plus rapide, et un pipeline de déploiement entier a été mis à la retraite.
Ne pas corriger le code, mais le cadre en six étapes clés
Alors, quelle est l'essence de cette approche ?
Anthropic la résume en une phrase : ne pas corriger le code, mais corriger la boucle qui produit le code.
Les grandes migrations se prêtent particulièrement bien à l'IA, pour une raison simple –
Le travail est naturellement parallélisable, des milliers de fichiers peuvent être traités simultanément ;
L'ancien code est en lui-même la meilleure spécification ;
La suite de tests est un arbitre prêt à l'emploi ;
Une échec de compilation ou de test fait immédiatement apparaître la prochaine tâche.
Le modèle peut s'acharner pendant des jours sur cette « vérité objective », sans nécessiter d'arbitrage humain intermédiaire.
Anthropic propose donc un cadre réutilisable en six étapes : d'abord préparer l'arbitre, écrire le manuel des règles, dessiner le graphe de dépendances, lister les lacunes.
Ensuite, effectuer un « test de navigation » à petite échelle pour vérifier les règles, et détecter les problèmes critiques avant de les étendre à des milliers de fichiers.
Puis la traduction complète, exécuter la boucle multi-agents « implémentation – revue – correction » ; enfin compiler, exécuter, comparer les comportements un par un.
Durant tout le processus, les règles ne sont jamais corrigées manuellement :
Chaque fois qu'un réviseur repère une erreur, il ajoute une phrase au manuel des règles, puis régénère le lot de fichiers concernés.
Anthropic suggère finalement de prendre une base de code que vous supportez depuis longtemps, et de demander à Claude à quoi ressemblerait son processus de migration.
Il y a quatre ans, c'était une blague. Aujourd'hui, c'est un chèque que l'on peut vraiment encaisser.
Autrefois, la migration était un gouffre que les développeurs n'osaient franchir ; aujourd'hui, ce n'est qu'une barre de progression à vider.
Cet article provient du compte WeChat public « Nouvelle Intelligence Originelle », auteur : ASI Apocalypse
