Selecting AI Coding Tools: A Practical Test Building a React E-Commerce Frontend

1. The Problem: When “Writing Code” Is No Longer a Scarce Skill

Over the past two years, AI coding tools have transitioned from simple code completion plugins to task-level agents. Developers’ focus has shifted from “can it generate code” to three more practical questions: Can it deliver a runnable project in a single pass, and does the delivered code meet maintainable engineering standards?

These three questions form the evaluation baseline of this article. To avoid relying on marketing claims, we designed a representative benchmark task, using the same set of prompts to drive four categories of technical approaches. This article does not endorse specific commercial products; instead, it abstracts observed phenomena into reusable technical evaluation criteria.

2. Task Design: Why a “10-Page E-Commerce Frontend”?

When evaluating AI coding tools, low task complexity masks issues, while high complexity makes root cause analysis difficult. We chose “building an e-commerce frontend from scratch” as the benchmark task. The tech stack is restricted to React, covering ten pages:

Page Category	Specific Pages
Product Browsing	Home (Product List), Product Detail
Transaction Flow	Purchase Page, Purchase Success Page
Account System	Login, Register
User Center	Dashboard, Orders, Wallet (Coupons), Settings

The core challenge is not implementing individual pages, but site completeness and overall consistency. The ten pages must share a routing structure, state management, styling system, and mock data. Any missing link results in a project that “looks runnable but isn’t.” This is exactly the key scenario for testing an agent’s planning capabilities.

3. Evaluation of Four Technical Approaches

3.1 Approach A: Conversational Craft Mode (Usability-First)

The first approach uses a conversational task orchestration mode. The tool autonomously plans the file structure and generation sequence based solely on the user’s goal description. In testing, this approach generated all ten pages in a single pass. The service responded smoothly with no noticeable blocking.

Deliverable Evaluation:

• Completeness: The main shopping flow is closed-loop and usable. Forms have basic validation logic, and route navigation is correct.
• Visual Consistency: The color scheme is unified and restrained. The UI leans towards mobile layout but includes basic responsive adaptation.
• Obvious Defects: Layout distortion occurs on login and registration pages under narrow screens; all image assets are placeholders; the product detail page is sparse, showing only name and price.
• Code Quality: Styles and logic are separated, and readability is acceptable. However, the project architecture is flat, and mock data is directly coupled with business code, lacking an independent data layer and type definitions.

This approach suits teams aiming for a “runnable prototype first, iterate later” workflow. Its value lies in minimizing time-to-prototype, at the cost of requiring refactoring later.

3.2 Approach B: Builder Mode Inheriting Editor Interactions (Comprehensive but Unstable)

The second approach follows the interaction habits of mainstream AI editors, offering engineering options like privacy mode, and executes tasks step-by-step in a Builder style.

In testing, the first generated project could not run directly due to errors, requiring multiple rounds of fixes. Its advantage lies in detail coverage: form validation rules are complete, and the information density on the product detail page is significantly higher than Approach A. However, the issues are equally prominent:

• No mobile adaptation; layout overflows on narrow screens.
• Some buttons have the same foreground and background colors, rendering text invisible—a typical issue of unmanaged style variables.
• The color scheme lacks overall design constraints, leading to inconsistent visuals.
• Image assets remain placeholders.

At the code level, styles are separated but not split into independent files. Structure reserves spots for state management and context, but the directories are actually empty. This indicates the tool possesses “architectural awareness” but fails to implement it. This “placeholder architecture” becomes hidden technical debt.

Another notable issue is generation speed: the task took a long time. Under free tiers, time costs directly impact development pace.

3.3 Approach C: Multi-Agent Mode (Shifting Selection Costs to Users)

The third approach provides multiple Agent modes for different scenarios. The problem is that the capability boundaries between modes are unclear, forcing users to decide which one to use.

Two typical modes were tested:

• Fast Generation Mode: Quick output, but the project structure had severe issues—it created a duplicate nested directory within the project root, causing dependency resolution failure. The project couldn’t start. Such hard errors in engineering standards are costly to debug.
• Complex Task Mode: Claimed to handle complex engineering, but response was slow. The generated project started but threw many runtime errors. Multiple rounds of fixes failed to converge, leading to abandonment.

Common issue exposed: Without a clear task routing strategy and quality gates in a multi-agent architecture, the user essentially acts as the “selector.” The time cost of choosing incorrectly often outweighs the benefits.

3.4 Approach D: Declarative Configuration-Driven (Stability-First)

The fourth approach drives the generation process via configuration files, emphasizing engineering standard constraints. Performance was average: standard project structure, clear dependency management, but weaker page detail richness than Approach B, and slower generation than Approach A. Its value lies in predictability—high structural stability of the output, suitable for teams with strict engineering requirements.

4. Horizontal Comparison: Abstracting Evaluation Dimensions

We condensed the observations into five quantifiable evaluation dimensions for team selection:

1. First-Pass Success Rate
The ratio of projects that run without manual intervention after the first generation. This directly determines efficiency in the “zero-to-one” phase. Only Approach A achieved a usable state; others required multiple fixes.

2. Architectural Rationality
Check three things: Is the directory structure excessively flat? Is the data layer independent? Is state management actually implemented rather than just empty directories? Approach B’s “empty directory architecture” is a typical anti-pattern.

3. Styling System Consistency
Quick checks: “Are there buttons with identical foreground and background colors?” “Is there narrow-screen overflow?” The root cause is centralized management of style variables.

4. Responsive Adaptation Completeness
If any of the ten pages distorts on narrow screens, it fails. E-commerce has high mobile traffic; this metric should be weighted heavily.

5. Resource and Data Replaceability
Are placeholder images and hardcoded mock data centralized in a single config file? Scattered coupling means massive changes when integrating real APIs.

5. Engineering Completion: Mandatory Steps Regardless of Tool Choice

Testing repeatedly validated one conclusion: Current AI coding tools deliver “high-quality drafts” rather than “production-ready code.” Therefore, teams must establish a standardized completion process alongside tool selection.

5.1 Establish Data Layer Isolation

Extract mock data from business components, consolidate it into an independent module, and define clear type contracts. Example structure:

// src/mock/products.ts
export interface Product {
  id: string;
  name: string;
  price: number;
  cover: string;      // Unified placeholder resource entry
  description: string;
}
export const products: Product[] = [ /* ... */ ];

All pages read through unified data access functions. Replacing this with real APIs later requires changes only to this layer.

5.2 Centralized Style Variable Management

Define primary colors, text colors, background colors, and spacing as design tokens. Hardcoding color values in components is prohibited. The aforementioned “white-on-white” issue stems from a lack of token constraints:

:root {
  --color-primary: #1a56db;
  --color-on-primary: #ffffff;   /* Foreground color must be defined as a pair with primary */
  --space-md: 16px;
}

5.3 Responsive Baseline Check

Set unified breakpoints for the ten pages, covering at least 375px and 768px widths. Add “page-by-page narrow-screen walkthrough” to the acceptance checklist. Form pages (login, register) are high-risk areas and should be checked first.

5.4 Shift Quality Gates Left

Make “can the project start in one go,” “are there empty directories,” and “are there hardcoded colors” mandatory checks in code reviews. These low-cost checks intercept most issues observed during testing.

6. Selection Advice: Matching Capabilities to Team Phases

Different teams have varying needs for AI coding tools. Match them according to project phases:

• Validation Phase (Prototypes, Demos, Internal Presentations): Prioritize conversational approaches with high first-pass success rates and fast responses. The goal is a clickable, complete flow quickly, tolerating rough details.
• Construction Phase (Formal Product Development): Prioritize approaches with good architectural standards and predictable outputs, supplemented by the aforementioned engineering completion process. Down-weight “generation speed” and up-weight “structural rationality.”
• Multi-Person Collaboration: Additionally evaluate the style consistency of the generated code to avoid merging costs caused by disparate module structures from different team members.

It must be emphasized that when selecting multi-agent solutions, require vendors to clarify the capability boundaries and applicable scenarios of each mode. Otherwise, selection costs will continuously transfer to frontline developers.

7. Conclusion

The core conclusion of this test can be summarized: Available AI programming tools are capable of completing medium-complexity full-stack tasks, but a significant gap remains between “usable” and “maintainable” deliverables. Tool differences mainly manifest in task planning capability, implementation of architectural awareness, and styling system rigor. These differences can be bridged through standardized processes.

For developers, the rational approach is not to seek the “strongest tool,” but to establish a stable set of evaluation dimensions and completion standards—tools will iterate, but methodology is a long-term asset. For platforms providing AI programming capabilities, future competition will shift from “generation speed” to “engineering standardization of generated results.” This is precisely a direction where platforms like Baidu AI Cloud, with long-term accumulation in cloud-native and engineering practices, can leverage their strengths.