From Code Agents to 3D Scripting: How Post-Training Drives LLM Capability Leaps

1. Introduction: Translating “It Got Better” into Engineer Language

The large language model industry’s release cadence has compressed from yearly to monthly. Whenever a new version ships, the first reactions on social media tend to be leaderboard screenshots and emotional takes. But for people who actually use models to get work done, three questions matter far more than “who ranks first”:

• Which categories of tasks improved, and do they overlap with my business scenarios?
• Does the improvement come from base-model capability or post-training strategy? This determines whether it can be reproduced and transferred;
• At comparable quality, how have cost and latency changed? This directly determines whether the model can go to production.

This article uses four of the most closely watched directions in recent model evolution—terminal code agents, script-based 3D modeling, financial document reasoning, and hallucination suppression—as threads to unpack the underlying technical principles, evaluation methods, and engineering paths to production.

2. Post-Training: The Real Engine of Capability Leaps

Base models set the ceiling of knowledge; post-training determines how usable that capability is. A successful post-training upgrade typically stacks three types of work:

1. Data: Higher-intensity synthetic data and real task trajectories. Agent trajectories in particular—the full “try, fail, fix, finish” process of experts or stronger models in real environments, condensed into training corpora;
2. Algorithms: A shift from human-preference alignment to reinforcement learning with verifiable rewards. Whether code passes tests, whether a command achieves its goal, whether a numerical result is correct—these automatically checkable signals dramatically raise the scaling ceiling of RL;
3. Environments: Training task environments that increasingly resemble real production—stateful, error-prone, and tangled in dependency conflicts, rather than one-shot single-turn Q&A.

Once you understand these three points, it is clear why new-generation models improve fastest on “multi-step, stateful, hands-on” tasks: those are precisely the bullseye of post-training.

3. Code Capabilities: From Code Completion to Terminal Agents

3.1 The Task Format Has Changed

Early code benchmarks centered on function-level generation and unit-test pass rates, where models faced well-defined inputs and outputs. The more representative format today is the “terminal task”: give the model a real command-line environment and a vague requirement—say, “reproduce this build failure and fix the dependency conflict.” The model must browse files, install dependencies, run commands, read error messages, and iterate until the acceptance criteria are met.

3.2 Why Terminal Tasks Are Hard

• Long horizons and statefulness: Every command changes the environment, and early decisions constrain later options;
• Error recovery: Failures are the norm, not the exception. The model needs a closed loop of “read logs, locate the cause, retry”;
• Tool orchestration: File I/O, full-text search, process management, and version control must be coordinated;
• Budget constraints: In real production, step counts and token budgets are finite resources.

3.3 A Minimal Working Agent Loop

# Minimal closed loop for a terminal code agent (illustrative pseudocode)
env = Sandbox(image="build-env")     # Isolated sandbox with restricted network and filesystem
obs = env.reset(task)
for step in range(MAX_STEPS):
    action = llm.plan(history, obs, budget=remaining)
    obs, done = env.execute(action)  # Execute the command; return output and exit code
    if done:
        break
report = verify(env)                 # Use an acceptance script, not model self-assessment, as the criterion

Four engineering details are easy to overlook: sandbox isolation and resource limits, truncation strategies for very long outputs, rollback mechanisms after failures, and replacing model self-assessment with deterministic acceptance scripts.

3.4 Look at the Score-Cost Curve, Not Just the Score

On the same tasks, different models vary enormously in the tokens and interaction rounds needed to finish. Industry consensus is shifting from “a single top score” toward the Pareto frontier: within a given cost budget, which curve delivers the higher score. For practitioners, a model that reaches 80% of the score at half the cost is often more valuable to deploy than the absolute score champion.

4. 3D Creation: The Creative Loop Unlocked by Direct Script Generation

4.1 Structural Pain Points of the Traditional Pipeline

3D content creation has long carried high barriers: manual modeling has a steep learning curve, asset libraries are rigid to reuse, and a single round of outsourced revisions can take days. More fundamentally, the traditional pipeline inserts a long manual translation step between “creative idea” and “implementation.”

4.2 Why Direct Script Generation Is the Critical Path

New-generation models demonstrate a different route: instead of generating meshes directly, they generate parametric modeling scripts—code that describes geometry, materials, lighting, and layout, then executed by professional modeling software. The advantages of this route are structural:

• Editable: Change one parameter to update the model in batch, instead of regenerating from scratch;
• Reproducible: Scripts are deterministic artifacts that can go into version control and code review;
• Composable: Naturally compatible with existing toolchains and asset formats, with no new software stack required;
• Verifiable: Script execution errors can be fed back to the model for self-repair, closing the loop.

4.3 Spatial Reasoning: The Real Technical Bottleneck

Writing scripts is only the surface. The core difficulty of 3D generation is spatial reasoning: a sense of scale (one meter versus one centimeter is a single order of magnitude in code), coordinate-system transforms, predicting the results of Boolean operations, and the topological plausibility of complex structures. The model must “rehearse” three-dimensional structures in its head—a capability dimension entirely different from text generation, and exactly where leading models separate in benchmarks.

4.4 An End-to-End Workflow

Text description → the model generates a modeling script → sandbox execution → online preview and interactive editing → export (3D-printable files / rendered video / shareable animated clips).

# Parametric modeling script example (pseudocode; interfaces are generic illustrations)
scene = Scene()
trees = Group()
for (x, y) in poisson_disk(area=(40, 40), min_dist=1.8):
    h = lerp(2.0, 6.0, noise2d(x, y))
    trees.add(cone_tree(pos=(x, h / 2, y), height=h, crown_ratio=0.6))
scene.add(trees)
scene.lighting(sun_dir=(30, 50, 20), ambient=0.35)
scene.export("indoor_forest.glb")   # Ready for preview or 3D printing

4.5 The Real Impact on the Creative Community

What looks like a capability “going mainstream” is really the collapse of barriers: product managers can quickly produce proof-of-concept 3D models, e-commerce sellers can generate their own 3D product showcases, and independent developers can fill in art assets at low cost. Professional modelers will not lose their value; it will move up the stack to aesthetic judgment, complex topology handling, and performance optimization—precisely the parts hardest to replace with generated scripts.

5. Financial Analysis: Retrieval, Verification, and Multi-Step Numerical Reasoning

5.1 Why Financial Documents Are Hard

Financial scenarios demand near-ruthless precision from models: documents are long and dense with tables; the same metric may be defined differently across reports; a single numerical error can invalidate an entire conclusion; and the cost of hallucination is extremely high. Financial capability benchmarks therefore typically stress the combination of three skills: retrieval and localization, cross-document verification, and multi-step numerical reasoning. A failure at any stage sinks the final result.

5.2 Capability Breakdown and Typical Failure Modes

• Retrieval: Locating key passages and tables across hundreds of pages. The failure mode is “citing adjacent data that does not answer the question”;
• Verification: Recognizing reconciliation relationships between documents. The failure mode is “citing each source independently without cross-validation”;
• Reasoning: Multi-step calculations such as unit conversion, year-over-year comparisons, and definition adjustments. The failure mode is “skipping steps.”

5.3 Engineering Techniques for Hallucination Suppression

The industry has accumulated a reusable playbook:

1. Mandatory citations: Every conclusion must be bound to traceable source text;
2. Externalized computation: The model plans the calculation steps; the actual arithmetic runs in a code interpreter, avoiding mental-math errors;
3. Calibration and refusal: Train the model to say “I don’t know” when evidence is insufficient, rather than improvising;
4. Stress testing: Deliberately inject nonexistent accounts and data to check whether the model “plays along.”

Systematically trained models can cut their error rate on such stress tests by an order of magnitude—an improvement that comes from training strategy, not luck.

5.4 Where Models Fit in the Investment Workflow

From screening targets and summarizing financials to earnings sensitivity analysis, models are well suited to play the “tireless junior analyst”: handling document retrieval, draft calculations, and formatted output, while humans retain hypothesis setting and final decisions. That is the most robust human-machine division of labor within current technical limits.

6. Security: Capability Spillover and Governance Boundaries

As post-training scales up, models keep improving on vulnerability analysis and attack-lab-style challenge solving. The coin has two sides:

• Defensive value: Automated code auditing, vulnerability pattern recognition, and patch suggestions significantly reduce security teams’ routine workload;
• Offensive risk: The same capabilities can be misused, so pre-release red-team evaluation, permission constraints, and usage policies are essential;
• Deployment essentials: Security agents must run in least-privilege environments, keep complete audit logs, and route high-risk operations through human review.

7. How to Read Leaderboards Rationally: A Checklist for Engineers

1. Align the task format: First confirm whether the benchmark tasks match your real scenarios—a high score on function generation says little about terminal-agent strength;
2. Look at the Pareto frontier, not the top score: Put cost, latency, and score on the same chart;
3. Watch for tool dependence: Open-book results (with retrieval, with executors) and closed-book capability should be judged separately;
4. Beware data contamination: Cross-check public leaderboard conclusions against your own held-out evaluation sets;
5. Build a small but real evaluation set: Extract 30–50 cases from real tickets—their decision value often exceeds any public leaderboard.

8. Engineering Deployment: A Reusable Reference Architecture

To bring these capabilities into your business, a three-layer decoupled architecture works well:

• Model gateway layer: Unified access and routing, supporting multi-model canary releases and fallback;
• Execution layer: Code sandboxes, modeling script executors, and computation engines—all containerized and least-privilege;
• Evaluation and monitoring layer: Scheduled regression testing, trajectory auditing, and cost/quality dashboards.

Supporting infrastructure can rely on common cloud components: container platforms host sandbox workloads, object storage holds datasets and artifacts, message queues decouple long-running tasks, and logging services plus monitoring and alerting provide observability. Cloud platforms such as Baidu AI Cloud offer these general-purpose capabilities. The most important architectural principle is decoupling the “model–tool–evaluation” layers: when the underlying model keeps upgrading, the business system should remain unaffected.

9. Conclusion

The gap between open-source and closed-source models is converging fast, and the narrative of “entering the same tier on a hard task” will become increasingly common. More important than chasing each release is building your own evaluation system and deployment architecture, so that every model improvement can flow along the path of “evaluate—integrate—verify—scale” and turn into real productivity for your team. As for whether direct 3D script generation can truly break into the creative mainstream, the answer is not on the leaderboards—it lies in how many non-professional creators use it over the coming year to make things they previously could not.