Domestic LLMs in Frontend Code Generation: A Hands-On Evaluation and Engineering Analysis

In recent years, as underlying large language model (LLM) technology has advanced rapidly, industry discussions have repeatedly claimed that certain Chinese models now match or even surpass top international models in specific capabilities. However, beyond the marketing noise, a practical question remains: how well do these models actually generate code in real engineering scenarios, especially for complex frontend business logic?

To explore this question, this article moves away from brand-focused narratives and vendor claims. Instead, it uses a real frontend business requirement as the benchmark to evaluate how current mainstream LLMs perform in AI-assisted programming. The focus is on code generation completeness, comprehension of complex requirements, and overall engineering design across typical pages such as login pages, list pages, and form pages. Based on these results, the article also examines the broader value of open-source collaboration and the co-evolution of AI development and software engineering.

1. Test Environment and Basic Interaction Experience

Before evaluating complex code generation tasks, the basic interaction experience of an LLM largely determines the barrier to entry for developers. In this test, we provided the model with a standard frontend requirements document that included page interaction logic, field validation rules, and UI layout requirements. The development language and framework were not specified, allowing the model to make its own decision. The model ultimately chose React as the primary framework.

From a practical standpoint, current LLMs still face stability challenges when handling complex engineering tasks. During the initial phase of the request, the system frequently displayed messages such as “high concurrency, please wait in queue” or prompts to upgrade to a paid tier. This reflects bottlenecks in underlying compute scheduling and elastic resource scaling when models handle large-scale concurrent inference requests. In cloud-native architectures, addressing these issues typically requires more mature container platforms and auto-scaling mechanisms to ensure high availability.

In terms of generation time, the model took approximately half an hour from requirement parsing to producing a runnable complete project. Although the process was relatively slow, the final output was not scattered code snippets but a complete project structure with an accessible project URL. This “end-to-end” project-level generation capability signals a shift in LLMs from being simple code completion tools toward becoming full-stack engineering assistants.

2. Typical Scenario Testing: Capability Boundaries and Logical Weaknesses

We divided the test project into three typical frontend pages and evaluated the model’s code generation and business requirement restoration capabilities one by one.

1. Login Page: Complete Basic Structure with Usable Quality

The login page is one of the most standardized modules in frontend projects. In this test, the LLM not only implemented the basic form structure and layout but also accurately reproduced the carousel display functionality described in the requirements document. The page ran smoothly with no obvious missing logic.

From an engineering perspective, the completion level of this page was relatively high. It could be considered “ready for production with minor refinements.” This indicates that LLMs already provide considerable practical value when handling highly standardized and pattern-based pages.

2. List Page: Noticeable Decline in Complex Interaction Comprehension

When moving to a product list page with complex business logic, the model’s limitations became apparent. The requirements document explicitly defined multi-dimensional filtering conditions and their linked interaction logic, but the generated code only implemented the basic page structure and data rendering. The filtering functionality was largely missing.

This was not an isolated bug. Rather, it reflects the limitations of LLMs in handling long-context complex instructions. The model was able to extract surface-level UI structure information, but it exhibited “attention loss” when attempting to understand dependencies between fields and state management flows at a deeper logical level.

3. Form Page: Insufficient Validation Logic and Detail Restoration

Form pages are central to data entry and demand particularly high standards for field validation and interaction details. The test results showed that while the generated form page could run, it did not strictly follow the document specifications for linked field validation and special interaction details.

The model tended to generate generic form validation rules, such as required fields and length limits, while demonstrating insufficient understanding of business-specific rules, including custom regular expression matching and multi-field combined uniqueness validation.

3. Overall Style and Engineering Design Assessment

In terms of UI design, the overall style generated by the model could be described as “conservative but acceptable”:

• Better than basic prototypes: The output was more complete than hand-drawn sketches or low-fidelity prototypes, directly producing runnable engineering code.
• Not on par with mature component libraries: Compared with established UI component libraries commonly used in the industry, the generated UI still lagged behind in detail refinement, spacing control, and visual hierarchy.
• Design orientation: The overall approach leaned toward “simple engineering” rather than delivering a product-level “wow factor.” Its core positioning appeared to prioritize engineering usability over visual polish.

4. Comparative Analysis and Core Gaps

When comparing these test results horizontally with industry-leading AI programming tools, several core gaps emerge:

1. Comprehension depth and instruction following: When processing the same document, top-tier models more completely reproduce complex logic such as list filtering and form validation. Their core advantage lies in precise parsing of natural language instructions and logical mapping, rather than merely assembling code syntax.
2. Generation efficiency: Top-tier models can complete complex project generation within minutes, relying on more optimized inference engines and underlying compute scheduling strategies.

Below is an example of the typical output pattern that LLMs produce when handling complex form logic. Models often attempt to parse forms by generating generic schemas, but they frequently struggle with complex business-specific logic:

// Typical form validation logic generated by an LLM (simplified version)
const formRules = {
  username: [{ required: true, message: 'Please enter your username' }],
  password: [
    { required: true, message: 'Please enter your password' },
    { min: 6, message: 'Password must be at least 6 characters' }
  ],
  // For complex logic that dynamically validates based on another field,
  // the model often generates incorrect or incomplete rules
  confirmPassword: [
    { required: true, message: 'Please re-enter your password' }
    // Missing: validator: (rule, value) => value === form.password
  ]
};

5. The Significance of Open Source for AI Development

Given these performance gaps, it is worth re-examining the value of open source in AI development. Some Chinese LLMs have chosen an open-source route. Although their absolute performance may lag behind top closed-source models on specific complex tasks, this open strategy holds irreplaceable value for the broader technology ecosystem:

1. Lowering trial and integration costs: Open-source models allow enterprises to deploy in private environments. By using localized container platforms and object storage services, organizations can protect data security and privacy, which is critical for sensitive industries such as finance and healthcare.
2. Promoting engineering maturity: The strength of the open-source community can quickly address model shortcomings in specific scenarios. Developers can enhance models for particular frontend business rules through fine-tuning, retrieval-augmented generation (RAG), and other techniques.
3. Driving infrastructure evolution: The widespread adoption of open-source models in turn accelerates the maturity of general cloud-native infrastructure, including compute scheduling, distributed training frameworks, logging, monitoring, and alerting.

6. Conclusion and Best Practice Recommendations

Based on this evaluation, current LLMs have made significant progress in code generation capabilities. They perform well on standardized page generation but still have room for improvement in understanding complex business logic and following deep instructions. For developers looking to integrate LLMs into frontend development workflows, the following strategies are recommended:

• Break down requirements into modules: Avoid handing an entire complex project to the model at once. Instead, decompose complex logic into standardized independent modules and generate them incrementally.
• Strengthen prompt constraints: For key interactions such as filtering conditions and validation logic, use more structured pseudo-code or JSON Schema descriptions in the requirements document to improve the model’s comprehension accuracy.
• Define the human-AI collaboration boundary: Treat the LLM as an “advanced scaffolding tool.” Use it to quickly generate basic project structures and standard pages, while retaining human involvement for complex business logic and refined UI tuning.

The open-source movement and continuous iteration of LLMs are reshaping the software engineering paradigm. Understanding their capability boundaries objectively and leveraging their engineering output effectively will be the key to improving developer productivity in the AI era.