From Prompt to 3D Worlds: How to Evaluate Large Model Coding Capabilities

I. From Benchmarks to Working Artifacts: The Changing Signal of Evaluation

A wave of compelling demonstrations has recently emerged in the overseas developer community. One developer used an intelligent coding model to complete an open-world-style game prototype, complete with streets, vehicles, and a controllable character. Another turned a foldable phone into a 3D interactive webpage that can be opened and folded in the browser. Others have shown virtual mechanical hands being disassembled into over two thousand parts, with fabric naturally swaying in the scene. What these works share is that they are not design mockups or concept screenshots—they are finished products that can be opened, operated, and even reproduced directly.

From a technical perspective, these demonstrations matter because the way we evaluate model capability is changing. In the past, we relied on code completion pass rates and benchmark scores. Those scores answer the question: “Can the model write a correct snippet of code?” Community works, however, answer a question closer to real engineering: “Can the model independently deliver a runnable application?” Between the two lies an entire engineering pipeline involving task decomposition, environment interaction, error correction, and performance trade-offs. Crossing that pipeline marks the evolution of the model from a “code assistant” to a “delivery partner.”

II. Four Key Capabilities Validated by the Demonstrations

1. Long-Horizon Task Planning and Self-Repair Loops

Generating a playable game prototype cannot be done in a single question-and-answer turn. The model must break down “build an open-world scene” into subtasks such as scene construction, entity control, camera systems, and collision detection, then generate and verify each one. Current mainstream agentic coding approaches generally adopt a “plan–generate–run–feedback–repair” loop:

# Agentic coding loop (illustrative)
task   = "Build an interactive 3D foldable phone webpage"
plan   = model.plan(task)              # Decompose: modeling, export, page skeleton, interaction logic
while not plan.finished:
    code   = model.generate(plan.next_step(), context=repo_snapshot)
    result = sandbox.run(code)          # Run verification in an isolated environment
    if result.has_error:
        model.fix(error=result.error)   # Locate and fix based on the error message
    else:
        plan.mark_done()

The critical part of this loop is the “feedback” stage: the model must read runtime errors, rendering anomalies, and other signals, and pinpoint the faulty module with precision. The claim in community demos of “completing an interactive case in about ten minutes” essentially indicates that the convergence speed of this loop is now fast enough to watch in real time.

2. Consistency Across Large Codebases

A 3D interactive webpage typically involves thousands of lines of code: scene graph structures, material definitions, animation state machines, and event listeners are all intertwined. The model must maintain clear module boundaries, consistent naming, and aligned interfaces over a long context window. This is a comprehensive test of long-context understanding and generation ability—and the dividing line between something that feels “stitched together” and a “complete work.”

3. Cross-Tool Workflow Orchestration

The foldable phone case is particularly representative: first, build the model in 3D modeling software; then export it to a format loadable by the browser; finally, write the interaction logic so that the folding motion and on-screen content stay synchronized. The model must understand the input/output formats of each stage and generate the “glue code” to chain them together. This tool-orchestration ability is a core feature that distinguishes an agent from a mere “code completer.”

4. Proficiency in Browser-Based 3D Technologies

Browser-side graphics rendering comes with hard constraints: render pipeline, draw call counts, frame rate budgets, and memory usage. In the demos, fabric simulates naturally and over two thousand parts remain fluid, suggesting that the model is not just calling libraries but making correct performance decisions—such as instanced rendering and staged loading—guided by prompts and examples.

III. Technical Breakdown of Three Representative Cases

Case 1: Open-World-Style Game Prototype

A developer reported that such a project took roughly ten hours and a cumulative consumption of millions of tokens, translating to costs on the order of tens of dollars (based on community-reported figures; actual values vary with model pricing and usage patterns). Technical elements include:

• Entity system: batch generation and state management for vehicles and pedestrians;
• Simplified pathfinding and collision: an open world does not require an industrial-grade physics engine, but basic occlusion and collision logic must hold;
• Camera and controls: smooth third-person camera following.

One interesting detail: the author attempted to ask the model to “enable image upscaling and frame generation optimization”—options that do not exist in a browser-based tech stack. When a model faces a request beyond its capability boundary, does it honestly explain and offer alternatives, or does it generate a plausible-looking but fake implementation? That reaction itself is an excellent observation point for evaluating model reliability.

Case 2: Foldable Phone 3D Interactive Webpage

Completed in about an hour and a half, the core difficulty lies in connecting the three-stage chain of “modeling–export–interaction.” The folding animation is typically controlled by a state machine: interpolation transitions occur among three states (expanded, folding, folded), and screen content switches display modes based on the fold angle. The value of this case is that it demonstrates a complete expression pipeline “from object to product,” with direct relevance to product presentation, creative proposals, and web interaction design.

Case 3: Physics Simulation and Structural Disassembly

A classic implementation of cloth simulation uses a mass-spring system with numerical integration. Disassembling a mechanical structure into over two thousand parts tests scene organization: parent-child relationships, disassembly ordering, and staged loading strategies. Some testers report completing both cases in under ten minutes, indicating that for tasks with clear structure and well-defined goals, the model has formed stable solution templates.

IV. Token Economics: Cost Structure and Control Practices

The cost structure of agentic programming differs completely from single-turn Q&A, driven by three main amplifiers:

1. Context accumulation: Each step in the loop carries historical conversation and code snapshots, causing input tokens to expand rapidly across rounds;
2. Retry overhead: A failed run followed by a repair round multiplies the step’s cost by a factor greater than one;
3. Redundant generation: Models tend to “write a bit more than necessary,” making output token costs for long code non-negligible.

A rough estimation follows this order of magnitude:

Total cost ≈ (input tokens × input price + output tokens × output price) × (1 + retry rate)

Several cost-control practices have been repeatedly validated in the field:

• Generate in segments and inject only the necessary context, avoiding full-code context in every round;
• Use sandboxed static checks instead of actual runs to reduce expensive failure retries;
• Offload deterministic steps (format conversion, file migration) to plain scripts, and call the model only at key decision points;
• Build usage tracking into the workflow with a budget breaker:

usage = {"input": 0, "output": 0}
for step in agent_loop:
    resp = model.call(step.prompt, context=step.context)
    usage["input"]  += resp.input_tokens
    usage["output"] += resp.output_tokens
    if usage["input"] + usage["output"] > TOKEN_BUDGET:
        raise BudgetExceeded(usage)   # Budget breaker, hand over to a human

Based on community-shared data, complex 3D projects consume millions of tokens and cost tens of dollars, while a simple promotional clip takes a few minutes and a single-digit dollar amount. This gap reveals a rule that is often overlooked: the degree of task structure, rather than how “complex” it looks, is the stronger determinant of cost.

V. A Rational Assessment: A Five-Point Checklist

When faced with impressive demos, developers and enterprise users are advised to filter information using the following checklist:

1. Reproducibility: Are the prompt, code, and runtime environment publicly available? Can the results be reproduced at a similar cost?
2. Code quality: Is the output modular and maintainable, or is it a one-off “it runs, that’s enough” hack?
3. Real-world constraints: How does the work perform on low-bandwidth networks or low-end devices in terms of frame rate and loading?
4. Failure modes: Proactively present boundary requests and observe whether the model honestly clarifies or “hallucinate-complies”;
5. Survivorship bias: The community showcases success cases; concurrent failed attempts often remain silent.

VI. From Demo to Engineering: A Reasonable Path to Adoption

The most reliable adoption zone for such capabilities today is “high-expression, low-risk” scenarios:

• Prototype validation: Align team understanding with interactive prototypes before writing requirement documents;
• Marketing and communication: Short-lived pages such as campaign pages and product display pages;
• Education and demonstration: Turn abstract concepts into operable 3D teaching aids.

Core business systems and long-lived codebases, on the other hand, should still be human-led in architecture, with models assisting in coding. A pragmatic dividing line: the longer the “expected lifespan” of the code, the higher human involvement should be.

For engineering adoption, a supporting pipeline is usually built around model capabilities: object storage for static assets and model files, container platforms for server deployment, and logging and monitoring services to track the runtime status of generated applications. Major large-model service platforms (including Baidu AI Cloud’s large-model offerings) are evolving toward agentic coding. Developers can build a continuously iterable workflow of “prompt–generate–verify–deploy” based on general large-model APIs and intelligent development tools, rather than treating these demos as isolated magic tricks.

Conclusion

From open-world prototypes to two-thousand-part mechanical disassembly, the real value of this round of community demonstrations is not the spectacle of any particular work—it is the validation of a path: natural language is becoming the shortest route from an idea to an interactive, deliverable artifact. For developers, the more valuable exercise than asking “can models get even stronger” is to design your own verification scenario—testing with real tasks, real budgets, and real constraints to reach your own assessment.