New-Generation LLMs in Practice: An Engineering Look at Code Generation and 3D Interaction

1. From Benchmark Scores to Runnable Artifacts

After the release of a new generation of large models, the focus of community discussion is shifting. In the past, evaluating a model often revolved around benchmark scores, leaderboard rankings, and single-turn Q&A quality. This time, more and more developers are directly sharing runnable, interactive results: some have generated game scenes with the beginnings of an open world, some have turned a foldable mobile device into an interactive page that can open and close in the browser, and others have decomposed a mechanical structure into more than two thousand individual parts and presented each one.

This shift is worth noting. Scores reflect how a model performs on controlled problems, while a working artifact tests its comprehensive capabilities across long-chain tasks: whether it understands requirements accurately, whether its code structure is reasonable, whether modules connect correctly, whether it can self-correct after errors, and whether the final output is actually operable. For developers, the latter is clearly closer to real-world work.

This article does not discuss specific leaderboards. Instead, it examines these models from an engineering practice perspective—their capability boundaries, cost structures, and usage patterns in typical scenarios—and offers practical recommendations for adoption.

2. Breaking Down Typical Scenarios: Three Types of Runnable Artifacts

2.1 Game Prototypes: Rapid Construction of Open-World Scenes

The first direction worth attention is game prototype generation. Some developers have used natural language instructions to have a model generate a demo scene with open-world characteristics: street layout, vehicle movement, character running animations, and camera following are basically all present, with the overall atmosphere approaching an early prototype of a mature commercial title.

The technical difficulty of such tasks lies not in implementing any single feature, but in coordinating multiple subsystems:

• Scene organization: How terrain, roads, and buildings are managed in layers to avoid mutual occlusion and performance collapse during rendering;
• Entity system: Vehicles and characters as independent entities, each requiring their own state machines and behavior logic;
• Rendering pipeline: The order and parameter configuration of lighting, shadows, and post-processing effects;
• Input and camera: The connection between view control, movement response, and collision detection.

The fact that the model can produce a runnable prototype in one pass suggests strong coherence in cross-module code organization. More noteworthy is the cost structure: according to the shared report, the project consumed approximately four million tokens (the unit by which models process text and code), with a total cost of around fifty-plus US dollars over a production period of roughly ten hours. For comparison, completing similar work with other solutions at the same tier could cost several times more. For teams that need to quickly validate gameplay, this cost range already has practical reference value.

It should be noted that there is a clear gap between a prototype and a finished product. Generated prototypes typically lack engineering modules such as resource management, save systems, and network synchronization, and most art assets are procedural placeholder content. The reasonable positioning is: use it to compress the time from idea to playable demo, not to replace the full development pipeline.

2.2 3D Web: Turning Static Models into Interactive Pages

The second direction is the generation of 3D interactive web pages. A developer had the model create a model of a foldable device in a 3D modeling environment, then convert it into an operable page in the browser: the device can unfold and fold, and screen content adjusts synchronously with the form factor. The entire process took about an hour and a half and cost about twelve US dollars.

The value of this case lies in connecting two previously separate stages—modeling and front-end interaction. In a traditional workflow, modeling is done by artists and interaction by front-end developers, and the asset handoff, coordinate alignment, and animation binding between the two often consume significant communication overhead. The model generates the “object” and the “behavior” in the same task, so the output is naturally consistent.

From a technical implementation perspective, such artifacts typically rely on the following capabilities:

// Illustration: fold-state-driven view switching logic (pseudocode)
const deviceState = { folded: false, angle: 0 };
function onFold(angle) {
  deviceState.angle = angle;
  deviceState.folded = angle < 90;
  // Adjust the screen content layout and visible area based on the fold angle
  updateScreenLayout(deviceState);
  updateHingeShadow(angle);
}

The pseudocode above reflects a typical state-driven approach: the fold angle serves as a single source of truth, from which a series of view changes are derived. The model’s ability to adopt this kind of structure on its own suggests a certain understanding of how to organize interaction logic, rather than merely piling up styles.

This capability directly helps with product showcases, creative proposals, and interactive documentation. Reviewers no longer need to imagine from static images—they can directly operate, rotate, and unfold to understand the product’s form and interaction logic.

2.3 Dynamic Effects and Structural Decomposition: Testing Detail Fidelity

The third direction leans more toward “detail stress testing.” Some developers had the model generate cloth-fluttering effects to test its representation of soft-body motion; others had the model decompose a mechanical structure into more than two thousand individual parts, each labeled, separated, and displayed.

These two types of tasks correspond to different capability dimensions:

• Cloth fluttering tests understanding of physical approximation, vertex animation, or shader logic, with the emphasis on “naturalness”—whether motion is continuous, whether edges jitter, and whether forces are reasonable;
• Structural decomposition tests hierarchical modeling and batch processing capabilities: more than two thousand parts means more than two thousand objects, hierarchical relationships, naming rules, and assembly sequences. Any naming conflict or hierarchy error can cause the whole thing to fail.

According to the shared reports, some of these cases were completed in under ten minutes. This speed suggests that when handling tasks that are “numerous but repetitive in pattern,” the model can control time consumption through batch generation and rule reuse, rather than writing each one by hand.

3. Cost and Efficiency: Underrated Engineering Metrics

When discussing model capabilities, cost is often placed in a secondary position. But from an engineering decision-making perspective, the comprehensive cost per task (time cost + invocation cost) often determines whether a solution is viable more than any single-point capability.

Task Type	Reference Time	Reference Invocation Cost	Main Consumption Stage
Game prototype	~10 hours	~$50 range	Multiple iterations, code fixes
3D interactive page	~1.5 hours	~$12 range	Modeling description, interaction logic
Short 3D clip	~5 minutes	~$1 range	Single-pass generation, minor adjustments

Two patterns emerge from the table. First, cost is strongly correlated with the length of the task chain: tasks requiring multiple iterations and repeated fixes see token consumption rise by orders of magnitude. Second, short, single-pass tasks cost extremely little and are suitable for high-frequency trial and error.

The implication for usage strategy is direct: break tasks down. Rather than asking for “a complete game” all at once, first have the model generate a runnable minimal skeleton, then iterate module by module. Keep the context of each iteration as lean as possible, avoiding repeatedly carrying irrelevant history into the context, thereby controlling token consumption.

4. Engineering Adoption Recommendations

4.1 Task Decomposition Before Prompt Engineering

Long-chain task failures are mostly not because the model “can’t write,” but because task boundaries are unclear. A three-layer progression is recommended: skeleton—modules—details. First, have the model produce a runnable minimal structure and confirm interfaces and data flow; then supplement the implementation module by module; finally handle styling and edge cases. Each layer should be verifiable to avoid errors accumulating layer by layer.

4.2 Establish Rollback-Capable Version Management

Model-generated code is non-deterministic, and multiple invocations of the same prompt can produce noticeably different results. Save snapshots before each key iteration and bring model output under version control. This way, when subsequent iterations introduce regressions, you can quickly locate and roll back rather than starting over.

4.3 Define Clear Validation Methods

Runnable does not equal correct. For generated 3D scenes, check frame rate and memory usage; for interactive pages, cover different screen sizes and fold states; for structural decomposition, verify part naming uniqueness and hierarchy completeness. The degree of automation in the validation step directly determines iteration speed.

4.4 Set Reasonable Expectations for Capability Boundaries

At the current stage, models excel at “zero to runnable prototype,” but still require human intervention for resource optimization, complex state management, and long-cycle maintenance. Positioning them as “efficient first-draft generators and exploration tools” is more realistic than positioning them as “developer replacements.”

5. Summary

The signal from this round of hands-on testing is clear: the value of large models is shifting from “answering questions” to “delivering runnable artifacts.” Cases like game prototypes, 3D interactive pages, dynamic effects, and structural decomposition all point to the same capability—maintaining structural consistency and logical coherence across long task chains, and delivering at controllable cost.

For developers, what matters is not how impressive any single artifact is, but the cost curve and iteration rhythm behind these artifacts. When the trial-and-error cost per task drops into an acceptable range, the paradigm of prototype validation will change: more ideas can be quickly validated, and more approaches can be eliminated or strengthened early on. How to embed this capability into existing R&D workflows is the real question to address next.