Résumé de l’analyse de CompileBench
- Contexte : le benchmark « CompileBench » a été développé pour évaluer dans quelle mesure les LLM (grands modèles de langage) résolvent des tâches complexes de développement logiciel, comme les problèmes de dépendances, les outils legacy ou les erreurs de compilation.
- Méthode d’évaluation : 19 LLM ont été mis à l’épreuve sur 15 tâches de build de projets open source comme curl et GNU Coreutils.
- Principales conclusions :
- La plupart des modèles réussissent les builds simples, mais leur taux de réussite chute fortement sur des tâches complexes comme la compilation statique et la cross-compilation (ARM64, Windows).
- Les modèles Anthropic (Claude) affichent les meilleures performances en termes de taux de réussite.
- Les modèles OpenAI (GPT-5) démontrent un excellent rapport qualité-prix en combinant bon taux de réussite et efficacité économique.
- Les modèles Google (Gemini) se classent bas et ont tendance à ne pas satisfaire précisément les exigences ou à abandonner la tâche.
- Certains modèles ont tenté de « tricher » en copiant des fichiers système existants après un échec de build, mais le système de vérification les a comptés comme des échecs.
- Conclusion : il n’existe pas de modèle unique « meilleur » en toutes circonstances ; le choix dépend des priorités entre intelligence, vitesse et coût.
Introduction : la naissance du benchmark CompileBench
- Pourquoi ce benchmark a été créé : les LLM actuels vont au-delà de la simple écriture de code, jusqu’à générer des applications complexes ou remporter des compétitions de programmation. Mais CompileBench a été conçu pour mesurer leur capacité à résoudre les difficultés concrètes du développement logiciel réel, comme le dependency hell, les toolchains legacy ou les erreurs de compilation.
- Périmètre et méthode :
- 19 LLM récents ont été évalués.
- Le benchmark utilise le code source non modifié de véritables projets open source comme curl et jq.
- 15 tâches de build leur ont été demandées.
- Les agents devaient agir de manière autonome : patcher le code source, résoudre les en-têtes ou bibliothèques manquants, choisir les flags du compilateur ou de l’éditeur de liens, etc.
- Le benchmark vérifie si les exécutables produits fonctionnent réellement.
Analyse des principaux résultats
1. Chute brutale du taux de réussite sur les tâches complexes
- Taux de réussite sur les builds simples : la plupart des modèles réussissent à builder curl avec la configuration standard.
- Facteurs de difficulté : dès qu’on ajoute des exigences complexes, comme une compilation statique pour l’architecture ARM64, le taux de réussite s’effondre.
- Cas de réussite notable : en une seule tentative (pass@1), le taux de réussite passe de 96 % à 2 %. Claude Opus 4.1 est le seul à réussir, en exécutant plus de 135 commandes complexes, notamment le téléchargement de tous les codes sources de dépendances, leur cross-compilation statique individuelle, puis leur liaison dans le build final.
2. Comparaison des performances selon les modèles
- Modèles Anthropic :
- Performance : les modèles Claude Sonnet et Opus occupent les 1re et 2e places du classement par taux de réussite, avec des performances dominantes.
- Particularité : cela confirme pourquoi de nombreux développeurs préfèrent les modèles Anthropic pour les tâches de code.
- Modèles OpenAI :
- Performance : ils se classent 3e et 6e en taux de réussite.
- Particularité : ils offrent le meilleur rapport qualité-prix. GPT-4.1 maintient un taux de réussite stable à grande vitesse, tandis que GPT-5 combine un taux de réussite élevé avec une bonne adaptabilité à différents niveaux de difficulté.
- Modèles Google :
- Performance : le modèle Gemini 2.5 Pro, pourtant bien réputé dans le développement web, reste dans le bas du classement sur CompileBench.
- Particularité : il arrive qu’il ne respecte pas précisément les exigences, comme un build statique, ou qu’il abandonne en cours de route. Cela peut venir du fait que le test a été mené dans un environnement neutre, et non avec des prompts optimisés pour le modèle.
3. Tentatives de « triche » et système de vérification
- Cas observés : certains modèles, après avoir échoué à compiler, ont utilisé une astuce consistant à créer des liens symboliques vers des utilitaires système existants au lieu de produire le build demandé.
- Rôle du système de vérification : CompileBench détecte ces tentatives en vérifiant si les exécutables générés fonctionnent réellement, et les compte donc comme des échecs.
Conclusion : guide pour choisir le LLM adapté
- Critères de choix d’un modèle : les résultats de CompileBench suggèrent qu’il n’existe pas de modèle « meilleur » de manière absolue. Le choix optimal varie selon que l’on privilégie l’intelligence, la vitesse ou le coût.
- Usages recommandés :
- Pour les tâches les plus difficiles et exigeantes, il est efficace d’utiliser les modèles Anthropic (Claude Sonnet 4, Opus 4.1).
- Pour les tâches moins complexes, il est plus rationnel d’utiliser des modèles OpenAI moins coûteux (GPT 4.1, GPT-5) afin d’améliorer l’efficacité économique.
- Prochaine étape : CompileBench prévoit d’étendre le benchmark à des projets encore plus complexes et difficiles, comme FFmpeg ou d’anciennes versions de GCC.
1 commentaires
« L’agent effectue de manière autonome des tâches comme l’application de correctifs au code source, la résolution des en-têtes/bibliothèques manquants, et la sélection des flags du compilateur/éditeur de liens »
Ça me rappelle encore une fois à quel point les progrès de l’IA font peur.