4M + 500K Lines, Rebuilding a Giant App in 3 Weeks

This Isn't a Greenfield Project

Earlier this year we published a case study: a five-person team shipped QoderWork in seven days using Qoder, work that would have taken twenty engineers several weeks the conventional way. That story was a zero-to-one project — a clean codebase, our own rules, our own architecture, AI writing code onto a blank page with no historical baggage. This article is the opposite story. This time the AI wasn't staring at a blank page. It was staring at a multi-year, multi-repo, multi-million-line production system. The system we were upgrading is Qoder itself. Qoder is a real, running, complex system: the frontend is a VS Code IDE extension, the backend is a Go service handling agent orchestration, knowledge engine, and multi-model invocation system, and frontend and backend live in separate repos that together come to roughly four million lines of code. Architectural decisions from years past are scattered throughout the code. Implicit dependencies between modules have never been fully documented. Any sizable change can trigger a chain reaction. On top of this system we needed to ship a brand-new 500K-line feature module — the full Quest overhaul that became Qoder V1.0:

A redesigned standalone Quest view: directing AI like dispatching tasks, with a completely reworked interaction model
A fully refreshed Editor: a systematic upgrade of the coding experience
A knowledge engine: code distilled into knowledge, memory extracted from conversations, agents that get smarter the more you use them
Multi-workspace, multi-task parallelism: cross-project coordination, multiple tasks delivered in parallel
Experts Mode collaboration plus custom experts: parallel division of labor, flexible configuration

Delivery deadline: three weeks. We used Qoder to build Qoder, and along the way we worked out a methodology specifically tuned for legacy giants — a combination of Agentic Engineering and Autonomous Engineering. What follows is the full account.

4M + 500K, rebuilding a giant app in 3 weeks

Foundation First: Letting AI Actually Read Four Million Lines

The first obstacle to bringing AI into a legacy system isn't that the AI isn't smart enough. It's that the AI has no idea what has happened inside that system. LLM context windows are bounded; you cannot stuff four million lines into them. The harder problem is that even if you could, the AI wouldn't know which lines are load-bearing architectural conventions, which are historical compromises someone made under deadline pressure, and which interfaces look refactorable but actually have a dozen callers depending on them. An AI that knows nothing about the legacy system writes new code that reads as foreign material — inconsistent style, incompatible interfaces, quietly violating a handful of unwritten rules, then exploding during integration. Our answer was to build out the AI's cognitive infrastructure before writing a single line of code. Three layers in total. The first two come from Qoder's product capabilities — Repo Wiki for the macro architectural view, the code knowledge graph for precise call relationships. The third is something we added through engineering discipline: keeping the spec and decision text of every major change checked into the repo, so the AI can not only see what the system looks like now, but trace why it became that way. Building Qoder with Qoder gave us the chance to build all three layers out fully.

Layer 1: Repo Wiki (Qoder built-in)

A repository-level document auto-generated from the code and updated alongside code changes. It covers overall project architecture, module boundaries, core data flows, and the cross-module reference graph. It takes the structural relationships scattered across four million lines and consolidates them into a project document you can actually read end-to-end. Code by itself can tell you what an individual file does, but it can't tell you how the system is organized as a whole. Repo Wiki fills in exactly that panoramic view. Repo Wiki is, in effect, a project map for the AI. A new AI agent doesn't need to crawl files one by one to reconstruct system structure. It reads the map and gets oriented immediately — how modules are partitioned, how dependencies flow, where the critical paths run.

Layer 2: Code Knowledge Graph (Qoder built-in)

Through static analysis combined with AI-driven understanding, the entire codebase is structurally modeled: module dependencies, interface contracts, data flow direction, read/write paths of core data structures. This isn't a simple call graph — it's a queryable knowledge base. When the AI generates new code, it can query in real time: "Who currently calls this interface?" "Where is this data structure mutated?" "If the new Quest view reuses this component, which existing features will it affect?" Repo Wiki shows the AI the rough shape of the project. The knowledge graph lets the AI look up the exact call situation of any given interface. One coarse, one fine — the two faces Qoder ships with.

Layer 3: Historical Spec Archive (accumulated engineering practice)

The first two layers come from Qoder's product capabilities. They let the AI see what the system looks like today. But there's still a missing layer — how this architecture evolved into its present shape. Why a particular interface was deprecated, what production incident a seemingly redundant compatibility shim was responding to — those decision trails usually live only in the memory of the people who were there. Once those people leave, the trail is gone, and the next refactor has to reverse-engineer intent from code, stepping into the same pits all over again. This layer isn't something a product feature can hand you directly. You have to deposit it through engineering discipline. We keep the spec and decision text of every major change checked into the repo. When the AI fixes a bug or adds a feature, it doesn't just see what the code looks like now — it can reach back and ask why it became this way. The repo stops being a snapshot of current code and becomes a queryable engineering archive. Two layers of product capability plus one layer of engineering practice — that's the foundation. Skip any of them and the AI is building on sand.

Ultra Spec: Write the Spec Through Before Writing Code

With the foundation laid, we did not rush to code. The first move in the QoderWork sprint was already "write specs, not code." Inside a legacy system, this principle has to be enforced even more strictly — once the AI starts generating code, the cost of correcting course rises sharply. We call this stage Ultra Spec. A regular spec describes what a feature is. An Ultra Spec describes every dimension of that feature, precise enough that the AI can implement directly from it, surfacing every issue that would otherwise cause rework. It has a fixed set of dimensions: functional goals, I/O contracts, business rules, edge cases, security boundaries, and a test plan. Each dimension has to be machine-readable — I/O is JSON Schema, not prose; every business rule maps to concrete inputs and outputs; security boundaries are split into three tiers: must-do, ask-first, must-not. In a legacy system, every dimension also has to carry a "legacy lens." Functional goals must call out which existing modules are affected. I/O contracts must align with existing interfaces and explicitly preserve forward compatibility. Business rules must surface the implicit conventions of the legacy system — never let the AI guess. Edge cases must cover dirty historical data. Security boundaries must list off-limits regions of code. The test plan must include regression coverage for legacy functionality. Without this lens, what the AI produces is foreign material. Take the knowledge engine module. Its spec is not just the sentence "extract memory from conversations." It precisely defines: what kinds of conversations get extracted, when the extraction triggers, the storage and retrieval structure for memory, the interface contract with the existing code indexing system, the degradation strategy when the memory store grows too large, and the isolation boundary rules between memories of different workspaces. Every line has concrete I/O. "It depends" is not allowed. Finishing the spec isn't the finish line. From there it enters multi-agent cross-review. We launch several sub-agents with different perspectives to audit the same spec independently: an architect agent checks module boundaries and interface design, a security agent looks for permission holes and data leakage, a performance agent predicts slow queries and high-frequency call bottlenecks, a legacy-system agent (backed by the knowledge graph) checks compatibility with existing code. After that comes a verification pass: an independent verifier agent reverse-derives every flagged defect to weed out hallucinated false positives. Final authorization is human — focused on the parts that touch SLO definitions and irreversible operations. The time invested at the Ultra Spec stage is leveraged. A day spent here saves several days of debugging and rework downstream.

Experts Mode: Turning the Spec Into Parallel Engineering

Ultra Spec breaks a module's requirements into a structured plan with clean dependencies. But there's still one gap on the way to delivery. A single module like the knowledge engine or multi-workspace parallelism spans the frontend IDE extension, the Go backend, agent orchestration, and the model invocation chain — thousands to tens of thousands of lines of change. If a single agent threads it end-to-end, the parallel branches Ultra Spec worked so hard to identify get serialized again. Worse, attention dilutes over long contexts and the conventions established early in the run quietly drift in the back half. Earlier versions of Qoder hit exactly this awkwardness: an agent task would clearly "forget" its opening as it neared the end. Experts Mode is built to close that gap. It's a Team Lead plus a set of specialist agents. The Team Lead doesn't write code. It reads the Ultra Spec task list, identifies dependencies, and dispatches work in DAG order to backend, frontend, testing, review, and research specialists. Each specialist runs in its own context, so they don't crowd each other out. The substantive difference between this and "just open several agent windows at once" is coordination: those windows have none. Experts Mode translates the DAG that Ultra Spec already identified directly into an execution plan, so frontend and backend can advance simultaneously. When ambiguous choices come up mid-execution — which encryption algorithm, whether the compatibility strategy should degrade or fail loudly — the Team Lead surfaces the candidates for a human decision before dispatching, instead of letting the AI guess in silence. Experts Mode also doesn't force every specialist to use the same top-tier model. Lightweight roles like researchers and bootstrap engineers run on cheaper, faster models. Architecture-critical reviewers and complex refactor engineers run on flagship models. The blended cost lands at one-half to one-fifth of running flagship-everywhere, while the intelligence floor on the critical path doesn't drop. Across three weeks we ran hundreds to thousands of sub-tasks. Putting every one of them on the most expensive model would have blown the budget; putting all of them on the cheapest would have left quality unguarded at critical nodes. Heterogeneous scheduling sits exactly on that budget curve. Experts Mode also retains what the team has learned. Each specialist accumulates an Expert Skill (how to spin up the test environment for a given module, the historical pitfalls of a given interface). At the team level, a Team Skill accumulates (which dispatch pattern works best for which class of task). The next time a similar workload comes through, this experience plugs straight in.

Ultra Review: Surfacing the Details Inside AI-Written Code

A new bottleneck shows up immediately: AI generates code far faster than humans review it. Qoder runs many Quests in parallel — knowledge engine, multi-workspace parallelism, Experts Mode collaboration — all advancing at the same time, each module potentially producing thousands of lines of code per day. If review stays linear and single-threaded, it instantly becomes the chokepoint of the whole pipeline, and however fast the AI runs, the gain is canceled out. Our answer is Ultra Review: turn code review from single-threaded into multi-agent parallel. Concretely, every PR gets a group of agents reviewing it in parallel. They start scanning from different positions in the code, with different traversal paths and different context loading orders. The point is to counteract the LLM's context-window bias — a single agent reading top-to-bottom tends to "thin out" its attention in the back half and miss problems. After the parallel pass comes verify and dedup: weed out hallucinated false positives, merge duplicate findings where multiple agents flagged the same issue. Review concentrates on a handful of dimensions: correctness, security, performance, architectural consistency, maintainability. Architectural consistency matters disproportionately on this project — 500K lines of new code that drift away from the legacy system's architectural style will compound technical debt exponentially. Every piece of AI-generated code gets checked: does the naming match legacy conventions? Does the layering match existing modules? Does it bypass the legacy abstraction layer to manipulate internals directly? Ultra Review has one rule: chase logic errors, ignore style. Style goes to linters and formatters. AI's review compute stays on what actually matters.

Computer Use Validation: AI Grows Eyes and Hands

Once the code is written and review is clean, you still have to verify the feature actually works. Traditional automated testing has a structural problem: writing the test scripts is itself a large chunk of work, the scripts usually only cover the happy path, edge cases need separate authoring, and maintenance cost grows linearly with code volume. Computer Use changes the framing. Qoder takes over the local development environment directly — screenshotting, locating coordinates, simulating keyboard and mouse — operating like a real person. You don't write test scripts. You describe the behavior to verify, and the AI handles the rest:

Spin up the IDE and confirm code state
Run the project and wait for services to come up
Open browser or IDE surfaces and execute the full business flow
Verify results against the expected outputs defined in the spec
Cover edge cases: empty inputs, permission boundaries, concurrent scenarios, legacy data compatibility

Take multi-workspace parallelism. Validation isn't "can it open multiple workspaces." It's: when two workspaces run agent tasks simultaneously, do they contend for resources? When you switch workspaces, is context correctly isolated? Does the knowledge engine's memory preserve the right isolation boundary across workspaces? When something breaks, the AI walks the full triage flow on its own: it assembles the operation trace and screenshots, parses error logs, hands in an initial root-cause hypothesis, and files a GitHub issue directly through the API. The issue isn't a bare "feature broken" — it includes reproduction steps, error context, and a first-pass code location. This loop covers three trigger paths: proactive validation after a new feature lands, automatic invocation in the CI pipeline, and automatic invocation when log monitoring catches anomalies in production.

Nightly Auto-Heal: Letting Machines Work While You Sleep

At this section the shape of the methodology shifts. Until now, AI has been a collaborator with a human in the loop — that's Agentic Engineering. Nightly Auto-Heal removes the human from the loop and lets the machine run the discover-fix-verify cycle on its own. This is where Autonomous Engineering begins. Issues from validation runs, manual testing, CI failures, and production log alerts all flow into a single processing queue. After the team logs off, Nightly Auto-Heal kicks in automatically.

Issue enters queue
        ↓
Model performs root-cause analysis using the code knowledge graph
Locates relevant files and call paths
        ↓
Generates a fix plan plus a corresponding spec patch
        ↓
AI executes the fix and opens a PR
        ↓
Computer Use runs self-validation
(full business flow + edge cases)
        ↓
Pass ──→ PR ready, awaiting human review and merge
Fail ──→ Flagged for human triage, prioritized for the morning

The point of this loop isn't "full automation." The point is to redistribute human time. When engineers come in the next morning, simple bugs in the queue already have PRs waiting for review. Root-cause analysis is done. The fix has already passed self-validation. Engineers don't start from scratch — they make the final judgment call. Engineers stop being pinned to the chain of "find the bug, locate the code, write the fix, verify by hand." That time gets redirected to where human judgment is actually required: architectural decisions, complex root-cause analysis, the final go/no-go before merge. The pairing of Nightly Auto-Heal and the code knowledge graph is where the leverage shows up most clearly. The most expensive part of bug fixing has rarely been "writing the patch" — it's been "finding the problem." Locating a bug across four million lines of code can take hours. The knowledge graph lets the AI trace call chains fast, compressing localization from hours to minutes.

Three Weeks Later

Three weeks. 500K lines of new code. 99% AI-generated. Quest standalone view, knowledge engine, multi-workspace parallelism, Experts Mode collaboration — all of it landed in Qoder V1.0 and shipped to users. But the number isn't really what this article is about. What sits behind the number is that we've now run two methodologies that lock into each other end-to-end: Agentic Engineering, where AI collaborates at high quality under human supervision, and Autonomous Engineering, where machines keep running the loop after the human has logged off. The difference between a legacy giant and a blank-slate project is cognitive load. On a blank-slate project the AI can improvise. In a legacy system the AI has to be domesticated first — it has to know what this system has been through, what has been agreed on, and what cannot be touched. The five-layer structure of this methodology maps to five distinct functions:

Layer	Tooling	Function
Foundation	Repo Wiki + Code Knowledge Graph + Historical Spec Deposits	Lets AI understand both the current state and the evolution of 4M lines of legacy code
Leverage	Ultra Spec + Multi-Agent Cross-Review	Surfaces rework-causing issues before any code is written
Execution	Experts Mode (Team Lead + specialist agents + engineering knowledge engine)	Turns the spec's dependency graph into parallel engineering delivery
Guardrail	Ultra Review (multi-agent parallel)	Keeps up with AI's generation speed and catches the details inside the code
Flywheel	Computer Use validation + Nightly Auto-Heal	Closes the discover-fix-verify loop into an autonomous cycle

None of the five layers is optional. Ultra Spec without the knowledge graph misses the legacy system's implicit constraints. Experts Mode without Ultra Review lets parallel specialists silently drift apart on style and boundaries. Auto-Heal without Ultra Review produces an endless stream of new bugs to fix because code quality wasn't held at the source. One more thing worth saying: the engineer's role changes in both stages, but in different ways. In the Agentic stage, the engineer is the standards-setter — defining the precision of the spec, drawing the architectural lines, deciding which review perspectives are mandatory, and making the final call on whether a PR merges. The AI writes code, the human sets direction. In the Autonomous stage, the engineer co-designs the verification system with the AI. For the machine to keep running the loop after the human has stepped away, it has to be able to judge "is this right?" on its own. That trustworthy verification infrastructure isn't something a human writes alone: end-to-end Computer Use validation, unit tests, integration tests, the CI pipeline, production log monitoring, regression datasets — every layer is hammered out jointly. The human defines what "correct" means and the fallback logic; the AI translates that definition into executable checks. The more solid the verification system, the wider the radius the machine can autonomously cover. How far AI can go is a function of how solid the cognitive infrastructure and verification infrastructure you give it are. The more precise the spec, the less the AI deviates. The more complete the verification, the more the flywheel actually spins. AI doesn't replace engineers, because the scarce resource in this game has never been the ability to write code. It's the ability to define what counts as correct. The Agentic stage defines the precision of the spec; the Autonomous stage defines the boundary of verification. AI can't help you with either of those, but those are the two things that decide how big a radius AI can work in on your behalf. Writing code is becoming infrastructure rather than the engineer's core job. The real moat has moved upstream — to whether you can break a fuzzy requirement into a spec a machine can execute, and whether you can translate "this looks fine to me" into criteria that can be auto-verified. The better you do those two, the further AI runs and the larger the engineer's leverage.

​This Isn't a Greenfield Project

​Foundation First: Letting AI Actually Read Four Million Lines

​Layer 1: Repo Wiki (Qoder built-in)

​Layer 2: Code Knowledge Graph (Qoder built-in)

​Layer 3: Historical Spec Archive (accumulated engineering practice)

​Ultra Spec: Write the Spec Through Before Writing Code

​Experts Mode: Turning the Spec Into Parallel Engineering

​Ultra Review: Surfacing the Details Inside AI-Written Code

​Computer Use Validation: AI Grows Eyes and Hands

​Nightly Auto-Heal: Letting Machines Work While You Sleep

​Three Weeks Later