ProgramGym: Scaling Training Environments for Long-Horizon Program Reproduction Agents
Chengyi Yang, Renxu Bao, Jue Hou, Zongpei Teng, Ziheng Wang, Yujie Lin, Chengsong Huang, Junnan Zhu, Delai Qiu, Yining Wang, Shengping Liu, Fei Long, Jinsong Su
ProgramGym provides a scalable, feedback-driven framework to train coding agents on long-horizon program reproduction from scratch.
How can we build scalable, long-horizon training environments that allow AI agents to learn to reproduce complex software programs from scratch?
Coding agents typically struggle with long-horizon tasks because they lack verifiable environments that force them to discover requirements and design systems from scratch, rather than just patching existing codebases. ProgramGym addresses this by using a feedback-driven pipeline to automatically convert open-source repositories into verifiable training environments, paired with a role-isolated agent workflow that separates analysis, implementation, and review. This approach significantly improves performance on program reproduction, with fine-tuned models exceeding the results of several flagship coding agents on the ProgramBench benchmark.
Paper Primer
Existing coding agents are largely limited to issue-resolution tasks where a codebase is already provided, leaving them unable to handle the "from-scratch" challenge of discovering requirements and architecting a system. ProgramGym solves this by building a "gym" of 1,648 verifiable environments across C, C++, Go, and Rust, where agents must reconstruct observable behavior from a reference executable and documentation.
The framework consists of two core components: Program-Env and Program-Agent. Program-Env is a feedback-driven pipeline that automatically builds reference executables and generates black-box behavioral tests by iteratively refining build scripts and test coverage. Program-Agent is a role-isolated workflow: it decouples the agent into an analyst and an implementer, using persistent handoff artifacts to coordinate long-horizon development while enforcing compilation checks as a gate for every iteration.
Training on ProgramGym environments and using the Program-Agent workflow significantly boosts reproduction performance.
Fine-tuning Qwen3.8-27B on ProgramGym trajectories raised its performance from 34.87% to 42.84% Tests Passed, while the Program-Agent scaffold further pushed the model to 55.71%. The combined approach yields a ~20% absolute improvement in Tests Passed compared to the base model using a standard single-session agent scaffold.
Program-Agent scales performance with additional iteration budget.
Evaluating Qwen3.8-27B-SFT across iteration budgets $K=1, 3, 5$ showed Tests Passed rising from 43.49% to 56.25%. Most performance gains are realized by the third iteration, demonstrating that structured, multi-round development effectively recovers program behavior.
Why is "from-scratch" program reproduction harder than standard issue-resolution tasks like SWE-bench?
Issue-resolution tasks provide a pre-existing codebase and a specific bug or feature request, whereas from-scratch reproduction requires the agent to independently discover what the program does, design the architecture, and implement the functionality without a scaffold.
What is the primary role of the "role-isolated" workflow in Program-Agent?
It prevents cross-stage memory contamination and context noise by separating analysis (evidence collection) from implementation (code generation), ensuring that the agent does not lose early behavioral insights as the context grows over long horizons.
ProgramGym shifts the training paradigm for coding agents from "code-edit assistants" to autonomous software engineers by providing the necessary behavioral supervision for long-horizon, from-scratch development.
Motivation and Problem Framing
We expose why training agents to rebuild full programs demands verifiable, scalable environments.
Training coding agents to reproduce complex software demands environments that can automatically build executables and generate black‑box behavioral tests from existing repositories. Existing pipelines for issue‑resolution or repository generation do not provide the verifiable, long‑horizon supervision needed for full program reconstruction. ProgramGym addresses this gap with a scalable pipeline that constructs such environments and orchestrates agents through analysis, implementation, and review.
Instead of fixing a single bug or generating code from a brief specification, the agent must discover the full set of required behaviors and design the entire program from scratch.
Two core challenges arise. (i) Scaling verifiable training environments requires a feedback‑driven loop that can repair sandbox builds and generate high‑quality black‑box tests across diverse repositories and toolchains. (ii) Sustaining long‑horizon development demands an explicit workflow that preserves behavioral evidence, coordinates implementation, review, and revision, and prevents agents from forgetting earlier requirements as context expands.
The shift from issue‑resolution to full program reproduction unlocks a richer, more realistic training regime for coding agents.
Framework Overview
We introduce ProgramGym, a scalable suite that builds executable environments and black‑box tests for training coding agents.
ProgramGym unifies two components—Program‑Env and Program‑Agent—into a scalable training ecosystem for long‑horizon program‑reproduction agents.
ProgramGym is a toolbox that automatically turns open‑source repositories into self‑contained training environments, each supplying a reference executable, a sandbox, documentation, and a black‑box test suite.
**Figure 1.** The overview of our framework. It consists of three stages: (1) Repository Collection, (2) Executable and Sandbox Generation, and (3) Black-Box Test Construction.
**Figure.** The left panel shows a donut chart representing the distribution of 1,648 tasks across programming environments: Go (49.64%), C++ (22.94%), Rust (18.39%), and C (9.04%). The right panel is a bar chart displaying the "Tests Passed Score on ProgramBench (%)" for various AI models, with bars colored to distinguish between Program-Env (light gray) and Program-Agent (dark green) performance, including dashed arrows indicating performance comparisons between specific models.
The three‑stage pipeline—Collection, Generation, Testing—enables automatic, language‑agnostic construction of verifiable training environments at scale.
Environment Construction
Program-Env builds reproducible sandboxes and black‑box tests for diverse code repositories.
Reproducing arbitrary programs at scale fails when build scripts break and tests miss subtle bugs. Program‑Env tackles this by automating both executable construction and exhaustive black‑box testing.
It is a pipeline that turns a raw code repository into a ready‑to‑run sandbox and a suite of black‑box tests that together define the program’s observable behavior.
Step 1: The collector fixes each repo to a known commit and creates $download.sh$ (no external deps) and $compile.sh$ (runs
Step 2: The outer loop executes $download.sh$ then $compile.sh$; all succeed, yielding executables $B_1^{*}$, $B_2^{*}$, $B_3^{*}$.
Step 3: Each executable is placed in its own sandbox $S_1$, $S_2$, $S_3$ and run once to confirm it prints “hello”.
Step 4: Coverage tools report that the only function
The example shows how a tiny, deterministic codebase flows through the full pipeline, guaranteeing that both build and test generation succeed before scaling to thousands of repositories.
How does Program‑Env differ from a simple CI build system that just compiles code?
CI systems stop after a successful build; Program‑Env continues by instrumenting the executable, generating black‑box tests, and iteratively repairing build scripts until the sandbox and test suite both meet strict validation criteria.
Invoke Claude Code to propose
Run the outer validation loop: if either script fails, return diagnostics to Claude Code for revision.
When both scripts succeed, execute the compiled binary to obtain $B_i^{*}$ and verify loadability.
Package $B_i^{*}$ into a container image $S_i$ with the required toolchain.
Instrument $S_i$ for coverage and expose it to the test‑generation dispatcher.
A black‑box test suite $T_i$ treats the program as an opaque function: it feeds inputs and checks outputs without looking at internal state.
Step 1: Run $B_1^{*}$ on input “0” → “hello”; run $\hat{B}_1$ (agent output) on “0” → “hello”. Pass.
Step 2: Run both on input “1” → “world”; both succeed, but the Dummy check flags that the test does not distinguish $\hat{B}_1$ from a stub that always returns “hello”.
Step 3: The Weak‑assert check notices the test only compares strings, so it adds a new assertion that the program must also return the length of the string.
Step 4: After the agent updates $\hat{B}_1$, the new test input “2” expects output length 5; $\hat{B}_1$ fails, triggering a Pass check failure.
Step 5: The agent revises its implementation, passes all four checks, and the suite $T_1$ is finalized.
The example demonstrates how the four checks collaboratively prune weak or misleading tests, ensuring that $T_i$ truly captures functional behavior.
Why can’t we rely on a single static test suite instead of this iterative feedback loop?
A static suite would miss many execution paths and be vulnerable to trivial “dummy” implementations; the iterative loop discovers uncovered functionality and strengthens assertions, producing a robust behavioral specification.
The Agentic Loop
Program-Agent isolates analyst and implementer roles to iteratively build and verify code.
Single‑session pipelines often discard early behavioral evidence, causing the generated program to fail to compile. This loss of context is the primary obstacle to reliable long‑horizon program reproduction.
Program‑Agent splits the coding task into two isolated roles—analyst and implementer—so each stage works with a clean, read‑only view of the problem, preventing cross‑stage contamination.
How does Program‑Agent differ from a generic coding agent that simply “think‑then‑code” in one go?
A generic agent keeps the entire conversation history in memory, so the implementation stage can inadvertently rely on hidden context. Program‑Agent enforces strict read‑only handoffs and separate sessions, so the implementer can only use the explicit evidence the analyst recorded, which forces a disciplined, reproducible build process.
Analysis: analyst extracts the single requirement “return the sum of two inputs” and stores it as a read‑only line in
Implement (round 1): implementer writes
Review (round 1): analyst executes the test suite, finds the output matches the requirement, and records no revisions.
Since $K=2$, a second Implement round could be used to add optional logging, but the loop terminates early because no revisions are needed.
The example shows that with a tiny $K$ the workflow already guarantees a compilable program, and any further rounds only add optional improvements.
The loop runs a single Analysis stage followed by up to $K$ alternating Implement and Review stages, treating compilation success as the gate that decides whether to continue or roll back.
Why not simply repeat the implementation step until compilation succeeds, without a separate Review stage?
Repeating implementation alone would never expose mismatches between the candidate and the reference program; the Review stage is essential because it translates observed behavioral differences into concrete revision directives that guide the next implementation round.
Iterative implementation loop with a fixed budget $K$.
**Figure 3.** Overview of Program-Agent. The **Analysis** stage explores the usage documentation and reference program to identify behavioral requirements. The **Implement** and **Review** stages then alternate to refine the candidate implementation for a fixed loop budget. Handoff carries behavioral evidence and delivery reports across isolated sessions, Workspace maintains the evolving implementation, and Revisions preserves independently buildable source code for validation and recovery.
Isolating analyst and implementer roles and gating each round by successful compilation yields a stable, reproducible path to long‑horizon program synthesis.
Evaluation and Results
ProgramGym boosts test pass rates, with Program‑Agent adding up to 21 % over Claude Code.
Training coding agents requires environments that can automatically build executables and generate behavioral tests. ProgramGym supplies this pipeline via Program‑Env and Program‑Agent.
Program‑Agent raises Qwen3.8‑27B‑SFT Tests Passed by 21.38 % over Claude Code.
Table 2: Qwen3.8‑27B‑SFT (Claude Code) 42.84 % → 56.25 % (Program‑Agent), $\Delta$ = +21.38 %.
**Table 2.** Results on ProgramBench across models and agent scaffolds. Program-Agent uses $K=5$ implementation rounds. $\Delta$ is relative to the base model with Claude Code.
**Figure 5.** Distributions of code lines, coverage, and test cases in Program-Env.
**Figure 6.** Tests Passed of Qwen3.8-27B-SFT with Program-Agent across different iteration budgets on ProgramBench.
**Figure 7.** Distribution of action types over agent turns. Each task contributes a total weight of one per turn, divided evenly among its tool calls and aggregated by action type. Bar heights decay with turn index because trajectories end at different lengths.
**Figure 12.** Program analysis guiding test writing on COLMAP. Top: coverage feedback (dynamic) steers the agent toward uncovered code in `ply.cc`. Bottom: the call graph (static analysis) reveals a lightweight entry to a target the agent had skipped.
Appendix: Implementation Details
A roadmap of the appendix contents, detailing all components and supplementary analyses.
The appendix is organized into four parts: core methodology (Program‑Env, Program‑Agent), experimental results, and extensive supplementary details. Each part contains subsections that describe data collection, sandbox generation, test construction, iterative workflow, revision management, and additional analyses.
Appendix: FAQ and Filtering
This section details the limits of the dataset collection and build pipeline, and answers common questions.
We first address the most frequent questions that arise when using the collected data and the build pipeline.
Why are there far fewer tasks than collected repositories? Only 1,648 tasks survive out of 30,459 repositories because (i) many repositories cannot be built on Linux, need a display, or exceed the 3,600‑second compilation limit, and (ii) constructing an environment costs about 82.99 M tokens on average, making full‑scale processing infeasible.
Why is the difficulty distribution skewed toward easy tasks? The complexity score $\\xi$ classifies 1,492 tasks as easy, 151 as medium, and only 5 as hard; this is intentional because (i) $\\xi$ measures repository size rather than reproduction difficulty, (ii) extremely hard tasks provide negligible training signal, and (iii) current models still benefit from the easy majority while future pipelines can target harder cases.
Why not report a mean coverage curve over iterations? Subagents terminate at different rounds—some stop after reaching a coverage threshold, others after hitting the round limit—so averaging would bias toward the hardest agents and hide gains from feedback; moreover, coverage is only aggregated at the repository level after all branches finish, so no per‑iteration repository curve exists.
Why can the Implement stage of $\\text{Program\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\!\\
Appendix: Build Process Details
Appendix details build-stage feedback, task decomposition, coverage instrumentation, and sandbox construction.
The build stage validates scripts and binaries, rejecting any attempt that fails to meet strict constraints. Failures are propagated as structured feedback for the next attempt, and the loop aborts after four tries.
**Figure 9.** Build-attempt distribution across programming languages.
Each failure is reported with a template containing the status, error details, and a remediation instruction. Linter findings list the rule, script, and line; execution failures include the log excerpt and a suggested code change.