Testing the New LLM for Frontend: Better First-Screen Rendering, but Long-Range Instruction Following Still Lags

One Iteration, Two Perspectives: From “Functional” to “Polished”

Large language model iterations are often accompanied by soaring benchmark scores, but a gap frequently remains between paper metrics and actual development experience. A recent model update emphasized increased post-training investments in coding and 3D generation. This article evaluates the differences between the old and new model versions under identical prompts using two reproducible frontend rendering tasks. Beyond the initial visual impression, we focus on the model’s underlying implementation mechanisms and its proficiency in following long-range instructions.

All tests were conducted on the desktop client using the “Advanced” mode, invoking both the old and new models. Following industry conventions, model capabilities might fluctuate after release due to service policy adjustments, so comparative testing was completed within a closely timed window.

Test 1: Single-File Offline 3D Scene Construction

The first test required generating an offline HTML file to build a complete scene featuring a giant ring floodgate, a terraced sea city, and dynamic rising and falling tides. The prompt explicitly specified that the tide simulation could not merely rely on moving a flat blue plane up and down; boats, waterlines, and the submersion state of the plaza all needed to react dynamically. The difficulty lies in the model’s ability not just to write runnable WebGL code, but to maintain logical consistency in scene organization, material rendering, and dynamic mechanisms.

Both versions delivered a native WebGL2 single-file implementation without relying on external images, models, or third-party libraries. However, what truly separated their visual quality was how they organized the scene’s focal points under the default camera.

Composition and Scene Layering

In the older model, the giant ring was large, but the mountainous terrain on both sides occupied too much of the frame. The initial screen was heavily filled with near slopes and distant mountains, causing the city to shrink into the depths of the bay with weak visibility for its buildings and plaza. Although the ring stood in the center, the sea city required significant effort to make out.

The new model showed clear optimization in scene prioritization. The building complex spread across both shores, the central plaza displayed clear concentric terraced layers, and the cold and warm textures of oxidized copper and stone were easily distinguishable. It felt much closer to the “complete world” requested in the prompt, moving away from the awkwardness of simply placing a single ringed object on terrain. This progress indicates a substantial improvement in the model’s scene comprehension and spatial organization, rather than just an inflation of polygon counts.

Implementation of Water Surface Reflections

The water rendering mechanisms also differed fundamentally. The older model primarily used analytical skies, specular highlights, and light smearing to simulate reflections—a somewhat “hacky” approximation. The new model introduced a mirror camera, redrawing the city and boats before sampling them onto the water surface. This gave the shoreline buildings’ reflections an actual spatial source, representing a structural upgrade in the implementation.

Looking at the code structure, the new model’s water rendering logic more closely resembles hand-written engineering implementations:

// Pseudo-code for mirror camera sampling
vec3 reflectedColor = texture(mirrorCameraRenderTarget, uv).rgb;
vec3 waterColor = mix(refractedColor, reflectedColor, fresnelFactor);

This mechanical improvement signifies that the model no longer simply pieces together “looks-like” visual effects. Instead, it is beginning to understand the causal relationships between different stages of the rendering pipeline.

Shortcomings in Parameter Consistency

However, the new model fell short when setting parameters for the maximum tide level. Based on the step heights and peak water level defined in the source code, only the lowest four layers of the new model’s nine-tier plaza were below the average water level at high tide, failing to meet the prompt’s requirement that “most stone steps should be submerged.” Conversely, the older model—which lacked initial visual impact—successfully set the maximum water level to cover the outermost steps.

This highlights a critical issue: improvements in a model’s visual expressiveness do not automatically translate to precise adherence to long-range instructions. When prompts involve multiple interrelated constraints, the model might experience a “trade-off” effect, dropping a local parameter. For frontend development scenarios requiring precise control over business logic, this inconsistency remains a risk to watch out for.

Evolution of LLM Frontend Capabilities Based on Hands-On Testing

These test cases reveal a notable trend: the improvement of LLMs in frontend tasks is shifting from “whether they can generate runnable code” to “whether they can generate well-structured, mechanically sound, and detail-consistent code.” At the same time, long-range instruction following and parameter consistency remain weak points.

Mechanism Understanding Over Visual Stacking

The new model’s improvement in water reflections suggests that when a model grasps underlying mechanisms—such as “reflections require a real spatial source”—the quality of generated code takes a qualitative leap. For developers, the takeaway is that when writing prompts, they should not only describe “how it should look” but also “how it should be implemented.” Naturally, this requires the model itself to possess sufficient domain knowledge to interpret these mechanical descriptions.

The “Forgetting” Phenomenon in Long-Range Tasks

The new model’s failure to fully satisfy the tide height parameter in the first test is not an isolated incident. When tasks involve multiple steps and constraints, models tend to “forget” early constraints during the later stages of generation. This is a universal challenge for current LLMs handling complex frontend tasks.

Common strategies to mitigate this include:

• Breaking down complex tasks into smaller sub-tasks, generating them step-by-step, and then integrating.
• Explicitly emphasizing key constraints in the prompt and asking the model to self-check during the generation process.
• Performing automated validation on the output, such as parsing parameters from the source code to verify if constraints are met.

Practical Impact on Development Workflows

From an engineering perspective, the new model’s enhanced first-screen performance makes it better suited for rapid prototyping and creative exploration. Developers can use it to quickly generate a visually acceptable scene framework and then apply manual adjustments and parameter corrections. In scenarios demanding strict control over business logic, however, developers still need to rigorously review the generated code rather than relying entirely on the model’s one-shot output.

Conclusion

The progress of LLMs in frontend rendering tasks is highly visible. From scene composition to rendering mechanisms, the new model demonstrates stronger scene comprehension capabilities. Yet, long-range instruction following and parameter consistency remain ongoing concerns. For developers, understanding the model’s capability boundaries and introducing manual validation at appropriate stages is crucial for effectively integrating these tools into efficient workflows. The real test for models moving forward is not how stunning the initial screen looks, but whether they can maintain logical consistency as task chains lengthen and constraints multiply.