Testing the New Generation of LLMs on Frontend Generation: From First Impressions to Engineering Usability

1. Background: Why Frontend Generation Capability Deserves Attention

The role of large language models in frontend development has expanded well beyond early use cases like code completion and single-function generation. Models are now expected to handle page structure design, component composition, 3D scene construction, data visualization, and other increasingly complex tasks. In generative UI scenarios, a model can no longer simply output a runnable piece of JavaScript or HTML. It must simultaneously address layout, visual hierarchy, interaction states, resource dependencies, and rendering performance.

These tasks differ significantly from traditional text generation or coding challenge problems. Frontend code quality is difficult to measure with a single metric. A page may run without errors while still suffering from disorganized visuals, unclear layering, and incomplete interaction states, leaving it far from deliverable quality. Evaluating LLM frontend capability therefore requires assessing not only whether the model can generate code, but also whether the output is structurally sound, aligned with engineering requirements, and maintainable.

This article presents findings from a relatively rigorous offline 3D scene generation test, examining how the current generation of LLMs handles a complex frontend task. The test forbade any online resources, third-party libraries, or external model files, restricting the implementation to browser-native capabilities. The required output was an annular water gate scene containing buildings, terrain, a water surface, and tidal variation. The task placed substantial demands on scene understanding, spatial organization, rendering strategy selection, and parameter consistency control, making it a meaningful probe of real-world frontend generation capability.

2. Test Design: A Deliberately Demanding Frontend Scene

To maximize the test’s ability to distinguish between models, the task intentionally avoided common frontend generation comfort zones. The prompt required the model to produce a single offline HTML file that fulfilled the following objectives:

1. Build a massive annular water gate
2. Arrange terraced coastal city areas and a central plaza
3. Implement tides that rise and fall
4. Ensure the water surface does not simply move as a flat blue plane
5. Make boats, waterlines, and plaza flooding states respond to tidal changes
6. Prohibit any dependency on external images, models, or third-party libraries

These requirements simultaneously test multiple capability dimensions:

• Scene composition: The model must determine which elements serve as visual focal points and which function as supporting background, and how to establish a clear hierarchy.
• Spatial modeling: The annular structure, terraces, building clusters, and water surface must form coherent spatial relationships.
• Rendering strategy selection: The model must choose appropriate techniques for water reflections, lighting, and material representation.
• Parameter consistency control: Values such as water height, terrace levels, and flooding extent must align with one another.
• Code engineering quality: Without external dependencies, the code must run independently while maintaining reasonable readability.

The test results show that while models deliver impressive first impressions, deeper inspection of engineering details and parameter consistency reveals persistent weaknesses.

3. Scene Composition: A Noticeable Improvement in First Impressions

Both model versions tested successfully generated single-file implementations based on native WebGL2 without introducing any external resources. This is noteworthy in itself, indicating that current models possess the fundamental ability to generate complex 3D scene code under strict constraints.

However, the two versions differed markedly in how they organized the default camera view.

In the older model’s default perspective, the giant ring dominated the scene, but the surrounding hillsides consumed too much screen area. The initial viewport was heavily filled by nearby slopes and distant mountains, while the coastal city cluster was compressed into the bay depths. The central plaza lacked visual distinction. Within the first seconds of opening the page, users were more likely to focus on the hills than on the core architectural elements, reducing the efficiency of scene communication.

The newer model showed clear improvement in composition. The giant ring, bridge openings, beacon towers, and tiered residential buildings formed a continuous visual sequence. Building clusters spread naturally along both shorelines, and the central plaza achieved strong visual focus through clearly defined concentric terrace layers. In terms of materials, the warm tones of oxidized copper contrasted effectively with the cool gray of stone, separating the architecture from the background. The result came closer to the “complete world” described in the prompt rather than a loose collection of objects placed on terrain.

This difference reflects an important trend: newer models are paying more attention to visual product quality. They no longer merely place elements in correct positions. They consider what users see in the first moments, how visual attention moves, and which elements deserve priority. This aligns more closely with the frontend engineering principle of optimizing the first-screen experience.

4. Rendering Mechanisms: From Surface Simulation to Spatial Sampling

A more significant difference emerged in the water surface rendering implementation.

The older model primarily used analytical sky reflections, sun highlights, and light trails to simulate water reflection effects. Visually, this approach can produce plausible results, but the reflected content has no true scene source. It functions more like a painted-on reflection with no actual spatial correspondence to buildings or boats along the shore.

The newer model introduced a mirror camera approach. In addition to the main scene rendering, it created a separate set of cameras for reflection sampling, rendered the city and boats into an off-screen buffer, and then composited the result through the water surface material. This gives the architectural reflections a genuine spatial source, representing a substantive upgrade in implementation mechanism.

The significance of this change extends beyond a single test case. It suggests that models are beginning to move from visual approximation toward mechanistic correctness. In frontend graphics development, the gap between these two approaches often determines long-term extensibility. Reflections produced through approximation are difficult to keep consistent as scene elements change or camera positions shift. Reflections based on spatial sampling mechanisms maintain reasonable behavior even after scene modifications.

This mirrors a broader evolution in generative AI across engineering domains: a shift from results that look right to processes that are also technically sound. For developers, only the latter serves as a foundation for real engineering workflows.

5. Parameter Consistency: The Engineering Shortcoming Behind the First Impression

Despite clear advances in visual expression and rendering mechanisms, problems emerged when the test probed parameter consistency.

Based on the terrace height and maximum water level parameters in the generated code, the newer model, at full tide, placed only the lowest four levels of the nine-tier plaza staircase below the average water line. This fell short of the prompt’s requirement that most stone steps be submerged. Ironically, the older model, despite its weaker first-screen composition, extended the maximum water level to cover the outermost terrace layer.

This detail exposes a common weakness in current LLM frontend generation: the models excel at generating code that looks reasonable, but they remain weak at cross-module parameter validation and numerical consistency control.

More specifically, when generating the terrace geometry, water height, and tide animation parameters, the model likely drew on three distinct stages of inference without effective cross-validation between them. The number of terrace levels, the height of each level, and the maximum water level were defined separately in the code, but the model never subsequently verified whether these values worked together. The result was a deviation from the intended design.

This is precisely the type of issue that requires the most care in real frontend engineering. A page that looks good but contains internally mismatched parameters often implies extremely high debugging costs later. For teams incorporating LLM-generated code into production pipelines, these subtle parameter inconsistencies may be more dangerous than obvious visual defects.

6. From First Impressions to Engineering Usability: What Still Stands in the Way

Based on this evaluation, we can make a provisional assessment of the current generation of LLMs on frontend generation tasks.

Areas with substantive progress:

• Overall organizational capability for complex scenes has improved, with more mature handling of visual hierarchy.
• Rendering strategy selection is moving toward engineering correctness rather than superficial approximation.
• Stability in generating runnable code under strict constraints has increased.

Areas still requiring attention:

• Cross-module parameter consistency validation is insufficient, and numerical relationships can easily become inconsistent.
• Understanding of quantitative requirements in prompts remains imprecise, especially when multiple layered constraints are present.
• The balance between functional correctness and visual polish in generated code is not yet stable.

For developers, this means LLMs should still be positioned as high-quality assisted generation tools rather than autonomous development systems that produce directly deliverable output. When using models to generate complex frontend code, it is advisable to establish verification workflows, such as:

• Running automated static checks on key parameter relationships in generated code.
• Separately verifying numerical constraints after generation for prompts containing quantitative requirements.
• Adding tests for interaction states, edge conditions, and parameter interdependencies beyond visual acceptance.

7. Conclusion

The new generation of LLMs has shown visible improvement in the first-impression quality of frontend generation. These models are beginning to understand visual hierarchy, material contrast, and spatial organization, the aspects of frontend work more closely tied to product sensibility. They are also making more engineering-aligned choices in core technical areas such as rendering mechanisms. These are encouraging signals.

At the same time, issues such as parameter inconsistency and missed quantitative constraints remind us that the distance from looking right to being engineering-ready remains significant. The central question at this stage is not whether models can generate more visually impressive scenes, but whether they can maintain sufficient numerical rigor and cross-module consistency under complex constraints. For cloud development platforms and intelligent development tools, the ability to build effective verification, testing, and iteration loops around model-generated code will directly determine the real-world value of LLM capabilities in production workflows.