CodeMidas génère des tâches RL depuis le code source

Entraîner un agent de codage réellement capable d'accomplir du travail n'a jamais dépendu uniquement d'un modèle plus grand ou de plus de GPU. L'apprentissage par renforcement a besoin de tâches, et précisément de tâches dont la sortie de l'agent peut être vérifiée automatiquement et de manière fiable comme correcte ou incorrecte, c'est-à-dire des tâches dotées de vérificateurs.

Sans vérificateur, aucune quantité de trajectoires d'entraînement ne vaut mieux que du bruit. C'est exactement le goulot d'étranglement que vise le nouvel article « CodeMidas: Scaling Agentic Coding RL Environments from Code Itself » (arXiv:2609.22068) : non pas un manque de calcul, mais une pénurie de la ressource qui limite réellement les progrès, à savoir des tâches de codage vérifiables.

Pourquoi les issues et les commits ne suffisaient pas

Avant CodeMidas, la méthode standard pour transformer des dépôts open source en tâches d'entraînement RL consistait à exploiter les artefacts du développement : issues, commits et pull requests, en associant un rapport de bug au commit qui l'a corrigé pour produire une tâche et sa condition de vérification. Cette approche fonctionne, mais son plafond est bas, car l'immense majorité du code déjà implémenté et fonctionnel dans le monde n'a aucune issue ni PR associée.

Ne dépendre que des métadonnées laissées par les développeurs revient à jeter la quasi-totalité du minerai avant même de creuser. CodeMidas inverse cette logique : il utilise uniquement le code source comme entrée, sans dépendre d'issues, de commits ni de PR. Tout morceau de code qui implémente déjà une fonctionnalité devient, en principe, extractible comme tâche, ce qui élargit le vivier de tâches exploitables des « dépôts avec une trace écrite » à pratiquement « tout code source open source qui fonctionne ».

Du calcul agentique à chaque étape de construction

CodeMidas mobilise du calcul agentique tout au long du pipeline de construction de l'environnement, pas seulement lors de l'entraînement. D'abord, des agents explorent les fonctionnalités déjà implémentées dans une base de code et formulent une spécification comportementale décrivant ce que ce code est censé faire.

Ensuite, ils construisent des tests ancrés dans l'exécution réelle du code d'origine, plutôt que des assertions devinées dans le vide. Enfin, les tâches candidates passent par une validation et un filtrage via des vérifications d'exécution et des rollouts répétés de solutions, éliminant celles dont la spécification est vague, dont les tests sont peu fiables ou qui ne peuvent pas être reproduites de façon stable. Cette volonté d'utiliser l'exécution elle-même pour vérifier la fiabilité d'une tâche est ce qui permet à tout le pipeline de monter en échelle sans dégrader silencieusement la qualité.

Pourquoi l'étendue est le levier de généralisation

Le jeu de données obtenu comprend 5 545 tâches d'entraînement issues de 3 185 dépôts open source, couvrant 23 langages de programmation et 15 domaines techniques. Cette étendue n'est pas un détail cosmétique, elle fait la différence entre un agent qui semble simplement compétent sur un benchmark étroit et un agent qui a acquis une compétence de codage transférable.

S'entraîner sur un éventail restreint de langages ou de structures de projets invite au surapprentissage d'une syntaxe précise, d'un motif de bug précis ou d'une convention de dépôt précise. Répartir les tâches sur 23 langages et 15 domaines force la compétence sous-jacente apprise à devenir quelque chose de plus général : comment s'orienter dans une base de code inconnue et comment vérifier son propre travail, plutôt que comment faire du filtrage de motifs sur un seul corpus.

Ce que les gains de benchmark révèlent réellement

L'équipe a entraîné le modèle MiMo-V2.5 sur ces tâches avec GRPO et l'a évalué sur cinq benchmarks, avec trois gains précis rapportés : DeepSWE, un benchmark de réparation d'issues, a progressé de 11,7 % ; ProgramBench, un benchmark de construction de programme complet, a progressé de 17 % ; et Terminal-Bench v2.1, couvrant le travail en terminal, a progressé de 8,5 %. ProgramBench affiche le plus grand bond, ce qui correspond parfaitement à la manière dont CodeMidas construit ses tâches dès le départ : puisque le pipeline est bâti autour de la compréhension et de la reproduction d'une fonctionnalité complète déjà implémentée plutôt que de la correction d'un bug étroit, il n'est pas surprenant que l'agent obtenu progresse le plus sur la construction de choses à partir de zéro plutôt que sur des réparations plus ciblées.

Les études d'ablation ont en outre montré que l'augmentation du nombre de tâches d'entraînement de haute qualité continuait d'améliorer les performances, ce qui suggère que cette approche consistant à fabriquer des vérificateurs à partir du code à grande échelle dispose encore d'une marge de progression. L'analyse des trajectoires a également révélé que l'agent entraîné par RL manifestait davantage d'exploration de la base de code et un comportement d'auto-vérification plus varié, ce qui signifie que le modèle n'a pas seulement appris à répondre correctement, mais quelque chose de plus proche de l'habitude d'un ingénieur : s'orienter avant d'agir et vérifier après.