AI-powered design-to-code tools have improved enough this year that we ran a real test: how much of a typical component, generated directly from a Figma file, actually holds up against our production code standards rather than just looking plausible in a quick demo. We picked a representative sample of components across three client projects, ranging from simple content cards to more involved interactive form elements, specifically to get an honest read across a range of complexity rather than cherry-picking the easiest case.
Static layout and basic responsive behavior came out close enough to production-ready that a developer's edits were mostly cosmetic rather than structural. Spacing, typography, and layout breakpoints translated from the Figma file with impressive fidelity, and a developer picking up the generated component spent most of their review time on small adjustments, a slightly off line-height here, a breakpoint that needed nudging there, rather than rebuilding the underlying structure from scratch. For components that are fundamentally about presenting content well, that's a genuinely useful head start.
Interactive states, hover, focus, loading, error, still needed a developer to fill in by hand, since the design file rarely specifies all of them explicitly in the first place. A Figma file typically documents a component's default appearance and maybe one or two key states a designer thought to mock up separately, but a production component needs to gracefully handle every state a user might actually encounter, including several a design file never depicts at all because they represent failure conditions or edge cases rather than the happy path a designer naturally focuses on when creating a mockup.
We noticed the generated components handled accessibility markup inconsistently, sometimes producing reasonable semantic HTML and ARIA attributes, sometimes producing a structure that looked visually correct but would behave poorly for a screen reader user. That inconsistency meant we couldn't treat generated accessibility markup as reliable without a dedicated review pass, which somewhat undercut the time savings on the components where accessibility mattered most, ones with complex interactive behavior rather than simple static content.
Generated components are a genuinely useful starting point, not a finished product. The time saved on static markup and layout is real; the interactive logic is still squarely a developer's job, and treating the output as a first draft to review carefully rather than code ready to ship directly is the right mental model for using these tools well. We've started incorporating design-to-code generation into our own workflow specifically for the static, presentation-heavy parts of a build, while continuing to build interactive logic and verify accessibility by hand, which has meaningfully sped up the parts of component work that were genuinely tedious without introducing new risk into the parts that require real engineering judgment.