With Qoder's cognitive foundation, Ultra Spec, and Experts collaboration, a 10-person team safely merged 500,000 lines of Agent-written code into a four-million-line legacy system in three weeks.
Before V1.0 launched, I closed my laptop just as the final group of pull requests had passed every verification step and was ready to merge into the main branch. Every status indicator on the console was green.
By the time we reached v1.4.0, the 500,000 lines written by Agents had been running in production without a single online incident and were still being changed by new requirements every day.
Delivered and launched in three weeks, 99% generated by Agents, on top of a four-million-line legacy system.
Writing 500,000 lines in an empty project would not be much of a story. In a greenfield project, an Agent is free to choose the architecture and design the interfaces. No one tells it, "Do not touch that module."
The difficult part was that these 500,000 lines were written with Qoder into Qoder's own codebase. Using our product to build itself put the method and the product on the same lever: the product could work only if the method worked.
Our team had already been using Qoder's Agents for everyday coding for nine months. V1.0 needed to answer one question: would this way of working still hold at the scale of adding hundreds of thousands of lines in three weeks?
The night before kickoff, I spread the module-dependency diagrams of two repositories across three monitors: frontend on the left, backend in the center, and knowledge graph on the right. This was not an ordinary iteration touching a few modules. Five hundred thousand new lines had to be laid across four million existing ones. Every possible seam needed to be understood before work began.
From v0.1 last August to today, Qoder expanded to roughly four million lines in nine months. The frontend is a VS Code extension. The backend consists of Go services for Agent orchestration, the knowledge engine, and multi-model invocation, split across two repositories. Iteration was extremely fast. We had experienced small incidents before, and the interfaces carried historical baggage. Repo Wiki and the knowledge graph covered most inter-module dependencies, but some apparently redundant layers had more than ten callers behind them, while the reasons for certain compatibility logic were known only to the people who wrote it. That was manageable when daily work changed only a few modules, but the requirements were different when dozens of Agents were writing in parallel.
We needed to add four major modules: a standalone Quest view, the knowledge engine, multi-workspace parallelism, and Experts collaboration. The launch date was fixed. We had three weeks.
The team consisted of ten people: three on the frontend client extension, four on the Agent harness, and three on the knowledge engine. Every new module required cross-team collaboration.
Under a conventional model, the schedule for this workload would have been several times longer. This major upgrade also gave us a chance to test the real capacity boundary of Agents at this scale.
What happens when the volume rises? How do we ensure that code written simultaneously by dozens of Agents can still run reliably in the existing system?
That was the problem we had to solve over the next three weeks.
By the morning of day three, we still had not asked an Agent to write a single new line of code.
That may sound unreasonable. Why not let the Agents start running and adjust later?
Because those first two days turned out to have the highest return on investment of the entire three weeks. We first refreshed the knowledge layer:
Two days and zero lines of code—all spent building the foundation.
On day three, we finally began working on modules. But we did not begin with code. We began with Specs.
This was the step with the deepest human involvement and, in retrospect, the highest return.
An ordinary Spec explains what a feature should do. An Ultra Spec is different. Multiple Agents first conduct broad and deep research in parallel so nothing is missed, and then merge and converge the findings into a complete execution plan. Agents work quickly, but people still need to read, challenge, and make trade-offs on every research result. The final Spec must be detailed enough for an Agent to execute directly.
Working in a legacy system adds another perspective: every item must be reviewed from the old system's point of view. Which existing modules will the feature affect? Which old interfaces must remain compatible with the new ones? What unwritten conventions has everyone implicitly followed?
For example, an Ultra Spec for the memory module in the team-shared knowledge engine needed to clarify which conversations would be distilled, when distillation would be triggered, how memories would be stored and retrieved, the interface contract with the existing code-index system, degradation strategies for an oversized memory store, and memory-isolation boundaries between workspaces.
The multi-workspace module was similar. An ordinary Spec might say, "Each workspace maintains an independent Quest session without interference." An Ultra Spec kept asking questions. A scheduled task in the legacy system briefly locks a table—what happens when an overnight Agent attempts a write at the same time? Workspace paths appear in the IDE as directories,
Once the Ultra Spec was ready, it was time to hand it to Qoder. The knowledge-engine module spanned all three teams: the frontend IDE extension layer, the Go-based Agent orchestration backend, and the core retrieval logic owned by the knowledge-engine team. Nearly ten thousand lines had to change. We knew what would happen if one Agent handled the whole task from beginning to end: in the second half, it would forget earlier agreements. Even though Qoder IDE supports a one-million-token context window, attention dilution and context decay still occur as context grows. A larger window does not mean every token receives equal attention.
So we started Experts Mode.
A Team Lead expert does not write code. It reads the Ultra Spec's task list, identifies dependencies, breaks the work into a DAG, and delegates subtasks. Tasks with dependencies do not run in parallel, and tasks likely to edit the same file do not run simultaneously. Backend, frontend, testing, and review experts each take their own assignments in independent contexts.
That afternoon, I opened the Quest task board and watched 11 different Experts tasks progress at once. Within each task, a frontend expert built the memory-display component, a backend expert implemented storage and retrieval interfaces, a testing expert generated regression cases from the Spec, and a research expert scanned the legacy modules for compatibility boundaries. Every expert operated in its own independent context.
In the previous single-Agent mode, every choice—solution A or B, which encryption algorithm to use—could stop the Agent and require a person. With a Team Lead coordinating the whole task, it made many intermediate decisions directly and surfaced only irreversible choices as question cards for human judgment. I was barely interrupted that afternoon.
But speed was not the key, although it was genuinely fast.
The code written by the 11 experts in that module shared consistent style, naming, and layering. The same held globally: multiple Experts tasks ran in each of the four modules, yet cross-module code still followed team conventions. That consistency came from the newly refreshed shared knowledge engine and the same original decision records.
A colleague looked over at my screen and said, "It is more elegant than what our team writes."
The greatest change produced by this model was execution efficiency and judgment.
A single Agent might take a long time to run the same task and repeatedly stop to ask people questions. With Experts, parallelizable work runs in parallel, the Team Lead handles many intermediate decisions, and people confirm only key nodes. Ten colleagues formed three groups, each running Experts tasks for its own modules. The groups aligned boundaries through the knowledge graph and Ultra Spec. Over the three weeks, they ran thousands of subtasks—roughly, each person led more than 20 Experts tasks per day, and every expert split work further in parallel. Overall execution efficiency was an order of magnitude higher than single-Agent mode.
We gained something else too. Qoder's memory system developed a genuine flywheel under this intensive use. After an expert Agent completes a run, experience is automatically accumulated as an Expert Skill—for example, how to start a module's test environment or which historical pitfalls an interface contains. Key decisions enter the knowledge engine, while obsolete information is automatically forgotten or replaced. The effect became increasingly visible over the three weeks.
At the end of the third week, all 500,000 new lines had entered the main branch. The standalone Quest view, knowledge engine, multi-workspace parallelism, and Experts collaboration were integrated into Qoder V1.0.
All four modules were ready the night before delivery. Ten people, three weeks, 500,000 lines: that was the capacity produced by this method.
People participated most deeply in writing the Ultra Spec at the beginning. While Agents wrote code in parallel, each group moved on to its next high-value work. The frontend group prepared interaction sketches for the next module. The Agent group handled cross-module decisions escalated by Team Leads. The knowledge-engine group worked with research Agents to calibrate legacy boundaries.
In The Mythical Man-Month, Brooks wrote that adding people to a late project only makes it later. Teams are actively practicing the alternative—adding Agents instead of people—but succeeding in production requires more than having a Coding Agent. Agents need to run in the right environment and system, under constraints and conventions, with problems traceable when they occur. Without that foundation, adding Agents resembles adding people, and delivery lead time does not shrink.
When we reviewed V1.0, these were the things we got right:
That concludes the first part.
But you may have noticed a missing step. I skipped the journey from 500,000 lines written by Agents on branches to production. After Ultra Spec set the direction and Experts delivered the code, one guardrail still stood between the code and a safe merge and release.
That guardrail had two parts: Ultra Review before merge, and Computer Use + Nightly Auto-Heal after merge, when people leave work and machines take over. Agent-generated code appears far faster than people can review it. Ultra Review uses multiple Agents in parallel to match code-generation speed. Computer Use + Nightly Auto-Heal lets machines run the discover-fix-verify loop themselves, moving people out of the bug pipeline.
Together, we call these capabilities Autonomous Engineering. The method changes from people directing multiple Agents to machines running the loop themselves.
Contact us for more enterprise solutions ➔
The Eve of Project Kickoff
Our team had already been using Qoder's Agents for everyday coding for nine months. V1.0 needed to answer one question: would this way of working still hold at the scale of adding hundreds of thousands of lines in three weeks?
The night before kickoff, I spread the module-dependency diagrams of two repositories across three monitors: frontend on the left, backend in the center, and knowledge graph on the right. This was not an ordinary iteration touching a few modules. Five hundred thousand new lines had to be laid across four million existing ones. Every possible seam needed to be understood before work began.
Day Three, and Not a Single Line of Code Yet
By the morning of day three, we still had not asked an Agent to write a single new line of code.
That may sound unreasonable. Why not let the Agents start running and adjust later?
Because those first two days turned out to have the highest return on investment of the entire three weeks. We first refreshed the knowledge layer:
- Repo Wiki received a full refresh. Repo Wiki is a Qoder capability that automatically generates repository-level documentation from code, comments, documents, and commit history without manual intervention. With dozens of Agents about to read the same global view in parallel, we triggered a complete refresh.
- The code knowledge graph received a deep update. This is also a Qoder capability. It automatically models module dependencies, interface contracts, and data flow. We focused on modules added in the previous month and recent interface changes.
- Historical Specs and original decisions were added to the repository. Commit history shows how code changed, but not why a design was chosen. The reasons certain interfaces were deprecated or compatibility layers existed lived only in a few colleagues' memories. We organized that information into documents so Agents could use it too.
"One More Day on the Spec Saves a Week Later"
This was the step with the deepest human involvement and, in retrospect, the highest return.
An ordinary Spec explains what a feature should do. An Ultra Spec is different. Multiple Agents first conduct broad and deep research in parallel so nothing is missed, and then merge and converge the findings into a complete execution plan. Agents work quickly, but people still need to read, challenge, and make trade-offs on every research result. The final Spec must be detailed enough for an Agent to execute directly.
Working in a legacy system adds another perspective: every item must be reviewed from the old system's point of view. Which existing modules will the feature affect? Which old interfaces must remain compatible with the new ones? What unwritten conventions has everyone implicitly followed?
For example, an Ultra Spec for the memory module in the team-shared knowledge engine needed to clarify which conversations would be distilled, when distillation would be triggered, how memories would be stored and retrieved, the interface contract with the existing code-index system, degradation strategies for an oversized memory store, and memory-isolation boundaries between workspaces.
The multi-workspace module was similar. An ordinary Spec might say, "Each workspace maintains an independent Quest session without interference." An Ultra Spec kept asking questions. A scheduled task in the legacy system briefly locks a table—what happens when an overnight Agent attempts a write at the same time? Workspace paths appear in the IDE as directories, .code-workspace files, or URIs—which forms does the new code support? Worktree paths are different again—has that been considered? Agents will not think of these questions for you. If they are not raised during the Spec phase, they become a chain of emergency hotfixes after launch.
Writing the Spec was not the end. We started multiple Agents to review the same Spec from different perspectives: an architect examined module boundaries, a security expert looked for permission vulnerabilities, a performance expert anticipated bottlenecks, and a legacy-system expert connected to the knowledge graph checked compatibility. A verifier Agent worked backward to filter out false issues created by Agent hallucinations. People made the final decisions, focusing on SLO definitions and irreversible operations.
Some may think this process is too heavy. Is spending so much effort on a Spec putting the cart before the horse? My experience is that the calculation should be reversed: one more day on the Spec saves a week later. Once an Agent starts writing code, correction costs multiply. Anything not clarified in the Spec returns during integration at ten times the cost.
"More Elegant Than What Our Team Writes"
Once the Ultra Spec was ready, it was time to hand it to Qoder. The knowledge-engine module spanned all three teams: the frontend IDE extension layer, the Go-based Agent orchestration backend, and the core retrieval logic owned by the knowledge-engine team. Nearly ten thousand lines had to change. We knew what would happen if one Agent handled the whole task from beginning to end: in the second half, it would forget earlier agreements. Even though Qoder IDE supports a one-million-token context window, attention dilution and context decay still occur as context grows. A larger window does not mean every token receives equal attention.
So we started Experts Mode.
A Team Lead expert does not write code. It reads the Ultra Spec's task list, identifies dependencies, breaks the work into a DAG, and delegates subtasks. Tasks with dependencies do not run in parallel, and tasks likely to edit the same file do not run simultaneously. Backend, frontend, testing, and review experts each take their own assignments in independent contexts.
That afternoon, I opened the Quest task board and watched 11 different Experts tasks progress at once. Within each task, a frontend expert built the memory-display component, a backend expert implemented storage and retrieval interfaces, a testing expert generated regression cases from the Spec, and a research expert scanned the legacy modules for compatibility boundaries. Every expert operated in its own independent context.
In the previous single-Agent mode, every choice—solution A or B, which encryption algorithm to use—could stop the Agent and require a person. With a Team Lead coordinating the whole task, it made many intermediate decisions directly and surfaced only irreversible choices as question cards for human judgment. I was barely interrupted that afternoon.
But speed was not the key, although it was genuinely fast.
The code written by the 11 experts in that module shared consistent style, naming, and layering. The same held globally: multiple Experts tasks ran in each of the four modules, yet cross-module code still followed team conventions. That consistency came from the newly refreshed shared knowledge engine and the same original decision records.
A colleague looked over at my screen and said, "It is more elegant than what our team writes."
Thousands of Subtasks, Ten People
The greatest change produced by this model was execution efficiency and judgment.
A single Agent might take a long time to run the same task and repeatedly stop to ask people questions. With Experts, parallelizable work runs in parallel, the Team Lead handles many intermediate decisions, and people confirm only key nodes. Ten colleagues formed three groups, each running Experts tasks for its own modules. The groups aligned boundaries through the knowledge graph and Ultra Spec. Over the three weeks, they ran thousands of subtasks—roughly, each person led more than 20 Experts tasks per day, and every expert split work further in parallel. Overall execution efficiency was an order of magnitude higher than single-Agent mode.
We gained something else too. Qoder's memory system developed a genuine flywheel under this intensive use. After an expert Agent completes a run, experience is automatically accumulated as an Expert Skill—for example, how to start a module's test environment or which historical pitfalls an interface contains. Key decisions enter the knowledge engine, while obsolete information is automatically forgotten or replaced. The effect became increasingly visible over the three weeks.
Three Weeks Later
At the end of the third week, all 500,000 new lines had entered the main branch. The standalone Quest view, knowledge engine, multi-workspace parallelism, and Experts collaboration were integrated into Qoder V1.0.
All four modules were ready the night before delivery. Ten people, three weeks, 500,000 lines: that was the capacity produced by this method.
People participated most deeply in writing the Ultra Spec at the beginning. While Agents wrote code in parallel, each group moved on to its next high-value work. The frontend group prepared interaction sketches for the next module. The Agent group handled cross-module decisions escalated by Team Leads. The knowledge-engine group worked with research Agents to calibrate legacy boundaries.
In The Mythical Man-Month, Brooks wrote that adding people to a late project only makes it later. Teams are actively practicing the alternative—adding Agents instead of people—but succeeding in production requires more than having a Coding Agent. Agents need to run in the right environment and system, under constraints and conventions, with problems traceable when they occur. Without that foundation, adding Agents resembles adding people, and delivery lead time does not shrink.
When we reviewed V1.0, these were the things we got right:
- Cognitive foundation (Repo Wiki + code knowledge graph + historical Specs): enabled Agents to understand the current state and history of the legacy code without repeatedly realigning context.
- Ultra Spec (divergent-then-convergent Specs + cross-review by multiple Agents): exposed ambiguity and rework risk before implementation, avoiding mutually destructive changes during integration.
- Experts collaboration (Team Lead + specialized Agents in parallel): divided large tasks into parallelizable subtasks rather than leaving everything on a single thread.
The Story Is Not Over
That concludes the first part.
But you may have noticed a missing step. I skipped the journey from 500,000 lines written by Agents on branches to production. After Ultra Spec set the direction and Experts delivered the code, one guardrail still stood between the code and a safe merge and release.
That guardrail had two parts: Ultra Review before merge, and Computer Use + Nightly Auto-Heal after merge, when people leave work and machines take over. Agent-generated code appears far faster than people can review it. Ultra Review uses multiple Agents in parallel to match code-generation speed. Computer Use + Nightly Auto-Heal lets machines run the discover-fix-verify loop themselves, moving people out of the bug pipeline.