Three-Stage Training Paradigms for Code LLMs and a Practical Framework for Coding Assistant Selection

1. The Landscape: Why Intelligent Coding Is a Must-Win Arena for LLMs

Among all large model application domains, code generation stands out as one of the most commercially certain scenarios: requirements are well-defined, results are verifiable, and willingness to pay is strong. From early line-level code completion to conversational generation and refactoring, and further to agentic forms capable of autonomous task planning, tool invocation, and multi-step execution, the capability boundary of AI coding assistants has expanded rapidly over the past year.

Competition has intensified accordingly. Major technology companies are investing in proprietary code model development: internet firms leverage massive internal engineering data to build domain advantages, while cloud providers tend to package model capabilities together with compute infrastructure and developer toolchains. One telling signal is iteration speed—some developers have noted that certain teams completed ecosystem adaptation for intelligent coding tools within a single month, expanding from supporting only one type of agent terminal to compatibility with mainstream IDE plugins and command-line tools. Behind this lies the maturation of training paradigms and the standardization of engineering pipelines.

This article does not focus on any specific product but returns to the technology itself: dissecting the mainstream training paradigms for code LLMs, discussing the right approach to evaluation, and presenting an enterprise-grade selection framework.

2. The Three-Stage Training Paradigm for Code LLMs

Based on publicly disclosed technical practices across the industry, the training pipeline for a code LLM oriented toward intelligent coding typically comprises three stages: Mid-Training, SFT & RFT (Supervised Fine-Tuning and Rejection Sampling Fine-Tuning), and Agentic RL Scaling (Agentic Reinforcement Learning Scaling). These three stages build upon each other, addressing respectively the problems of “knowledge injection,” “behavior alignment,” and “autonomous execution.”

2.1 Mid-Training: The Injection Window for Foundational Capabilities

Mid-Training is a continued training phase between pre-training and alignment training. Its goal is to equip the base model with the comprehensive capabilities needed to complete programming tasks. Key areas typically include:

• Instruction following: Accurately understanding constraints in compound instructions, such as “only modify the specified module” or “keep existing interface signatures unchanged.”
• Tool use: Mastering tool protocols for function calling, command execution, file reading and writing, including parameter construction and return value parsing.
• Multi-turn interaction: Maintaining contextual consistency across long conversations and revising prior plans based on feedback.
• Code knowledge injection: Learning from high-quality code corpora, technical documentation, and engineering standards, covering mainstream languages, frameworks, and build systems.
• Version management and collaboration workflows: Understanding collaboration semantics such as code commits, branch management, and merge requests—a prerequisite for agents to participate in real repository development.
• General and reasoning capabilities: Avoiding degradation of general abilities during specialized capability improvement, maintaining foundational competencies in mathematics and logical reasoning.

Why is this stage so critical? Because the essence of agentic coding is a closed loop of “model + environment + tools.” If the base model lacks a basic understanding of repository structure, build errors, and tool invocation protocols, subsequent reinforcement learning has no starting point for exploration.

2.2 SFT and RFT: From Imitation Learning to Quality Filtering

The core of the SFT stage is task systematization. A common industry practice is to construct a “task × scenario” coverage matrix: task dimensions include requirement implementation, bug fixing, code refactoring, unit test generation, and code review explanation—high-frequency user operations; scenario dimensions cover typical code environments such as frontend interaction, backend services, data pipelines, and scripting tools. The closer the fine-tuning data distribution is to real-world usage, the more stable the model’s out-of-the-box experience.

The value of RFT (Rejection Sampling Fine-Tuning) lies in data quality control. The basic process is: sample multiple times for the same task, use test cases or rule-based validation to filter out verifiable correct trajectories, and incorporate multiple correct references (rather than a single standard answer) into training. This approach yields two benefits: first, it improves rollout pass efficiency, avoiding wasted compute on samples destined to fail; second, it provides a smoother, more stable reward distribution for subsequent reinforcement learning, improving training efficiency and stability in the RL stage.

2.3 Agentic RL Scaling: Teaching the Model to Actually “Do the Work”

The first two stages address “can it do it”; Agentic RL addresses “can it do it reliably.” Real agentic coding task trajectories often span dozens of steps: reading code, locating problems, modifying multiple files, running tests, and iterating based on error messages. Such long-horizon tasks pose two major challenges for reinforcement learning: high environment interaction costs and sparse effective reward signals.

Current frontier engineering approaches focus on three key ideas:

• Trajectory compression and high-signal expansion: Compressing massive historical trajectories into a prefix tree structure, ranking nodes by policy entropy and visit probability, and expanding only high-signal nodes within the compute budget to avoid wasting resources on low-value branches.
• Entropy-guided tree pruning: Using policy entropy as an exploration signal, pruning redundant branches, and concentrating sampling budget on “uncertain but potentially high-return” paths, balancing exploration breadth with convergence speed.
• Decoupling training from agent logic: Separating environment interaction and tool execution from the main training loop, achieving “zero-bubble” full-load operation on the training side through asynchronous heterogeneous cluster scheduling, significantly improving overall training efficiency.

Competition at this stage has moved beyond algorithms alone to a comprehensive contest of distributed training frameworks, heterogeneous resource scheduling, and environment simulation capabilities. Whether Agentic RL can be scaled economically is becoming a core moat for code model R&D teams.

3. Evaluation: From Leaderboard Scores to Real Tasks

3.1 The Value and Limitations of Software Engineering Benchmarks

The industry commonly uses real software engineering task benchmarks to measure code model capabilities. A typical format is providing a code repository and a problem description, requiring the model to produce a patch that passes tests. Compared to traditional function-level completion evaluations, these benchmarks are closer to real-world practice, but they still have clear limitations: risk of data contamination, narrow task distribution, and inability to cover the complexity of enterprise private codebases. Therefore, leaderboard scores should only serve as an initial screening reference and cannot replace hands-on testing against your own business scenarios.

3.2 End-to-End Testing with “Manual Comparison” Tasks

A widely validated and effective approach is: select a task you are very familiar with and have previously implemented manually from scratch, give it to the model to complete from start to finish, then evaluate it item by item against your human experience. The classic N-Back cognitive experiment page from cognitive psychology is an excellent test case—it involves timer control, state management, user interaction, and statistical logic. It is moderate in scale but rich in detail. A reference prompt is as follows:

Please implement an N-Back cognitive experiment page:
1. Flash and display an image every 1 second, with the image randomly drawn from 10 common Chinese characters,
   such as "国" "火" "道" "市" "天" "家" "理" "态" "至" "心";
2. The user needs to judge whether the current image matches the one N positions back.
   Select "Yes" if it matches, "No" if it does not;
3. Before each experiment, the user can choose from three difficulty levels: N = 2, 3, or 4;
4. After the experiment ends, display accuracy statistics.

When evaluating, consider four dimensions:

• Functional correctness: Whether the generated code runs directly and whether the core logic conforms to the experiment design.
• Edge case handling: Behavior when judging time windows, repeated key presses, or when the sequence has fewer than N images.
• Interaction details: Countdown feedback, result visualization, and state reset when switching difficulty levels.
• Maintainability: Whether module division is clear, naming is consistent, and future extension is straightforward.

Although this type of evaluation does not produce a polished score, it genuinely reflects the model’s engineering competence under complex instructions—more valuable for decision-making than any benchmark run.

4. Enterprise Selection Framework: Six Key Dimensions

Facing a large number of intelligent coding tools and code models, enterprises should establish a structured selection framework across the following six dimensions:

1. Capability foundation: Evaluate the upper and lower bounds of fundamental capabilities such as code completion, cross-file generation, bug fixing, and refactoring, with particular attention to performance on long-context repository-level tasks.
2. Agent maturity: Task planning, tool invocation, autonomous debugging, and multi-turn error correction capabilities determine whether the model can evolve from “assisting with code writing” to “independently delivering tasks.”
3. Ecosystem fit: Whether it is compatible with the team’s existing IDEs, command-line toolchains, and CI/CD processes. Migration cost is a hidden variable in deployment success.
4. Security and compliance: Code is a core enterprise asset. Evaluate capabilities such as private deployment, data residency, and audit logging. Industries like finance and government should consider these requirements upfront.
5. Cost model: Consider token billing, concurrent throughput, response latency, and team size comprehensively. Calculate the per-person-month cost rather than looking only at unit price.
6. Platform support: The stability, observability, and operational tooling of the model service are equally critical. Large model service platforms such as Baidu AI Cloud typically provide integrated support from model inference and fine-tuning to monitoring, alerting, and log services, helping to smoothly embed code model capabilities into enterprise R&D workflows and lower the engineering barrier to deployment.

It is important to emphasize that there is no universal answer for selection. A “small steps, fast iterations” strategy is recommended: select two to three candidate solutions, trial them in parallel on real business tasks for two to four weeks, and drive the final decision with quantitative data (task pass rate, manual modification ratio, team satisfaction).

5. Conclusion

The crowded AI coding assistant landscape is essentially a collective bet by the industry on the judgment that “software production methods are undergoing transformation.” For developers, the competition brings not choice anxiety but capability democratization. For enterprises, the truly important question is no longer “whether to adopt” but “how to select scientifically and how to use deeply.” Understanding the training paradigms and evaluation methods behind code LLMs is the prerequisite for making rational decisions. When the tide goes out, what remains will certainly be those long-term players who have connected model capabilities, engineering infrastructure, and real business scenarios.