Un projet GitHub baptisé ts-rust circule depuis quelques jours dans les cercles de développeurs. Il porte intégralement vers Rust le compilateur TypeScript que Microsoft avait réécrit en Go, avec le vérificateur de types et le serveur de langage (LSP); l'outil en ligne de commande s'appelle tsc-rs. Le mainteneur, pingdotgg, l'annonce sans détour dans la description du projet: tout le code d'implémentation a été généré par un grand modèle de langage, et lui-même n'en a pas lu une seule ligne.
Le projet est figé sur une version upstream de microsoft/typescript-go, correspondant à TypeScript 7.1.0-dev. Selon la documentation, les 181 711 tests migrés depuis la version Go sont tous passés, et dans les projets réels testés par l'auteur, la compatibilité atteint 100%. Le dépôt est sous licence MIT, tout en conservant les mentions Apache-2.0 de TypeScript et BSD-3-Clause de la bibliothèque standard de Go, et compte actuellement plus de 600 étoiles.
Deux approches, deux modèles
L'auteur a d'abord testé avec GPT-5.6 Sol et GPT-6 Astra, d'OpenAI: le coût d'API a dépassé 400 000 dollars, pour environ 1,3 million de lignes de Rust produites, mais la compatibilité est restée bloquée à 84%. Il est ensuite passé à Claude Opus 5.5 en repartant de zéro: en 10 heures, une v0 fonctionnelle était prête, pour un coût total sur deux semaines d'environ 24 047 dollars.
"I've never read a line of this code."
(Je n'ai jamais lu une seule ligne de ce code.)
Côté performance, l'auteur a utilisé son propre projet T3 Code comme référence: tsc-rs termine la vérification de types en 7,25 secondes, contre 16,10 secondes pour tsc 7 en Go, soit 2,22 fois plus rapide. En prenant tsc 6 en JavaScript comme base, tsc 7 est 7,1 fois plus rapide et tsc-rs, 11,4 fois. Ces chiffres proviennent tous des propres tests de l'auteur, sans reproduction indépendante à ce jour, et ni OpenAI ni Anthropic ne se sont exprimés publiquement sur cette comparaison.
Face à des projets similaires
L'utilisation de grands modèles pour des migrations de code à grande échelle a déjà donné lieu à plusieurs cas publics cette année. GitHub avait révélé avoir utilisé Copilot pour réécrire l'un de ses runtimes en 830 000 lignes de Rust; Mistral a utilisé un agent pour migrer 40 000 lignes de Fortran 77 vers C++. Le point commun de ces projets est de disposer déjà d'une suite de tests à large couverture faisant office d'arbitre.
ts-rust suit le même schéma. Le portage de Microsoft vers Go était lui-même une réécriture fichier par fichier quasiment « recopiée », et les cas de test ont été transférés avec elle, offrant au modèle un objectif presque entièrement déterministe: des dizaines de milliers de tests, ça passe ou ça ne passe pas. Dans des tâches à l'objectif aussi clair et au retour aussi immédiat, l'écart entre les deux modèles se trouve fortement amplifié. Reste à savoir si cette comparaison tient pour du code métier aux exigences floues et sans filet de tests.
Limites connues
La documentation liste quatre limites: dans les monorepos où un même fichier est accessible par plusieurs chemins, les fichiers de sortie peuvent être plus nombreux qu'avec tsc; lors des builds incrémentaux avec tsc -b, des artefacts obsolètes ou manquants peuvent être lus; lors de longues sessions d'édition, la mémoire augmente lentement, environ 20 Mo tous les 1 000 changements; le numéro de version affiché est le 7.1.0-dev de l'époque du portage, pas la version npm.
L'auteur le présente comme une version précoce. Pour les équipes qui veulent l'essayer, la voie la plus sûre consiste à exécuter tsc-rs en parallèle du tsc officiel en CI et à comparer les sorties de diagnostic; l'utiliser directement pour remplacer la chaîne de build de production, sans que personne n'ait relu le code, est un risque que chaque équipe doit évaluer elle-même.
Sources: documentation du projet ts-rust, CocoLoop, discussion sur Hacker News; la documentation du projet a été recoupée avec le nombre de tests, le coût d'API, ainsi que le temps et le facteur du benchmark T3 Code.