LLM Code Generation Tested: Building an Interactive Michelangelo Sculpting Experience

    This article explores the capabilities of Large Language Models (LLMs) in handling complex 3D interactive web development projects. Using the creation of an interactive web experience that simulates the sculpting of Michelangelo's David as a case study, it analyzes the technical performance, engineering challenges, and practical solutions—such as hybrid model scheduling and multimodal delivery—involved in AI-driven code generation.

    In the current evolution of AI programming assistants, generating simple code snippets is no longer sufficient for complex engineering needs. Testing the upper limits of an LLM’s code generation capabilities requires evaluating how well it understands abstract narrative intentions and autonomously executes visual design, interaction logic planning, and frontend 3D rendering. This article uses an ambitious project—building an interactive website that helps users understand the creation process of Michelangelo’s David—as a case study to deeply analyze the technical performance, engineering challenges, and solutions of mainstream LLMs when handling complex 3D interaction projects.

    1. Creative Intent and Technical Challenges

    The core goal of this project was not merely to display a 3D model, but to convey an artistic philosophy: sculpting is the process of stripping away the “excess” material from a stone block to reveal the essential form. To translate this concept into an interactive web experience, the project established the following technical requirements:

    1. Narrative and Visual Integration: Instead of a conventional linear presentation, a dark room environment was used to simulate the gradual revelation of the stone through light and shadow.
    2. Core Interaction Mechanism: Users simulate “chiseling” through press interactions, triggering the block-by-block peeling of the stone model to ultimately reveal the David sculpture inside. Additionally, a counter-intuitive “Undo” button was designed. When triggered, it returns a message stating “Marble has no undo button,” reinforcing the immersive feeling that sculpting is irreversible.
    3. 3D Asset Processing: The project required parsing and utilizing authoritative open-source 3D scan data (such as open-source STL files under the CC BY-SA 4.0 license) for lightweight rendering on the web.

    These requirements posed a high bar for AI models: they needed not only to understand the APIs of 3D graphics libraries like Three.js or WebGL but also to possess spatial geometry imagination. They had to simulate the visual effect of “stone peeling” by calculating vertex differences, applying boolean operations, or transitioning material transparency.

    2. AI Engineering Practices for Complex Long-Chain Tasks

    When faced with long-chain, multi-module development tasks, an LLM’s context window length, instruction-following capability, and engineering decomposition skills are severely tested. During testing, different technical approaches showed significant differences.

    1. Deep Thinking and Limitations of High-Compute Models

    When using flagship models with larger parameter counts and stronger reasoning capabilities, the AI demonstrated excellent architectural design abilities. It accurately understood the “man in stone” narrative concept and autonomously planned a multi-act structure: starting from a whole block of stone, using a drag slider to control the peeling layers, and finally revealing the ultimate form.

    However, these models frequently encountered truncation issues during long code outputs. Due to slower generation speeds and single-output token limits, continuous generation of code involving complex geometric calculations and state management was often forced to pause midway. Although prompts could be used to make the model continue writing, variable name conflicts and logic gaps caused by context loss occurred frequently, resulting in a less-than-ideal rate of ultimately runnable code.

    2. Agile Handoff Strategy with High-Throughput Lightweight Models

    To solve this bottleneck, an “anchor model for architecture, lightweight model for details” relay strategy is often adopted in engineering practice. Once the core architecture and interaction logic were established by the high-compute model, specific tasks like 3D component encapsulation, styling fine-tuning, and deployment finishing touches were switched to high-throughput lightweight models (such as common Flash-tier LLMs).

    Lightweight models are extremely fast and cost-effective when executing specific local code completions. In testing, through precise context injection and project folder state synchronization, these models could fix truncated code and finalize the website in a matter of minutes. They could even simultaneously generate accompanying video introduction scripts and storyboard prompts. This agile iteration strategy is a key path for reducing AI development costs today.

    3. Technical Implementation of Core Interaction Logic

    At the frontend code implementation level, restoring the process of “sculpting David from stone” typically adopts the following technical approach:

    1. Model Loading and Geometry Alignment

    First, the open-source STL scan model needs to be loaded. In a Three.js environment, after parsing the vertex data via STLLoader, it must be precisely aligned with an external box geometry (BoxGeometry) at the axis. This is the foundation for the subsequent “peeling” effect.

    1. // Sample code: STL model loading and initial material setup
    2. const loader = new STLLoader();
    3. loader.load('david_scan.stl', (geometry) => {
    4. geometry.computeVertexNormals();
    5. const material = new THREE.MeshStandardMaterial({
    6. color: 0xeaeaea,
    7. roughness: 0.7,
    8. metalness: 0.1
    9. });
    10. const davidMesh = new THREE.Mesh(geometry, material);
    11. // Centering and scaling alignment processing
    12. geometry.center();
    13. davidMesh.scale.set(0.1, 0.1, 0.1);
    14. scene.add(davidMesh);
    15. });

    2. Visual Simulation of “Chiseling and Peeling”

    Since real-time 3D boolean operations (CSG) in the browser incur massive performance overhead, excellent interaction schemes usually employ an “illusion” approach. Specific practices include:

    • Dividing the outer stone material into multiple small grids (or fragments).
    • Listening for user press events and simulating the falling of stone material by altering the scale property of the outer fragments or adjusting their material’s opacity and visible properties.
    • Generating splashing stone debris using a particle system (Points or Sprites) to enhance physical realism.

    3. “No Undo” State Machine Control

    For the irreversible process of sculpting, the frontend requires a one-way state machine. Each press drives a one-way increase in the peeling progress value. When the user clicks “Undo,” instead of triggering a state rollback logic, a custom UI Modal layer pops up displaying the text “Marble has no undo button.” This is not just an interactive easter egg, but a crucial part of the narrative closure.

    4. Evolution from Code Generation to Multimodal Delivery

    Once the 3D interactive website is deployed, how do we promote this work to the general public? The empowerment of LLMs should not stop at code. In testing, we further required the AI to output a video introduction plan tailored for mobile short-video platforms (e.g., a 9:16 aspect ratio) based on the completed website project.

    This phase requires the LLM to possess cross-modal narrative decomposition capabilities:

    1. Script Generation: Based on the web interaction logic, distill a video structure of “suspenseful intro - visual display - core interaction demo - philosophical elevation.”
    2. Camera and Storyboard Planning: Specify when to show the global dark room, when to focus on a close-up of the stone debris peeling, and the rhythm pacing for the voiceover.
    3. Material Integration: Guide the AI to utilize website screen recording materials, generate voiceover audio via TTS API, and ultimately output an MP4 through a video composition tool.

    In this process, the AI acted as both a project engineer and a video director. Although fully automated, high-quality video output still requires manual fine-tuning today, the efficiency gains provided by AI in material cutting, timeline alignment, and subtitle generation are already highly significant.

    5. Conclusion and Engineering Recommendations

    Through this AI generation test of the David sculpture interactive website, we can derive the following engineering insights:

    1. Narrative-Driven Technology Selection: Do not let the AI blindly write code. Have it output the narrative structure and interaction prototype first. Once the logic is validated, move into the code generation phase to significantly reduce rework.
    2. Hybrid Model Scheduling: For complex 3D or long-page frontend projects, abandon the illusion of a “single model does it all.” Using a high-capability model for architecture and difficult breakthroughs, and a high-throughput model for component filling and finishing, is the optimal balance of quality and cost.
    3. 3D Asset Lightweighting: Rendering high-precision scan models on the web requires polygon reduction and Draco compression. This step should be handled as a preprocessing pipeline to prevent memory overflow when the LLM directly handles massive STL files during code generation.

    As LLMs continue to evolve in code comprehension, spatial reasoning, and engineering collaboration, the future of frontend development and digital interactive art creation will increasingly shift toward an “intent-to-product” paradigm. What developers need to master is no longer just the details of API calls, but the architectural design ability to accurately express business intent to AI.