AI Coding Assistants Put to the Test: Building an E-Commerce Site from Scratch

By 2026, AI coding assistants have evolved far beyond simple code completion tools. They can now understand natural language, plan autonomously, and execute multi-step development tasks. The market is crowded with products whose demos look increasingly impressive. But for working developers, the real questions are more practical: Can an AI assistant independently complete a full “zero to one” development task? Is the generated code merely runnable, or is it actually usable? And is the tool accessible, stable, and secure in the developer’s own environment?

Answering these questions requires more than reading feature lists. You need a unified, reproducible evaluation methodology. This article uses a standardized task—building a 10-page frontend e-commerce site—to present a complete framework for evaluating AI coding assistants, along with the typical problems uncovered in testing and how to address them.

Why Full-Process Testing Matters

1. Isolated experiences don’t reflect real capability. In day-to-day use, AI assistants mostly handle localized tasks like completing a function or explaining a piece of logic, which primarily tests a model’s contextual understanding. A “zero to one” build, by contrast, tests long-range planning: page decomposition, routing architecture, state design, and styling systems are all interconnected. If any link breaks, the product won’t run.

2. There’s a gap between “runnable” and “usable.” A project that starts up may still hide hardcoded styles, tightly coupled data, and messy directory structures that make long-term maintenance expensive. Evaluation must go deep into the code itself, not stop at screenshots.

3. The engineering environment is a hard constraint. Users need tools that are directly accessible, responsive, and support privacy modes. Enterprise users must also consider compliance and data security. These factors matter as much as technical capability—sometimes they’re deal-breakers.

Test Task Design: Treating the E-Commerce Site as an Exam

2.1 Task and Prompt

The unified test task is as follows: use a mainstream component-based frontend framework to build a frontend shopping site with 10 pages covering the complete shopping and user account journey:

Use a component-based frontend framework to build a frontend shopping site with 10 pages:
1. Home page (product listing)
2. Product detail page
3. Product purchase page
4. Purchase success page
5. User login page
6. User registration page
7. User center – Dashboard
8. User center – Orders
9. User center – Wallet (cards and coupons)
10. User center – Settings
Requirements: consistent visual style, mobile responsiveness, basic form validation, and mock data stored separately.

2.2 Why This Task Is Discriminating

• Broad coverage: Listing, detail, transaction, and account pages span four major categories with varying component and state complexity.
• Tests the full loop: From browsing products to placing orders and viewing order history, the complete journey most readily exposes consistency issues where pages don’t align with each other.
• Moderate difficulty: No backend or real payment integration required, placing the task within current AI capability boundaries while focusing on engineering quality rather than algorithmic prowess.

The hardest part is “site completeness and overall consistency”—the 10 pages need to look like they were written by the same team in the same timeframe. That’s a genuine test of an AI’s long-range coherence.

Evaluation Criteria: Four Measuring Sticks

3.1 Task Completion Rate and Interaction Mode

Current mainstream assistants generally offer two working modes: step-by-step instruction mode, where developers issue commands and confirm results incrementally, and agent mode, where the AI autonomously breaks down tasks, generates files in batches, and attempts to run and fix issues. During evaluation, record: Can a single prompt complete the task? How many rounds of self-repair does it take to converge after errors? Does it spiral into “fixing one thing breaks another”?

Notably, different tools have different default levels of automation. This reflects a fundamental trade-off around autonomy—similar to the debate over self-driving car levels: more automation means higher efficiency, but debugging costs rise when things go wrong, and users’ tolerance for loss of control tends to be far lower than expected.

3.2 Completeness and Consistency of the Generated Product

• Completeness: Are all 10 pages present? Do forms have validation? Are all images placeholders? Is the detail page content too thin?
• Consistency: Is the color scheme unified? Are component styles coherent? Are there basic visibility errors like white text on white buttons?
• Responsiveness: Does the layout break on mobile viewports? Are critical pages like login and registration misaligned?

3.3 Code Engineering Quality

• Are styles separated from logic, with shared styles and theme variables extracted?
• Is the project structure reasonable, or are there structural errors like nested folders with duplicate names?
• Is mock data decoupled from components, or hardcoded into pages?
• Are extension points like state hooks and global contexts provided, or is it just a pile of page code?

3.4 Stability, Speed, and Usable Environment

• Response speed: Does the tool lag or time out on long tasks?
• Direct accessibility: Is the service smooth to access in the developer’s network environment without additional configuration?
• Privacy mode: Can sensitive code be excluded from model training?
• Cost: Are free tiers and paid plans clear and transparent?

Typical Problems Found in Testing and Root Cause Analysis

4.1 Incomplete output. Most tools generated sites where all images were placeholders and product detail pages were overly simplistic. The root cause: models lack real business data sources, and prompts didn’t explicitly require richer placeholder content.

4.2 Consistency breakdown. Some projects lacked a coherent color system and even produced basic errors like invisible buttons due to white text on white backgrounds. The root cause is that AI generates pages one by one without unified design variable constraints—each page is written in isolation.

4.3 Missing responsiveness. Generated sites often leaned toward one breakpoint, with obvious distortion on the other end—login and registration pages being particularly problematic. Responsive layout requires cross-file holistic planning, which is precisely the weakest link in long-range consistency.

4.4 Engineering structure issues. Testing revealed structural errors like directories nested inside same-named directories, preventing projects from starting. It also showed mock data directly coupled into component code, with reserved hook and context directories left completely empty. This suggests models understand engineering conventions at the level of formal imitation rather than substantive adherence.

4.5 Repair loops. Some tools generated projects that started but had numerous errors. After several rounds of autonomous repair, the issues still hadn’t converged, requiring manual takeover. Error-fixing capability is a core metric for agent mode—“repair convergence speed” is more indicative of real-world performance than “first-attempt success rate.”

Practical Recommendations for Improving AI-Generated Quality

5.1 Prompting: Break Down Tasks, Set Constraints, Define Acceptance Criteria

Instead of asking for 10 pages in a single prompt, proceed in stages: first have the AI output the project structure and design specifications, confirm them, then generate modules one by one. Prompts should explicitly state constraints, for example:

- Use a unified theme variable file to manage colors and spacing
- Store all mock data in a mock directory; do not embed it in components
- Each page must adapt to 375px / 768px / 1440px breakpoints
- Forms must include required-field, format, and length validation

5.2 Iteration Strategy: Small Steps, Fast Feedback

Run and verify each module immediately after generation. Report errors right away to prevent accumulation that makes issues hard to localize. When autonomous repairs fail, read the stack trace yourself and describe the problem precisely to the AI—this is far more efficient than repeatedly saying “fix it.”

5.3 Manual Acceptance Checklist

After the AI delivers, verify against a checklist:

- [ ] All routes navigable, no dead links
- [ ] Form validation fully functional
- [ ] Layout intact across all three breakpoints
- [ ] Colors, font sizes, and spacing use unified variables
- [ ] Mock data decoupled from component logic
- [ ] Build passes with no console errors

Selection and Implementation Considerations

Based on testing experience, teams should focus on four points when choosing a tool:

1. Evaluate real task performance, not demos. Run horizontal tests using standardized tasks similar to your own business needs. Record completion rates, repair rounds, and code quality to build your own evaluation report.
2. Include the engineering environment in the decision. Direct accessibility, response speed, privacy mode, and compliance directly affect daily experience. Major cloud providers have been deeply integrating large model capabilities with development toolchains—for example, Baidu AI Cloud offers intelligent coding assistants with code completion, natural language generation, and agent-style task execution. Evaluate such options based on your environment’s requirements.
3. Define the human-machine division of labor. At the current stage, AI excels at building the “rough shell” from zero to one. The fine finishing—visual polish, performance optimization, edge case handling—still requires human leadership.
4. Establish team-level conventions. Codify directory structures, naming standards, and style constraints into scaffolds and prompt templates so AI operates within constraints rather than improvising freely. A recommended engineering structure:

src/
├── pages/          # Page-level components
├── components/     # Reusable components
├── hooks/          # Custom state hooks
├── context/        # Global state
├── services/       # API and mock data
└── styles/         # Global styles and theme variables

Conclusion

The capabilities of AI coding assistants are expanding rapidly, but the “last mile”—consistency, engineering quality, and maintainability—still requires human oversight. A scientific evaluation methodology is more reliable than any review article: unified tasks, unified criteria, and deep code-level verification will yield conclusions you can trust for your own selection decisions. For developers, the key isn’t obsessing over “which tool is strongest,” but establishing a collaborative workflow of “AI generates, humans verify, conventions constrain”—turning AI into a true pair-programming engineer that boosts delivery efficiency.