Turborepo Est 96% Plus Rapide — L'Expérience AI Agents Chez Vercel

Turborepo Est 96% Plus Rapide — L'Expérience AI Agents Chez Vercel

lschvn5 min de lecture

Les ingénieurs de Vercel ont passé une semaine en mars 2026 à utiliser des agents de coding IA pour optimiser le planificateur de tâches Rust de Turborepo. Le résultat : le calcul du graphe de tâches est désormais 81 à 96% plus rapide, selon la taille du dépôt. Sur un monorepo de 1 000 paquets, turbo run est passé de 10 secondes de surcharge à une sensation quasi instantanée. Le compte-rendu mérite d'être lu pour tous ceux qui travaillent sur des outils JavaScript haute performance.

Commencer Avec des Agents Non Supervisés

L'expérience a commencé avec huit agents de coding en arrière-plan, chacun ciblant une zone différente de la base de code Rust. Chaque agent recevait un objectif vague — trouver des problèmes de performance — sans guidance détaillée. Le lendemain matin, trois avaient produit des résultats exploitables : une réduction de 25% du temps réel en passant au hachage par référence, un gain de 6% grâce au remplacement de la crate twox-hash par xxhash-rust, et un nettoyage d'un algorithme de Floyd-Warshall devenu inutile.

Mais les ingénieurs ont rapidement identifié un schéma : les agents produisaient des microbenchmarks impressionnants qui ne se traduisaient pas en gains réels. Un agent a produit une « amélioration de 97% » sur un microbenchmark qui ne représentait que 0,02% en pratique. Les agents n'écrivaient jamais de tests de régression. Ils n'utilisaient jamais le flag --profile. Et surtout, ils effectuaient leurs tests sur des cibles synthétiques plutôt que sur la base de code Turborepo réelle.

Le Problème du Profilage

Lorsque l'équipe a essayé d'utiliser les profils JSON Chrome Trace standard avec les agents, les résultats étaient médiocres. Les noms de fonctions coupés sur plusieurs lignes, des métadonnées non pertinentes mélangées aux données de timing, impossibles à grepper. Les agents se débattaient avec ces fichiers de la même façon qu'un humain — mal.

La percée est venue de l'observation que Bun avait introduit un flag --cpu-prof-md qui génère des profils en Markdown. L'équipe Vercel a créé une crate turborepo-profile-md qui génère des fichiers .md compagnons à côté de chaque trace : fonctions chaudes triées par temps propre, arbres d'appels par temps total, relations appelant/appelé — tout greppable, tout sur des lignes uniques.

La différence fut immédiate. Même modèle, même base de code, même harnais. Juste un format différent. Les agents produisaient soudain des suggestions d'optimisation dramatiquement meilleures.

Ce Qui a Vraiment Accéléré

La boucle d'itération guidée par humain — profiler, identifier les points chauds, proposer, implémenter, valider avec hyperfine — a tourné pendant quatre jours et a produit plus de 20 PRs. Les gains se sont répartis en trois catégories :

Parallélisation. La construction de l'index git, la marche dans le système de fichiers pour les correspondances glob, l'analyse des lockfiles et le chargement des package.json étaient tous séquentiels. Ils sont maintenant concurrents. Les gains étaient les plus importants pour les dépôts avec de nombreux paquets.

Élimination des allocations. Le pipeline clonait des HashMaps entières quand des références auraient suffi. Les filtres d'exclusion glob étaient recompilés à chaque appel au lieu d'être précompilés. Chaque client HTTP était construit par requête au lieu d'être réutilisé. Ces petites copies s'accumulaient.

Réduction des syscalls. Les appels git subprocess par paquet ont été regroupés en un seul index global. Ensuite, les subprocesses git ont été remplacés par libgit2, lui-même remplacé par gix-index — une implémentation pure Rust plus rapide.

La Limite : 85% Comme Plafond

À 85% plus rapide, les progrès se sont arrêtés. Les gains restants se situaient dans le bruit de mesure sur les MacBooks des ingénieurs. L'équipe soupçonne que le problème venait de la méthodologie de benchmark plutôt que du code lui-même — plus les opérations s'accélèrent, plus la variance du bruit système (I/O disque, ordonnancement CPU) submerge le signal.

La leçon : votre code source est la meilleure boucle de rétroaction. Les agents qui avaient précédemment écrit du code médiocre produisaient, dans des sessions ultérieures, un meilleur code — non pas parce que le modèle avait changé, mais parce que les améliorations fusionnées étaient désormais visibles dans la base de code et que les agents les suivaient. Le contexte, il s'avère, reste l'ingrédient clé.

Ce Que Cela Signifie Pour l'Écosystème JavaScript

Turborepo est une infrastructure fondamentale pour une grande partie du monde des monorepos JavaScript. Les améliorations de vitesse ici se cumulent sur chaque turbo run build, turbo run test et turbo run lint dans chaque dépôt qui en dépend. Le fait que l'optimisation ait été pilotée par des agents IA — mais validée par des humains — est une image réaliste de où en est le développement assisté par IA en 2026 : un accélérateur puissant pour trouver des victoires, encore dépendant du jugement humain pour séparer le signal du bruit.

Le format de profilage Markdown est déjà discuté comme un standard potentiel pour la sortie de performance lisible par LLM dans les projets d'outils Rust.

Questions fréquentes

Articles connexes

Plus de couverture avec des sujets et tags en commun.

Vite 8 stable : 7 correctifs en trois semaines
build-tools

Vite 8 stable : 7 correctifs en trois semaines

Vite 8.0.0 stable est sorti le 12 mars, et les correctifs n'ont pas cessé — v8.0.7 est disponible le 7 avril avec des corrections CSS, SSR, WASM et serveur de dev. Un contraste net avec le long cycle bêta.
Oxc Construisit Discrètement En Rust Le Toolkit JavaScript Le Plus Rapide — Et Il Est Presque Prêt
rust

Oxc Construisit Discrètement En Rust Le Toolkit JavaScript Le Plus Rapide — Et Il Est Presque Prêt

Alors qu'ESLint v10 se battait avec le ménage legacy, le projet Oxc a livré un linter 100x plus rapide, un formateur 30x plus rapide que Prettier, et un parser qui laisse SWC dans la poussière. Voici ce qu'est réellement le compilateur d'oxydation JavaScript.
Next.js 16.2 Stabilise l'API Adaptateur — et c'est Plus Important que Ça en a l'Air
vercel

Next.js 16.2 Stabilise l'API Adaptateur — et c'est Plus Important que Ça en a l'Air

Vercel, Netlify, Cloudflare, AWS et Google Cloud ont tous signé le même contrat public. Next.js 16.2 fait du déploiement multi-plateforme une fonctionnalité de première classe.

Commentaires

Connexion Connectez-vous pour participer à la conversation.

Pas encore de commentaires. Soyez le premier à partager vos pensées.