Paper deep dive
Toward Executable Repository-Level Code Generation via Environment Alignment
Ruwei Pan, Junlei Shen, Linhao Wu, Yueheng Zhu, Zixiong Yang, Yakun Zhang, Lu Zhang, Hongyu Zhang
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 96%
Last extracted: 4/10/2026, 2:15:37 AM
Summary
EnvGraph is a framework for repository-level code generation that treats repository executability as an environment alignment problem. It uses a dual-layer environment representation (external dependency graph and internal reference graph) and execution-evidence-based attribution to iteratively guide code revision, significantly outperforming existing baselines in functional correctness and non-functional quality.
Entities (5)
Relation Signals (3)
EnvGraph → uses → Dual-layer environment representation
confidence 100% · It maintains a dual-layer environment representation, uses execution evidence to perform execution-evidence-based attribution
Repository executability → dependson → External dependency satisfaction
confidence 95% · Successful repository execution depends on two coupled conditions: external dependency satisfaction and repository-internal reference resolution.
EnvGraph → improves → Repository-level code generation
confidence 95% · EnvGraph consistently achieves the best performance on these repository-level benchmarks.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Large language models (LLMs) have achieved strong performance on code generation, but existing methods still struggle with repository-level code generation under executable validation. Under this evaluation setting, success is determined not by the plausibility of isolated code fragments, but by whether a generated multi-file repository can be successfully installed, have its dependencies and internal references resolved, be launched, and be validated in a real execution environment. To address this challenge, we propose EnvGraph, a framework for repository-level code generation that formulates repository executability as an environment alignment problem. EnvGraph jointly models two coupled conditions for successful repository execution, namely external dependency satisfaction and repository-internal reference resolution. It maintains a dual-layer environment representation, uses execution evidence to perform execution-evidence-based attribution, and guides repository generation through a unified targeted revision mechanism within an iterative alignment loop. We evaluate EnvGraph on repository-level code generation with three representative backbone LLMs and compare it against representative environment-aware and repository-level baselines. Experimental results show that EnvGraph consistently achieves the best performance on these repository-level benchmarks. In particular, it outperforms the strongest non-EnvGraph baseline by an absolute margin of 5.72--5.87 percentage points in Functional Correctness and 4.58--8.66 percentage points in Non-Functional Quality.
Tags
Links
- Source: https://arxiv.org/abs/2604.03622v1
- Canonical: https://arxiv.org/abs/2604.03622v1
Trouble viewing inline? Open PDF directly →
Full Text
70,675 characters extracted from source content.
Expand or collapse full text
Toward Executable Repository-Level Code Generation via Environment Alignment Ruwei Pan 1,2 Junlei Shen 1 Linhao Wu 2 Yueheng Zhu 1,2 Zixiong Yang 2 Yakun Zhang 3 Lu Zhang 2 Hongyu Zhang 1 ∗ Abstract Large language models (LLMs) have achieved strong performance on code generation, but existing methods still struggle with repository- level code generation under executable validation. Under this evalua- tion setting, success is determined not by the plausibility of isolated code fragments, but by whether a generated multi-file repository can be successfully installed, have its dependencies and internal references resolved, be launched, and be validated in a real execution environment. To address this challenge, we propose EnvGraph, a framework for repository-level code generation that formulates repos- itory executability as an environment alignment problem. EnvGraph jointly models two coupled conditions for successful repository execu- tion, namely external dependency satisfaction and repository-internal reference resolution. It maintains a dual-layer environment represen- tation, uses execution evidence to perform execution-evidence-based attribution, and guides repository generation through a unified tar- geted revision mechanism within an iterative alignment loop. We evaluate EnvGraph on repository-level code generation with three representative backbone LLMs and compare it against representative environment-aware and repository-level baselines. Experimental re- sults show that EnvGraph consistently achieves the best performance on these repository-level benchmarks. In particular, it outperforms the strongest non-EnvGraph baseline by an absolute margin of 5.72– 5.87 percentage points in Functional Correctness and 4.58–8.66 percentage points in Non-Functional Quality. CCS Concepts • Software and its engineering→Software creation and manage- ment. Keywords Environment-aware Code Generation, Large Language Models, End- to-end Code Generation ACM Reference Format: Ruwei Pan 1,2 Junlei Shen 1 Linhao Wu 2 Yueheng Zhu 1,2 Zixiong Yang 2 , [2pt] Yakun Zhang 3 Lu Zhang 2 Hongyu Zhang 1 . 2026. Toward Executable Repository-Level Code Generation via Environment Alignment. In . ACM, New York, NY, USA, 11 pages. https://doi.org/10.1145/n. n 1 Introduction Large language models (LLMs) have substantially advanced code generation and have achieved strong performance on tasks ranging ∗1 Chongqing University 2 Peking University 3 Harbin Institute of Technology (Shenzhen) Conference’17, Washington, DC, USA 2026. ACM ISBN 978-x-x-x-x/Y/M https://doi.org/10.1145/n.n from function completion to repository-level code completion [11, 18,19,33]. As code generation moves beyond single functions and files toward repository-level generation, models are increasingly required to construct complete multi-file repositories from high-level requirements [4]. Under this evaluation setting, the objective is no longer merely to generate plausible code fragments, but to deliver an executable repository that can be successfully installed, satisfy its external dependencies, resolve its internal references, be launched, and be validated in a real execution environment. Therefore, ensuring repository executability becomes a fundamental prerequisite for repository-level code generation [7]. However, ensuring repository executability in repository-level generation remains fundamentally challenging [19,33]. In repository- level generation, execution failures are not solely caused by logic faults. Many failures instead arise because the generated repository is not yet aligned with the execution conditions required for end-to- end validation. More specifically, successful repository execution depends on two coupled conditions: external dependency satisfaction and repository-internal reference resolution. External dependency satisfaction requires third-party libraries, version constraints, and API migration requirements to be compatible with the target envi- ronment [14,30]. Repository-internal reference resolution requires files, modules, imports, and symbol references within the reposi- tory to remain consistently connected and resolvable. As a result, repository execution may fail because the external execution context is unsatisfied, because repository-internal references are broken, or because both conditions are violated. The key challenge, there- fore, is not merely to observe execution failure, but to determine which failure source is currently dominant under real execution conditions. Existing work has addressed this challenge from two main direc- tions. One line of work incorporates external execution constraints into code generation by modeling library versions, API compatibility, and migration requirements [5,14,30,35]. These methods improve awareness of external compatibility constraints. However, they are mainly designed to make generated code compatible with external libraries, versions, and APIs. They do not explicitly distinguish whether a surfaced execution failure is caused mainly by unsatisfied external dependencies or by broken repository-internal references. Another line of work improves repository-level generation through planning, executable validation, and structural reasoning across files and components [1,8,23]. These methods strengthen repository- level reasoning and often use execution feedback to continue revision. However, they typically treat surfaced execution signals as cues for further revision, rather than as evidence for identifying the currently dominant failure source. Consequently, later revisions may be guided mainly by surfaced execution symptoms rather than by a diagnosis of the dominant source of misalignment, which can lead to misdirected refinement and inefficient iteration. arXiv:2604.03622v1 [cs.SE] 4 Apr 2026 Conference’17, July 2017, Washington, DC, USA Ruwei Pan 1,2 Junlei Shen 1 Linhao Wu 2 Yueheng Zhu 1,2 Zixiong Yang 2 Yakun Zhang 3 Lu Zhang 2 Hongyu Zhang 1 To address these limitations, we propose EnvGraph, a framework for repository-level code generation that formulates repository gener- ation as an iterative process of environment alignment. The core idea is to jointly model external dependency satisfaction and repository- internal reference resolution, perform attribution based on execution evidence, and guide subsequent generation accordingly. Specifically, EnvGraph maintains a dual-layer environment representation to jointly capture the two major sources of repository executability failure. One layer models external dependency satisfaction by cap- turing dependency requirements, inferred third-party packages, and compatibility constraints exposed during execution. The other mod- els repository-internal reference resolution by capturing repository structure, import and reference relations, and unresolved repository- internal references. Given build results, runtime errors, stack traces, and test outcomes, EnvGraph identifies the dominant source of misalignment and uses this diagnosis to guide the next generation iteration. By continuously updating the environment representation and execution evidence, EnvGraph forms an iterative alignment loop for repository-level code generation. We evaluate EnvGraph on repository-level code generation across multiple backbone LLMs and compare it against representative environment-aware and repository-level baselines. Results show that EnvGraph consistently improves both functional correctness and non-functional quality under realistic validation settings. In particular, EnvGraph outperforms the strongest non-EnvGraph baseline by 5.72–5.87 points in functional correctness and by 4.58–8.66 points in non-functional quality across different backbone models. Additional ablation and error analyses further reveal the contribution of each component and the remaining limitations of EnvGraph. In summary, this paper makes the following contributions: • We reformulate repository-level code generation as an environment alignment problem and show that repository executability depends on both external dependency satisfaction and repository-internal reference resolution. •We propose EnvGraph, a framework for repository-level code generation that jointly models these two conditions, performs execution-evidence-based attribution to identify the dominant source of misalignment, and improves generation through an iterative alignment loop. •EnvGraph consistently outperforms representative environment- aware and repository-level baselines across multiple backbone LLMs. In particular, it surpasses the strongest non-EnvGraph baseline by 5.72–5.87 points in functional correctness and by 4.58– 8.66 points in non-functional quality under realistic validation settings. We further provide detailed ablation studies and error analyses. 2 Motivating Example Figure 1 shows a motivating example of repository-level code gener- ation under executable validation. The generated repository appears plausible at first glance: it contains multiple files, the main compo- nents are present, and the overall structure looks reasonable. However, passing a structural inspection does not guarantee repository exe- cutability. In this example, the repository still fails during execution with a ModuleNotFoundError. config src __init__.py client.py requirements.txt ... Generated Repository Terminal Issue: Plausible but not yet executable. $ python main.py Traceback (most recent call last): File "__init__.py", line 3, in <module> from app.client import APIClient File "src/client.py", line 2, in <module> import requests ModuleNotFoundError: No module named 'requests' LLMs LLMs $ python main.py Traceback (most recent call last): File "__init__.py", line 3, in <module> from app.client import APIClient File "src/client.py", line 2, in <module> import requests ModuleNotFoundError: No module named 'requests' $ python main.py Traceback (most recent call last): File "__init__.py", line 3, in <module> from app.client import APIClient File "src/client.py", line 2, in <module> import requests ModuleNotFoundError: No module named 'requests' Environment Graphs Execution Evidence Terminal $ python main.py .......All Passed! Codebase FAILURE ATTRIBUTION: Observed failure: ModuleNotFoundError Possible causes: (1) external dependency satisfaction is not met (2) repository-internal reference resolution is broken Priority: address the dominant source of misalignment first Figure 1: A motivating example of repository-level code genera- tion under executable validation. The same execution symptom may arise from unmet external dependencies, broken repository- internal references, or both. The difficulty is that this failure symptom does not by itself reveal why execution fails. The sameModuleNotFoundErrormay indicate that external dependency satisfaction is not achieved because a required third-party package is unavailable in the current environment. It may also indicate that repository-internal reference resolution is broken because an internal module path, import relation, or file-level reference is not correctly resolved. In other words, the same observed failure can arise from two different sources of misalignment, or from their interaction. This ambiguity easily misleads generic generate–execute–revise pipelines. As illustrated in the upper part of Fig. 1, a baseline method can observe the failure and continue revising the repository, but the symptom alone does not indicate which problem should be addressed first. The method may keep modifying local code or import statements while the real issue is that the required external dependency is still unavailable. It may also keep revising dependency-related artifacts while the actual problem lies in broken repository-internal references. In both cases, subsequent revisions follow the visible symptom rather than the dominant source of misalignment, causing iteration to proceed in the wrong direction and preventing repository executability from being established. In contrast, EnvGraph does not treat the observed failure as an un- differentiated bug. Instead, it interprets execution evidence together with environment graphs to perform execution-evidence-based attri- bution. Specifically, EnvGraph determines whether the dominant source of misalignment lies in external dependency satisfaction or repository-internal reference resolution, and then performs targeted repository revision accordingly. As illustrated in the lower part of Fig. 1, this design helps the next iteration move toward the correct revision direction rather than repeatedly reacting to surface execution symptoms. This example highlights the central motivation of our work: in repository-level code generation, the key challenge is not merely to observe execution failure, but to identify the dominant source of Toward Executable Repository-Level Code Generation via Environment AlignmentConference’17, July 2017, Washington, DC, USA External only Internal only Both 0 20 40 60 Failure cases (%) 3.0% 29.7% 2.0% GPT-5 External only Internal only Both 0.0% 67.0% 1.9% DeepSeek-V3 External only Internal only Both 2.1% 26.8% 2.1% Gemini-3-Pro External onlyInternal onlyBoth Figure 2: Environment-related failure types in failed direct generations on NL2Repo-Bench. misalignment behind that failure. This observation motivates our formulation of repository-level code generation as an environment alignment problem. Motivating empirical study. To examine whether failed repository- level generations already exhibit environment-related misalignment, we analyze all failed direct generations from GPT-5, DeepSeek- V3, and Gemini-3-Pro-Preview on NL2Repo-Bench [4]. For each failed repository, we inspect the generated repository together with dependency manifests, import structure, build logs, runtime errors, and test outcomes. We then manually annotate whether the failure involves external dependency mismatches only, repository-internal reference resolution failures only, or both. Main results. Fig. 2 shows that environment-related failures ac- count for 34.7%, 68.9%, and 30.9% of failed direct generations for GPT-5, DeepSeek-V3, and Gemini-3-Pro-Preview, respectively. These results directly support our motivation. In failed direct gen- erations, environment-related failures arise not only from external dependency mismatches, but also, and more often, from repository- internal reference resolution failures. This suggests that repository executability in full-repository generation cannot be reduced to de- pendency installation alone. Instead, it depends on two coupled conditions: external dependency satisfaction and repository-internal reference resolution. This observation motivates our formulation of repository-level code generation as an environment alignment problem. 3 Approach 3.1 Overview We study repository-level code generation from high-level natural- language requirements. Given a natural-language requirement푄, the goal is to generate a complete multi-file repository푅that satis- fies executable validation under a target execution setting. In this setting, success is determined by repository executability of the generated repository as a whole, rather than by the local plausi- bility of individual files. We formulate repository executability as an environment alignment problem between the current repository and its execution environment. Successful repository execution de- pends on two coupled conditions: external dependency satisfaction and repository-internal reference resolution. The former concerns whether third-party dependencies, version constraints, and environ- ment requirements can be satisfied, while the latter concerns whether files, modules, imports, and references within the repository are con- sistently connected and resolvable. Because failure in one condition Algorithm 1 Iterative environment alignment in EnvGraph Input:high-level natural-language requirement푄, initial repository 푅 0 , executable validation settingV, revision budget 퐵 [Executability State] external environment graph퐺 ext , repository dependency graph 퐺 int [Execution Evidence] evidence set 퐸 ←∅ Output: final repository 푅 final 1 푅 ← 푅 0 # Phase I: Environment Representation Initialization 2 (퐺 ext ,퐺 int ) ← BuildEnv(푅) 3 for 푡= 1 to 퐵 do # Phase I: Execution and Evidence Collection 4 퐸 ← ExecRepo(푅,V) 5 if PassExec(푅,퐸,V) then 6푅 final ← 푅 7return 푅 final 8 end if # Phase I: Dominant Misalignment Attribution 9 푠 ← Attribute(퐺 ext ,퐺 int ,퐸) 푠 ∈ unmet external dependency satisfaction, broken repository-internal reference resolution, residual logic faults # Phase IV: Targeted Repository Revision 10 푅 ← Revise(푅,퐺 ext ,퐺 int ,퐸,푠) // a unified revision step whose focus is conditioned on 푠 # Phase V: Executability State Update 11 (퐺 ext ,퐺 int ) ← BuildEnv(푅) 12 end for # Phase VI: Final Output 13 푅 final ← 푅 14 return 푅 final may mask, trigger, or amplify failure in the other, the two conditions must be reasoned about jointly. Based on this formulation, EnvGraph follows an iterative work- flow. Starting from an initial repository푅 0 , it builds a dual-layer environment representation consisting of an external environment graph and a repository dependency graph, executes the current repos- itory, collects execution evidence, identifies the dominant source of misalignment, and performs targeted repository revision accordingly. The attribution step considers three possible sources: unmet external dependency satisfaction, broken repository-internal reference resolu- tion, and residual logic faults. This process repeats until the repository satisfies executable validation or the revision budget퐵is exhausted. Figure 3 illustrates the overall workflow, and Algorithm 1 summarizes the corresponding control logic. The following subsections describe the dual-layer environment representation, execution-evidence-based attribution, targeted repository revision, and iterative alignment loop in detail. 3.2 Dual-Layer Environment Representation To operationalize repository executability as environment alignment, EnvGraph maintains a dual-layer environment representation as the executability state of the current repository. This representation does not decompose repository failures into isolated subproblems. Instead, it jointly models the two coupled conditions that determine whether Conference’17, July 2017, Washington, DC, USA Ruwei Pan 1,2 Junlei Shen 1 Linhao Wu 2 Yueheng Zhu 1,2 Zixiong Yang 2 Yakun Zhang 3 Lu Zhang 2 Hongyu Zhang 1 config src __init__.py client.py requirements.txt ... Generated Repository Terminal Issue: Plausible but not yet executable. $ python main.py Traceback (most recent call last): File "__init__.py", line 3, in <module> from app.client import APIClient File "src/client.py", line 2, in <module> import requests ModuleNotFoundError: No module named 'requests' LLMs LLMs $ python main.py Traceback (most recent call last): File "__init__.py", line 3, in <module> from app.client import APIClient File "src/client.py", line 2, in <module> import requests ModuleNotFoundError: No module named 'requests' $ python main.py Traceback (most recent call last): File "__init__.py", line 3, in <module> from app.client import APIClient File "src/client.py", line 2, in <module> import requests ModuleNotFoundError: No module named 'requests' Environment Graphs Execution Evidence Terminal $ python main.py .......All Passed! Codebase FAILURE ATTRIBUTION: Observed failure: ModuleNotFoundError Possible causes: (1) external dependency satisfaction is not met (2) repository-internal reference resolution is broken Priority: address the dominant source of misalignment first NL Requirements Generate a complete Python client repository for a web service that can be executed to send requests and handle responses ... config src __init__.py client.py requirements.txt ... Generated Repository Dual-Layer Environment Representation Execution Evidence Dominant Source of Misalignment External Environment Graph Repository Dependency Graph Target Revision The nodes represent the project, repository files, and Python packages used by the current repository. The edges represent project-file containment and file-package import relations. The nodes represent files, modules, symbols, external module references, and parse-error nodes. The edges represent relations such as module definition, module import, internal import, symbol reference, module dependency, and parse-error linkage. Iterative Alignment Loop DECISION RULES: 1. Direct Reuse if the historical-best repository has a full functional score. 2. Start a New Run otherwise 3. Fall Back if the new repository does not outperform the historical -best repository. Figure 3: Overview of EnvGraph. Starting from an initial repository, EnvGraph builds a dual-layer environment representation, executes the repository, collects execution evidence, identifies the dominant source of misalignment, and performs targeted repository revision in an iterative alignment loop. the repository can be successfully executed under the target validation setting: external dependency satisfaction and repository-internal reference resolution. The first layer captures whether the external packages required by the repository are available and consistently declared. The second layer captures whether repository files, modules, and symbols are consistently connected and resolvable. Together, these two layers provide the structural basis for subsequent execution- evidence-based attribution and targeted repository revision. 3.2.1 External environment graph. The external environment graph, denoted by퐺 ext =(푉 ext ,퐸 ext ), models external dependency satisfac- tion. In our implementation,푉 ext contains a project node, repository file nodes, and external package nodes. We construct퐺 ext by scanning repository files, extracting import statements, and reading depen- dency declarations from repository manifests when available. The resulting edges encode project–file containment and file–package im- port relations, while each package node records whether the package is used in code and whether it is explicitly declared in the repository configuration. Through this construction,퐺 ext captures whether the external packages required by the current repository are available and consistently declared under the target execution setting. An example. Figure 4 shows a concrete example based on the gener- ated repositoryClient. The project node is connected to repository file nodes such asmain.py,src/__init__.py,src/client.py, andrequirements.txt. The file nodesrc/client.pyis connected to the package noderequeststhrough a file–package import relation. Because the package node is marked asused_in_code=truebut declared=false, the graph directly exposes that the repository de- pends on an external package required by the code but missing from the repository declaration. This provides a structural explanation for the observed ModuleNotFoundError during execution. Project node: - __PROJECT__ File nodes: - file:main.py - file:src/__init__.py - file:src/client.py - file:requirements.txt Package nodes: - requests (used_in_code=true, declared=false) Representative edges: - __PROJECT__ -> file:src/client.py (project_contains_file) - __PROJECT__ -> file:requirements.txt (project_contains_file) - file:src/client.py -> requests (file_imports) File nodes: - file:main.py - file:src/__init__.py - file:src/client.py Module nodes: - module:src - module:src.client Symbol nodes: - symbol:src.client:APIClient Unresolved internal module refs: - module:app.client Representative edges: - file:src/__init__.py -> module:src (defines_module) - file:src/client.py -> module:src.client (defines_module) - module:src.client -> symbol:APIClient (defines_symbol) - file:main.py -> module:app.client (imports_internal / unresolved) Figure 4: Example of the external environment graph for reposi- tory Client, showing unmet external dependency satisfaction. 3.2.2 Repository dependency graph. The repository dependency graph, denoted by퐺 int =(푉 int ,퐸 int ), models repository-internal ref- erence resolution. In our implementation,푉 int contains file nodes, module nodes, symbol nodes, unresolved module reference nodes, and parse-error nodes. We construct퐺 int by parsing repository files, extracting module definitions, import relations, and symbol ref- erences, and explicitly materializing unresolved imports or parse failures when they occur. The resulting edges encode file–module def- inition, module–module import, module–symbol definition, symbol reference, and module dependency relations. Through this construc- tion,퐺 int captures whether repository files, modules, and symbols are consistently connected and resolvable during execution. Toward Executable Repository-Level Code Generation via Environment AlignmentConference’17, July 2017, Washington, DC, USA Project node: - __PROJECT__ File nodes: - file:main.py - file:src/__init__.py - file:src/client.py - file:requirements.txt Package nodes: - requests (used_in_code=true, declared=false) Representative edges: - __PROJECT__ -> file:src/client.py (project_contains_file) - __PROJECT__ -> file:requirements.txt (project_contains_file) - file:src/client.py -> requests (file_imports) File nodes: - file:main.py - file:src/__init__.py - file:src/client.py Module nodes: - module:src - module:src.client Symbol nodes: - symbol:src.client:APIClient Unresolved internal module refs: - module:app.client Representative edges: - file:src/__init__.py -> module:src (defines_module) - file:src/client.py -> module:src.client (defines_module) - module:src.client -> symbol:APIClient (defines_symbol) - file:main.py -> module:app.client (imports_internal / unresolved) Figure 5: Example of the repository dependency graph for repositoryClient, showing broken repository-internal reference resolution caused by an unresolved internal module reference. An example. Figure 5 shows the corresponding repository depen- dency graph for the same repository. In this graph,src/__init__.py defines the internal modulesrc,src/client.pydefines the internal modulesrc.client, andsrc.clientfurther defines the symbol APIClient. However,main.pystill imports the unresolved internal module referenceapp.client, which cannot be matched to any defined internal module node in the repository. As a result, the graph directly exposes broken repository-internal reference resolution, even though the repository may still appear structurally plausible at a coarse level. These two layers must be maintained jointly. In theClient example, the external environment graph explains why execution fails becauserequestsis required but not declared, whereas the repository dependency graph shows that execution may still fail even after the missing package is added becausemain.pyrefers to the unresolved internal moduleapp.client. This coupling is exactly why EnvGraph uses the two graphs jointly for subsequent execution- evidence-based attribution and targeted repository revision. 3.3 Execution-Evidence-Based Attribution Raw evidence and normalization. EnvGraph executes the current repository푅and collects execution evidence, including dependency installation failures, runtime errors, stack traces, and test outcomes. It then uses an LLM to normalize these heterogeneous signals, together with퐺 ext ,퐺 int , and the current executability state, into a fixed evidence schema. The LLM is used only for evidence normalization, not for the final attribution decision. The full normalization schema, prompt template, and validation rules are provided in our anonymous repository. Attribution policy. EnvGraph applies an explicit policy over the normalized evidence to determine one dominant failure source. If the repository cannot obtain a satisfiable external execution context, the failure is attributed to failure of external dependency satisfaction. Otherwise, if unresolved internal file-, module-, or symbol-level references remain, the failure is attributed to repository-internal refer- ence resolution failure. If neither condition holds and the repository can already be installed and launched but still fails executable valida- tion, the failure is attributed to residual logic faults. When multiple signals co-occur, EnvGraph resolves the ambiguity according to the prerequisite structure of executable validation: failure of external dependency satisfaction>repository-internal reference resolution failure>residual logic faults, since upstream external and internal failures can mask downstream logic faults. 3.4 Targeted Repository Revision Unified revision. Once the dominant source of misalignment has been identified, EnvGraph performs a unified targeted repository revision step. Rather than decomposing revision into separate repair pipelines, EnvGraph uses a single revision mechanism whose focus is conditioned on the current executability state and the attributed source of misalignment. In this way, repository revision is not treated as a generic post-hoc correction step, but as a directed continuation of repository-level code generation toward repository executability. State-conditioned focus. Under different dominant sources of misalignment, the same revision mechanism prioritizes different aspects of the repository. When the dominant source is unmet external dependency satisfaction, revision focuses on dependency- related inconsistencies that prevent the repository from obtaining a satisfiable external execution context. When the dominant source is broken repository-internal reference resolution, revision focuses on restoring the connectivity and resolvability of repository files, modules, and symbols. When the repository has largely achieved environment alignment but still fails executable validation, revision shifts its focus to residual logic faults and prioritizes implementation- level correction while preserving the already aligned dependency and structural conditions as much as possible. Graph-guided refinement. The two graphs are used not only to determine the revision direction, but also to guide the revision itself. The external environment graph highlights dependency-related inconsistencies between package usage and package declaration, while the repository dependency graph highlights unresolved internal module references, broken symbol links, missing definitions, and parse failures. As a result, the same revision process is able to focus on the most critical inconsistency under the current executability state, thereby reducing ineffective corrections and more directly advancing repository executability. 3.5 Iterative Alignment Loop State-dependent process. Repository executability is inherently state- dependent rather than being established in a single step. Revising one aspect of the current repository may expose previously hidden failures in another, and the dominant source of misalignment may therefore change across iterations. For this reason, EnvGraph organizes repository-level code generation as an iterative alignment loop rather than as a one-shot revision procedure. Loop execution. In each iteration, EnvGraph updates the dual- layer environment representation of the current repository, executes the repository under the target validation setting, collects execution evidence, attributes the dominant source of misalignment, and then performs targeted repository revision. The revised repository then Conference’17, July 2017, Washington, DC, USA Ruwei Pan 1,2 Junlei Shen 1 Linhao Wu 2 Yueheng Zhu 1,2 Zixiong Yang 2 Yakun Zhang 3 Lu Zhang 2 Hongyu Zhang 1 becomes the current state for the next iteration. In this way, the generation process remains grounded in the current executability state rather than in stale observations from earlier revisions. Stopping conditions. The loop terminates in one of two cases. The first is successful termination, in which the repository satisfies executable validation and is returned as the final output. The second is budget-limited termination, in which the predefined revision budget is exhausted before repository executability is established. By repeatedly updating the repository state, execution evidence, and attributed source of misalignment together, EnvGraph progressively advances the repository toward executability. 4 Experiments and Results We evaluate EnvGraph by defining the following research questions (RQs) and outlining how we answer them: •RQ1. How effective is EnvGraph for repository-level exe- cutable code generation compared with existing approaches? We compare EnvGraph with representative baselines across diverse backbone LLMs to assess its overall effectiveness. •RQ2. What are the individual contributions of the key com- ponents in the environment alignment design of EnvGraph? We conduct ablation studies on the external environment graph, the repository dependency graph, execution-evidence-based at- tribution, and the iterative alignment loop to examine how each component contributes to the overall effectiveness of EnvGraph. •RQ3. What do the remaining failure cases reveal about the current limitations of EnvGraph? We analyze the major cate- gories of remaining failures to understand which repository-level problems are still difficult after environment alignment. 4.1 Experiment Settings Benchmarks. Following prior repository-level code generation works, we conduct comprehensive experiments on two benchmarks: RAL- Bench [25] and NL2Repo-Bench [4]. Both benchmarks evaluate repository-level code generation under executable validation settings, but they emphasize different aspects of the task. RAL-Bench focuses on complete repository generation from a core natural language requirement and evaluates both functional correctness and non- functional quality attributes using black-box system tests. NL2Repo- Bench focuses on long-horizon repository generation from a single requirements document and evaluates generated repositories using the upstream pytest suites of target projects. The statistics of these benchmarks are summarized in Table 1. In our experiments, generated repositories are executed and evaluated using the corresponding benchmark protocols and test suites. Metrics. RAL-Bench and NL2Repo-Bench use different evalua- tion protocols, and we therefore report benchmark-specific metrics. On RAL-Bench, we report functional correctness and non-functional quality. Functional correctness is measured by the functional test pass rate. For non-functional quality, following the ISO/IEC 25010 quality model [6], we aggregate five normalized dimensions, namely maintainability (lower-bound MI from static analysis [21,22]), secu- rity (high-risk static-analysis findings), robustness (robustness-suite pass rate), efficiency (reference-normalized runtime), and resource usage (reference-normalized RSS memory and CPU usage), using AHP-derived weights. Formally, if푠 푖 denotes the normalized score of the푖-th dimension and푤 푖 denotes its AHP-derived weight, the final non-functional score is computed as푄 nf = Í 푖 푤 푖 푠 푖 , where Í 푖 푤 푖 = 1 . This design complements functional correctness by capturing repos- itory quality beyond test passing alone. On NL2Repo-Bench, we report functional correctness only, measured by the functional test pass rate under the benchmark-provided upstream pytest suites. We do not introduce an additional non-functional score on this benchmark because its protocol is designed primarily for long-horizon repository generation under executable validation. Detailed metric definitions, normalization formulas, and AHP derivation are provided in our repository. Comparative Methods. We compare EnvGraph with representa- tive baselines from two closely related directions: environment-aware code generation and repository-level code generation. Although these two directions partially overlap, we group baselines according to their primary modeling focus. The first direction explicitly models external execution constraints, such as library versions and API mi- gration requirements. The second direction improves repository-level generation through planning, executable validation, and structural reasoning. Environment-aware code generation. This line explicitly in- corporates environment constraints into code generation, primarily by modeling external conditions such as library versions, API com- patibility, and migration requirements. We consider the following representative baselines. •VersiCode [30] treats library versions as explicit generation con- straints and supports version-aware code generation and editing. •APIMig [14] addresses repository-level API migration across mul- tiple library versions by combining an API evolution knowledge graph with chain exploration. Repository-level code generation. This line advances code gen- eration beyond single functions or files by strengthening repository- level planning, executable validation, and structural reasoning. We consider the following representative baselines. •CodePlan [1] formulates repository-level code generation as a planning problem and addresses it with a task-agnostic framework that synthesizes a multi-step chain of edits. • Repo2Run [8] focuses on executable repository construction through iterative environment building, Dockerfile generation, test execution, and execution-driven output revision. Among prior repository-level methods, it is the closest baseline to our setting because it explicitly incorporates runnable-environment construction into repository-level generation. •RepoGraph [23] introduces an explicit repository-level struc- tural representation to support repository-wide navigation and reasoning in code generation. Implementation details. We instantiate EnvGraph with GPT- 5-2025-08-07, DeepSeek-V3.2, and Gemini-3-Pro-Preview. Unless otherwise specified, we use the default context window of each model and adopt greedy decoding by setting the temperature to 0. According to prior work [20], the maximum number of iterations is set to 4 for EnvGraph and other iterative refinement-based baselines. To ensure a fair comparison, all approaches are given the same problem descriptions for code generation. The generated repositories are then executed and evaluated under the corresponding bench- mark protocols. This setup ensures that different approaches receive Toward Executable Repository-Level Code Generation via Environment AlignmentConference’17, July 2017, Washington, DC, USA Table 1: Statistics of the benchmarks used in our evaluation. Benchmark#TasksCategoriesInputKey Characteristics RAL-Bench387NL requirement 450+ evaluation points; evaluates both functional correctness and non- functional quality NL2Repo-Bench1049Single requirements documentAvg. input length≈ 18.8k tokens; Easy/Medium/Hard = 26/46/32 Table 2: Comparison of repository-level code generation methods on RAL-Bench under different backbone models. Functional and Non-functional denote Functional Correctness and Non- Functional Quality, respectively. Numbers are percentages. Gray numbers in parentheses indicate absolute changes relative to Direct under the same backbone. Red rows report its relative improvement over the best non-EnvGraph baseline. ModelMethodFunctional Non-functional GPT-5-2025-08-07 Direct42.3258.26 CodePlan52.39 (+10.07)59.01 (+0.75) Repo2Run40.48 (-1.84)56.26 (-2.00) RepoGraph49.33 (+7.01)58.93 (+0.67) APIMig41.31 (-1.01)49.30 (-8.96) VersiCode39.37 (-2.95)54.20 (-4.07) EnvGraph55.43 (+13.11)64.12 (+5.86) Imp.%+5.80%+8.66% DeepSeek-V3.2 Direct27.2352.16 CodePlan30.86 (+3.62)53.32 (+1.16) Repo2Run30.12 (+2.89)52.88 (+0.72) RepoGraph29.24 (+2.00)43.10 (-9.06) APIMig25.23 (-2.00)31.52 (-20.64) VersiCode21.35 (-5.88)26.74 (-25.42) EnvGraph32.62 (+5.39)55.76 (+3.61) Imp.%+5.72%+4.58% Gemini-3-Pro-Preview Direct38.5555.10 CodePlan42.92 (+4.37)51.41 (-3.69) Repo2Run35.80 (-2.75)45.87 (-9.23) RepoGraph32.25 (-6.30)24.78 (-30.32) APIMig42.71 (+4.15)34.38 (-20.72) VersiCode32.80 (-5.75)41.24 (-13.86) EnvGraph45.44 (+6.89)59.47 (+4.37) Imp.%+5.87%+7.93% consistent external feedback, thereby enabling fair and rigorous comparison. 4.2 RQ1: Overall Performance Comparison The main results on RAL-Bench are reported in Table 2. Across all three backbone models, EnvGraph consistently achieves the best performance on both Functional Correctness and Non-Functional Quality. Compared with Direct, EnvGraph improves Functional Correctness by 13.11, 5.39, and 6.89 points on GPT-5-2025-08- 07, DeepSeek-V3.2, and Gemini-3-Pro-Preview, respectively. It also improves Non-Functional Quality by 5.86, 3.61, and 4.37 points under the three backbones. Compared with the strongest non-EnvGraph baseline, which is CodePlan under all three backbones, EnvGraph still achieves consistent relative gains, reaching 5.80%–5.87% in Table 3: Comparison of methods for repository-level code genera- tion on NL2Repo-Bench under different backbone models. Imp.% denotes relative improvement over the best non-EnvGraph base- line. Method OverallEasyMediumHard Score (%) (≤1.5k LOC) (1.5k–4k LOC) (≥4k LOC) GPT-5-2025-08-07 Direct21.738.420.79.6 CodePlan30.0 (+8.3)50.2 (+11.8)29.6 (+8.9)14.2 (+4.6) Repo2Run 30.0 (+8.3)50.4 (+12.0)29.5 (+8.8)14.2 (+4.6) RepoGraph29.2 (+7.5)51.3 (+12.9)28.0 (+7.3)12.9 (+3.3) APIMig30.6 (+8.9)47.2 (+8.8)30.8 (+10.1)17.0 (+7.4) VersiCode28.0 (+6.3)47.3 (+8.9)26.2 (+5.5)15.0 (+5.4) EnvGraph33.2 (+11.5)48.0 (+9.6)33.2 (+12.5)21.3 (+11.7) Imp.%+8.4%-6.4%+7.8%+25.3% DeepSeek-V3.2 Direct25.033.622.88.8 CodePlan23.3 (-1.8)32.1 (-1.5)22.4 (-0.4)7.1 (-1.7) Repo2Run28.6 (+3.6)39.8 (+6.2)27.5 (+4.7)8.8 (+0.0) RepoGraph23.3 (-1.7)32.1 (-1.5)22.5 (-0.3)7.9 (-0.9) APIMig22.3 (-2.7)32.0 (-1.6)21.6 (-1.2)5.9 (-2.9) VersiCode25.8 (+0.8)33.6 (+0.0)23.7 (+0.9)9.5 (+0.7) EnvGraph28.9 (+3.9)33.2 (-0.4)29.9 (+7.1)16.1 (+7.3) Imp.%+1.0%-16.6%+8.7%+69.5% Gemini-3-Pro-Preview Direct34.244.940.916.8 CodePlan42.0 (+7.8)50.8 (+5.9)46.6 (+5.7)28.2 (+11.4) Repo2Run43.0 (+8.8)51.0 (+6.1)46.9 (+6.0)30.3 (+13.5) RepoGraph42.2 (+8.0)49.9 (+5.0)45.8 (+4.9)29.1 (+12.3) APIMig41.6 (+7.4)48.5 (+3.6)45.4 (+4.5)28.6 (+11.8) VersiCode37.1 (+2.9)42.6 (-2.3)41.5 (+0.6)21.8 (+5.0) EnvGraph44.02 (+5.72)50.8 (+6.6)46.3 (+5.4)35.2 (+18.4) Imp.%+5.72%+14.7%+13.2%+52.5% Functional Correctness and 4.58%–8.66% in Non-Functional Quality. These results show a consistent advantage of EnvGraph across the tested backbone models. The NL2Repo-Bench results, as shown in Table 3, follow a consistent pattern. EnvGraph achieves the highest overall score across all settings, outperforming other methods in the overall score. Comparison with Repository-Level Baselines. A closer compari- son with repository-level baselines further highlights the advantages of EnvGraph. Methods such as CodePlan, Repo2Run, and Repo- Graph provide partial improvements in some settings, suggesting that planning, executable validation, and structural reasoning can benefit repository-level code generation. Among them, CodePlan is the strongest non-EnvGraph baseline across all three backbones. Conference’17, July 2017, Washington, DC, USA Ruwei Pan 1,2 Junlei Shen 1 Linhao Wu 2 Yueheng Zhu 1,2 Zixiong Yang 2 Yakun Zhang 3 Lu Zhang 2 Hongyu Zhang 1 However, these gains remain limited and are not always consistent on Non-Functional Quality, as illustrated by the performance drop of CodePlan on Gemini-3-Pro-Preview. This suggests that repository- level mechanisms alone can improve task-relevant generation, but they are still insufficient to reliably ensure repository executability together with broader engineering quality. Comparison with Environment-Aware Baselines. The compari- son with environment-aware baselines reveals a different limitation. APIMig and VersiCode explicitly model external execution con- straints, such as API evolution, dependency migration, and version adaptation. However, their performance remains noticeably weaker and less stable across backbone models, and several results are even worse than Direct, especially on Non-Functional Quality. This pattern suggests that modeling only external execution conditions is insufficient for repository-level code generation, where successful generation also depends on repository-internal reference resolution and repository-wide structural consistency. Cross-Backbone Trends. Another notable observation is that the relative ranking of baselines varies substantially across backbone models, whereas EnvGraph remains consistently strongest. This indicates that repository-level code generation is sensitive to the capability profile of the underlying model, and that many existing baselines do not maintain stable gains across different backbones. In contrast, EnvGraph delivers consistent improvements under all three tested models, suggesting that its design captures a more reliable mechanism for improving repository executability across diverse backbone settings. Answer to RQ1: EnvGraph achieves the best results across all compared methods and backbone models on both Func- tional Correctness and Non-Functional Quality. These find- ings show that jointly addressing external dependency sat- isfaction and repository-internal reference resolution is critical for repository executability, enabling EnvGraph to maintain a consistent advantage over representative repository-level and environment-aware baselines. 4.3 RQ2: Ablation Study The ablation results are presented in Table 4. Across all three backbone models, the full EnvGraph consistently achieves the best performance on both Functional Correctness and Non-Functional Quality. Removing any component leads to performance degradation, indicating that all four components make positive contributions to repository-level code generation and repository executability. Effect of Environment Graphs. Both graph modules are benefi- cial, but they contribute in different ways. Removing the external environment graph consistently reduces both Functional Correctness and Non-Functional Quality, highlighting the importance of model- ing dependency availability and version compatibility. Removing the repository dependency graph causes a larger decline in Functional Correctness, especially on GPT-5 (-6.99), suggesting that this module is particularly important for repository-internal reference resolution. These results indicate that the two graphs provide complementary support for external dependency satisfaction and repository-internal reference resolution. Table 4: Ablation study of EnvGraph on RAL-Bench under different backbone models. EEBA denotes execution-evidence- based attribution. Gray numbers in parentheses indicate absolute drops relative to the full model under the same backbone. ModelVariantFunc.Non-Func. GPT-5 -2025-08-07 EnvGraph55.4364.12 w/o External Env. Graph52.57 (-2.86) 59.92 (-4.20) w/o Repo. Dep. Graph48.44 (-6.99) 62.76 (-1.36) w/o EEBA44.07 (-11.36) 58.56 (-5.56) w/o Iterative Alignment Loop43.33 (-12.10) 57.97 (-6.15) DeepSeek -V3.2 EnvGraph32.6255.76 w/o External Env. Graph29.33 (-3.29) 54.73 (-1.03) w/o Repo. Dep. Graph31.56 (-1.06) 55.03 (-0.73) w/o EEBA31.96 (-0.66) 55.46 (-0.30) w/o Iterative Alignment Loop31.56 (-1.06) 55.29 (-0.47) Gemini-3 Pro-Preview EnvGraph45.4459.47 w/o External Env. Graph43.17 (-2.27) 58.75 (-0.72) w/o Repo. Dep. Graph43.29 (-2.15) 58.53 (-0.94) w/o EEBA42.41 (-3.03) 57.58 (-1.89) w/o Iterative Alignment Loop42.41 (-3.03) 57.28 (-2.19) Effect of Execution-Evidence-Based Attribution and the Iter- ative Alignment Loop. Execution-evidence-based attribution and the iterative alignment loop have the largest impact, particularly on GPT-5. Removing execution-evidence-based attribution decreases Functional Correctness and Non-Functional Quality by 11.36 and 5.56 points, respectively, while removing the iterative alignment loop causes even larger drops of 12.10 and 6.15 points. These findings show that environment modeling alone is insufficient; the framework must also identify the dominant source of misalignment and perform targeted repository revision based on execution evidence. Cross-Backbone Trends. The overall trend is consistent across backbone models, although the magnitudes of the drops vary. The effects are strongest on GPT-5, moderate on Gemini-3-Pro-Preview, and smaller on DeepSeek-V3.2, suggesting that stronger backbones are better able to exploit structured environment signals and iterative alignment. Nevertheless, all ablated variants perform worse than the full EnvGraph on every backbone, confirming the consistent advantage of the complete design across the evaluated backbones. Answer to RQ2: All four components contribute to the final performance of EnvGraph. Among them, execution- evidence-based attribution and the iterative alignment loop have the largest impact, while the external environment graph and the repository dependency graph provide comple- mentary support for external dependency satisfaction and repository-internal reference resolution. 4.4 RQ3: Error Analysis For this RQ, we analyze the remaining failures of EnvGraph using GPT-5-2025-08-07, DeepSeek-V3.2, and Gemini-3-Pro-Preview on RAL-Bench. Figure 6 shows the distribution of major failure types across the three backbone models. This analysis aims to reveal Toward Executable Repository-Level Code Generation via Environment AlignmentConference’17, July 2017, Washington, DC, USA Repository Packaging Failure Interface Contract Violation Residual Logic Fault Implementation Incompleteness 0 2 4 6 8 10 12 14 16 Count 18.75% 34.38% 40.62% 6.25% (a) GPT-5-2025-08-07 Repository Packaging Failure Interface Contract Violation Residual Logic Fault Implementation Incompleteness 0.0 2.5 5.0 7.5 10.0 12.5 15.0 17.5 Count 20.00% 22.86% 45.71% 11.43% (b) DeepSeek-V3.2 Repository Packaging Failure Interface Contract Violation Residual Logic Fault Implementation Incompleteness 0 2 4 6 8 10 12 14 16 Count 21.21%21.21% 39.39% 18.18% (c) Gemini-3-Pro-Preview Figure 6: Failure-type distribution of EnvGraph across different backbone models. which repository-level problems remain difficult after environment alignment and therefore still limit repository executability. Failure Assignment. We manually inspect the remaining failed repositories produced by EnvGraph on RAL-Bench for each back- bone model. We assign one primary failure category to each failed case based on the generated repository, execution logs, stack traces, and test outcomes. When multiple issues co-occur, we use the domi- nant failure type as the assigned label. Failure Modes. We use the following failure categories in this analysis: •Repository Packaging Failures: Failures caused by improper repository organization, broken packaging structure, or missing files that prevent successful repository execution. These failures are closely related to unresolved repository-level structural and reference issues. •Interface Contract Violations: Failures caused by inconsistent function signatures, incorrect parameter passing, or mismatched module-level invocation assumptions across repository compo- nents. •Residual Logic Faults: Failures in which the repository can be executed but still does not implement the required functionality correctly. •Implementation Incompleteness: Failures caused by missing, unfinished, or only partially implemented code that prevents full repository functionality. Results. Residual Logic Faults account for the largest share of the remaining failures across all three backbone models. For GPT- 5-2025-08-07, Residual Logic Faults account for 40.62% of all analyzed failures. For DeepSeek-V3.2, this category further rises to 45.71%. For Gemini-3-Pro-Preview, Residual Logic Faults remain the largest category at 39.39%. This pattern suggests that environment alignment alone is not sufficient for full repository executability, and that final success still depends heavily on accurate logic generation. At the same time, the distributions also reveal model-specific differences in the remaining bottlenecks. DeepSeek-V3.2 exhibits a relatively higher proportion of Repository Packaging Failures (20.00%), suggesting that repository-level structural construction remains a nontrivial challenge for this model. Gemini-3-Pro-Preview shows a more balanced failure distribution, with Interface Contract Violations (21.21%) and Implementation Incompleteness (18.18%) also contributing substantially. This suggests that, beyond logic correctness, cross-module interface consistency and complete im- plementation remain important challenges in repository-level code generation. Overall, the remaining failures are distributed across logic, struc- ture, interface consistency, and completeness, rather than being domi- nated by a single non-logic factor. This indicates that EnvGraph alle- viates part of the environment-related bottleneck, but full repository executability still depends on stronger end-to-end implementation quality and cross-file coordination. Answer to RQ3: The remaining failures show that envi- ronment alignment is necessary but not sufficient for full repository executability. Residual Logic Faults are the main remaining failure source, while repository structure, inter- face coordination, and implementation completeness also de- serve attention. In addition to improving alignment, stronger end-to-end implementation and cross-file coordination are promising directions for future work. 5 Threats to Validity Threats in generalizability. Although we evaluate EnvGraph using three diverse backbone models and compare it against representative repository-level and environment-aware baselines, the current eval- uation still cannot cover the full diversity of repository-level code generation scenarios. Our experiments also consider both functional correctness and non-functional quality, which reduces the risk that our conclusions depend on a single metric. However, the benchmark scope, software stacks, and execution environments considered in this work remain limited. Therefore, our findings should be interpreted as evidence of effectiveness within the evaluated settings rather than as proof of universal generalizability. In future work, we plan to further examine the generalizability of EnvGraph on broader benchmark collections, more diverse software stacks, and additional backbone models. Threats in benchmark contamination. Since modern LLMs are trained on large-scale corpora, it is difficult to completely rule out the possibility that some benchmark repositories, dependency specifications, or related implementation patterns may have appeared Conference’17, July 2017, Washington, DC, USA Ruwei Pan 1,2 Junlei Shen 1 Linhao Wu 2 Yueheng Zhu 1,2 Zixiong Yang 2 Yakun Zhang 3 Lu Zhang 2 Hongyu Zhang 1 in the training data. Such contamination may influence the absolute level of performance achieved by all methods. However, this threat applies to all compared methods under the same backbone model. Therefore, although benchmark contamination may affect absolute scores, it does not invalidate the fairness of our comparative analysis or the relative improvements of EnvGraph, which remain consistent across different backbone settings. Threats in method scope. Our framework focuses on failures related to external dependency satisfaction and repository-internal reference resolution, and uses execution evidence to identify the dom- inant source of misalignment and guide targeted repository revision. Although this design is effective for the failure space considered in our evaluation, it may not fully cover all execution failures en- countered in real-world repositories. For example, some failures may arise from hidden infrastructure assumptions, undocumented build or deployment logic, dynamically generated resources, or external ser- vices that are not explicitly modeled in the current framework. When failures are dominated by such factors, the attribution and revision process may become less accurate. We therefore view EnvGraph as a principled step toward environment-aligned repository-level code generation rather than as a complete solution to every real-world ex- ecution failure mode. Extending the framework to broader classes of environment and infrastructure constraints is an important direction for future work. 6 Related Work Environment-Aware Code Generation. Early studies on LLM- based code generation are typically conducted under standardized evaluation settings in which the runtime environment is fixed in advance [2, 13, 27]. Under this assumption, models are expected to generate code without explicit access to library versions, API com- patibility requirements, or other execution constraints, and success is evaluated primarily based on functional correctness [26,31,34]. Subsequent studies have shown that this assumption is often too restrictive: code that appears functionally correct may still fail in the target environment because of unmet dependency requirements, ver- sion incompatibility, or API evolution [3,8,29]. This observation has motivated a growing body of research on environment-aware code generation, which explicitly models execution constraints rather than treating them as implicit assumptions [10,15,28,30]. Representative efforts in this direction primarily focus on modeling external envi- ronment conditions. VersiCode [30] explicitly incorporates library version constraints into code generation, treating version compati- bility as a first-class objective rather than an implicit prerequisite. Extending this perspective beyond local code generation, APIMig [14] addresses repository-level API migration with the support of an API evolution knowledge graph, enabling migration across multiple library versions rather than isolated API replacement. Overall, these studies establish the importance of environment constraints in code generation and substantially improve generation under changing dependency and API conditions. However, they mainly formulate environment awareness in terms of external dependency satisfaction, such as library versions, API compatibility, and migration constraints, without jointly modeling repository-internal reference resolution as another necessary condition for repository executability. Repository-Level Code Generation. A parallel line of research moves beyond single-function or single-file generation and investi- gates repository-level code generation in multi-file software projects [9,12,16,17,24,32,36]. CodePlan [1] shows that repository-level generation cannot be reduced to local retrieval alone and instead for- mulates code generation as a planning problem that coordinates edits across files and components. Repo2Run [8] further shifts the focus from producing plausible code to improving repository executability by iteratively building runnable environments and revising outputs based on execution feedback. Complementarily, RepoGraph [23] introduces an explicit graph representation of repository structure and dependencies, enabling more accurate cross-file reasoning and refinement. Taken together, these methods substantially advance repository-level code generation in terms of planning, executable validation, and structural reasoning [1]. However, they are still pri- marily designed around repository coordination, execution-driven revision, or structural dependency modeling, rather than formulating repository executability itself as a unified environment alignment problem. In particular, they do not explicitly determine whether an observed execution failure is mainly caused by unmet external depen- dency satisfaction, broken repository-internal reference resolution, or residual logic faults after the environment is largely aligned [8]. Our Position. Prior work has advanced either the modeling of ex- ternal execution constraints or repository-level planning, executable validation, and structural reasoning, but has rarely unified them as a single problem of environment alignment for repository executability [1,8,14,15,30]. Our core idea is to jointly model two coupled conditions for repository executability: external dependency satis- faction and repository-internal reference resolution. Based on this unified perspective, EnvGraph uses execution evidence to perform execution-evidence-based attribution, identifies the dominant source of misalignment, and then performs targeted repository revision, thereby forming an iterative alignment loop for repository-level code generation and refinement. 7 Conclusion In this paper, we propose EnvGraph, a framework for repository- level code generation that formulates repository executability as an environment alignment problem. It jointly models external de- pendency satisfaction and repository-internal reference resolution through a dual-layer environment representation, and improves repos- itory generation via execution-evidence-based attribution, unified targeted repository revision, and an iterative alignment loop. Ex- tensive experiments on diverse benchmarks and LLMs demonstrate the superior performance of EnvGraph. Our work represents a promising step toward environment-aligned repository-level code generation and executable repository construction. In future work, we plan to evaluate EnvGraph on broader benchmark collections and additional backbone models. We will also explore how the environ- ment alignment framework can be extended to other repository-scale software engineering tasks beyond repository-level code generation. References [1] Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Vageesh D C, Arun Iyer, Suresh Parthasarathy, Sriram Rajamani, Balasubramanyan Ashok, and Shashank Shet. 2024. Codeplan: Repository-level coding using llms and planning. Proceed- ings of the ACM on Software Engineering 1, FSE (2024), 675–698. Toward Executable Repository-Level Code Generation via Environment AlignmentConference’17, July 2017, Washington, DC, USA [2]Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al.2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374 (2021). [3]Keyuan Cheng, Xudong Shen, Yihao Yang, TengyueWang TengyueWang, Yang Cao, Muhammad Asif Ali, Hanbin Wang, Lijie Hu, and Di Wang. 2025. Codemenv: Benchmarking large language models on code migration. In Findings of the Association for Computational Linguistics: ACL 2025. 2719–2744. [4] Jingzhe Ding, Shengda Long, Changxin Pu, Huan Zhou, Hongwan Gao, Xiang Gao, Chao He, Yue Hou, Fei Hu, Zhaojian Li, et al.2025. NL2Repo-Bench: Towards Long-Horizon Repository Generation Evaluation of Coding Agents. arXiv preprint arXiv:2512.12730 (2025). [5] Yangruibo Ding, Zijian Wang, Wasi Ahmad, Hantian Ding, Ming Tan, Nihal Jain, Murali Krishna Ramanathan, Ramesh Nallapati, Parminder Bhatia, Dan Roth, et al.2023. Crosscodeeval: A diverse and multilingual benchmark for cross-file code completion. Advances in Neural Information Processing Systems 36 (2023), 46701–46723. [6] John Estdale and Elli Georgiadou. 2018. Applying the ISO/IEC 25010 qual- ity models to software product. In European Conference on Software Process Improvement. Springer, 492–503. [7]Nam Le Hai, Dung Manh Nguyen, and Nghi D. Q. Bui. 2025. On the Impacts of Contexts on Repository-Level Code Generation. arXiv:2406.11927 [cs.SE] https://arxiv.org/abs/2406.11927 [8]Ruida Hu, Chao Peng, Xinchen Wang, Junjielong Xu, and Cuiyun Gao. 2025. Repo2run: Automated building executable environment for code repository at scale. arXiv preprint arXiv:2502.13681 (2025). [9]Xing Hu, Feifei Niu, Junkai Chen, Xin Zhou, Junwei Zhang, Junda He, Xin Xia, and David Lo. 2025. Assessing and advancing benchmarks for evaluating large language models in software engineering tasks. ACM Transactions on Software Engineering and Methodology (2025). [10]Nizar Islah, Justine Gehring, Diganta Misra, Eilif Muller, Irina Rish, Terry Yue Zhuo, and Massimo Caccia. 2024. Gitchameleon: Unmasking the version-switching capabilities of code generation models. arXiv preprint arXiv:2411.05830 (2024). [11]Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2026. A survey on large language models for code generation. ACM Transactions on Software Engineering and Methodology 35, 2 (2026), 1–72. [12] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2023. Swe-bench: Can language models resolve real-world github issues? arXiv preprint arXiv:2310.06770 (2023). [13]Sathvik Joel, Jie Wu, and Fatemeh Fard. 2024. A survey on llm-based code generation for low-resource and domain-specific programming languages. ACM Transactions on Software Engineering and Methodology (2024). [14]Li Kuang, Qi Xie, HaiYang Yang, Yang Yang, Xiang Wei, HaoYue Kang, and YingJie Xia. 2025. APIMig: A Project-Level Cross-Multi-Version API Migration Framework Based on Evolution Knowledge Graph. In Proceedings of the Thirty- Fourth International Joint Conference on Artificial Intelligence. 7455–7463. [15]Sachit Kuhar, Wasi Ahmad, Zijian Wang, Nihal Jain, Haifeng Qian, Baishakhi Ray, Murali Krishna Ramanathan, Xiaofei Ma, and Anoop Deoras. 2025. Libevo- lutioneval: A benchmark and study for version-specific code generation. In Pro- ceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers). 6826–6840. [16]Nam Le Hai, Dung Manh Nguyen, and Nghi DQ Bui. 2025. On the impacts of contexts on repository-level code generation. In Findings of the Association for Computational Linguistics: NAACL 2025. 1496–1524. [17] Jia Li, Ge Li, Yunfei Zhao, Yongmin Li, Huanyu Liu, Hao Zhu, Lecheng Wang, Kaibo Liu, Zheng Fang, Lanshen Wang, et al.2024. Deveval: A manually-annotated code generation benchmark aligned with real-world code repositories. In Findings of the Association for Computational Linguistics: ACL 2024. 3603–3614. [18]Wei Li, Xin Zhang, Zhongxin Guo, Shaoguang Mao, Wen Luo, Guangyue Peng, Yangyu Huang, Houfeng Wang, and Scarlett Li. 2025. Fea-bench: A benchmark for evaluating repository-level code generation for feature implementation. arXiv preprint arXiv:2503.06680 (2025). [19]Tianyang Liu, Canwen Xu, and Julian McAuley. 2023. Repobench: Benchmarking repository-level code auto-completion systems. arXiv preprint arXiv:2306.03091 (2023). [20]Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. 2023. Self-refine: Iterative refinement with self-feedback. Advances in neural information processing systems 36 (2023), 46534–46594. [21]Paul Oman and Jack Hagemeister. 1992. Metrics for Assessing a Software System’s Maintainability. In Proceedings of the Conference on Software Maintenance. 337– 344. [22]Paul Oman and Jack Hagemeister. 1994. Construction and Testing of Polynomials Predicting Software Maintainability. Journal of Systems and Software 24, 3 (1994), 251–266. [23]Siru Ouyang, Wenhao Yu, Kaixin Ma, Zilin Xiao, Zhihan Zhang, Mengzhao Jia, Jiawei Han, Hongming Zhang, and Dong Yu. 2024. Repograph: Enhanc- ing ai software engineering with repository-level code graph. arXiv preprint arXiv:2410.14684 (2024). [24]Ruwei Pan, Hongyu Zhang, and Chao Liu. 2025. CodeCoR: An LLM-Based Self- Reflective Multi-Agent Framework for Code Generation. arXiv:2501.07811 [cs.SE] https://arxiv.org/abs/2501.07811 [25]Ruwei Pan, Yakun Zhang, Qingyuan Liang, Yueheng Zhu, Chao Liu, Lu Zhang, and Hongyu Zhang. 2026. RAL-Bench: Benchmarking for Application-Level Functional Correctness and Non-Functional Quality Attributes. arXiv preprint arXiv:2602.03462 (2026). [26]Jishnu Sen. 2025. Large Language Models for Code: A Focused Survey of Ten Recent Studies on Methods, Evaluation, and Robustness. (2025). [27]Umama, Kamaluddeen Usman Danyaro, Maged Nasser, Abubakar Zakari, Shamsu Abdullahi, Atika Khanzada, Muhammad Muntasir Yakubu, and Sara Shoaib. 2025. LLM-Based Code Generation: A Systematic Literature Review With Technical and Demographic Insights. IEEE Access 13 (2025), 194915–194939. doi:10.1109/ACCESS.2025.3631952 [28]Chong Wang, Kaifeng Huang, Jian Zhang, Yebo Feng, Lyuye Zhang, Yang Liu, and Xin Peng. 2025. Llms meet library evolution: Evaluating deprecated api usage in llm-based code completion. In 2025 ieee/acm 47th international conference on software engineering (icse). IEEE, 885–897. [29]Tongtong Wu, Rongyi Chen, Wenjie Du, Suyu Ma, Guilin Qi, Zhenchang Xing, Shahram Khadivi, Ramesh Periyathambi, and Gholamreza Haffari. 2026. Environment-Aware Code Generation: How far are We? arXiv preprint arXiv:2601.12262 (2026). [30]Tongtong Wu, Weigang Wu, Xingyu Wang, Kang Xu, Suyu Ma, Bo Jiang, Ping Yang, Zhenchang Xing, Yuan-Fang Li, and Gholamreza Haffari. 2024. Versicode: Towards version-controllable code generation. arXiv preprint arXiv:2406.07411 (2024). [31]Yixi Wu, Pengfei He, Zehao Wang, Shaowei Wang, Yuan Tian, and Tse-Hsun Chen. 2024. A comprehensive framework for evaluating api-oriented code generation in large language models. arXiv preprint arXiv:2409.15228 (2024). [32]Dayu Yang, Tianyang Liu, Daoan Zhang, Antoine Simoulin, Xiaoyi Liu, Yuwei Cao, Zhaopu Teng, Xin Qian, Grey Yang, Jiebo Luo, et al.2025. Code to think, think to code: A survey on code-enhanced reasoning and reasoning-driven code intelligence in llms. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing. 2586–2616. [33] Jian Yang, Jiajun Zhang, Jiaxi Yang, Ke Jin, Lei Zhang, Qiyao Peng, Ken Deng, Yibo Miao, Tianyu Liu, Zeyu Cui, et al.2024. Execrepobench: Multi-level executable code completion evaluation. arXiv preprint arXiv:2412.11990 (2024). [34]Hao Yu, Bo Shen, Dezhi Ran, Jiaxin Zhang, Qi Zhang, Yuchi Ma, Guangtai Liang, Ying Li, Qianxiang Wang, and Tao Xie. 2024. Codereval: A benchmark of pragmatic code generation with generative pre-trained models. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering. 1–12. [35] Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Jian-Guang Lou, and Weizhu Chen. 2023. Repocoder: Repository-level code completion through iterative retrieval and generation. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing. 2471–2484. [36]Quanjun Zhang, Chunrong Fang, Yang Xie, YuXiang Ma, Weisong Sun, Yun Yang, and Zhenyu Chen. 2024. A systematic literature review on large language models for automated program repair. ACM Transactions on Software Engineering and Methodology (2024).