Candace Wilson and her design team wanted engineers to reuse the code from their AI-assisted prototypes. The goal was to preserve details that can get lost when someone rebuilds a design. Writing for Bootcamp, she describes what happened at handoff:

By the time development picked up the prototype, something that looked almost finished on the surface could still be difficult to use as a starting point. We had pages that had grown into thousands of lines of code, unclear component boundaries, and sometimes implementations that didn’t match the design intent. A responsive experience, for example, could end up built more like separate adaptive layouts. In trying to reduce the visual handoff gap, we had sometimes created a different problem: an architectural handoff gap. Development then had to interpret, separate, refactor, or rebuild that work before it fit the production environment. Design had moved faster, but some of that effort had simply moved downstream.

This is the double-edged sword with designers using AI to write code. It looks done or good enough to us, but in reality, the generated code might be hiding a bunch of tech debt.

She allows for looser code when the prototype is disposable. For code another team is expected to build on, she proposes a different standard:

Prototype code does not need to be production-ready, but it should be production-useful.

For the kind of handoff I am talking about, that means the code should be structured well enough that development can extract from it without first untangling the entire thing. Component boundaries should be clear. Reusable pieces should actually be reusable. Responsive behavior should match the design intent. The prototype does not need to mirror the production codebase exactly, but it should be close enough that the handoff preserves some of the speed we gained by building in code in the first place.