Testing a Domestic Large Model’s Front-End Code Generation: How Far from “Runs” to “Usable”?

Introduction: Beyond the Hype, a Measured Test

After a recent release of a new version of a domestic large model, technical communities produced a wave of emotional assessments—phrases like “capabilities on par with leading industry models” and “a new generation UI generation tool” appeared repeatedly. As an engineer working in front-end and full-stack development for years, I remain cautious about these claims. A model’s actual capability cannot be judged from demo videos and marketing language alone; it must be tested against real project requirements.

This article documents a complete hands-on test: using a real project’s front-end requirements document as input, the model was asked to independently build a front-end project containing a login page, a product list page, and a form page. The evaluation covers five dimensions—completeness, requirements comprehension, interaction fidelity, UI style, and generation efficiency—and is compared with my earlier experience of implementing the same feature set using a leading industry model. Finally, I discuss what the current state of such models means for the open-source ecosystem and the development of AI technology.

It should be noted that this article discusses “the general capability of large models on front-end code generation tasks” and does not constitute a recommendation or review conclusion for any specific product.

1. Test Design and Overall Experience

1.1 Test Methodology

The test input was a front-end requirements document written in natural language, covering three pages:

• Login page: including a carousel, account and password inputs, a login button, and basic validation;
• Product list page: including multi-condition filtering, list rendering, and pagination interaction;
• Form page: including multi-field entry, inter-field linked validation, and submit logic.

No tech stack was specified; the model chose a mainstream component-based framework on its own. Evaluation points included: whether the page structure was correct, whether features were implemented per the document, whether interaction details were reproduced, and whether the generated output could run directly.

1.2 Access and Generation Experience

The first obstacle in the test was availability: multiple prompts indicated “too many users, please queue or pay,” and only after repeated attempts did the generation process start. This reflects the current strain on inference resources and is a non-negligible engineering constraint for development scenarios that require stable calls.

The generation process was generally slow, taking more than half an hour from submitting the requirements to producing a complete project. By comparison, implementing the same feature set with a leading industry model previously took only a few minutes. The speed difference may be related to resource scheduling policies for free quotas, but in a real development workflow, waiting cost directly affects usability.

One point worth affirming: the model delivered not scattered code snippets but a directly accessible project address, and the pages could actually run. This matters greatly in engineering practice—it means the model has some ability to scaffold projects, organize dependencies, and build and deploy, not just complete single-file code.

2. Page-by-Page Capability Assessment

2.1 Login Page: Good Completeness

The login page performed best among the three. The carousel component required by the document was correctly implemented, input fields, buttons, and basic validation logic were all present, and there were no obvious functional gaps. The overall assessment is “close to launch-ready; usable with minor adjustments.”

This indicates that for clear-structured, simple-interaction, mature-pattern pages, current large models already have high generation reliability. The login page is a typical “templated” scenario with ample coverage in training data, and the model can map requirements to implementation fairly accurately.

2.2 List Page: Requirements Comprehension Begins to Degrade

Moving to the product list page, problems began to appear. The document explicitly described filter conditions and interaction logic, but the filter options were not implemented in the generated result. The page structure itself was correct—table/card layout and data rendering positions matched expectations—but “functional comprehension” was clearly discounted.

More notably, this was not an isolated issue: the same type of omission recurred across multiple list-page scenarios. This suggests that when handling combined “structure + logic” requirements, the model tends to prioritize visual structure completeness while implementing interaction logic insufficiently. Filtering involves state management, condition combination, and data filtering—a typical multi-step reasoning task, and precisely where current models fall short.

2.3 Form Page: Incomplete Document Implementation

The form page could run overall, but field definitions, validation rules, and interaction details were not fully implemented per the requirements document. I consider the requirements document to have been fairly clear—field relationships, validation timing, and error messaging methods were all explicitly specified—yet the model’s ability to understand and reproduce complex form requirements was clearly insufficient.

The difficulty of form scenarios lies in: fields have dependencies (e.g., one field’s value affects another field’s options and validation rules), validation logic must cover both synchronous and asynchronous timing, and interaction details (such as blur validation and unified validation before submit) must correspond precisely. Such requirements place higher demands on the model’s structured comprehension and constraint-following abilities.

2.4 Overall UI Style: Engineering-Usable, Mediocre Design

The UI style was generally acceptable:

• Better than most hand-written prototype pages, with neat layout and reasonable spacing;
• But still behind directly applying a mature component library/style solution;
• The design feel is simple and engineering-oriented, lacking striking visual expression.

In one sentence: engineering usability > product aesthetics. For internal tools, rapid prototypes, and similar scenarios, this level is sufficient; but for end-user product interfaces, human design intervention is still needed.

3. Comparison with a Leading Industry Model: The Gap Is in “Depth of Understanding”

I previously implemented the same feature set with a leading industry model. The comparison is as follows:

Dimension	Domestic Model (this test)	Leading Industry Model
Login page	Close in completeness	Close in completeness
List page	Filter options missing	More complete understanding of filters and field structure
Form page	Fields and validation not fully reproduced	Accurate reproduction of field relationships, validation logic, and interaction details
Generation speed	Over half an hour	Minutes-level
Requirements comprehension precision	Medium	Clearly higher

The conclusion is clear: the gap is not in “whether pages can be generated” but in “whether requirements can be accurately understood.” On simple pages the two are close; as page complexity rises and requirement constraints increase, the leading model’s advantage in document comprehension precision expands rapidly. This also explains why “explosive” community reviews often come from simple demos—simple scenarios do easily “look strong,” but complex requirements in engineering practice are the real dividing line.

4. Significance for Open-Source Attributes and AI Development

4.1 The Value of Open-Source Attributes: More Than “Free”

The significance of such models should not stop at “benchmarking a leading model.” More noteworthy is the structural value brought by its open-source or open-weight attributes:

• Private deployment: Enterprises can deploy the model on their own infrastructure to meet hard requirements such as data residency and compliance auditing—a capability closed-source APIs cannot easily replace;
• Customization and fine-tuning: Teams can fine-tune based on their own code standards, component libraries, and business-domain data, turning “general code generation” into “team-specific code generation”;
• Controllable cost: In batch-call scenarios, the marginal cost structure of self-hosted inference differs from token-billed APIs, and is more favorable for high-frequency users in the long run;
• Ecosystem participation: Open weights mean the community can contribute evaluation benchmarks, toolchains, and best practices, forming a positive cycle.

In other words, the core significance of open-source attributes is returning partial ownership of capabilities to users, turning the model from “a rented service” into “controllable infrastructure.”

4.2 Implications for AI Development: Evaluation Benchmarks Must Keep Pace

This test also exposed an industry-wide issue: there is a gap between community evaluation systems and real engineering needs. Demo-level generation results are easy to spread, but engineering usability depends on depth of requirements comprehension, precision of constraint following, and stability on long tasks. If the open-source community can establish evaluation benchmarks closer to real projects—for example, front-end project generation tasks with multiple pages, multiple interactions, and strong constraints—it will better promote substantive progress in model capabilities.

4.3 Engineering Practice Recommendations

Based on the test experience, here are several practical recommendations:

1. Split task granularity: Break complex pages into two steps—“structure generation + logic supplementation.” First have the model produce static structure, then issue separate generation instructions for interaction logic, which can significantly improve fidelity;
2. Structure the document: Replace long natural-language paragraphs with explicit field tables, state machine descriptions, and acceptance conditions to reduce comprehension ambiguity;
3. Generated output must pass CI: Bring generated code into type checking, unit tests, and build pipelines to use engineering methods to contain model uncertainty;
4. Build an internal evaluation set: Construct regression test sets from the team’s real project requirements to continuously track model iteration results and avoid letting external marketing narratives dictate technology choices.

Conclusion

The conclusion of this test can be summarized as: this type of domestic model is already engineering-usable for simple page generation, still has a clear gap in understanding complex requirements, and its speed and stability are affected by resource constraints. But the more important judgment is that its open-source/open-weight attributes enable private deployment, customized fine-tuning, and ecosystem co-building, so its value does not depend entirely on point-by-point comparison with leading models.

For developers, the rational attitude is: let test data speak, choose by scenario, and use engineering methods as a safety net. For the industry, hype will recede; what truly remains is reproducible evaluation, controllable infrastructure, and a sustainably iterating ecosystem. The progress of domestic models deserves recognition, but “benchmarking” is only the starting point—“usable” is the destination.