AI Coding Tools in Practice: Building a Complete E-Commerce Project

1. Background: From “Writing Code” to “Delivering a Project”

Over the past two years, AI coding tools have evolved rapidly from completing a single line to generating an entire project from a one-sentence prompt. For developers, the real question is no longer whether these tools can write code, but whether they can deliver a complete project that is runnable, well-structured, and ready for further development.

This article uses a realistic scenario to evaluate the current engineering maturity of mainstream AI coding tools: building an e-commerce site with 10 pages from scratch. To avoid focusing on any specific product’s marketing claims, the tools tested are referred to as “AI coding tool A/B/C/D.” The goal is to analyze the common technical issues they expose and the reusable evaluation methods developers can apply.

2. Task Definition: What a “Minimum Viable E-Commerce Site” Should Include

The test task was defined as follows:

• Tech stack: React frontend

• Page scope (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 vouchers)
  10. User center - Settings

• Core prompt: Use React to build a frontend shopping site with the above 10 pages.

Although this task appears simple, it actually tests several critical capability dimensions of AI coding tools:

Dimension	What Was Evaluated
Completeness	Whether all 10 pages were generated and routes were connected
Consistency	Whether global colors, component reuse, and state management were unified
Usability	Whether the project compiled and ran, and whether form validation worked
Engineering quality	Directory structure, separation of styles and logic, data layer abstraction
Responsiveness	Whether mobile and desktop layouts were reasonable
Maintainability	Whether there was redundant nesting, empty directories, or tightly coupled data

3. Test Observations: Analysis of Four Typical Tool Behaviors

3.1 Tool A: Friendly Interaction, Complete Generation, but Overly Simple Architecture

This tool used a conversational generation mode and completed all pages in one pass. The service response was fast with no noticeable lag. Key characteristics of the generated result:

• Strengths: Visually consistent UI, a complete shopping flow, basic form validation, and initial separation of styles from logic.
• Problems:
  • The overall layout leaned toward mobile, with poor desktop adaptation. The login and registration pages were visibly distorted on wide screens.
  • All image resources used placeholders, and the product detail page had very low information density.
  • Mock data was directly coupled inside component code rather than abstracted into a separate data layer.
  • The project architecture was overly flat, lacking layers such as services, hooks, and context.

Technical assessment: This type of output is suitable for prototyping, but it falls short of being deliverable. The core issue is the lack of architecture constraints in the prompt. If the prompt explicitly required “separating the data layer from the view layer,” “using React Router for route management,” and “using CSS Modules for styling,” the output quality would improve significantly.

3.2 Tool B: Inherits Mainstream Interaction Patterns, but Lacks Stability

This tool adopted interaction patterns similar to popular AI IDEs and offered two generation modes. Test results:

• The first generation was runnable but produced errors, requiring multiple rounds of fixes before the full result could be reviewed.
• Strengths: Form validation was fairly complete, and the product detail page contained richer information than Tool A. The code reserved directory locations for hooks and context.
• Problems:
  • The reserved directories were empty, representing “placeholder architecture” without actual state management implementation.
  • The mobile layout was not responsive. Some buttons appeared as white text on a white background, making them invisible.
  • The color scheme lacked unified design tokens, resulting in poor visual consistency.
  • Generation speed was slow, which affected iteration efficiency.

Technical assessment: “Reserved empty directories” is a warning sign worth paying attention to. It indicates that the model has learned the surface form of project structure without understanding its purpose. When evaluating, developers should specifically check whether the context directory contains actual Provider implementations and whether hooks contains custom hooks that are actually referenced by components.

3.3 Tool C: Multi-Agent Mode Creates Decision Paralysis

This tool offered multiple generation modes targeting “fast generation” and “complex task handling.” In testing:

• Fast mode: Generated quickly, but the directory structure was chaotic, including “nested folders with the same name inside a folder,” which ultimately prevented the project from starting.
• Complex task mode: Service response was slow. The generated project was runnable but produced many errors. After multiple failed repair attempts, the test was abandoned.

Technical assessment: Multi-agent mode essentially separates planning from execution, which should theoretically be better suited to complex tasks. However, testing revealed a common problem: agents lack a shared understanding of project state, leading to basic issues such as incorrect path concatenation and dependency version conflicts. When evaluating such tools, checking whether the generated directory tree is reasonable should be a priority, as it often reflects tool maturity better than the code itself.

3.4 Tool D: Response Speed and Structural Problems Coexist

This tool performed acceptably in terms of response speed, but the generated output exhibited common issues similar to the other tools: non-standard project structure and a need for substantial post-generation modification.

4. Common Problems: Five Pitfalls of AI-Generated E-Commerce Projects

Based on the tests above, the following common problems can be identified when current AI coding tools generate complete projects:

Pitfall 1: Flattened Architecture

Most tools tend to place all components flatly under src/components, lacking feature-based directory organization. It is recommended to explicitly specify in the prompt:

Organize directories by feature domain:
src/
  features/
    product/
    cart/
    user/
  shared/
    components/
    hooks/
    utils/
  services/
  routes/

Pitfall 2: Missing Data Layer

Mock data is written directly inside components, causing a large blast radius when integrating real APIs later. The correct approach is to abstract a services layer:

// services/productService.js
const BASE_URL = import.meta.env.VITE_API_BASE;
export async function fetchProducts(params) {
  const res = await fetch(`${BASE_URL}/products?${new URLSearchParams(params)}`);
  if (!res.ok) throw new Error('Failed to fetch products');
  return res.json();
}

Pitfall 3: Styles Disconnected from Design Tokens

Colors, spacing, and border radii are hardcoded in components, leading to visual inconsistency. Design tokens should be introduced:

:root {
  --color-primary: #1677ff;
  --color-text: #1f1f1f;
  --color-bg: #ffffff;
  --radius-md: 8px;
  --space-md: 16px;
}

Pitfall 4: Crude Responsive Handling

Most tools generate mobile-first layouts by default and simply stretch them for desktop. Breakpoint requirements should be explicitly stated in the prompt:

Implement responsive layouts with breakpoints at 768px and 1200px.
Use a 4-column grid for the product list on desktop and a 1-column layout on mobile.

Pitfall 5: Superficial Form Validation

Some tools generate validation that only checks for non-empty fields, lacking format validation, error messaging, and submission state management. Use a proven form validation approach:

const schema = z.object({
  email: z.string().email('Please enter a valid email'),
  password: z.string().min(8, 'Password must be at least 8 characters'),
});

5. Reusable Strategies for Improving Generation Quality

5.1 Constrain Generation with an “Architecture Contract”

The prompt should describe not only functionality but also structure. For example:

Implement with React + React Router + Context. Requirements:

1. Organize directories by features.
2. Centralize all API calls in the services layer.
3. Manage global state with Context, placed in shared/context.
4. Use CSS Modules for styling, with colors referencing CSS variables.
5. Each page must include loading, empty, and error states.

5.2 Generate in Stages Rather Than All at Once

When generating 10 pages in a single pass, models tend to lose focus. A more reliable approach is:

1. Stage 1: Generate only the project skeleton, routing, and layout components.
2. Stage 2: Generate each page individually in separate conversations.
3. Stage 3: Integrate the data layer and state management across pages.
4. Stage 4: Consolidate responsive behavior and visual consistency.

5.3 Establish an Automated Acceptance Checklist

Before visually inspecting the generated output, run automated checks first:

npm run build      # Does it compile?
npm run lint       # Are there obvious standards violations?
npm test           # Is there test coverage for key flows?

Then manually verify:

• Whether the directory tree matches expectations.
• Whether there are empty directories or placeholder files.
• Whether all routes are reachable.
• Whether both mobile and desktop layouts are usable.

6. Conclusion: Tools Are Levers, Constraints Are the Fulcrum

AI coding tools can indeed compress the “0 to 1” timeline from days to hours, but testing shows that output quality depends heavily on the architecture constraints embedded in the prompt. Without constraints, even the strongest models will only produce runnable demos. With constraints, they can produce maintainable projects.

For developers, the most practical approach at this stage is to treat AI coding tools as efficient code generators rather than architecture decision-makers. Architecture, standards, and acceptance criteria still need to be defined by humans—and that is precisely where the irreplaceable value of experienced developers lies.