Generating the David Statue with LLMs: A 3D Interactive Web Development Case Study

1. Why Use a “Statue” to Test Large Models?

When new generations of large models are released, 3D and multimodal capabilities are often highlighted by the providers. To verify how these capabilities hold up in actual creative development, I designed an open-ended task as a touchstone: have an AI coding agent build an interactive website that explains how Michelangelo’s David statue was born from a block of stone.

There are three reasons for choosing this topic:

1. Comprehensive Skill Coverage: A 3D interactive website simultaneously tests narrative ability (telling a centuries-old story), visual design (art style and layout), interaction design (how users “participate” in the sculpting), and engineering capability (3D rendering, asset loading, performance optimization). Any weak point will directly reflect in the final product.
2. Objective Acceptance Criteria: The David statue has real dimensions, a real posture, and real historical data. Whether the output model “looks like” David is immediately obvious, avoiding the ambiguity of purely subjective evaluation.
3. Open-Ended Tasks Expose Weaknesses: Checklist tasks (e.g., “build a website with a login page”) are handled well by most coding tools today. However, a task where “narrative, visual style, interaction, and technical routing are entirely up to you” truly tests the model’s autonomous planning and aesthetic judgment.

I structured the prompt as follows:

Goal: Complete an ambitious creation—build an interactive website that 
helps ordinary people understand how Michelangelo's David statue was born 
from a block of stone.
Requirements:
1. After viewing, the audience shouldn't just remember historical facts; 
   they should gain a new understanding of "the act of sculpting" and be 
   willing to pause and observe.
2. You decide the narrative angle, visual style, interaction method, and 
   technical approach. Use your judgment to find the expression that 
   truly fits this theme.
3. You can search for information, find usable assets, write code, and 
   use 3D or other appropriate tools.
4. First assess what the current environment can do, then autonomously 
   proceed until delivering a runnable, experiential work. Do not stop 
   at the planning or mockup stage.

This prompt has four key design choices worth standardizing as a template:

• Goals over Checklists: Define only “what the audience gets” without dictating the implementation path.
• Delegated Judgment: Explicitly tell the model “you decide the technical route” to stimulate autonomy.
• Environment Awareness First: Require an assessment before coding to avoid generating castles in the air.
• Closed Delivery Standards: “Runnable and experiential” is a hard threshold, blocking the retreat of “just outputting mockups.”

2. Two Technical Routes from the Model

Handing the same task to different agents yields distinctly different but equally valid solutions. This test produced two complete works, representing two typical architectures for 3D narrative websites.

Route A: Immersive Experience — “The Remaining Form”

The core narrative is a single sentence: David is what is “left over” from the stone.

• Opening the website reveals a dark room with a complete block of marble in the center.
• The user holds down a button to continuously “chisel,” peeling off pieces of stone block by block until David’s silhouette slowly emerges.
• There is almost no text dumping throughout; the understanding comes from the “hands-on action” itself.

Technically, the key points of this route include:

1. Real Scan Data Foundation: The solution uses a public 3D scan model of the David statue (STL format, from a public digital heritage dataset under an open license). This is a smart choice: self-built approximate models lack persuasive power, while real scan data carries historical texture and authority. For cultural 3D projects, prioritizing open scan assets usually yields better results than purely generated ones.
2. Mesh Subtractive Sculpting: An “outer stone mesh” wraps the “David mesh.” During user interaction, ray picking hits the target point, and boolean subtraction or vertex displacement is applied at the hit area to peel off stone piece by piece. The core interaction loop is outlined below:

// Pseudo-code: Core interaction for holding down the chisel
let chiseling = false;
canvas.addEventListener('pointerdown', () => chiseling = true);
window.addEventListener('pointerup',   () => chiseling = false);
function tick() {
  if (chiseling) {
    const hit = raycast(pointer, marbleMesh);   // Pick the stone surface
    if (hit) {
      carveAround(hit.point, hit.normal, 0.15); // Locally peel off a fragment
      if (exposureOf(davidMesh) > 0.62) {       // Calculate David's exposure rate
        revealStage(nextChapter);               // Drive the narrative to the next act
      }
    }
  }
  renderer.render(scene, camera);
}

1. Performance Trade-offs: Original scan meshes have extremely high polygon counts; doing real-time boolean operations directly in the browser will easily freeze it. The standard practice is: offline mesh decimation during preprocessing to keep the mesh in the tens of thousands of triangles; at runtime, making “peeling” a hybrid of prefabricated fragments and vertex displacement; moving heavy computations into Worker threads so the main thread only handles rendering. If necessary, apply chunked loading and Level of Detail (LOD) management.

Route B: Exhibition Reader — “Man in the Stone”

The other route abandons immersion for a “digital exhibition booklet” style:

• Paper-colored background, serif fonts, looking overall like an exhibition manual.
• Content progresses in four acts, from the quarry to the final completion.
• The core interaction is a slider: dragging it reduces the stone block layer by layer until it becomes David.

The technical cost of this route is much lower than Route A—essentially replacing real-time boolean operations with continuous morph animations (morph target interpolation or hiding mesh slices by layer). However, the narrative pace is more leisurely, and the information density is higher, making it suitable for serious popular science and educational scenarios.

Comparing the Two Routes

Dimension	Immersive Experience	Exhibition Reader
Emotional Impact	High (hands-on participation)	Medium (reading empathy)
Technical Complexity	High (real-time 3D operations)	Low (animation and layout)
Information Capacity	Low (conveyed via metaphor)	High (expandable narrative)
Mobile Friendliness	Average	Good

It is worth emphasizing that both solutions got “interaction as metaphor” right. The essence of sculpting is subtraction, so the core interaction is “removal” rather than “addition”—this reflects an understanding of the theme, not just technical stacking.

3. Narrative Skill in the Details

One impressive detail: the experiential solution provided users with an “Undo” button, but clicking it prompted—“Marble has no undo button.”

This is a classic intertextuality of narrative and interaction:

• Functionally, it honestly informs the user that the operation is irreversible, managing expectations.
• Thematically, it reinforces the sculpting philosophy that “every chisel strike is irreversible”—historically, Michelangelo himself had to abandon projects due to flaws in the stone.
• Emotionally, it makes the user genuinely hesitate for a second before the next strike, realizing the goal of making them “willing to pause and observe.”

This kind of detail cannot be directly demanded via a prompt; it can only emerge autonomously when the model deeply understands the theme. Leaving room for the model’s judgment allows this “human touch” to appear—which is the core value of open-ended tasks over checklist tasks.

4. From Website to Video: Secondary Creation via Asset Reuse

After the website was completed, I used the same methodology to have the agent generate an introductory video. The prompt structure was as follows:

Based on the completed website and previous research, create a 60-90 second 
short video for the general public, helping them understand the essence of 
this website and sparking interest in learning more about the David statue.
Requirements:
1. Judge for yourself how this story is best suited for video expression;
2. You may reuse assets, scenes, and code from the website, or reorganize 
   the visuals;
3. You decide the narrative, camera work, pacing, sound, and visual style;
4. Deliver a playable 9:16 vertical MP4, editable project files, and an 
   asset source list;
5. Actually review the final cut and fix obvious issues.

Compared to the website task, the video task added two engineering requirements: delivering editable project files (ensuring future modifications are possible, rather than a black-box final cut) and an asset source list (ensuring copyright traceability). These two are standard acceptance criteria for content production tasks and are recommended to be standardized in prompt templates.

A practical issue arose during testing: higher-quality video generation relies on more powerful models and greater compute quotas, and the token consumption and costs of high-capability models accumulate quickly. Planning the ratio of “model tier × task complexity” within budget is an unavoidable cost engineering aspect of AI collaborative development.

5. Practical Findings and Engineering Reflections

A few directly reusable experiences:

1. Having Ideas ≠ Delivering: In testing, some models performed excellently during the planning phase with beautiful narrative concepts, but gave up halfway through engineering implementation, leaving semi-finished products that couldn’t run. The key to judging whether a coding model is usable lies in its “finishing capability”: can it self-test, fix errors, and complete the final 10%?
2. Worth Waiting for the Cost Inflection Point: Products of the same generation are often slow and expensive at launch, but subsequent iterative versions will significantly drop in price and increase in speed while maintaining capabilities. For batch production tasks (like generating multiple candidate solutions for comparison), waiting for a more cost-effective version is a rational strategy.
3. Environment Assessment First: Having the model first answer “what can and cannot be done in the current environment” before coding can significantly reduce the idle loop of “generate—error—retry.”
4. Write Acceptance Criteria into Prompts: Hard closing clauses like “runnable and experiential” and “actually review the final cut, fix obvious issues” are the most effective means to prevent the model from stopping at the “mockup stage.”
5. Prioritize Real Assets: Open 3D scan data and public domain art imagery are more convincing than approximations generated out of thin air by the model, especially for cultural themes.

6. Conclusion: Treating AI as a “Collaborator with Judgment”

The biggest takeaway from this practice isn’t the two websites, but a verified workflow:

Define Goals → Delegate Judgment → Assess Environment → Autonomously Execute → Hard Acceptance → Secondary Creation via Asset Reuse.

When large models are sufficiently strong, a developer’s true value is no longer writing code line by line, but: designing good enough problems, providing clear enough acceptance criteria, and pulling it back on track when the model deviates. Michelangelo said he merely “removed the superfluous parts”—good AI collaborative development might be the exact same thing: we are responsible for imagining the David inside the stone, and the model is responsible for chiseling away the excess.