The AI-Native Design Workflow

Learning from Linear, Cursor, and Anthropic

Introduction

Something fundamental is changing in how the best product teams work.

Linear's Figma files are intentionally "messy." Cursor's Head of Design ships features without creating specs. Anthropic's designers make "state management changes you typically wouldn't see a designer making."

These aren't edge cases or experiments. These are the teams shipping some of the industry's most polished products—and they've fundamentally reimagined what "design" means.

The shift

They've stopped trying to maintain perfect design documentation alongside AI-powered development. Instead, they've accepted that code is the source of truth, roles are fluid, and traditional handoffs are obsolete.

This document shows you how they actually work—with direct quotes from their designers and practical workflows you can adapt.

Table of Contents

Research & Principles

• Part 1: What We Learned from Linear, Cursor, and Anthropic
• Part 2: The 6 Core Principles

Implementation

• Part 3: The Actual Workflow
• Part 4: Documentation Strategy
• Part 5: Working with AI Tools
• Part 6: Communication Protocols

Reality & Transition

• Part 7: The Hard Parts
• Part 8: Making the Transition (12-week plan)
• Part 9: When to Override This Workflow

Evaluation

• Part 10: Measuring Success
• Part 11: A Real Example: The Navigation Conflict
• Part 12: FAQ

Part 1: What We Learned from the Best

Linear: "Design is Only a Reference"

Karri Saarinen, CEO & Co-founder:

"Primer on how we design at @linear: The main point is that the design is only a reference, never any kind of deliverable itself, so the way it's constructed doesn't really matter.

1. We screenshot the app and design on top of
2. Simple design system that has mostly colors..."

What this means:

• Figma files are intentionally "messy" because they're not the deliverable
• They screenshot production and design on top of screenshots
• Code is the source of truth, not Figma
• No design system team, no councils, no meetings about atomic design

On quality and craft:

"We started with quality. Then we learned that people actually noticed, because it's a rare approach—especially for startups."

"Craft is the mindset and activity you do, and the quality and beauty are the output."

Linear's quality doesn't come from perfect documentation. It comes from obsessive iteration on the actual product.

Cursor: Roles Are Muddy, Build with AI

Ryo Lu, Head of Design at Cursor:

"At Cursor, roles between designers, PMs, engineers are muddy. We just do what it takes based on each person's unique strengths and use the AI agent to tie everything together."

"PM jobs are spread across builders at Cursor."

On "vibe coding" and the design process:

"Software creation is almost like sculpting. You get something then you poke at it. Maybe you get rid of certain parts. Maybe you rearrange certain parts. Maybe you say, ah, do it again, again, and again. Do it five times. Pick the right one. It changes completely… you've flipped how you built."

Ryo's 12 Golden Rules for Cursor (key highlights):

1. "Set 5-10 clear project rules upfront so Cursor knows your structure and constraints"
2. "Be specific in prompts. Spell out tech stack, behavior, and constraints like a mini spec"
3. "Work file by file; generate, test, and review in small, focused chunks"
4. "Keep design docs and checklists in .cursor/ so the agent has full context on what to do next"
5. "If code is wrong, just write it yourself. Cursor learns faster from edits than explanations"

Notice what's missing: No mention of maintaining Figma files. Documentation lives in the codebase, where the AI can use it.

Anthropic: Designers Ship Production Code

From "How Anthropic Teams Use Claude Code":

"Product Design team members would feed Figma design files to Claude Code and then set up autonomous loops where Claude Code writes the code for the new feature, runs tests, and iterates continuously."

"Engineers noted they're making 'large state management changes that you typically wouldn't see a designer making', enabling them to tackle more complex work."

Meaghan Callahan (Design Lead for Claude Code):

From her demo and workflow, the key pattern is:

1. Start with Figma mock (if needed)
2. Feed it to Claude Code
3. Build, test, iterate in code
4. Ship directly to production

Top use cases: "0 to 1 explorations, prototyping new features in an existing product, and understanding the codebase."

The theme: Designers as builders, not spec creators.

Part 2: The Principles (Not Rules)

Now that you've seen what Linear, Cursor, and Anthropic actually do, let's extract the underlying principles. These aren't rigid rules to follow blindly—they're principles that should guide your decisions.

Think of them as a compass, not a map.

Principle 1: Code is the Source of Truth

Not Figma. Not documentation. Code.

The actual running product is the ultimate reference. Everything else is temporary scaffolding to get there.

What this means in practice:

• We don't maintain parallel Figma files that "mirror production"
• We don't promise to "update Figma after shipping"
• We accept that Figma will drift from production (this is fine)
• When there's a question about "how does X work?", we look at the code

Why this matters:

Trying to keep Figma and code in sync is like maintaining two separate inventories—it's double work that provides diminishing returns. Linear figured this out: make the screenshot your reference, design on top, implement. Repeat.

Principle 2: Design Through Building

Designing and building are the same activity, not sequential phases.

The old way:

Design → Spec → Handoff → Build → QA → Ship

The new way:

Idea → Build + Design + Test → Ship
(with AI accelerating all of it)

What this means in practice:

• Start building sooner, even if the design isn't "complete"
• Use Cursor/Claude Code to prototype in real code, not Figma
• Discover edge cases by building, not by trying to anticipate them
• Iterate in the actual medium (code), not in simulation (Figma)

As Ryo Lu puts it: "You get something then you poke at it... It changes completely… you've flipped how you built."

Principle 3: Fluid Roles Over Fixed Boundaries

Everyone is a builder. Designers who code. Engineers who design.

At Cursor: "roles between designers, PMs, engineers are muddy."

What this means in practice:

• Designers ship code (frontend polish, animations, UI components)
• Engineers make design decisions (within system constraints)
• No one waits for someone else to "finish their part"
• Collaboration is real-time, not through handoffs

The scary part: This requires trust. You trust that:

• Engineers won't ship ugly UI (because they respect craft)
• Designers won't ship broken code (because they test their work)
• Everyone aligns on quality standards (because it's cultural, not enforced)

Principle 4: Documentation Lives Where AI Can Use It

If AI agents are our collaborators, documentation should be accessible to them.

Ryo Lu: "Keep design docs and checklists in .cursor/ so the agent has full context on what to do next."

What this means in practice:

• Design decisions documented in .md files in the repo
• Component behavior documented in code comments
• Design system rules in a DESIGN_RULES.md file
• Context for AI agents stored where they can access it

Example structure:

/project-root
  /.cursor/
    - design-principles.md
    - component-guidelines.md
    - animation-standards.md
  /src/
    - components/
    - styles/
  README.md

This way, both humans AND AI agents can understand the design intent.

Principle 5: Figma is for Thinking, Not Documenting

Figma is a sketch tool, not a specification deliverable.

Linear: "The design is only a reference, never any kind of deliverable itself, so the way it's constructed doesn't really matter."

What this means in practice:

• Use Figma to explore ideas quickly
• Use Figma to communicate "what if?" scenarios
• Use Figma to get alignment before building
• Don't use Figma as the authoritative record (that's what code is for)

Analogy: Figma is like an architect's napkin sketch. The actual blueprints are the code.

Principle 6: Quality Through Iteration, Not Planning

Karri Saarinen (Linear): "We started with quality."

But Linear's quality doesn't come from extensive planning. It comes from:

• Obsessive attention to detail in the actual product
• Rapid iteration based on real usage
• Willingness to change things even if users push back
• Cultural commitment to craft at every level

What this means in practice:

• Ship something good, then make it great
• Polish in production, not in mocks
• Use real data and real users to guide refinement
• Don't wait for perfect; wait for "proud to ship"

Part 3: The Actual Workflow

Principles are great, but you need to know: "What do I actually do on Monday morning?"

Here's the concrete workflow that emerges when you apply these principles. It's based on patterns we've seen at Linear, Cursor, and Anthropic—adapted into something you can use starting today.

The Core Loop

1. Problem/Idea
   ↓
2. Sketch (Figma, whiteboard, or just talk)
   ↓
3. Build (Cursor/Claude Code with AI)
   ↓
4. Test (in the real product)
   ↓
5. Iterate (back to step 3)
   ↓
6. Ship
   ↓
7. Polish (continue iterating after shipping)

Notice what's missing:

• No "documentation phase"
• No "handoff meeting"
• No "update Figma to match production"

Path A: Simple Changes (The Majority of Work)

Examples: Button polish, spacing tweaks, hover states, micro-interactions, small bug fixes

Workflow:

1. Notice the need (you or someone else points it out)
2. Make the change directly in Cursor/Claude Code
   • For small things, just do it
   • For less obvious things, share a quick preview in Slack first
3. Test it (does it work? does it look good?)
4. Ship it
5. Post what you did (one line in Slack: "Refined the button hover animation on the navigation")

Time: Minutes to hours

No Figma involved. The change is simple enough that coding it is faster than mocking it.

Path B: New Components or Features

Examples: New form pattern, redesigned card, updated navigation section, new feature that fits existing patterns

Option 1: Start in Cursor (if you can visualize it clearly)

1. Build a first version in Cursor/Claude Code
2. Share for feedback (Loom, preview link, screenshots)
3. Iterate based on feedback (2-3 cycles)
4. Document the pattern (add notes to /design-system/components.md)
5. Ship it

Option 2: Start in Figma (if you need to think through states/variations)

1. Quick exploration in Figma (30 min - 2 hours)
   • Core idea + key states (not every pixel)
   • Share for alignment
2. Build in Cursor/Claude Code
   • Feed Figma mock to AI if helpful
   • Or just use it as reference while coding
3. Iterate in code (discover real constraints)
4. Document the pattern (in code repo, not Figma)
5. Ship it

Time: Half day to 2 days

Key insight: The Figma step is for your thinking, not for creating a handoff document. Once you start building, you're iterating in code.

Path C: Complex Multi-Screen Flows

Examples: Complete onboarding redesign, new multi-step process, major feature with backend implications

Workflow:

1. Map the flow (Figma, Miro, or even pen and paper)
   • What are the steps?
   • What are the decision points?
   • What are the error states?
   • Goal: Understand the problem, not create final designs
2. Build a skeleton (Cursor/Claude Code)
   • Get the basic flow working
   • Use placeholder UI
   • Focus on the logic and structure
3. Iterate on the experience (in code)
   • Now add the real UI
   • Test with real data
   • Discover edge cases you didn't anticipate
4. Document the system (in repo)
   • Add a /docs/features/onboarding.md explaining:
     • What problem this solves
     • How the flow works
     • Key decision points
     • Edge cases and how we handle them
5. Ship incrementally (if possible)
   • Can you launch step 1 alone?
   • Get real user feedback before building step 5
6. Polish after shipping
   • Now that it's real, what feels off?
   • Iterate based on actual usage

Time: 1-2 weeks

The Figma work is minimal—just enough to think through the problem. Most of the design work happens while building.

Path D: Urgent Fixes (Move Fast)

Examples: Critical bug, emergency content change, something obviously broken

Workflow:

1. Fix it immediately in Cursor/Claude Code
2. Ship it
3. Tell people what you did (post in Slack after, not before)

Time: Minutes

No permission needed. If it's obviously wrong and obviously fixable, just fix it.

Part 4: Documentation Strategy

Since Figma isn't our documentation, what is?

The Repository as Documentation

Create a /docs folder in your repo:

/docs
  /design-system
    - principles.md          (Core design values)
    - colors.md              (Color system with code values)
    - typography.md          (Type scale and usage)
    - components.md          (Component patterns and when to use them)
  /features
    - navigation.md          (How navigation works, all states)
    - forms.md               (Form patterns and validation approach)
  /decisions
    - 2024-12-why-we-redesigned-nav.md
    - 2024-11-animation-principles.md

What Goes in Documentation

Document the "why" and "what", not the "how":

Good documentation:

• "We use 8px spacing grid because it scales across devices"
• "Navigation collapses on mobile to preserve screen real estate"
• "Error states use orange (#FF6B35) to differentiate from destructive actions (red)"
• "Forms validate on blur, not on keystroke, to reduce anxiety"

Bad documentation:

• Pixel-perfect specs of every state
• Exhaustive lists of every component variation
• Screenshots that will be outdated next week

The rule: If AI or a new teammate needs to understand the system, document it. If they can figure it out by looking at the code, don't.

Design System in Code

Your design system lives in code, not Figma.

Example: Button Component

Instead of a Figma frame with 12 button variants, you have:

// Button.tsx
/**
 * Primary button for main actions
 * Use sparingly - typically one per screen
 * Examples: "Save", "Submit", "Continue"
 */
export const Button = ({ variant = "primary", ... }) => {
  // implementation
}

This is your design system. The code IS the documentation.

Part 5: Working with AI Agents

Since AI agents are our collaborators, we need to set them up for success.

The .cursor/ Folder

Create a .cursor/ folder with context for AI:

.cursor/design-rules.md:

# Design Rules for Our Product

## Core Principles
- We prioritize speed and clarity over decoration
- Every interaction should feel immediate (< 100ms feedback)
- We use subtle animations (200-300ms) for state changes
- Color is used sparingly to draw attention

## Component Guidelines
- Buttons have 12px padding, 8px border radius
- Cards have 1px border, 12px radius, subtle shadow
- Forms validate on blur, show errors below inputs
- Navigation icons are 20px, labels are 14px medium

## Do NOT
- Use animations longer than 500ms
- Add loading states for actions under 200ms
- Create custom components without checking existing ones first
- Ship without testing error states

## Current Focus
[Update this regularly with what the team is working on]
- Improving form validation UX
- Standardizing empty states across the product

.cursor/coding-standards.md:

# Coding Standards

## Tech Stack
- React + TypeScript
- Tailwind CSS for styling
- Framer Motion for animations
- Radix UI for accessible primitives

## File Structure
- Components in /src/components
- Styles scoped to components (no global CSS)
- Tests alongside components (Button.test.tsx)

## Naming Conventions
- Components: PascalCase (Button.tsx)
- Utilities: camelCase (formatDate.ts)
- CSS classes: kebab-case (via Tailwind)

Why this works: When you start a Cursor/Claude Code session, the AI reads these files and understands your system. It's like onboarding a new team member—but instant.

Prompting Best Practices (from Ryo Lu)

Be specific: "Add a hover state to the navigation buttons. Use scale: 1.02 and opacity: 0.8. Transition should be 200ms ease-out. Test with all button variants."

Not: "Make the buttons look better."

Work file by file: Don't ask AI to change 10 files at once. Do one component, test it, then move to the next.

Use @ mentions: "@Button.tsx - Add loading state with spinner. @icons/Spinner.tsx - Make sure spinner respects button size variant."

Review everything: AI makes mistakes. Always read the code it generates. If it's wrong, just fix it yourself—AI learns from your edits.

Part 6: Communication Protocols

This might be the most important section in the entire document.

You can have the perfect tools and workflow, but if your team doesn't communicate well, everything falls apart. The freedom of AI-native workflows only works when everyone knows what everyone else is doing.

Here's how to prevent chaos:

Daily Standup (Async in Slack)

Post what you're working on:

Good update: "Today: Building the new empty state for project lists. Will have a prototype by EOD."

Great update: "Today: Building the new empty state for project lists. Started with quick Figma sketch (shared in thread), now building in Cursor. Question for team: should empty states have CTAs or just be informational? Working prototype here: [link]"

Before Starting Major Work

Post your intention:

"Planning to redesign the navigation this week. My approach:

1. Screenshot current nav and explore options in Figma (today)
2. Build prototype in Cursor (Tues-Wed)
3. Test with team and iterate (Thurs)
4. Ship Friday if we're happy with it

Feedback welcome—especially on step 1."

This gives people a chance to say:

• "Wait, I'm already working on something related"
• "Have you considered X?"
• "Let me help with Y"

When Changing Existing Designs

If there are existing specs (Figma or docs):

❌ Bad: "I'll just build my version and see what people think"

✅ Good: "Hey @designer, I reviewed your specs and have some ideas for modifications. Here's what I'm thinking and why: [reasoning]. Should I build a variant for comparison, or do you feel strongly about the original approach?"

The template for communicating deviation:

@[designer] I reviewed your [feature] specs/prototype.

I'm thinking of trying [X, Y, Z] instead because:
- [Reasoning 1]
- [Reasoning 2]
- [Reasoning 3]

Options:
A) I can build a variant and we compare both
B) We stick with your original design
C) We collaborate on a hybrid approach

What do you think? Want to discuss as a team?

This message:

• ✅ Shows you reviewed their work
• ✅ Explains your reasoning
• ✅ Offers options (not just overriding)
• ✅ Invites collaboration
• ✅ Opens the door to team discussion (not just designer's decision)

After Shipping

Post what you shipped:

"Shipped: Refined navigation collapse animation. Changes:

• Reduced animation time from 400ms → 250ms (felt more snappy)
• Icons now fade out instead of disappear (smoother)
• Avatar stays at bottom (more consistent)

Preview: [link] Code: [PR link]"

This serves as:

• A changelog for the team
• Documentation of what changed and why
• A forcing function to articulate your decisions

Part 7: The Hard Parts (Let's Be Honest)

Everything up to this point probably sounds exciting or terrifying—maybe both. Now let's talk about what we've been avoiding: the uncomfortable truths that make this workflow difficult.

Most articles skip this part. We won't. If you're going to adopt this workflow, you need to know what you're signing up for.

Hard Truth #1: Figma Files Will Be Messy and Out of Date

Linear accepts this. Their Figma files are "messy" because they're not the deliverable.

How to handle it:

• Don't try to keep Figma updated post-ship
• Archive old files regularly
• When starting new work, screenshot production and design on top
• Accept that Figma is temporary, code is permanent

The mindset shift: Figma is a whiteboard, not a filing cabinet.

Hard Truth #2: You Need to Trust Your Team

This workflow requires high trust:

• Trust that designers won't ship broken code
• Trust that engineers won't ship ugly UI
• Trust that people will ask for help when needed
• Trust that everyone cares about quality

If trust is low, this won't work. You'll need more process, more approvals, more handoffs.

Building trust:

• Start with small experiments (let someone ship one small feature end-to-end)
• Review work with curiosity, not criticism ("What were you thinking here?" vs "This is wrong")
• Celebrate when people ship good work independently
• Fix mistakes together, not with blame

Hard Truth #3: Roles Will Feel Uncomfortable at First

For designers: You're now responsible for code quality, not just visual design. Scary!

For engineers: You're now making design decisions, not just implementing specs. Scary!

This discomfort is growth.

Linear, Cursor, and Anthropic didn't start with perfectly fluid roles. They built that culture over time by:

• Hiring people willing to learn beyond their discipline
• Celebrating "design engineers" and "engineer designers"
• Having designers and engineers pair on work
• Making quality everyone's job, not just design's job

Hard Truth #4: Some Features Still Need Upfront Design Work

Not everything can be "vibe coded."

Complex flows with multiple stakeholders, legal requirements, or backend dependencies still need upfront thinking.

The difference: That upfront work is about understanding the problem and aligning on approach, not creating pixel-perfect mocks.

Pattern:

1. Map out the flow (rough)
2. Identify the hard questions (data, permissions, edge cases)
3. Answer those questions with product/engineering
4. THEN start building

But most features aren't this complex. Don't over-plan the simple stuff.

Hard Truth #5: This Requires Skill Investment

Designers need to learn:

• Enough code to ship frontend changes confidently
• How to prompt AI effectively
• How to debug when things break
• How to think in components and systems

Engineers need to learn:

• Design fundamentals (spacing, hierarchy, color, typography)
• How to recognize "good enough" vs "needs design input"
• When to ask for help vs figure it out
• How to use Figma (at least to view designs)

This is time-intensive. But it's an investment that compounds.

Resources:

• Pair programming/designing sessions
• Internal workshops on Cursor/Claude Code
• Design system documentation
• Code review with teaching mindset

Part 8: Making the Transition (A 12-Week Plan)

The biggest mistake teams make: Trying to flip a switch from old to new overnight.

You can't. Your team has muscle memory built over years. You need to retrain those muscles gradually.

Here's a realistic 12-week transition plan:

🚀 Phase 1: Experiment (Weeks 1-4)

Goal: Get comfortable with the new tools and mindset

Actions:

• Designers: Ship 2-3 small features entirely in Cursor (spacing tweaks, hover states, UI polish)
• Engineers: Take 2-3 design decisions without waiting for specs (within system guidelines)
• Everyone: Start using .cursor/ folder for design documentation

Success metric: At least 3 features shipped without traditional Figma → Engineering handoff

📋 Phase 2: Codify (Weeks 5-8)

Goal: Establish the new patterns and document them

Actions:

• Create /docs/design-system folder with core principles
• Write .cursor/design-rules.md with team input
• Have a retrospective: What's working? What's scary? What's unclear?
• Refine the workflow based on learnings

Success metric: New team member could read docs and understand how to work

✅ Phase 3: Default (Weeks 9-12)

Goal: Make the new workflow the default, not the exception

Actions:

• Stop maintaining master Figma files (archive them)
• Start all new features with "code or sketch?" decision, not "start in Figma"
• Celebrate examples of great AI-assisted work
• Address remaining friction points

Success metric: The team naturally uses the new workflow without forcing it

🔄 Phase 4: Optimize (Ongoing)

Goal: Continuously improve based on what you learn

Actions:

• Monthly retrospectives on what's working
• Update documentation as the product evolves
• Share learnings across the team
• Stay current with AI tool improvements

Part 9: When to Override This Workflow

This workflow isn't dogma. Here's when to deviate:

Use More Figma When:

• You're redesigning a core flow and need stakeholder alignment
• You're exploring multiple drastically different directions
• You're working with external partners who expect Figma deliverables
• The feature is SO complex that sketching saves significant build time

Use Less AI When:

• You're working on something novel that AI doesn't understand well
• You're debugging a subtle interaction that needs manual control
• You're optimizing performance where AI-generated code is inefficient
• You just want to code something yourself because you enjoy it

The principle: Use the right tool for the job, and be able to articulate why.

Part 10: Measuring Success

How do you know if this workflow is actually better?

Velocity Metrics

• Time from idea to shipped: Should decrease significantly
• Number of features shipped per week: Should increase
• Time spent in "handoff" or "waiting": Should approach zero

Quality Metrics

• Design consistency: Should improve (because designers can fix inconsistencies directly)
• Bug rate: Monitor carefully (if it increases, we need more testing)
• User satisfaction: The ultimate measure

Team Health Metrics

• Designer satisfaction: Do designers feel empowered or sidelined?
• Engineer satisfaction: Do engineers feel trusted or overwhelmed?
• Collaboration quality: Are people working together or in silos?

Cultural Metrics

• Learning & growth: Is everyone expanding their skills?
• Ownership: Do people take end-to-end responsibility?
• Quality pride: Is the team proud of what they ship?

Part 11: A Real Example: The Navigation Conflict

Let's make this concrete with a real story from our team.

This isn't hypothetical - it actually happened between Seb and Paulius (both designers), and it perfectly illustrates why the principles in this document matter.

The Story

Seb spent time creating detailed navigation specs in Figma - pixel-perfect screens, detailed behaviors, all the work you'd expect. But he never posted about it. No Slack message, no WIP update. The specs just lived quietly in the master Figma file.

Meanwhile, Paulius was asked to work on improving the navigation. He looked at the live product, saw room for improvement, and built it in Cursor. He made his own decisions about icons, avatar placement, and collapse behavior. Then he posted in the public channel:

"Hey team! Just pushed my first PR. Would love your feedback on what could be better next time."

Seb was in that channel. He saw the message. He said nothing.

Paulius shipped to staging. Posted the link. The team tested it.

When Seb saw it, he was frustrated. All his work felt wasted. He later wrote: "I'm wondering if my work has any value here."

Paulius was confused: "We're naturally defaulting to how we worked before Cursor."

What actually happened:

• Seb worked silently → Paulius had no way to know
• Paulius posted publicly → Seb had a chance to speak up but didn't
• Both felt hurt and misunderstood

The Deeper Issue

In the follow-up discussion, Seb said something revealing:

"yeah our role is definitely changing, I just want to control it a bit 😬"

There it is. This wasn't just about communication. It was about control.

Traditional workflow:

• Designer creates comprehensive specs
• Specs get "approved" before implementation
• Designer maintains control over the final output
• Changes go through the designer

AI-native workflow:

• Anyone can prototype and ship
• Iteration happens in code, not Figma
• Control is distributed
• Speed sometimes trumps perfect alignment

Seb's desire to "control it a bit" is completely understandable. But it's fundamentally at odds with AI-native workflows.

You can't have both tight design control AND rapid AI-assisted iteration.

This isn't a process problem. It's an identity and role anxiety problem.

What Should Have Happened

Two simple messages would have prevented everything:

Seb, when starting work: "Hey team! Starting exploration on navigation improvements. Main focus: collapse behavior, icon states, avatar placement. Will share as I go. 🧵"

OR, when he saw Paulius's post: "@paulius Hey, I've actually been working on navigation specs! Just saw your post. Want to sync up? I have explorations in Figma we could review together."

Paulius, before building: "Hey team! Looking at current navigation and seeing some UX opportunities: avatar at bottom, faster animation, icon visibility when collapsed. Planning to build in Cursor and test in staging. If anyone's working on nav or has concerns, lmk!"

Either message would have created coordination instead of conflict.

The Lesson

The AI-native workflow requires two types of public communication:

1. "I'm starting work on X" → Claims the work, prevents duplicates
2. "I'm changing X because Y" → Explains intent, invites discussion

Both were missing here.

But the deeper lesson is about control:

Traditional designers had authority through gatekeeping. AI-native designers have influence through collaboration.

That's not a downgrade - it's a different skill. But it requires letting go of control, trusting the team, and accepting that others can ship too.

If you want tight control over every design detail, the AI-native workflow will frustrate you.

If you want speed, iteration, and collaborative quality, you have to embrace distributed authority.

The choice is yours. But you can't have both.

Part 12: FAQ

"What if I'm a designer who doesn't want to code?"

Short answer: This workflow will be challenging for you.

Long answer: You don't need to be a senior engineer, but you need to be comfortable enough with code to:

• Ship frontend changes (HTML, CSS, basic React)
• Use AI tools like Cursor to build prototypes
• Understand what's technically easy vs hard
• Communicate with engineers in their language

If you're unwilling to learn these skills, you'll increasingly find yourself in a support role rather than a driver role.

The good news: AI makes learning to code much easier. You can build real features even as a beginner.

"What if I'm an engineer who doesn't care about design?"

Short answer: You need to start caring, or find a team with traditional roles.

Long answer: At AI-native companies, engineering is design. You can't say "just tell me what to build" when there's no one creating comprehensive specs.

You need to develop:

• An eye for quality (spacing, alignment, typography)
• Understanding of design systems
• Willingness to ask "does this look good?" before shipping
• Respect for craft

The good news: You don't need to be a world-class designer. You need to be good enough to maintain quality within an existing system.

"What if this breaks everything and we ship terrible products?"

Valid fear. Here's how to mitigate:

1. Start small: Experiment with low-risk features first
2. Maintain quality bar: Just because you CAN ship without review doesn't mean you SHOULD
3. Use feature flags: Ship to internal users first, then gradually roll out
4. Have design reviews: Not before every feature, but regularly to catch drift
5. Empower anyone to say "this isn't good enough"

Remember: Linear, Cursor, and Anthropic ship high-quality products with this approach. It works if the culture supports it.

"How do we onboard new people to this workflow?"

Week 1: Observe

• Shadow someone shipping a feature end-to-end
• Read the /docs folder
• Set up Cursor/Claude Code and experiment

Week 2: Pair

• Work with someone on a real feature
• Ask lots of questions
• Ship something small with guidance

Week 3: Solo (with support)

• Take on a small feature alone
• Post your approach before starting
• Ask for review before shipping

Week 4: Independent

• Ship features normally
• You're now part of the rotation

"What if our Figma files are our competitive advantage?"

They're not.

Your competitive advantage is:

• The quality of the product people actually use
• How fast you can iterate based on feedback
• The taste and judgment of your team
• The system you've built (in code)

Perfect Figma files are nice internally, but users never see them. They see the product.

"This sounds like chaos. Where's the structure?"

The structure is in:

• Clear design system (in code)
• Documented principles (in /docs)
• AI context (in .cursor/)
• Communication protocols (in Slack)
• Cultural commitment to quality

What's removed is:

• Mandatory handoffs
• Separate documentation systems
• Rigid role boundaries
• Process for process's sake

Less process, more principle.

Closing Thoughts

This workflow is uncomfortable because it's new. Traditional design processes evolved over decades. Everyone knows their role.

AI-native workflows are still emerging. We're figuring it out in real-time.

But the companies leading this transition—Linear, Cursor, Anthropic—are shipping exceptional products. They're moving faster, maintaining quality, and empowering their teams in new ways.

The core insight:

Code is the source of truth. Roles are fluid. AI is the accelerant. Quality comes from iteration, not planning.

The tension on your team wasn't a failure—it was a signal. A signal that you're outgrowing traditional workflows.

This document is a proposal for how to evolve, inspired by the teams doing it best.

It won't be perfect on day one. You'll adapt it to your context. But the direction is clear:

Less documentation. More building. Faster iteration. Higher quality.

Next Steps

1. Discuss as a team - What resonates? What feels scary?
2. Try one experiment - Ship a small feature using this workflow
3. Iterate the workflow - This is v2.0, not the final answer
4. Share learnings - We're all figuring this out together

The future of design is being written right now.

Linear is writing it. Cursor is writing it. Anthropic is writing it.

Now it's your turn.

Resources

From Linear

• Karri Saarinen on Craft and Quality
• How We Redesigned the Linear UI
• Karri's thread on how Linear designs (search X/Twitter: @karrisaarinen "design is only a reference")

From Cursor

• Ryo Lu's 12 Golden Rules for Cursor
• Full Tutorial: Design to Code with Cursor's Head of Design
• Dive Club: Designing the Future of Cursor with Ryo Lu

From Anthropic

• How Anthropic Teams Use Claude Code
• Claude Code: Best Practices for Agentic Coding
• Meaghan Callahan Demo: From Design to Code

On Design Engineering

• Vercel: Design Engineering at Vercel
• Adobe: Should You Pursue Design Engineering?
• Design Engineer Job Board

Version 2.0 | December 2025

Built with insights from Linear, Cursor, Anthropic, and your team's real experiences.

This is a living document. Fork it, adapt it, make it yours.