How Do You Hand 310,000 Lines of Code to AI for Refactoring? Meituan Team's Governance Methodology

Title

How Do You Hand 310,000 Lines of Code to AI for Refactoring? Meituan Team's Governance Methodology

Meta Description

Meituan's business R&D platform applies an Agent evaluation mindset to AI coding: facing 310,000 lines of code, first unify layering and modeling consensus, then translate it into model rules and skills, and through lead-by-example, migration processes, pre-submission review, and structured testing, turn AI generation speed into sustained delivery capability.

Article Content

When a system balloons from under 50,000 lines of code to 310,000, handles an average of 16 requirements per month—about 80% of which are business requirements—and the team still has to digest the technical debt of the old architecture, can this still be handed to AI? The answer from Meituan's business R&D platform is not "let the model rewrite it," but rather "unify the standards first, then let the model execute." This approach comes from their practice of managing AI coding, and also from their already-familiar Agent evaluation experience: first align human judgment, then check whether machine and human judgments are consistent.

The Real Difficulty of Refactoring: Complexity Hides in Capability Combinations

According to the original article, this system supports 6 types of multimodal data evaluation at the bottom layer, with different task views, business actions, tags, and dynamic allocation mechanisms on top. The complexity is not just the number of files, but the massive combinations among capabilities—a single interface change can affect multiple business flows.

The team identified three drivers for refactoring: insufficient extensibility of the business model, where new business forms often require a new implementation; past packaging by requirement, resulting in mixed logic and lack of clear layering; and a team with increasingly diverse sizes and technical backgrounds, where AI also handles a large amount of coding work. When different people give different designs and different contexts, the model continues generating code in different styles. Faster generation does not automatically lead to structural convergence; the system needs clear boundaries so that new code grows in the same direction.

Phase 1: Expert Direction, Model Expansion

Facing a large amount of implicit logic and compatibility branches, the team did not read line by line from scratch. Instead, they adopted an approach of "expert experience for direction, model assistance for investigation": first identify high-priority directions such as business models, database query performance, state management, and indexing, then let the model scan call relationships along these directions. Humans decide which issues are high priority and which are worth fixing first.

The division of labor is clear: models are good at expanding the scope of investigation, while business impact and fix value still require human judgment. Scan findings must also be verified back in the code. In this step, the team identified three highest-priority and two second-highest-priority technical debts, and used the model to locate ten deeply hidden performance risks.

The boundary worth preserving is: discovering more problems and knowing which problem to solve first are two different stages. A more reliable migration approach is to first explain the risk categories and verification basis, then judge the probability of occurrence, scope of impact, and cost of repair.

Phase 2: Unify Consensus First, Then Write It into Rules

The core of Phase 2 is to put team consensus before tool configuration. If developers do not even agree on which layer a certain responsibility belongs to, even if they share the same configuration, they may each interpret it into different versions. The engineering lesson is: rule conflicts should first be discussed with concrete examples to form a reviewable judgment.

The original article implemented engineering layering, business domain models, and repository layer specifications, and configured basic requirements as always-effective model rules. For orchestration and capability responsibilities that easily cause disagreement, they first unified within the group, then distilled them into skills loaded progressively during coding. The two forms correspond to different levels—basic boundaries continuously constrain generation, while task knowledge provides details when needed.

The pre-submission review step is also not just about letting the model generate a document. From an engineering perspective, it is best to use real changes to observe whether the rules are effective: whether they block old problems, whether they mistakenly harm reasonable implementations, and whether textual constraints and code checks support each other.

Model Rules and Skills: In the AI coding toolchain, "rules" typically refer to constraints always injected into the model context (such as layering specifications and naming conventions), ensuring every generation follows basic boundaries; "skills" are instruction packages loaded on demand, providing detailed guidance for specific tasks (such as writing orchestration code). Together, they continuously constrain generation style while providing flexible knowledge for complex scenarios, avoiding rule conflicts or context overload.

Migration Phase: Governing Coupling, Not Directories

During the migration phase from March to April, the team gradually migrated code organized by requirement into a four-layer structure of entry, application, infrastructure, and common, while organizing by business domain. The focus is not directory adjustment, but governing deep coupling, especially the problem of persistent data objects propagating layer by layer along the call chain. If upper-layer interfaces directly depend on lower-layer table structures, a single storage change may require modifications in multiple places.

Around the leakage of low-level objects, the article presents three consecutive actions: first complete the business object and data conversion layer, centralizing previously scattered conversion logic; then rebuild interface contracts at the application layer to prevent low-level data objects from flowing directly upward; finally fix the parameter dependencies of upstream call chains along the new contracts. This is a coherent path—doing only the first step, such as adding business objects but still letting callers read persistent objects, means dependencies are not truly closed.

Checking whether migration succeeds cannot rely solely on counting file moves; it must also observe whether places that should not know low-level details truly no longer depend on them. The model can handle a large amount of repetitive rewriting, but humans need to check whether the new contracts accurately express business meaning and whether compatibility paths have been missed. To this end, the lead personally completed the transformation of the two most complex packages, distilling judgment and operations into a standard process the model can execute. Other members then guided the model to migrate the remaining packages according to the process, focusing their own attention on business semantic acceptance and code review. In this way, the team completed the engineering structure migration of more than ten core packages. The key is to first run the process through with real problems, rather than writing a guide out of thin air.

For deeper business model refactoring, the team adopted the approach of breaking technical debt into daily high-priority requirements: when iterating on one core function, they designed a new business model along the way; when upgrading another function, they completed the quality inspection business model transformation. By late March, the related full migration was complete. The article calls this "zero-schedule refactoring"—not applying for dedicated refactoring time does not mean refactoring consumes no effort; lead-by-example, rule-making, compatibility migration, and review are all real investments. What can be learned is binding transformation to current business goals to reduce the difficulty of securing resources, but this should not be understood as any technical debt being solvable for free. If the transformation risk exceeds the control capability of the current iteration, continuing to split is usually safer than forcing it in.

Deep Coupling: Refers to strong coupling formed between modules through implicit dependencies (such as directly referencing low-level data structures), which is harder to detect and govern than interface coupling. In a layered architecture, persistent objects (such as entities corresponding to database tables) propagate upward along the call chain, binding upper-layer business logic to storage details. Governing deep coupling requires introducing business objects and a data conversion layer, and rebuilding contracts at the application layer to block low-level object leakage.

After Coding Speeds Up, Review Becomes the New Bottleneck

The team found that code review became the new bottleneck, so they redistributed work: the model handles specification issues and does initial screening of business logic, while humans focus more on judging direction in upfront design reviews and judging whether the implementation matches the design and business logic during review. This is not canceling code review, but adjusting the allocation of human attention. Evaluating efficiency gains should look at the complete cycle from design to merge, avoiding只看 generation speed while ignoring downstream backlog.

The pre-review mechanism requires developers to let the model perform multiple rounds of self-check before submission, covering specifications, exception handling, consistency, extensibility, and performance issues, then submit explanations according to a template, focusing on change points, impact scope, and business logic requiring human attention. An additional verification can be added here: automatically generated explanations must match the actual diff, especially checking unlisted impacts and uncertainties—a complete explanation does not prove complete analysis.

The original article also tried two model mutual-review methods: using a more capable model to review code generated by other models, and having models from different vendors cross-review. The team believes this can expand review coverage, but the article does not provide accuracy guarantees applicable to other projects. Multiple models may also share blind spots and repeatedly reach the same erroneous conclusion. Cross-opinions are best compared against code locations, execution paths, and test evidence; when disagreements arise, what is truly valuable is understanding each side's basis, not voting by number of models.

Model Mutual Review: Having one model review code generated by another, or having models from different vendors cross-review, to expand review coverage. However, note that models may share blind spots in training data, leading to repeated erroneous conclusions. Cross-opinions should be compared against code locations, execution paths, and test evidence, rather than simply voting by number of models.

Testing: Define Scope First, Then Talk About Generation

With developers doubling as testers, the team explored two routes. The first was to let the model automatically generate all test cases with humans doing final checks, which quickly exposed problems: the model relies on requirement documents, easily misses high-risk scenarios with implicit associations, and diverges into many low-value edge cases, increasing review burden. After communicating with a professional testing team, they chose the second: humans first determine test scope and risk level, then the model scans code to supplement steps.

In the process, the first step is to collect affected interfaces from two directions—traffic monitoring and code changes—with humans reviewing the final scope and excluding false positives; the second step is for the model to read the code and answer how large the change is, where the branches are, and whether old data is compatible, after which humans judge risk level and test depth. Code differences and real usage provide different perspectives that complement each other—traffic lists may seem naturally complete, but humans still need to supplement business flows and historical constraints.

The third step uses a decision table to split first and then merge, generating as streamlined a combination of test cases as possible, with humans checking the reasonableness of grouping and supplementing special scenarios. There is an easily misused point here: treating the minimal combination as a minimum quantity target. Streamlining should be based on the premise that risks and conditions are covered; if key differences are merged away, a small number only conceals omissions. Finally, generate a coverage matrix of interfaces and verification dimensions and mark covered items, with humans confirming whether there are blind spots. The matrix can explicitly display correspondences scattered in textual test cases, but if an important dimension was not listed initially, even a complete table cannot reveal the omission. Therefore, coverage confirmation must examine both gaps inside the matrix and whether the matrix definition itself is accurate.

Decision Table: A systematic method for designing test cases that lists combinations of conditions and actions, splitting first and then merging, to generate a streamlined set of test cases covering key scenarios. In AI-assisted testing, humans first determine test scope and risk level, the model uses decision tables to generate combinations, and then humans check the reasonableness of grouping and supplement special scenarios, avoiding the model diverging into low-value edge cases.

What This Method Means for the Team

Looking back at the full article, the most valuable thing is not the scale of 310,000 lines, but how it breaks the governance problems brought by rapid generation into executable steps. The original article reports specific migration and investigation results, but does not provide efficiency-improvement ratios applicable to all systems, nor can it be concluded that automated refactoring is risk-free. The necessary conditions include: people who can judge architectural boundaries, repeatable migration processes, and acceptance capabilities for business semantics and historical compatibility.

If you want to learn from it, you can proceed in the order of the original article: core developers identify high-priority directions and use models to clarify technical debt; unify layering, modeling, and dependency standards, and put consensus into rules and skills; the lead completes a complex module and distills the migration process before scaling it out; finally, establish pre-submission review and manual business acceptance. Each step requires concrete artifacts—technical debt lists, contract organization, review explanations—to judge whether the method is truly executed. There is no need to copy all layer names and tool configurations from the original article, but the order should be preserved: make judgments first, then constrain generation, and verify with actual changes.

This practice converges on a specific change: engineers, in addition to writing code, must also design and maintain an environment in which models can reliably produce output. This environment consists of team consensus, persistent rules, task skills, migration processes, pre-submission review, and test acceptance. When learning from it, the most worthwhile first step is to pick a real problem and run through how to judge, how to migrate, and how to accept—all of it. Only when such experience accumulates can the speed brought by models more likely translate into sustained delivery capability.

One-line Summary

Meituan's 310,000-line system refactoring: unify consensus first, then let AI execute; govern coupling and adjust review and testing division of labor.

Paragraph Summary

Facing the refactoring challenge of a 310,000-line system handling an average of 16 requirements per month (80% business requirements), Meituan's business R&D platform proposes a "unify standards first, then let the model execute" approach. Through expert direction and model expansion, they clarify technical debt; write consensus on layering and modeling into model rules and skills; during migration, focus on governing deep coupling from persistent objects leaking along call chains, using contracts rather than directories to test effectiveness; the lead first runs through complex modules to distill a process before scaling it out; after coding speeds up, adjust review division of labor, with models doing initial specification screening and humans focusing on business logic; testing follows the order of humans defining scope and risk, models supplementing steps and combinations. The core is that engineers need to design and maintain an environment for reliable model output.