LLM Coding in Practice: From a Single Prompt to an Interactive 3D Prototype

Evaluation Criteria Are Shifting: From Benchmarks to Running Artifacts

For years, the mainstream way to evaluate the coding ability of large language models has been public benchmarks: function-level code generation pass rates, competitive programming accuracy, repository-level bug-fix rates. These metrics measure how well a model “solves problems,” but they struggle to answer the question developers actually care about — can a one-sentence natural-language requirement be turned directly into a finished product you can open in a browser, play with, click, and interact with?

A wave of recent projects from the developer community offers a different lens. One developer used an LLM to build an open-world-style game scene with streets, vehicles, and a running character. Another generated a release promo with 3D visuals and dynamic camera work in about five minutes. Someone else modeled a foldable phone in 3D modeling software, then brought it into the browser as an interactive demo that can be opened and closed repeatedly, with on-screen content changing in real time as the fold angle changes. In an even more extreme case, a robotic hand model was broken down into 2,317 individual parts, paired with a cloth simulation that flutters naturally — both cases were completed in under 10 minutes.

These demos are more convincing than benchmark scores for three reasons. First, they are end-to-end: from prompt straight to a runnable artifact, with no human taking over the coding in between. Second, they are interactive: not static screenshots, but objects you can manipulate in a browser. Third, they are quantifiable: nearly every case came with its build time, token consumption, and cost — for example, the open-world scene took roughly 10 hours, 4 million tokens, and $51.98 in total; the 3D promo took about 5 minutes and $1.10; the foldable phone took about 1.5 hours and $12.50. This article doesn’t focus on any particular product. Instead, it treats these cases as research samples, dissects the technical pipelines and cost structures behind them, and lays out a reproducible hands-on methodology.

The Technical Pipelines Behind Four Case Studies

Case 1: Open-World Game Scene — Procedural Generation + the Game Loop

The open-world feel doesn’t come primarily from how refined the art assets are, but from an engineering combination of “procedural generation + a real-time loop.” City blocks can be generated in bulk with grid subdivision plus randomized rules; buildings, streetlights, and vegetation are placed according to density functions. Vehicle movement relies on simplified rigid-body physics — acceleration, steering angle, collision detection. Characters and the camera are driven by state machines and third-person follow logic. This kind of code is highly pattern-based, which puts it squarely in the comfort zone of current LLM code generation.

According to the builder, the project took about 10 hours and consumed roughly 4 million tokens. The 10 hours themselves reveal something important: this wasn’t a one-question-one-answer exchange, but an agent-style long-running task — the model continuously generated code, executed it, observed the results, and corrected itself. The builder also estimated that completing the same work with a more expensive inference option could cost an order of magnitude more. Billing rules vary across providers and the estimate is only a reference, but the order-of-magnitude gap does show how elastic the cost structure is in prototype scenarios.

Case 2: 3D Promo Video — Real-Time Browser Rendering Replaces Offline Rendering

Another type of demo is a release promo generated in about 5 minutes for $1.10. Its technical foundation is the browser-side 3D rendering ecosystem: standard rendering techniques built on WebGL/WebGPU are mature enough that 3D visuals can be rendered in real time directly in a web page, with none of the lengthy waits of traditional offline rendering. All the model has to do is translate text instructions into scene descriptions, animation timelines, and camera movement code, which the render loop then outputs frame by frame before being recorded into a video.

“Using a new model to promote a new model” is just a coincidence of the moment. The real takeaway is this: low marginal cost turns “making a 3D promo video for a small feature on a whim” from a luxury into a routine operation. For lightweight scenarios such as product launches, event warm-ups, and social media campaigns, this pipeline already has practical value.

Case 3: Foldable Phone — Bridging Modeling Software and Web Interaction

The third case carries more engineering weight. The developer had the model first complete the foldable phone modeling in a mainstream 3D modeling tool, then export it into a format a web page can load, and finally implement open-and-close interactions in the browser, with the screen content dynamically changing along with the fold angle. The whole process took about 1.5 hours and $12.50.

Broken down, this pipeline chains together three things that used to be separate: first, driving the modeling tool through its scripting interface, automating the modeling process itself; second, converting the model asset from the modeling tool’s format into something the web runtime can load; third, the interaction logic — the folding motion is essentially a rotation transform on a hinge hierarchy plus state machine control, while the screen content is data-bound to the fold angle. In the past, this required days of collaboration between a 3D artist and a front-end engineer; now a single prompt chain compresses it into 1.5 hours. For product showcases, creative pitches, e-commerce product pages, and similar scenarios, this means the cost of “making an interactive digital sample of an idea” has dropped dramatically.

Case 4: Cloth and Robotic Hand — A Stress Test for Physics Simulation and Geometric Complexity

The first two cases test whether things look right; the last two test whether they hold up. How naturally the cloth flutters depends on the quality of the physics simulation — the common industry approach is a mass-spring system with constraint solving, and poorly tuned parameters easily produce clipping or stiffness. Breaking the robotic hand into 2,317 parts is an extreme test of scene organization: the model must generate a clearly structured hierarchy tree, use instanced rendering to keep thousands of separate objects from tanking the frame rate, and keep the geometry of every part sensible. Completing tasks like these within 10 minutes suggests that models are starting to combine fast response on short tasks with sustained capability on long ones.

Why Now: Three Technical Prerequisites

First, code generation quality has crossed the “runnable” threshold. 3D application code is tightly coupled — rendering, physics, input, and resource loading depend on each other, and a single error can black out the entire screen. This demands long-context memory, multi-file project organization, and a high one-shot success rate; otherwise debugging costs will eat every efficiency gain.

Second, the agent workflow loop has matured. A single generation rarely produces perfect code; what really makes the difference is the automated cycle of “generate — run — read errors and screenshots — fix.” The model is no longer just an autocomplete tool but an “engineer” that can execute, observe, and iterate on its own. A 4-million-token long task is, in essence, this loop running for dozens or even hundreds of rounds.

Third, the web 3D stack has standardized. The spread of browser-side rendering means a model’s output is naturally WYSIWYG: a single HTML file is the complete work, and one shared link lets anyone play with it. This low-friction presentation format, in turn, amplifies the reach of every demo.

Token Economics: Units, Metrics, and Cost Structure

First, the unit of measurement. A token is the smallest unit a model uses to process text and code. The common rule of thumb: 1 token corresponds to roughly 0.5–0.75 English words, about 1–1.5 Chinese characters, or a handful of code characters. Generating a 3D scene of a thousand-plus lines, multiplied by the context accumulation across multiple revision rounds, causes token consumption to balloon quickly — that’s where “4 million tokens” comes from.

Based on $51.98 for 4 million tokens, the blended price works out to roughly $10–20 per million tokens. It’s worth stressing that this is only a rough figure from a single case: input/output pricing varies widely across providers and models, so treat actual costs as what your bill says, and don’t over-extrapolate from specific numbers.

More interesting than the absolute price is the change in cost structure. In traditional development, the bulk of prototyping cost is labor — a fixed investment, where trying three times and trying thirty times carry completely different price tags. LLMs compress a single iteration into “minutes of time plus cents of cost,” turning the relationship between iteration count and total cost into a gentle, low-slope line. For tasks that inherently demand high-frequency trial and error — creative validation, prototype exploration — this is an order-of-magnitude improvement. Conversely, for performance-sensitive core systems that need long-term maintenance and have highly settled requirements, human-led engineering development remains the safer choice. AI and traditional development aren’t substitutes; they divide the labor: the former handles the 0-to-1 look and feel, the latter handles the 1-to-100 engineering.

A Reproducible Methodology: Building an AI 3D Prototype in Six Steps

Step 1: Define the minimum demo goal. Make the acceptance criteria concrete enough to “explain in a single screenshot” — for example, “once the page opens in a browser, the arrow keys drive a car through two city blocks at no less than 45 FPS.” The more focused the goal, the stronger the model’s sense of direction.

Step 2: Choose the output format and tech stack. At the prototype stage, prefer single-file HTML output — ready to run and easy to share. For 3D presentation, rely on browser-side rendering to avoid complex local build environments.

Step 3: Deliver prompts in layers; don’t try to do it all in one sentence. A three-stage “skeleton — interaction — polish” approach works well:

[Round 1 - Skeleton] Generate a single-file HTML: an 8x8 procedural city grid,
roads, and a skybox, with a third-person camera following a car
controlled by the WASD keys.
[Round 2 - Interaction] Add collision detection, acceleration and braking feel,
and camera damping.
[Round 3 - Polish] Add lighting atmosphere, particle effects, and a sound toggle.

Step 4: Build the feedback loop. Feed runtime console errors, page screenshots, and frame rate data back to the model so it can “see” its own output. This step has the biggest impact on the success rate:

# Illustrative: a model-driven "generate-run-fix" loop
prompt = build_prompt(requirements)
for round in range(MAX_ROUNDS):
    code = llm.generate_code(prompt)
    result = run_in_headless_browser(code)   # execute in a headless browser
    if result.errors or result.fps < TARGET_FPS:
        prompt = attach_feedback(prompt, result.errors,
                                 result.screenshot, result.metrics)
    else:
        break

Step 5: Control costs. Set a maximum number of retry rounds; split large tasks into independently acceptable modules to avoid regenerating the whole page; archive every working version immediately so you have somewhere to retreat to when “edits make things worse.”

Step 6: Accept and archive. Beyond visual inspection, add three hard criteria: a performance budget (frame rate, memory usage), zero console errors, and code readability. Archive each passing version together with its prompts to build your team’s own prompt asset library.

Typical 3D web code generated by a model looks roughly like this in structure:

// Illustrative pseudocode (not tied to any specific framework API):
// the core logic of the foldable phone interaction
const scene = new Scene3D();
const camera = new Camera({ fov: 60, position: [0, 2, 6] });
const phone = await loadModel("foldable-phone.glb");
scene.add(phone);
let foldAngle = 0;                          // fold angle state
onDrag((delta) => {
  foldAngle = clamp(foldAngle + delta, 0, 120);
  phone.rotateHinge(foldAngle);             // hinge-level rotation transform
  updateScreenContent(foldAngle);           // screen content linked to the angle
});
renderLoop(() => scene.render(camera));

To put this into practice, developers can connect to LLM inference through model services on cloud platforms such as Baidu AI Cloud and embed the loop above into their own development process. The real barrier isn’t the integration itself, but rebuilding your prototype delivery workflow and acceptance criteria around it.

A Reality Check: How Far Are Stunning Demos from Production Use?

First, a demo is not production. Demo works generally lack error handling, test coverage, and maintainability design; the code often “runs but is hard to read,” and it still needs human refactoring and hardening before entering a real product.

Second, performance has a ceiling. Scenes with thousands of parts and complex cloth place harsh demands on draw call counts and memory management. A model can write “correct” code without writing “efficient” code — deep optimization still depends on engineer experience.

Third, security and compliance can’t be skipped. Code generated by a model runs directly in the browser, so it needs review for untrusted logic; the copyright status of 3D assets should also be confirmed before commercial use.

Fourth, teams should establish their own evaluation metrics: runnable rate, average number of revision rounds, per-task cost, and the proportion of tasks requiring human takeover. These four numbers reflect the real capability of LLMs in your own business far better than any third-party demo.

Conclusion

The shift from “the model got smarter” to “the work is viewable, playable, and cost-accountable” is itself a sign that the industry is maturing. For developers, the most pragmatic move isn’t watching demos from the sidelines — it’s picking one small requirement, running the full loop with the methodology above, and measuring the cost and success rate in your own scenario firsthand. LLMs are responsible for quickly turning ideas into things you can see; humans are responsible for judging whether it’s worth further investment. That division of labor is becoming the new normal in creative development.