Can copy-paste beat code generation?

Executive Summary

For a designer, the useful lesson is not “copy-paste is always better”. It is that a mature component can carry colour, focus and keyboard behaviour into a product without asking the model to remember them. The risk moves to the joins: the product-specific code that connects those components into a flow.

The study covers 88 runs across eight interface tasks. Arm C, which copied vetted component source and generated only the connecting code, ranked first. Arm A, which generated the interface directly, came second. Arm B, which read the real component API and then recreated the component, came last.

Three ways to build the same screen

A component is a reusable interface part, such as a button, field, menu or dialog. Its API is the rulebook that tells other code how to use it. A primitive is a foundational component that other interface patterns build on.

The experiment gave one AI model the same product task and the same empty project, then changed where the component source came from.

Arm A — generate everything

The model writes the whole interface directly, mostly with ordinary HTML elements and local styling.

Arm B — read, then recreate

The model reads the real component documentation, but still rewrites the component source itself.

Arm C — copy, then compose

A tool copies the vetted component files exactly. The model writes only the product-specific code that joins them together.

I call that copying step materialisation: known source becomes a real project file without passing through model output.

The missing middle path changed the answer. The first version of the study compared only A and C. Arm A had no external component API to misunderstand; arm C received the correct files intact. Neither was exposed to the predicted error.

Arm B created that condition. It knew the real API and still had to reproduce every line. Five of its 16 projects failed to build. The defect was real, but narrower than expected: it appeared when the model recreated a known component contract, not whenever it generated an interface.

Before looking at the numbers, compare the screens. These three compound interfaces all passed the five browser behaviours named in the task.

Arm A compound-state interface. It uses native elements and makes more local presentation choices.

×Close

A

Arm B compound-state interface. It uses a component layer recreated after reading the API.

×Close

B

Arm C compound-state interface. It composes copied registry components.

×Close

C

They look broadly similar. The important differences are mostly invisible in a static mock-up: who authored the reusable layer, which behaviours arrived with it and what happened when the pieces were connected.

A successful screen needs four green lights

The compiler is the software that checks and translates source code before a production build can ship. It catches broken imports and invalid types. It cannot tell whether a menu ignores Escape or focus disappears after a dialog closes.

Accessibility means whether people with different abilities can perceive, navigate and operate the product. An automated accessibility scan can catch some serious barriers, but it cannot judge every interaction or the whole experience.

Composition is the act of connecting components into a product. The composition seam is the boundary where a reusable component meets the page-specific code around it.

The layers disagreed in useful ways. One arm B command palette passed all five browser checks even though its production build had two compiler errors. A browser-only score would have called it perfect; a user could try it locally, but the team could not ship it.

The scorers were checked against a clean reference and a deliberately broken control before the experiment. Missing evidence stayed missing rather than being counted as a pass. One of the 88 runs lacked runtime evidence, so browser conclusions use 87 runs.

The failures were concentrated, not everywhere

Most runs worked. The complete ledger shows a few clear clusters rather than a general collapse of generated interfaces.

Five runs failed to build, all in arm B. Seven runs failed at least one browser behaviour. Nine runs had a serious or critical accessibility finding, all involving colour contrast. The composition audit found ten cases where the application discarded behaviour that a reusable component already provided.

Recreating known source caused every build failure

Arm B invented module paths, passed a property the component did not accept and twice used a real API in the wrong shape.

The fifth build failure was recovered during the manual production pass. Its original snapshot had no build result, but the final source survived in the trace. Rebuilding it revealed two module paths that did not exist, matching another failed users-table run. The earlier count of four was therefore one too low.

Arm A avoided this failure by not using the library. Arm C avoided it by copying the real files. Only arm B studied an implementation that already existed and then tried to recreate it.

Copying changed where the work came from

Reading documentation was not the useful step on its own. Across the five tasks completed by all three arms, arm B cost roughly twice as much as arm A, around three times as much as arm C, wrote the most source and produced every failed build.

Moving from B to C removed the unnecessary rewrite. Spend returned to roughly arm A’s level and the build failures disappeared. On the task combining tabs, a table and a dialog, arm B wrote 836 lines. Arm C wrote 258 lines and copied the existing components.

But “copy-paste writes less code” needs a qualifier. It writes less model-authored code. Copied files still ship in the repository.

Across the five shared tasks, arm C shipped 1.46 to 2.26 times as much source as arm A. That larger source tree contained a reusable layer that arm A usually did not create at all.

On the dashboard, arm A wrote six buttons directly in the page. Arm C copied one Button component containing variants, focus styling, disabled states and error states. Arm A did not make a smaller version of that layer; it skipped the layer.

There is a fairness caveat here. Arm A was told to build the interface “directly”, while the registry arms were told where component files belong. That wording nudged arm A towards page-specific code. The clean comparison is B versus C: both were asked to create the same component layer, and differed only in whether the model rewrote it or a tool copied it.

A component file carries invisible design decisions

The original hypothesis focused on broken imports and invented properties. The more interesting design finding was what travelled inside copied source without being requested.

The accessibility scan found only colour-contrast issues. On the compound-state task, arm A produced 11 serious or critical contrast findings, arm B produced six and arm C produced none. On the users table, arm C produced two while the other arms produced one each. The result favours C overall, but one task drives most of the gap; copying did not magically solve contrast everywhere.

Keyboard behaviour travelled more consistently. The users-table prompt never asked for its row menu to close on Escape. Arm A had to remember to add that behaviour. Arm C inherited it from the copied dropdown component.

Without extra reasoning, arm A failed all three runs while arm C passed all three. At high reasoning effort, arm A passed three of four and arm C passed all four. Arm A’s result depended on how much reasoning the model was allowed. Arm C’s did not; the behaviour arrived in the file.

The join is where behaviour disappeared

Copied behaviour only helps when the application connects it correctly.

The copied dialog knows how to return keyboard focus to the button that opened it. But the application still has to register that button as the opener. If it drives the dialog with separate state instead, the focus logic remains in the component file but never reaches the user.

Ten of 46 eligible runs lost behaviour at this seam, or 21.7%. Eight came from the compound-state task: every eligible arm B and arm C run. The defect was not peculiar to copying. It appeared whenever the dialog lived far from its opening button and the easiest implementation route bypassed the intended trigger.

These dialog screenshots look complete. All three open and close. All three return focus to the page body instead of the opening button—arm A because it never implemented restoration, arms B and C because they had the behaviour and routed around it.

Arm A dialog. It works visually, but focus is not restored after closing.

×Close

A

Arm B dialog. Its recreated component can restore focus, but the application bypasses the trigger.

×Close

B

Arm C dialog. The copied component contains focus restoration, but the application does not connect its opening button.

×Close

C

One controlled change confirmed the mechanism. Connecting arm C’s existing dashboard button through the dialog’s intended trigger moved the browser score from 14 of 15 to 15 of 15 and returned focus to the button. The same structural repair fixed the compound-state task.

The compiler, production build and accessibility scan could not see this defect. More documentation was not an obvious fix either: the model had read the dialog guidance and used the equivalent menu trigger correctly elsewhere.

Visually, all three approaches could look convincing

At application scale, the three paths converged in a four-route operations dashboard. Arm A added pill badges, chart gridlines and stronger local presentation choices. Arm C inherited structural details such as a close button that the prompt never requested. Arm B produced a similar reusable layer at greater cost.

Arm A dashboard overview, with KPI cards, gridlined charts and recent events.

×Close

A

Arm B dashboard overview, using components recreated after API retrieval.

×Close

B

Arm C dashboard overview, using copied components and a visually quieter chart treatment.

×Close

C

Copied components supplied structure. The model still made most presentation decisions. Arm A was often the most visually polished; C was often the most structurally consistent. Neither was uniformly better, and this experiment did not include a visual-quality scorer.

The row menus make that distinction tangible. All three opened and closed with Escape in the dashboard task, even though arm A had been inconsistent on the smaller users-table task.

Arm A services table with its generated row-action menu open.

×Close

A

Arm B services table with a model-written, library-backed row menu open.

×Close

B

Arm C services table with its copied dropdown menu open.

×Close

C

The arm A and C compound-state workspaces had been pruned. Their screenshots were rebuilt from durable experiment artefacts: generated files replayed from traces and copied files restored from the pinned registry snapshot. They are faithful reconstructions, not byte-identical originals.

The biggest shared design failure was responsive

The desktop screenshots hide the clearest failure shared by all three approaches.

I reconstructed and manually browser-tested 48 matched high-reasoning outputs: 16 per arm across the five shared tasks. I also checked one representative output from every arm and task at a 390-pixel viewport.

All dashboards completed the requested filters, menus, incident flow, routing and settings persistence. All three were unusable on a phone-sized screen. Forms and command palettes fitted. Wide tables were mixed: arms B and C usually contained overflow inside a table region, while one representative arm A table widened the whole page.

The production pass kept the same overall ranking: C first, A second, B third. It also sharpened the code-volume claim. Arm A averaged 358 application lines. Arm C averaged 237 application lines plus 450 copied component lines, or 688 shipped lines in total.

The measurement system had defects too

The test harness—the software that ran and scored the projects—created misleading results of its own. Six defects had already distorted a number before they were found and corrected.

There was a separate seventh issue in the prompt. Telling arm A to build the interface “directly” made the code-shape comparison partly a prompt comparison. It belongs beside the six harness defects, but it is not the same kind of problem: repairing it requires a new experimental arm rather than a scorer fix.

Two early checks also inspected implementation shape instead of observable behaviour. One demanded a particular input element and marked a correct component as broken. Another read an attribute and marked a menu as working without opening it. The final checks drive the interface and require a visible state change.

What designers can take into the next project

The component contract is not the finished experience. A design system can provide good local behaviour, but product design still owns how that behaviour survives composition, state, routes and breakpoints.

This changes what is worth specifying. A static dialog frame is not enough. The design needs to show which control opens it, where focus returns, what changes behind it, what persists after navigation and what happens when the viewport collapses.

It also changes review. A visually convincing screen can compile and still fail the product. Review the keyboard path, the close path, the empty state, the mobile layout and the state transitions that cross component boundaries.

What this experiment cannot prove

This is evidence from one inexpensive model, not a universal ranking of AI coding methods. High-reasoning cells used three or four seeds per task. Arm B covered five of the eight tasks. Three tasks also received three runs with no extra reasoning. Reasoning mode removed temperature control, so variation was observed rather than suppressed.

Only 87 of 88 runs had browser evidence. Dependencies were prewarmed, so installation cost was not measured. The accessibility gap was driven mainly by one task. The study did not score visual quality, screen-reader experience, long-term maintenance or how the outputs respond to later design changes.

The strongest next replication is a frontier model. It may recreate the component API correctly and remove arm B’s build gap.

A neutral arm A′ should say: build the interface and extract reusable components where useful. That would show whether arm A’s page-specific code was the model’s preference or the prompt’s instruction.

A blocks-based arm C should copy larger interface sections that already connect primitives. The question is whether moving more connecting code into the registry reduces the 21.7% seam rate or simply moves the next seam elsewhere.

So, can copy-paste beat code generation?

Yes, when the component contract already exists.

Copying vetted source prevented the failures caused by recreating that source, reduced the amount of custom code the model had to author and carried useful palette and interaction decisions into the project. Generating directly also proved reliable: arm A completed 36 runs without a build failure.

The honest design rule is conditional. Copy stable components. Generate the product-specific work. Then test the seam between them as seriously as the component itself.