MISSION Tu vas construire un benchmark clé en main pour comparer les meilleurs modèles frontières de code sur MON projet, afin de déterminer objectivement quel modèle est le plus performant pour travailler sur cette codebase spécifique. Le benchmark doit être entièrement automatisé, reproductible, et évalué par des tests pass/fail. ÉTAPE 0 — Prérequis et configuration Demande-moi les clés API dont tu as besoin avant de commencer (Anthropic, OpenAI, Google, et tout autre provider nécessaire). Stocke-les dans un fichier .env que tu ajoutes immédiatement au .gitignore. Va chercher la liste actuelle des meilleurs modèles en coding sur https://artificialanalysis.ai/models/capabilities/coding (via WebFetch). Sélectionne les 5 meilleurs modèles frontières accessibles par API publique. Si la page est inaccessible, propose-moi une liste des 5 modèles frontières les plus récents que tu connais (Anthropic, OpenAI, Google, xAI, DeepSeek…) et demande ma validation. Affiche la liste retenue (nom exact du modèle, provider, model string API) et attends ma confirmation avant de continuer. ÉTAPE 1 — Analyse du projet Explore la codebase : stack, langages, frameworks, architecture, conventions, système de tests existant, points de complexité. Produis un fichier benchmark/PROJECT_ANALYSIS.md résumant : la stack et les patterns du projet ; les zones du code représentatives de mon travail quotidien ; les types de tâches réalistes pour ce projet (features, bugs, refactos). ÉTAPE 2 — Génération des tâches de benchmark Génère 6 à 10 tâches de code adaptées à ce projet, dérivées de la vraie codebase. Elles doivent couvrir un gradient de difficulté : 2-3 tâches faciles (fonction utilitaire, petit fix, ajout simple) ; 3-4 tâches moyennes (feature touchant plusieurs fichiers, refacto localisée, correction d'un bug injecté) ; 2-3 tâches difficiles (feature transverse, respect strict des conventions du projet, cas limites). Contraintes impératives pour chaque tâche : Vérifiable automatiquement : chaque tâche est accompagnée d'une suite de tests (unitaires et/ou intégration) écrite par toi, qui échoue avant la solution et passe après. Écris toi-même une solution de référence pour prouver que les tests sont résolubles, puis supprime-la du contexte donné aux modèles. Auto-contenue : le prompt donné au modèle contient l'énoncé, les fichiers pertinents du projet (contexte identique pour tous les modèles), et les contraintes (ne pas modifier les tests, respecter les conventions). Anti-triche : les tests ne sont jamais fournis au modèle candidat (seulement leur description en langage naturel), pour éviter le hardcoding des assertions. Structure attendue : benchmark/ tasks/ task_01_nom/ prompt.md # énoncé + contexte fourni au modèle context/ # fichiers du projet fournis (copie figée) tests/ # tests pass/fail, jamais montrés au modèle reference/ # ta solution de référence (preuve de résolubilité) ÉTAPE 3 — Harnais d'exécution Construis un runner (Python ou Node, selon la stack du projet) qui : Pour chaque (modèle × tâche) : envoie le prompt via l'API du provider, récupère le code généré, l'applique dans un environnement isolé (copie temporaire du projet ou conteneur), lance les tests. Gère les formats de sortie : demande aux modèles de répondre dans un format structuré (par ex. blocs de fichiers avec chemins explicites) et parse-le de façon robuste. Un échec de parsing = échec de la tâche (c'est une donnée en soi). Enregistre pour chaque run : pass/fail par test, temps de réponse, tokens consommés, coût estimé, code brut généré (pour audit). Exécute 3 runs par couple modèle×tâche (pass@1 sur 3 essais indépendants) pour lisser la variance, avec température par défaut du provider. Prévoit retry avec backoff sur les erreurs API, et un timeout par tâche. ÉTAPE 4 — Rapport de résultats Génère automatiquement benchmark/RESULTS.md contenant : un tableau modèle × tâche avec taux de réussite ; un score global pondéré par difficulté ; coût total et coût par tâche réussie (métrique clé : perf/prix) ; latence moyenne ; des observations qualitatives : erreurs récurrentes par modèle, respect des conventions, qualité du code au-delà du simple pass ; une recommandation finale argumentée : quel modèle choisir pour ce projet, et pourquoi. RÈGLES DE CONDUITE Ne modifie jamais mon code de production : tout vit dans benchmark/. Estime le coût total API avant de lancer les runs et demande ma validation si ça dépasse 10 $. Avance étape par étape : présente-moi les tâches générées (étape 2) pour validation avant de coder le harnais. Commit chaque étape séparément avec des messages clairs. Commence par l'étape 0.
