Evaluating Domestic AI Coding Tools: A Hands-On Build of an E-Commerce Site from Scratch

In 2026, competition among AI coding tools has entered a more sophisticated phase. While international benchmarks have established the “AI-native IDE” form factor, domestic tools have gained rapid traction by offering direct local network connectivity, a better understanding of Chinese context, and stronger data compliance. Many developers have already migrated their daily workflows to these domestic solutions. Yet, a persistent gap remains between promotional demos and real-world delivery. Videos showcasing “one-click full application generation” are impressive, but handing a genuine project brief to these tools can often result in broken builds and an endless loop of error-fixing.

Tool selection shouldn’t be based on launch events, but on reproducible, real-world tasks. This article offers a practical evaluation framework: using the “build an e-commerce store from scratch” as a unified benchmark to test the true capabilities of different tools. We will also share best practices for prompt design, staged generation, and acceptance checklists.

1. Designing the Evaluation Task: A Common Benchmark for Comparability

1.1 Task Definition

Using a mainstream component-based front-end framework, build a shopping site with the following 10 pages:

• Homepage (Product Listing)
• Product Details
• Product Purchase
• Purchase Success
• User Login
• User Registration
• User Center - Dashboard
• User Center - Orders
• User Center - Wallet (Coupon Pack)
• User Center - Settings

1.2 Why an E-Commerce Site is an Ideal Benchmark

• Complete User Flow: Browsing → Details → Checkout → Payment Success → Order Management. A break in any link signifies task failure; there is no room for shortcuts.
• State Management Complexity: Login state, shopping cart, orders, and coupon information test the tool’s ability to manage global state effectively.
• Form-Heavy Pages: Login, registration, and settings forms require robust validation logic and thorough error handling.
• High Consistency Requirements: All 10 pages must share navigation, color schemes, spacing, and component styles. This tests the tool’s ability to enforce a “design system” level of uniformity—an area where AI often struggles.

1.3 Evaluation Criteria

Dimension	Key Observations
Functional Completeness	Are all 10 pages present? Is the purchasing flow closed-loop?
Visual & Responsiveness	Mobile adaptation, layout integrity, button readability.
Interaction & Validation	Form validation, error messages, and empty/loading states.
Code Quality	Separation of styles and logic, component granularity, decoupling of data and views.
Engineering Standards	Logical directory structure, successful build on first attempt, extensibility.
Fix Cost	How many rounds of manual intervention are needed to go from “runnable” to “usable”?
Generation Experience	Response time, stability, and recovery from failures.

2. Development Paradigms: Three Models and the “Full-Auto” Debate

Current tools generally fall into three interaction paradigms. Understanding them is key to interpreting test results:

1. Conversational Completion: Primarily chat-based Q&A and inline code completion, with the developer confirming each segment. This offers the most control but has a lower efficiency ceiling for medium-to-large tasks.
2. Single-Agent Auto-Execution: After a task is given, the tool automatically creates files, writes code, and runs builds, typically offering both “full-auto” and “step-by-step confirmation” modes. Full-auto is convenient but operates as a black box, making it costly to roll back or correct course if it goes astray. Step-by-step confirmation is slower but more controllable. Our experience suggests full-auto works well for simple tasks, but “plan-first, confirm-in-segments” is more reliable for complex ones.
3. Multi-Agent/Architecture Planning: An “architect” role first decomposes the task and plans the project structure, which is then implemented by execution agents. This is positioned for complex engineering tasks but incurs a longer response chain and slower speeds.

Additionally, for enterprise and team scenarios, attention must be paid to privacy modes—whether conversations and code are used for training, where data resides, etc. This is often a hard requirement in compliance-driven environments.

3. Six Common Issues Exposed by Hands-On Testing

Across multiple test runs, several highly common “AI-flavored” defects emerge that all users should be aware of:

1. Vast Differences in “One-Shot” Capability: Some tools can complete all 10 pages with a closed loop in a single task run. Others fail on the first run and require multiple “error-fix” cycles to show any results. This difference stems from task decomposition and context management, not just raw model parameters.
2. Visual Design and Responsiveness Are Major Pain Points: Common issues include layouts that are mobile-oriented without proper desktop adaptation, login/registration pages that deform on small screens, invisible white-on-white buttons, excessive use of placeholder images, and inconsistent color aesthetics. The root cause is a lack of explicit design constraints, with models defaulting to “task completion” over “quality completion.”
3. Data and View Coupling: Mock data is often hardcoded within components, requiring near-rewrites when integrating with real APIs later. A good output should abstract mock data into a separate data layer, accessed through a unified interface.
4. Intermittent, Fatal Structural Errors: In severe cases, the directory structure is flawed—such as nested folders with identical names— which directly prevents the project from starting. AI often fails to detect these errors itself because its “confidence” isn’t based on actual execution results.
5. “Placeholder Architecture”: Some outputs include directories for hooks, global state, etc., but leave them internally empty. The skeleton looks professional but is “structure for structure’s sake,” which only adds to comprehension cost.
6. Service Stability and Speed Variance: The generation experience ranges from smooth and responsive to “too slow for patience,” with observable fluctuations during peak hours. For heavy users, this is a non-negligible factor in selection.

4. Root Cause Analysis: Why It “Runs” but Isn’t “Good”

• Context Window and Global Consistency: The design language shared by 10 pages exceeds what a single generation can consistently maintain, leading to visible style drift in later pages.
• Lack of Design System Constraints: Without defining design tokens upfront, colors, spacing, and border-radius are re-generated each time, making consistency unattainable.
• Optimization Goal is “Looks Complete”: Generative models are biased toward outputting structurally complete code that compiles. Runtime correctness, accessibility, and visual details are not direct optimization targets.
• Error Accumulation in the Fix Loop: During multi-round fixes, local patches can break established conventions, making things progressively worse. If a tool lacks whole-repository understanding and self-testing capabilities, fix costs will continue to rise.

5. Best Practices: Getting “Production-Ready” Deliverables from AI

1. Use Structured Prompts Instead of One-Sentence Requirements:

# Role
You are a senior front-end engineer. Deliver a runnable e-commerce shopping site.
# Technical Constraints
- Use a component-based framework with a clear separation of styles and logic.
- Use a unified design token system: primary color, secondary color, spacing (multiples of 4), border-radius, font size scale.
- All pages must share the same navigation bar and footer component.
- All mock data must be placed in the `src/mocks` directory and accessed via a data access layer. Do not inline it within components.
- Mobile-first design, with desktop adaptation at breakpoints: 768px / 1200px.
# Page List (10 pages, all required)
1. Homepage (Product List) ... 10. User Center - Settings
# Acceptance Criteria
- The shopping flow must be a closed loop: List -> Details -> Checkout -> Success Page.
- All forms must have front-end validation and error messages.
- The build must pass on the first attempt with zero console errors.

2. Define Design Tokens First to Prevent “White-on-White” Issues:

:root {
  --brand-500: #2563eb;
  --space-2: 8px;  --space-3: 12px;
  --radius-md: 8px;
  --text-primary: #111827;
  --text-on-brand: #ffffff; /* Text on brand color is fixed to white */
}

3. Generate in Stages: In the first round, generate only the scaffold, routes, design tokens, and shared components. In the second round, generate pages one by one. In the third round, handle integration and responsiveness fixes. Keep a snapshot of each stage for easy rollback.

4. Use a Fixed Acceptance Checklist: After each generation round, self-check for: page count, flow closure, form validation, mobile breakpoints, zero console errors, and data decoupling.

5. Adopt a Scientific Fix Strategy: Fix one problem at a time and request an explanation of the change scope. Prioritize “minimal changes” over full-file rewrites. Immediately re-run the build after each fix to prevent regression.

6. A Decision-Making Framework and Outlook

Stakeholders have different priorities. Individual developers often care about free quotas, ease of learning, and generation speed. Small and medium-sized teams prioritize code quality, engineering maturity, and fix costs. Enterprises, however, are more concerned with data compliance, private instances, audit capabilities, and integration with existing internal R&D processes.

The most effective selection method is to run the benchmark task described in this article against 2-3 candidate tools and score them on the evaluation dimensions. Half a day of testing will yield results far more credible than any marketing material. Major cloud providers typically offer AI-powered coding assistants with free tiers, so the barrier to testing is quite low.

Looking ahead, the frontier for agent capabilities is shifting from “generating code” to “delivering software.” End-to-end delivery that integrates requirement understanding, task decomposition, and self-testing and self-fixing will become the main battleground. Multi-agent collaboration and an “architecture-first” approach will be standard for complex projects. The integration of tools with cloud development pipelines (code hosting, CI/CD, object storage, monitoring) will create a complete “generate-deploy-observe” loop.

Conclusion: The upper bound of an AI coding tool is its model; the lower bound is your engineering discipline. Instead of asking “which tool is strongest,” focus on building your own benchmark tasks and acceptance checklists. Let every tool selection be data-driven and every generation occur within a well-defined constraint. That is the right way to harness AI coding in 2026.