Deux mille agents se réécrivent en deux semaines : comment Prime Agent a fait passer TypeScript dans Rust

Une armée de deux mille, dont aucun n'est humain

Prime Agent, l'agent de codage sorti seulement en août 2026, a accumulé en deux mois plus de 300 000 téléchargements et traité plus de 8 000 milliards de tokens. Le 9 octobre, son éditeur Prime Intellect a annoncé quelque chose de plus marquant encore : l'outil a été réécrit par lui-même. Le passage de TypeScript à Rust a pris deux semaines, et ceux qui ont travaillé étaient plus de deux mille agents autonomes.

Il ne s'agit pas du slogan « l'IA écrit du code à votre place ». Durant tout le portage, l'équipe humaine a surtout fait une chose : mettre en place les critères d'acceptation pour que les agents puissent mesurer eux-mêmes s'ils avaient bien travaillé. Le reste, orchestration, écriture du code, revue et vérification, a été confié aux machines.

Coût et échelle : déplacer 200 milliards de tokens

D'après le blog officiel, cette réécriture a mobilisé plus de 2 000 agents travaillant en parallèle sur plus de 10 000 sandbox Prime, et consommé plus de 200 milliards de tokens sur l'endpoint GLM-5.3 de Prime Inference. La phase qui a réellement écrit du Rust a été menée par 1 981 agents, pour environ 192,99 milliards de tokens ; la phase de montée en performance qui a suivi pendant trois jours a mobilisé 228 agents supplémentaires, pour environ 35,7 milliards de tokens.

Ces chiffres sont en eux-mêmes un signal. Que le modèle ouvert GLM-5.3 devienne le moteur d'inférence principal d'un essaim d'agents de niveau production n'est pas la même chose que « un modèle a encore gagné un point à un benchmark ». Cela montre que, dans des contextes d'ingénierie longs, volumineux et exigeant des appels d'outils fiables, le rapport coût-efficacité des modèles à poids ouverts est désormais acceptable pour de vrais projets.

Orchestration : l'agent racine n'écrit aucun code produit

Ce qu'il faut copier, ce n'est pas « avoir utilisé deux mille agents », mais leur façon de se répartir le travail. Toute la réécriture était dirigée par un unique agent racine, qui lui-même n'a pas écrit une seule ligne de code produit. Il ne faisait que trois choses : découper les tâches en un graphe d'ordre topologique, suivre l'avancement de chaque tâche, et fusionner le travail terminé.

Chaque tâche traverse quatre rôles, dans l'ordre :

• Planificateur : il rédige la spécification, la conception de la fonctionnalité et la « réponse de référence », cette dernière étant reprise directement du comportement existant de la version TypeScript.
• Implémenteur : il écrit le code Rust dans un worktree séparé, pour que différentes fonctionnalités avancent en parallèle.
• Relecteur : il change de modèle et de contexte pour chercher de façon adversariale les défauts de cette modification.
• Vérificateur : il compile le code et lance les tests de cohérence dans un sandbox tout neuf.

Si la revue ou la vérification échoue, la tâche revient à l'implémenteur avec les conclusions. Ce n'est que lorsque les deux passent que la modification peut être fusionnée. Prime Intellect a délibérément séparé la « génération » de l'« évaluation », pour une raison limpide : laisser l'agent qui a écrit le code juger sa propre production, il aura naturellement tendance à se favoriser.

Les vrais garde-fous : quatre types de contrôles de cohérence

Un processus ne suffit pas ; il faut aussi des critères objectifs de justesse. L'équipe a mis en place quatre types de contrôles de parité, couvrant différentes facettes d'une même fonctionnalité :

• Tests différentiels de TUI : exécuter les binaires TypeScript et Rust sous le même modèle scripté, comparer l'écran du terminal image par image, en couvrant le démarrage, les menus, les appels d'outils, la reprise de session, les sous-agents et la reprise après plantage.
• Cohérence du harness : comparer les transcriptions de session produites de chaque côté, ainsi que les requêtes que chacun envoie au fournisseur de modèle.
• Cohérence du protocole : vérifier chaque type de message du protocole du démon contre l'implémentation TypeScript.
• Audit fonctionnel : là où les scripts ne vont pas, les agents vérifient composant par composant et marquent chacun comme « cohérent », « partiellement cohérent » ou « manquant ».

Avec ces règles objectives, les agents peuvent juger eux-mêmes leur avancement et bloquer les régressions avant la fusion, ce qui réduit d'autant la nécessité d'une revue humaine. L'équipe se montre aussi franche : les bugs qui ont échappé étaient ceux qu'aucun test ne couvrait, et ils ne sont apparus qu'à force d'utilisation quotidienne en interne.

Résultats : démarrage à froid 14 fois plus rapide, 80 % de mémoire en moins

Dans les comparaisons officielles, le délai entre le démarrage à froid et le moment où l'on peut saisir du texte passe de 737,8 millisecondes pour la version TypeScript à 55,8 millisecondes, soit un gain de 14,18 fois ; le démarrage à chaud gagne 13,34 fois ; la mémoire de tout l'arbre de processus tombe de 607,4 Mo à 106 Mo, soit environ 80 % économisés ; la taille d'installation passe de 172,1 Mo à 59,6 Mo. La première sortie visible tombe à 23,6 millisecondes. La phase de montée a enregistré 144 expériences et fusionné 69 modifications valides. Une mise en garde toutefois : cette comparaison utilise la suite d'exécution de l'équipe elle-même, et l'équipe reconnaît l'absence de benchmark commun, donc les chiffres sont à interpréter avec prudence.

Le changement structurel pourrait durer plus longtemps que la vitesse. Le code a été découpé en neuf crates, avec des dépendances unidirectionnelles imposées par Cargo ; le plus gros fichier source est passé d'environ 15 000 lignes à environ 2 500, et plus aucun fichier ne dépasse 5 000 lignes. Chaque session tourne dans son propre processus de travail, donc un plantage n'affecte pas les autres. Le support de Windows est arrivé comme effet de bord d'une abstraction de plateforme plus propre, et le catalogue de modèles est désormais récupéré à l'exécution, si bien qu'ajouter un nouveau modèle ne dépend plus d'une release.

Pourquoi Rust

Les points douloureux de TypeScript listés par l'équipe sont concrets : les types sont optionnels et disparaissent à l'exécution ; les erreurs se propagent sous forme d'exceptions non vérifiées ; les tâches gourmandes en CPU, comme le rendu et l'analyse de grosses sessions, se disputent la même boucle d'événements que la saisie au clavier ; chaque processus doit entretenir un runtime JavaScript et un ramasse-miettes. Pour un démon qui reste résident et fait tourner un processus de travail par session, du code natif sans GC est la principale source d'amélioration de la mémoire et du temps de démarrage.

Et quand le code est surtout écrit par des agents, la valeur des « garanties à la compilation » est démultipliée. Les énumérations exhaustives, la propriété et les durées de vie, plus les lints stricts de Clippy, éliminent toute une classe de bugs avant même que le code ne tourne. Autrement dit, le compilateur prend en charge une partie du jugement qui reviendrait sinon à un relecteur humain.

Ce que cela signifie selon les personnes

Si vous dirigez une équipe d'ingénieurs, ce que vous pouvez réutiliser n'est pas le chiffre « deux mille agents » mais la méthode : transformer d'abord les critères d'acceptation en contrôles objectifs et automatiquement exécutables, répartir ensuite génération et évaluation entre différents modèles et contextes, et enfin laisser les agents avancer seuls à l'intérieur des garde-fous. Primer Intellect industrialise déjà ce modèle à quatre rôles en un flux de travail réutilisable, au motif qu'une « usine à essaim bien définie » est plus fiable qu'un bricolage improvisé pour chaque projet.

Si vous êtes un simple utilisateur, cela explique une chose : la cadence de mise à jour d'outils comme Prime Agent va ressembler de moins en moins à celle d'un logiciel classique. Quand un produit peut se réécrire lui-même, le sens du numéro de version change. C'est aussi un rappel : quand vous voyez des conclusions du type « le refactoring a accéléré 14 fois », allez d'abord voir la note de bas de page pour savoir qui a mesuré et par rapport à quoi. Les agents savent écrire du code utile, mais ils savent tout aussi bien écrire de fiers éloges d'eux-mêmes.