Comparing Two Generated Versions of the Same Front-End Requirement: How Much Do Design Constraints Matter?

## 1. Background: Why One Requirement Produces Different Results

Once AI coding tools enter the front-end workflow, a familiar pattern appears: a single requirement can generate multiple versions almost instantly. On the surface they all cover the basic functionality, but the differences surface quickly when the code has to be integrated into a real project.

Take a request for an “image segmentation demo page.” One generated version simply piles upload, preview, buttons, and export elements together. Another version accounts for component boundaries, style variables, state management, accessibility, responsive layout, and downstream maintenance cost. The decisive factor is usually not whether the model “knows how to write code,” but whether the context supplies clear enough design constraints.

A design constraints context is a form of explicit specification input: design tokens, component rules, naming conventions, layout constraints, accessibility requirements, interaction state definitions, performance budgets, and so on. It converts the experience that designers, front-end engineers, and reviewers accumulate over time into structured prompts a machine can act on.

This article therefore takes the approach of generating two versions of the same front-end code and comparing the difference with and without a design constraints context, then offers a reusable experimental method. The point is not to rank one tool’s absolute capability, but to discuss a general engineering practice: using specification context to improve the consistency and maintainability of AI coding output.

2. Experimental Design: Keeping the Comparison Fair

A comparison is only meaningful if variables are controlled. Otherwise, differences between the two versions may come from an unclear requirement description, random generation, a different runtime environment, or inconsistent evaluation criteria — rather than from the design constraints themselves.

2.1 Fix the Requirement

The experiment uses one front-end requirement: build an image segmentation demo page that supports uploading a local image, previewing it, drawing a segmentation region on the image, adjusting basic parameters, and exporting the result.

The requirement description is kept as neutral as possible, without technical implementation preferences:

Build an image segmentation demo page with the following capabilities:
1. The user can select and preview a local image.
2. The page provides the ability to draw a segmentation region.
3. The user can adjust segmentation parameters.
4. An export button outputs the processing result.
5. The page must account for empty, error, and loading states.
6. The interface should be reasonably usable and suitable for desktop access.

2.2 Set Up Two Versions

• Baseline: requirement only, with no additional design specifications.
• Enhanced: the requirement plus a design constraints context.

Both versions receive the same requirement text, the same output target, and the same page scope, so no extra variables are introduced.

2.3 Unify the Evaluation Dimensions

To judge whether design constraints genuinely add value, an evaluation checklist is needed instead of a gut feeling about “which one looks better.” Candidate dimensions include:

1. Completeness of requirement coverage;
2. Semantic quality of the page structure;
3. Style consistency and reusability;
4. Clarity of component boundaries;
5. Completeness of state management;
6. Stability of the responsive layout;
7. Baseline accessibility quality;
8. Code readability and maintainability;
9. Cost of future extension;
10. Cost of adapting the output for a real project.

3. Set Up a Clean Working Directory

Before the comparison starts, it helps to create a well-structured local directory with no cross-contamination between the two versions, the specification documents, and the evaluation notes. This makes item-by-item comparison easy and gives the team something to review afterwards.

A recommended structure:

frontend-compare/
  baseline/
  enhanced/
  docs/
    design-rules.md
    acceptance.md

Where:

• baseline holds the version generated without design constraints;
• enhanced holds the version generated with design constraints;
• docs/design-rules.md records the design specifications used as input;
• docs/acceptance.md records the acceptance criteria and comparison conclusions.

The value of this organization is that “code generation” becomes a repeatable, reviewable engineering experiment rather than a one-off chat result.

4. What a Design Constraints Context Should Contain

A design constraints context is not better for being longer. Too many, too granular, or mutually conflicting rules can actually reduce generation stability and even make the output rigid. A more sensible approach is layered, structured, executable constraints.

4.1 Design Tokens

Design tokens unify the basic visual variables — colors, typography, spacing, radii, shadows — and keep generated code from scattering hard-coded values.

For example:

:root {
  --color-text: #1f2329;
  --color-text-secondary: #646a73;
  --color-surface: #ffffff;
  --color-border: #d9dce0;
  --color-primary: #2f6fed;
  --color-primary-hover: #1f5fd6;
  --color-danger: #d93026;
  --font-size-sm: 12px;
  --font-size-md: 14px;
  --font-size-lg: 16px;
  --space-1: 4px;
  --space-2: 8px;
  --space-3: 12px;
  --space-4: 16px;
  --space-6: 24px;
  --radius-sm: 4px;
  --radius-md: 8px;
  --radius-lg: 12px;
}

Without these tokens, generated code is likely to contain scattered literals such as #fff, #333, margin: 10px, and padding: 7px, which are hard to maintain consistently later.

4.2 Layout Constraints

Layout constraints define the page container, grid, spacing, and breakpoints. For example:

The main page content has a maximum width of 1200px.
The horizontal safe margins are at least 16px.
Primary sections are separated by 16px or 24px of spacing.
On narrow screens the toolbar may wrap, and the preview area height adapts to the viewport.

Such constraints reduce the common problem of a layout that looks fine on a desktop monitor but breaks down once the window is resized.

4.3 Component Specifications

Component specifications define the visual and behavioral boundaries of common elements such as buttons, inputs, cards, dialogs, and toolbars.

For example:

Buttons come in primary, secondary, and danger variants.
Every button must have default, hover, disabled, and loading states.
Every input must have a label, placeholder text, and an error message slot.
All interactive elements must show a visible focus indicator on keyboard focus.

Rules like these move generated code from “clickable” to “usable.”

4.4 Accessibility Requirements

Accessibility is an important quality indicator for front-end engineering. Without explicit constraints, AI coding tends to focus on visual presentation and overlook semantics and keyboard operation.

You can require:

Page structure uses semantic tags.
Images have alternative text.
Form controls have labels.
Dynamic state changes are announced through appropriate accessibility attributes.
Interactive elements support keyboard operation.

4.5 Performance and Resource Constraints

Performance constraints do not have to be elaborate, but they should give a clear direction. For example:

Preview images should be displayed via object URLs rather than reading large files immediately.
Export actions should show a loading state so users cannot click repeatedly.
Processing large images must not block the main thread for long.
Unnecessary layout reflows should be avoided where possible.

Constraints like these help generated code move from “works as a demo” to “usable in production engineering.”

5. How the Two Prompts Differ

5.1 Baseline Prompt

The baseline prompt only describes the requirement:

Build an image segmentation demo page with image upload, image preview, segmentation region drawing, parameter adjustment, and result export. The page should be as complete as possible.

This kind of prompt is flexible and generates fast, but it offers no engineering decision criteria. The model may freely choose structure, styling, state handling, and naming, which makes the result less stable.

5.2 Enhanced Prompt

The enhanced prompt appends design specifications to the requirement:

Implement this under the following constraints:
1. Use design tokens for colors, spacing, font sizes, and radii.
2. Avoid extensive inline styles; keep styles centrally managed.
3. Use semantic tags for page structure.
4. Buttons must include default, hover, and disabled states.
5. The file input needs a label and an error message.
6. The preview area needs empty and loading states.
7. The toolbar may wrap on narrow screens.
8. All interactive elements need a visible focus indicator.
9. Split structure, styles, and interaction logic into separate files.
10. Do not introduce additional external resources.

The enhanced prompt is not merely longer. It makes the implicit definition of “what good front-end code is” explicit.

6. Code Comparison: From Functional to Maintainable

To see the difference more concretely, compare a partial page from each version.

6.1 Typical Baseline Output

The baseline version may generate something like the following:

<div style="padding: 16px; background: #ffffff;">
  <input id="file" type="file" style="margin-bottom: 8px;" />
  <div
    id="preview"
    style="width: 600px; height: 400px; border: 1px solid #dddddd;"
  ></div>
  <button onclick="exportImage()" style="padding: 8px 16px;">
    导出
  </button>
</div>

This runs quickly, but it has clear problems:

1. Style values are hard-coded, making consistent adjustment difficult;
2. Loading, error, and empty states are missing;
3. The file input has no clear label;
4. The preview area has a fixed width and height, which is awkward for responsive layouts;
5. The button has no disabled or hover states;
6. Structure and styles are coupled, raising maintenance cost.

6.2 More Reasonable Output Under Design Constraints

With design constraints in place, the result is likely to look closer to this:

<section class="workspace" aria-label="Image segmentation workspace">
  <h1 class="workspace__title">Image Segmentation Demo</h1>
  <div class="workspace__toolbar">
    <label class="field-label" for="file">Choose an image</label>
    <input id="file" class="file-input" type="file" accept="image/*" />
  </div>
  <div id="preview" class="preview" aria-live="polite">
    <p class="preview__empty">Select an image to get started</p>
  </div>
  <div class="workspace__actions">
    <button id="export" class="btn btn--primary" type="button" disabled>
      Export result
    </button>
  </div>
</section>

The corresponding styles can be centralized:

.workspace {
  max-width: 1200px;
  margin: 0 auto;
  padding: var(--space-4);
  background: var(--color-surface);
}
.workspace__title {
  font-size: var(--font-size-lg);
  color: var(--color-text);
  margin-bottom: var(--space-4);
}
.workspace__toolbar {
  display: flex;
  flex-wrap: wrap;
  gap: var(--space-2);
  margin-bottom: var(--space-4);
}
.file-input {
  font-size: var(--font-size-md);
}
.preview {
  min-height: 360px;
  border: 1px solid var(--color-border);
  border-radius: var(--radius-md);
  display: flex;
  align-items: center;
  justify-content: center;
  margin-bottom: var(--space-4);
}
.preview__empty {
  color: var(--color-text-secondary);
}
.btn {
  border: none;
  border-radius: var(--radius-sm);
  padding: var(--space-2) var(--space-4);
  font-size: var(--font-size-md);
  cursor: pointer;
}
.btn--primary {
  background: var(--color-primary);
  color: #ffffff;
}
.btn--primary:hover {
  background: var(--color-primary-hover);
}
.btn--primary:disabled {
  background: var(--color-border);
  color: var(--color-text-secondary);
  cursor: not-allowed;
}

The point of this comparison is that the enhanced version is not necessarily more complex — it simply puts more weight on structure, state, and conventions.

7. Breaking Down the Evaluation Dimensions

7.1 Requirement Coverage

The baseline version may implement only three core points: upload, preview, and the export button. The enhanced version is more likely to add edge cases such as error messages, empty states, disabled states, and export progress.

For front-end delivery, what really separates versions is usually not the happy path but the exception paths and the completeness of states.

7.2 Semantic Quality of the Page Structure

When speed is the only goal, generated code tends to use non-semantic containers everywhere. With specifications in place, the output is more likely to use landmark regions, headings, form labels, and buttons.

The benefits of semantic structure include:

1. Screen readers understand the page more easily;
2. Maintenance and element location are clearer;
3. Style selectors are more stable;
4. Better support for search engines and automated tests;
5. Easier communication within a team.

7.3 Style Consistency and Reusability

Design tokens noticeably reduce randomness in colors, spacing, and radii. For instance, the baseline version may contain three near-white values — #fff, #ffffff, and #f8f8f8 — while the enhanced version is more likely to reference variables consistently.

Improved reusability significantly lowers the cost of switching themes, adjusting spacing, or adapting to a new page later.

7.4 Clarity of Component Boundaries

Whether front-end code is maintainable depends heavily on whether component boundaries are clear. The enhanced version is more likely to split the page into modules such as a toolbar, a preview area, an action area, and status messages; the baseline version may stuff everything into a single container.

Clear boundaries make it easier to swap implementations, add tests, and adjust layout later.

7.5 Completeness of State Management

A mature front-end page usually includes at least the following states:

1. Initial empty state;
2. Loading;
3. Successful preview;
4. Processing failure;
5. Export in progress;
6. Export complete;
7. Export failure.

The baseline version may implement only the success state; the enhanced version is more likely to cover the full state chain. This directly affects both user experience and engineering reliability.

7.6 Responsive Layout Stability

Problems are often invisible in a desktop demo, but once the window is resized or the device size changes, fixed widths, fixed heights, fixed spacing, and a non-wrapping toolbar expose the defects.

Layout rules in the design constraints push the generated code to consider:

1. Maximum width;
2. Safe margins;
3. Flexible spacing;
4. Wrapping strategy;
5. Adaptive preview area;
6. Minimum usable size.

7.7 Baseline Accessibility Quality

Accessibility is not an add-on; it is part of baseline engineering quality. The enhanced version is more likely to consider:

1. Label association;
2. Keyboard focus;
3. Button semantics;
4. Dynamic announcements;
5. Color contrast;
6. Image alternative text.

These details are routinely skipped in a quick demo but are critical in a real product.

7.8 Readability and Maintainability

The baseline version commonly suffers from arbitrary naming, scattered styles, and coupled logic. The enhanced version is more likely to use consistent naming, layered structure, and explicit states.

For example:

• workspace refers to the page workspace;
• toolbar refers to the action bar;
• preview refers to the preview area;
• btn--primary refers to a primary button;
• preview__empty refers to the empty state.

This naming convention lets team members understand the intent of the code quickly.

8. How to Verify the Real Difference Between the Two Versions

8.1 Build an Acceptance Checklist

Score each version item by item against a checklist like this:

Does the page complete the upload, preview, and export happy path?
Are empty, loading, and error states covered?
Does the button have a disabled state?
Does the file selection have a label?
Does the preview area have boundary guidance?
Are shared style variables used?
Are there many hard-coded colors?
Are semantic tags used?
Does the page support keyboard focus?
Is the layout stable on narrow screens?
Is the code clearly layered?
Is there obvious duplicated code?

8.2 Run Static Checks

Static checks focus on how the code is written, for example:

1. Is there heavy use of inline styles?
2. Are colors redefined repeatedly?
3. Are meaningless numbers used?
4. Are style variables missing?
5. Are key semantic tags missing?
6. Are there obvious naming conflicts?

Even if the page renders today, these issues affect later maintenance.

8.3 Run Runtime Checks

Runtime checks focus on real interaction:

1. Does a preview appear after an image is selected?
2. Is the export button disabled when no image is selected?
3. Is there a loading indication during export?
4. Is feedback given for an invalid file?
5. Can the keyboard focus the primary actions?
6. Does the layout break when the window is resized?

8.4 Assess Maintenance Cost

Maintenance cost can be estimated by asking how many places must change to make one modification in the future. For example:

• Change the primary button color;
• Adjust page margins;
• Add an error message;
• Replace the preview component;
• Add export progress;
• Adapt to narrow-screen devices.

If the design constraints took effect, these changes will typically be concentrated in the variables, components, or state layer rather than scattered across the whole codebase.

9. More Constraints Is Not Always Better

Design constraints improve generation quality, but that does not mean more rules are better. Over-constraining brings its own problems.

9.1 It Limits Creative Space

If the rules are too granular — for instance, specifying exact pixel values for every element — the output can become rigid and hard to adapt to real requirements.

9.2 It Increases Context Burden

An overly long context can dilute the important parts. A more reasonable approach is layered input:

1. The core requirement first;
2. Then visual specifications;
3. Then interaction specifications;
4. Acceptance criteria last.

9.3 Rule Conflicts

If one rule demands “fixed maximum width” while another demands “full-screen fluid layout,” the result may be unstable. Rules must stay consistent with each other.

9.4 The Source Must Be Trustworthy

If design tokens come from an outdated design file, the generated code may look compliant while actually violating current brand standards. Specification context therefore needs periodic maintenance.

10. Practical Advice for Real Projects

10.1 Build a Lightweight Specification Library

A team does not need a complete design system on day one, but it can start by capturing a minimum usable set of specifications:

1. A base color palette;
2. A type scale;
3. Spacing rules;
4. Radius rules;
5. Button states;
6. Form rules;
7. Page layout constraints;
8. A baseline accessibility requirement.

10.2 Write the Specifications Into Project Documentation

Specifications should not live only in verbal discussion; they should become reusable documents. For example:

Colors must use design tokens.
Spacing should prefer multiples of 4px.
Buttons must include default, hover, and disabled states.
Form controls must have labels.
The main page content has a maximum width of 1200px.
The toolbar may wrap on narrow screens.

10.3 Pilot Locally, Then Expand

Start by using specification context on one page or one module, verify the effect, and then extend to more pages. This avoids introducing too many rules at once for a team to maintain.

10.4 Tie Generated Output to Acceptance Criteria

AI coding output should not be judged only by “does it run.” It also needs to be checked against acceptance criteria. Only by turning specifications into checkable items can you form a stable feedback loop.

11. Conclusion: The Difference Is Engineering Usability, Not Surface Polish

For the same front-end requirement, adding or omitting a design constraints context can produce noticeably different results. The baseline version is usually better suited to fast prototype validation because it produces a visible page quickly; the enhanced version is closer to deliverable engineering code, and it is more stable in structure, styling, state handling, accessibility, and maintainability.

The essence of this difference is not a change in the amount of code but the explicit expression of engineering standards. Design specifications turn content that once depended on human review, individual experience, and repeated discussion into context that machines can understand, execute, and check.

For a front-end team, the real question is not how impressive one generation looks, but whether the output can enter the existing engineering system — whether it can be tested, maintained, extended, and reused. Building lightweight, clear, and maintainable design constraint context is a practical path to higher-quality AI coding output.