The Evolution of LLM Post-Training: From Code Generation to 3D Spatial Reasoning

1. Background: Post-Training as the New Battleground for Model Capabilities

Over the past year, the focus of LLM competition has gradually shifted from “pre-training scale” to “post-training quality.” While the base model determines the capability ceiling, it is the post-training phase—comprising alignment strategies, reinforcement learning (RL) signal design, and tool-calling trajectory construction—that truly dictates a model’s usability in real-world tasks. An industry-wide observation is that the same base model, under different post-training schemes, can show performance gaps of over ten percentage points on hard metrics like terminal tasks, code repair, and spatial reasoning.

A typical technical approach in this context is performing targeted post-training enhancements on top of existing base models rather than pre-training from scratch. The engineering significance of this is clear: controllable compute investment, shorter iteration cycles, and the ability to precisely deploy capability improvements to specific task domains. This article discusses the concrete performance of such post-training enhancement schemes in two directions—code agents and 3D content generation—and their practical impact on developer workflows.

2. Code and Terminal Tasks: The True Meaning of Capability Improvements

2.1 Why Terminal-Style Benchmarks Are Harder

Terminal-style benchmarks differ fundamentally from traditional function-level code completion. The latter only tests “writing a function body given a signature,” while the former requires completing multi-step operations in a real command-line environment: reading errors, locating files, modifying code, executing verification, and handling dependency conflicts. It evaluates the coupling of long-horizon planning + tool-calling accuracy + environment feedback comprehension.

Therefore, score improvements on terminal tasks often better reflect whether “this model can actually do the work for me” than improvements in code completion scores. A model improving from 50 to 65 on terminal tasks holds far more practical value than improving from 80 to 90 on a unit test benchmark.

2.2 Three Key Designs in the Post-Training Phase

Based on publicly available technical paths, such enhancements typically involve three components:

First, trajectory data construction. This requires a large amount of “complete processes of human experts solving problems in a terminal” as supervised signals, including intermediate failed attempts. Keeping only successful trajectories prevents the model from learning error correction. Retaining the complete failure-correction chain allows the model to exhibit a “trial-and-error -> read-back -> adjust” behavioral pattern during inference.

Second, RL signals for tool calling. The correctness of tool calls cannot be judged solely by the final result; the call sequence must also be checked for redundancy and invalid retries. A common practice is designing hierarchical rewards: result correctness serves as the primary reward, while the number of call steps and invalid operations act as penalty terms.

Third, inference strategies under cost constraints. This is often overlooked. Terminal tasks naturally consume more tokens than standard conversations because they require repeatedly reading file contents and command outputs. If the post-training phase incorporates “achieving the goal in fewer interaction rounds” as an optimization target, it can significantly reduce per-task costs while maintaining accuracy.

2.3 Why the Cost Dimension Deserves Separate Discussion

In engineering deployment, a common pitfall is looking only at benchmark scores without considering per-task costs. In actual deployment, the cost structure for terminal tasks roughly looks like this:

# Pseudocode for cost estimation
Per-task cost ≈ (Input token count × Input price) + (Output token count × Output price)
# Where input tokens mainly come from: file content reading, command output read-back, historical trajectory concatenation

As shown, the input side accounts for the bulk of the cost. Therefore, a model capable of completing tasks in fewer rounds may result in a lower total cost, even if its unit price is higher. Conversely, some low-priced models might incur higher total expenditures due to needing more rounds of trial and error. This is why “cost control capability” should be evaluated alongside “task performance”—cost per task × success rate is a far more meaningful metric.

For scenarios requiring batch processing of terminal tasks (such as large-scale code migrations, dependency upgrades, or static check fixes), this metric directly determines viability. Developers should build their own small-scale evaluation sets to measure “the comprehensive cost of completing a single task” using real-world tasks, rather than blindly trusting any single leaderboard.

3. 3D Content Generation: From Tool Dependency to Direct Scripting

3.1 The Divergence of Two Technical Routes

There are currently two mainstream routes for 3D content generation:

Route A: Tool Protocol Invocation. The model invokes the capability interfaces of external modeling tools via standardized tool protocols (such as universal interface specifications like the Model Context Protocol), letting the tool perform geometric operations. The advantage is stable, composable interfaces; the disadvantage is that capabilities are limited by the interface granularity exposed by the tool, and complex modeling often requires numerous fine-grained calls.

Route B: Direct Scripting. The model directly generates native scripts for the target software (e.g., the built-in scripting language of 3D modeling software, or modeling scripts for parametric CAD) to be executed by the host software. The advantage is high expressiveness, allowing one-shot descriptions of complex geometric relationships and material layouts. The disadvantage is that it demands high domain knowledge from the model, requiring an understanding of script API semantics and common pitfalls.

Looking at recent performance, the viability of Route B is rapidly improving. On parametric modeling benchmarks, open-source models have reached levels close to top-tier closed-source models, with the gap narrowing to single-digit percentages. This means “models directly writing scripts for modeling” is transitioning from a proof-of-concept to engineering usability.

3.2 The Engineering Value of Direct Scripting

Why is direct scripting more valuable than tool protocol invocation? The core lies in reusability and versionability.

A modeling script is plain text: it can enter version control, be diffed, and be parameterized. A modeling operation completed via a tool protocol is essentially a string of transient calls that are difficult to reproduce and review. In team collaboration scenarios, the former forms an asset, while the latter only forms a result.

A typical parametric modeling script structure looks like this (illustrative):

# Illustrative pseudocode, not specific to any software API
def build_assembly(params):
    base = create_primitive("cube", size=params.base_size)
    apply_transform(base, location=(0, 0, 0))
    for i in range(params.count):
        part = create_primitive("cylinder", radius=params.r, depth=params.h)
        place_on_grid(part, index=i, spacing=params.spacing)
        assign_material(part, params.material_name)
    join(base, collect_parts())
    return export("assembly")

The key point of this script is not the syntax, but that it expresses “layout, material, and geometry” as parameters. If a model can stably generate such scripts, it means it understands spatial relationships and parameter constraints, rather than just memorizing API names.

3.3 Spatial Reasoning is the True Threshold

The difficulty of 3D generation is not “calling modeling functions,” but spatial reasoning: whether parts interfere with each other, whether the bounding box after rotation exceeds boundaries, whether material assignments align with semantic groupings, and whether the hierarchical structure is sound. The common trait of these issues is that they cannot be judged by local syntactic correctness; they require holistic geometric consistency checks.

Therefore, when evaluating such capabilities, simply checking “whether the script runs successfully” is insufficient. More meaningful evaluation dimensions include:

• Geometric validity: Does the result have self-intersections, zero-volume faces, or flipped normals?
• Constraint satisfaction: Are parameter constraints like dimensions, spacing, and symmetry respected?
• Structural rationality: Does the hierarchical organization follow standard modeling conventions and facilitate subsequent editing?
• Reentrancy: If parameters are modified and the script is re-executed, is the result still valid?

This explains a common phenomenon: some models can write “runnable” scripts, but the outputs cannot be used for subsequent production. The true capability watershed lies in constraint satisfaction and structural rationality, not execution success rates.

4. How Developers Can Integrate These Capabilities

4.1 Task Layering and Model Selection

It is not recommended to use a single model for all tasks. A more practical approach is to layer by task complexity:

Task Level	Typical Scenarios	Selection Preference
Lightweight completion	Function body completion, single-file fixes	Low-latency, low-cost models
Medium-horizon tasks	Multi-file refactoring, test generation	Balanced models
Long-horizon terminal tasks	Environment setup, dependency migration, batch fixes	High-planning-capability models
3D script generation	Parametric modeling, layout generation	Strong spatial reasoning models

The point of layering is cost control: pushing lightweight tasks to cheaper models and concentrating the budget on segments that genuinely require long-horizon reasoning.

4.2 Build Evaluation Sets Before Integration

Before formal integration, it is recommended to construct an internal evaluation set of 30 to 50 items covering the team’s real, high-frequency tasks. Evaluation metrics should at least include:

• Task success rate (human-judged, not auto-scripted);
• Average interaction rounds;
• Comprehensive cost per task;
• Output maintainability (whether team members can directly take over and modify it).

Combined, these four metrics reflect actual usability far better than any public leaderboard.

4.3 Implementation Suggestions for Scripted Modeling

If you plan to introduce direct scripting for modeling into your production workflow, follow this sequence:

1. Read-only validation first: Let the model generate scripts without executing them; manually review whether the geometric logic is correct.
2. Sandbox execution next: Execute in an isolated environment to validate geometric validity and constraint satisfaction.
3. Pipeline integration last: Bring the scripts into version control, build a parameter template library, and form reusable assets.

This progressive path mitigates the risk of “model-generated scripts directly polluting production assets.”

5. Conclusion

Advancements in post-training technology are pushing LLMs from “being able to write code” to “being able to complete tasks.” Terminal-style benchmarks measure long-horizon planning and tool calling, while 3D script generation measures spatial reasoning and constraint understanding. The commonality between these two capabilities is that neither can be faked through memorization and pattern matching.

For developers, the real focus should not be on the score fluctuations of any single update, but on three things: whether task layering is clear, whether the internal evaluation set is reliable, and whether the product of cost and success rate is acceptable. By solidifying these three areas, any model capability iteration can be quickly absorbed into existing workflows without constantly starting from scratch.