How I built an AI-native design process ·5m

Origin Story: How I built an AI-native design process

fig. 01 — origin story

project no. 01

How I built an AI-native design process

I built an AI-native design process at Pilotly– turning a sole-designer bottleneck into a pipeline where design system cleanup, documentation, prototypes, and front-end code all generate a single source of truth.

Role

Product Designer

Team

Joseph Audette, VP of Product and Engineering; Najeeb Chowdhury, Head of Product; 3-person engineering team

Timeline

Q1 2026 – present (in progress)

Space

Pilotly’s internal design system, tooling, and design-to-engineering pipeline

Skills

Design systems, automated documentation, interactive prototyping, AI tooling (Claude, Figma MCP), front-end code generation

problem

Our design-to-engineering pipeline carried structural debt — documentation lagged behind the product, handoff lived in static annotated screens, and the codebase wasn’t built around a design system — which meant the gap between design and engineering kept widening as engineering accelerated using AI.

solution

I built an AI-native design process in four compounding phases: a cleanup of the design system and a unified tokens.json across Figma and code, auto-generated component documentation pushed to Confluence, clickable Storybook prototypes generated from hi-fi designs via the Figma MCP, and an in-progress phase generating UX flows and front-end code from the documented system.

impact

~50% faster

design phase

shorter

design reviews

better output

from engineers

· the call

keeping pace with engineering

Engineering at Pilotly had roughly 3x’d their output by leaning into AI tooling. Our design-to-engineering pipeline carried structural debt: documentation lagged the product, handoff was static annotated screens, and the codebase wasn’t built around a design system.

In Q1 2026, we set a design OKR:

Explore whether AI could meaningfully accelerate the design-to-engineering pipeline. Not just use AI tools, but build an AI-native process.

· suit up

becoming #devsuma

In late 2025, my VP of Product and Engineering and I started talking about whether I could get into Claude and start coding. The thought was practical: if I could fix small visual polish myself, engineers could focus on architecture and product.

I set three key results: ship five design-authored UI improvement PRs, bring two core UI components into the codebase, and deliver a feature.

fig. 02 — #devsuma wins

fig. 03 — suiting up

· the four powers

Each phase opened the door to the next, often because Claude or Figma’s MCP shipped new capabilities mid-quarter.

· power 1

cleaning up the design system

I had Claude cross-reference every Figma component against actual usage in our codebase. Orphaned components got pruned, misplaced ones got rehomed. I unified design tokens into a single tokens.json so the system and the codebase finally spoke the same language. Without this foundation, none of the later phases would have worked.

Without a clean foundation, none of the later phases (especially front-end code generation) would have produced anything reliable.

fig. 04 — housekeeping!

· power 2

documentation that refreshes itself

With the system clean, Claude generated component and token documentation, pushed to Confluence. Documentation used to live in three places (Figma, scattered docs, my head). Now it regenerates from the actual system in minutes.

The real win is that the documentation regenerates from the actual system in minutes.

fig. 05 — documenting

· power 3

click-through design reviews

Using the Figma MCP, Claude reads hi-fi designs and produces interactive Storybook prototypes. New feature scoping is now reviewed on a prototype, not on static screens.

The review was shorter, there were almost no UX clarifying questions, which freed up the room to talk about how we would architect tickets and technical tradeoffs.

fig. 06 — prototype using claude x figma mcp

· power 4

generating UX flows and code

Mid-quarter, Claude and Figma updated their MCP so Claude could create designs, not just read them. The lesson, mid-experiment: working from documented components produces dramatically better output than generating from a vague prompt. The cleaner the context, the better the output.

The question shifted: given a prompt and the documentation I’d built, could Claude reliably produce a UX flow that respected our patterns? And from there, could it produce front-end code that aligned with our existing codebase?

fig. 07 — design generated using claude

· witness it

the handoff repo

When an engineer picks up a ticket now, they pull from a repo and find the PRD, static designs, Confluence docs, and a working code starter — all generated from a system that’s already in sync.

This repo is the proof point for taking on larger feature work using this process. It’s also where the handoff errors show up less. Engineers used to flag missing states, ambiguous spacing, or unclear interaction logic, and we’d cycle. Now most of that gets caught before the ticket is opened.

fig. 08 — component + code + ticket created using claude

· the crossover effect

design x engineering

Our engineers use Claude in their normal work too, and they’ve started reporting that the code their Claude produces is noticeably better when the shared context is right there. The pipeline is amplifying engineering output without anyone changing how they work.

· the proving ground

a designer building a feature

The pillar feature engineering didn’t have bandwidth for this quarter. My PM and I are coding it ourselves through the AI-native pipeline.

What I’m testing here is whether the pipeline scales from a single component to a full feature. My hypothesis: a combination of a PRD, documented Confluence components, and the tokens.json file should help give Claude enough context to write production-ready code.

Two non-engineers (a product designer and a product manager) – building a pillar feature for a production dashboard, using documented components, Figma MCP, and Claude. That is the fastest answer I have to “does this process actually scale.”

We’re still in progress. It might end with us shipping it, it might end with engineering pulling it across the finish line. Either outcome will teach us whether non-engineers can ship a pillar feature through this pipeline.

· the receipts

AI’s impacts

As a sole designer, I get my time back for the strategic layer.

fig. 09 — how this process impacted our workflow

· lessons from the lab

what i learned

AI didn’t replace any phase of design — it compressed the mechanical layer so I could spend more time in the strategic one.

Stable foundations make AI useful. Without Phase 1, none of this would have worked.

None of this came at the expense of quality.

· the ultimate form

where i see this going

Where this is headed: a designer or PM brings a DRD or PRD. Claude returns multiple UX flow options in Figma (or now, in Claude Design!), drawn from documented components and patterns. Design will refine. Code will generate. Engineering picks up tickets with something that already speaks the codebase’s language.

AI is the foundational layer of how we work.

For a 20-something-person company shaping research to studios that move billions, productivity is the surface story. The real one is competitive positioning.

I’ll write the next version of this piece when Build Audience ships.

the end.

see my work →

read project no. 2