Design Engineering at Fortune 500 Scale: What Actually Works

A Fortune 500 product designer tried to push AI-generated interfaces straight into production and hit a wall. The bottleneck wasn't the models. It was governance.

Jinson C. Johny, who works inside a large design organization with hundreds of components, multiple product teams, and established accessibility and compliance processes, set out to test whether Figma Make, Codex, Antigravity, and Claude could compress the path from concept to shippable code.

The first attempt failed. "Outputs were fast but they weren't ready for that environment," Johny wrote in his first HackerNoon article. Component governance, accessibility reviews, and design system consistency all required human checkpoints that no AI workflow could replace.

What changed the workflow?

The team stopped treating Figma as the source of truth. Storybook became it.

Designers started updating components directly through code, using Figma MCP as a bridge. Motion, states, edge cases, and interactions moved into the actual component environment. Designers and engineers stopped handing off files and started iterating inside the same surface.

"Engineers moved further into architecture and business logic. Designers got closer to the thing they'd always been trying to influence: the final product," Johny wrote.

How did skills replace handoffs?

The team packaged repeated process steps as markdown-based "skills" that AI agents could execute on demand.

A Figma-to-Storybook skill mapped variables, colors, and spacing to the right tokens and Code Connect references rather than hardcoded values. A Code Connect skill automatically wired approved Figma components to their Storybook counterparts. Accessibility checks, motion spec generation, and missing-state flagging all became reusable instructions the team could call repeatedly.

"You write it once, and it runs every time, for everyone," Johny noted.

What does the role actually require?

Design Engineering, in Johny's framing, is neither a designer who codes nor an engineer who designs interfaces. It is a practitioner at the intersection: product thinking, UX, design systems, frontend, and accessibility awareness, with each skill reinforcing the others.

Learning a JavaScript framework makes someone a sharper prototyper. Working inside components makes accessibility something designers apply in context, not audit after the fact. AI accelerates every dimension of that role, but it does not replace any of them.

Where does AI still fall short?

AI can generate an interface in minutes. It cannot judge whether the information architecture suits the users, whether the interaction pattern fits the product ecosystem, whether the design is accessible across the full user base, or whether a new hire will understand it eight months from now.

At Fortune 500 scale, those questions carry more weight, not less. "The speed of production is going up, and someone still has to make sure the right things are getting built," Johny wrote.

How are teams using AI in practice?

Two workflows are taking shape across organizations experimenting with these practices.

A prototype-first path uses AI to put functional experiences in front of stakeholders early, compressing feedback loops before misalignment becomes expensive. A production-ready path embeds designers inside design systems and component libraries so AI-accelerated output can actually ship.

Neither is universally right. In a large org, the prototype-first approach often smooths the path for production-ready work. Both demand that designers think about implementation.

Large organizations will still need specialists in research, service design, accessibility, content, and design systems. But the designers who can sit in a sprint, review a pull request, and ship a skill that saves the team an hour each week carry a different kind of leverage than the ones handing off static screens.

For Johny, the lesson that emerged from months of experimentation had little to do with AI itself. "The closer you are to how something gets built, the easier it becomes to validate your decisions, catch the gaps, and ship something that actually reflects what you intended," he wrote.

The next step for design organizations is not deciding whether to adopt AI, but deciding who inside the team will own the skills, tokens, and review processes that turn AI speed into shipped quality.