Evaluating LLM Frontend Generation: From Object Placement to World Building

I. Background: When Models Start Writing Frontend Code

Recently, a cloud provider released a flagship model featuring trillions of parameters and supporting up to a million tokens of context. Diverging from the industry trend of betting on lightweight models for quick returns, this model continues to push the boundaries of frontier capabilities, with post-training specifically reinforcing coding, 3D creation, and financial research.

For developers, the true focus should not be the parameter scale, but the model’s actual performance in long-horizon programming and tool-assisted tasks. Frontend 3D scene generation is an excellent comprehensive benchmark in this regard. It simultaneously evaluates the model’s code organization, spatial imagination, understanding of physical consistency, and prompt adherence.

This article uses an offline, single-file HTML 3D scene generation task to compare the performance differences between two generations of models and abstract a general methodology for evaluating generative frontend code.

II. Test Design: The Challenge of Generating a Complete World

2.1 Task Definition

The model is required to generate a standalone, runnable HTML file using native WebGL2 to implement the following scene:

• A massive ring-shaped water gate
• A terraced coastal city complex
• A navigable tidal system
• Synchronized changes in boats, waterlines, and plaza submersion states based on tide levels

The prompt explicitly demands that the ebb and flow of the tide should not merely be a blue plane moving up and down. Reflections of onshore buildings, the floating and sinking of boats, and the submersion state of the plaza must all change synchronously. This essentially tests whether the model understands that a “water level change” is a systemic state, rather than a simple animation of a single visual element.

2.2 Evaluation Dimensions

We established four core evaluation dimensions:

Dimension	Description
Scene Organization	Whether the primary and secondary elements are balanced under the default camera, and if the building complex has structural layers
Rendering Mechanism	Whether water reflections and material textures are based on real spatial logic
Physical Consistency	Whether tidal parameters and building geometry are numerically self-consistent
Prompt Adherence	Whether specific constraints like “most stone steps are submerged” are fulfilled

III. Comparative Testing: Progress and Regressions Coexist

3.1 Scene Organization: From Object Placement to World Building

Both generations of models delivered native WebGL2 single files with no external dependencies. However, under the default camera, the visual gap was immediately apparent.

The previous generation model had an issue: although the giant ring was massive, the mountainous terrain on both sides occupied more of the frame, pushing the city deep into the bay and weakening the visibility of the buildings. The ring stood in the center, but identifying the coastal city required effort. Essentially, this conveyed a rigid feeling of placing a single ring object onto a terrain.

The new generation model organized the giant ring, bridge arches, beacon towers, and tiered residences into a cohesive landscape. The building complex spread along both shores, and the central plaza featured clear concentric stepped layers. The visual distinction between the warm and cold textures of oxidized copper and stone was apparent. It aligned much closer to the prompt’s requirement of a “complete world.”

This difference reflects the depth of the model’s understanding of scene composition semantics: the former focuses on “whether the object exists,” while the latter focuses on “how objects form a visual narrative together.”

3.2 Rendering Mechanism: From Simulated Reflections to True Mirroring

Water rendering is another key differentiator.

• Previous generation approach: Parsed sky, sun highlights, and light smears to simulate reflections. This is an approximation technique where reflections lack a true spatial source.
• New generation approach: Introduced a mirror camera, redrawing the city and boats before sampling them onto the water surface. The reflections of onshore buildings now have a corresponding real spatial source.

This is a substantial upgrade in implementation. The mirror camera approach incurs higher computational overhead but achieves physically correct reflection relationships. When a boat moves, the water reflection follows accurately, rather than playing a pre-baked smear animation.

3.3 Physical Consistency: The Backend Test Beyond the First Impression

However, the new generation model exhibited a noticeable oversight in setting the maximum tide level parameters.

Based on the step height and maximum water level in the source code, only the bottom four layers of the nine-layer plaza steps are below the average water level at high tide. This fails to fulfill the prompt’s requirement that “most stone steps are submerged.” Conversely, the previous generation model successfully covered the outermost steps with the maximum water level range.

This highlights a critical issue: models excel at creating a “first impression” but still fall short in backend logic requiring precise numerical mapping.

The tidal system is essentially a state machine: tide level height -> water line -> submerged step layers -> boat buoyancy height -> plaza submersion state. The model must establish mathematical mappings between these variables and maintain consistency in the code. A visually stunning scene may not be numerically self-consistent.

IV. Methodology: How to Evaluate Generative Frontend Code

Based on the testing above, we summarized a reusable evaluation framework:

4.1 Three-Layer Inspection Method

Layer 1: Visual Presentation
  - Is the default camera composition reasonable?
  - Are primary and secondary relationships clear?
  - Is there distinct contrast in materials and lighting?
Layer 2: Implementation Mechanism
  - Is it "simulated" or "truly calculated"?
  - Do reflections/shadows have spatial sources?
  - Are animations driven by a unified state?
Layer 3: Numerical Consistency
  - Are numerical constraints in the prompt fulfilled?
  - Are parameters across subsystems self-consistent?
  - Is behavior correct under boundary conditions?

4.2 Common Pitfalls

• Visual Priority Trap: Models tend to prioritize looking good while ignoring precise numerical constraints.
• Local Optimum Trap: Individual objects are exquisitely rendered, but relationships between objects are rigid.
• State Split Trap: Water level, boats, and reflections animate independently without a unified state source.

V. Implications for Development Practice

5.1 Prompt Design Recommendations

To ensure the model generates physically consistent scenes, prompts should explicitly define state variables and mapping relationships. For example:

// Explicitly define the state model in the prompt
const tideLevel = 0.0; // 0.0 ~ 1.0
const stepHeight = 0.5; // Height of each step
const submergedSteps = Math.floor(tideLevel * totalSteps);
// Requirement: Water level, boats, and reflections must all be driven by tideLevel

5.2 Code Review Focus

For frontend code generated by models, developers should focus on reviewing:

1. State Source Singularity: Are all visual changes driven by the same set of state variables?
2. Numerical Mapping Consistency: Are geometric parameters and animation parameters in the same coordinate system?
3. Boundary Condition Handling: Is the behavior correct at maximum and minimum tide levels?

5.3 Human-AI Collaboration Mode

At the current stage, models are better suited for scene scaffolding and visual implementation, while numerical logic and boundary conditions still require manual verification. The ideal workflow is:

• The model generates the initial scene and rendering pipeline.
• The developer defines the state model and constraints.
• The model refactors the code based on the constraints.
• Human verifies numerical consistency.

VI. Conclusion

From object placement to world building, the capability of generative frontend code is evolving rapidly. The new generation of models demonstrates significant progress in scene organization and rendering mechanisms, capable of crafting a more immersive “first impression.”

However, the real test lies in the backend: state management, numerical consistency, and boundary condition handling. These less visible aspects that determine system reliability remain a threshold that current models need to cross.

For developers, understanding the boundaries of model capabilities and designing reasonable prompts and review processes are essential to making generative tools truly serve production practices.