# Same Prompt, Two AI-Generated Frontends: How Far Apart Are the Results

1. Why “it runs” and “it’s usable” are two different problems

When you use AI to generate a frontend page, the most common gap is not missing functionality — it is missing craft. The page can upload, slice, and download, yet the very first screen is a full marketing landing page: a large headline, a subheadline, buttons, and feature blocks crowded together. You have to scroll to reach the controls you actually need. That is where most complaints about “AI-generated pages looking ugly” come from.

But “ugly” is not an actionable requirement. To turn it into an engineering problem, the conclusion first has to be abstracted into a few hypotheses:

1. Output quality is decided mainly by how much constraint information a prompt carries, not by model randomness. If the requirement only says what to build, and not who it is for, where it will be used, and what must not appear, the output naturally falls back to the most common web template in the training data.
2. “The first screen is the workbench” is a hard requirement for tool pages. Users open the link to start working right away; every scroll is a point of drop-off.
3. “Local processing” is a compliance decision, not just a performance decision. Not uploading images is the most persuasive selling point for this kind of tool, and it has to be written into the prompt as a hard constraint — otherwise the model may “helpfully” wire up an external endpoint.

The three hypotheses are then verified with a single controlled experiment.

2. Experimental setup: holding everything else constant

Item	Setting
Requirement text	Identical, word for word
Session and directory	Same session, same empty directory
Only variable	Whether a “web design and UI polish” capability is loaded into the AI first
Output A (baseline)	No design capability loaded; generate directly
Output B (comparison)	Design capability loaded first, then generate
Dimensions observed	Information hierarchy, spacing rhythm, color consistency, state coverage, accessibility, code maintainability

The key point is that there is only one variable. If you change the wording of the requirement, the model, or the context at the same time, you can no longer tell whether an improvement came from the design capability or simply from the more detailed description.

3. The first step is not writing code, it is defining the acceptance checklist

Making this engineering-grade starts with translating a vague request into checkable items. For an online image slicing tool, the list looks like this:

Functional items

• Support both drag-and-drop upload and click-to-select, accepting common bitmap formats
• Support three slicing modes: 3×3 nine-grid, 2×2 four-grid, and a 3×1 vertical three-way split
• Label every tile with an index (1–9) and its dimensions
• Download a single tile, or download all tiles as an archive
• All processing happens locally in the browser; no image data is sent to any external address

Experience items

• The first screen is the working interface: the upload area or slicing result is visible without scrolling
• Processing shows progress or a loading state, and failures explain a understandable reason with a retry entry point
• Keyboard operable, visible focus styles, text contrast that meets requirements

Anti-pattern items (explicitly forbidden)

• No decorative illustrations unrelated to the tool, no sample avatars, no fabricated user testimonials, no fabricated statistics
• No filler content such as feature overviews, industry trends, or price comparisons

This list goes directly into the prompt. Writing down “what must not appear” is far more effective than repeating “make it look good.”

4. Breaking down the two outputs

4.1 Output A: functionally correct, rough in feel

The baseline code skeleton looks roughly like this, with no hard defects in the logic:

// Decode: always go through bitmap decoding to avoid the memory leak of Image + objectURL
async function decode(file) {
  return await createImageBitmap(file, { imageOrientation: 'from-image' });
}
// Split: round to integers to avoid a 1px half-pixel on export
function splitGrid(img, cols, rows) {
  const cellW = Math.floor(img.width / cols);
  const cellH = Math.floor(img.height / rows);
  const blocks = [];
  for (let r = 0; r < rows; r++) {
    for (let c = 0; c < cols; c++) {
      blocks.push({
        index: r * cols + c + 1,
        sx: c * cellW, sy: r * cellH, sw: cellW, sh: cellH,
      });
    }
  }
  return blocks;
}
async function exportBlock(bmp, b) {
  const canvas = new OffscreenCanvas(b.sw, b.sh);
  const ctx = canvas.getContext('2d');
  ctx.drawImage(bmp, b.sx, b.sy, b.sw, b.sh, 0, 0, b.sw, b.sh);
  return canvas.convertToBlob({ type: 'image/png' });
}

Even so, it exposes five typical problems:

• Broken information hierarchy: a landing-page header takes up the first screen, and the real upload area is pushed below the fold.
• Random spacing: 8px, 13px, 22px, and 31px are mixed together with no consistent spacing base, so the layout visually “drifts.”
• Colors without semantics: five or six colors appear, with no clear rules for primary, danger, success, or disabled colors.
• Only the happy path: decoding a large image fails, exporting an oversized image fails, and building the archive times out — none of it produces any feedback.
• Missing accessibility: icon buttons have no aria-label, the drop zone is not focusable, and the focus outline is erased by outline: none.

4.2 Output B: after adding a layer of design constraints

Once the prompt also specifies who it is for, where it will be used, what rhythm to arrange things in, and which states must exist, the output changes in four places:

1. The layout goes from “a page” to “a workbench”: two columns — a control panel on the left (slicing mode, export format, download button) and a preview grid on the right; it stacks automatically on narrow screens.
2. Design tokens are extracted: spacing is based on 4px (4/8/12/16/24/32), the font-size scale is narrowed to four or five steps, corner radius and shadow each keep only two options, and color is reduced to a primary color, a neutral color, and one status color.
3. States are complete: uploading, decoding, exporting, success, failure, and empty state each have their own presentation, and the failure state gives a reason plus a retry button.
4. Interaction feedback is perceivable: the border highlights when a drag enters the area, tiles generate thumbnail cards in order with index and pixel size labeled, and the archive download button enters a disabled state while multiple tiles are exporting.

Loading a design capability does not mean “zero human work.” Output B still requires a person to verify three things: whether the palette fits the brand requirements, whether contrast meets the bar, and whether the first screen really needs no scrolling at the target resolution.

5. Quantifying the difference: turning “looks good” into measurable metrics

Subjective judgment never converges, so it is better to compare before and after using metrics that can be counted mechanically:

• Color count: count the unique colors that appear in the CSS. For a tool page, 5–8 is a reasonable range.
• Spacing base: collect every padding/margin/gap value and take the greatest common divisor. A base of 4 or 8 means a rhythm has been established.
• Font-size variety: the number of unique font-size values. More than six usually means the hierarchy has run out of control.
• State coverage: whether loading / empty / error / disabled states are all covered.

Comparing these metrics is a far more convincing criterion for “the design capability worked” than eyeballing screenshots, and it also prevents regressions across multiple iterations.

6. A reusable prompt structure template

A design capability is only one layer of constraints. What really decides output quality is the structural completeness of the prompt. Seven slots are recommended:

[ROLE AND GOAL] You are a senior frontend engineer. Produce a ready-to-use single-page tool.
[CONTEXT AND AUDIENCE] Used by creators/content marketers in a desktop browser, full screen; the goal is to finish one task in under 10 seconds.
[FUNCTIONAL REQUIREMENTS] List the functional items, numbered one by one, each verifiable.
[DESIGN CONSTRAINTS] Provide the spacing base, font-size scale, maximum number of colors, and the number of corner-radius and shadow options;
             the first screen must present the working area directly; decorative illustrations, fictional testimonials, fictional data, and filler copy are forbidden.
[INTERACTION AND STATES] Must cover six states: uploading / processing / success / failure / empty / disabled;
             keyboard reachable, visible focus, text contrast that meets requirements.
[TECHNICAL BOUNDARIES] All image processing happens locally in the browser with no external requests;
             large images need graceful degradation and upper-limit protection; export uses Blob + temporary URLs, released immediately after use.
[DELIVERY AND ACCEPTANCE] Output a single HTML file (inline styles and scripts), plus a self-check list.

The [DESIGN CONSTRAINTS], [INTERACTION AND STATES], and [DELIVERY AND ACCEPTANCE] blocks are the ones most often skipped — and the ones that make the biggest difference.

7. Engineering points for pure client-side local processing

The technical risks of a tool page are rarely in the features; they are in the boundaries:

• Memory peak: after decoding, a bitmap occupies roughly width × height × 4 bytes. A 6000×4000 image is about 96 MB, and with tile and export buffers the peak can double. Above a threshold, show a clear warning, or switch to lazy per-tile decoding.
• Main-thread blocking: put large image decoding and encoding in a Web Worker, or schedule it during idle time, so the interface does not freeze.
• Oversized canvas: browsers cap a canvas’s single-side dimension and total area; exceeding the cap makes exports fail silently, so you need a try/catch fallback.
• Pixel alignment: cut points must be rounded to integers, otherwise adjacent tiles overlap or leave a gap by 1px, which is clearly visible once a nine-grid is reassembled.
• Orientation and watermark: correct according to the file’s orientation flag during decoding, so the export is not rotated; if denoising or smooth scaling is needed, use the browser’s image interpolation quality option.
• Packaging strategy: when there are many small files, bundling them into an archive is the least effort; when the files are large, downloading one by one may be more stable — let users switch between the two modes.
• Resource recovery: every temporary URL created for an export result must be released after use, otherwise memory keeps climbing during long sessions.

8. Shipping path and cost control

Because all computation happens inside the browser, deployment for this kind of tool is extremely simple: static assets only.

• What to host: one HTML file plus any necessary static assets, placed on any object storage or static site hosting service.
• Caching: enable long cache for static assets plus hashed filenames, so updates take effect immediately while origin requests stay minimal.
• Domain and HTTPS: bind a custom domain and enable the certificate; image downloads are only unblocked by the browser under HTTPS.
• Monitoring: hook into standard logging and alerting, and watch first-screen load time, script error rate, and the 4xx/5xx ratio for static assets.

Since there is no backend computation and no bandwidth relaying, the monthly cost is usually a tiny amount tied only to storage and request count. That confirms the advantage of “local processing” in the cost model: the compute is spent on the user’s own device.

9. Retrospective: three transferable conclusions

1. A design capability is a set of constraints, not aesthetic mysticism. The spacing base, font-size scale, color ceiling, and state list — write these four into the prompt and output consistency improves the most.
2. Define “done” before letting the AI start. Putting the acceptance checklist first eliminates both problems at once: incomplete features and padded content.
3. One generation round is worse than several iterations. Round one only guarantees that structure and functionality run; round two adds states and accessibility; round three converges spacing and color. Change one class of problem per round and the regression risk stays lowest.

With this method, you can end up with an image slicing tool that is usable on the first screen, restrained in layout, and complete at the boundaries — without writing a single line of code. The real payoff is that this workflow of acceptance checklist + layered prompt + quantified comparison transfers directly to any AI-assisted single-page tool project.