KwaiKAT lance KAT-Coder-Pro V2.5, démontre des capacités de codage avancées

Le modèle de codage chinois déchire tout ! KAT-Coder-Pro V2.5 de Kuaishou résout un vrai bug en 1 min 20 sec, crée manuellement « Minecraft » avec 1 395 lignes de code, et ses capacités à long terme rivalisent avec Opus 4.8 — plus besoin d’être le nanny de l’IA.

Auteur et source de l'article : Nouvelle Intelligence

Les tests en direct sur le codage par IA en sont déjà arrivés à ce point ?

Peu importe à quel point on le présente comme exceptionnel, rien ne vaut la pratique. Maintenant, nous allons intégrer KAT-Coder-Pro V2.5 dans davantage de scénarios réels pour en explorer pleinement les capacités.

Pas de suspense — voici la révélation : l’IA intégrée à CC est KAT-Coder-Pro V2.5, publié par Kuaishou, un modèle agentic de codage de pointe. Alors que d’autres IA se concentrent encore sur « vous aider à compléter un morceau de code », elle vise à résoudre le problème consistant à « réaliser l’ensemble d’un projet » pour vous. Voilà précisément le fossé ultime qui sépare tous les modèles de codage.

Le penalty précédent n'était qu'un échauffement ; maintenant, on augmente l'intensité avec la V2.5 et on reconstitue en direct Minecraft.

Les instructions contiennent également plus de 400 lignes. Compressez-les, environ comme ceci :

Fichier HTML unique, Three.js, première personne. 14 blocs, chacun avec des propriétés de dureté, de transparence et de collision ; la roche mère est indestructible. Toutes les textures doivent être générées par programme en images Canvas de 16×16 pixels — aucune texture externe autorisée. Génération procédurale d'une île à l'aide de bruit à seed fixe, avec des collines, des côtes, des eaux peu profondes et des veines minières souterraines. Génération procédurale d'une forêt de chênes, accompagnée d'une cabane en bois que l'on peut entrer (planchers en bois, piliers en troncs, fenêtres en verre, toit en pierres rondes, cheminée en brique), et un chemin de pierres rondes partant du point de spawn jusqu'à la cabane. Affichage de lignes de visée ; en maintenant le bouton gauche, une barre de progression s'affiche ; lorsqu'un bloc est creusé, des particules de débris tombent. Les effets sonores sont synthétisés en temps réel avec Web Audio.

Immédiatement, un monde « Minecraft » jouable est terminé. Cliquez sur « Entrer dans le monde » ; la souris est verrouillée dans l’écran. Sous vos pieds se trouve de l’herbe, au-dessus s’étend un ciel bleu, un sentier de pierres rondes s’étend depuis vos pieds, contourne un chêne et mène à une petite maison derrière l’arbre — des murs en planches, des piliers en troncs, un toit en pierres rondes et une cheminée en brique rouge, avec des fenêtres en verre intégrées tout autour. Ensuite, avancez vers une clairière devant la maison, maintenez le bouton gauche enfoncé : « pop ! » — le bloc d’herbe se brise. Une dizaine de petits cubes verts jaillissent du trou, tournent sur eux-mêmes en tombant. La couleur des débris correspond exactement à celle du bloc que vous venez d’extraire. Ensuite, faites glisser la barre d’outils pour sélectionner des matériaux comme du sable, du bois de chêne et des pierres — il est temps de vous lancer dans la construction de votre maison. Pour votre étonnement, dans ce monde miniature, vous avez également assisté à un coucher de soleil teintant tout l’horizon.

Testons encore un autre type interactif : faisons-en un système solaire avec les mains par V2.5. Pour évaluer ses capacités, nous lui avons imposé des contraintes extrêmement strictes :

Plus de 1000 lignes de prompts, les points essentiels sont principalement les suivants :

Un seul fichier HTML, uniquement Canvas 2D, interdiction d'utiliser Three.js. Huit planètes et onze satellites, avec toutes les éléments orbitaux réels de l'époque J2000 — demi-grand axe, excentricité, inclinaison, longitude du nœud ascendant, paramètre du périapse, anomalie moyenne. Interdiction formelle de utiliser angle += speed. Les planètes et les satellites doivent résoudre l'équation de Kepler par itération de Newton, en partageant tous le même joursDepuisJ2000. La rotation de Vénus et d'Uranus doit être négative. Triton doit orbiter rétrogradement avec une inclinaison de 157,3°. Les anneaux de Saturne et d'Uranus doivent être tracés en deux passes distinctes — avant et après — afin que les planètes puissent masquer les anneaux. En vitesse élevée, les satellites doivent basculer en mode trajectoire pour éviter le clignotement. Lors de la pause, la rotation de la surface des planètes doit s'arrêter ; en lecture inverse, elles doivent reculer en sens inverse. La surface de toutes les planètes est générée par programme : Jupiter doit présenter une Grande Tache Rouge qui traverse la demi-sphère visible selon sa rotation ; les continents terrestres doivent disparaître lorsqu'ils passent à l'arrière et réapparaître de l'autre côté. En plus : huit vitesses temporelles, deux échelles orbitales, caméra virtuelle suivie, 700 étoiles à graine fixe, ceinture d'astéroïdes, ceinture de Kuiper, mise en page réactive, neuf touches raccourci.

Face à une telle complexité, V2.5 a démontré une pensée ingénieuse exemplaire. Il a décomposé avec précision l'ensemble du projet : depuis la conception de l'architecture et les stratégies de calcul orbital, jusqu'au système global de proportions double-tracks, à la génération du fond étoilé, puis au tracé de l'étoile principale, au rendu en couches des anneaux planétaires, et enfin à la coordination du système satellite complexe. Tous les modules s'enchaînent de manière hiérarchique, avec une logique impeccable. Pas besoin de mots inutiles, passons directement à la démonstration.

Ouvrez cette page web : au centre se trouve la date d'aujourd'hui, et les huit planètes à l'écran se trouvent exactement à leurs positions réelles à ce moment précis. Ce n'est pas une illustration du système solaire, mais un système solaire en fonctionnement réel ! Le Soleil est au centre, et les planètes s'étendent progressivement. Entre Mars et Jupiter, un anneau de poussière fine tourne lentement — ce sont les astéroïdes. Tous les corps célestes, toutes les lunes, chaque nuage à la surface des planètes, sont pilotés par un même temps de simulation. Lorsque vous appuyez sur la touche de pause, les planètes s'arrêtent de tourner autour du Soleil, les lunes s'arrêtent de tourner autour de leurs planètes, et la Terre s'arrête de tourner sur elle-même. En cliquant sur Saturne, un panneau d'informations glisse vers la droite. Dans la petite fenêtre d'aperçu en haut du panneau, Saturne tourne lentement sur elle-même, ses anneaux suivent le mouvement, et les occlusions avant/arrière sont parfaitement respectées. Cela ne ressemble plus à un devoir scolaire, mais à un produit mis en ligne.

Ensuite, nous avons plongé KAT-Coder-Pro V2.5 dans un vrai bug open source. Le résultat a été bien plus stimulant qu’un benchmark. Le problème provenait de humanize, une bibliothèque Python open source réelle. En 2024, elle a connu un bug réel : naturaldelta(timedelta(hours=-5)) devait retourner « 5 hours », mais elle répondait « a day ». Cinq heures négatives étaient traduites par une journée entière. Nous avons ramené le dépôt au commit où le bug existait encore, n’ayant fourni qu’un seul issue, puis nous avons laissé faire, sans aucune indication tout au long du processus. Après avoir recherché 2 motifs et lu 2 fichiers, il a directement fourni un diagnostic : Python stocke les timedelta négatifs sous forme de complément, donc timedelta(hours=-5) est en interne représenté comme days=-1, seconds=68400. Le code original appliquait abs() séparément à chaque composant : -1 jour devenait 1 jour, et 68400 secondes restaient inchangées, produisant ainsi artificiellement « 1 jour + 19 heures ». Cette analyse de la cause racine correspond exactement à celle de la correction officielle — stockage en complément, signes des composants incohérents, application séparée de abs entraînant une erreur. Toutefois, sa solution diffère de celle officielle : l’officiel applique abs() au timedelta entier, tandis qu’il choisit de convertir d’abord en secondes totales, puis de décomposer. Pour info, cette série complète s’est exécutée dans Claude Code. Et Claude Code est précisément l’un des environnements d’entraînement cités dans Harness Scaling officiel — mini-swe-agent, Claude Code, Codex, OpenClaw. Des tests répétés sur plusieurs frameworks visent à garantir « une adaptation sans heurts lors du changement de framework ». Les tests réels ont confirmé qu’il y parvient parfaitement, sans aucun signe de « mal adaptation ».

La dernière question ne consiste pas à corriger un bug, mais à intégrer un ensemble complet de nouvelles fonctionnalités dans un système en cours d'utilisation. Tout le monde a vécu cela : vous transférez un fichier de 1 Go, il atteint 92 %, puis la connexion est interrompue. Vous actualisez — et tout recommence à 0 %. La solution s'appelle le téléchargement par fragments : divisez-le en mille morceaux ; si la connexion tombe, vous ne retransmettez que les fragments incomplets. Cela semble simple : découper, télécharger, réassembler. Mais ce n'est pas ces trois étapes qui sont difficiles, c'est tout le désordre qui se trouve entre les deux :

Les fragments arrivent dans le désordre. Le client réessaie après une déconnexion, mais le serveur ne distingue pas si c'est une réessai ou une écrasement. Après un redémarrage du serveur, 700 fragments sur disque deviennent des orphelins sans propriétaire. Même s'ils arrivent tous, cela ne signifie pas qu'ils ont été transmis correctement.

Il a mis 20 minutes et 12 secondes. La solution consiste à diviser le disque en trois tiroirs : publié, métadonnées de progression, fragments incomplets. Les fragments restent toujours dans chunks/ et sont physiquement inaccessibles depuis la zone publiée. Les métadonnées sont d'abord écrites dans un fichier temporaire, puis renommées de manière atomique. Car le processus pourrait s'arrêter brusquement au milieu de l'écriture de la progression, laissant des données corrompues. En écrivant d'abord complètement, puis en effectuant un seul renommage, on obtient soit tout, soit rien. Après un redémarrage, un simple examen permet de retrouver instantanément la progression. Répétition des fragments, comparaison byte par byte. Une approche paresseuse consisterait à dire : « Il y a déjà un fragment à cette position, considérons-le comme dupliqué et passons ». Mais ici, chaque octet est comparé un par un : même une légère différence déclenche une erreur, et les données d'origine restent inchangées. Le résultat final est composé de 8 fichiers, environ 1 400 lignes de code, cinq nouvelles API, 26 tests de téléchargement, avec la prise en charge complète du reprise après pause et de la restauration après actualisation côté navigateur. npm test → 33 tests, 0 échecs. Et aucun des cinq anciens interfaces n'a été rompu. La clé de ce problème réside dans ces vingt minutes où cette longue liste de « Et si… ? » n'a oublié aucune possibilité. Le vrai génie logiciel, c'est neuf fois sur dix de consacrer son temps à ces « Et si… ? ».

Les capacités de l'agent au niveau professionnel approchent celles d'Opus 4.8

Revenons sur les résultats de KAT-Coder-Pro V2.5 dans les classements réels. Sur PinchBench, qui évalue les capacités d'utilisation d'outils agentic, KAT-Coder-Pro V2.5 obtient 94,2 points, dépassant Opus 4.8. Sur SWE-Bench Pro, considéré comme le classement le plus difficile pour l'ingénierie logicielle à l'échelle des dépôts, il obtient 65,2 points, légèrement en dessous d'Opus 4.8 (69,2 points), mais nettement au-dessus d'une série de modèles nationaux. De plus, sur l'ensemble d'évaluation réel construit en interne, KAT Code Bench, il obtient 53,1 points, se classant également dans le deuxième groupe supérieur ; sur l'ensemble d'évaluation agentic orienté métier KAT Claw Bench, il atteint 85,5 points, se battant au corps à corps avec les meilleurs modèles propriétaires et open source. Dans le paysage global des modèles de codage, il s'agit d'une progression concrète vers le premier échelon. Après avoir découvert la puissance réelle de KAT-Coder-Pro V2.5, il est temps d'explorer ses réalisations techniques sous-jacentes.

Analyse technique fondamentale

Cette fois-ci, autour de « chaînes de tâches plus longues et flux de travail métier plus complexes », l'équipe KwaiKAT a effectué une mise à niveau systématique. Plus précisément, KAT-Coder-Pro V2.5 réalise une avancée complète sur trois dimensions clés :

Capacités à long terme, capacités agentic générales, et système d'apprentissage par renforcement agentic à grande échelle qui les soutient.

« Un seul fichier avec un bon score » et « Réellement efficace dans le projet » sont deux choses différentes

La réalité à bien comprendre : demander à une IA de « compléter une fonction » et de « terminer une tâche d’ingénierie logicielle complète » relèvent de deux niveaux de capacité totalement différents. Le premier, les modèles actuels le maîtrisent déjà parfaitement. Mais le véritable génie logiciel a toujours une tout autre face. Les trois erreurs les plus fréquentes des modèles dans les tâches de longue portée sont : se perdre lors de la localisation entre fichiers, ignorer les normes du projet et soumettre un travail sans que les tests passent. Le véritable goulot d’étranglement se situe souvent à un endroit contre-intuitif : ce qui bloque le modèle, ce n’est pas tant la quantité de code qu’il a lu, mais le nombre de projets réels qu’il a exécutés avec succès. Le problème, c’est que créer en masse des environnements de dépôt exécutables et vérifiables est extrêmement difficile — le taux de réussite direct dans l’industrie stagne depuis longtemps autour de 16,5 %. Autrement dit, réussir à configurer un dépôt sur six, c’est déjà bien. La solution de KwaiKAT repose sur AutoBuilder, qui fait du modèle un « ingénieur environnemental » : il analyse le dépôt, génère la configuration et vérifie dans un sandbox isolé si les tests sont effectivement exécutés ; en cas d’échec, il itère automatiquement pour corriger. Les résultats sont immédiats : le taux de réussite de la configuration environnementale passe de 16,5 % à 57,2 %, accumulant ainsi plus de 100 000 environnements de dépôts exécutables et vérifiables couvrant 12 langages de programmation. Ces environnements couvrent tous les types de modifications rencontrées en développement réel : corrections de bogues, ajout de fonctionnalités, compatibilité d’interfaces, interactions inter-modules et corrections de régression. Voilà le « atelier d’entraînement » de la version V2.5. Il y a aussi une astuce dans le traitement des données. L’industrie a pour habitude de « conserver les bonnes réponses et jeter les mauvaises » ; KwaiKAT choisit au contraire d’extraire de la valeur des échecs — beaucoup d’échecs ne manquent que d’un dernier pas : la bonne direction, une localisation précise, mais un seul jugement clé manque. L’équipe extrait ces échantillons, leur applique des instructions ciblées et relance l’exécution ; environ 20 % d’entre eux se transforment en données d’entraînement de haute qualité reproductibles. Ainsi, le modèle apprend non seulement « comment faire correctement », mais aussi quelque chose d’encore plus précieux : « comment se redresser après une erreur ».

Agentic universel, du « savoir utiliser des outils » au « pouvoir assumer des opérations »

Écrire du code n’est qu’une moitié des capacités agentic. L’autre moitié, c’est maîtriser les flux de travail métier réels. Les évaluations actuelles des appels d’outils portent principalement sur des tâches atomiques — vérifier la météo, réserver un billet, et c’est terminé en environ cinq étapes. Mais les activités métier réelles sont d’un tout autre ordre ; prenons un exemple :

Lire les tendances pluriplatformes de la semaine, filtrer les éléments du secteur des courtes vidéos, sélectionner les cinq plus populaires par plateforme, puis produire un bulletin avec des chapitres et des limites de mots, classé par date décroissante, sans inventer de données.

Ce type de tâche implique souvent plus de dix interactions, accompagné d’un ensemble de contraintes implicites en matière de format et de cohérence ; rompre un seul maillon suffit à tout faire échouer. Comme les projets à long terme, cette compétence s’acquiert également dans le « atelier ». Du côté code, c’est AutoBuilder qui assure la tâche, tandis que du côté métier, c’est KwaiClawEnv qui prend le relais, en établissant une boucle fermée à trois niveaux :

• La couche Service étend dynamiquement le pool et convertit un grand nombre de compétences communautaires en services déployables ;
• La couche Task génère des milliers de variantes de tâches à partir de cas d'utilisation réels comme point de départ ;
• La couche Eval utilise un double filtrage « règles strictes + évaluation par modèle » pour ne conserver que les trajectoires exécutables, vérifiables et naturelles.

Les données d'entraînement produites contiennent en moyenne 15 appels d'outils par trajectoire, avec un maximum dépassant 100 étapes, couvrant l'analyse de données, l'intégration inter-systèmes, le traitement par lots de documents et la génération de rapports. Ce sont exactement les tâches que des milliers de développeurs et d'équipes métier de Kuaishou doivent accomplir quotidiennement.

Apprentissage par renforcement à grande échelle, permettant à l'IA d'apprendre « comment faire » par elle-même

Le fine-tuning supervisé permet au modèle de copier des exemples, mais il se retrouve perdu face à des erreurs inédites ou des retours inattendus. Ce qui enseigne véritablement au modèle à explorer, corriger et vérifier, c'est le RL à grande échelle. L'équipe KwaiKAT a concentré ses efforts sur les trois points suivants :

Premièrement, l’échafaudage n’est pas limité (Harness Scaling).

Faites passer le modèle en revue sur plusieurs frameworks tels que mini-swe-agent, Claude Code, Codex et OpenClaw. Ces frameworks présentent d'importantes différences en termes de protocoles d'appel, de gestion du contexte et de flux de contrôle, obligeant le modèle à développer ses compétences directement sur la résolution des tâches, afin qu'il ne soit pas désorienté lors d'un changement de framework.

Deuxièmement, l'allocation de crédit à long terme.

Au cours de centaines d'interactions, quelle étape exactement a conduit aux bons résultats ? L'équipe utilise un PPO asymétrique : pendant l'exécution, le modèle ne voit que les informations de l'environnement réel, tandis que le Critic, chargé de l'évaluation en formation, peut bénéficier d'une « vue de dieu » supplémentaire — permettant d'attribuer des récompenses et pénalités précises à chaque étape spécifique, évitant ainsi le risque d'un « seul mauvais pas qui gâche tout ».

Troisièmement, trois niveaux de récompenses.

Vérifiez les résultats des tests réels au niveau supérieur pour bloquer toute tentative de tricherie ; normalisez les pratiques d'ingénierie au niveau intermédiaire, comme l'appel des outils et le nettoyage des fichiers temporaires ; au niveau fondamental, fournissez un retour positif même pour les échecs précieux, tels que « localisation précise, tests partiels effectués », afin de préserver la curiosité exploratoire du modèle. Il convient de souligner que l'équipe a initialement supposé que l'incapacité à augmenter la récompense provenait d'un problème algorithmique, mais après investigation, il s'est avéré que la cause principale était l'environnement d'entraînement lui-même : au début, environ 16 % des trajectoires contenaient au moins un échec dû au sandbox et non au modèle. Après un travail intensif sur l'infrastructure de base, le taux d'erreurs du sandbox a été réduit à moins de 2 %, et la fréquence des plantages d'entraînement a diminué d'environ un ordre de grandeur. Ce sont précisément ces tâches discrètes mais fondamentales qui ont permis un entraînement stable par la suite.

Un modèle intégrant cinq compétences

Ingénierie à long terme, agentic général, terminal, esthétique frontend, connaissances générales — KwaiKAT a formé un expert pour chacune de ces cinq directions. Le défi consiste à les intégrer en un seul modèle, tout en évitant le phénomène « on appuie sur une extrémité, l’autre remonte » du balancier. La solution de l’équipe est le MOPD (Multi-Teacher Online Policy Distillation) : l’étudiant résout les exercices lui-même, et selon le domaine de l’exercice, il sollicite l’expert correspondant ; les compétences se fusionnent dans l’espace des fonctions, et non par combinaison brute des paramètres.

Un KAT-Coder-Pro V2.5 qui intègre les compétences de cinq experts, à déployer sans avoir à changer : écrire du code, exécuter des processus, créer des pages, tout en un.

Les capacités esthétiques de l'interface précédemment largement saluées sont pleinement conservées dans cette version, ce qui confirme précisément ce mécanisme : les nouvelles fonctionnalités ont été considérablement élargies, tandis que les anciennes n'ont subi aucune perte. Cette reconstruction sans compromis a directement forgé le bilan le plus convaincant.

La seconde moitié du codage repose sur l'« ingénierie »

KAT-Coder-Pro V2.5 repose sur un jugement clair : les limites actuelles à l’augmentation des performances des modèles de programmation ne proviennent plus de la taille du modèle, mais de la solidité de l’infrastructure environnante. Ainsi, la construction de l’environnement, la synthèse de trajectoires, la stabilité de l’apprentissage par renforcement et la fusion des capacités sont traitées comme des projets systémiques prioritaires. Le résultat est un profil de compétences nettement défini — une utilisation agente de haut niveau, associée à des capacités d’ingénierie au niveau des entrepôts, parmi les plus avancées au monde. Pour les développeurs, cela signifie qu’ils peuvent désormais confier en toute confiance un problème complet ou un flux de travail entier au modèle, sans avoir à en assurer la supervision constante. KAT-Coder-Pro V2.5 est désormais disponible en version complète et peut être expérimenté immédiatement. Pour commencer : appelez directement l’API via StreamLake.com (ID du modèle : kat-coder-pro-v2.5).