Post-Training for LLMs and Programming Agents in Practice

    Over the past six months, the competitive focus of coding large language models has shifted from raw parameter scale to more substantive factors: the depth of post-training, the completeness of agent toolchains, and the controllability of inference costs. This article breaks down that shift across technical approaches, capability evaluation, and engineering implementation, while offering practical guidance for teams building or adopting programming agents.

    Post-Training for LLMs and Programming Agents in Practice

    Over the past six months, the competitive focus of coding large language models has undergone a noticeable shift. The question is no longer simply “who has the largest base model,” but rather “who has stronger post-training, a more complete agent toolchain, and more controllable inference costs.”

    A direct reflection of this change is that many teams are no longer rushing to release their next-generation base models. Instead, they are investing in reinforcement learning over existing models, refining toolchains, and optimizing inference costs.

    This article examines the trend from three angles: technical approach, capability evaluation, and engineering implementation. It also provides practical recommendations that can be applied to real projects.

    Why “not scaling parameters” has become a rational choice

    In the early stages, parameter scale was almost synonymous with capability ceiling, which drove the open-source community’s pursuit of the largest possible models. However, once base models exceed a certain size, marginal returns begin to decline.

    First, training costs rise sharply. Doubling parameters typically brings non-linear increases in compute requirements, while capability gains tend to flatten.

    Second, inference costs remain high. Larger models consume more memory and introduce longer response latency, directly affecting multi-turn interactions in agent scenarios.

    Third, toolchain gaps are often more damaging. In real programming tasks, whether a model can correctly invoke a terminal, read and write files, and interpret error messages is often more important than whether it can solve additional algorithm problems.

    As a result, a more pragmatic approach has emerged: keep a capable full-scale base model and concentrate resources on post-training and toolchain development. Typical practices include:

    • Running long-duration reinforcement learning over the base model across hundreds of specialized task domains.
    • Continuously improving the agent runtime by standardizing sandbox, terminal, and browser capabilities.
    • Reducing API prices to a fraction of their previous levels through inference optimization and architectural adjustments.

    The combined effect of these measures is often more direct than simply increasing parameter count.

    Long-duration reinforcement learning: what post-training actually trains

    Post-training is not a new concept, but its meaning has changed substantially in the context of programming agents. Traditional supervised fine-tuning leans toward imitating correct answers, while agent-oriented reinforcement learning places more emphasis on trial and error within an environment to achieve a goal.

    Reward signal design

    In programming tasks, reward signals can come from multiple dimensions:

    • Task completion: whether the code passes unit tests or builds successfully.
    • Process correctness: whether command-line tools are used properly and project structure is followed.
    • Efficiency: the number of interaction turns and token consumption required to complete the task.
    • Robustness: the ability to recover from unexpected inputs or missing dependencies.

    A simplified reward function might look like this:

    1. def reward(trajectory):
    2. score = 0.0
    3. score += 1.0 if trajectory.tests_passed else 0.0
    4. score += 0.3 * trajectory.tool_correctness_ratio
    5. score -= 0.01 * trajectory.interaction_steps
    6. score -= 0.001 * trajectory.token_usage
    7. return score

    Real-world reward design is far more complex, but the core principle is the same: optimize simultaneously for code that runs, runs reliably, and runs efficiently.

    Capability emergence through long-duration training

    After months of sustained reinforcement learning, models usually show clear improvements in several areas:

    • Terminal operation: progressing from “writing code snippets” to “troubleshooting issues in a real shell environment.”
    • Multi-step planning: when faced with ambiguous requirements, proactively breaking down tasks and setting intermediate goals.
    • Self-correction: identifying the cause of an error and adjusting the strategy instead of repeatedly producing the same mistake.

    This explains why some models achieve double-digit benchmark improvements with only a minor version increment. The gain comes from a change in training paradigm, not from stacking more parameters.

    Key capabilities of programming agents

    A usable programming agent generally needs the following capabilities. Understanding their boundaries helps teams set reasonable expectations in real projects.

    Terminal and command-line fundamentals

    Terminal operation is a hard requirement for programming agents. The model needs to:

    • Understand the current working directory and file structure.
    • Correctly use common build, test, and version control commands.
    • Parse command output and identify error types.
    • Combine multiple commands when necessary to complete complex operations.

    These capabilities are difficult to acquire through text-only pretraining. They depend on reinforcement learning with real environment interaction.

    Graphical interfaces and visual annotation

    Some agent tools are introducing graphical interfaces that wrap command-line capabilities in a more accessible interaction layer and support visual annotation. This is especially important for:

    • Frontend debugging: annotating problem areas directly on rendered output.
    • 3D scene construction: adjusting models, materials, and lighting based on visual feedback.
    • Design-to-code conversion: translating visual differences into specific style changes.

    The addition of visual capabilities moves agents from text-only assistants toward multimodal collaborators.

    Long-horizon task planning

    Long-horizon tasks are the dividing line between a toy and a practical tool. Typical characteristics include:

    • Tasks requiring dozens or even hundreds of steps.
    • Intermediate states that need to be persisted and support interruption recovery.
    • Goals that may shift dynamically as the environment changes.

    Common engineering approaches for these tasks include:

    • Plan/goal dual modes: a plan mode generates steps first, then a goal mode executes and verifies them.
    • State snapshots: periodically saving workspace state for rollback.
    • Subtask isolation: breaking large tasks into independent subtasks to reduce context pressure.

    3D and frontend visual generation: capabilities and limitations

    In practice, programming agents often deliver their most impressive results in 3D and frontend visual tasks, but these areas also create the highest expectations. A realistic view requires attention to several points.

    Frontend visual generation

    The challenge in frontend tasks is not writing HTML and CSS. The real difficulties lie in:

    • Reproducing the hierarchy, spacing, and responsive behavior intended by the design.
    • Handling browser compatibility and accessibility.
    • Integrating with existing component libraries and build toolchains.

    The agent’s strength in these tasks is rapidly producing runnable prototypes. Production-grade code still requires human review.

    3D scene construction

    3D tasks involve geometry, materials, lighting, cameras, and other dimensions. Agents can assist with:

    • Basic scene setup and parameter adjustment.
    • Scripted generation of repeated elements.
    • Producing initial material and lighting proposals from descriptions.

    However, complex performance optimization and artistic consistency still depend on professional expertise.

    Engineering practices for cost control

    Capability improvements inevitably raise the question of inference cost. The following are common cost-reduction approaches.

    Model tiered routing

    Not every task requires the strongest model. Routing can be based on task complexity:

    1. def route(task):
    2. if task.complexity == "high":
    3. return strong_model
    4. elif task.complexity == "medium":
    5. return medium_model
    6. else:
    7. return lightweight_model

    Context compression

    Context grows quickly in agent scenarios. Common techniques include:

    • Summarizing historical dialogue.
    • Keeping only file segments relevant to the current subtask.
    • Replacing verbose natural language records with structured state.

    Caching and reuse

    For repetitive tasks such as fixed-format code generation or routine build scripts, caching can significantly reduce the number of model calls.

    Balancing price and performance

    When model prices drop to a fraction of their previous levels, scenarios that were previously too expensive become feasible, such as:

    • Batch refactoring of large codebases.
    • Automatic fixes in continuous integration.
    • High-frequency interaction in educational settings.

    Selection and implementation recommendations

    Based on the analysis above, several practical recommendations apply to development teams:

    1. Define task boundaries first. Distinguish between tasks the agent can complete independently and tasks that require human intervention.
    2. Prioritize the toolchain over any single model. The maturity of sandbox, terminal, browser, and version control infrastructure directly determines the user experience.
    3. Establish an evaluation loop. Build an internal evaluation set from real tasks and continuously track the effects of model iterations.
    4. Plan cost and capability together. Include inference cost, concurrency scale, and response latency in the selection process.
    5. Remain architecturally neutral. Isolate model calls through an abstraction layer so that switching between models of different capability levels is straightforward.

    Conclusion

    Programming agents are moving from the demonstration stage to the engineering stage. Base model scale still matters, but what determines real-world results is the depth of post-training, the completeness of the toolchain, and the precision of cost control.

    For developers, understanding the logic behind this technical direction is more valuable than chasing a specific version number. As platforms such as Baidu AI Cloud continue to improve general-purpose computing and model service capabilities, the more important challenge is turning model capability into maintainable, scalable engineering systems.