A Practical Guide to Evaluating Frontend Generation and Agent Capabilities in LLMs

Why Frontend Generation Is a Litmus Test for LLMs

For developers, asking an LLM to generate a working web page directly is one of the fastest ways to assess its overall capability. A seemingly simple landing page exercises aesthetic judgment, layout calculation, state management, and engineering conventions all at once. Adding 3D scenes and animations further requires knowledge of spatial geometry, materials, lighting, and rendering pipelines. In short, frontend generation is a low-cost, high-information probe into a model’s strengths and weaknesses.

Unlike traditional code completion tasks, however, frontend generation is evaluated with a strongly subjective lens: two pieces of code may both run correctly, yet produce visually incomparable results. A robust evaluation method must therefore convert subjective impressions into quantifiable, comparable, and reproducible observations.

Deconstructing the Evaluation Dimensions: From “It Works” to “It Looks Great”

1. Visual Aesthetics and Typography

Key points to examine include color harmony, font hierarchy clarity, whitespace and alignment consistency with design conventions, and uniformity of component styles. One practical technique is to ask the model to produce multiple design variants for the same requirement, then assess both style stability and diversity—rather than relying on a single lucky output.

2. Spatial Understanding and Layout

This dimension tests the model’s grasp of two-dimensional space: whether grid systems are correctly established, responsive breakpoints are reasonable, and the trade-off between absolute positioning and document flow is handled appropriately. A typical stress case is a hybrid layout combining equal-width cards, a floating sidebar, and a fixed bottom action bar—this exposes issues like broken hierarchy and content overflow.

3. 3D Modeling and Visual Effects

This is an advanced differentiator among models. Observation points include: accuracy of geometry construction (proportions and perspective), sensible camera and lighting setups (ambient, directional, and point lights), natural-looking materials and shadows, and smooth interactions such as drag-to-rotate and zoom. WebGL-based in-browser rendering is the most common carrier; a single-file HTML page opened directly in a browser provides immediate verification.

4. Code Engineering Quality

Good looks are not enough. Assess whether the code is modular, uses semantic HTML, handles edge cases (empty data, loading states, error states), and leaves room for maintainable extension in future iterations.

A Practical Testing Method: Tiered Cases and Scoring Criteria

We recommend designing three levels of test cases with increasing difficulty, while keeping the prompt template fixed to enable fair cross-model comparisons:

• L1 Static presentation page — e.g., a product introduction landing page. Evaluates aesthetics and typography.
• L2 Interactive page — e.g., a filterable data dashboard. Evaluates state management and interaction details.
• L3 3D demo scene — e.g., a rotatable and zoomable product showcase. Evaluates spatial understanding and rendering capability.

A reference prompt template:

Role: Senior frontend engineer and visual designer.
Task: Build a single-file HTML page with the theme: ______.
Requirements:
1. Use mainstream frontend technologies, run directly in a browser;
2. Visual style: modern, restrained, breathable, with a consistent grid and spacing system;
3. Interactions: ______ (e.g., card hover feedback, 3D scene with drag-rotate and zoom);
4. Compatibility: latest versions of mainstream desktop browsers;
Output: complete code + brief design notes.

A “three-way” scoring system is recommended: functionality (can it run directly, does it cover the requirements), experience (visual and interaction quality), and engineering (structural clarity and maintainability), each scored from 1 to 5. Each case should be evaluated at least twice, with attention to result stability—a single high score is not sufficient evidence.

Evaluating Agent Capabilities: From Passive Response to Proactive Planning

Agent capability determines whether an LLM rises from a question-answering tool to an execution assistant. Evaluation should focus on four layers:

1. Contextual Self-Awareness

A key observation is whether the model clearly recognizes that it is operating within an agent framework—understanding which tools it has access to and which execution step it is currently on. A useful test case is a “framework self-description” task: inject a tool list and process description into the system prompt, then ask “Which tools can you invoke right now, and what do you plan to do next?” A competent model should accurately restate the environment information and propose a plan consistent with the task, instead of giving generic, context-free answers.

2. Tool Invocation and Result Handling

Construct tasks that require multiple tools in sequence, such as “search for information — read a file — compute and summarize — write the result.” Observe whether the model assembles parameters correctly, attempts to repair failed calls (by fixing parameters or switching to alternatives), and genuinely integrates tool outputs into its final response—rather than fabricating results.

3. Multi-Step Planning and Self-Correction

Give a task with a clear goal but implicit steps, and observe whether the model first breaks down a plan and, when intermediate results deviate from expectations, proactively adjusts its strategy. Deliberately plant “traps”—for example, provide a data file with inconsistent structure—and see if the model notices the anomaly and reports it to the user, rather than pushing through at all costs.

4. Boundary and Permission Awareness

In open-ended tasks (such as autonomous exploration in a simulated environment), observe whether the model executes operations that clearly exceed its authorized scope. An agent with strong “execution drive” but poor boundary awareness poses real production risks. Whether it stops to confirm upon detecting an anomaly is a more valuable signal than how many tasks it completes.

Common Issues and Root Cause Analysis

• The page runs but looks flat: Often caused by insufficient style constraints in the prompt. Explicitly specify color systems and spacing rules in the template.
• The 3D scene lags or shadows look wrong: Common causes include overly dense geometry or an unreasonable number of light sources. Constrain polygon counts and light counts in the prompt.
• The agent “forgets” it is an agent: Usually a result of system prompt dilution over long conversations. Record role consistency across multiple turns during evaluation.
• Incorrect tool call parameters: Distinguish between model capability gaps and unclear tool description documentation. The former calls for a different model or added examples; the latter requires fixing the interface documentation.

Implementation Advice and Engineering Practices

1. Build a case library: Turn the three-tier cases and agent scenarios into a standardized evaluation set. Run regression tests after each model or prompt update to avoid non-comparable “new demo every time” outcomes.
2. Fix the evaluation environment: Standardize browser versions, screen resolution, and hardware to eliminate environmental noise.
3. Use multi-person blind scoring: For highly subjective visual dimensions, have multiple evaluators score independently and average the results to reduce individual bias.
4. Automate initial screening: Use scripts to check whether the page runs, whether the console reports errors, and whether key elements exist—before human review. Example pseudocode:

// Pseudocode: automated initial screening with a headless browser
const page = await browser.newPage();
const resp = await page.goto('file://eval-page.html');
log('HTTP status code:', resp.status());
log('Console error count:', errors.length);
log('3D canvas exists:', await page.$('canvas') !== null);

At the engineering level, when the evaluation workflow and downstream applications need to be deployed in the cloud, general-purpose cloud services can be used to set up the runtime environment: container platforms host the evaluation pages and task executors, object storage archives artifacts from each evaluation round, and logging and monitoring services track the execution traces of multi-step agent tasks for evidence retention. For example, developers can package the evaluation workflow into a standardized pipeline on Baidu AI Cloud, upgrading model evaluation from a manual exercise to continuous regression testing—which also helps teams align on conclusions.

Conclusion

Frontend generation and agent execution represent the two poles of an LLM’s expressive and action-oriented capabilities. A structured, reproducible evaluation methodology is far more valuable than being persuaded by a single impressive demo. Some compare LLMs to a philosopher’s stone that turns base metal into gold—but whether the stone truly possesses that power must be verified through rigorous testing. Developers should treat evaluation as a long-term engineering asset: the case library, scoring rubric, and regression process are the most reliable foundation for model selection and application iteration.