Evaluating LLM Capabilities in Frontend Generation and AI Agents: From Aesthetics to Self-Aware Task Planning

1. Introduction: What Do We Expect from LLMs?

Whenever a new Large Language Model (LLM) is released, the most debated topic in developer communities is rarely its parameter scale. Instead, it often boils down to a somewhat philosophical question: Is the LLM a “Philosopher’s Stone”—a universal catalyst capable of turning vague intents into usable products?

While this metaphor is compelling, an engineering perspective requires a more analytical breakdown. This so-called “turning stone into gold” actually encompasses two distinct capabilities:

1. Generation Capability: Transforming natural language descriptions into structured, runnable artifacts, such as page structures, styling rules, 3D scene descriptions, or shader logic.
2. Agentic Capability: Given a goal, autonomously decomposing steps, selecting tools, observing intermediate results, correcting deviations, and maintaining a clear cognitive awareness of its own state.

The former tests the model’s expression precision and domain knowledge density, while the latter tests its planning stability and state-tracking ability. This article uses an empirical test of LLM frontend and agentic capabilities as a thread to abstract reusable evaluation methods and engineering best practices. It focuses purely on technical capabilities without endorsing any specific commercial product.

2. Test Design: Making Subjective “Coolness” Measurable

Evaluations like “aesthetically pleasing” or “strong spatial awareness” are merely subjective feelings without test case support. To make conclusions reproducible, it is recommended to organize the test set across four dimensions, with basic, advanced, and extreme difficulty levels for each.

2.1 Dimension 1: Static Page Structure and Style Restoration

Basic Level: Given a business description (e.g., “a product list page with a filter bar”), require the output of a semantic structure + responsive layout. Observation points include: whether the tag semantics are reasonable, whether the grid and breakpoints form a system, and whether there are redundant wrapper layers.

Advanced Level: Require the implementation of a specified visual style (e.g., “low saturation, large border radius, soft shadows”) without introducing external dependencies. Observation points include: whether design variables (CSS custom properties) are abstracted, whether the spacing system is consistent, and whether the color hierarchy is maintainable.

Extreme Level: Require the implementation of complex components with interactive states (e.g., multi-step forms, drag-and-drop sortable lists). Observation points include: whether state management is clear, whether event bindings are missing, and whether edge cases (empty data, ultra-long text) are handled.

/* Expected style organization output by the model: variables first, clear hierarchy */
:root {
  --space-1: 4px;
  --space-2: 8px;
  --space-3: 16px;
  --radius-lg: 12px;
  --shadow-soft: 0 4px 16px rgba(0, 0, 0, 0.06);
}
.card {
  padding: var(--space-3);
  border-radius: var(--radius-lg);
  box-shadow: var(--shadow-soft);
}

2.2 Dimension 2: Spatial Understanding and 3D Scene Construction

This dimension is key to distinguishing between “can write a webpage” and “understands space”. The test method involves providing a spatial relationship description of objects (e.g., “three cubes arranged in a triangle, with a point light source above the center”) and requiring the model to output a runnable 3D scene configuration.

Observation points include:

• Correct understanding of the coordinate system and orientation (right-handed system, unit scale, rotation order);
• Camera parameters matching the description (position, orientation, field of view);
• Lighting and materials creating a reasonable light and dark hierarchy, rather than the whole scene being dead white or completely black;
• Whether the scene requires additional post-processing (like tone mapping) to achieve the described atmosphere.

2.3 Dimension 3: Lighting and Special Effects Expression

Special effects are a touchstone for testing whether a model “truly understands the rendering pipeline”. Test items can include: gradient backgrounds, glassmorphism, floating particles, glowing borders, and noise distortion. Observation points include:

• Whether a controllable implementation path is used (e.g., CSS gradients rather than per-pixel scripts);
• Whether animations follow time-stepping rather than hardcoded delays;
• Whether degradation strategies and performance budgets are considered.

// Expected animation organization: time-based stepping, easy to pause and degrade
function tick(now) {
  const dt = Math.min((now - last) / 1000, 0.05);
  last = now;
  updateParticles(dt);
  requestAnimationFrame(tick);
}

2.4 Dimension 4: Agentic Task Planning and State Self-Awareness

This is the most notable shift in recent evaluations. The test method involves giving a multi-step task (e.g., “read local data file -> generate summary -> output an interactive report page”) and observing whether the model can:

1. Clearly list steps and annotate dependencies;
2. Recount “what step I am on, what is known, and what is missing” after each execution;
3. Proactively adjust the plan when tools return exceptions, rather than mechanically retrying;
4. Stop at task boundaries without arbitrarily expanding the scope.

“Clearly knowing what it is doing” sounds like a low bar, but it is actually a high threshold: it requires the model to maintain an internal state summary across multi-turn interactions and realign with the goal before each decision. Engineering-wise, this capability can be made explicit by requiring the model to output a structured state description.

{
  "step": 2,
  "goal": "Summarize data and generate report page",
  "done": ["Read data file", "Validate field integrity"],
  "pending": ["Calculate summary metrics", "Generate page skeleton"],
  "risks": ["Some fields missing, fallback display needed"]
}

3. Empirical Observations: Where Are the Capability Boundaries?

3.1 Frontend Generation: High Quality but Requires Constraints

In static page and visual style tasks, the model performs stably: the semantic structure is reasonable, the style organization is maintainable, and the understanding of composite style descriptions like “low saturation + large border radius + soft shadows” is accurate. In 3D and special effects tasks, the expression of spatial relationships and lighting hierarchy is significantly better than earlier versions, capable of producing directly runnable demo pages with complete aesthetics.

However, the boundaries are equally clear:

• Complex business logic still requires human intervention. When it comes to permissions, pagination, and caching strategies, the model tends to provide implementations that “look right”, requiring line-by-line review of the details.
• Performance awareness is unstable. In special effects tasks, it may choose implementation paths with high overhead, requiring explicit performance budget constraints in the prompt.
• Accessibility is easily overlooked. Contrast, focus management, and semantic tags need to be listed separately in the acceptance checklist.

3.2 Agentic Capability: Clear Planning Progress, but External Validation Still Needed

In multi-step tasks, the model can provide clear step decomposition and recount its own status during execution, significantly reducing the probability of “drifting off course”. When encountering tool exceptions, it can also propose alternative paths instead of dead-loop retries.

Points to note:

• State summaries can be distorted. The model’s self-reported “completed” does not mean the artifact is actually usable; it must be backed by external validation steps (like running tests or structural validation).
• Goal drift in long tasks. As steps increase, early constraints (like “do not introduce external dependencies”) may be gradually forgotten, requiring constraint reminders to be injected in each turn.
• Parameter construction for tool calls remains a weak point. It is recommended to perform input schema validation for critical tools.

4. Engineering Implementation: Placing Capabilities Within Guardrails

1. Prompt Layer: Write acceptance criteria as a checklist injected into the prompt, such as “semantic tags, no external dependencies, include empty data fallback, time-based animation stepping”. Checklists are more effective than adjectives.
2. Validation Layer: Perform automated checks on generated artifacts—structural validation, style variable coverage, dependency whitelist, and accessibility scanning. Let the model’s self-reports be verified against external facts.
3. Layered Usage: Split “draft generation” and “review/modify” into two calls, where the second call only does critique and patching. This usually significantly improves the final quality.
4. Proactive Performance Budget: Explicitly state frame rate targets, animation quantity limits, and above-the-fold resource constraints in the prompt to avoid rework later.
5. Explicit State: Require the agent to output a structured state description in each turn. This facilitates both human review and programmatic parsing for interrupt recovery.

5. Conclusion

Returning to the opening metaphor: LLMs are more like a high-grade ore than a Philosopher’s Stone. They can already produce satisfactory “semi-finished products” in frontend generation, spatial understanding, and lighting expression, and have taken a solid step forward in task planning and state self-awareness. However, turning semi-finished products into deliverable engineering artifacts still relies on clear acceptance criteria, automated validation processes, and rational layered usage strategies.

For developers, the true worthwhile investment is not chasing the hype of a single release, but solidifying evaluation methods, prompt specifications, and validation pipelines as team assets. Capabilities will iterate, but methodologies will endure.