Same Requirements, Two Builds: Do AI Coding Tools Need Design Skills?

1. Breaking Down the Requirements: What “Professional-Grade” Means for a Slicing Tool

When you hand “build an online image slicing and annotation tool” to an AI coding tool, the same request with a different configuration rarely produces the same kind of artifact. One version gives you code that runs. The other gives you an interface that looks like a real product in use. The gap isn’t only about “aesthetics” — it comes from whether the prompt turns visual rules, interaction details, and acceptance criteria into executable requirements.

Before generating anything, the implicit requirements have to be spelled out, otherwise the two builds can’t be compared fairly.

A usable slicing tool needs at least four groups of capabilities:

• Image loading: pick a file from disk or drop an image in, and read its intrinsic dimensions. This determines whether the pixel annotations that follow are accurate.
• Slice configuration: set the rows and columns of an equal grid, or cut slices by custom rectangular coordinates. Each slice should be previewable, downloadable, and renameable on its own.
• Pixel annotation: draw rulers, dimension lines, and text labels against source-image coordinates. Annotations must stay pixel-accurate after zooming while keeping line widths legible.
• Export and experience: single-slice export plus bulk download as an archive, along with the full interaction set — zoom, pan, error messages, and undo.

Two details are easy to miss:

1. When the grid and annotations are drawn over the image, ruler text has to land on integer pixels. Otherwise it goes half-pixel blurry on high-DPI screens and looks cheap.
2. When the row and column counts don’t divide the image dimensions evenly, you have to decide up front how the remainder is distributed across slices. Otherwise gridlines and slice boundaries don’t line up, and the coordinates you annotate stop meaning anything.

This requirements list is also the baseline for the comparison below.

2. Method: Change One Variable Only

The basic rule of a controlled comparison is single-variable isolation. Everything held constant across both generation runs:

• The same requirements document and the same five-part prompt (see Section 5);
• The same model version and the same inference configuration;
• Generation starting from the same empty directory;
• All artifacts written directly by the tool, with no manual code edits at any point.

The only variable is whether a “design skill pack” — short form “design skills” — was loaded. These skills are typically a set of specifications and checklists shipped with the tool and invoked on demand, used to constrain how the front-end UI is generated. Both builds load the same skill pack, so differences in skill content can’t skew the result.

One more caveat: a model’s single output is stochastic. The assessment is based on the overall tendency across several consecutive generations, not on the outcome of one run.

3. Side by Side: Where the Builds Differ, and Where They Don’t

Both builds generated a structurally complete single-page app that runs, and both get the core features working. So “does the feature exist” is not the dividing line. The difference is in how complete, how smooth, and how good the result looks.

Aspect	Prompt-only build	Build with design skills loaded
Visual system	Spacing is scattered; the accent color is consumed by buttons, gridlines, and selection outlines at once, so hierarchy is unreadable	Spacing mostly sits on one baseline grid; the accent is concentrated on the primary action and the selected state; neutrals are layered
State coverage	Often default state only; button press and input focus lack visual feedback	Hover, focus, pressed, disabled, and loading states are largely all present
Annotation legibility	Rulers, connector lines, and text share the same color and weight, so they interfere with each other over the image	Lines, endpoints, and text are separated by color hierarchy and outlines, and stay readable on dark images
Information organization	Settings and results are laid out flat; the more elements, the more crowded	Settings, annotation list, and canvas are clearly zoned, with common actions surfaced first
Code structure	Colors and spacing hard-coded ad hoc throughout the CSS	Palette, spacing, and radii collected into CSS custom properties, so re-theming is a one-place change
Engineering details	Images blur from resampling while loading and zooming; bulk download fires one download per slice	Backing store sized against device pixel ratio; bulk download merged into a single archive; stray styles consolidated
Responsive behavior	On narrow screens the sidebar squeezes the canvas, and horizontal scrolling appears	The settings panel collapses, and the canvas keeps priority in the main area

These differences boil down to three layers:

1. Visual consistency: design skills require the palette, spacing, and type scale to be defined before they are used, which gives the interface a consistent order.
2. State completeness: they require every interactive element to have a full set of states, and much of a tool’s “feel of reliability” comes from exactly this.
3. Engineering details: they push attention toward things users can’t name but feel immediately — sharpness while zooming, how bulk download works.

Design skills aren’t free, though. Three things to watch:

• Higher context and latency cost: design skills usually carry long specification text, which isn’t a good trade on simple tasks.
• Possible increase in decoration: some skills lean toward “visual impact” and introduce gradients, large radii, or elaborate animations, which undercuts the restraint a tool UI needs.
• Conflict with project conventions: a generic spec inside the skill may not match the project’s own design system.

4. Mechanism: What Design Skills Actually Change

To decide when design skills are worth it, you first need to understand how they work. They don’t change the model’s grasp of code syntax, and they don’t grant it new capabilities. They change the constraint set and the attention allocation during generation.

First, they translate vague adjectives into checkable rules. Write “make it look professional” in the prompt and the model has to guess. A design skill expands “professional” into concrete constraints, for example:

• Spacing follows a single baseline system;
• The accent color is used only for primary actions and the selected state;
• Every interactive element has a complete set of states;
• Text and background maintain sufficient contrast;
• No horizontal scrolling on small screens.

The more specific the constraint, the more stable the output.

Second, they fill in what the user left unsaid. People describing a tool usually talk about features and rarely mention empty states, loading states, error messages, or keyboard operation. Design skills turn these implicit requirements into defaults, so the result looks closer to a “complete product” than a “feature demo.”

Third, they change the starting point for information organization. With a design spec in place, the model tends to establish design tokens first — palette, type scale, spacing scale — and then assemble the page from them. This top-down approach keeps styling consistent in structure, not just for this one render, and any later adjustment has a single source of truth.

Conversely, the gap narrows sharply once the prompt itself is specific enough. The fourth block of the template in Section 5 works precisely because it acts as a lightweight design skill.

5. A Five-Part Prompt Template: Writing Requirements as Executable Specs

Whether you get a high-quality interface reliably often depends more on how the prompt is organized than on the model’s parameters. Here is a reusable template. Using the slicing tool as the example, each part has a distinct job:

• Part 1 · Role and goal: fixes the technical boundaries so the artifact is zero-dependency and works out of the box.
• Part 2 · Data model and state: requires structure to be defined before code, which is what makes canvas rendering accurate.
• Part 3 · Core interactions and algorithms: converts fuzzy feature descriptions into explicit inputs, outputs, and behavior contracts.
• Part 4 · Visual and interaction spec: yields a rule-driven interface with no design skill loaded at all.
• Part 5 · Delivery and self-check: brings acceptance criteria into the generation step and cuts down on rework.

Part 1: Role, scope, and technical constraints

You are a senior front-end engineer. Build a single-page "online image slicing and annotation tool" with vanilla HTML, CSS, and JavaScript.
The target environment is modern browsers. Do not use any third-party library or framework, do not depend on a backend service; all image processing happens locally in the browser.
Deliver a single index.html file that can be opened by double-clicking, with the CSS and JavaScript inlined.
Split the code into modules for "config & state", "image loading", "canvas rendering", "interaction control", and "slice export", and mark the module boundaries with comments.

Part 2: Data model and state

First define the data structure for the slice configuration (JSON), then implement rendering and interaction on top of that structure:
{
  "grid": { "rows": 4, "cols": 6 },
  "slice": { "mode": "equal", "rects": [] },
  "annotations": [ { "type": "rect", "x": 0, "y": 0, "w": 1200, "h": 600 } ]
}
Requirements:
1. The source image and the canvas must use exactly the same coordinate system, with the origin at the top-left corner, in source-image pixels;
2. When rows × cols does not divide the image width and height evenly, compute each gridline coordinate by distributing the remainder row by row and column by column to the last few cells, so gridlines and slice boundaries match exactly;
3. Annotation coordinates and sizes are always stored in source-image coordinates; zooming changes only the display scale, never the underlying data;
4. Support multiple annotation types (rectangular regions, horizontal/vertical rulers, text labels) and provide a list view for adding, deleting, and locating them.

Part 3: Rendering, interaction, and export

Canvas rendering:
1. Size the canvas backing store using devicePixelRatio so images and lines do not blur after scaling;
2. Draw ruler lines and annotation text at integer pixel positions, with line width independent of the zoom level;
3. Provide three zoom modes — fit to window, zoom in, zoom out — anchored on the canvas center, and show the current scale in real time.
Interaction and export:
1. Support space + drag to pan and mouse wheel to zoom;
2. Each slice can be previewed and downloaded individually, named "<originalname>_r<row>_c<col>.<ext>";
3. Bulk download produces a single archive with no external library;
4. On error, show a clear message in the UI (for example, unsupported file format or decode failure).

Part 4: Visual and interaction spec

Visual rules:
1. Dark-theme tool panel. The accent color is used only for the primary action button and the currently selected item; gridlines use a low-contrast neutral so they are not confused with the annotation layer;
2. Spacing follows a 4px scale; the overall layout is "settings panel on the left, canvas in the middle, annotation list on the right";
3. Every button and input has five states — default, hover, focus, pressed, disabled — and keyboard focus is visible;
4. Below 900px viewport width the settings panel can be collapsed, the canvas stays fully visible, and the page has no horizontal scrolling.
Feedback and details:
5. Show load progress while the image decodes; display zoom level, image dimensions, and pointer coordinates in real time;
6. Support undo for the last annotation and Esc to cancel the current drawing;
7. Use the system font stack for UI text (add a CJK fallback if the interface is localized), and use tabular numerals so coordinate and dimension readouts line up.

Part 5: Acceptance and self-check

After completing the implementation, self-check the list below item by item, and summarize the result of each item in a table at the end of your response; fix any failures and re-run the check:
1. The page opens in a Chromium-based browser with no console errors;
2. Importing a 1200 × 800 image set to 4 rows and 6 columns produces 24 slices of 200 × 200, with the row/column numbers in the filenames starting at r0_c0;
3. At 300% zoom the image and text show no visible blur, and annotation coordinates match the actual image pixels;
4. Both per-slice download and bulk download produce correct files;
5. Layout is intact with no horizontal scrolling at 1440px, 768px, and 375px viewport widths;
6. All annotation operations — add, delete, undo — can be completed with the keyboard alone.

Two things worth noting when using this template:

• Write requirements as checkable facts. Use “line width does not change with zoom” instead of “make it crisp,” and “filename format is …” instead of “use sensible naming.” The more checkable items there are, the more reliable the model’s self-check, and the less rework you do.
• Send it part by part rather than pasting one long block. Review each part’s output quickly, then carry the result into the next part. Errors are easier to localize this way, and the context doesn’t get filled up with useless material.

6. Conclusions and How to Choose

Back to the original question: how far apart are the two builds with and without design skills?

• Functionality: not far apart. Both complete the core features.
• Delivery quality: clearly apart. On visual consistency, state completeness, information organization, and engineering details, the build with design skills is closer to a shippable product; the build without usually needs one to a few rounds of manual polish.

Choose based on the nature of the task:

Task type	Recommendation	Reason
Building a front-end UI from scratch, prototype validation, internal tool pages	Enable	The gains in visual consistency and state completeness are immediately visible
Page structure and data model design, API integration, algorithm implementation	Skip	Design constraints contribute little and just add context overhead
Working inside an existing project that already has a design system	Enable with care, or use the project’s own spec	Generic rules may override the project’s existing palette and component style, creating inconsistency
Results will be shown to external users	Enable, together with the Part 4 visual spec	Manual polish is most expensive here, so constraint-driven output pays off most

The safer pattern is layered use:

1. Let design skills cover the generic quality floor — spacing system, contrast, state completeness, responsiveness.
2. Write the project’s proprietary rules explicitly into the prompt — brand colors, component style, existing design tokens.
3. When the two conflict, the project spec wins.

7. From Local Run to Zero-Cost Launch

This tool is entirely front-end: images are processed in browser memory, with no server and no database, which makes it a natural fit for zero-cost deployment.

• Deployment: the build output is static files, so hosting it on any object storage service with static website hosting is enough to make it reachable. If traffic grows, add a CDN to speed things up.
• Custom domain: you can serve the tool from your own domain. Note that some browsers treat certain free domain suffixes as an insecure context, where capabilities like the Clipboard API may be restricted — worth verifying in advance.
• No data upload: everything is processed locally, which saves server and bandwidth cost and reduces the risk of user images leaking. This is the advantage such tools have over upload-based online services.
• Where cost actually comes from: zero cost doesn’t mean zero cost structure. With no server or database, cost comes only from static asset storage and CDN traffic. For a small page this is typically negligible, but with many image assets and rising traffic, storage and bandwidth charges need to be estimated up front.
• Large images: with very large files (a scan of hundreds of megapixels, for example), decoding alone can exhaust memory. Prompt the user to compress first, or adopt a chunked decoding approach before generating slices.

8. Pre-Launch Checklist

Functional correctness

• Grid coordinates and slice sizes stay consistent when the division is not exact;
• Annotation coordinates match image pixels exactly after zooming;
• Images with an alpha channel export without a black background.

Compatibility

• The compression library API used for bulk download differs across browsers;
• Some compression implementations lack a synchronous interface and can block the page during large batch archiving, so an async path is required.

Performance

• Release the previous image data before importing a new one;
• Avoid redrawing the whole image on every frame while dragging an annotation;
• Where necessary, move slice computation off the main thread using an OffscreenCanvas or a Web Worker.

Security and privacy

• The tool should only process images locally;
• Do not add third-party analytics scripts or references to external resources.

9. Closing

Generating two builds from the same prompt illustrates how AI coding tools actually work: the prompt sets the floor for the output, and design constraints set the ceiling.

Design skills are neither “aesthetic magic” nor optional decoration. They are a way to encode professional front-end experience as executable rules:

• Used well, they raise “code that works” to “a product you can deliver”;
• Used excessively, they bring context overhead and spec conflicts.

The more transferable lesson is the brand-agnostic method: describe requirements in verifiable language, write the acceptance criteria into the prompt, and then check the artifact item by item. It works for any AI coding tool, and it works for plenty of work outside prompting too.