Skip to content
Nikhil Sharma
Operating Manual · AI-native Delivery

AI Workflow

AI-native workflows should compress repetitive translation work without bypassing human judgment or engineering ownership.
Audience
Design leaders, product leaders, engineering leaders
Status
Operating guide v1

The goal is not to prove that designers can generate code. The goal is to reduce waste between design intent and shipped product while protecting quality.

What this solves
  • Manual Figma-to-code translation
  • QA/UAT drift
  • Repetitive frontend work
  • Slow experimentation
  • Weak design-to-production continuity
  • Design system not connected to implementation
  • Engineering time spent on repetitive UI translation
  • Designers unable to validate production parity quickly
When to use this system

Use this operating model when:

  • A design system exists but implementation still varies across squads.
  • Engineers repeatedly rebuild UI from Figma.
  • QA/UAT is catching visual parity problems late.
  • Designers are producing polished screens but not production-ready foundations.
  • Product teams need faster experiments without lowering implementation quality.
  • AI tools are available but workflow governance is missing.
When not to use this system

Do not use this model when:

  • The design system is still messy.
  • Components lack clear naming, variants, states, or tokens.
  • Engineering has not agreed on review ownership.
  • Product logic is complex, regulated, or security-sensitive.
  • The team wants AI to bypass code review.
  • Designers are not ready to own Figma hygiene.
  • Leadership expects magic automation instead of operating change.
Core principles
  1. 01

    AI accelerates the system you already have.

    If the operating model is weak, AI scales the weakness.

  2. 02

    Source quality determines output quality.

    Generation is only as reliable as the tokens, variants, and naming it reads.

  3. 03

    Production-ready does not mean production-owned by AI.

    Foundations still pass engineering review before anything ships.

  4. 04

    Human review becomes more important, not less.

    Output volume rises; human judgment is the gate that keeps quality flat.

  5. 05

    Prompts and workflows are product infrastructure.

    Reusable patterns beat personal tricks; maintain them like code.

  6. 06

    Engineering trust is the scaling constraint.

    Adoption grows at the speed engineers trust the output, not faster.

  7. 07

    Start with controlled components before journeys.

    Prove the loop on small surfaces before screens and full flows.

  8. 08

    AI should automate translation, not judgment.

    Repetitive UI translation is in scope; product and design decisions are not.

Inputs required

What must exist before the workflow starts.

  • Clean Figma components
  • Naming conventions
  • Tokens
  • Variants
  • States
  • Responsive rules
  • Accessibility basics
  • Existing frontend conventions
  • Component ownership
  • Review ownership
  • Prompt patterns
  • QA/UAT path
  • Production release path
Operating model

The step-by-step system. Each step has a purpose, an owner, and an output.

  1. 01

    Audit design-system readiness.

    Purpose
    Confirm the source system can support generation before any tooling.
    Owner
    Design, with engineering input
    Output
    Readiness gaps and a go / no-go call
  2. 02

    Select controlled components.

    Purpose
    Start where volume is high and judgment is low.
    Owner
    Design + engineering
    Output
    A pilot component list
  3. 03

    Clean Figma source structure.

    Purpose
    Make the source unambiguous: naming, tokens, variants, states.
    Owner
    Design
    Output
    Generation-ready components
  4. 04

    Define generation boundaries.

    Purpose
    Fix what AI may produce and what stays human-led.
    Owner
    Design + engineering leadership
    Output
    Written boundary rules
  5. 05

    Connect Figma structure through MCP.

    Purpose
    Give the generation tool structured design input, not screenshots.
    Owner
    Engineering setup; design owns the source
    Output
    A live design-to-tool connection
  6. 06

    Generate frontend foundation.

    Purpose
    Produce componentized, token-aligned, responsive starting code.
    Owner
    The designer or engineer operating the workflow
    Output
    A reviewable frontend foundation
  7. 07

    Run design visual QA.

    Purpose
    Verify parity, states, hierarchy, and responsive behavior.
    Owner
    Design
    Output
    Visual QA pass, or a fix list
  8. 08

    Run engineering review.

    Purpose
    Protect code quality, architecture, security, and integration.
    Owner
    Engineering
    Output
    Production-quality code, or rework notes
  9. 09

    Run product and QA validation.

    Purpose
    Confirm behavior against acceptance criteria and edge cases.
    Owner
    Product + QA
    Output
    A validated build
  10. 10

    Move through the normal release process.

    Purpose
    Ship with the same guarantees as any other code.
    Owner
    Engineering
    Output
    A released frontend
  11. 11

    Feed failures back into the design system.

    Purpose
    Convert defects into system improvements, not one-off fixes.
    Owner
    Design-system owner
    Output
    Updated components, tokens, and prompt patterns
Ownership model

Design owns

  • Figma structure
  • Component naming
  • Visual parity
  • Design tokens usage
  • Interaction intent
  • State completeness
  • Visual QA

Engineering owns

  • Code quality
  • Architecture
  • Performance
  • Accessibility
  • Security
  • API integration
  • State management
  • Testing
  • Deployment
  • Maintainability

Product owns

  • Business intent
  • Flow priority
  • Experiment scope
  • Acceptance criteria
  • Outcome validation

QA owns

  • Functional validation
  • Edge cases
  • Regression
  • Release confidence
Quality gates

What must be true at each stage before work moves forward.

Before generation

  • Figma source uses approved components.
  • Tokens are applied.
  • States are defined.
  • Responsive expectations are clear.
  • Component ownership is known.

Before engineering review

  • Generated UI matches Figma visually.
  • No hardcoded styles where tokens exist.
  • Common states are present.
  • Component structure is reusable.
  • Known gaps are documented.

Before production

  • Engineering review complete.
  • Accessibility reviewed.
  • Functional QA complete.
  • Product validation complete.
  • Release path followed.
  • Learnings captured.
Anti-patterns

What breaks this system.

  • Generating from messy Figma files.
  • Treating AI output as production code.
  • Bypassing engineering review.
  • Using AI for complex product logic too early.
  • Hardcoding styles instead of tokens.
  • Letting every designer invent their own prompts.
  • Measuring tool usage instead of workflow impact.
  • Calling prototypes “production-ready”.
  • Scaling before controlled wins.
  • Ignoring accessibility and responsive behavior.
Metrics to track

Track these before and after adoption. Targets depend on your product, team, and regulatory context; no benchmark numbers are implied here.

  • Time from approved design to working frontend foundation
  • Visual QA defects
  • QA/UAT cycle time
  • Number of handoff clarification loops
  • Rework caused by visual mismatch
  • Component reuse rate
  • Token usage consistency
  • Number of AI-generated components accepted after review
  • Engineering review effort
  • Accessibility issues found
  • Adoption across squads and designers
Governance rules
  • AI cannot bypass design QA.
  • AI cannot bypass engineering review.
  • AI cannot own regulated or business logic.
  • AI cannot ship code without the normal release process.
  • Prompt patterns must be reusable.
  • Generation failures must improve the system.
  • Human owners remain accountable.
Implementation sequence
  1. Phase 1

    Foundation audit

    Design-system hygiene: tokens, variants, states, and coded-component parity.

  2. Phase 2

    Controlled component pilot

    Use safe, high-volume components first.

  3. Phase 3

    Screen-level generation

    Move from components to screens only after pilot stability.

  4. Phase 4

    Review loop standardization

    Design QA, engineering review, product validation, and QA/UAT as a fixed loop.

  5. Phase 5

    Scale across teams

    Adoption, training, prompt libraries, and measurement.

Leadership questions

The questions a leadership team should be able to answer before and during adoption.

  1. 01What should AI be allowed to generate?
  2. 02What should remain human-led?
  3. 03What must engineering own?
  4. 04What source-system quality is required before scaling?
  5. 05What metrics prove the workflow is working?
  6. 06What risks increase if adoption is forced too early?
  7. 07Where can this create technical or design debt?
  8. 08How will failures improve the system?
Related transformations

This operating guide is derived from the AI-native Product Development transformation story. The workflow also depends on the design-system and organizational maturity built in Building the Design Organization.

AI-native Product Development
Building the Design Organization
Related operating guides
Design Systems

The system-readiness layer for clean components, tokens, states, naming, and governance before AI-assisted generation.

Organization Design

The operating model that creates the ownership, review discipline, and engineering trust required before AI-native workflows can scale.

Future additions

This guide will expand with:

  • AI-readiness checklist
  • Prompt pattern library
  • Design-system audit template
  • Visual QA rubric
  • Engineering review checklist
  • Governance checklist
  • Adoption scorecard