Source-linked AI summary
RepoZero: Can LLMs Generate a Code Repository from Scratch?
Zhaoxi Zhang, Yiming Xu, Jiahui Liang, Weikang Li, Xiaoshuai Chen, Liwei Qian, Xin Pei, Jizhou Huang, Run Sun, Yunfang Wu
TL;DR
Repository-level generation from scratch lacks scalable, verifiable evaluation, while data leakage further complicates benchmark integrity. RepoZero evaluates repository reproduction through cross-language execution, and ACE adds iterative code-test refinement; experiments report moderate success of approximately 40%, with self-verification remaining important.
Problem
Repository generation from scratch is underexplored, and existing evaluation often relies on subjective human or LLM judgments while GitHub pretraining complicates leakage control.
Source: §1 · p. 2Method
RepoZero evaluates cross-language repository reproduction against source-executed test outputs, and ACE iteratively feeds test results back for code refinement.
Source: §1 · p. 2Results
State-of-the-art models with advanced scaffolds achieve only moderate success, approximately 40%, and the code-test loop is described as promising while a self-verification gap remains.
Source: §8 · p. 10Takeaways & Limitations
The findings identify self-verification and more robust integration of autonomous, high-quality test-suite synthesis as important directions for repository-level generation.
Source: §8 · p. 10The benchmark’s future scope includes expansion to large-scale, multilingual, and industry-level software development scenarios.
Source: §8 · p. 10
Abstract
from arXiv · showhide
Large Language Models (LLMs) have recently shown remarkable progress in code generation, yet their ability to construct complete software repositories from scratch remains poorly understood. A fundamental bottleneck is the lack of verifiable and scalable evaluation: existing benchmarks either focus on patch-based editing or rely on human or LLM-based judgments, which introduce bias and limit reproducibility. In this work, we present RepoZero, the first benchmark that enables fully automated, execution-based verification of repository-level generation from scratch. Our key idea is to reformulate generation as repository reproduction: given only API specifications, an agent must re-implement an entire repository such that its behavior matches the original implementation. This design allows for strict black-box validation via output equivalence, while naturally supporting large-scale construction by reusing existing open-source repositories. To further mitigate data leakage and shortcut solutions, we introduce cross-language constraints and a sandboxed evaluation protocol. Building on this benchmark, we propose an Agentic Code-Test Evolution (ACE) framework that performs iterative test generation and error-driven refinement, enabling effective test-time scaling for repository-level synthesis. Extensive experiments across multiple state-of-the-art LLMs and agent frameworks reveal that even the strongest LLM agents achieve only limited pass rates (30\% - 55\%), exposing a substantial gap between current capabilities and real-world software development requirements. Our results establish RepoZero as a challenging, scalable, and reliable testbed for end-to-end code generation, and highlight self-verification via test generation as a critical direction for advancing LLM-based coding agents.
1 Introduction
Repository generation from scratch remains difficult to evaluate reliably, with existing approaches limited by subjective judgments and data-leakage concerns. RepoZero addresses these gaps with execution-based reproduction and cross-language constraints, alongside an agentic test-time-scaling workflow.
1 Introduction
- From-scratch repository generation remains underexplored because existing benchmarks largely assess edits, while generation benchmarks rely on human or LLM judgments that can introduce subjective bias.Patch-based benchmarks assess repository edits and incremental development, rather than generation from scratch.Source: §1 · p. 2
- Pretraining on GitHub makes it difficult to distinguish reasoning from memorization, while rare or recent repositories constrain dataset scale and can become contaminated after publication.Keeping such datasets clean requires frequent, labor-intensive updates.Source: §1 · p. 2
- RepoZero evaluates repository generation by asking agents to reproduce a repository’s API behavior, then comparing generated and source outputs on saved tests.The protocol requires cross-language implementation and prohibits external site packages to mitigate data leakage and shortcuts.Source: §1 · p. 2
- The paper proposes ACE as a test-time-scaling framework for repository-level synthesis.The introduction identifies ACE as a primary contribution centered on test-time scaling.Source: §1 · p. 3
- The authors report comprehensive evaluations of state-of-the-art models and agent scaffolds as a foundation for research in autonomous software engineering.The introduction lists benchmarking as a primary contribution.Source: §1 · p. 3
2 Benchmark: RepoZero
RepoZero spans two cross-language subsets and frames repository reproduction as black-box functional matching. Its task requires agents to synthesize multi-file implementations and navigate several reasoning challenges under safeguards against evaluation shortcuts.
2.1 Statistics of RepoZero
- RepoZero contains 400 Python-to-JavaScript samples and 200 C/C++-to-Rust samples, grouped by repository category and estimated difficulty.Difficulty estimates use LOC, API counts, and input/output complexity, with majority voting across three LLMs.Source: §2.1 · p. 3
2.2 Task Definition and Challenges
- Agents receive API specifications, four white-box test cases, and anti-shortcut constraints, then must match the source repository’s outputs under black-box testing.The task challenges include functional synthesis, modular reasoning, iterative self-correction, and long-context retention.Source: §2.2 · pp. 3–4
2.3 Evaluation Pipeline
- The evaluation uses OpenHands-bash and Mini-SWE-Agent, with four representative tests shown to agents and the rest of the test suite withheld.Evaluation runs in isolated Docker containers with read-only source tests and a hidden suite inaccessible to agents.Source: §2.3 · p. 4
- Agents cannot import external packages or invoke the source language through bridge commands, preserving the cross-language synthesis requirement.The protocol also restricts system-level commands to preclude non-generalizable solutions.Source: §2.3 · p. 4
3 Benchmark Construction
The benchmark is constructed from selected open-source repositories, API-invoking test files, generated test cases, and filtering that retains stable, executable ground truth.
3 Benchmark Construction
- The construction process selects open-source repositories, generates API-invoking test files and test cases, then filters the resulting samples.Each successful test file represents one dataset sample.Source: §3 · p. 4
3.1 Sample Generation
- Repository selection requires determinism and open-source integrity, while API-call counts are regulated to vary task difficulty and architectural complexity is intended to rule out single-file implementations.The prompt regulates API calls per file from 1 to 20; repository choice also relies on expert judgment.Source: §3.1 · pp. 4–5
3.2 Test Case Generation
- For each target repository, an LLM uses its name and test files to infer API specifications and generate input-output pairs that require subsequent filtering for reliability.The initial outputs may be unpredictable because the LLM sees only limited codebase information and source repositories may be inconsistent.Source: §3.2 · p. 5
3.3 Environment Configuration
- Each sample receives an isolated Docker environment, which is accepted only after generated test files run and at least five baseline cases pass without runtime errors.OpenHands dynamically resolves and installs dependencies required by the source test files.Source: §3.3 · p. 5
3.4 Data Filtering and Ground-Truth Verification
- Test cases are run 20 times and discarded if they raise runtime exceptions or produce nondeterministic outputs; samples with fewer than 10 valid cases are also discarded.The remaining stable outputs serve as ground truth.Source: §3.4 · p. 5
4 Agentic Code-Test Evolution Workflow
ACE addresses challenges in code-test feedback by structuring iterative testing and revision for repository synthesis. Source execution supplies reliable ground-truth outputs for the testing loop.
4 Agentic Code-Test Evolution Workflow
- Code-test feedback can improve code generation, but LLMs may not generate tests without explicit prompting, and their tests often cannot verify functional correctness independently.Such tests may assess executability rather than whether the implementation functions correctly.Source: §4 · p. 6
- ACE applies an iterative code-test feedback loop as a structured workflow designed for RepoZero.The workflow is inspired by Agentless, which uses a structured process for LLM-based bug localization.Source: §4 · p. 6
- A coding agent first generates the repository, then a testing agent obtains source-execution outputs and sends failures back for revision until all tests pass.RepoZero’s source repository provides ground-truth outputs, allowing effectively unlimited test cases with reliable labels.Source: §4 · p. 6
5 Experimental Setup
The experiments pair two software-engineering agent scaffolds with state-of-the-art LLMs and use strict output consistency as the primary measure of success.
Models and Scaffolds
- OpenHands-bash and Mini-SWE-Agent are evaluated with a range of state-of-the-art LLMs.Agents have no explicit cap on tool-calling iterations and may use context management and retrieval-augmented tools.Source: §5 · p. 6
- The only iteration constraint is each base model’s maximum output-token limit.Agents may use context-management techniques and retrieval-augmented tools.Source: §5 · p. 6
Metrics
- Pass Rate is the primary metric, requiring strict string-level consistency between source and target outputs for a sample to pass.Success Rate across test cases is also reported as a complementary measure.Source: §5 · p. 6
6 Results and Analysis
Across both benchmarks and scaffolds, performance remains suboptimal, while Claude-4.6-Sonnet leads; ACE gains and failure analysis highlight the roles of testing, context management, and semantic correctness.
6.1 Main Evaluation
- Mini-SWE-Agent generally outperforms OpenHands-bash, and OpenHands-bash can fail even on test cases included in the prompt.The authors suggest more sophisticated context engineering may explain the scaffold gap and identify context management as important for long-context reasoning.Source: §6.1 · pp. 6–7
- All evaluated models perform suboptimally, while Claude-4.6-Sonnet achieves the highest performance across evaluation metrics.The primary results are reported for RepoZero-Py2JS and RepoZero-C2Rust.Source: §6.1 · p. 6, Table 2 · p. 7, Table 3 · p. 7
- Pass rates generally rise with per-sample cost, but GLM-5.1 significantly outperforms GLM-5 at nearly identical cost.Claude-4.6-Sonnet sets the upper bound for pass rate and cost; the reported model hierarchy is also consistent with broader industry benchmarks.Source: §6.1 · p. 7, Figure 3 · p. 8
6.2 Test-time Scaling via ACE
- ACE substantially improves performance when test cases are dynamically generated and executed during inference.The reported RepoZero-Py2JS case study uses the DeepSeek V3.1 backbone with both OpenHands-bash and Mini-SWE-Agent.Source: §6.2 · p. 7, Table 4 · p. 8
Py2JS
- ACE’s directions include generating executable, verifiable tests and integrating predefined human- or LLM-generated tests into software-engineering workflows.The described retry settings compare coding alone with one or two coding-testing-refining cycles.Source: Py2JS · p. 8
6.3 Failure Analysis
- Runtime errors are infrequent; other failure categories include code-generation failures, failures on illustrative white-box tests, and black-box output mismatches.Agents also lose track of stated requirements during extended reasoning, a pattern described as contextual drift.Source: §6.3 · p. 8
- Agents that proactively design and run unit tests in the environment are commonly among the higher-performing agents.The authors describe this self-correcting capability as instrumental in mitigating runtime errors and connect environment use with test-driven development.Source: §6.3 · p. 8
- Approximately 40% of executable code generated by agents fails to match the source repository’s deterministic output.The authors use this gap between runnability and semantic correctness to support output-verified evaluation.Source: §6.3 · pp. 8–9
7 Related Works
Prior work covers repository maintenance, feature implementation, and from-scratch generation, but comprehensive verification for repository generation remains difficult.
7.1 Repo-level Coding Benchmarks
- Repository-level benchmarks extend from bug-fixing tasks to feature implementation, while from-scratch generation still faces scalability, leakage, and test-construction challenges.RepoZero frames reimplementation from source APIs as a way to automate test verification while supporting large-scale evaluation.Source: §7.1 · p. 9
7.2 LLM Coding Agents
- Most repository coding agents target bug fixing; the few described for generation from scratch sketch repositories before filling in code.The difficulty of rule-based verification is identified as a critical barrier to developing such agents.Source: §7.2 · p. 9
8 Conclusion
RepoZero evaluates end-to-end repository generation from scratch, with cross-language subsets intended to mitigate data contamination. Experiments report moderate success and identify self-verification as important.
8 Conclusion
- RepoZero evaluates construction of complete software projects from scratch and uses C2Rust and Py2JS cross-language subsets covering 600 test files.The protocol is presented as a way to ensure evaluation integrity and mitigate data contamination.Source: §8 · pp. 9–10
- Even state-of-the-art models with advanced scaffolds achieve approximately 40% success, and the paper identifies self-verification as important.The authors call for stronger integration of autonomous, high-quality test-suite synthesis.Source: §8 · p. 10
- The authors identify specialized training, better measures of codebase readability and integrity, and broader large-scale, multilingual, industry-level evaluation as future directions.Source: §8 · p. 10
Py2JS
The supplied passages describe model pass-rate reporting across five categories and an aggregate success rate for the full dataset.
Py2JS
- Model pass rates are reported across five categories, whose definitions are referenced in Figure 1.Source: Py2JS · p. 13
- Table 6 reports the full-dataset success rate averaged across all test cases.Source: Table 6 · p. 13
A Additional Results
The additional results define repository domains and report test-case construction details. They also state a limitation in the Mini-SWE-Agent model coverage.
A Additional Results
- The evaluation set spans five domains: Form, Crypto, Struc, Math/Sci, and Spec.These cover serialization and data formats; cryptography and encoding; data structures and utilities; mathematics and science; and specialized tools.Source: A Additional Results · p. 13
- Mini-SWE-Agent evaluation excludes proprietary GPT and Gemini models because of computational-resource constraints and inference costs.The authors plan to expand model coverage in future benchmark iterations.Source: A Additional Results · p. 13
- The test-generation prompt requests 60 cases per file; filtered files average about 40, with 20–60 cases per file.Source: A Additional Results · p. 13
Py2JS
The Py2JS experiments vary ACE retry depth, while a deeper analysis reports that retries improve sample-level pass rates. The prompts specify cross-language implementation constraints and an iterative test-and-refinement workflow.
Py2JS
- Py2JS success rates are averaged across Easy, Medium, and Hard tasks with retry limits of 0, 1, or 2.The settings correspond respectively to coding only, coding-testing-refining, and coding-testing-refining-testing-refining.Source: Py2JS · p. 13
B A Deeper Look into ACE
- Table 7 reports ACE success rates, and Retry-2 improves sample-level pass rate significantly despite only a marginal increase in individual test-case success.The authors suggest ACE helps resolve corner-case failures within samples.Source: Table 7 · p. 13, B A Deeper Look into ACE · p. 14
- The authors recommend comprehensive test-suite synthesis for self-verification and high-fidelity predictive oracles when large-scale test cases are difficult to obtain.They propose integrating such oracle models into ACE to augment coding-agent reasoning and self-correction.Source: B A Deeper Look into ACE · p. 14
C Prompts
- The Py2JS prompt requires Node.js ES modules, matching Python CLI arguments and output, and no external npm packages.Generated code must use .mjs files and Node.js built-in modules.Source: C Prompts · p. 15
- The Rust migration prompt requires a complete Rust 2021 project with matching CLI behavior and byte-identical output, using only the standard library.It also prohibits reading the C++ library source and requires black-box reimplementation.Source: C Prompts · p. 16
- ACE prompts request five CLI-argument test sets covering normal, boundary, and error inputs, then instruct refinement to fix existing code rather than rewrite it.Source: C Prompts · p. 16
Related papers
This paper cites
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues?2023
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering2024
- OpenHands: An Open Platform for AI Software Developers as Generalist Agents2024
- GLM-5: from Vibe Coding to Agentic Engineering2026
- Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces2026
- Kimi K2.5: Visual Agentic Intelligence2026
Cited by
- SpatialScout: Can VLM Agents Actively Explore and Map 3D Scenes?2026
- Doc2Harness: Benchmarking LLMs on Long-Horizon Harness Engineering of Coding Agents2026
- SWE-Journey: Towards More Realistic Evaluation of Coding Assistants through Long-Horizon, Multi-Turn Interaction2026
- When Sub-Agents Work in Parallel: The Promises and Pitfalls of Dynamic Concurrency in Long-Horizon Coding Tasks2026
- $τ^τ$-Bench: An Environment for End-To-End, Realistic Agent Construction2026
- Forward-Deployed Full-Stack Engineering for Autonomous Cloud MLOps2026