Silin Chen, Haoyi Teng, Xiaodong Gu, Yuling Shi, Jiale Huang, Yongpan Wang, Hongyu Zhang, Haibing Guan
5 min
Abstract
Large language model agents have made substantial progress in code generation, yet most existing systems assume a predefined repository architecture. This assumption does not hold in zero-to-all code generation, where an agent must construct an entire software project directly from natural-language requirements while maintaining a modular repository architecture throughout development. We present Repo0, a continuous structural evolution framework for zero-to-all code generation. Repo0 maintains an explicit architectural state instantiated as a Dual-Directed-Acyclic-Graph (Dual-DAG), consisting of a requirement-level DAG, a component-level DAG, and their alignment relation. Starting from natural-language requirements, it iteratively evolves component boundaries through structural actions guided by modularity metrics until structural convergence, after which the converged architecture guides test-driven development code generation. We evaluate Repo0 on six real-world repositories from RepoCraft using GPT-5 mini and DeepSeek V3.2. Repo0 achieves the highest Functionality Coverage and Pass Rate across all settings. Compared with RPG, the strongest repository-planning baseline, Repo0 improves Functionality Coverage by up to 20.08 percentage points and Pass Rate by up to 29.74 percentage points. Ablation and structural-evolution analyses further demonstrate the importance of the Dual-DAG architectural state, modularity-guided structural evolution, and explicit structural convergence.
Sam: And those measurements actually drive the system's decisions — it's not just guessing when to split a component apart or merge two together.
Alex: Exactly. If a component's internal pieces are too loosely related, the system splits it. If two components overlap heavily in what they're doing, it merges them. And once no more splits or merges are triggered, the system considers the architecture stable and moves on to writing the actual code.
Sam: So it has a genuine stopping rule, rather than just looping forever or giving up arbitrarily.
Alex: That's the key insight. And the evidence in the paper suggests this metrics-guided approach outperforms letting an AI decide on its own when the design is "good enough" — because without those guardrails, the system can wander away from a coherent structure.
Sam: What does that process actually look like in practice? Is it mostly tearing things down and rebuilding, or more like fine-tuning?
Alex: Mostly fine-tuning. The most common action is splitting components — refining boundaries that were drawn a little too broadly at first. Wholesale rebuilds are rare. That tells you that even an early draft usually contains workable pieces; the system is mainly adjusting the edges.
Sam: And once the architecture is locked in, what happens next?
Alex: It moves to the coding phase, using an approach where tests are written before the code that needs to pass them. That way, every piece of code has a clear target to hit, and the system can verify that what it writes actually matches what the user originally asked for.
Sam: That's a useful discipline even for human developers — it forces you to be precise about what "done" actually means before you start building.
Alex: It does. Now, the paper is also clear about where the limits are. The quality of those structural decisions depends heavily on how capable the underlying AI model is. If the core reasoning isn't strong enough, even well-designed metrics won't save you — the system might make split or merge decisions that miss the point entirely.
Sam: And there's a scope question too — these experiments were run on Python projects specifically. We don't yet know how well the same structural rules carry over to other programming languages.
Alex: The authors note that the underlying principles are technically language-agnostic, but that's still an open question waiting for more evidence.
Sam: So stepping back — what does this point toward, longer term?
Alex: It points toward software generation systems that don't just write a codebase once and hand it over. They could continuously refactor their own architecture as requirements shift — which, in real software projects, they always do. That's a meaningful step beyond the one-shot planning model that most current tools rely on.
Sam: It moves the conversation from "AI that writes code" to "AI that reasons about the structure of code over time." That's a different kind of capability.
Alex: And a more useful one for anything that needs to last longer than a weekend project. Thanks for listening to ResearchPod.