The AI-Native Design Playbook

This article is based on the English original.

Over the past month, Buzzvil’s design team shipped five web applications and made 344 commits. Remarkably, Figma was barely involved. There were no engineering sprint allocations, handoff tickets, or long waits.

This is an account of how we got here. It is for product teams, designers, PMs, and engineers who will soon encounter the same wall. The old loop of mockups and handoffs has become the slowest part of the system, and the tools that supported it no longer match the pace of the work.

Why the old loop broke

Jenny Wen, Anthropic’s head of design and formerly a design director at Figma, described it on Lenny’s Podcast in March 2026:

“When an engineer is running seven coding agents simultaneously and ships a working version before a designer has even explored the options, the traditional explore–diverge–converge loop no longer works.” ¹

The data from 2025–2026 supports that observation:

• 51% of code committed to GitHub was generated or assisted by AI. ²
• AI-assisted engineers completed 21% more tasks per person, while PR creation jumped 98%. ³
• Median PR size increased 33%, and PR review time rose 91%. ³

When engineers move this quickly, every step premised on “we can build it once the designer finishes the mockups” becomes a bottleneck. At Anthropic, the team watched designers’ time allocation change in real time.

Type of work	Before	Now (AI-native)
Mockups and prototyping	60–70%	30–40%
Pairing with engineers (jamming)	About 20%	30–40%
Communication and coordination	About 10%	Shrinking
Implementing directly in code	0%	A new category

Designers’ time has shifted into two new modes: supporting execution—advising engineers as they build, giving feedback, and refining the code directly—and setting near-term direction, with strategies spanning three to six months rather than multiyear roadmaps. ¹

At Buzzvil, we took this a step further. I no longer make mockups. I write user stories instead, on paper or in a text file. I spell out the product intent, constraints, and success criteria. Then I implement directly with Claude Code or delegate the work to an agent.

The time once spent refining pixels now goes into thinking carefully about what should exist and why. Visual results arrive much faster and much closer to production. The center of gravity of creative work has moved upstream: well-written user stories, sharp constraints, and decisions about what to leave out.

One designer working this way can produce what previously kept a designer and frontend engineer busy for an entire sprint. The question is no longer “Can we build it?” It is “Should we build it?”

“Doesn’t AI design all look the same?”

This is the concern we hear most often. Until early 2025, it was fair. An unconstrained LLM tends toward the statistical average of its training data. When intent is vague, the model fills the gaps with the most familiar layouts and predictable styles.

The answer is a well-designed environment: harnessing. Tools such as design.md have shown that brand voice, visual language, and component constraints can be encoded directly into an agent’s context. CLAUDE.md files, design skills, and hooks together create a design environment in which the agent can produce work that belongs to the brand.

At Buzzvil, we have put the following into production:

• Brand and design skills: Claude Code skills encode our visual language, including brand guidelines and the OKLCH color system, and enforce it during generation.
• An internal UI library for LLMs: @buzzvil/design-library is structured so agents can assemble the right tokens and components accurately. It is used in more than five repositories and has been validated against 60 brand × recipe combinations.
• Hooks that enforce consistency: These check Biome lint rules, spacing conventions, and more. Hardcoded colors are blocked before they reach a commit.

A designer using AI without a prepared environment gets ordinary results. Designing the environment is now a core part of the job. Define the constraints and encode the brand, and AI can finally produce your design.

Separating discovery from delivery

For a long time, discovery and delivery lived in the same design tool. We explored in Figma, presented in Figma, and handed off in Figma. Intent changed; the tool did not. That made the two modes hard to distinguish.

AI coding agents make the distinction explicit. When a designer can build a working prototype in hours, the question changes from “Which Figma file is this?” to “Am I exploring, or am I shipping?”

Marty Cagan draws a clear boundary: discovery is building to learn, and delivery is building to earn. ⁴ Discovery tests four risks: value, usability, feasibility, and viability. Delivery validates scalability, performance, reliability, security, and everything else required for a product customers can trust. Both are called validation, but they mean very different things. When building was expensive, this distinction was largely the PM’s domain. Now that a designer with an agent can make a working prototype in hours, the discovery loop is open to everyone who builds.

Discovery: building to learn

Discovery artifacts are disposable. Their purpose is to answer a question, not to ship. A prototype that fails to demonstrate value has still done its job. A Figma exploration that makes the wrong direction obvious has saved weeks.

Figma remains useful for spatial exploration. As Jenny Wen points out, a single canvas lets you lay out eight to ten directions and compare them simultaneously. Code-based tools are linear: it is easy to become absorbed in one direction and fall into sunk-cost thinking. ¹ Use Figma when you need to compare several directions side by side, show stakeholders options before deciding, or explore a brand or visual identity.

Code prototypes have also become practical discovery tools. A quick Claude Code prototype can reach users within hours, with real data, real interactions, and real responsive behavior—without an engineering ticket.

Delivery: building to earn

Delivery assumes that a direction has been validated, or that there is enough evidence to proceed. The work must now meet production standards: scalability, reliability, accessibility, token compliance, and responsive behavior.

The delivery loop looks like this:

1. Write the intent. Capture the validated direction as a user story, a set of constraints, or a statement of what is needed and why. Paper works. Markdown works. Precision matters more than format.
2. Build in code. Open Claude Code, describe what you want, and iterate until you are satisfied. The agent uses your tokens, components, and standing orders.
3. Open a PR. Push the branch, explain what changed, and request a review.
4. Review and merge. Design review checks visual quality; engineering review checks correctness. It is one process.
5. Deploy. Vercel deploys when the change is merged.

The entire loop, from intent to production, can take hours. The designer opens the PR directly. There is no handoff.

During delivery, Figma is the wrong tool across the board: for making components, tokens and code are the source of truth; for page layouts, building directly is faster; for specification handoff, the designer opens the PR; and for responsive design, a canvas cannot reproduce real responsive behavior.

Five layers of harness

An AI coding agent behaves like a fast, tireless junior developer: talented, but in need of structure. SmartScope reports that projects with well-structured agent context files reduce median execution time by 29% and token consumption by 17%. ⁵

We run five layers.

1. Standing orders (CLAUDE.md). A Markdown file at the root of every repository, read at the start of every agent session. It contains project context, coding conventions, patterns, things to do and never do, file structure, and naming rules. Encoding one convention here can save hundreds of future corrections.

2. Skills. Reusable playbooks for recurring work. Buzzvil has skills for publishing SDK documentation, following brand guidelines, generating illustrations and icons, applying dashboard design patterns, and writing blog posts. A skill tells the agent how to approach a category of work. It takes know-how that might otherwise remain in someone’s head and makes it explicit.

3. Memory. Persistent notes the agent carries between sessions: patterns confirmed through repeated interactions, architectural decisions, and user preferences. It is accumulated organizational knowledge.

4. Permissions. An allowlist that separates what the agent can do autonomously from what needs human approval. File writes, git operations, and external API calls each have explicit permission levels.

5. Hooks. Checks that run automatically at specific events: before a commit, after a file write, or at session start. Buzzvil uses hooks to enforce Biome linting and formatting, TypeScript checks, spacing conventions, and warnings about destructive operations.

The principle is simple: quiet on success, loud on failure. The agent works freely inside the guardrails. When it reaches a boundary, it stops and asks.

Anthropic calls verification its “highest-leverage tip”: giving an agent a way to check its own work dramatically improves quality. ⁶ If you take only one thing from this article, take this: set up hooks that verify before committing. Everything else compounds on top of that.

Tokens as a shared language

A design system is not a Figma library to consult. It is the material the interface is made from.

Every color, spacing value, typography scale, and shadow at Buzzvil exists as a semantic CSS variable generated in the OKLCH color space. The system has three layers:

1. Primitives: raw values—OKLCH lightness, chroma, and hue.
2. Semantic: names that express intent, such as action-primary, surface-default, and text-muted.
3. Component: names tied to specific elements, such as button-bg and card-border.

An agent uses semantic tokens to build a page and component tokens to build a component. With a systematic environment around it, a hardcoded value naturally looks out of place.

Aligning design tokens and code tokens is UX Collective’s first prerequisite for an AI-native design workflow: ensuring that “MCP Server, Claude Code, and Codex CLI speak the same design language.” ⁷ Indeed’s Diana Wolosin tested eight MCP configurations with 1,056 prompts and found that JSON used 80% fewer tokens and cost five times less than prose documentation. ⁸

Principles, recipes, and guidelines

Agents need three layers of direction when assembling an interface.

Principles are non-negotiable constraints. “Never use red as a background color.” “Every interactive element has a touch target of at least 44px.” “Use Noto Sans KR for Korean.” These do not change with context.

Recipes are proven patterns for known contexts. “Campaign interactions follow Hook → Challenge → Reward → Offer.” “Advertiser landing pages open with trust signals, then case studies, then a CTA.”

Guidelines are detailed rules: tone of voice, token usage, spacing conventions, and animation timing. They are the fine-grained knowledge that prevents drift.

At Buzzvil, these map to:

• Principles → CLAUDE.md, the repository’s standing orders
• Recipes → skills and component patterns
• Guidelines → design tokens, brand guidelines, and hooks

Cristian Morales Achiardi of Design Systems Collective describes this as a transition toward “agentic design systems”: systems that detect and report drift and autonomously suggest corrections. ⁹ The design system is becoming structured knowledge that agents consult and assemble, rather than a Figma library people read.

What changes for PMs and engineers

Your team’s designer no longer hands you mockups. You will also be shipping UI changes directly.

AI coding agents let anyone on a product team create and modify interfaces: a PM prototyping a flow, an engineer adjusting a layout, or a data analyst adding a dashboard view. With a design system, tokens, and a harness underneath, the output is structurally sound regardless of who authored it.

What changes is the collaboration model—specifically, who reviews what.

Do not wait for specifications. The designer may ship a working version before you have even reviewed the Figma file. Review the pull request instead.

You can ship UI too. Engineers and PMs with access to a design system and AI agents can make UI changes themselves. Use the tokens and components, and open a PR.

Designers review your UI. When you ship an interface change, the designer becomes the reviewer responsible for visual quality, consistency, and user experience. This mirrors engineering code review: you review their logic; they review your interface. A designer does not have to write the code to be accountable for its quality.

Design feedback happens in code. Comment on PRs, suggest changes, and iterate together on branches, just as you would review any other contribution.

The design system belongs to all of us. Tokens, components, and patterns are the contract that holds everyone’s output together. Your token change affects the designer’s work; a component they add becomes available to you immediately.

Quality gates are automated. Hooks catch structural issues such as linting, type checks, and formatting. Human review focuses on areas that require judgment: product fit, visual quality, and user experience.

The boundary between who writes markup and who writes logic is now permeable. The design system is what holds the team’s work together across it.

Which designers thrive?

Jenny Wen identifies three types of designer who thrive in this workflow. ¹ We use the same framework in hiring.

1. Full-stack generalists. Rather than a traditional T shape—deep in one area and shallow elsewhere—these designers operate at roughly 80% across several core capabilities: research, visuals, prototyping, product thinking, and light coding. As design extends into PM and engineering territory, people who move comfortably between domains absorb this change naturally.
2. Exceptional specialists. People in the industry’s top 10% in one area: visual design, motion, typography, illustration, or highly technical design close to engineering. When everyone can produce something reasonably good, these are the people who make it special.
3. Adaptable newcomers. Early-career designers who are humble, technically curious, and already building in code. Jenny makes a counterintuitive point: people without entrenched habits or attachments to existing processes can have an advantage when those processes change quickly. Without the muscle memory of a Figma-centered workflow, they have less to unlearn.

Adaptability is the common thread. The process is changing too quickly for an attachment to any one tool or method to keep up; that attachment has become a liability. Judgment, speed, and evidence of working in code are stronger preparation than a portfolio full of polished case studies.

Measuring output and keeping tempo

If designers ship through PRs, measure PRs.

Buzzvil tracks the number of PRs opened by the design team as a team metric. This is new for us; we have not found another design team using PR count this way. It answers one question directly: Are designers actually shipping, or are they still handing work off?

The trend matters more than the number. Weekly PR counts should rise, and the range of contributors should broaden.

Tempo is another challenge. AI makes individuals faster. Without a shared rhythm, that speed creates confusion. A team shipping twenty PRs a day without coordination is producing noise, not productivity.

Standups assume tasks take days. Sprint planning assumes two-week units. Design reviews assume one direction per week. When an individual can ship several features in a day, those rhythms are too slow for coordination and too frequent to be useful. We rebuilt our cadence around what AI-assisted work actually produces: commits, PRs, and measured output.

• Daily, asynchronous, artifact-based. No standups. Commits and open PRs make the work visible. The output is the status update.
• Weekly, automatically generated reviews. Progress reports come from the git logs of active projects. “What did you do this week?” becomes an evidence-based discussion. Dependencies become visible too: a commit to the interaction library affects the design library documentation, which in turn affects SDK documentation.
• Monthly stakeholder alignment. One-to-ones with the people who use the design team’s output. These are alignment checks, not status reports.
• Quarterly reviews using directly counted results. We count outputs such as merged PRs and published pages directly. The conversation focuses on what those numbers mean.

This cadence serves two purposes. For individuals, it creates checkpoints: moments to step back from the daily pace of AI-assisted work and ask whether the direction is still right. For the team, it creates cohesion: confidence that, even while shipping independently, we are still building one product.

AI accelerates individual output. Tempo brings it together.

Where this is heading

Christopher Alexander described this pattern long before it reached software. In The Timeless Way of Building (1979), he argued that enduring quality comes from a shared pattern language: a living system of rules anyone can use to create coherent, beautiful results. ¹⁰ When the patterns are right, the building takes care of itself. When the language is shared, a system can scale without losing its soul.

Alexander’s insight crossed from architecture into software, inspiring design patterns, wikis, and eventually design systems. It is crossing again. AI agents are a new kind of builder—faster and more tireless than any before them, but only as good as the patterns they are given. Designing those patterns is our role.

Teams that design the environment, ship tokens, and open PRs themselves will define how products are built. Teams still waiting for the next Figma file will wonder where the month went.

I have published the full playbook separately, with more sources and a deeper explanation of the environment. This article is the shorter version for teams considering the transition.

Footnotes

1. Jenny Wen, "The design process is dead. Here's what's replacing it." Lenny's Newsletter/Podcast, March 2026. lennysnewsletter.com ↩ ↩² ↩³ ↩⁴

2. Chris Roth, "Building An Elite AI Engineering Culture In 2026." cjroth.com ↩

3. Greptile State of AI Coding Report / Index.dev, cited in "When product managers ship code: AI just broke the software org chart." dataworldbank.net ↩ ↩²

4. Marty Cagan, "Build to Learn vs Build to Earn." Silicon Valley Product Group, April 2026. svpg.com ↩

5. "AGENTS.md Optimization: 5x Performance Boost for AI Coding Agents." SmartScope. smartscope.blog ↩

6. "Claude Code power user tips: Verification." Anthropic Help Center. support.claude.com ↩

7. "Building AI-driven workflows powered by Claude Code and other tools." UX Collective. uxdesign.cc ↩

8. "Your Design System Is Not Ready for AI Agents." Into Design Systems. intodesignsystems.com ↩

9. "Towards an agentic design system." Cristian Morales Achiardi, Design Systems Collective. designsystemscollective.com ↩

10. Christopher Alexander, The Timeless Way of Building (Oxford University Press, 1979). ↩