Datacurve a sorti DeepSWE, un benchmark long-horizon de génie logiciel avec 113 tâches à travers 91 dépôts dans 5 langages. Top scores rapportés : GPT-5.5 à 70%, GPT-5.4 à 56%, Claude Opus 4.7 à 54%, Gemini 3.1 Pro à 10%. Le titre lit « GPT-5.5 gagne ». L'histoire intéressante pour les bâtisseurs est dans la page de méthodologie, pas dans le leaderboard.
Les quatre avancées déclarées du benchmark : tâches écrites à partir de zéro plutôt qu'adaptées de PR ou commits existants, avec un GUID deep-swe-canary embarqué pour que la contamination puisse être détectée si le corpus fuite dans le pretraining ; couverture sur 91 dépôts et 5 langages ; prompts environ moitié la longueur de ceux de SWE-bench Pro mais solutions exigeant 5.5x plus de code pis ~2x plus de tokens de sortie ; verifiers écrits à la main qui testent le comportement logiciel plutôt que les détails d'implémentation. Tous les modèles roulent via mini-swe-agent pour un scaffold commun. Les exemples de tâches sont non triviaux — « Ajouter opérations XML diff, patch, et merge à etree », « Ajouter génération trap coredump à wasmi », « Corriger le tri PromQL des labels à travers valeurs typées et non typées » — du travail qui prenait des heures aux ingénieurs avant l'ère agentique. Tiers de budget de raisonnement asymétriques dans la comparaison : GPT-5.5 roulait à xhigh, Claude Opus 4.7 à max, Gemini 3.1 Pro non étiqueté.
Deux lectures pertinentes aux bâtisseurs. Premièrement : l'écart de 60 points entre GPT-5.5 pis Gemini 3.1 Pro est assez grand pour suspecter un biais structurel du benchmark vers l'idiome tool-use d'un modèle, surtout sur un nouvel eval où les conventions de harness comptent. Les scores SWE-bench Verified se sont resserrés quand le champ a eu le temps de re-rouler sur plusieurs scaffolds ; DeepSWE va probablement suivre le même arc. Deuxièmement : Datacurve est dans le business de services de données, donc un benchmark qui classe les modèles foundation est aussi une publicité pour la compagnie qui l'a bâti. Ça n'invalide pas l'eval, mais ça veut dire que le leaderboard demande une ré-exécution indépendante avant d'être load-bearing. Le choix du harness mini-swe-agent est un scaffold — OpenHands, Aider, harnesses style Claude Code vont produire différents ordonnancements relatifs sur les mêmes tâches.
Si tu ships des agents qui utilisent du code lundi matin : lis la section méthodologie de n'importe quel nouveau benchmark SWE avant de traiter les numéros comme un ordering. Cherche le GUID canary, la divulgation du scaffold, la normalisation du budget de raisonnement, pis si l'eval vit dans un conteneur Docker que tu peux rouler toi-même. Parie sur la tendance méthodologique, pas sur le titre du leaderboard.