GPT-6 Sol ou Claude Opus 5.5 pour coder : préparer une comparaison équitable

La version courte

Même dépôt → Mêmes tests → Diff vérifié.
Conserver les preuves et vérifier le résultat avant de l’utiliser.

Comparez GPT-6 Sol et Claude Opus 5.5 sur le même état de dépôt, avec les mêmes tâches, outils et contrôles. Conservez le patch, le journal des commandes et les notes de revue. Cet article propose un protocole ; Thrive n’a pas exécuté ce face-à-face.

Préparer une comparaison reproductible

Utilisez un dépôt autorisé et un environnement sans secrets. Notez le commit puis restaurez cet état avant chaque essai. Pour un bug, gardez une reproduction défaillante. Donnez les mêmes fichiers et commandes aux candidats, avec un budget de temps ou de tentatives défini.

Si un produit dispose d’outils supplémentaires, indiquez-le et présentez l’essai comme une comparaison de parcours de travail. Utilisez une branche de test ; une preuve de correctif local n’exige ni publication de package ni mutation d’une base réelle.

Choisir cinq types de tâches

Le débogage doit corriger la cause et ajouter une vérification de régression utile. La refactorisation doit préserver le comportement et les contrats publics. Les tests doivent couvrir les cas limites et révéler un échec significatif. Le raisonnement sur le dépôt doit citer les fichiers et suivre les appels réels. Les exemples de documentation doivent fonctionner sur la version indiquée.

Écrivez les entrées, le comportement attendu, les contraintes et la commande de validation. Le cas fictif d’un espace CV privé peut distinguer un visiteur déconnecté, redirigé vers la connexion avec sa destination conservée, d’un visiteur connecté ayant accès. Les conseils publics doivent rester accessibles. Cette demande fixe des états et une limite testables.

Relire sans le nom du modèle

Présentez les patches sous des noms neutres si possible. Vérifiez le fonctionnement, le périmètre, la maintenabilité et les preuves. Gardez une égalité lorsque les deux solutions remplissent le contrat avec un effort similaire.

Exécutez les tests dans un environnement propre. Recherchez les tests affaiblis, les erreurs supprimées et les réglages modifiés pour masquer un échec. Examinez les dépendances et les permissions : élargir l’accès pour corriger un défaut peut créer un problème plus grave.

Documenter les résultats et leurs limites

Notez les tokens, les nouvelles tentatives, les coûts d’outils et le temps du relecteur. Comparez le coût d’une tâche acceptée, pas seulement le tarif par token. Les tokenizers et les niveaux de service peuvent différer.

Le compte rendu doit préciser les identifiants, les réglages, le dépôt, le nombre de tâches, le budget de tentatives, la date et la méthode de revue. Gardez les échecs avec les réussites et les traces permettant de refaire les contrôles. Ces résultats concerneront vos cas testés ; ils n’établiront pas un gagnant universel en programmation.