AI Coding Assistant Selection in Practice: Building an E-Commerce Site from Scratch

1. Background: From “Code Completion” to “Application Delivery,” the Selection Logic Has Changed

In 2026, the AI coding assistant market shows two clear trends. First, the capability boundary has expanded from line-level completion and function generation to a complete delivery pipeline: understand the requirement, plan tasks, generate an entire application, and self-repair. Second, accessibility has improved dramatically—major vendors now offer intelligent coding environments that require no extra configuration and work right after sign-up, significantly lowering the entry barrier for individual developers and small teams.

Yet there is often a gap between capability claims and real delivery. The “generate a website with a single sentence” shown in demo videos can turn into a half-finished product full of errors when applied to your own requirements. Therefore, the core of tool selection is not collecting opinions, but designing a reproducible testing method: use a unified task and unified standards to measure how good different tools really are.

2. Why an E-Commerce Site as the Benchmark Task

To evaluate an AI coding assistant, the task design must meet three conditions: broad coverage, moderate complexity, and objective acceptance criteria. Building an e-commerce site from scratch satisfies all three:

1. Complete page coverage. The product detail page, purchase page, and purchase success page form the core transaction flow. Login and registration pages cover forms and authentication. The user center—Dashboard, orders, wallet (coupon pack), and settings—covers list rendering, state management, multi-tab layouts, and other typical scenarios.
2. Dense technical elements. Form validation, component reuse, routing and navigation, mobile responsiveness, and mock data management bring together nearly all the high-frequency pain points of frontend engineering in a single task.
3. Clear acceptance boundaries. Whether each page opens, whether validation works, and whether the layout breaks are all objectively checkable yes/no questions, keeping subjective aesthetics out of the conclusion.

Compared with a single-page demo, a site-level task exposes a tool’s weaknesses in task decomposition, context management, and cross-file consistency. Compared with a real production system, it can be completed within a single session, keeping experiment costs manageable.

3. A Five-Dimension Evaluation Framework

3.1 Interaction Experience and Task Execution Modes

Today’s AI-powered IDEs generally offer two task execution modes:

• Autonomous execution mode: the AI decomposes the requirement on its own, continuously generates and applies changes, and aims to deliver a complete result in one pass.
• Step-by-step collaboration mode: the AI first presents a plan or a localized change, and the developer confirms each step and corrects course at any time.

Each mode has its place. CRUD-style pages with clear goals suit the autonomous mode; architectural decisions and complex business logic benefit from the controllability of step-by-step mode. When evaluating tools, focus on three points:

1. Task decomposition quality: given a “10 pages” requirement, does the tool advance in sensible batches, or dump everything at once and then fail across the board?
2. Context continuation: after a session interruption or a file switch, can it accurately pick up previous progress?
3. Privacy and security design: does it offer a privacy mode, and can sensitive directories be excluded from the model’s context?

Interaction friendliness is worth recording too: whether the operation path is straightforward, whether the generation process is observable, and whether error messages are human-readable. Over long pairing sessions, a tool’s “feel” directly affects cognitive load—part of the reason anthropomorphic assistants and guided interfaces have become popular in recent years.

3.2 One-Shot Generation Quality

Take “all 10 pages run in one pass” as the acceptance line and record each item:

• Runnability: whether the first generation starts directly, and the number and severity of errors;
• Completeness: any missing pages or broken flows (e.g., broken navigation after a successful purchase);
• Detail completeness: whether required, format, and length validation all work, and whether empty and error states are handled;
• Responsiveness: whether the layout stays usable from 375px to 1440px wide.

Failure patterns that show up repeatedly in testing include: all-placeholder images that leave the detail page with too little information density; white text on white buttons (contrast failure); layouts fitted to a single breakpoint that break as soon as it changes; and deformed elements on narrow pages like login and registration. These problems are not necessarily fatal, but they directly determine how far the generated result is from being usable—and they are an important basis for quantitative scoring.

3.3 Code Quality and Engineering

A result that runs is only the pass line; maintainability is the long-term value. Core checks:

1. Style/logic separation: separate style files beat inline styles, making theming and reuse easier;
2. Directory structure sanity: no “same-named folder nested inside a same-named folder” chaos;
3. Reserved extension points: hooks, context, and similar slots exist and are not empty shells;
4. Data decoupling: mock data is consolidated in an independent service layer and can be swapped for a real backend in one move.

A healthy project structure looks roughly like this:

src/
├── pages/        # Routed pages: detail / login / orders ...
├── components/   # Reusable components: Button / Card / FormItem
├── hooks/        # Custom state logic (not empty shells)
├── context/      # Global state: user info, coupon data
├── services/     # Service layer; all mock data consolidated here
└── styles/       # Global styles and design variables

The anti-pattern looks like this:

src/pages/order/order/order.jsx   // Same-named directory nesting, confusing paths
// Mock arrays hardcoded inside components; wiring a real API requires file-by-file surgery

Structural chaos and data coupling are the biggest sources of future iteration cost, and they should be weighted more heavily than surface-level UI aesthetics.

3.4 Performance and Stability

• Generation speed: how long from submitting the requirement to a full page being produced, and whether it degrades over long sessions;
• Service stability: queuing, rate limiting, and timeouts, and how the service behaves at peak hours;
• Pace matching: if it is slow enough to make you “want to pay for faster generation,” its efficiency already conflicts with your development rhythm.

Speed is not just an experience issue; it shapes workflow design. A tool that generates too slowly forces developers to give up conversational iteration and fall back to hand-writing, and the leverage AI provides drops to zero.

3.5 Iteration and Fix Cost

One-shot generation always ships with defects, so the real watershed is how efficient fixes are:

• Defect localization: can the AI locate the root cause from an error message on its own, or does it blindly rewrite?
• Fix side effects: does it play whack-a-mole—fix one thing, break two others?
• Abandonment cost: after several consecutive failed fix rounds, how much rewriting does taking over manually require?

Record the number of fix rounds for each defect and use the average as a “fix cost index.” In practice, some tools converge within two rounds, while others are still going in circles after five. This metric often discriminates better than first impressions.

4. A Reusable Testing Methodology

4.1 Benchmark Prompt Template

Build an e-commerce site from scratch, including:
1. Product detail page, purchase page, and purchase success page;
2. Login and registration pages (with required, format, and length validation);
3. User center: Dashboard, orders page, wallet (coupon pack), and settings page.
Hard requirements:
- Mobile-first, with responsive desktop support;
- All images go through a unified placeholder component; field structures align with a real API;
- All mock data is consolidated in services/mock; never inline it into components;
- Separate styles from logic and reserve hooks/context extension points.

Front-loading architectural constraints into the prompt significantly raises the floor of what gets generated. At the same time, how well a tool follows those constraints is itself a test of its instruction-following capability.

4.2 Acceptance Checklist (Excerpt)

Check item	Pass criteria
First run	Starts without modifying any code
Form validation	Required/format/length rules all work
Responsiveness	No layout breakage from 375px to 1440px
Readability	No contrast failures such as white text on white
Engineering structure	No same-named nested directories; mock data consolidated
Fix cost	No more than 2 fix rounds per defect on average

4.3 Scoring and Decision Method

Assign weights to the five dimensions (adjust for your team): one-shot generation quality 30%, code engineering 25%, iteration fix cost 20%, interaction and modes 15%, performance and stability 10%. Score each dimension from 1 to 5, compute a weighted sum, and then apply qualitative adjustments for your scenario:

• Prototype validation: prioritize one-shot generation quality and speed—fast trial and error matters more than polish;
• Long-term iterative projects: prioritize code engineering and fix cost, and avoid the “fun to generate, painful to refactor” trap;
• Data-sensitive scenarios: prioritize privacy mode and private deployment capability. These teams can also look at cloud vendors’ developer toolchains—for example, general capabilities such as intelligent coding assistants and cloud development environments offered by platforms like Baidu AI Cloud—and verify them with the same framework through hands-on testing rather than taking marketing claims at face value.

5. Five General Lessons from Hands-On Testing

1. Front-load constraints: putting architecture requirements into the prompt is an order of magnitude cheaper than refactoring afterwards;
2. Accept in small steps: manually review each page as soon as it is generated, before errors accumulate across pages;
3. Layer your data: keep mock data decoupled from components so the real backend has a clean replacement point;
4. Beware the “it runs” illusion: running is not the same as usable—contrast, responsiveness, and validation must be verified manually;
5. Record fix rounds: they are the sharpest mirror of a tool’s real delivery capability—more convincing than any demo video.

6. Conclusion

There is no single right answer when choosing an AI coding assistant, but there is a reproducible method. With a site-level benchmark task, a five-dimension evaluation framework, and a quantifiable acceptance checklist, developers can see a tool’s true capability within a few hours instead of being led around by marketing. Tools will keep iterating and mode names will keep changing, but the evaluation philosophy—start from the deliverable and verify capability through delivery—will remain effective in 2026 and well beyond.