Post-Training Breakthroughs in LLMs: Evaluating Flagship Vision and Code Capabilities through Practical Programming

I. Background: Shifting from Base Model to Post-Training Competition

Over the past year, the focal point of competition in the large language model (LLM) landscape has structurally shifted. Early competition revolved around parameter scale and pre-training data volume; whoever built the larger dense or sparse base model gained an edge on general leaderboards. However, once parameter scales surpassed the trillion threshold, marginal returns began to diminish. What truly determines product experience today is the compute investment and algorithm design in the post-training phase.

A noteworthy technical trend is opting for long-term reinforcement learning (RL) on existing large-scale base models rather than rushing to stack parameters for a next-generation base. This approach, combined with continuous refinement of peripheral toolchains, fully unlocks the potential of the existing “skeleton.” A recent iteration of a domestic model exemplifies this trend. Without altering its original massive parameter skeleton, it underwent approximately 100 days of joint RL re-training. This resulted in a double-digit leap in comprehensive intelligence metrics while reducing inference API pricing by about one-third.

This article does not endorse any specific brand. Instead, it uses this iteration as a technical case study to deconstruct three questions:

1. What capability dimensions did long-term reinforcement learning actually change?
2. How does the model perform in practical tests on 3D/frontend visual tasks and programming benchmarks?
3. For developers, what do the current capability boundaries and cost structures imply?

II. Technical Path: Why “100-Day Re-training” Matters More Than “Stacking Parameters”

2.1 The Division of Labor Between Pre-training and Post-training

In large-scale model training, pre-training builds general world knowledge and language proficiency—akin to laying a foundation. Post-training then aligns these base capabilities to specific task distributions via supervised fine-tuning (SFT) and reinforcement learning. It is widely recognized that when a base model possesses sufficient representation capability, the return on investment (ROI) for post-training is often higher than expanding pre-training scale.

An intuitive analogy: pre-training determines “how much the model has learned,” while post-training determines “whether the model can use it.” For scenarios requiring strict process adherence—such as command-line operations, multi-step tool calling, and long-horizon task planning—post-training is critical. These capabilities are difficult to acquire through mere data coverage; they must be reinforced through interactive processes with feedback.

2.2 Key Designs in Joint Reinforcement Learning

“Joint RL re-training” refers to conducting reinforcement learning across multiple task domains simultaneously, rather than sequential fine-tuning domain by domain. The technical challenges of this approach include:

• Heterogeneous reward signals: Rewards for code tasks might come from unit test pass rates, while visual task rewards derive from the similarity between rendered results and target images. Their dimensions and noise characteristics differ completely, requiring normalized and weighted mechanisms.
• Capability conflicts and catastrophic forgetting: Over-reinforcing one domain may harm performance in others. Common countermeasures include experience replay, parameter-efficient fine-tuning (PEFT) module isolation, and staged curriculum learning.
• Long-horizon credit assignment: In a tool-calling task spanning dozens of steps, attributing the final success or failure to each intermediate step is a classic RL challenge. Industry practices often introduce process reward models (PRMs) or intermediate checkpoint evaluations.

Public evaluation results indicate that well-designed joint training can yield simultaneous improvements across multiple dimensions without trade-offs. This explains why a single post-training iteration can deliver a “cross-generational” feel—it optimizes holistically rather than on a single point, raising the baseline of capabilities.

2.3 Synchronous Evolution of Peripheral Toolchains

Model capability is only half of productivity; the other half depends on the toolchain. Current mainstream technical solutions typically include the following components:

• Sandbox execution environments: Providing isolated runtime spaces for code, supporting file I/O, dependency installation, and process management.
• Terminal and CLI interfaces: Allowing the model to execute shell commands for building, testing, and version control.
• Browser and visual annotation: Enabling the model to read web pages, locate UI elements, and compare screenshots—the infrastructure for frontend and visual tasks.
• Task planning paradigms: Expanding one-shot Q&A into a multi-stage “plan-execute-verify” workflow, supporting the decomposition and rollback of long-horizon tasks.

These components do not generate intelligence themselves, but they determine whether a model’s intelligence can materialize into deliverable products. A common engineering observation is that a tier improvement in toolchain stability significantly boosts the task success rate of the same model, as many failures stem from environment anomalies rather than reasoning errors.

III. Evaluation Dimension 1: 3D and Frontend Visual Capabilities

3.1 Why Visual Aesthetics Became a Differentiating Metric

Beyond code generation, visual aesthetics is becoming a crucial dimension for differentiating model tiers. The evaluation criteria for visual tasks are more subjective than purely logical tasks and rely heavily on understanding design intent. A model might generate syntactically perfect page code, but if the layout is unbalanced, spacing is chaotic, and colors clash, the output remains unusable.

Representative task types in practical tests include:

• Single-page application reproduction: Generating structurally clear and stylistically consistent page code from a design mockup or reference screenshot.
• 3D scene construction: Building 3D scenes with lighting, materials, and interactions using common Web 3D rendering solutions.
• Component library style unification: Maintaining consistent spacing systems, font hierarchies, and border-radius specifications across multiple pages.

3.2 Practical Observations

Across several rounds of comparative testing, a few stable phenomena were observed:

First, more accurate grasp of structured layouts. Faced with complex layouts containing sidebars, main content areas, and card grids, the model tends to establish a clear grid structure first before populating content, rather than stacking elements sequentially. This “skeleton-first, details-second” generation sequence significantly reduces subsequent adjustment costs.

Second, more reasonable default values for visual details. Parameters like shadow blur radius and offset, border opacity, and transition easing curves lack absolute correct answers but distinctly separate “professional” from “amateur” work. The default values provided by the RL-enhanced model align more closely with mature design system practices.

Third, more self-consistent spatial relationships in 3D scenes. When constructing 3D scenes, the model maintains better consistency among camera positions, lighting directions, and object proportions, reducing common issues like “floating objects” or “contradictory shadow directions.”

It must be objectively noted that visual tasks still highly rely on iteration. The proportion of one-shot generations meeting expectations perfectly is low, typically requiring two to three rounds of targeted adjustments. Therefore, the “visual annotation + local modification” capability in the toolchain is practically more important than single-shot generation quality.

3.3 A Typical Workflow

1. Input design mockup or requirement description
2. Model generates initial page structure (HTML + CSS + interaction logic)
3. Start local preview server in sandbox
4. Capture screenshots and annotate difference areas
5. Generate patches for difference areas
6. Repeat steps 4-5 until acceptance criteria are met

The key to this workflow is turning “generation” into a closed loop of “generation + verification.” For enterprise users, writing acceptance criteria into automated checks (e.g., pixel position deviation thresholds for key elements) can drastically reduce manual intervention.

IV. Evaluation Dimension 2: Programming Benchmarks and Real-World Engineering Capabilities

4.1 The Meaning and Limitations of Benchmark Scores

Programming capability evaluations generally fall into two categories: competitive algorithmic problems testing algorithm design and edge-case handling, and engineering tasks testing the ability to locate issues, modify code, and pass tests within real codebases. Scores for the former are nearing saturation, while the latter better reflects actual productivity.

Taking terminal operations as an example, early versions achieved only a ten-plus percent pass rate on real-world command-line benchmarks. Primary failure modes included:

• Command spelling and parameter order errors
• Misjudging the current working directory and path relationships
• Lacking environment dependency checks before execution, leading to cascading failures
• Inability to effectively read error messages and adjust strategies upon failure

Following long-term reinforcement learning, performance on such tasks typically improves significantly. This is because RL is naturally suited for training the “trial-and-error, feedback, correction” behavioral pattern.

4.2 Capability Stratification in Practical Tests

Through multiple test rounds, the model’s performance can be broadly categorized into three tiers:

Tier 1: Single-file, single-function generation and modification. This tier is quite mature. The model accurately understands function signatures, type constraints, and boundary conditions, generating directly usable code. For common data processing, API encapsulation, and unit test writing, it generally passes in one shot.

Tier 2: Cross-file refactoring and integration. Differentiation emerges here. The model must understand inter-module dependencies, interface contracts, and call sequences. In tests, the model performs well in projects with clear dependencies and naming conventions. However, in legacy codebases with heavy technical debt and chaotic naming, it often “fixes A but breaks B.”

Tier 3: End-to-end feature development. The complete pipeline from requirement understanding and solution design to coding and test verification. This tier still requires deep human involvement. The model acts more as an “efficient executor” than an “independent owner.” A pragmatic approach is for humans to define the technical solution and acceptance criteria, while the model handles implementation and self-testing.

4.3 Engineering Practices to Improve Success Rates

Based on empirical testing, the following practices significantly help improve the model’s success rate in programming tasks:

Provide clear context boundaries. Instead of letting the model search the entire repository, directly specify relevant files and key functions. The more precise the context, the higher the reasoning efficiency.

Front-load acceptance criteria. Clearly state test cases, type-checking rules, and code style constraints at the start. This ensures the model satisfies constraints during generation rather than fixing them afterward.

Deliver in stages. Break a large feature into independently verifiable small steps, running checks immediately after each step. This reduces the complexity of single inference passes and makes issue localization easier.

Maintain rollback checkpoints. Commit versions at key nodes. If subsequent modifications introduce regressions, you can quickly roll back, avoiding sustained investment in the wrong direction.

V. Cost Structure: The Practical Significance of Accessing Flagship Capabilities at Lower Costs

5.1 Technical Drivers for Price Reductions

Inference API price reductions typically stem from several areas: model architecture inference optimizations (e.g., attention mechanism sparsification, KV cache compression), improved server-side batching and scheduling efficiency, and better hardware utilization. When these optimizations accumulate, vendors can lower unit prices while maintaining gross margins.

For developers, price reductions directly enable large-scale usage in scenarios previously restricted by cost. For example:

• Batch comment completion and documentation generation for legacy codebases
• Integrating automated code reviews and style checks into CI pipelines
• Automatically classifying and triaging large volumes of historical tickets
• Running multiple rounds of visual iteration in frontend development without worrying about API costs

5.2 The Product of Unit Cost and Task Success Rate

Evaluating model economics requires looking at the “total cost of task completion”—single call cost divided by task success rate—not just the price per call. A cheap model requiring repeated retries might have a higher total cost than an expensive model with a high one-shot success rate.

Therefore, in practical selection, it is recommended to focus on a combination of three metrics:

Metric	Description	Focus
Single Call Cost	Input/output token unit price	Multiplied by average token consumption per task
Task Success Rate	Proportion of tasks passed in one or a few attempts	Requires empirical testing based on own task distribution
Manual Intervention Cost	Time spent on manual fixes after each failure	Often underestimated hidden cost

In most enterprise scenarios, manual intervention costs are significantly higher than API costs. This is why “improving success rates” impacts total cost more than “reducing unit prices.”

VI. Productivity Boundaries: What It Can and Cannot Do Now

6.1 Tasks Safe to Delegate

• Standardized code generation: CRUD APIs, data validation, unit tests, configuration files
• Initial implementation of pages and components: Generating well-structured page code from mockups
• Code explanation and documentation: Adding comments and descriptions to legacy code
• Preliminary analysis of logs and errors: Providing possible causes and troubleshooting directions
• Small-scale deterministic refactoring: Renaming, extracting functions, adjusting directory structures

6.2 Tasks Requiring Human Leadership

• Architectural decisions: Technology selection, module partitioning, data model design
• Complex concurrency and distributed logic: Race conditions, consistency guarantees, failure recovery
• Security-sensitive code: Final把关 for authentication, encryption, and input validation
• Performance critical path optimization: Requiring profiling data analysis
• Cross-system integration debugging: Complex issues involving external dependencies and network environments

6.3 A Pragmatic Collaboration Principle

Treat the model as an engineer with “broad knowledge, fast execution speed, but lacking project context.” Providing clear task boundaries, explicit acceptance criteria, and necessary context significantly boosts delivery speed. Conversely, expecting it to figure out vague requirements usually yields unstable results.

VII. Conclusion

Several broadly valuable conclusions for developers can be drawn from this model iteration:

First, post-training investment is becoming the primary source of capability differentiation. With base model scales stabilizing, the combination of long-term reinforcement learning and toolchain refinement improves actual experience better than simply expanding parameters.

Second, the intersection of vision and programming warrants close attention. Tasks like frontend development, data visualization, and 3D interaction rely on both code capability and aesthetic judgment, making them the directions with the most notable capability improvements currently.

Third, cost reduction changes usage paradigms. When API cost is no longer a constraint, developers can embed models into more automated pipelines, shifting from “occasional querying” to “continuous pipeline execution.”

Fourth, boundary awareness is more important than capability ceilings. Knowing which tasks can be safely delegated and which require human oversight is the prerequisite for models to generate real productivity.

For enterprise users, the recommended approach is to conduct a small-scale empirical test on their own business codebases, tracking task success rates and manual intervention costs, before deciding on the depth and scope of integration. Benchmark scores are for reference, but they cannot replace validation in real-world scenarios.