Evaluating LLM Frontend Generation and Agent Capabilities: A Complete Practice from Page Creation to Task Execution

1. Background: Why Frontend and Agent Capabilities Have Become a Dividing Line

LLM evaluation is shifting from “how many questions can it answer correctly” to “can it actually get things done.” In real development scenarios, users rarely ask only for an explanatory paragraph. More commonly, they want a runnable interactive page generated, or they want the model to break down a task on its own, call tools, and iterate until the goal is reached. These two types of needs correspond to frontend generation capability and agent execution capability, and they are two key dimensions for measuring a model’s engineering usability today.

Frontend generation may look like just “writing HTML/CSS/JS,” but it actually imposes compound requirements on the model:

• Aesthetic ability: whether colors, spacing, hierarchy, and motion rhythm are coordinated;
• Spatial understanding: whether element positioning, stacking relationships, and responsive layout match intuition;
• 3D and visual effects: whether it can correctly construct 3D scenes, cameras, lighting, and materials;
• Code runnability: whether the output is self-consistent, has no missing dependencies, and can be previewed directly.

Agent execution tests another set of capabilities: task decomposition, state tracking, tool selection, error recovery, and most critically — knowing which step it is currently on and what should be done next. Based on observations from a hands-on test of a newly released model version, this article abstracts a reusable evaluation framework and provides engineering recommendations for implementation.

2. Hands-On Testing of Frontend Generation: From Aesthetics to 3D

2.1 Aesthetics and Layout: From “Readable” to “Polished”

The first threshold for high-quality frontend output is aesthetics. The more obvious improvements observed in testing include:

1. Clear visual hierarchy: font sizes and weights for titles, body text, and supporting information form a stable gradient rather than random values;
2. Restrained whitespace: container padding and margins follow a unified grid, avoiding elements sticking to edges or feeling crowded;
3. Systematic color schemes: primary, secondary, and accent colors have clear roles, and both dark and light modes maintain contrast.

These are not “mystical” qualities; they are rules that can be described structurally. In practice, you can ask the model to output design tokens first, then generate the page:

:root {
  --space-unit: 8px;
  --radius-md: 12px;
  --color-bg: #0f1115;
  --color-surface: #171a21;
  --color-primary: #4f8cff;
  --color-text: #e8eaf0;
  --color-muted: #9aa3b2;
}

When design tokens are explicitly defined, the model is more likely to maintain consistency in subsequent generation and less likely to produce output that becomes increasingly chaotic.

2.2 Spatial Understanding and Layout: A Prerequisite for 3D Thinking

Spatial understanding is most evident in two types of tasks: complex 2D layouts and 3D scene construction. On the 2D side, the model needs to understand positioning context, stacking order, overflow, and scrolling; on the 3D side, it needs to understand coordinate systems, camera orientation, light direction, and the relative positions of objects.

An effective approach observed in testing is to have the model first provide a structural sketch before writing code. For example, when generating a 3D product showcase page, first describe the scene composition:

• Scene: perspective camera, 45° field of view, initial position slightly above the target;
• Lighting: ambient light + directional light, with the main light shining from the upper left toward the subject;
• Objects: the subject centered, the ground receiving shadows, and the background using a gradient or fog;
• Interaction: mouse drag to rotate, scroll wheel to zoom, with damping.

When these constraints are made explicit, the stability of the generated code improves significantly and rework decreases.

2.3 3D Modeling and Lighting Effects: From Static to Interactive

3D and lighting are the areas in frontend generation most prone to “looking right but running wrong.” Common issues include unreasonable light intensity causing overexposure or a completely black scene, missing material parameters making objects look like plastic, and incorrect camera clipping planes causing objects to disappear.

A practical troubleshooting order is:

1. First confirm the render loop: whether it updates every frame and whether it correctly adapts to size;
2. Then confirm camera and lighting: whether the camera is looking at the target and whether the lighting covers the scene;
3. Finally tune materials and post-processing: roughness, metalness, environment maps, bloom, and tone mapping.

In testing, newer models showed better “parameter intuition” on these tasks, producing initial values close to usable without repeated manual trial and error. For teams that want to quickly produce impressive pages or 3D demos, this capability can directly shorten the prototyping cycle.

3. Hands-On Testing of Agent Capabilities: Clear Task State Is the Core

3.1 Why “Knowing Which Step You’re On” Matters

The most common failure mode for agents is not “not knowing how to do it,” but “forgetting the goal along the way.” Typical symptoms include:

• Repeatedly calling the same tool and falling into a loop;
• Ending prematurely and missing key subtasks;
• Losing early constraints after the context becomes too long;
• Failing to correct errors and continuing along the wrong path.

One notable improvement observed in testing is that the model can clearly express its current stage, completed items, and to-dos. This kind of explicit task state is the foundation of reliable execution. In engineering, this can be reinforced through structured prompting:

{
  "goal": "Generate an interactive 3D product showcase page",
  "stage": "implement",
  "done": ["Requirement breakdown", "Scene design", "Dependency confirmation"],
  "todo": ["Write page structure", "Integrate 3D rendering", "Add interaction", "Self-test"],
  "constraints": ["No external network dependencies", "Interactive within 2 seconds on first screen"]
}

When the model updates and reads back this state every round, the probability of drift in long tasks drops noticeably.

3.2 Tool Invocation and Error Recovery

Another reflection of agent capability is tool invocation strategy: when to look up information, when to execute code, and when to ask for clarification. Better behavior patterns include:

• Validate before expanding: first get a minimal runnable version working, then gradually add features;
• Diagnosable errors: after an error, locate the cause first rather than retrying blindly;
• Clear boundaries: proactively ask about uncertain inputs rather than guessing.

In testing, when execution failed, the model could provide fairly specific correction directions, such as pointing out missing dependencies, parameter type mismatches, or path errors. This is critical for the stability of automated workflows.

3.3 Constraint Retention in Long Contexts

In long tasks, early constraints are the easiest to lose. A feasible engineering technique is periodic constraint rereading: after completing each subtask, recheck the original goals and constraints. This does not require special model capabilities, but it does require prompt structure support. Testing showed that models with better state-tracking ability performed more reliably here, still adhering to the original format and scope requirements after multiple rounds.

4. Engineering Implementation Recommendations: Turning Evaluation into Productivity

4.1 Build a Reusable Evaluation Set

It is recommended to build a small evaluation set around your own business, covering:

• Frontend: layout, responsiveness, 3D, motion, accessibility;
• Agent: task decomposition, tool invocation, error recovery, long-context retention.

For each case, record the input, expected output, and scoring criteria to facilitate comparison across versions.

4.2 Template the Prompt Structure

Solidify successful experience into templates, such as “design tokens first, then structural sketch, then code, and finally self-test.” Templating reduces randomness and facilitates team collaboration.

4.3 Human-Machine Division of Labor

Models are suitable for generation and initial screening, while humans are suitable for acceptance and decision-making. Treating model output as a “high-quality draft” rather than a “final deliverable” can significantly reduce risk.

5. Conclusion

From hands-on observations, the new generation of models has made substantive progress in both frontend generation and agent execution: on the frontend side, aesthetics, spatial understanding, 3D, and lighting are closer to usable output; on the agent side, task state tracking and error recovery are clearer. For developers, the real value lies not in a single demo result, but in whether these capabilities can be embedded into stable, reusable engineering workflows. Building evaluation sets, templating prompts, and clarifying human-machine division of labor are the three key steps for turning model capabilities into productivity.