Evaluating AI Coding Tools: Engineering a Full-Stack E-commerce Site from Scratch

Background: When AI IDEs Become the Default Development Environment

Over the past two years, AI coding tools have rapidly evolved from simple code completion plugins into task-level development agents. Developers only need to describe their goals in natural language, and the tool autonomously handles requirement decomposition, file creation, dependency installation, page rendering, and even local debugging. The core value of these tools lies not in “writing a few lines of code,” but in compressing the pipeline from “requirements to runnable artifacts” down to minutes.

However, in real-world enterprise and individual development scenarios, selection constraints are often more complex than feature lists: network accessibility, model compliance, data privacy, maintainability of generated artifacts, and the ability to maintain overall project consistency across long tasks. This article uses “building a complete e-commerce front-end site” as a unified task to discuss how to evaluate such tools and provides engineering methods to improve the first-pass success rate.

Task Design: Why an “E-commerce Site”

An e-commerce site is a typical “medium complexity, high consistency” task. It involves multiple page routes and requires cross-page state sharing, form validation, visual uniformity, and responsive adaptation. Evaluating tools with a single-page task easily masks architectural flaws, while using an overly massive system introduces too much noise unrelated to the tool’s capabilities.

The unified task is defined as follows:

• Tech Stack: React (Functional Components + Routing)
• Number of Pages: 10
  • Home Page (Product List)
  • Product Detail Page
  • Product Purchase Page
  • Purchase Success Page
  • User Login Page
  • User Registration Page
  • User Dashboard
  • User Orders Page
  • User Wallet (Coupons/Vouchers)
  • User Settings
• Implicit Requirements: Consistent global navigation, cross-page state flow, basic form validation, mobile responsiveness, separation of styles and logic, and decoupling of data layer from views.

The difficulty lies not in implementing a single page, but in the completeness and overall consistency of the site. This is exactly the key watershed that distinguishes “generating code” from “delivering a project.”

Six Dimensions for Tool Evaluation

Without relying on external networks, AI coding tools can be structurally evaluated across the following dimensions:

1. Interaction and Task Orchestration: Does it support issuing multi-step tasks at once (similar to Agent/Craft modes), or does it force step-by-step confirmation? One-time orchestration is friendlier for “full-site generation” but requires strong context management capabilities.
2. Generation Speed and Stability: Does the long task lag, lose context midway, and can it resume after a failure?
3. Artifact Structural Rationality: Is the directory layering clear (components, pages, state, services, styles), and are there structural errors like nested directories with the same name?
4. Visual and Responsive Quality: Is mobile-first adopted by default, are breakpoints reasonable, and is the contrast ratio of buttons and text up to standard (white text on a white background is a classic accident)?
5. Data and State Decoupling: Is mock data coupled in the view code, and are placeholders reserved for the service layer and hooks/context?
6. Repairability: Can it locate the root cause after an error, and does the fix introduce new issues?

It should be noted that these tools generally share the characteristic of “usable on the first pass but lacking polished details.” Therefore, the focus of evaluation should be on the “rework cost” rather than the “first impression.”

Observations: Four Typical Behavior Patterns

Under the unified task, different tools exhibited four classifiable behavior patterns (described here by capability characteristics, not pointing to specific products):

Type A: One-Pass Success, Simple Structure
The complete shopping flow runs on the first pass, with basic form validation and separated styles and scripts. However, visually it leans mobile, login/registration pages deform on narrow screens, product images use placeholders, detail pages lack information density, and mock data is written directly inside components. Conclusion: Suitable for rapid validation, but requires supplementing the data layer and design specifications.

Type B: Feature-Rich, Multiple Issues
Form validation is complete, and detail pages are richer in information, but the first-pass artifact throws runtime errors requiring multiple rounds of fixes; mobile responsiveness is missing, button color contrast is insufficient making text invisible, and the color scheme lacks a unified design language. At the code level, styles are separated but not in independent files; placeholders for hooks and context exist in the directory but are empty implementations—this is “scaffolding-style reservation,” helpful for future expansion but not a substitute for real state management. Conclusion: Significant later modification workload, suitable for teams with refactoring capabilities.

Type C: Multi-Mode Coexistence, High Structural Risk
Provides multiple Agent modes. The fast mode generates rapidly but the project structure is chaotic, with nested directories of the same name ultimately causing the project to fail to start; the complex task mode responds slowly, the artifact runs but has many errors, and multiple rounds of fixes fail. Conclusion: Structural issues are harder to fix than syntax errors; directory trees should be prioritized for validation after generation.

Type D: Steady but Slow
Generation speed is slow, but the artifact structure is relatively regular. These tools are suitable for scenarios sensitive to quality but insensitive to time.

Overall, “fast generation” and “structural stability” are often mutually exclusive. Selection should be weighed against the team’s refactoring capabilities.

Prompt Engineering to Improve First-Pass Success

Overly brief original task descriptions are the main cause of uneven artifact quality. It is recommended to structure the prompt as a “constraint checklist”:

Goal: Build an e-commerce front-end site using React, 10 pages in total (list the page manifest).
Architectural Constraints:
- Directory layering: pages/ components/ hooks/ context/ services/ styles/
- State management uses Context + useReducer, hardcoding product data inside components is prohibited
- Mock data is placed uniformly in services/mock.js, exposed via async functions
- Styles use independent CSS Module files, inline styles are prohibited
Visual Constraints:
- Mobile-first, breakpoints at 768px / 1024px
- Unified primary color, button text and background contrast complies with WCAG AA
- Images use a unified placeholder component, reserving src replacement slots
Quality Constraints:
- All forms include required and format validation
- Route guards: User center pages require a logged-in state
Acceptance: Output the directory tree and page route table after generation

The value of structured prompts lies in making “implicit requirements” explicit, forcing the tool to adhere to architectural constraints during the generation phase, thereby reducing rework costs at the source.

Post-Generation Acceptance and Refactoring Checklist

Regardless of the tool used, the artifact must undergo standardized acceptance:

1. Directory Tree Validation: Check for nested directories with the same name and empty implementation files.
2. Route Completeness: Access all 10 pages one by one to confirm no white screens or 404s.
3. Responsive Check: Check layout and text visibility at three widths: 375px / 768px / 1440px.
4. State Flow: Walk through List -> Detail -> Purchase -> Success page to confirm correct data passing.
5. Data Decoupling: Migrate hardcoded data within components to the service layer, replacing them with async calls.
6. Style Extraction: Migrate inline styles to independent style files and unify design variables.
7. Login State and Guards: Complete access control for the user center.

Conclusion

AI coding tools can now handle the “0 to 1” skeleton construction, but “1 to usable” still relies on the developer’s architectural judgment and acceptance capabilities. When selecting a tool, do not obsess over first-pass impressions; instead, focus on the rationality of the artifact’s structure, the degree of decoupling between data and views, and repairability after failure. Structuring prompts and checklisting acceptance are the only ways to enjoy generation efficiency while safeguarding the baseline of engineering quality.