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.
Alex: Welcome to another episode of ResearchPod. Today we're looking at how autonomous artificial intelligence agents build complex software systems completely from scratch.
Sam: When most people use AI for coding, the system starts with an existing project folder and fills in the missing pieces. But this paper looks at something more ambitious — generating an entire codebase from nothing, where the agent has to create every file and every folder without any initial structure to lean on.
Alex: And that's where the central puzzle comes in. Current tools treat software architecture like a one-shot decision — you make a plan upfront, and then you build to that plan, no matter what you discover along the way.
Sam: So the question this paper is really asking is: can an autonomous agent design, build, and fix a multi-file project structure as it goes — learning and adjusting rather than committing blindly to an early guess?
Alex: Exactly. The authors present a framework called Repo0, and its core idea is that a software project's structure shouldn't be frozen at the start. It should evolve continuously as the system learns more about what the code actually needs to do.
Sam: That's a bit like hiring a contractor who doesn't just draw a blueprint and build the whole house without looking up. Instead, they check the framing as it goes up, and if two rooms are going to collide awkwardly, they catch it before the walls go in.
Alex: That's the right analogy. And the reason this matters is that a project's natural boundaries — which pieces of code belong together, which should be kept separate — aren't always obvious at the start. You often only see them once you've written some of the code itself.
Sam: So how does Repo0 actually keep track of all those moving parts without losing sight of what the user originally asked for?
Alex: It maintains the project's state using two separate maps that are linked together. Think of one map as tracking the goals — what the software is supposed to accomplish and how those goals relate to each other. The other map tracks the code — which files exist and how they depend on one another. Keeping these two maps separate is important because it stops the system from confusing "what we're trying to do" with "how we're currently doing it."
Sam: And without that separation, an AI agent can easily end up with code that's tangled — where changing one file unexpectedly breaks five others, or where a single file is trying to do too many unrelated things at once.
Alex: Right. There are two specific problems that come up. The first is low cohesion — imagine a kitchen drawer that holds spatulas, batteries, old receipts, and a screwdriver. Everything's in one place, but nothing really belongs together. The second is high coupling — where components are so intertwined that you can't touch one without disturbing everything connected to it. Repo0 uses measurable targets for both of these to decide when the architecture needs adjusting.
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.