Evolving Coding Capabilities in Open-Source LLMs: Engineering Practices from Base Training to Reinforcement Learning

1. The Shift from Parameter Narratives to Usability Narratives

For a long time, the industry’s focus on large language models (LLMs) has centered heavily on parameter scale, benchmark scores, and single-turn generation quality. However, as models are increasingly embedded into actual development workflows, evaluation criteria are shifting. Whether a model can stably complete multi-step tasks, understand engineering context, and continuously operate within terminal and browser environments is now far more critical than simply “writing a snippet of code that looks correct.”

The reasoning behind this shift is clear. Real-world software engineering is not a single-turn Q&A session; it is a closed-loop process involving requirement clarification, code modification, debugging, verification, and rollback. Models must possess three layers of capability:

1. Language-layer capability: Correct syntax, clear semantics, and consistent style.
2. Tool-layer capability: The ability to call command lines, read/write files, execute tests, and access network resources.
3. Task-layer capability: The ability to plan steps, evaluate intermediate states, and retry or switch strategies upon failure.

Among these, language-layer capability is the easiest to train and is already present in most open-source models. Tool-layer capability relies on the coordination between external environments and model invocation capabilities. Task-layer capability is the rarest; it requires the model to have long-term memory, state tracking, and strategy selection capabilities.

Therefore, when a model claims a “significant improvement in coding capability,” we should ask not “how much did its code generation score increase,” but rather “how much did its success rate improve in long tasks requiring continuous terminal operations, output observation, and error correction.” The former can be quickly measured using static benchmarks, while the latter requires dynamic evaluation closer to real development environments.

2. Base Models Determine the Upper Limit; Post-Training Determines How Much of It Is Unlocked

From a technical perspective, the capability construction of mainstream LLMs is roughly divided into two stages:

1. Base Training Stage

The goal of base training is for the model to learn general language knowledge, code syntax, logical reasoning patterns, and cross-domain association capabilities from massive amounts of text. The core resources at this stage are compute power and data quality. The larger the parameter scale and the stricter the data cleaning, the higher the theoretical capability ceiling of the model.

However, a base model itself does not naturally adapt to real-world tasks. A powerful base model might have vast knowledge coverage but may not output results in the way users expect. Its performance in complex instruction following, long-chain reasoning, and error identification and recovery often requires the post-training stage to activate and calibrate.

2. Reinforcement Learning Post-Training Stage

The post-training stage typically includes Supervised Fine-Tuning (SFT) and Reinforcement Learning (RL), where RL is particularly critical for improving coding tasks. This is because coding tasks inherently possess verifiability: whether the code runs, whether tests pass, and whether results meet expectations can all be automatically determined. This provides stable reward signals for RL.

Under an RL framework, the model no longer just learns “what answer looks reasonable,” but learns “what behavior yields higher verifiable rewards.” When training covers multiple domains, the model gradually forms cross-task problem-solving strategies rather than merely memorizing fixed patterns from training samples.

A notable trend is that the duration of post-training is significantly increasing. Some models undergo continuous reinforcement learning for weeks or even months between their base release and their capability-leaping versions. This approach of “not increasing parameter scale, only increasing post-training investment” reflects the industry’s renewed understanding of model capability enhancement paths. Once parameter scale reaches a certain point, the marginal returns of simply stacking parameters diminish. Deep post-training for real-world tasks can often yield much more noticeable usability improvements at a lower cost.

3. The Co-evolution of Development Toolchains and Model Capabilities

The improvement of model capabilities cannot exist independently of the development environment. Even if a model performs excellently in offline evaluations, its value in real-world engineering will be heavily discounted if it cannot efficiently interact with tools like terminals, browsers, and file systems.

Currently, typical intelligent coding toolchains consist of the following components:

Sandbox Execution Environments

Sandboxes provide models with an operable file system and process space. Models can create projects, modify code, and execute commands within them without affecting the user’s local environment. The isolation and reproducibility of sandboxes mean that a model’s multi-step operations can be tracked and replayed.

Terminal Interaction Layer

The terminal is the core channel for models to interact with the operating system. Models must correctly understand terminal output, determine if a command executed successfully, extract key information upon errors, and decide the next action. This requires models to be exposed to massive amounts of real terminal session data during training, rather than just learning isolated code snippets.

Browser Operation Capabilities

In scenarios like frontend development, page debugging, and interaction verification, models need the ability to understand webpage structure, locate elements, and read console errors. Visual annotation capability is particularly crucial here—models need to be able to “see” the page rendering results, not just read the HTML source code.

State Management and Task Planning

Long-cycle development tasks require models to possess task decomposition and state tracking capabilities. Breaking down a large goal into verifiable subtasks and checking completion quality at each stage is the prerequisite for reliable delivery.

The maturity of the aforementioned toolchains directly impacts the upper limit of a model’s real-world performance. A model scoring extremely high on benchmarks might deliver actual development efficiency far below expectations if deployed in an environment with an incomplete toolchain. Therefore, when evaluating model capabilities, the “overall performance after model-environment synergy” should be the ultimate standard.

4. How Pricing is Changing Model Selection Logic

For enterprise users, price remains an unavoidable factor when selecting coding models. However, how price impacts decisions is changing: enterprises used to focus primarily on “single-generation cost,” whereas now they pay more attention to the “total cost to complete a real-world task.”

Even if a model has a low unit price, its actual comprehensive cost might be much higher than a model with a higher unit price but a better first-time success rate, especially if it frequently errors in long-chain tasks and requires massive manual intervention. Therefore, simply comparing the price per million tokens is of limited significance; a more reasonable metric is the cost per unit of effective output.

The definition of effective output can include: lines of mergeable code, number of tested feature points, or completed task steps. By amortizing costs over these verifiable outputs, enterprises can make more objective cost-performance evaluations of models.

Currently, some models leverage large-scale post-training optimization to lower API prices to a fraction of competing products while maintaining strong capabilities. The essence of this strategy is trading compute investment during the training phase for lower service costs during the inference phase, while simultaneously reducing users’ hidden expenditures on debugging and retries through a more stable task completion rate.

5. The Necessity and Methodology of Real-World Task Evaluation

Benchmark scores can reflect capability changes along specific dimensions, but they are insufficient to support selection decisions for real-world scenarios. It is recommended that teams build internal evaluation sets closely aligned with their own business before adopting a coding model. The evaluation design should follow these principles:

Prioritize Multi-Step Continuous Tasks

Single-turn Q&A cannot reflect a model’s real-world development performance. Evaluation tasks should contain at least three or more continuous operation steps, such as: creating a project structure, modifying core logic, running tests and fixing failed cases, and submitting change descriptions.

Introduce Verifiable Scoring Standards

Evaluation results should not rely on subjective manual scoring but should use automated judgments wherever possible. Examples include: test pass rates, number of successful command executions, and the runnability of the output code. Automated judgment not only improves evaluation efficiency but also ensures result consistency.

Cover Failure Recovery Scenarios

In real-world development, failures are the norm. Evaluations should deliberately inject error scenarios—such as missing dependencies, occupied ports, or failed test cases—to observe whether the model can identify the error cause and take effective repair measures rather than repeatedly executing the same operation.

Evaluate with the Entire Toolchain

Evaluations should not isolate the model. Instead, the model should be placed within the actual toolchain environment it will use to evaluate the synergy between the model and the terminal, browser, and sandbox. The same model may perform significantly differently under different toolchains.

6. Implementation Recommendations and Future Outlook

For teams planning to deeply integrate LLMs into their development workflows, here are a few pragmatic recommendations:

1. Establish internal benchmarks first: Before selecting any model, build a multi-step evaluation set that reflects your business characteristics. Without benchmarks, there is no basis for selection.
2. Prioritize post-training and domain adaptation: There is a gap between general coding models and vertical business scenarios. If conditions permit, fine-tuning or applying reinforcement learning to models based on internal code repositories and task data can significantly enhance their stability in specific domains.
3. Build toolchain capabilities simultaneously: The model itself is not everything. Infrastructure like sandboxes, terminals, browser automation, log collection, and state tracking determine how much of the model’s capability can be released.
4. Replace “price per token” with “cost per unit of effective output”: Procurement decisions should not look solely at unit prices but should comprehensively weigh the first-time success rate, manual intervention frequency, and overall delivery cycle.

Looking at current trends, the technical evolution of coding models is entering a new phase: the marginal returns from parameter growth have decreased, while post-training intensity, toolchain maturity, and task-level reliability have become the new competitive focus. For end-users, this means lower trial-and-error costs and more pragmatic implementation paths. In the near future, solutions that can effectively integrate a strong base model, deep post-training, and a highly available toolchain will hold a distinct advantage in real-world development scenarios.