Evaluating LLMs in Frontend Generation and AI Agent Capabilities: From Cool Pages to Controllable Execution

Over the past two years, the evaluation criteria for Large Language Model (LLM) capabilities have shifted from “can it generate a snippet of runnable code” to “can it reliably produce ready-to-use engineering results.” This shift is particularly evident in frontend and AI agent scenarios. In frontend development, pages must not only run but also possess aesthetics, spatial depth, and interactive details. In agent scenarios, models must not only complete tasks but also clearly understand what they are doing, track their current step, and know when to stop. Based on a comprehensive evaluation of frontend generation and agent execution, this article discusses the actual performance, key highlights, and engineering implementation points of current LLMs in these two types of tasks.

1. Frontend Generation: From “Usable” to “Aesthetic and Maintainable”

Frontend code generation is one of the earliest widely validated LLM capabilities, but early models often produced pages with correct structure but crude styling. In this evaluation, the models demonstrated noticeable maturity in the following areas.

1. Aesthetics and Visual Hierarchy

The first threshold for high-quality frontend is not syntax, but visual organization. In testing, the model could generate pages with clear visual hierarchies based on natural language descriptions: the spacing, font sizes, and color contrast between the main visual area, information cards, auxiliary text, and action buttons were reasonable, and the overall style was unified. For abstract descriptions like “tech vibe,” “minimalist style,” or “dark theme,” the model translated them into specific color schemes, border-radius scales, shadow intensities, and font pairings, rather than just applying templates.

The practical significance for developers is that the generated code is more suitable as a “first draft” to enter code review directly, rather than requiring a complete visual redesign. The review cost is reduced from “overthrow and redo” to “local adjustments.”

2. Spatial Understanding and 3D Modeling

When dealing with 3D scenes, the model’s ability to understand spatial relationships is a key differentiator. Tests showed that the model could handle basic spatial parameters such as camera position, relative object coordinates, rotation, and scaling, generating logically sound scene description code. For example, when building a product showcase 3D page, the model arranged the model position, light source direction, and ground reflection according to the description, giving the scene basic spatial depth rather than simple flat stacking.

It should be noted that the model generates code at the level of scene organization and parameter configuration; complex geometric modeling still relies on existing model assets. Therefore, a more sound engineering approach is: let the model handle scene orchestration, interaction logic, and lighting configuration, while art assets are provided by a dedicated pipeline, with the two connected via agreed-upon interfaces.

3. Lighting, Shadows, and Special Effects

Lighting and shadow effects are among the most difficult frontend visuals to generate stably. In testing, the model provided structurally clear implementation solutions for common effect scenarios—gradient glows, blurred backgrounds, particle effects, dynamic highlights—and chose relatively reasonable implementation paths based on performance constraints. For instance, in scenarios requiring mobile compatibility, the model tended to use transform and opacity animations rather than high-cost frame-by-frame calculations.

A reusable evaluation criterion is to observe whether the model provides performance tips alongside the generated effects. An engineering-aware model will often note in comments or explanations which properties trigger reflow or which animations should use composite layers. Such details reflect the model’s engineering maturity better than the effects themselves.

// Example: Model-generated effect implementations usually include performance-related notes
const panel = document.querySelector('.panel');
panel.style.willChange = 'transform, opacity'; // Hint the browser to promote to a composite layer in advance
panel.style.transform = 'translate3d(0, 0, 0)';

4. Engineering Boundaries for Frontend Capabilities

Although the quality of frontend generation has improved significantly, boundaries must be noted during implementation:

• Manual intervention for complex state management: In scenarios involving shared state across multiple components or asynchronous race conditions, the model’s solutions often require developer review.
• Accessibility requires explicit prompts: Semantic tags, keyboard accessibility, and contrast ratios are usually not automatically complete; it is recommended to explicitly specify these constraints in the prompt.
• Unified styling conventions: The model might mix different styling implementations. In engineering, prompts or post-processing should unify these into the established approach.

Overall, in the dimension of frontend generation, models now possess the capability to produce “cool pages and 3D demos” as first drafts, making them suitable as acceleration tools for visual exploration and prototype validation.

2. AI Agent Capabilities: Clear Self-State Perception is the Core Progress

Compared to frontend capabilities, the improvement in agent capabilities is even more noteworthy. The most critical feature is that the model can clearly know its position and state within an agent workflow.

1. Task Decomposition and Execution Boundaries

Agent task failures are often not due to “inability to do it,” but rather “doing too much” or “going off track.” In testing, after receiving a multi-step task, the model first provided task decomposition, then executed step by step, confirming after each step whether the current progress met expectations. This self-state perception brings a direct benefit: clearer execution boundaries. The model knows what the input for the current step is, who the output should go to, and under what conditions it should terminate.

2. Restraint in Tool Calling

Regarding tool calling, an interesting phenomenon was observed: some models exhibit a tendency towards excessive restraint in agent training, meaning they try to minimize call counts and resource consumption. While this is an advantage in cost-sensitive scenarios, it may lead to insufficient information in tasks requiring thorough exploration. The engineering workaround is to explicitly specify calling budgets and sufficiency requirements in the prompt, such as stating “must continue searching if information is insufficient,” to balance restraint with completeness.

3. Impact of State Perception on Reliability

The reliability of an AI agent largely depends on “whether it knows what it has done.” Models with clear state perception performed more stably in the following areas:

• Error recovery: When a tool returns an exception at a certain step, the model can identify the failure point and fall back to a reasonable state, rather than continuing down the wrong path.
• Avoiding redundant work: The model can remember completed sub-tasks, reducing duplicate calls.
• Clear handoffs: In multi-agent or human-machine collaboration workflows, the model can output structured intermediate results for downstream takeover.

Example: Execution log structure of an agent with state perception
step 1: Parse requirements -> Generate task list (3 items)
step 2: Execute Task A -> Success, log result
step 3: Execute Task B -> Tool returns empty result, determine information is insufficient, trigger supplementary search
step 4: Aggregate -> Verify task list completion, output structured results

3. Evaluation Methodology: How to Scientifically Assess Such Models

Based on this evaluation, here is a reusable assessment framework for teams looking to adopt similar capabilities.

1. Frontend Dimension

• Visual fidelity: Given the same description, compare the visual hierarchy and style consistency of the output.
• Spatial合理性 (Spatial Rationality): In 3D scenes, check whether object relative positions and light source directions match the description.
• Performance awareness: Observe whether composite layers, reflow, and other performance-related handling are provided.
• Maintainability: Check if the code structure, naming, and style organization are easy to modify later.

2. Agent Dimension

• Decomposition quality: Is the task breakdown logical, and are there any missing steps?
• State consistency: Are intermediate results correctly recorded and reused?
• Termination judgment: Does it stop after the goal is achieved, and does it actively supplement information when insufficient?
• Exception recovery: Can it fall back and choose an alternative path after a tool failure?

3. Engineering Implementation Points

• Position model outputs as “high-quality first drafts” and retain the manual review process.
• Set explicit calling budgets and termination conditions for agent workflows.
• Explicitly constrain styling approaches, accessibility requirements, and performance goals in prompts.
• Establish a regression test suite to continuously track capability changes brought by model version iterations.

4. Conclusion

From this evaluation, LLMs show a clear trend toward engineering maturity on both frontend generation and agent execution fronts. On the frontend side, they are moving from “able to generate” to “generating aesthetic, performance-conscious code.” On the agent side, they are moving from “able to call tools” to “knowing what they are doing.” For developers, the true value lies not in the peak performance of isolated capabilities, but in whether these capabilities can be stably embedded into existing engineering workflows. Treating models as producers of high-quality first drafts and maintainers of process states—rather than complete replacements—is a more pragmatic approach for the current stage.