CodeMidas

• CodeMidas is a pipeline for creating executable reinforcement-learning environments from open-source codebases, generating diverse tasks with natural-language specifications and hidden verifiers, using the functionality in code
• It selects, adapts, and validates tasks from 3,185 open-source codebases across 23 programming languages and 15 technical domains, producing 5,545 training tasks
• By iteratively refining assertions and filtering tasks, CodeMidas ensures the production of high-quality, reliable RL environments, aiding coding agents in learning from a broad range of codebases and programming languages

CodeMidas is an agentic pipeline for constructing executable reinforcement-learning environments for coding agents directly from implemented functionality in open-source codebases. Rather than requiring GitHub issues, pull requests, commits, documentation, or existing tests as task specifications, it selects public functionality, infers externally observable behavior, removes the target implementation, generates execution-grounded tests, validates the resulting environment, and filters tasks through repeated solution rollouts. The resulting tasks contain a natural-language specification, an adapted codebase, and a hidden executable verifier. CodeMidas produced 5,545 training tasks from 3,185 open-source codebases spanning 23 programming languages and 15 technical domains (Ye et al., 18 Sep 2026).

1. Motivation and conceptual basis

Reinforcement learning for coding agents requires diverse tasks, executable environments, and reliable verifiers that distinguish correct from incorrect implementations. Existing environment-construction methods commonly depend on development artifacts such as issues, pull requests, commits, unit tests, synthesized bugs, patches, or documentation. Such artifacts constrain task diversity to functionality that developers reported, modified, documented, or tested.

CodeMidas treats source code itself as the only task-specific input. Existing implementations provide both a behavioral target and a reference implementation whose execution can generate expected test outcomes. The pipeline is consequently able to mine functionality that has no corresponding issue, commit, written specification, or pre-existing test suite.

The method distinguishes specification from implementation. A generated task describes public inputs, observable behavior, interfaces, and relevant constraints, while leaving internal implementation choices open. The intended behavioral contract can involve:

• Process output from command-line programs
• Return values from pure functions
• Exceptions
• Stateful transitions across multiple API calls
• Ordering and cleanup behavior

The source implementation is not presented to the solver. CodeMidas instead removes the selected core functionality while retaining the surrounding repository, dependencies, build resources, and project structure. The original implementation is preserved separately as a reference solution for test generation and validation.

This design addresses a central weakness of executable coding rewards: a reference implementation can exhibit accidental behavior, undocumented quirks, or overly restrictive assumptions. CodeMidas therefore combines reference execution with assertion review, consistency checks, adversarial leakage searches, verifier–solution agreement checks, and rollout-based difficulty filtering.

2. Environment-construction pipeline

Each final CodeMidas task consists of a natural-language task statement, a containerized development environment, and a hidden executable verifier. The solver sees the task statement and adapted codebase but not the verifier or original implementation. The verifier returns a binary reward:

$$r = \begin{cases} 1, & \text{if the submitted implementation passes the hidden verifier},\ 0, & \text{otherwise}. \end{cases}$$

The pipeline has four principal modules.

Functionality selection and adaptation

A design agent explores the repository, its structure, and build metadata to identify functionality with public entry points, observable outcomes, sufficient scope for meaningful reasoning, and dependencies requiring codebase-level understanding. Supported interfaces include command-line programs, pure library functions, and stateful library APIs.

After selecting a target, CodeMidas traces its public entry points, identifies shared dependencies, defines the task boundary, removes the core implementation, and retains the surrounding project context. It also stores the original implementation as a reference solution. The resulting repository is partially implemented and must be completed by the solver.

Behavioral specification inference

A task-generation agent examines the original functionality and writes requirements in terms of externally observable behavior. A specification may require a command to accept particular flags, a function to return specified values, an API sequence to produce a state transition, or a particular exception type.

The specification should not require a private helper, internal data structure, incidental ordering, or exact exception-message wording unless those properties are explicitly part of the public contract. This distinction permits multiple correct implementations rather than requiring reproduction of the original code.

Execution-grounded test construction

A test-construction agent maps each requirement to test cases and executes the original implementation in a reference copy of the repository. Test forms depend on the interface:

Interface	Test form
Command-line program	Shell or process invocations and output checks
Pure function	Input–output examples and property checks
Stateful API	Call sequences, state transitions, ordering, and cleanup

Each test is associated with the requirement it covers. The reference implementation supplies expected values for behavior fixed by the specification, while unspecified properties are not imposed by the verifier.

Assertion review

A second agent reviews every assertion for unsupported restrictions. It removes checks for exact wording, incidental ordering, internal structure, private symbols, or other behavior inherited accidentally from the reference implementation. The revised tests are rerun against the original solution. A task is rejected if an assertion depends on a private symbol and cannot be replaced with a public behavioral check.

3. Execution validation and task filtering

CodeMidas validates candidate environments before adding them to the dataset. Environment preparation begins from a uniform base container. An environment-preparation agent installs dependencies, follows project build declarations, prepares runtime resources, retains required packages and fixtures, and preserves build wrappers needed to execute completed solutions.

Potential implementation leakage is removed, including compiled outputs, caches, construction-agent leftovers, installed copies of the target project, and original tests associated with the removed functionality.

Six-container consistency check

Each candidate task is evaluated in six fresh containers: two contain the incomplete starting codebase and four contain the restored reference implementation. Acceptance requires both starting-state runs to fail and all four reference-solution runs to pass. Tasks are discarded if they pass before implementation, fail with the reference solution, or behave nondeterministically.

This procedure checks both the intended fail-to-pass transition and execution stability. It does not establish complete semantic correctness, because finite tests cannot cover all possible behavior.

Leakage filtering

Adversarial coding-agent rollouts search the solver-visible environment for ways to bypass implementation. The search includes compiled artifacts, caches, construction leftovers, installed project copies, and residual files. A separate reviewer examines evidence of exploitation, and tasks with confirmed leakage are rejected.

Verifier–solution agreement

A coding agent makes four attempts per task. A reviewing agent examines the trajectories, submitted code, test outputs, task statement, verifier, and reference solution. It checks whether the implementation satisfies the stated requirements and whether the verifier agrees.

The process targets false positives, where an incorrect implementation passes, and false negatives, where a correct implementation fails. Tasks with identified verifier defects are rejected.

Mixed-success rollout filtering

A frontier model attempts every candidate task multiple times. CodeMidas retains only tasks for which both successful and failed attempts occur. If $r_i \in \{0,1\}$ denotes the result of rollout $i$, retention requires:

$\exists i,j:\quad r_i=1,\qquad r_j=0.$

All-pass tasks may be too easy or under-tested; all-fail tasks may be too difficult, defective, or incompletely specified. Mixed-success filtering selects tasks that provide a nontrivial learning signal for the screening model, although it also biases the dataset toward that model’s capability boundary.

4. Dataset composition and task structure

The retained dataset contains 5,545 training tasks from 3,185 open-source codebases, covering 23 programming languages and 15 technical domains. The largest language categories are Python, TypeScript, Go, C++, and JavaScript.

Language	Share of tasks
Python	21.4%
TypeScript	18.3%
Go	16.2%
C++	12.5%
JavaScript	11.3%

The ten most frequent languages account for 5,445 tasks, or 98.2% of the training set. The largest technical domains are systems software, web technologies, and developer tools, which together account for 45.6% of tasks.

Reference solution size includes all added or deleted source lines, including comments and blank lines. The median reference size is 142 lines, with an interquartile range of 66–305 lines. At least two source files are touched in 65.9% of tasks, indicating that the collection is predominantly repository-level or multi-file rather than isolated code-completion data.

The 5,545 tasks form the reinforcement-learning training pool. CodeMidas Val contains 200 randomly sampled tasks kept separate from training, with three evaluation attempts per task. The training set is reported to be disjoint from CodeMidas Val and from the five external benchmarks used in evaluation. No separate CodeMidas test set is described.

The task format is conceptual rather than a fully specified serialized schema. Its principal components are:

Component	Solver visibility	Function
Task statement	Visible	Specifies required public behavior
Adapted codebase	Visible	Supplies realistic repository context
Dependencies and build resources	Visible	Enables development and execution
Hidden verifier	Not visible	Produces the execution reward
Original implementation	Not visible	Generates tests and validates the task

5. Reinforcement-learning methodology

CodeMidas trains MiMo-V2.5 using Group Relative Policy Optimization with binary execution rewards. For each task, the policy samples multiple rollouts, and each rollout receives a reward of zero or one according to the hidden verifier. A group-relative advantage is formed by subtracting the mean reward within the rollout group from each individual reward. The reported implementation disables advantage normalization by standard deviation.

The principal training configuration is:

Setting	Value
Training pool	5,545 CodeMidas tasks
Algorithm	GRPO
Reward	Binary verifier outcome
Batch size	32
Rollouts per task	32
Maximum prompt length	8,192 tokens
Maximum response length	516,096 tokens
Maximum turns	500
Maximum staleness	8
Optimizer	Adam
Learning rate	$5 \times 10^{-6}$
Warmup	0 steps
Adam parameters	$(0.95, 0.95)$
Adam $\epsilon$	$10^{-15}$
Gradient clipping	1
Weight decay	0

The paper does not report the total number of optimizer steps, GPU configuration, wall-clock training time, or total FLOPs. It also does not provide all exact GRPO implementation details, including complete prompts, tool APIs, base-container specifications, or per-stage task-retention counts.

6. Evaluation, ablations, and learned behavior

CodeMidas evaluates the initial MiMo-V2.5 policy and RL-trained checkpoints on five external benchmarks: SWE-bench Pro, DeepSWE v1.1, ProgramBench, RepoZero C2Rust, and Terminal-Bench v2.1. ProgramBench uses the Almost Solved metric, defined as the percentage of tasks passing at least 95% of tests; the other reported results are pass rates.

The supplied results are:

Benchmark	Initial policy	CodeMidas RL	Improvement
DeepSWE v1.1	10.0%	21.7%	+11.7 percentage points
ProgramBench Almost Solved	4.5	21.5	+17.0 points
Terminal-Bench v2.1	63.7%	72.2%	+8.5 percentage points

Performance improves on all five external benchmarks, although numerical results for SWE-bench Pro and RepoZero C2Rust are not provided in the supplied text. On CodeMidas Val, the initial pass rate is 35.0% and the RL pass rate is 44.7%.

Dataset-size ablation

Training on larger high-quality task pools improves performance:

Training pool	DeepSWE score	CodeMidas Val
1,000 tasks	17.57	41.30
3,000 tasks	19.05	43.22
5,545 tasks	21.70	44.73

The complete high-quality dataset also outperforms an approximately 8,000-task unfiltered pool by 0.59 points on SWE-bench Pro, 4.59 points on DeepSWE, and 4.49 points on CodeMidas Val. The comparison supports the conclusion that task reliability and suitability matter more than raw task count alone.

Trajectory behavior

CodeMidas analyzes exploration, drafting, and self-verification. Exploration is measured by distinct read or search requests before the first edit. Drafting ratio measures the proportion of sampled code fragments in write or edit operations that already appeared in preceding reasoning. Self-verification counts distinct checking commands after the final repository edit.

Behavior	Early	Late	Change
Pre-edit read/search calls	27.2	40.1	+12.9
Drafting ratio	0.358	0.629	+0.271
Distinct post-edit commands	2.03	2.53	+0.50

The RL-trained agent explores more before editing, exhibits greater overlap between reasoning and written code, and performs more varied verification. On CodeMidas Val, rollouts containing agent-written and executed checks have a mean pass rate 4.2 percentage points higher than rollouts without such checks, with a 95% confidence interval of $[1.8, 6.6]$. The associations for exploration and drafting are weaker.

7. Limitations and significance

CodeMidas’s source-code-only formulation broadens the potential supply of coding-agent tasks, but it does not eliminate specification uncertainty. Behavioral requirements are inferred from existing implementations and may omit relevant behavior, encode undocumented quirks, or fail to identify all valid alternatives. Assertion review mitigates these risks without guaranteeing complete behavioral coverage.

The verifier remains finite and may accept implementations that fail on untested inputs. Reference execution supplies expected behavior but does not prove that the reference implementation is correct, secure, or free of accidental semantics. Mixed-success filtering also selects tasks according to the capabilities of the screening model, potentially excluding very easy, very difficult, or unusually specialized tasks.

The pipeline executes untrusted repositories, dependencies, build scripts, and generated programs. Containerization, cleanup, leakage searches, and execution checks provide safeguards, but the supplied material does not define a complete security threat model or license-compliance procedure. The paper also does not provide a full contamination audit of the pretrained model’s data; it establishes task-set disjointness from CodeMidas Val and the external benchmarks, not complete repository-level pretraining exclusion.

Reproducibility is constrained by unspecified agent prompts, tool APIs, base images, dependency-installation procedures, hardware, wall-clock cost, total optimization steps, exact task serialization, and some GRPO settings. The paper demonstrates that agentic task construction can produce high-quality RL environments and that quality-controlled task scaling improves coding-agent performance, but it does not provide a complete cost–benefit analysis of the construction pipeline.

The central implication of CodeMidas is that implemented software functionality can serve as a scalable source of behavioral specifications, masked repositories, reference executions, and executable rewards:

$$\text{existing code} \rightarrow \text{behavioral task} \rightarrow \text{masked repository} \rightarrow \text{execution-grounded verifier} \rightarrow \text{validated RL environment}.$$

Its reported results indicate transfer across issue repair, whole-program construction, code translation, and terminal-based software work. The accompanying trajectory analysis suggests that training on these environments changes not only task success rates but also coding-agent behavior, particularly repository exploration, planning before editing, and self-verification.