Cognition vient de sortir FrontierCode 2.0, leur bench qui cherche à répondre à une question : est-ce qu'un maintainer mergerait vraiment ta PR, pas seulement est-ce que les tests passent ? De nouvelles tâches, gardées privées pour limiter la contamination, des consignes moins détaillées et des critères de mergeabilité plus exigeants. Sur la 2.0 : • Opus 5.5 : 45,5 % • GPT-6 Astra : 42,8 % • DeepSeek V4.1 Flash : 19,3 % • Kimi K3 : 17,7 % Ce sont des scores pondérés, avec un zéro si un critère bloquant échoue. Pas directement des taux de PR acceptées. Pour remettre en contexte, sur la 1.1, Kimi et DeepSeek étaient autour de 44 %, contre 54,6 % pour Opus. Sur cette nouvelle suite, Opus baisse d'environ 9 points, contre environ 25 pour DeepSeek et Kimi. La baisse ne concerne pas seulement les open weight : Grok 4.7 et Gemini 4 Argon perdent aussi autour de vingt points. Sur cette comparaison, Opus et Astra conservent une avance nette. Les tâches et les critères ont changé. Ce n'est pas une régression des modèles, mais l'écart se creuse sur ce que cette version cherche à mesurer. La 2.0 insiste davantage sur ce que l'agent doit déduire du code et de la demande, sans qu'on lui écrive tout : corriger aussi un chemin voisin touché par le même bug, par exemple. Et honnêtement, c'est précisément là que je vois des différences dans mes usages. Avec les open weight que j'utilise, notamment DeepSeek et Kimi, j'obtiens de bons résultats sur une tâche bien délimitée. Quand la demande devient plus pointue ou laisse des choses implicites, je dois davantage recadrer : changements non demandés, mauvaise interprétation du besoin, réponses à côté. Ça m'arrive aussi avec Opus, Astra ou GPT-6.1 Sol, mais moins souvent. En perso, ça passe. En pro, beaucoup moins. Sur mes side projects, je peux accepter de passer une soirée à tester plusieurs approches. Beaucoup sont des expériences, avec des données de test et aucun business derrière. Au boulot, si je dois arrêter une tentative après une heure et tout relancer avec un autre modèle pendant trente minutes, j'ai perdu une heure par rapport à ce que j'aurais pu faire directement. Et ça, ça se paie. Le classement rejoint donc une partie de mon ressenti. Peut-être aussi que je retiens plus facilement un résultat qui va dans mon sens. Le harness, les outils, les skills et les consignes du projet changent beaucoup le résultat. Ce qui compte reste ce que vous arrivez à faire sur votre code. J'espère vraiment que l'écart va se réduire, que les modèles viennent de Chine, des États-Unis ou d'ailleurs. J'ai envie d'avoir davantage d'options auxquelles confier ce travail, avec moins de reprises. Et vous, sur vos projets, quels modèles vous demandent le moins de reprises quand la demande n'est pas complètement cadrée ? xitter.cf/cognition/status/21151…

Avec les agents, je code plus vite et je fais plus de choses. Mais si le goulot se déplace, est-ce qu’on gagne vraiment du temps ? On en discute souvent avec mes collègues. De mon côté, j’ai le sentiment de produire du meilleur code. Mais ça demande une vraie relecture des PR, des consignes adaptées au projet et de surveiller la complexité que les agents proposent d’ajouter. Le rapport State of Developer Experience 2026 d’Atlassian fait écho à ces discussions : 87 % des développeurs interrogés disent que l’IA les aide à livrer plus vite. Pourtant, 72 % déclarent rencontrer autant ou plus de friction qu’avant. Ce sont leurs perceptions, pas une mesure du temps de livraison. Mais je retrouve ce décalage dans mon quotidien. Concrètement : de l’implémentation, mais aussi une partie du design et de la réflexion produit. Le temps gagné me permet d’élargir mon périmètre. Avant de coder, il faut toujours comprendre le besoin, puis trancher sur ce qu’on fait. Après, il faut relire, tester et vérifier que ça répond vraiment à la demande. Une PR prête, ça ne veut pas dire que la fonctionnalité est livrée. Si l’organisation de l’entreprise ne s’adapte pas aux agents, les décisions et les validations gardent le même rythme. On peut donc coder plus vite sans livrer beaucoup plus vite. C’est ce que j’essaie de mieux comprendre en ce moment : où part le temps gagné, et qu’est-ce qu’il nous permet réellement d’améliorer ? Chez vous, le goulot se situe plutôt au début, pendant l’implémentation ou au moment de livrer ? Et vous avez l’impression de livrer plus vite, ou juste de coder plus vite ?