arXiv Science⌕ Search

arXiv · 2610.00425

Code That Works, Environments That Don't: Measuring Environment Reproducibility in AI-Generated Software

Abstract

Code generation has emerged as a central capability of large language models, with coding agents now able to produce functionally correct software projects from natural language prompts. However, functional correctness alone does not capture a critical dimension of generation quality: environment specification, defined as the accurate identification of the dependencies required to execute generated code, is equally critical. We develop an agent protocol for environment specification and introduce a three-layer framework comprising declared, runtime-installed, and necessary-and-sufficient dependencies to systematically assess coding agents for environment specification. Using this protocol, we evaluate the extent to which coding agents systematically misspecify software environment dependencies and how this misspecification varies across three agents, four languages, and fifty programming tasks. Our results show that current coding agents exhibit systematic generalization failures along this dimension, producing dependency specifications that are inconsistent, redundant, or incomplete in ways that functional tests do not detect. Across agents, dependency set agreement is as low as 7% for identical tasks, and newer agents show no meaningful improvement, suggesting the failure is not resolved by scale or recency. The largest divergence occurs between the declared and runtime dependency layers, implicating environment priors learned from the models' training distributions as the primary driver. Our findings establish environment specification as a distinct, measurable axis of code generation quality that current benchmarks do not capture, and motivate training objectives and evaluation protocols that jointly optimize for functional correctness and environmental portability.

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Bhanu Prakash Vangala, Tanu Malik. 2026-09-30. Code That Works, Environments That Don't: Measuring Environment Reproducibility in AI-Generated Software. https://arxiv.org/abs/2610.00425

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

Pluvio: Assembly Clone Search for Out-of-domain Architectures and Libraries through Transfer Learning and Conditional Variational Information Bottleneck

The practice of code reuse is crucial in software development for a faster and more efficient development lifecycle. In reality, however, code reuse practices lack proper control, resulting in issues such as vulnerability propagation and intellectual property infringements. Assembly clone search, a critical shift-right defence mechanism, has been effective in identifying vulnerable code resulting from reuse in released executables. Recent studies on assembly clone search demonstrate a trend towards using machine learning-based methods to match assembly code variants produced by different toolchains. However, these methods are limited to what they learn from a small number of toolchain variants used in training, rendering them inapplicable to unseen architectures and their corresponding compilation toolchain variants. This paper presents the first study on the problem of assembly clone search with unseen architectures and libraries. We propose incorporating human common knowledge through large-scale pre-trained natural language models, in the form of transfer learning, into current learning-based approaches for assembly clone search. Transfer learning can aid in addressing the limitations of the existing approaches, as it can bring in broader knowledge from human experts in assembly code. We further address the sequence limit issue by proposing a reinforcement learning agent to remove unnecessary and redundant tokens. Coupled with a new Variational Information Bottleneck learning strategy, the proposed system minimizes the reliance on potential indicators of architectures and optimization settings, for a better generalization of unseen architectures. We simulate the unseen architecture clone search scenarios and the experimental results show the effectiveness of the proposed approach against the state-of-the-art solutions.

cs.SE↗

FeatureFuzz: Treating Bug-prone Features as Core Primitives for Compiler Fuzzing

CI/CD pipelines often execute build and test tasks with high privileges, making the compilation stage security-sensitive. In this setting, malicious pull requests may exploit carefully crafted source code to trigger arbitrary code execution or excessive resource consumption during compilation, making compiler vulnerabilities security-relevant. Recent work has leveraged bug-prone knowledge from historical bugs to drive compiler exploration and bug discovery. However, many compiler bugs depend on program semantics rather than syntax, and existing approaches either rely on syntactic mutation or encode this knowledge in model parameters, making it difficult to preserve and recombine the semantics that actually trigger compiler bugs. We propose FeatureFuzz, a compiler fuzzer that explicitly reuses bug-prone semantics through features and feature groups. FeatureFuzz extracts these bug-prone semantics from historical bugs as features, synthesizes them into coherent feature groups, and instantiates them into programs for compiler fuzzing. On GCC and LLVM, over 24-hour campaigns, FeatureFuzz uncovers 167 unique crashes, 2.78x as many as the second-best fuzzer. Over a 72-hour fuzzing campaign, FeatureFuzz identifies 122 bugs, of which 106 have been confirmed by compiler developers as zero-days. Among reported bugs, 64 affect release-build compilers, including 9 memory-corruption bugs, highlighting the security relevance of compiler fuzzing in CI/CD settings.

cs.SE↗

A Longitudinal Study of Dependency Reclassifications in JavaScript Projects

Modern software projects depend on third-party dependencies, whose declarations must be maintained as projects evolve. Prior work has focused on dependency version updates, while much less is known about how developers assign dependencies to different roles over time. In this paper, we investigate how developers of JavaScript projects reclassify their dependencies, including removal and role reassignment. By analyzing commit-level modifications to package.json files, we reconstruct dependency role histories and identify recurring reclassification practices. Our analysis of 33,087 JavaScript projects with active dependency maintenance reveals that dependency reclassification is a prevalent maintenance activity, occurring in 79.1% of the studied projects, and accounting for 19.4% of all dependency-maintenance commits. Of these projects, nearly all (97.2%) remove dependencies at some point, while 38.0% undergo role reassignments across Core (runtime), Dev (development-only), and Peer (consumer-provided) roles. These changes are not always final, as 33.1% of projects later reintroduce removed dependencies and 11.2% exhibit repeated role switching. Reclassification practices also tend to unfold over long periods, with a median duration of 408 days. Illustrative cases further show recurring motivations: batch removals as accumulated cleanup or toolchain retirement; reassignments from Core to Dev, which revise production install scope for auditing or builds; and Peer reassignments that simplify consumer installation or move packages that consumers need not provide into Dev. These findings broaden the study of dependency maintenance beyond version updates, and contribute implications for project maintainers, dependency tools, package managers, and research to support correct dependency role declarations.

cs.SE↗