Le 7 octobre 2026, Theo Browne a publié en open source le dépôt ts-rust ainsi que son paquet npm associé, tsc-rs. Il s’agit d’un chantier d’ingénierie titanesque : transposer en Rust le compilateur natif TypeScript 7 de Microsoft, son vérificateur de types et l’ensemble de son implémentation LSP (Language Server Protocol), initialement réécrits en Go. Le projet reproduit scrupuleusement l’architecture algorithmique, le comportement à l’exécution, les options en ligne de commande et les interfaces de programmation du dépôt officiel, en alignant rigoureusement son code sur la version TypeScript 7.1.0-dev du 29 septembre 2026 (révision 673a5f17d713). Soumises à ce même cahier des charges, deux familles de modèles d’avant-garde ont affiché un écart d’un ordre de grandeur complet en matière de délais et de coûts d’exécution.
Un coût théorique de 400 000 dollars ramené à 24 000 dollars d’abonnements réels
Les premières tentatives du développeur s’appuyaient sur GPT-5.6 Sol et GPT 6 Astra. Durant plusieurs mois de boucles agentiques /goal autonomes, ces modèles ont englouti l’équivalent de plus de 400 000 dollars de jetons aux tarifs publics de l’API. Ils ont généré 1,3 million de lignes de code en Rust, pour finalement caler net sur un plafond de compatibilité de 84 % sans pouvoir progresser davantage. Après avoir basculé le projet sur Claude Opus 5.5, l’intégralité du portage a été bouclée en seulement deux semaines. Sur X, l’auteur a résumé la situation sans détour : « Près de 400 000 dollars de tokens Codex brûlés pour rien ; environ 20 000 dollars d’Opus investis et le projet était bouclé en deux semaines ».
Ce montant de 400 000 dollars ne reflète toutefois que la valeur faciale calculée selon la grille tarifaire standard de l’API. Dans les faits, les dépenses réelles engagées sur Opus se sont élevées à environ 24 047 dollars grâce à l’utilisation intensive des quotas d’abonnements professionnels, représentant entre 925 % et 983 % du plafond hebdomadaire d’un forfait à 200 dollars. Sur des tâches d’ingénierie au long cours, le goulot d’étranglement décisif réside dans la capacité du modèle à maintenir un contexte cohérent et à oser tout jeter lorsqu’une approche s’avère sans issue. Facturée au tarif unitaire d’API, une telle entreprise épuiserait instantanément la trésorerie d’une petite équipe ; c’est précisément ce qui rendait l’exercice viable uniquement sous le régime des quotas forfaitaires.
Figure : Comparaison des dépenses en tokens et des délais d’exécution entre les deux tentatives. Source : @theo / X
Jeter 1,3 million de lignes de code : quand faire table rase devient une stratégie
Dès son entrée en jeu, Opus 5.5 n’a pas cherché à rapiécer les 1,3 million de lignes de code léguées par Astra. Le modèle a jugé ces fondations irrécupérables, a initialisé un crate vierge et a tout réécrit à partir de zéro. En seulement dix heures, il livrait une version v0 fonctionnelle, devançant d’un coup les semaines d’errance du modèle précédent.
Face à la surcharge cognitive de plusieurs centaines de milliers de tokens de contexte, la lucidité d’un agent à éliminer les résidus défectueux et à repartir d’une feuille blanche conditionne la survie du projet. Dans les missions de génération de code étendues dans le temps, l’accumulation de correctifs sur des bases viciées engendre des cascades d’erreurs ingérables. Recommencer à zéro s’avère infiniment plus rapide que de tenter de sauver un code corrompu, bousculant au passage l’attachement viscéral des développeurs humains aux coûts irrécupérables.
181 711 tests amont pour verrouiller la ligne de défense
Dans la section des avertissements de ce dépôt sous licence MIT — qui a réuni 572 étoiles et 5 963 commits —, l’auteur a inscrit un avertissement frappant : « Je n’ai pas lu une seule ligne de ce code ». En réalité, l’ensemble du corps du README situé sous la ligne de démarcation a été rédigé directement par Claude Code. Si le développeur a osé publier un tel colosse logiciel sans la moindre relecture humaine, c’est que son assurance repose sur un socle objectif : les 181 711 tests unitaires portés depuis la version Go passent tous sans exception.
Lors des étapes de validation, les journaux de diagnostic sur le cœur de TanStack Query et Hono se sont révélés identiques point par point à ceux du compilateur Go, tandis que les réponses du serveur de langage et de l’API concordaient rigoureusement avec les jeux d’oracles amont. Testée sur 120 dépôts open source, la sortie en ligne de commande ne présentait d’écarts que sur une poignée de cas particuliers déjà répertoriés. La crédibilité de bases de code générées par des LLM repose désormais exclusivement sur la barrière infranchissable des suites de tests amont ; la revue de code manuelle, tributaire des limites cognitives humaines, a été purement et simplement exclue de la chaîne de confiance.
Figure : Carte d’aperçu social du dépôt ts-rust. Source : GitHub
En retrait face à Bun, mais armé de diagnostics Effect intégrés
Grâce à l’outil hyperfine sur une puce Apple M4 Pro (en retenant la médiane sur cinq exécutions), l’auteur a mesuré les performances du binaire de manière objective. Lors de la vérification de types de six projets open source, la vitesse moyenne géométrique de tsc-rs a atteint 1,61 fois celle de tsc 7. Sur le projet VS Code et ses 3,75 millions de lignes, tsc 6 demandait 54,56 secondes et tsc 7 prenait 6,84 secondes, tandis que tsc-rs a abaissé ce temps à 4,20 secondes. Les préversions actuelles ne bénéficiant pas encore des optimisations de profilage PGO et BOLT, les versions finales seront plus véloces. Toutefois, l’utilitaire bun check de Bun a exécuté le contrôle de VS Code en à peine 1,62 seconde, conservant sans conteste la palme de la rapidité.
En revanche, sur des diagnostics spécifiques liés à certains écosystèmes, l’unification architecturale a révélé toute sa force. Sur les tests cumulés des cinq projets constituant T3 Code, sans les vérifications Effect, tsc-rs a bouclé l’analyse en 7,25 secondes contre 16,10 secondes pour tsc 7. En activant les diagnostics Effect (codes d’erreur 377xxx), tsc-rs a affiché 11,13 secondes, contre 21,07 secondes pour l’association de tsc 7 et de @effect/tsgo. En intégrant les règles Effect directement dans la passe principale du compilateur, le coût d’une seconde analyse syntaxique est purement supprimé. Il suffit aux développeurs de lancer npm install -D tsc-rs pour bénéficier de cette chaîne de diagnostic unifiée.
Restrictions de plateforme et facture de calcul : les débats s’enflamment
En tant que projet expérimental à ses débuts, tsc-rs impose des contraintes d’exécution strictes. Il ne prend en charge pour l’heure que les environnements Linux x64 à liaison statique et macOS arm64, les plateformes Windows et Linux arm64 n’étant pas encore gérées. Parmi les dysfonctionnements recensés figurent des erreurs TS6059 dans certaines architectures de monorepo (signalant que des fichiers ne se situent pas sous rootDir) et des résultats parfois obsolètes avec tsc -b. Fait révélateur : sur les cinq premières anomalies signalées sur GitHub, quatre ne faisaient que reproduire le comportement natif du compilateur TypeScript amont. Lorsqu’un outil de migration calque son modèle amont au pixel près, les défauts d’origine sont automatiquement entérinés comme des fonctionnalités.
Au fil des débats sur Hacker News, les subtilités d’implémentation ont rapidement cédé le pas à des désaccords philosophiques plus profonds. Certains ont sorti la calculette pour souligner que 400 000 dollars auraient suffi à embaucher un ingénieur compilateur chevronné pendant un an au lieu d’alimenter des fermes de serveurs ; d’autres ont rétorqué que ces 400 000 dollars n’étaient qu’une facture faciale d’API et que la dépense effective plafonnait à 24 000 dollars. D’aucuns se sont également émus de voir un développeur publier un tel volume de code généré par IA sans même y jeter un coup d’œil, certains allant jusqu’à qualifier le README de manœuvre publicitaire au profit de Claude Code. Dès lors que le coût de fabrication logicielle tombe au niveau d’un abonnement mensuel, le cœur du débat en génie logiciel bascule : la question n’est plus de savoir comment architecturer du code, mais comment arbitrer entre la puissance de calcul des machines et la rémunération de l’intelligence humaine.
Liens de référence :
- Déclaration de Theo Browne sur X
- README du dépôt pingdotgg/ts-rust
- Débats de la communauté sur la réécriture de TypeScript par l’IA
