With Qoder's cognitive foundation, Ultra Spec, and expert-team collaboration, 10 people merged 500K lines of Agent code into a 4-million-line legacy codebase in 3 weeks.
Back
Right before V1.0 launched, as I closed my laptop, the last batch of PRs had just cleared every validation step and was ready to merge into the main branch. The status bar on the console was all green.
Today it has iterated to v1.4.0. These 500,000 lines of Agent-written code have run in production ever since launch without a single production incident, and they're still being changed daily to meet new requirements.
Delivered and launched in 3 weeks, 99% generated by Agents, running on a 4-million-line legacy codebase.
If it were just writing 500K lines on an empty project, honestly there'd be nothing to talk about. On a blank project, Agents have free rein—they set the architecture, design the interfaces, and no one tells you "don't touch that module."
What's hard is that these 500,000 lines were written into Qoder's own codebase, using Qoder. Building your own product with your own product puts the method and the product on the same lever at once: only if the method holds up does the product hold up.
Our team writes code day-to-day using Qoder's own Agents, and we've been running this way for the past 9 months. V1.0 had only one question to answer: does this way of working still hold up at the scale of adding hundreds of thousands of lines in 3 weeks?
The night before kickoff, I spread the module dependency graphs of the two repositories across three screens—frontend on the left, backend in the middle, knowledge graph on the right. This time it wasn't the usual tweak of a few modules; it was 500K lines of new code being laid onto 4 million lines of legacy. Every possible seam had to be seen clearly before we started.
Since Qoder's v0.1 launch last August, it has ballooned to around 4 million lines in 9 months: the frontend is a VS Code extension, and the backend—Agent scheduling, the knowledge engine, and multi-model calls written in Go—lives in two repositories. It iterates extremely fast; there have been minor incidents before, and the interfaces carry plenty of historical baggage. Repo Wiki and the knowledge graph cover most of the inter-module dependencies, but some seemingly redundant intermediate layers have a dozen callers behind them, and some compatibility logic is understood only by the person who wrote it—why it was routed so awkwardly at the time. Tweaking a few modules in daily iteration is fine, but having dozens of Agents write code on it simultaneously is a different requirement.
On top of this, we had to add 4 core modules: the standalone Quest window, the knowledge engine, multi-workspace parallelism, and expert-team collaboration. The launch date was already set—3 weeks.
The team had 10 people: 3 on the frontend client extension, 4 on the agent harness, and 3 on the knowledge engine. Every new module required cross-team collaboration.
Under a traditional model, this workload would normally take at least several times the schedule. This full-scale upgrade also let us validate the real productivity boundary of Agents at this scale.
What happens once the volume goes up? How do you ensure that what dozens of Agents write at the same time can still run stably in the legacy system?
That was the problem to solve over the next three weeks.
By the morning of the third day, we still hadn't let the Agents write a single line of new code.
You might find this unreasonable: why not just get the Agents running first?
Because the work we did over those two days later proved to be the highest-ROI investment of the entire three weeks. First, we refreshed the knowledge layer to the latest state:
● Repo Wiki ran a full update. This is a Qoder product capability that automatically generates repository-level documentation from code, comments, docs, and commit history—no manual intervention needed. This time dozens of Agents would read the same global view in parallel, which triggered a full refresh.
● The code knowledge graph went through a round of deep completion. Also a product capability, it automatically models module dependencies, interface contracts, and data flows. The focus was on consolidating the modules and interface changes added over the past month.
● We added historical Specs and original decision records into the repo. Commit history shows how the code changed, but not why it was designed that way at the time. Why some interfaces were deprecated and how compatibility layers came to be existed only in a few colleagues' heads; this time we organized it all into documentation so Agents could reference it too.
These three layers together are what we internally call the "cognitive foundation." Because dozens of Agents would autonomously deliver code based on the same shared understanding, any gap would be amplified.
Two days, zero lines of code. All spent building the foundation.
Only on the third day did we start on the modules. But what we started on wasn't code—it was the Spec.
This was the step where humans were most deeply involved throughout the process, and also the one that, in retrospect, delivered the highest returns.
An ordinary Spec writes down "what this feature should do." Ultra Spec is different: first, multiple Agents run broad research and deep research in parallel to make sure nothing is missed, then the results are merged and converged into a complete execution plan. Agents run fast, but every piece of research they produce still needs a human to read, question, and make the final call on trade-offs. Ultimately this Spec has to be written to the point where an Agent can run against it directly.
Working in a legacy codebase adds one more layer of consideration: every item has to be reviewed again from the perspective of the old system. Which old modules will the new feature affect? Which old interfaces must the new interfaces stay compatible with? What are the unwritten rules that everyone tacitly follows?
Take the memory module in the team-shared knowledge engine as an example. Ultra Spec needs to clarify: what types of conversations get distilled, the trigger timing for distillation, the storage and retrieval structure of memory, the interface contract with the existing code indexing system, the degradation strategy when the memory store grows too large, and the boundaries of memory isolation between different workspaces.
The same goes for another module. For multi-workspace parallelism, an ordinary Spec would just write "each workspace independently maintains its Quest session, without interfering with one another." Ultra Spec keeps probing: the legacy system has scheduled jobs that briefly lock tables—what happens when an overnight long-running Agent's writes collide with them? Workspace paths come in three formats in the IDE—directory, .code-workspace file, and URI—which ones does the new code support? Paths differ again in the Worktree scenario—was that considered? Agents won't think of these for you proactively; if you don't surface them at the Spec stage, they become a string of emergency hotfixes after launch.
Even after writing it, you're not done. We simultaneously spin up multiple Agents to review the same Spec from different angles: the architect looks at module boundaries, the security expert looks for permission vulnerabilities, the performance expert anticipates bottlenecks, and the legacy-system expert (attached to the knowledge graph) checks compatibility. There's also a validator Agent dedicated to reverse reasoning, picking out false problems caused by Agent hallucination. Finally, a human makes the call, focusing on SLO definitions and irreversible operations.
Some may feel this step is too heavy—isn't putting so much effort into the Spec upfront putting the cart before the horse? My take is that you should do the math the other way around: spend one more day on the Spec, save a week later. Once Agents start writing code, the cost of correcting errors multiplies. If you don't sort out the problems at the Spec stage, they'll come back to you tenfold during integration.
With Ultra Spec done, it was time to hand it off to Qoder to run. The knowledge engine module had to span our three teams—the frontend IDE extension layer, the Go backend's Agent scheduling, and the core retrieval logic owned by the knowledge engine team all had to change, with a change size close to ten thousand lines. We've seen what happens when you let a single Agent thread it all from start to finish: partway through it "forgets" the conventions set earlier. Even though Qoder Desktop already supports a 1M context window, once the context gets long, attention dilution and context rot still happen. A bigger window doesn't mean every token gets equal attention.
So we launched Experts Mode.
A Team Lead expert doesn't write code; it only reads the task list in the Ultra Spec, untangles the dependencies, and splits them into subtasks as a DAG to dispatch downward. Those with sequential dependencies don't run in parallel; those that might modify the same file don't run at the same time. The backend expert, frontend expert, testing expert, and review expert each take their own share, and each runs in an independent context.
That afternoon I opened the Quest task board, with 11 different expert-team tasks rolling at the same time. Within each expert-team task, the frontend expert was building the memory display component, the backend expert was writing the storage and retrieval interfaces, the testing expert was generating regression cases based on the Spec, and the research expert was scanning the compatibility boundaries of legacy modules. Every expert executed in its own independent context.
Under the old single-Agent model, whenever the Agent hit any choice (Plan A or Plan B? Which encryption algorithm?) it had to stop and ask a human. Now the Team Lead coordinates the whole picture, making a large number of intermediate decisions directly; only irreversible choices proactively pop up a question card for a human to decide. I was hardly interrupted that entire afternoon.
But the key isn't the speed (although it is indeed fast).
It's that within this one module, the code style, naming, and layering produced by the 11 expert-team tasks were consistent with one another; and the same held globally—the 4 modules each ran multiple expert-team tasks, and the cross-module code also conformed to the team's project conventions. This relied on the just-refreshed team-shared knowledge engine and adherence to the same original decision records.
A colleague next to me leaned over to look at my screen and said, "That's more elegant than what our own team writes."
The biggest change this model brings is execution efficiency and judgment.
For the same task, letting a single Agent run from start to finish might take a very long time, with constant questions to humans in between. Switch to the expert team, and whatever can run in parallel runs in parallel; the Team Lead handles a large number of intermediate decisions on the human's behalf, and people only need to confirm at key nodes. The 10 colleagues split into three groups, each running the expert teams for its own module, with groups aligning boundaries through the knowledge graph and Ultra Spec. Over three weeks, a thousand subtasks were run (roughly each person led 20-some expert-team tasks per day, with each expert further splitting work in parallel internally), and overall execution efficiency was an order of magnitude higher than the single-Agent model.
Another gain: Qoder's memory system produced a real flywheel effect during this round of intensive use. After an expert Agent finishes a round, its experience is automatically distilled into an Expert Skill (how to bring up the test environment for a certain module, what historical pitfalls a certain interface has), key decisions enter the knowledge engine, and outdated information is automatically forgotten and overwritten. Over the three weeks, this effect became more pronounced the further along we got.
At the end of the third week, all 500,000 lines of new code had gone into the main branch. The standalone Quest window, the knowledge engine, multi-workspace parallelism, and expert-team collaboration—four modules—were integrated into Qoder V1.0.
The night before delivery, all four modules were ready. 10 people, 3 weeks, 500K lines—this is the productivity this method produced.
Where humans were most deeply involved over the three weeks was writing the Ultra Spec upfront. While the Agents ran code in parallel, the three groups were each advancing the next round: the frontend group prepared interaction drafts for the next module, the Agent group handled cross-module decisions escalated by the Team Lead, and the knowledge engine group worked with the research Agent to calibrate legacy boundaries. Everyone was doing their highest-value work.
Brooks wrote in The Mythical Man-Month: adding people to a late project only makes it later. "Don't add people, add Agents" is something everyone is also actively practicing in production, but the real prerequisite for making it work isn't having a Coding Agent available—it's that the Agent can be correctly run within a suitable environment and system, constrained, rule-abiding, and traceable when something goes wrong. If this step isn't done well, adding Agents is just like adding people: the delivery turnaround won't shorten.
When we reviewed Project 1.0, here's what we got right:
● Cognitive foundation (Repo Wiki + code knowledge graph + historical Specs): lets Agents understand the current state and the full context of the legacy code, without repeatedly re-aligning context
● Ultra Spec (diverge-then-converge Spec + multi-Agent cross review): lays out ambiguities and rework risks before starting, eliminating mutual overrides during integration
● Expert-team collaboration (Team Lead + specialized Agents in parallel): splits big tasks into parallelizable subtasks to run, without getting stuck on a single thread
What these three parts jointly solved was the question I asked myself on day one of those first three weeks: can the 500,000 lines of code written by Agents be stably maintained and continuously iterated within this 4-million-line legacy system, without becoming a black box no one dares to touch.
The answer as of today is: no production incident since launch, and still being changed daily by new requirements.
That wraps up Part One.
But you may have also noticed a problem: for the 500,000 lines of Agent-written code, I skipped the stretch between branch and launch. After Ultra Spec sets the direction right and Experts Mode delivers the code, there's still a guardrail between that and "daring to merge into the main branch, daring to push to production."
The guardrail consists of two parts: Ultra Review after writing but before merging, and Computer Use + Nightly Auto-Heal, where machines take over after people go home. Agents generate code far faster than humans can review it; the former uses multi-Agent parallel review to keep pace with the speed of writing code, while the latter lets machines run the discover-fix-validate loop on their own, moving humans off the bug assembly line.
These two parts are what we call Autonomous Engineering. From "humans directing multiple Agents" to "machines running the closed loop themselves," the form of the method has changed.