Evaluating LLMs for Frontend Project Generation: Capabilities, Gaps, and Improvements

1. Background: Shifting from Benchmark Metrics to Project Implementation

Recently, discussions about general-purpose Large Language Models (LLMs) generating frontend pages and even complete engineering projects have increased. Many evaluations showcase a model’s score on standard benchmarks or its ability to generate a seemingly complete page from a short prompt. This can create an illusion: that models can now act like junior frontend engineers, delivering production-ready business pages directly from requirement documents.

In real-world projects, however, requirements are rarely a single sentence like “make a login page.” Actual requirements typically include:

• Navigation flows between multiple pages;
• Filtering, sorting, pagination, and empty states for list pages;
• Field dependencies, validation rules, and submission behaviors for form pages;
• Data interaction agreements with backend APIs;
• Implicit logic like permissions, error handling, and loading states.

These details are often scattered across requirement documents and require developers to combine them with business context for full comprehension. Therefore, judging whether a model is ready for the frontend development workflow depends not just on its ability to generate a page, but on its ability to maintain stable comprehension and engineering delivery capabilities under complex requirements.

This article uses a real-world project requirement as input to observe how general-purpose models perform in typical scenarios such as login, list, and form pages. The results are abstracted into a reusable evaluation methodology. This article does not endorse any specific model or commercial product; it focuses solely on general capability boundaries and areas for improvement.

2. Evaluation Methodology: Observing Generation Tasks

To approximate real development scenarios, this evaluation used a requirement specification matching actual project standards, including page structures, field descriptions, interaction logic, and boundary conditions. The model’s task was not to output a single component, but to generate a runnable frontend project.

The evaluation focused on the following dimensions:

2.1 Requirement Comprehension Completeness

Does the model identify explicit requirements, such as:

• Which modules the page must include;
• Whether the list page requires a filter area;
• Whether form fields include validation rules;
• Under what conditions buttons are enabled or disabled.

Simultaneously, we observed the model’s understanding of implicit requirements, such as:

• Whether the page accounts for loading states;
• Whether error prompts appear on API failure;
• Whether reasonable placeholders exist for empty data;
• Whether interaction consistency is maintained across different pages.

2.2 Engineering Usability

Is the generated result genuinely runnable, rather than just a static screenshot? Engineering usability includes:

• Complete dependencies;
• Correct routing;
• Reasonable component splitting;
• Unified styling;
• Ease of subsequent development.

A project that can only be displayed but not maintained has very limited value in actual development.

2.3 Code Quality

Code quality determines whether a team can take over the project. Key observations include:

• Presence of excessive duplicate code;
• Clarity of component responsibilities;
• Whether state management is chaotic;
• Maintainability of style organization;
• Presence of obvious type errors or runtime risks.

2.4 Fidelity and Design Sense

Fidelity refers to the consistency between the generated page and the requirement description, while design sense refers to the visual completeness of the page. The two are not identical: a page might be fully functional but visually rough, or visually appealing but functionally deviant.

3. Login Page: High Completion Rate and Solid Pattern Mastery

Experimentally, the login page yielded the best overall performance. The requirements included a carousel area, a login form, a “remember password” option, and a submission entry. The generated page basically covered all these modules.

The high completion rate of the login page can be attributed to the following reasons:

3.1 High Pattern Maturity

The login page is one of the most common pages in frontend projects, with abundant public code, templates, and tutorials. Models have encountered numerous similar structures during training, giving them strong prior knowledge of “what a login page should contain.”

3.2 Relatively Simple Interaction Logic

Login pages typically only involve:

• Username and password input;
• Form validation;
• Login button states;
• Simple redirection logic.

These interaction patterns have been repeatedly validated by extensive engineering practices, making it easier for models to generate expected results.

3.3 Rich Visual References

Design references for login pages are plentiful. Even without a specified design style, the model can generate a standard, visually complete page. It might not be stunning, but it generally avoids obvious layout issues.

However, minor issues remain. For instance, the prompt style for form validation, the visibility toggle for password input, and the persistence logic for “remember password” may be superficial and fail to meet actual business requirements. Overall, the login page is close to being “ready for direct modification and use.”

4. List Page: Significant Differences in Functional Understanding

The list page presented multiple issues during this evaluation. The requirement document explicitly described filter conditions and related interaction logic, but the generated results featured missing filters or inconsistent behaviors.

4.1 Incomplete Filter Logic Implementation

List pages typically include:

• Status filters;
• Type filters;
• Time range filters;
• Keyword search;
• Table column configuration;
• Pagination logic.

The model might generate the table and pagination, but it performs poorly in linking the filter conditions with the table data. For example, filter components might render, but switching them does not change the list data, or filter parameters are not actually passed to the data request logic.

This indicates that the model’s ability to restore “UI structure” is acceptable, but its understanding of “data flow” and “state linkage” remains insufficient.

4.2 Consistent Issues Across Multiple List Pages

Notably, this issue is not an isolated incident but recurs across multiple generated list pages. This suggests a systematic capability deficit rather than a random generation deviation.

This is understandable: list pages are more complex than login pages. They require the model to simultaneously handle:

• UI states;
• Query parameters;
• Data requests;
• Pagination states;
• Empty states;
• Loading states;
• Interaction feedback.

This logic often requires implicit causal reasoning rather than simple template filling. If the model fails to capture key constraints in the requirements, it will generate results that “look like a list page but are practically unusable.”

5. Form Page: Insufficient Restoration Under Complex Constraints

Form pages further exposed the model’s comprehension bottlenecks in complex business scenarios.

5.1 Missing Field Structures and Validation Rules

The requirement document defined a detailed field list, field types, mandatory rules, and some linkage relationships between fields. However, the generated results exhibited:

• Missing fields;
• Ineffective validation rules;
• Unimplemented field linkage logic;
• Incomplete pre-submission checks.

For instance, certain fields should be disabled or hidden under specific conditions, but the page might display all fields constantly. Or, during submission, only frontend non-empty checks were performed without complete validation based on business rules.

5.2 Interaction Details Inconsistent with Documentation

Interaction details on form pages often determine whether the business flow works. During implementation, the model’s understanding of long-text descriptions in the requirements was imprecise, leading to a “implementing the trunk, ignoring the branches” approach.

This reflects a universal issue: current models understand short instructions well, but easily lose key information when dealing with structured requirement documents containing numerous prerequisites and branching logic.

5.3 Capability Decline with Rising Engineering Complexity

From the login page to the list page and then the form page, page complexity gradually increased, while the model’s completion rate gradually decreased. This trend indicates that a model’s capability cannot be judged simply by “whether it can generate a page,” but rather by its performance stability across scenarios of varying complexity.

6. Overall Style: Engineering Usable, but Limited Design Sense

Visually, the generated pages leaned toward a clean, engineering style, basically reaching the level of “slightly better than a wireframe.” However, compared to mature design systems or high-quality templates, a gap remains.

Specifically:

• Conservative color usage;
• Mechanical spacing and layout;
• Unified but flat component styles;
• Basic interaction feedback;
• Lack of visual highlights.

If the goal is merely to quickly build internal tools or validate workflows, this style is acceptable. But for external users or products demanding higher experiences, designer intervention is still required.

This also implies that current models are better suited for generating “usable engineering skeletons” rather than directly producing “visually polished products with market competitiveness.”

7. Core Gap in Complex Tasks: Depth of Understanding

Synthesizing the performance across login, list, and form pages, the core gap can be summarized as “depth of understanding.”

7.1 Surface Structure Restoration ≠ Logic Restoration

The model can generate page structures and even build component hierarchies based on common patterns. However, when requirements involve multiple conditions, states, and interaction paths, the model is prone to logic omissions.

Superficially, the page has many elements; practically, critical paths might be broken.

7.2 Good at Short Prompts, Struggling with Long Documents

Under short, explicit instructions, the model usually delivers good results. But real-world requirements are often lengthy, dense in information, and contain cross-references. The model needs to extract key constraints from long texts and map them to concrete implementations.

Currently, this “long document to complete implementation” capability remains unstable.

7.3 The Gap Between General Generation and Business Understanding

General-purpose models master language and code patterns, not business semantics. They can generate a list page based on the word “list page,” but struggle to truly understand “why this filter condition must link with that field.”

This gap is negligible in simple pages but rapidly amplifies in complex business pages.

8. Impact of Generation Speed and Resource Constraints

In this experiment, the generation process took a considerable amount of time from start to the complete project output. Although generation speed is affected by computing resources, concurrent pressure, and version strategies, this factor cannot be ignored from an engineering perspective.

8.1 Speed Affects Iteration Efficiency

Frontend development is typically a high-frequency iteration process. If a single generation takes dozens of minutes, developers might prefer to manually complete the work rather than wait for the model’s output.

8.2 Limited Interactive Generation Experience

Ideally, model generation should support rapid trial and error: generate a version, then quickly adjust based on feedback. If a single generation takes too long, this interactive workflow is hard to establish.

8.3 Differences in Free vs. Paid Resources

Under different resource conditions, model response speeds may vary significantly. For individual developers or small teams using limited resources, generation efficiency is further impacted.

9. The Proper Positioning of Model-Generated Frontend Projects

Based on the experimental results, positioning the model’s generation capability as “assisted development” rather than “replacement development” is more accurate.

9.1 Suitable for Generating Project Skeletons

Models can quickly generate basic project structures, routing configurations, page frameworks, and common components. This reduces repetitive work, allowing developers to focus on business logic and experience optimization.

9.2 Suitable for Generating First-Iteration Pages

For internal systems, prototype validation, and early demos, model-generated pages can serve as a foundational first version. Subsequent detailed adjustments are more efficient than starting from scratch.

9.3 Unsuitable for Directly Replacing Complex Business Implementations

In scenarios involving complex lists, complex forms, and heavy interactions, the model’s generated results still require deep developer intervention. Human verification is irreplaceable, especially concerning data flows, state linkage, permission controls, and exception handling.

9.4 Need to Establish Secondary Development Standards

To integrate model-generated results into a team development workflow, supporting standards should be established, including:

• Unified directory structures;
• Component naming rules;
• State management conventions;
• API calling standards;
• Code review criteria.

Otherwise, even if a project can be generated, it may become unmaintainable due to chaotic code styles.

10. How to Use These Capabilities in Practice

If teams wish to incorporate model generation capabilities into their frontend development workflow, they should consider the following practices.

10.1 Split Requirements and Generate Incrementally

Do not attempt to generate the entire system at once. Split requirements by page or module, allow the model to generate the base version, and then let developers incrementally add complex logic. This reduces the comprehension difficulty of a single generation.

10.2 Define Engineering Standards First

Before generation, explicitly require the model to follow specified directory structures, component organization methods, and styling schemes. Although the model might not fully comply, explicit constraints improve the consistency of the output.

10.3 Conduct Layered Reviews of Generated Results

It is recommended to review the output layer by layer:

1. Is the page structure complete?
2. Are the routing and dependencies correct?
3. Is the interaction logic consistent with the requirements?
4. Is the data state flowing normally?
5. Are boundary conditions and exception handling comprehensive?

Layered reviews uncover issues more effectively than simply “running it to see.”

10.4 Integrate Existing Component Libraries and Design Systems

If the team has mature component libraries or design systems, the prompt can instruct the model to use these specifications. This makes the generated pages more consistent with existing systems and reduces subsequent styling adjustment costs.

11. Expectations for Improving Frontend Generation Capabilities

From this experiment, several key improvement directions emerge.

11.1 Long Document Understanding and Information Extraction

Models need to more accurately extract key fields, interaction rules, and boundary conditions from lengthy requirement documents, avoiding the omission of critical constraints.

11.2 State Management and Data Flow Modeling

The core difficulty in list and form pages lies in state management. Models need to better establish state models, clarifying which states affect UI rendering and which operations trigger state changes.

11.3 Business Logic Validation Mechanisms

After generating a project, models could incorporate self-checking capabilities. For example, identifying missing filter logic, omitted form validations, or unhandled loading/error states.

11.4 Iterative Modification Capabilities

In actual development, requirements constantly adjust. Models need the ability to make localized modifications based on existing projects, rather than regenerating the entire project from scratch every time.

12. Conclusion

This experiment reiterates that the capability of models to generate frontend projects holds practical value, particularly in building project skeletons and generating simple pages. However, in complex business scenarios, models still exhibit clear deficiencies in requirement comprehension depth, logical integrity, and interaction detail implementation.

For developers, the most crucial step is establishing reasonable expectations: these capabilities are suited for efficiency assistance, not direct delivery. Treating model generation as a starting point, and bridging capability gaps through engineering standards, human review, and iterative development, is the most pragmatic implementation approach today.

In the future, if models continuously improve in long document understanding, state modeling, and logic validation, their applicable scope in real-world projects will further expand. Until then, developers still need to shoulder the most critical judgment and implementation responsibilities.