Testing Domestic LLMs for Front-End Code Generation: Capabilities, Gaps, and the Open-Source Path

1. Evaluation Background: From Hype to Engineering Reality

When a new generation of domestic large models is released, social media tends to overflow with bold claims—“on par with top international models,” “a front-end development powerhouse,” and similar strong wording. Such messaging can be exciting, but for developers, the only way to know whether a model actually works is to run it against a real project.

This article takes the front-end requirements of a real project as a sample and asks a domestic large model to fully implement a front-end project consisting of a login page, a product listing page, and a form page. It records and analyzes the results across dimensions including functional completeness, depth of requirement understanding, UI style, and generation speed, and concludes with a discussion of what such capability improvements mean for open-source attributes and AI development.

It should be noted that the subject of this article is the general technical question of “front-end code generation capability of domestic large models.” The conclusions are oriented toward engineering practice and do not constitute a recommendation of any specific product.

2. Hands-On Experience: Conclusions First

2.1 Access and Queuing

The first issue encountered in testing was resource scheduling: multiple attempts returned messages indicating “too many users, please queue or pay,” and only after repeated tries did the generation process begin. This phenomenon itself indicates that compute supply on the model service side remains tightly balanced, and for users on free quotas, the availability experience suffers.

2.2 Generation Approach and Time Cost

Without specifying a technology stack, the model chose a mainstream front-end framework (a component-based, declaratively rendered SPA framework) to organize the project. Overall generation speed was on the slow side: from submitting the requirements to producing an accessible project, the process took more than half an hour.

One detail worth commending: what the model delivered was not scattered code snippets but a complete, directly accessible project URL. This is critical for the verification phase—developers do not need to first set up a local environment and assemble files to see the pages running, which significantly reduces the cost of initial screening.

2.3 Evaluation Dimensions

To avoid letting subjective impressions dominate the conclusions, this evaluation scored each page across the following dimensions:

• Functional completeness: whether all functions explicitly described in the document were implemented;
• Requirement fidelity: how closely fields, validation, and interaction logic matched the document;
• Structural soundness: whether page structure and component division followed engineering conventions;
• Visual style: whether it reached a level that could be shipped with direct modifications;
• Generation efficiency: the time cost from submission to a runnable artifact.

3. Login Page: Solid Completeness

The login page performed best among the three pages.

The document explicitly specified a carousel requirement, and the model did implement a carousel component and filled in the basic functionality the page needed, with no obvious omissions. The overall page structure was complete, and both styling and interactions ran correctly—at a “tweak and ship” level.

From an engineering perspective, the reason the login page is easy to get right is that its requirement pattern is highly standardized: few form fields, simple validation rules, short interaction paths, and mature layout templates. Such pages appear extremely frequently in training corpora, so the model can reuse existing patterns effectively.

4. Listing Page: Understanding Begins to Slip

Upon moving to the product listing page, problems began to surface in concentrated form.

The document explicitly described filter conditions and interaction logic, but the test result was: the filter options were not implemented. This was not an isolated issue on one page but recurred across multiple listing pages, marking a weakness at the overall capability level.

Specifically, the problems fall into three categories:

1. Right structure, missing functionality: the page skeleton, card layout, and pagination area were all built, but filter controls were missing or non-interactive;
2. Absent state management: the linkage logic between filter conditions and list data was not established, lacking the chain by which condition changes trigger data recomputation;
3. Lost interaction details: common interactions such as multi-select, reset, and condition combination were not reproduced.

From a technical standpoint, the core difficulty of a listing page is not “drawing the page” but translating business rules from the requirements document into runnable state logic. Schematically, a filterable list requires at least the following data flow:

filter condition state → change event → data filtering / request parameter assembly → list rendering → empty state / loading state handling

The model often generates the first and fourth segments but omits the middle linkage. This shows that its ability to map “requirement semantics → state machine” still has a clear discount: the page structure is right, but functional understanding falls short.

5. Form Page: Not Fully Implemented per the Document

The form page ran overall, but fields, validation logic, and interaction details were not fully implemented as described in the document.

Typical deviations observed in testing included:

• Missing or inconsistently named fields: fields defined in the document were not all implemented, or field meanings deviated from the description;
• Incomplete validation rules: rules such as required, format, range, and cross-field validation were simplified or even omitted;
• Lost interaction details: behaviors such as conditional visibility, field linkage, and pre-submission confirmation were not reproduced.

To be fair, the requirements document used in this evaluation was, by the author’s own assessment, written quite clearly. Yet the model’s ability to understand and reproduce complex form requirements was clearly insufficient. The essence of a form page is “codifying structured business rules”: fields have dependencies, validation logic has ordering, and interaction behaviors have state constraints. The complexity of such requirements lies not in the visual layer but in the logic layer—precisely where current models are weaker.

6. Overall Style: Engineering-Ready, But Not Stunning

The overall UI style can be summarized in three points:

1. Better than most low-fidelity prototypes, with basic visual completeness;
2. Still a gap compared with directly applying mature component libraries and mature style solutions;
3. The design sensibility is simple and engineering-oriented, not the “eye-catching” type.

In one sentence: engineering usability takes priority over product aesthetics. For internal tools, rapid validation, and prototype demos, this level is sufficient; for end-user-facing product pages, designers and front-end engineers still need to do a second round of polishing.

7. Comparison with International Mainstream Models: The Gap Is Mainly in “Depth of Understanding”

The same set of features had previously been implemented once with an international mainstream model, allowing a page-by-page comparison:

Dimension	Domestic Model	International Mainstream Model
Login page completeness	Close	Close
Listing page filter and field structure understanding	Clearly insufficient	More complete
Form page field relationships, validation, interaction fidelity	Clearly insufficient	More accurate
Generation speed	Slow (over half an hour)	About a few minutes

The speed difference may be related to free quotas and queuing policies and should not be directly equated with a gap in model inference efficiency. But the gap in understanding fidelity is clear: on the listing and form pages, the international mainstream model reproduced the filter conditions, field structures, and validation logic from the document more completely and accurately.

This also suggests an important judgment: the gap between current domestic models and the international frontier lies mainly not in “whether it can generate a page” but in “whether it can accurately understand a piece of business description and implement it completely.” The former is a code generation problem; the latter is a requirement understanding and logical reasoning problem.

8. What This Means for Open-Source Attributes and AI Development

8.1 The Capability Ceiling of Open-Source Models Is Being Redefined

The industry has generally held that open-source models lag behind the international closed-source frontier by a generation on complex code generation tasks. This hands-on test shows that on highly standardized pages, open-source models can already achieve close completeness; the gap is concentrated in reproducing complex business logic. This means the capability boundary of open-source models is moving upward—and moving fast.

8.2 Open Source Lowers the Cost of “Capability Verification”

The direct value of open-source attributes is reproducibility, auditability, and private deployment. For enterprises, models can be validated against real projects in an intranet environment without uploading business requirements documents to external services; for researchers, weights can be used for fine-tuning and distillation, enabling targeted enhancement for specific business domains (such as industry-specific form specifications or component standards). This “modifiability” is something closed-source APIs cannot provide.

8.3 A Clearly Located Gap Is Actually Easier to Close

This test locates the gap in “depth of requirement understanding” rather than “code generation capability,” which is a valuable conclusion. Code generation can be improved through more high-quality code corpora and reinforcement learning, whereas requirement understanding requires document comprehension, structured reasoning, and state-logic modeling. With a clear direction, investment pays off.

8.4 Practical Impact on the Developer Ecosystem

• Efficiency gains at the prototype stage: standardized pages like the login page can be generated directly, saving setup costs;
• Complex pages still need human backup: listing and form pages require developers to complete filter, validation, and linkage logic;
• Promotes a “document-as-requirement” engineering habit: model fidelity depends heavily on how structured the requirements document is, which in turn pushes teams to write requirements more clearly and executably.

8.5 A Rational View of the “Benchmarking” Narrative

“Performance benchmarking against the international frontier” is a meaningful engineering goal, but the benchmarking dimensions need to be separated: benchmarking on standardized page generation is reasonable; benchmarking on complex business logic reproduction still needs time. For developers, the more practical attitude is to treat the model as a collaborator with uneven but continuously evolving capabilities—use it for efficiency where it excels, and keep human review and completion where it is weak.

9. Conclusion

The core conclusions of this hands-on test can be summarized in four points:

1. Domestic large models already possess the complete delivery capability to “generate a runnable front-end project,” and the delivery form (an accessible project URL) is superior to scattered code snippets;
2. Standardized pages (login page) approach the international mainstream level in completeness, while complex pages (listing page, form page) still show clear gaps in requirement understanding and logic reproduction;
3. The essence of the gap is the ability to map “requirement semantics to state logic,” not code syntax generation;
4. Open-source attributes give such models unique value in verifiability, fine-tuning, and private deployment, with substantive significance for AI technology diffusion and industrial adoption.

For developers, the most pragmatic approach at this stage is: use the model to complete page skeletons and standardized modules, and put logic-intensive parts—filter linkage, form validation, state management—on the human review checklist. For the industry, the upward movement of open-source model capabilities is a certainty; the real watershed is not the messaging of any single release, but whether the fidelity of complex business requirement reproduction can keep converging.