From Code Completion to Interactive 3D Prototypes: What Large Language Models Can Now Build

From “Writing Code” to “Shipping Work”: A New Evaluation Baseline

For a long time, the standard way to measure a large language model’s coding ability was fairly narrow: Can it complete a function? Can it fix a defect? Can it pass unit tests? Recently, however, a wave of projects shared by overseas developer communities has pushed the evaluation bar further. The model’s output is no longer just a code fragment. It is a complete work that users can open, operate, and experience directly.

Examples include:

• An open-world style city scene with streets, moving vehicles, and running pedestrians. Users can roam freely from a third-person view, and the overall atmosphere is close to a mainstream open-world game.
• A concept showcase page for a foldable phone. The body model was first generated in professional 3D modeling software, then packaged into a web page. The phone can unfold and fold, with on-screen content responding to the form factor in real time.
• Mechanical assembly and physics simulation. A robotic hand can be disassembled step by step into more than two thousand parts. Another demo shows cloth drifting dynamically in the wind.
• A product launch short film. Starting from a text instruction, the model produced a promotional video with 3D visuals and dynamic camera movement within minutes.

These works share two traits: they are interactive and perceivable. A one-point improvement on a benchmark is hard for ordinary users to feel. A game scene that runs the moment it is opened can be judged by anyone in ten seconds. That is why this round of showcases spread so widely. For the first time, a leap in model capability was made visible through finished work rather than through scores.

The Technical Foundation: The Model Does Not “Draw” Directly. It Draws Through Code.

To understand what is really happening, it helps to clear up a common misunderstanding: large language models do not output 3D visuals end-to-end. The medium of their output is still code.

1. Code generation is the core

On the web, real-time rendering is done through WebGL-based 3D rendering libraries. On desktop, scripts drive professional 3D modeling software for procedural modeling. In other words, the model’s “3D capability” is essentially an engineering capability. It must understand the node hierarchy of a scene graph, material and lighting parameters, camera logic, and input control logic, then organize all of this into structurally correct, runnable project code.

2. Long context and iterative continuity are prerequisites

A roamable city prototype often involves thousands or even tens of thousands of lines of code. The model must maintain a consistent understanding of the entire project so that it can handle incremental changes such as “switch the camera to third-person follow” or “add collision to vehicles” without starting over each time. In community tests, the feasibility of sessions lasting around ten hours and millions of tokens is a direct result of maturing long-context engineering.

3. Physics and procedural generation determine whether motion feels natural

Looking good in a static frame is only the baseline. Whether things move naturally is a stronger test of actual capability. Cloth simulation requires correct mass, damping, and constraint parameters. Disassembling a robotic hand requires understanding assembly relationships between parts. Running characters and NPC pathfinding rely on procedural generation rules. This is why demonstrations such as “cloth that drifts” and “a robotic hand with more than two thousand parts” are far more convincing than static models alone.

Case Review: Time and Cost Data Worth Recording

Beyond any specific product, developers have shared several sets of measured data that serve as a practical feasibility reference. Tokens are the basic unit used by models to process text and code, and inference services are billed by token usage.

1. Open-world game prototype

About 10 hours, roughly 4 million tokens, and a total cost of about 52 US dollars. The output was a roamable demo with streets, vehicles, pedestrians, and adjustable visual enhancement options. According to the developer’s estimate, using another comparable flagship model for equivalent work could cost around ten times as much. For independent developers, “validating a gameplay idea in an afternoon” is shifting from a luxury to a routine.

2. Launch short film

Built on web-based 3D rendering technology, the process from text instruction to finished video took about 5 minutes and cost about 1.1 US dollars. The video was created for a model launch event, forming an interesting self-referential loop: the model was used to promote the model.

3. Foldable phone interactive web page

Modeling plus web packaging took about 1.5 hours and cost about 12.5 US dollars. This case connected the full pipeline of modeling, export, and web interaction, providing genuine cost reduction for product showcases and creative proposals.

4. Mechanical assembly and cloth simulation

Individual cases generally took under 10 minutes from instruction to completion. Part-level disassembly and flexible physics simulation could be reproduced reliably.

Together, these data points outline a clear cost curve. 3D demonstrations that previously required days of collaboration across artists, modelers, and programmers are now compressed into the scale of hours and dollars. The sharp drop in prototyping cost extends the “fail fast, iterate fast” philosophy into 3D and interactive development for the first time.

A Practical Guide for Developers: Turning Capability into Output

1. Write prompts like engineering requirement documents

Do not write “make me a cool city.” Instead, provide structured constraints. A reusable prompt skeleton looks like this:

Goal: A roamable city scene prototype for the web
Tech stack: Web-based 3D rendering on WebGL
Must include:
- Street grid and building placeholder boxes (formal assets can replace them later)
- Drivable vehicle: WASD controls + simple collision
- Pedestrian NPCs: looping movement along preset paths
- Third-person follow camera
Performance requirement: target 60 FPS, use instanced rendering for repeated models
Acceptance criteria: runs directly in the browser with no local dependencies

2. Advance in stages and lock in milestones

A recommended three-stage process is: gray-box validation, core mechanics, then visual polish. First use placeholder geometry to verify whether the core interaction works. Then gradually replace assets and refine details. At each milestone, save a code snapshot to prevent later iterations from breaking already-validated functionality.

3. Human review is not optional

Model-generated rendering code often has performance pitfalls: creating objects repeatedly every frame, missing instanced rendering, or uncontrolled draw call counts can all create a gap between “it runs” and “it runs smoothly.” Use the browser’s built-in performance panel to locate bottlenecks. Pay special attention to frame rate, memory usage, and script execution time.

4. Choose the right use cases

This capability is best suited to scenarios that emphasize expression over production: game mechanic prototypes, product concept showcases, creative proposals, training demos, and data visualizations. For long-lived commercial products, engineers still need to gate architecture, security, and maintainability. AI accelerates the path from zero to demo. The path from demo to production still demands engineering discipline.

From a Team Perspective: Embedding the Capability into Business Workflows

For teams, the value is not just technical spectacle. It directly compresses three common costs. First, initial interactive 3D showcases for marketing and pre-sales can be produced by product managers themselves. Second, innovation validation no longer requires formal project scheduling; a reviewable prototype can be available the same day. Third, internal training materials, process demonstrations, and digital twin visualization interfaces can be generated quickly at low cost.

In terms of engineering deployment, web-based 3D prototypes naturally fit cloud hosting. Static assets can be managed through object storage. Rendering and inference services can be deployed on container platforms with elastic scaling. Logging services and monitoring alerts can ensure availability. For teams that want to integrate model capabilities privately, cloud platforms with containerized components and adequate compute resources provide a relatively smooth path from prototype to internal tool.

A Balanced Assessment: Strengths, Limitations, and Trends

Authenticity

Interactive, runnable work is hard to inflate. Compared with question-answering benchmarks that can be contaminated by training data exposure, “deliver a playable prototype” is harder evidence to fake.

Economic viability

Token-based billing makes workload and cost linearly convertible for the first time. If the input-output ratio of “tens of dollars for an open-world prototype” is reproduced across more projects, the R&D budget structure of small and medium-sized teams will change materially.

Limitations

Aesthetic quality and asset quality still depend on human judgment. The engineering quality of generated code is uneven. Complex physics scenes may show artifacts such as clipping or jitter. Copyrighted assets and brand imagery still require compliance review.

Overall, the significance of this capability leap is not about replacing anyone. It lowers the barrier to 3D and interactive development from a specialized skill to an expressive ability. When the speed of expressing an idea catches up with the speed of thinking, the most scarce resource in prototype innovation is released: the number of iterations. For developers, the worthwhile next step is to build a personal set of prompt templates, iteration workflows, and performance review checklists, and turn this emerging advantage into reusable productivity.