Contexte et objectif

Depuis janvier 2025, l’auteur teste la capacité des grands modèles de langage (LLM) à améliorer du code existant en le ré‑itérant. Après les premiers essais avec du Python, il oriente l’expérience vers Rust, langue réputée pour sa vitesse et sa sûreté mémoire, afin de vérifier si une instruction du type « write better code » peut générer des gains de performance mesurables. Le projet cible l’algorithme de réduction dimensionnelle UMAP, dont les implémentations classiques en C restent lentes sur de grands jeux de données.

Mécanique de l’optimisation agentique

Le modèle Claude Opus 4.5 reçoit un prompt détaillé incluant : création d’un crate Rust, génération d’un banc d’essai criterion couvrant des entrées jusqu’à 100 000 × 768 en modes CPU et GPU, interdiction d’utiliser du code unsafe, et autorisation d’ajouter des dépendances externes. L’agent itère tant que les benchmarks ne cessent d’évoluer, en intégrant des crates spécialisées comme faer pour l’algèbre linéaire et simsimd pour les opérations SIMD. Chaque itération est évaluée par criterion, qui calcule la significativité statistique du gain et consigne les résultats dans un fichier Markdown.

Résultats de benchmark

Après plusieurs cycles d’optimisation, le modèle a atteint des accélérations comprises entre 2 × et 20 × selon le domaine testé. Un exemple concret montre une amélioration de 3,5 × par rapport à la version précédente du crate, mesurée sur un jeu de 50 000 × 768 en mode CPU. Les gains proviennent principalement de la vectorisation SIMD via simsimd et de la résolution plus efficace des systèmes linéaires grâce à faer. Aucun code unsafe n’a été introduit, préservant ainsi les garanties de sécurité de Rust. Le benchmark final indique que tous les tests CPU dépassent le seuil de 1,2 × d’amélioration par rapport à la ligne de base établie avant toute optimisation.

Limites et perspectives

Les expériences restent confinées à un seul algorithme (UMAP) et à des tailles de données limitées par la capacité de la machine hôte. Le modèle ne manipule pas encore automatiquement le code GPU natif, ce qui contraint les gains potentiels sur des architectures spécialisées. De plus, la dépendance à des crates externes comme faer implique un coût de compilation supplémentaire, parfois négligeable mais pertinent pour des projets très légers. Enfin, la stratégie repose sur des prompts très détaillés ; une moindre précision pourrait entraîner des itérations inefficaces ou des modifications du benchmark lui‑même, ce qui est explicitement interdit. Malgré ces réserves, la démonstration confirme que les LLM agentiques, lorsqu’ils sont guidés par des contraintes claires et des outils de mesure robustes, peuvent produire du code Rust nettement plus performant que les implémentations traditionnelles.