CodeMidas: Scaling Agentic Coding RL Environments from Code Itself

CodeMidas. Scaling Agentic Coding RL Environments from Code Itself. By Bowen Ye and eighteen others, from L L M Core, Xiaomi, Peking University, and two other institutions. Published on the eighteenth of September. No code repository is linked to it.

Training capable coding agents with reinforcement learning needs diverse tasks with reliable verifiers. Open-source codebases are a rich source of such tasks, but existing methods usually rely on development artifacts, issues and commits, and that limits the range of tasks that can be extracted. Only the parts of a codebase that someone happened to file an issue about, or change in a commit, become training material.

CodeMidas is an agentic pipeline that turns functionality already implemented in a codebase into executable reinforcement learning environments. Source code is its only task-specific input. Whatever a codebase already does can, in principle, become a task. The name hints at the ambition: code that was written for its own purposes is turned into training environments.

It allocates agentic compute to every stage of building an environment. Agents explore implemented functionality and formulate behavioral specifications. They construct tests grounded in executing the original code, so the verifier reflects what the code actually does. And they validate and filter candidate tasks, through execution checks and repeated solution rollouts. Each stage is carried out by agents, which is what lets the pipeline run across thousands of codebases without a person writing each task. The checks at the end are there to keep only tasks that execute properly and can be solved. The resulting dataset has five thousand five hundred and forty-five training tasks, drawn from three thousand one hundred and eighty-five open-source codebases. They span twenty-three programming languages and fifteen technical domains.

Training MiMo-V2.5 on these tasks with GRPO improves performance on all five diverse benchmarks. Issue repair on DeepSWE improves by eleven point seven percent. Whole-program construction on ProgramBench improves by seventeen percent. Terminal work on Terminal-Bench version two point one improves by eight point five percent. The three kinds of work are different from one another, repairing issues, building whole programs, and working at the terminal, and the gains appear in each.

Ablations show that increasing the number of high-quality training tasks improves performance, which is the property a scalable source needs. Trajectory analysis shows the trained agent behaving better, exploring the codebase more and verifying its own work in more diverse ways.

Issues and commits cover only part of what a codebase contains. CodeMidas starts from the implemented code itself, and the authors take their results as establishing source code as a scalable foundation for environments that improve coding agents across diverse software tasks.

CodeMidas. Scaling Agentic Coding RL Environments from Code Itself. By Bowen Ye and eighteen others, from L L M Core, Xiaomi, Peking University, and two other institutions. Published on the eighteenth of September. This is the long version: the whole paper rather than the abstract.

Training a coding agent with reinforcement learning needs two things in quantity: diverse tasks, and verifiers you can trust to say whether the work is right. Existing pipelines mostly mine development records. They lift task statements from issues, pull requests and commits, break existing tests, or turn documentation into specifications. Functionality that never had an issue, a test or a written description is invisible to them. The team from Xiaomi, Peking University and two other universities ask a blunter question: can the code itself be the only task-specific input? Implemented functionality already holds both a task and a candidate answer. Its public interfaces say what should exist, and running it says what the right outputs are.

Each task is three things: a statement, a containerized development environment, and a hidden executable verifier. The verifier stays outside the solver's environment and is injected only at grading, returning a reward of one or zero. The hard part is the test oracle. The statement must make the required behaviour explicit while leaving internal choices open, and the tests must reject wrong solutions while still accepting alternative correct ones. A test that insists on exact error wording, or on one internal structure, punishes a correct agent. A test that checks too little rewards a broken one.

Agents do the work at every stage. First, task design. An agent reads the codebase's structure and build metadata to find functionality with public entry points and observable outcomes: command-line tools, pure library functions, and stateful library APIs. It traces dependencies to set the scope, removes the core implementation, and adjusts the remaining code into a coherent starting point. The original is kept aside as the reference solution.

Second, tests grounded in execution. An agent maps each stated requirement to inputs and boundary cases, runs them against a reference copy, and records what happens. Where the statement fixes an output, the reference's output becomes the expected value. Where it leaves something open, the assertion checks only the stated constraint: the required exception type, say, but not the message. A review pass then replaces any restriction the statement does not support, like exact wording or incidental ordering, with a behavioural check. A task is rejected if an assertion depends on a private symbol and has no behavioural substitute.

Third, execution consistency. Each task runs in six fresh containers: two with the starting codebase, which must both fail, and four with the reference in place, which must all pass.

Fourth, filtering by rollouts. The leakage hunt runs, with a separate review of each suspected exploit. Then a coding agent attempts every task four times, and a reviewing agent reads those trajectories alongside the statement and the reference, flagging false positives, where a wrong implementation passes, and false negatives, where a correct one fails. Finally a frontier model makes several attempts, and only tasks with both a success and a failure are kept. All-pass or all-fail could mean a task is too easy, too hard, or still broken, and the outcome alone cannot say which. Roughly one candidate in four survives the whole funnel, leaving five thousand five hundred and forty-five tasks.

MiMo-V2.5 was trained on those tasks with GRPO and a binary reward, and improved on all five external benchmarks. DeepSWE pass rate roughly doubled, from ten percent to twenty-one point seven. On ProgramBench, which asks for whole programs, the share of tasks almost solved rose from four point five to twenty-one point five. Terminal-Bench gained eight and a half points, with code translation and SWE-bench Pro improving too.

The comparison that tests the thesis most directly is about filtering, not scale. The authors also trained on about eight thousand tasks sampled before any cleaning, consistency checks or rollout filtering, with identical settings. The full filtered set beat it on all three evaluations: by four point five nine points on DeepSWE, by four point four nine on the held-out validation tasks, and by only zero point five nine on SWE-bench Pro. Even a filtered subset less than half the size of that unfiltered pool beat it on all three. Within the filtered data, more was better: subsets of increasing size rose steadily on every evaluation.

Behaviour changed too. Between early and late training, read and search calls before the first edit rose from twenty-seven point two to forty point one. Rollouts in which the agent wrote and ran its own checks passed four point two points more often than rollouts on the same task and checkpoint without them, with a confidence interval that excludes zero.

The paper has no limitations section, so the limits here come from what its evidence reports. No repeated training runs are reported, and the benchmark gains carry no error bars. Some gains are small: SWE-bench Pro moved four point one points, and the filtered set's edge over the unfiltered pool there was about half a point. The behaviour findings are associations, not causes, and only the agent's own checks came out clearly; the exploration effect has an interval that spans zero. And the filtering leans on agents judging agents, with no reported human check of how often their judgments are right.

The idea to carry away is that a working function is already a task with its answer attached. Delete it, describe what it does from the outside, and let running the original write the test expectations. Everything else in CodeMidas exists to keep that conversion honest: tests that ask for behaviour rather than wording, containers that must fail before and pass after, and adversaries looking for the copy left behind. The sharper result is that honest tasks matter more than many: a smaller, cleaner set beat a larger pile that skipped the checks.