Not long ago I built a small app to help designers rehearse the conversations they dread: the “I disagree with this roadmap” talk, the “I need to renegotiate this deadline” talk. Somewhere in the build I hit a fork I couldn’t design my way around. Do I reward people for showing up to practice, with a streak and a satisfying green check, or for actually doing the uncomfortable reps, the halting, awkward, say-it-out-loud part that makes the real conversation easier later?

Those are not the same product. And I had a bad feeling I knew which one people would open every day.

Andrej Karpathy would have an opinion about my fork. This year he, the person who taught a generation of us neural networks from scratch one hand-derived gradient at a time, quietly joined Anthropic’s pretraining team. Not agents. Not the demo-friendly layer everyone’s pitching. Pretraining: the slowest, least glamorous grind at the very bottom of the stack. It’s a fitting move for someone who keeps insisting that real learning is slow and painful, that you should want the mental equivalent of sweating, close the “Learn X in 10 minutes” tabs, and seek the meal instead of the snack.

I agree with all of it. I’d also just spent weeks building something that, done wrong, would let designers fake the sweat.

So which is it?

The feeling of learning is not the learning

Here’s the uncomfortable part: Karpathy isn’t just being a purist. The cognitive science backs him almost embarrassingly well.

In the early ’90s, the psychologists Robert and Elizabeth Bjork named a paradox they’d been chasing for years: the conditions that make learning feel smooth and productive in the moment are often the ones that produce the weakest long-term memory. They called the good kind of hard “desirable difficulties,” things like spacing your practice out, testing yourself instead of rereading, and mixing topics so your brain has to work to tell them apart. Every one of these feels worse while you do it. Every one of them wins on the delayed test.

Their sharpest insight is that performance during learning and actual learning are not the same thing. They can even move in opposite directions. When material flows easily, you feel fluent, and you mistake that fluency for mastery. Elizabeth Bjork’s line stays with me: forgetting is the friend of learning. The struggle to drag something back out of your memory is the thing that strengthens it.

That’s Karpathy’s “sweating,” dressed in a lab coat. The feeling of learning is a trap.

But Duolingo isn’t the villain in this story

Here’s where the “close the tabs, seek the meal” crowd loses me a little.

If you actually look under Duolingo’s candy shell, its engine is desirable difficulty. Spaced repetition. Retrieval practice: recall, not recognition. Interleaving across lesson types. The green owl smuggled decades of memory science into a format that feels like a game. The bite-sized packaging isn’t the enemy of hard learning; in the best case, it’s the delivery mechanism.

And it solves the one problem Karpathy’s advice quietly assumes away: showing up. Slow, painful learning only compounds if you keep doing it, and the failure mode for most adults isn’t that the textbook is too easy. It’s that the textbook is closed. A streak is a commitment device wearing a cartoon costume.

So where does it actually fail? Right where the reviews land in 2026: learners plateau around A2 to B1, and the app’s progress metrics quietly overstate how much they know. People “game the app,” chasing the streak, tapping through the easy path, mistaking a 1,000-day counter for conversational French. The candy shell starts eating the medicine. The moment the streak becomes the goal instead of the scaffold, it stops measuring learning at all. Goodhart’s law, in a fifteen-second dopamine loop.

What this means for the products we make

I don’t think the design lesson here is “make things harder.” It’s more precise, and more useful, than that:

Know which friction is load-bearing.

Every product decision about learning, and increasingly about work, is a decision about which difficulty to preserve and which to remove. Removing friction is our whole job, right up until we remove the friction that was doing the learning. So before you smooth something out, run a quick audit:

1. What’s the real outcome, and what’s the proxy you’re actually optimizing? (Fluency, or streak length?)

2. Which friction produces that outcome, and which is just annoying? Effortful recall is load-bearing. A confusing settings menu is not.

3. Is your engagement loop serving the outcome, or quietly replacing it?

4. The honesty test: does your progress metric track the thing, or the feeling of the thing?

If that sounds abstract from your day, look at where AI tooling is right now. Karpathy, again, is the one calling much of “vibe coding” what it is: a fast path to confident slop. The same trap, one level up. These tools make the feeling of productivity nearly free, and the temptation is to optimize for that feeling instead of the competence underneath it. The designer’s edge in that world isn’t speed. It’s judgment about which friction is worth keeping.

That, to me, is the whole game as generation gets commoditized. Anyone can remove friction now; a machine will do it for you. Knowing which friction was holding the roof up is the part that’s still hard, still slow, and still yours.

For what it’s worth, I keep landing on the same answer for my own app: reward the reps that are actually hard, the ones where you stumble, not the days someone showed up to tap through the easy ones. Even knowing the second version is the one that would juice my numbers. I’m not always sure that’s the right business call. I’m fairly sure it’s the right design one.

So here’s my open question, and I’d love a fight about it in the comments: as our tools get better and better at making everything feel effortless, what’s the load-bearing friction you refuse to design away?

References

• Andrej Karpathy, “on shortification of ‘learning’.” X, Feb 2024.

• Andrej Karpathy. Wikipedia (Anthropic pretraining team, 2026). https://en.wikipedia.org/wiki/Andrej_Karpathy

• “Beyond the Hype: 5 Counter-Intuitive Truths About AI from Andrej Karpathy” (summary of the Dwarkesh Patel interview). DEV Community, Oct 2025. https://dev.to/amananandrai/beyond-the-hype-5-counter-intuitive-truths-about-ai-from-andrej-karpathy-afk

• Robert & Elizabeth Bjork, “Desirable Difficulties: Why Effortful Learning Outlasts Easy Learning.” Glasp, 2026. https://glasp.co/articles/desirable-difficulties

• Bjork & Bjork, “Introducing Desirable Difficulties Into Practice and Instruction” (PDF). University of New Hampshire. https://www.unh.edu/teaching-learning-resource-hub/sites/default/files/media/2023-06/itow-introducing-desirable-difficulties-into-practice-and-instruction-bjork-and-bjork.pdf

• “Does Duolingo Work? How Effective It Actually Is.” The Linguist, Mar 2026. https://blog.thelinguist.com/duolingo-review/

• “Duolingo French Review 2026: Does It Actually Work?” HelloFrench, Apr 2026. https://www.hellofrench.com/en/tips/duolingo-french-review

• “Results from Duolingo efficacy studies.” Duolingo Blog. https://blog.duolingo.com/results-duolingo-efficacy-studies

There’s a specific kind of dread that comes with building your own portfolio.

You know design. You have opinions about typography, whitespace, motion. You can critique someone else’s portfolio in thirty seconds flat. But when it’s your own work: your name, your case studies, your reputation on the page, suddenly everything feels harder. The blank canvas paralysis is real, and I’ve seen more talented designers avoid updating their portfolios for years because the bar they’ve set for themselves is impossibly high.

Here’s the thing that shifted for me recently: Claude Code has changed the math on what it costs (in time and cognitive energy) to actually build and iterate on a portfolio. Not just to ship a first version — but to keep it alive.

Let me walk you through the workflow I’d use if I were building mine from scratch today.

Start With a CLAUDE.md: Your Design System Lives Here

The biggest mistake I see designers make when jumping into Claude Code is treating it like a search bar. “Build me a portfolio website.” The output is technically functional and aesthetically… fine. Forgettable. The kind of thing that looks like it was made by an AI, because it was.

The antidote is what the community has started calling the CLAUDE.md-first approach. Before you write a single prompt about a hero section or a case study layout, you create a CLAUDE.md file at the root of your project. This is a plain text file — essentially a project brief and design system rolled into one — that Claude Code reads at the start of every session.

Think of it like the brief you’d give a developer. Except the developer is an AI that never forgets, never skips ahead, and will apply your constraints obsessively across every component it generates.

A strong CLAUDE.md for a portfolio should include:

Brand tokens — your exact hex colors, type scale, spacing units, border radius, and shadow definitions. Don’t write “use a clean sans-serif.” Write font-family: 'Instrument Serif', serif for display and font-family: 'DM Mono', monospace for body. Be specific enough that there’s only one correct interpretation.

Component conventions — how cards behave, how hover states feel, whether you prefer subtle motion or none at all. “Transitions: 200ms ease-out. No bounce. No slide-in from off-screen.”

What not to do — this is underrated. Listing explicit anti-patterns (“no purple gradients,” “no full-width hero images with overlay text,” “no glassmorphism”) is just as important as describing what you want. Claude will avoid these across the entire project.

Page intent — a short description of what each page is trying to accomplish, not just what it contains. “The work page should feel like a gallery, not a grid of thumbnails. Breathing room matters more than density.”

This file becomes your source of truth. You’ll edit it as you go — that’s expected. Treat it as a living document rather than a one-time setup. When something feels off after a generation, update the constraint in CLAUDE.md before re-running. You’re training the context, not just fixing a bug.

The Screenshot Loop: Design Feedback That Actually Works

Here’s a workflow detail that doesn’t get talked about enough. Claude Code can spin up a local server, take a screenshot, read the image directly, compare it against a reference, fix what’s off, and screenshot again: handling the whole cycle without you stepping in.

For a portfolio, where the visual output is the product, this is transformative. You set a reference screenshot (a Dribbble shot, a competitor’s site, a Figma frame you exported), and Claude iterates against it visually rather than just textually. The delta between “it looks roughly right” and “it matches my vision” collapses dramatically when there’s an actual visual feedback loop.

The reference cloning works better on sections than full pages. Breaking the design into header, body, and footer and handling each separately gives you a lot more control. I’d treat your portfolio the same way: tackle the nav, then the hero, then the case study card, then the footer — rather than asking Claude to generate everything at once.

Where Should Your Portfolio Content Live?

This is the question I actually get asked most often, and it’s worth spending real time on. The answer isn’t obvious, and it depends on your workflow more than any tool’s feature list.

Your content, case study write-ups, project descriptions, role timelines, the “about” text you’ve revised seventeen times, is the hardest part of a portfolio to maintain. The design can be rebuilt. The words take weeks. So the system you use to store and update them matters enormously.

Option 1: Markdown files in your project repo

This is my personal preference for designers who are comfortable in a code environment. Your content lives as .md files alongside your code. When you update a case study, you open the file, edit it, commit, and push. Claude Code can read and reference these files directly — you can ask it to “pull the intro paragraph from /content/case-studies/communication-app.md“ and it will. The content and the code stay in sync because they live in the same place.

The downside is that it’s not a great writing environment if you’re a prose-heavy writer. Markdown in VSCode is functional, not beautiful.

Option 2: Obsidian

Obsidian’s Markdown-native format integrates naturally with Git workflows — store your vault in a Git repository for version control, and you can query your notes programmatically. For a portfolio, this means you can write your case studies in a beautiful, linked note environment, and then export them as .md files that Claude Code can read directly. No format conversion, no copy-paste friction.

For anyone who writes in one tool and publishes in another, Obsidian’s native Markdown format eliminates the formatting friction that plagues Notion-to-external-platform workflows. This is real. If you’ve ever tried to copy a Notion page into a codebase, you know what I mean.

The tradeoff: Obsidian is a solo tool. If you collaborate with anyone on your portfolio content (a copywriter, a mentor giving feedback), the experience is clunky.

Option 3: Notion

Use Notion if you need content planning, editorial calendars, and project management alongside your writing. For a portfolio that’s actively being built: multiple case studies in different stages, a running list of things to add — Notion’s database views are genuinely useful. You can track each case study’s status (draft, needs images, published) in a kanban board.

The problem is export friction. Notion’s rich text doesn’t always convert cleanly to code-friendly formats. If you’re feeding content directly to Claude Code, you’ll find yourself doing manual cleanup more often than you’d like.

The recommendation: Start with Markdown files in your repo if you’re already working in VSCode. Graduate to an Obsidian vault if you find yourself writing long-form content and wanting a better writing experience. Use Notion only if you have collaborators or need to manage many projects simultaneously.

The Actual Build Order (Don’t Skip This)

Here’s the sequence that produces the best results, based on what I’ve seen work:

1. Write your CLAUDE.md first. Don’t touch code yet. Define your brand tokens, your aesthetic constraints, and your anti-patterns. This takes 30–60 minutes and saves hours of re-generation later.

2. Populate your content files. Write your case studies, your about blurb, your role history, even in rough draft form. Claude Code will use this as source material. A portfolio with real content and mediocre design beats a beautiful portfolio with placeholder text every time.

3. Build one component, test the design system. Before generating full pages, ask Claude to build a single case study card. Review it against your CLAUDE.md. Adjust the constraints. Then expand.

4. Use the screenshot loop for visual QA. Set your reference, run the loop, iterate. Trust the visual feedback more than the code review at this stage.

5. Ship early, iterate in public. Your portfolio is not a product launch. A live, imperfect portfolio with three real case studies is worth more than a perfect one that’s been in development for eight months.

What This Workflow Actually Changes

The deeper shift here isn’t about Claude Code being a faster way to write HTML. It’s about what happens when the cost of iteration drops low enough that you’ll actually do it.

Most designers update their portfolios once every few years, when they’re job hunting, when they feel enough accumulated guilt to force a weekend sprint. The reason isn’t laziness. It’s that the cost of updating felt too high relative to the payoff on any given week.

When your design system is encoded in a CLAUDE.md and your content is in Markdown files in a Git repo, the cost of updating a case study is fifteen minutes. The cost of tweaking your type scale across every page is a one-line edit and a re-run. That’s a different relationship with your portfolio entirely, and it’s the one that keeps it current enough to actually matter.

The bar for a portfolio worth sending hasn’t gotten lower. But the effort required to clear it has.

Forward-Looking Thought

I keep thinking about a question that doesn’t have a clean answer yet: as AI handles more of the execution, what does it mean for a portfolio to demonstrate your taste? If Claude Code built the UI, what exactly is the thing being evaluated?

My working answer is that the CLAUDE.md is the design artifact. The constraints you chose, the anti-patterns you named, the aesthetic precision you encoded — that’s judgment. That’s the thing that’s actually hard to replicate.

Which means the portfolio of the future might look less like a gallery of finished work and more like a record of the decisions you make along the way.

References

• Tutorials Dojo — Claude Code: The Web Design Workflow That Actually Works (February 2026): https://tutorialsdojo.com/claude-code-the-web-design-workflow-that-actually-works/

• MindStudio — How to Avoid AI Slop When Using Claude Design (The Design System Approach) (April 2026): https://www.mindstudio.ai/blog/claude-design-avoid-ai-slop-design-system

• Design Systems Collective — From Prompt to Production: A Designer’s Step-by-Step Workflow with Claude Design + Claude Code (April 2026): https://www.designsystemscollective.com/from-prompt-to-production

• Medium / Katherine Yeh — A Designer’s Guide to Claude Code (March 2026): https://medium.com/design-bootcamp/a-designers-guide-to-organizing-ai-skills-and-tools-in-claude-code

• Tech-Insider — Obsidian vs Notion 2026 (April 2026): https://tech-insider.org/obsidian-vs-notion-2026/

• DataCamp — Claude Code in VS Code: Setup, Features, and Workflow (2026): https://www.datacamp.com/tutorial/claude-code-in-vs-code

• Abbas Ali / Substack — How to Build a Stunning Portfolio Website Using Claude Code (March 2026)

On July 16, Figma shipped a release note most people scrolled right past. When you bring a coded screen back onto the canvas now, the colors, type, and spacing bind to the variables already in your file instead of landing as dead, hardcoded values. Frames arrive with auto layout, so they reflow instead of sitting there like flat screenshots. Translation: code can travel back into design as cleanly as design once traveled into code. The wall between the two has a door in it now, and the door swings both ways.

I noticed because I’d spent that same week doing the exact thing the wall was built to prevent. I’ve been building a small app that helps designers rehearse hard conversations, the raise ask, the disagree-and-commit, the “I need to push this deadline” talk, and for the first time I wasn’t mocking a feature up for an engineer. I opened a branch, vibe-coded it, and pushed the PR myself. Which meant, for the first time, I got to feel the handoff from the other side of it.

Half of us are already doing this

I’m not unusual anymore. In the AI in Design 2026 report from Designer Fund and Foundation Capital, 900 designers across sixty-plus countries, half said they’ve shipped AI-generated code to production. At early-stage startups it’s closer to two in three. Founders were the shippiest group of all, around 70%. One in five respondents now call themselves a “design engineer,” a title that barely existed as a job posting two years ago and today anchors teams at Linear, Vercel, Stripe, and Anthropic.

So the classic handoff — designer mocks it up, engineer rebuilds it, and two weeks later the buttons are 2px off and the empty state never got built, is dying. Good riddance. But here’s the part nobody warns you about: it didn’t disappear. It moved.

The friction relocated downstream

When designers couldn’t code, the expensive translation happened at the design-to-code boundary. Now that we can generate a working screen in an afternoon, that boundary is cheap. The friction slid downstream to the pull request. The question is no longer “how do I write a spec an engineer can build from.” It’s “how do I hand off code an engineer can actually accept.”

And vibe-coded code is deceptively hard to accept. It looks flawless on screen one and quietly falls apart on screen two. It invents a fourth button variant because it never knew the other three existed. It’s the old trap in reverse: generation got commoditized, but judgment about what’s mergeable did not.

The tooling is racing to close this new gap. At Config 2026 in June, Figma made runnable code a first-class object on the canvas and shipped Motion with a timeline you can inspect keyframe-by-keyframe in Dev Mode and pass straight to a coding agent over MCP — no more animation specs lost in translation. Anthropic’s Claude Design pipes a design surface into Claude Code into your actual repo, same model family the whole way, so intent never gets flattened into a JPEG and thrown over a wall. And Claude Code’s Code Review now sends a fleet of specialized agents at every PR, catching the logic error or the broken auth path a human skimming a diff would miss.

Notice what all of that is really doing. It isn’t making the handoff faster. It’s moving the review — of intent, of correctness, of fit — as close to the moment of creation as it can get.

A workflow for pushing your own PRs

So if you’re a designer opening your own pull requests now, here’s the loop I’ve settled into. Four moves.

Branch, don’t sandbox. Vibe-code into a real branch off the real repo, not a disposable playground. The goal from keystroke one is a diff, not a demo. Everything downstream gets easier when there’s a diff to point at.

Carry intent as context, not pixels. Wire your agent to the source of truth: Figma’s Dev Mode MCP, Code Connect, your token file; so it generates against real components and spacing instead of eyeballing a screenshot. This one move is the whole difference between “same vibe” and same product.

Encode the guardrails once. A CLAUDE.md or design.md that names the design system, the file paths, and what’s off-limits does more to keep output mergeable than any amount of clever prompting. It’s the brief every session reads before it writes a single line.

Open the PR small, and let review be the net. Ship a tight diff, run agentic review before you request a human, and hand engineers the thing they’re genuinely good at judging, the tradeoffs, instead of the syntax.

What’s the engineer for, then?

The handoff was never really about files. It was about trust: can the next person take this and run without redoing it? For years designers earned that trust by producing the cleanest possible spec. Now we earn it by opening the cleanest possible pull request. The medium changed; the job didn’t.

Which leaves the question I keep turning over. When one person can generate the code, review it, and merge it, when the whole loop fits inside a single head, what exactly is the engineer for? My bet is it’s the same thing the best designers are quietly becoming: less about producing the artifact, more about being the judgment that decides it’s ready to ship. But I’d love to be argued with.

References

• Figma, Product news and release notes (July 16, 2026 — code-backed screens binding to variables on import): https://www.figma.com/release-notes/

• Figma Blog, Config 2026: New Materials, New Tools and a More Expressive Canvas (code layers, Figma Motion, MCP-connected design agent): https://www.figma.com/blog/config-2026-recap/

• Designer Fund, AI in Design 2026: The inflection point is here: https://designerfund.com/blog/ai-in-design-2026

• Foundation Capital, How AI is reshaping design in tech (900-designer survey, design-engineer share): https://foundationcapital.com/ideas/how-ai-is-reshaping-design-in-tech

• Claude Code Docs, Code Review (multi-agent PR review, July 2026 update): https://code.claude.com/docs/en/code-review

• DEV Community, From Prompt to Pull Request: Using Claude Design, Claude Code, and GitHub Together: https://dev.to/bilelsalemdev/from-prompt-to-pull-request-using-claude-design-claude-code-and-github-together-3m00

• Muzli, The Complete Vibe Coding Guide for Designers (2026) (MCP-first, “same vibe” vs same product): https://muz.li/blog/the-complete-vibe-coding-guide-for-designers-2026/

• uithings, The Complete Guide to Design Engineering (2026) (Vercel’s no-handoff model, role definition): https://uithings.com/design-engineering

A few months ago I built a small app to rehearse hard conversations — the performance review you’re dreading, the pushback you keep swallowing in standup. It worked, sort of. But every session had the same tell: I would pause to think, and the AI would take that as its cue and start talking. Real conversations aren’t like that. In a real conversation, the other person hears you hesitate and waits. Or they don’t wait, and that itself is information.

I filed it under “limits of the medium.” Then on July 8, OpenAI shipped GPT-Live, and the limit moved.

What actually changed

GPT-Live replaces ChatGPT’s default voice experience with a full-duplex architecture: the model listens and speaks at the same time, rather than waiting for silence to signal a turn. It’s a replacement, not an upgrade. Where Advanced Voice Mode processed one side of a conversation at a time, GPT-Live runs a continuous interaction layer that can hand harder questions off to a bigger reasoning model behind the scenes. More than 150 million people use ChatGPT’s voice and dictation features weekly, and all of them got a different product that week.

It wasn’t an isolated launch. A week earlier, xAI opened Voice Agent Builder in beta: a no-code layer that turns a plain-language description of a call flow into a working phone agent, bundling telephony, retrieval, tool-calling, guardrails, and observability into a single meter at $0.05 per minute. And ElevenLabs entered talks for a secondary sale at roughly $22 billion, double its February valuation, on reported ARR that crossed $500 million in the first four months of the year.

Read those together and the shape is obvious. Voice infrastructure is finished being a research problem. It’s now a line item.

The part nobody put in the launch video

Seven days after GPT-Live, on July 15, China’s Interim Measures for the Administration of AI Anthropomorphic Interactive Services took effect. ByteDance’s Doubao, Alibaba’s Qwen, and Tencent’s Yuanbao all disabled user-created AI personas rather than retrofit them. The requirements: anti-addiction systems, mandatory usage notifications, instant-exit mechanisms — were judged architecturally incompatible with agents built to hold a consistent emotional relationship over time. Workplace and productivity agents were spared. Sustained emotional interaction was the target.

Meanwhile, in the U.S., the FBI’s 2025 Internet Crime Report logged 22,364 AI-related complaints totaling $893 million in losses, driven substantially by voice cloning. It was the first time in the report’s 26-year history that AI got its own category.

So in a single two-week window: voice became genuinely conversational, the tooling became commodity, one government drew a hard line around emotional realism, and the fraud numbers made the cost of unearned trust legible.

Why this is a design problem, not a model problem

Turn-taking was doing a lot of quiet work. It gave voice interfaces a state machine. My turn, your turn, that’s a mental model, and users had it for free.

Full-duplex takes it away. Now the interface has no discrete states, no screen, no visible affordances, no undo, no way to scan ahead. Every trick we lean on in visual design: hierarchy, progressive disclosure, a disabled button, has no equivalent in a channel that is one-dimensional and moves at the speed of speech.

What replaces it is interaction texture: when the system interrupts, how it backchannels, how long it waits, what it does when you go quiet. Those aren’t model parameters. They’re design decisions, and right now most teams are shipping whatever the default sounds like.

The commoditization makes this sharper. When a working phone agent costs five cents a minute and takes two minutes to configure, the agent is not the product. How it behaves in the first ten seconds is.

Four things to actually design

If you’re building anything voice-adjacent in the next quarter, these are the decisions the platform won’t make for you:

• The interrupt policy. When does your agent yield, and when does it hold the floor? Warmth and efficiency pull in opposite directions here. Pick deliberately.

• State without a screen. How does a user know what the system heard, what it’s about to do, and how to take it back? Confirmation is not a UX nicety in voice, it’s the only recovery mechanism you have.

• Disclosure and distance. How human should this sound, and how obviously synthetic? China just made this a compliance question. It’s already a trust question everywhere else.

• The exit. How does someone end it, delete it, or walk away? The Doubao shutdown stranded millions of users’ histories. Design the offboarding before the onboarding.

The open question

We spent a decade designing interfaces that wait for us. The next stretch is designing ones that don’t, and deciding, product by product, how much of that we actually want.

I went back to my rehearsal app after the GPT-Live launch and realized the old limitation had been doing me a favor. The pauses were the point. An AI that fills every silence is more conversational and less useful for what I built it to do.

More capable isn’t the same as better designed. It never was. Voice is just the first medium where the gap is audible.

What’s the last voice interface that genuinely earned your trust, and what did it do differently?

References

• SiliconANGLE, “OpenAI launches GPT-Live voice model series ahead of broad GPT-5.6 release,” July 8, 2026 —  https://siliconangle.com/2026/07/08/openai-launches-gpt-live-voice-model-series-ahead-broad-gpt-5-6-release/

• ExplainX, “GPT-Live: OpenAI Full-Duplex ChatGPT Voice,” July 2026 —  https://www.explainx.ai/blog/gpt-live-openai-chatgpt-voice-july-2026

• Let’s Data Science, “xAI Launches Voice Agent Builder For Grok Voice,” July 2026 —  https://letsdatascience.com/news/xai-launches-voice-agent-builder-for-grok-voice-706092b4

• Bloomberg, “ElevenLabs Holds Early Talks for Tender Offer at $22 Billion Valuation,” July 2, 2026 —  https://www.bloomberg.com/news/articles/2026-07-02/elevenlabs-in-talks-for-tender-offer-at-22-billion-valuation

• Tech Funding News, “ElevenLabs in talks for a $22B valuation,” July 2026 —  https://techfundingnews.com/elevenlabs-is-in-talks-for-a-22b-valuation-doubling-its-price-tag-five-months-after-its-last-raise/

• South China Morning Post, “ByteDance and Alibaba to disable humanlike AI custom agents as new rules loom,” July 2026 —  https://www.scmp.com/tech/big-tech/article/3359482/bytedance-and-alibaba-disable-humanlike-ai-custom-agents-new-rules-loom

• Tech Times, “China AI Companion Law Takes Effect,” July 15, 2026 —  https://www.techtimes.com/articles/320525/20260715/china-ai-companion-law-takes-effect-doubao-qwen-shut-down-millions-lose-chat-data.htm

• Malwarebytes, “Americans lost nearly $900 million to AI-powered scams, FBI says,” June 8, 2026 —  https://www.malwarebytes.com/blog/scams/2026/06/americans-lost-nearly-900-million-to-ai-powered-scams-fbi-says

• VoiceAISpace, “Voice AI News — Jun 29–Jul 6, 2026” —  https://www.voiceaispace.com/news/voice-ai-news-2026-07-06

The detail nobody put on the slide

Last December, a Chinese phone called the nubia M153 sold out its first run of 30,000 units in a single day. It ran ByteDance’s Doubao assistant at the operating-system level, meaning the AI didn’t sit in a chat window waiting for prompts. It reached out and tapped the screen for you. Booked the cab. Compared the prices. Filled in the form.

And then WeChat and Taobao blocked it.

Not the phone. The behavior. China’s biggest apps looked at an agent driving their interfaces like a very fast, very literal user, and shut the door almost immediately.

I keep coming back to that detail, because this week in Shanghai its sequel took a victory lap. At the 2026 World Artificial Intelligence Conference — July 17–20, four venues, a reported 3,000+ exhibits — nubia unveiled the NaviX Ultra, billed as the world’s first AI-agent smartphone, with Doubao wired into the OS itself. It won a SAIL award before it ever went on sale. Alongside it, StepFun debuted what it calls an “Agent Operating System,” swapping the old file + application paradigm for intent + task: you state a goal, the system figures out the sequence.

So the industry is now shipping, at consumer scale, a product whose core value proposition is that it doesn’t need your app. And the apps have already said no.

That gap — between the demo and the ecosystem — is the most useful thing WAIC gave us this year.

Trend one: the unit of design is no longer the app

For twenty years, product design has assumed a stable container. You design a screen, inside a flow, inside an app, inside a store. Distribution and interface were the same object.

Agentic OSes break that. If the intent layer sits above the app layer, your carefully wrought onboarding is something a machine skims on its way to the checkout button. The exhibition floor in Shanghai reflected this everywhere: the story shifted from cloud models to on-device agents, from chat partners to operating systems, from parameter-count bragging to embodied and physical deployment. AGIBOT rolled out four robots at once. ACE Robotics shipped a world model plus an open benchmark for physical intelligence. Nobody was selling a chatbot.

But here’s the part product people should sit with: capability arrived before consent. The agent can operate the app. Whether the app permits it is a commercial negotiation, not a technical one. Every platform now has to decide whether agents are users, partners, or parasites, and that decision will be made by business development teams, then handed to designers as a constraint.

Trend two: governance became infrastructure

Two days before the exhibition opened, 29 countries signed an agreement in Shanghai establishing the World Artificial Intelligence Cooperation Organization, an intergovernmental body headquartered in the city, with founding members including Indonesia, Brazil, Malaysia, South Africa, Russia and Pakistan. The UN Secretary-General attended. The US and most Western governments did not.

It’s easy to file this under geopolitics and move on. Don’t. For anyone building product, this is the beginning of divergent default settings: different consent models, different data residency assumptions, different definitions of an acceptable autonomous action. The same agent flow may be legal, illegal, or simply unshippable depending on which standards bloc your user opens the app in.

Governance used to be a compliance review at the end. It’s becoming a design input at the start.

What this means if you design or build products

Three things I’m taking into my own work:

1. Design the permission layer as a first-class surface. If an agent acts on someone’s behalf, the most important screen in your product is no longer the feature, it’s the moment where a person grants, scopes, or revokes authority. Most teams are still treating that as a settings toggle. It’s the whole product.

2. Assume you are designing for two users. One human, one machine. Your interface now has a second audience that reads structure, not affordance. Semantic clarity, stable labels, and machine-legible state stop being hygiene and start being distribution strategy.

3. Get specific about what shouldn’t be delegated. This is where taste earns its keep. When execution is cheap and automatic, the differentiating judgment is knowing which decisions a person actually wants to keep, the ones where the choosing is the value. A phone that books your flight is convenient. A phone that picks your seat, your airline, and your layover has quietly made a set of judgments you might have enjoyed making.

The open question

WAIC 2026 answered a technical question, yes, agents can drive the whole device, and opened a much harder one: who gets to be the interface?

If the agent is the OS, the app becomes a supplier. If the app fights back, the agent becomes a very expensive voice assistant. Somewhere between those outcomes is a new contract about interaction, and I don’t think anyone in Shanghai has written it yet.

So: what’s the first thing you’d refuse to let an agent do on your behalf? I suspect the answer is where the next decade of product design actually lives.

If this was useful, I’d love to hear what you saw in the WAIC coverage that I missed — especially from anyone who was on the floor.

References

• Al Jazeera — China’s Xi Jinping launches new AI alliance: What is it? (July 17, 2026): https://www.aljazeera.com/news/2026/7/17/chinas-xi-jinping-launches-new-ai-alliance-what-is-it

• Xinhua — 29 countries sign agreement on establishing World AI Cooperation Organization (July 16, 2026): https://english.news.cn/20260716/b0449aa2133542868e310fdc45ef2969/c.html

• eWeek — China Launches Global AI Organization With 29 Countries as West Stays Out: https://www.eweek.com/news/china-waico-global-ai-governance-organization/

• PYMNTS — 29 Nations Join China-Led World AI Cooperation Organization: https://www.pymnts.com/news/artificial-intelligence/2026/29-nations-join-china-led-world-ai-cooperation-organization/

• Concept Phones — nubia NaviX Ultra unveiled as the world’s first AI agent smartphone (July 19, 2026): https://www.concept-phones.com/zte/nubia-navix-ultra-ai-agent-phone/

• iGeekPhone — Nubia NaviX Ultra Debuts at WAIC as World’s First AI-Native Smartphone: https://www.igeekphone.com/nubia-navix-ultra-debuts-at-waic-as-worlds-first-ai-native-smartphone-with-doubao-mobile-assistant/

• Memeburn — Nubia AI Agent Smartphone Will Use Apps Without You Touching: https://memeburn.com/nubia-ai-agent-smartphone/

• George Chen (Substack) — PREVIEW: WAIC 2026 showcases Xi’s keynote, Huawei’s Atlas 950, ZTE’s AI Agent Phone: https://georgechen.substack.com/p/preview-waic-2026-showcases-xis-keynote

• 36Kr — WAIC 2026 Full Preview: 108 Chips & 261 Large Models Unveiled: https://eu.36kr.com/en/p/3896827901200259

• 36Kr — Upcoming WAIC 2026: Multiple New Embodied Intelligence & AI Infrastructure Products Set to Debut: https://eu.36kr.com/en/p/3898343171687813

• Tech Times — AGIBOT Debuts Four Robots at WAIC 2026: https://www.techtimes.com/articles/320899/20260718/agibot-debuts-four-robots-waic-2026-global-export-push-meets-chinas-spy-law-obligation.htm

• Bastille Post — ACE Robotics Unveils Kairos 3.1 at WAIC 2026: https://www.bastillepost.com/global/article/6021153-ace-robotics-unveils-kairos-3-1-and-expands-its-embodied-ai-stack-from-data-to-deployment-at-waic-2026

• EqualOcean — WAIC 2026 Guide: https://equalocean.com/event/2026071422027-waic-2026-guide-ai-partnership-brighter-future

I had a brutal Tuesday two weeks ago. I was running on five hours of sleep, back-to-back meetings starting at 8am, a critical design review at 2pm, and I had somehow convinced myself to schedule a strength session at 6pm because “I’d feel better after.” I did not feel better after. I felt like a hollowed-out version of myself for the rest of the week.

Here’s the thing — I had the data to know that was going to happen. My WHOOP was telling me my HRV had cratered overnight. My recovery score was in the red. My calendar was packed with high-cognitive-load events. But none of those systems were talking to each other. I was the one who had to synthesize it all in real time, which I did not do, because I was already tired.

That moment of friction, the gap between having data and having insight — is exactly what a new class of AI integrations is starting to close.

Subscribe now

The Trend: Wearables Are Leaving Their Walled Gardens

For most of its existence, WHOOP was a closed loop. Your data lived in the app, you looked at your recovery score in the morning, maybe you adjusted your training. It was useful in a passive, dashboard-ish way. You had to go find the insight. The insight didn’t come to you.

That’s changing fast.

In May 2026, WHOOP announced a major expansion of its health platform, including on-demand clinician consultations, Electronic Health Record syncing through HealthEx, and two significant AI features: My Memory (a persistent personal context layer) and Proactive Check-Ins — marking what the company described as its evolution into a full intelligent health platform.

But even before those official features launched, the developer community had already been building something more interesting — and arguably more flexible. Through a handful of open-source Model Context Protocol (MCP) servers, anyone willing to spend 20 minutes on setup can now pipe their WHOOP data directly into Claude, the AI assistant, and get conversational access to their biometrics.

The pitch is simple: connect your WHOOP fitness data to Claude Desktop through the Model Context Protocol and access your workouts, recovery, sleep patterns, and more through natural language queries — with your data staying local and private.

That last part matters. We’ll come back to it.

The Setup: What This Actually Looks Like in Practice

Here’s where it gets concrete. There are currently several WHOOP MCP servers built by the developer community. These expose tools covering recovery scores, HRV, sleep stages, day strain, workout history, and trend analysis over configurable windows — running locally with OAuth2 setup, storing refresh tokens in your home directory, and auto-refreshing on subsequent runs.

You connect that server to Claude Desktop. You also connect Google Calendar via its own MCP connector (which Claude.ai supports natively on Pro plans). Now Claude has simultaneous access to:

• Your biometric data from WHOOP (how your body actually performed and recovered)

• Your calendar (what you’re asking your body to handle today and this week)

The queries you can now run are qualitatively different from anything a single-app dashboard can give you:

“My recovery score is 42 today. I have a board presentation at 3pm and a dinner with a client at 7pm. Should I move my morning run or keep it light?”

“Look at my sleep data from the last two weeks alongside my calendar density. Is there a pattern between my meeting load on Thursdays and my Friday recovery dips?”

“I have a big product launch week coming up. Based on my historical strain and recovery patterns, what’s my optimal sleep target and the latest I should schedule workouts?”

The use cases that developers are already building around include: daily readiness check-ins that pull last night’s sleep and today’s recovery to summarize what it implies for training intensity and focus; weekly trend reviews aggregating seven days of recovery, HRV, RHR, sleep consistency, and strain to spot improvements, plateaus, or warning signs; and training-load planning using recent strain and recovery patterns to decide when to push, maintain, or deload.

Add calendar context and each of those becomes significantly more actionable. You’re no longer looking at your body in isolation — you’re looking at your body within your life.

How to Set It Up (Mac, ~20 Minutes Total)

If you just want the concept, skip ahead. If you want to actually do this tonight, here’s the exact path.

Phase 1 — Get Your WHOOP Developer Keys (~5 min, browser only)

Go to developer-dashboard.whoop.com and sign in. Create a team if prompted (any name works), then create an app with these settings:

• Scopes: read:profile, read:workout, read:sleep, read:recovery, read:cycles, offline

• Redirect URI: http://localhost:8080/callback

Save. Copy your Client ID and Client Secret somewhere handy — you’ll need them in a moment.

Phase 2 — Set Up the Server (~10 min, Terminal)

Open Terminal (⌘ + Space → type Terminal → Enter). Paste each block in order:

# 1. Download the code
cd ~ && git clone https://github.com/juliandag/whoop-mcp.git && cd whoop-mcp

# 2. Set up Python and install dependencies (takes ~1 min)
python3 -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt

# 3. Create and open your credentials file
cp .env.example .env && open -e .env

# 4. Authenticate with WHOOP
source .venv/bin/activate && python setup.py

In the text file that opens, paste your Client ID and Secret after the = signs on their respective lines. Save and close.

Your browser opens a WHOOP login page. Log in, approve access. Tokens are saved locally — you’re done with Terminal.

Phase 3 — Connect Claude Desktop (~5 min)

Run this to get your exact folder path:

echo $HOME/whoop-mcp

Copy the result (e.g. /Users/yourname/whoop-mcp). Then open your Claude Desktop config:

open ~/Library/Application\ Support/Claude/

Open claude_desktop_config.json (create it if it doesn’t exist) and paste this, swapping in your actual path:

{
  “mcpServers”: {
    “whoop”: {
      “command”: “/Users/yourname/whoop-mcp/.venv/bin/python”,
      “args”: [”/Users/yourname/whoop-mcp/src/whoop_mcp_server.py”],
      “env”: {
        “PYTHONPATH”: “/Users/yourname/whoop-mcp/src”
      }
    }
  }
}

Save. Quit Claude Desktop completely (⌘+Q) and reopen it.

Test it: Type “Show my WHOOP profile” — if your data comes back, you’re live. Then try: “How is my recovery trending this week?”

Why This Matters Beyond the Gym

I want to push past the athlete framing here, because most people I know who wear WHOOP aren’t training for marathons. They’re founders, designers, product managers, engineers — people who do cognitive work for a living and treat the band as a proxy for overall readiness.

And that’s exactly where the calendar integration becomes most interesting. Because the highest-stakes decisions most of us face on a given day aren’t about whether to do a tempo run. They’re about when to schedule a hard conversation, whether to say yes to an extra commitment, how to structure a day before a travel week. These are judgment calls that most of us make on autopilot — powered mostly by coffee and calendar density.

Wearables in 2026 are tracking HRV suppression patterns, since sustained low HRV over multiple days suggests the autonomic nervous system isn’t recovering. Sleep disruption trends also now register as early warning signals, since overtraining — and by extension, overwork — often manifests as poor sleep quality before performance declines.

What if those signals informed your planning before the crash, not after? That’s the shift this integration enables. From reactive to anticipatory.

A Framework for Thinking About Your Personal Health Stack

If you’re a product person, here’s how I’d think about this in terms of information layers:

Layer 1 — Signal (What your body is doing): This is your WHOOP data. HRV, sleep stages, respiratory rate, strain. It’s continuous, objective, and timestamped. This is the raw input.

Layer 2 — Context (What you’re asking your body to do): This is your calendar. Meetings, travel, high-stakes events, social commitments. Most health apps have zero access to this layer, which is why their “recommendations” often feel generic.

Layer 3 — Synthesis (What it means): This is where Claude lives when you connect both. It’s the reasoning layer that takes signal + context and produces an actual recommendation — not a score, not a nudge, but a judgment call with your specific situation accounted for.

The magic isn’t in any single data source. It’s in the synthesis layer having access to both.

The Privacy Question You Should Be Asking

Before you wire everything together, there’s a real conversation to have about data. The local-first WHOOP MCP approach is built specifically for people who care about this: tokens are written locally, not pasted into chat, and your data doesn’t pass through a third-party server.

That’s meaningfully different from handing your health data to a consumer app that might resell it, aggregate it, or use it for model training. The local MCP model keeps your biometrics on your machine and passes them into Claude’s context window only for the duration of a session.

Still — you’re giving an AI model access to your HRV, your sleep, and your calendar. That deserves a pause. Know what you’re sharing and with what. WHOOP’s own “My Memory” feature acknowledges this tension explicitly: members can view, add, edit, or delete personal context at any time, and the company frames it as “your information, and you decide what WHOOP remembers.” Apply that same standard to any third-party integration you build.

What Comes Next

Apple’s Health+ service, reportedly launching in 2026, is framing its AI health coach as something that would offer guidance that “anticipates, not just responds” — sleep hygiene tweaks that match your actual patterns, stress strategies that fit your calendar rhythm, and flags about whether a doctor visit is worth scheduling, grounded in clinical knowledge from Apple’s on-staff physicians.

The direction is clear. The question is whether you wait for one company to build the integrated solution for you, or whether you stitch together the pieces that exist today — trading polish for flexibility and data ownership.

For most product people and designers I know, the answer to that question is obvious. We are not the wait-for-the-polished-version type.

The tools exist. The protocol exists. Your WHOOP is already tracking 24/7. Your calendar is already there. The only thing missing is the interpreter — and you now have one, if you’re willing to set it up.

The open question I keep sitting with: as AI gets better at synthesizing our physical and cognitive context, what decisions should we let it influence — and where does the line between useful nudge and algorithmic override start to blur? I’d love to hear how you’re thinking about it.

Subscribe now

References

1. WHOOP MCP Server (Open Source) — https://github.com/nissand/whoop-mcp-server-claude

2. Totem: Universal Wearables MCP Bridge — https://github.com/briangaoo/totem

3. WHOOP MCP Unofficial (Local-First) — https://whoopmcp.vercel.app/

4. How to connect a WHOOP MCP with Claude Code — https://www.merge.dev/blog/whoop-mcp-claude-code

5. WHOOP Expands Health Platform with On-Demand Clinician Access and New AI Features (May 2026) — https://finance.yahoo.com/sectors/healthcare/articles/whoop-expands-health-platform-demand-130000213.html

6. How WHOOP Coach uses AI to deliver personalized health guidance — https://www.whoop.com/us/en/thelocker/new-ai-guidance-from-whoop/

7. Fitness Wearables 2026: From Step Tracking to AI Coaching — https://thewellproven.com/fitness-wearables-2026/

8. Apple Health+ AI Coach Launches 2026 — https://apple.gadgethacks.com/news/apple-health-ai-coach-launches-2026-what-to-expect/

9. Unlocking Your Health Data: A Deep Dive into the Whoop MCP Server — https://skywork.ai/skypage/en/unlocking-health-data-whoop-mcp-server/1981559023663640576

10. MCP for WHOOP — https://mcpforwhoop.com/

The moment the demo becomes real life

A few weeks ago, I was talking to a friend who works in fintech about AI agents. The conversation stayed abstract — tools calling tools, autonomous workflows, “the agent economy.” Then she pulled out her phone and showed me Robinhood’s new agentic trading feature, which had gone live on May 27th. She’d already funded a dedicated account, connected it to a third-party AI agent via MCP, and given it a standing instruction: rebalance toward AI supply chain stocks whenever my exposure drops below 20%.

The agent had already made three trades. While we were having coffee.

That’s the moment the abstract becomes visceral. And for those of us who design digital products for a living, it raises a question that goes way beyond fintech: what does it actually mean to design for a user who isn’t always the one clicking?

What Robinhood Actually Launched

On May 27, 2026, Robinhood unveiled two products that collectively represent one of the most consequential UX bets in recent memory: Agentic Trading and an Agentic Credit Card.

The trading feature lets users create a dedicated, ring-fenced account that a third-party AI agent can access via Robinhood’s Model Context Protocol (MCP) server. The agent can analyze portfolios, monitor concentration risk and sector exposure, scan analyst notes for new opportunities, backtest strategies, and — crucially — execute trades. All without the user touching anything. A real-time activity feed and push notifications surface every trade after the fact, and users can disconnect the agent with a single tap.

The credit card side works similarly. Gold Card holders can issue a virtual card to their AI agent, set monthly spending caps, toggle manual approval mode on or off, and let the agent buy things — flights when prices dip, sneaker drops the moment they hit a threshold — autonomously.

CEO Vlad Tenev framed it around Robinhood’s founding thesis: “Our mission has always been to democratize finance for all, and now, that mission extends to AI agents.” The implication being that hedge funds have run algorithmic trading for decades. Now retail investors get the same infrastructure. That’s a genuinely compelling democratization story — and also a genuinely complicated design problem.

The Broader Shift This Belongs To

Robinhood’s launch didn’t happen in isolation. It’s one node in a rapidly forming ecosystem where financial action is being decoupled from human decision-making at the moment of execution.

Stripe has been building what it calls the “Agentic Commerce Suite” — infrastructure that lets AI agents discover products, negotiate purchases, and complete transactions on behalf of users through a single integration. Amazon, in partnership with Coinbase and Stripe, launched Bedrock AgentCore Payments in May, enabling agents to autonomously pay for APIs, data feeds, and digital services at the infrastructure level. Stripe’s own Machine Payments Protocol (MPP), launched in developer preview in March 2026, provides AI agents with cryptographic identity and programmable spending controls for sub-second, autonomous settlement.

The direction is unmistakable. The question of whether agents will transact is settled. The open design question is how do we make that safe, legible, and trustworthy for real people?

Why This Is a Design Problem, Not Just a Tech Problem

Here’s what struck me most about Robinhood’s product launch: the safety architecture is genuinely thoughtful — isolated accounts, spending caps, kill switches, manual approval toggles, real-time notifications — but the liability language in the disclosures is almost disarmingly honest. Robinhood explicitly states it “does not guarantee the accuracy, completeness, or suitability of any agent output” and is “not responsible for losses resulting from agent-generated decisions.” Users are responsible for monitoring positions and ensuring the agent is operating as intended.

That’s not a dodge. That’s a design constraint hiding in legal text.

Because here’s the thing: when a user sets up an agentic trading account, they’re not just granting access. They’re delegating judgment. And delegating judgment to software — especially software that can move real money without asking first — requires a level of trust that our current UX vocabulary was never built to handle.

We’ve spent fifteen years designing for what I’d call the “click-confirm loop”: user intends action → user sees affordance → user confirms → system executes. Every major safety pattern in finance and e-commerce has been built around that loop. Two-factor auth, order previews, “are you sure?” dialogs, purchase confirmations. All of it assumes a human at the moment of execution.

Agentic products break that loop by design. The human is present at the instruction stage and the review stage — but not at the execution stage. That’s a fundamentally different trust relationship, and it requires different design primitives.

What the Design Playbook Might Look Like

I’ve been thinking about this in terms of three new patterns that product designers will need to develop:

1. Intent Legibility When a user sets an instruction for an agent — “buy any AI infrastructure stock that drops more than 3% in a day” — they need to understand, in advance, what edge cases that instruction might hit. This is the design equivalent of writing a legal contract. The interface needs to surface ambiguity before the agent acts on it, not after. Robinhood’s examples (rebalancing portfolios, building thematic positions, backtesting strategies) are evocative but underspecified for a user who’s never thought about what “mean reversion” actually implies in a volatile week.

2. Ambient Accountability The real-time activity feed is the right instinct. But it’s a notification-based model — it tells you what happened. The next design frontier is anticipatory transparency: showing a user what the agent is about to do before it does it, with just enough friction to prompt a moment of human judgment without breaking the automation promise. Robinhood’s “trade preview” feature goes partway there. The interface challenge is making that preview feel like genuine oversight rather than an interruption.

3. Graceful Failure Surfaces When an AI agent makes an error — misinterprets an instruction, acts on stale data, executes a trade the user didn’t mean to authorize — the recovery experience matters as much as the prevention experience. Designing for agent failure is still largely terra incognita. What does an “undo” look like when real money has already moved? What does the dispute flow look like when the user technically authorized the agent but didn’t anticipate the outcome?

The Deeper Shift

What Robinhood’s launch really signals is that we’re entering an era where the user and the actor are no longer the same entity. The user sets policy. The agent executes it. The product designer’s job is to make that delegation legible, reversible, and trustworthy — without making it so friction-laden that the whole value proposition collapses.

This is harder than it sounds. The instinct will be to add confirmations, approvals, and “are you sure?” moments until the agent feels safe. But an agent you have to approve on every action isn’t an agent — it’s a slower version of doing it yourself. The real design challenge is building enough oversight to maintain user trust without undermining the autonomy that makes agents useful in the first place.

Stripe’s Head of Information and Data Science Emily Glassberg Sands put it well: “Agents don’t just change who’s at the checkout. They change who’s doing the searching, the deciding, the trusting — all of it.”

That’s the shift worth sitting with. The parts of product design that used to be UX problems are becoming protocol problems. And the parts that are still UX problems — trust, legibility, accountability — are becoming the hardest design problems in the industry.

A Question Worth Wrestling With

I keep coming back to this: Robinhood’s feature is explicitly targeted at “early adopters of agents” who want to “bring their own tools.” That’s a technically sophisticated, high-intent user. But the long-term vision is clearly mass-market — the same democratization story Robinhood has always told, now extended to autonomous finance.

When agentic trading reaches mainstream retail investors — people who don’t know what MCP stands for, who set up an instruction once and forget about it — what does the design responsibility look like then?

That’s the question I’d love to hear your take on. Because I don’t think anyone has a clean answer yet.

References

• Mehta, I. (2026, May 27). Robinhood now lets your AI agents trade stocks. TechCrunch. https://techcrunch.com/2026/05/27/robinhood-now-lets-your-ai-agents-trade-stocks/

• CNBC. (2026, May 27). Your AI agent can now trade for you on Robinhood. https://www.cnbc.com/2026/05/27/your-ai-agent-can-now-trade-for-you-on-robinhood-and-buy-stuff-with-your-credit-card-too.html

• Robinhood Newsroom. (2026, May 27). Robinhood is now open to agents. https://robinhood.com/us/en/newsroom/robinhood-is-now-open-to-agents/

• Robinhood. (2026). Agentic Trading overview. https://robinhood.com/us/en/support/articles/agentic-trading-overview/

• Fortune. (2026, May 27). Robinhood launches credit card for AI agents with 3% cash back. https://fortune.com/2026/05/27/robinhood-ai-agents/

• AWS Machine Learning Blog. (2026, May 7). Agents that transact: Introducing Amazon Bedrock AgentCore payments. https://aws.amazon.com/blogs/machine-learning/agents-that-transact-introducing-amazon-bedrock-agentcore-payments-built-with-coinbase-and-stripe/

• Stripe. (2026). Introducing the Agentic Commerce Suite. https://stripe.com/blog/agentic-commerce-suite

• Glassberg Sands, E. (2026). Quoted in Stripe’s Guide to Agentic Commerce. https://stripe.com/guides/agentic-commerce

• Forrester. (2026, May). Stripe Sessions 2026: Stripe is rearchitecting payments for an agentic AI economy. https://www.forrester.com/blogs/stripe-sessions-2026-stripe-is-rearchitecting-payments-for-an-agentic-ai-economy/

• Memeburn. (2026). Robinhood Agentic Trading: AI now buys stocks for you. https://memeburn.com/robinhood-now-lets-ai-agents-trade-stocks-and-shop-for-you-in-2026/

It’s 9:47 AM on a Tuesday. You’ve already written three Jira tickets, talked the CEO out of a UI decision you know users will hate, and scheduled a user interview for noon. By 3 PM, you’ll be in a heated debate about button copy with an engineer who’s been building since before you graduated. By 5, you’ll be pushing live.

Nobody asked you to do most of this. Nobody needed to. You just are.

The Job Description Nobody Writes

There’s a particular fiction baked into most job postings for “First Designer” or “Sole Product Designer” at startups. They list things like “own the design system” and “collaborate cross-functionally” as if these are distinct, tidy line items. What they don’t list: becoming the de facto product manager when the roadmap goes dark. Writing onboarding copy when there’s no content person. Running QA because you’re the only one who noticed the padding broke on mobile. Defending design decisions to a board that thinks “make it more modern” is actionable feedback.

This is the role. And it’s not a complaint, it’s the whole point.

Anton Sten, who published one of the most searingly honest essays on solo startup design in early 2025, put it directly: “There’s nothing glamorous about being a designer at a startup. It’s a role that frequently values speed and pragmatism over going deep in the craft.” That friction, between the designer you trained to be and the operator the startup needs right now, is where the real growth quietly happens.

What 2026 Is Making More Extreme

Here’s what’s raising the stakes further: AI has made it cheaper to build, which means startups expect more from their single designer, not less. Designer Fund’s 2026 report lands on an uncomfortable truth — as AI lowers the cost of building, design becomes the differentiator. That sounds like validation. For the sole designer, it means the scope of what’s expected has quietly expanded again, without a corresponding increase in headcount.

The State of AI Design 2026 report found that 65% of designers are now taking on more product or engineering responsibilities. At startups, that number is almost certainly higher. A designer who can move fluidly between Figma, v0, and Cursor can ship what a small team used to require. That capability becomes expectation almost overnight.

The Three Things You Actually Learn

Here’s what nobody tells you going in, but everyone who’s been through it knows:

You learn to make a case, not just a design. Presenting to engineers, founders, and investors means translating design intent into business outcomes and observable user behavior. You stop saying “this is more intuitive” and start saying “users dropped off here, here’s the data, here’s what we’re testing.” That shift in framing is career-defining and nearly impossible to build in a larger org where someone else handles the storytelling.

You learn what “good enough” actually means. Not in a defeatist way, in a precision way. You build an instinct for which decisions deserve rigor and which just need a decision, any decision, by Thursday. This is the judgment call that separates senior designers from everyone else. Startup designers get forced into it fast.

You learn how a product actually works. Not just the interaction layer, the whole system. Why were features built the way they were; Where the technical debt lives; What sales is promising that the product can’t yet deliver; This full-stack understanding takes years to develop at a larger company. You get a version of it in months.

The Part Nobody Talks About

The hardest part isn’t the volume. It’s the absence of design feedback. Nobody else in the room thinks like you, which means no one can tell you whether your information architecture makes sense or whether your design system accumulated seventeen button variants because of genuine need or because things spiraled during the Series A sprint.

This is why community matters so much in this role. The designers who thrive — not just survive — build external peer networks: design critique groups, ADPList mentors, async Slack communities where people speak fluent systems thinking. They seek the feedback their own building can’t give them, because they’ve learned early that it won’t.

Why This Role Is Actually an Accelerant

In a world where AI increasingly handles production work, the competitive edge for any designer is judgment. And there is no faster path to that than being the person a startup calls for everything. The role is clarifying in its way: you find out quickly what you actually know how to do versus what you’ve only ever known how to talk about.

The sole designer role isn’t a gap year or a compromise. In 2026, with design expectations rising and the tools to meet them more powerful than ever, it may be the most complete, if unofficial, product education available.

It just won’t look anything like design school.

References

• The Solo Designer: Lessons from a Startup Journey — Anton Sten (2025)

• AI in Design 2026: The Inflection Point Is Here — Designer Fund

• Design Is the Differentiator: What We’re Looking Forward to in 2026 — Designer Fund Substack

• The Year Designers Stopped Being Just Designers — AI in Design Report 2026, ArtificialStudio

• State of AI Design Report 2026

• The Ultimate Guide to the Founding Designer Role — First Round Review

• What I Learned as the First Product Designer in a Startup — Rhiannon Mapson, Medium

• On Being a Sole Designer — Medium Design Bootcamp

• Sole Designer at a Startup? — Muskan Bhatia, Medium

• Lessons from Working as a Solo Designer at a Startup — Federico Dal Fò, Medium

• How AI Is Rewriting Design Careers: What’s Actually Changing in 2026 — Growthmates

There’s a moment Jenny Wen keeps coming back to. She’s the Head of Design for Claude Cowork at Anthropic — formerly Director of Design at Figma, where she built FigJam from scratch. She left a director title to go back to individual contributor work. That choice alone should tell you something is shifting.

On Lenny Rachitsky’s podcast in March, she said it plainly: “This design process that designers have been taught, we sort of treat it as gospel. That’s basically dead.”

Not evolving. Not disrupted. Dead.

And the thing that killed it wasn’t AI in the abstract. It was an engineer at Anthropic named Boris who started spinning up seven Claude instances simultaneously and shipping prototypes before Jenny had even opened Figma. The power dynamic between design and engineering flipped — and most designers haven’t felt it yet.

The Numbers Are Already Strange

The Designer Fund and Foundation Capital just released their AI in Design 2026 report, drawing on 900 designer responses and 25+ interviews with leaders at Anthropic, Stripe, Cursor, DoorDash, and others. A few numbers from it that I keep returning to:

50% of designers — including brand designers, not just the engineering-adjacent ones — have pushed AI-generated code to production. Only 20% of those identify as design engineers. The rest are people who, a year ago, had never touched a terminal.

65% of designers say they’re now doing more product management and engineering work. 40% say the reverse is also true — their PMs and engineers are doing more of what used to be design.

And the average designer’s toolstack went from 3 tools to 7. In one year. Nearly half say they’re still searching for their definitive setup.

That last detail captures something true about this moment. We’re all mid-molt.

What “Design” Actually Looks Like at AI-Native Companies

At Anthropic, the workflow has split into two distinct modes, according to Jenny. There’s the rapid-fire layer — engineers building prototypes at speed, designers embedded inside that loop to steer quality and intent rather than lead from the front. And then there’s the longer arc work: the kind of design that requires holding a broader vision across six months rather than five years.

The classic discovery → mock → iterate cycle is gone. Not because it was bad design thinking, but because by the time you’ve completed a diverge-converge loop, the engineer has already shipped three working versions and learned something real from users. You can’t block that with a process built for a slower world.

Jenny describes design at Anthropic as “supporting engineer-led execution” — which sounds like a demotion until you realize the designers doing this well are the ones shaping what gets built, why it gets built, and how it feels when someone actually uses it. The title on the org chart matters less than the accountability you hold.

At Notion, the framing is similar. Designers are working inside the product squad, not as a handoff layer. At OpenAI, the job posting for ChatGPT’s product designer explicitly asks for someone who gets “excited about being immersed in the AI research process and defining how AI-first products should look and behave.” Research immersion. Behavioral definition. Not wireframes.

What Vercel has done to formalize this is instructive. Their Design Engineer role operates in three modes: design collaboration (working alongside an engineer in Figma or code), product team integration (embedded inside a squad), and independent ownership (sketches, socializes, and ships alone). Their job description defines the role not as a hybrid but as “one fluid workflow.” The conjunction “and” in “design and engineering” is doing less work than it used to — it’s becoming an ampersand where both sides blur into each other.

The Tool Stack Is Rewriting Itself

Phil Vander Broek from Superhuman described what I think is the most significant shift in the report: “Figma has shifted from being the primary design tool to a canvas for quick exploration and polishing details as input for Claude Code.”

That’s a seismic repositioning of a tool that defined an entire era of product design. Figma didn’t disappear — the UX Tools State of Prototyping survey confirms it’s still the most-used design tool in 2026. But its role changed. It’s an input now, not the destination.

The pipeline designers at leading companies are actually running looks something like this: a rough sketch or prompt in Figma, fed through the Figma MCP server into Claude Code or Cursor, which generates working UI, which then gets pulled back into Figma as editable frames via the Anthropic-Figma bridge launched in February. Rapid cycles between code and canvas, with the designer as the quality filter and direction-setter at each pass.

Obsidian is showing up for design system documentation and decision logging. Linear for tracking what’s actually shipping and what’s rotting in the backlog. Claude Code and Cursor for prototype iteration. The designer as orchestrator of a pipeline, not author of a deliverable.

I’ve been building this way for a few months on my own projects, and the honest truth is: the first week feels like you’ve lost your superpower. The second week feels like you got a different, larger one.

Three Archetypes That Are Actually Getting Hired

Jenny mentioned she’s currently hiring for three specific archetypes at Anthropic. She didn’t name them in the podcast, but based on what’s emerging across job posts and team structures at leading AI companies, the pattern is readable:

The Systems Designer. Someone who thinks in constraints, tokens, and states — who can encode a design system as a machine-readable file that an AI can follow, rather than a Figma library that an engineer has to manually interpret. This person thinks in CLAUDE.md files as much as component specs.

The Prototype-first Designer. Someone who reaches for code before mocks, who can hold a working prototype as their primary thinking medium. At early-stage companies, the Foundation Capital report found 68% of designers are already shipping code. This archetype is table stakes, not differentiator, at most AI-native companies.

The Judgment Layer. The rarest and arguably most valuable — the designer who can sit at the intersection of product and engineering, make fast decisions about what actually matters, and take accountability for those decisions. Jenny put it cleanly in an earlier interview: “Taste without accountability is decoration. Taste with accountability is leadership.”

The third archetype is the one that AI cannot replace, and the one that most designers are least trained to inhabit. We were never taught to be accountable for the decision — only for the design.

What This Actually Means If You’re a Working Designer

The shift isn’t that designers should all become engineers. Half the designers shipping code to production in 2026 don’t call themselves design engineers. The shift is that the sequencing changed — and with it, where your value sits.

When engineers can generate functional UI faster than you can finish your first round of exploration, your value is no longer in producing the artifact. It’s in knowing what the artifact should do, why it should exist, and whether what got built is actually right.

That’s a PM question. It’s also a taste question. It’s also a systems-thinking question. Which is probably why 65% of designers say they’re doing more of all three.

A few things worth building into your practice right now:

Learn to think in working prototypes. Not wireframes that need translation — code that runs. Claude Code, Cursor, Framer’s AI layer — pick one and get fluent enough to use it as your thinking medium, not just a production shortcut.

Get close to engineers earlier. The designers who are thriving in this shift are the ones embedded in the build loop from day one, not brought in to review at the end. The double-diamond process was partly a compensation for the friction of late handoffs. Remove the friction, and you can remove the process.

Own the decision, not just the design. When you’re the person who decides what gets built next and why, you’re irreplaceable. When you’re the person who produces the mock of what someone else decided, you’re increasingly optional.

The Open Question

The thing I keep sitting with: Jenny’s own words on whether AI will eventually match human taste and judgment. She said: “We’ll get better at taste and judgment and design. We might be holding onto that a little bit too much.”

This is the head of design at the company building the most capable AI system in the world. She’s not speculating from the outside. She watches it happen daily.

So the question isn’t whether the design process is dead — that’s already settled. The question is what comes after the moat of taste, if the moat eventually floods. And the answer I keep coming back to is the same one that survives every wave of automation: the people who understand users, who feel the friction before it shows up in the data, who can hold a direction when everyone else is iterating without one.

That’s not a design skill. It’s a human one. And it might be the only thing worth sharpening right now.

References

• Foundation Capital & Designer Fund. AI in Design 2026 Report. May 2026. foundationcapital.com/ideas/how-ai-is-reshaping-design-in-tech

• ArtificialStudio. The year designers stopped being just designers. May 2026. artificialstudio.ai/blog/ai-design-report-2026

• Designer Fund. AI in Design 2026: The inflection point is here. May 2026. designerfund.com/blog/ai-in-design-2026

• Rachitsky, Lenny. The design process is dead. Here’s what’s replacing it. | Jenny Wen. Lenny’s Newsletter. March 1, 2026. lennysnewsletter.com/p/the-design-process-is-dead

• Double Diamond NYC. Jenny Wen – Design Lead at Anthropic. March 17, 2026. doublediamondnyc.substack.com

• Yang, Peter. Inside Anthropic: Claude Cowork Tutorial from Claude’s Head of Design. Creator Economy. March 29, 2026. creatoreconomy.so

• Roth, Chris. Building An Elite AI Engineering Culture In 2026. February 2026. cjroth.com/blog

• Medium / Design Bootcamp. Product Designers Are Not Being Replaced. They Are Being Sorted. March 2026. medium.com/design-bootcamp

• OpenAI. Product Designer, ChatGPT — job listing. 2026. builtin.com

Imagine being handed the most powerful cognitive tool in human history, and your first instinct is to use it as a typewriter.

That’s not a hypothetical. That’s what Ali Ghodsi, co-founder and CEO of Databricks, described at HumanX 2026 — and it’s the uncomfortable mirror that the entire conference held up to anyone building AI products today.

“The AIs have already achieved AGI, maybe a year or two ago,” Ghodsi said plainly. “The models are plenty smart. The problem is they don’t have the context. And that’s going to take a really long time to fix. It’s not something the next model release is going to solve.”

I sat with that for a while. And then I watched the rest of the conference double down on it, from nearly every angle.

The Gap No One Wants to Talk About

There’s a collective fantasy running through the AI industry right now: that the next model release will close the distance between what AI can do and what it’s actually doing inside enterprises and products. A better model, the thinking goes, fixes everything.

Ghodsi thinks that’s misdirected. So does Bret Taylor, CEO of Sierra and chairman of OpenAI. So does Matt Garman, CEO of AWS, who quietly mentioned that Amazon’s internal developers are seeing 4.5x productivity gains from AI — and yet, most of the world is still manually filing reports, sitting through status update meetings, and copy-pasting between systems.

The gap isn’t capability. It’s context. It’s organizational process. It’s the willingness — and the design intelligence — to actually restructure how work gets done.

Taylor put it bluntly: “The Venn diagram of people who know how to make an agent and understand accounting rules is the empty set. Everyone who knows how to make websites using the previous generation of technology just wants to make website-making tools.”

We’re building with the medium we know, not the one that’s possible.

The Bottleneck Has Moved — Have You?

Here’s what struck me most across ten talks at HumanX: the bottleneck in product development has fundamentally shifted, and most teams haven’t caught up.

Andrew Ng, founder of DeepLearning.AI, described something he’s witnessing across companies he works with: “We’re increasingly bottlenecked, not by the act of building, but by deciding what to build.” He’s now regularly assigning projects that would have required 15 engineers to two — and they’re done in a month instead of three. The bottleneck isn’t the build. It’s the vision.

OpenAI’s Srinivas Narayanan made the same observation from the inside: “The job of software engineer has now become more like the job of a CEO. It’s becoming less about how you accomplish things, and more about what you actually want to accomplish.”

This is the new design brief. Not “how should this interface work?” but “what workflow does this replace entirely, and what does the human do instead?”

Denis Yarats, co-founder of Perplexity, offered a sharp heuristic: “You have to build for what is going to be like six or 12 months ahead, never what is now. Because if you do that, you’re always going to be behind.”

Applied AI Is the Biggest Opportunity No One Is Chasing

Taylor was emphatic on a point I think is deeply undervalued in the startup world: the most durable value in AI won’t come from foundation models. It will come from applied AI — companies that take deep domain knowledge, combine it with AI, and solve real business problems.

“You’re not selling AI. You’re selling a solution to a business problem,” he said, name-checking Sierra’s work in customer experience and Harvey’s work in legal. “Most companies don’t want to make software. They want solutions to their problems.”

The opportunity is enormous precisely because it’s unglamorous. The financial auditing agent that Taylor described — one that could compress weeks of quarter-close work into hours — doesn’t exist yet. Neither does most of what should exist.

Lin Qiao of Fireworks AI added another layer: the real competitive moat for AI products isn’t the model. It’s private data. “The private data locked inside enterprises — those are the real moat. And by and large, that data hasn’t been fully activated today.”

Product teams that understand their users’ data intimately, and build specifically around it, will be nearly impossible to replicate. Screenshot-to-clone still can’t copy what you know.

Frameworks for Designers and Product People

If you’re building AI products — or helping organizations adopt them — here’s what HumanX 2026 actually changed for me:

1. Design for six months ahead, not today. Your product’s constraints should be set by where the model is going, not where it is. Mike Krieger of Anthropic Labs said it cleanly: “This is the worst the models will ever be.” Build harnesses that improve as the model does.

2. The new design question is organizational, not interface. Taylor made web apps sound almost quaint — “forms and fields and buttons in a browser that you could use to change the rows in a database.” The design challenge now is: what workflow or decision should an agent own end-to-end? Start there, then work backwards.

3. Context engineering is the new craft. Ghodsi’s “context gap” thesis means that identifying, cleaning, and surfacing the right private data for AI systems is among the highest-leverage work a product team can do. This is design work, not just data infrastructure.

4. Think beyond point solutions. Andrew Ng’s distinction between bottom-up and top-down AI transformation is critical. Point optimizations (saving an hour on loan approval) are good. But the bank that redesigned the entire loan product — “approved in 10 minutes” — created a new product that drives growth. That’s the difference between AI as tool and AI as transformation.

The Best Products Haven’t Been Built Yet

Krieger closed his talk with the thing his Labs team is most focused on: “How do you actually extend and have the models be able to do productive, useful work, such that you feel like you have a coworker — not just a useful delegate.”

That distinction deserves a moment. A delegate does what you tell it. A coworker anticipates, contributes, flags problems you didn’t see, and earns trust over time. Most of what’s been built so far is a delegate. The coworker is the product no one has shipped yet.

The infrastructure is there. The models are ready. The $30 billion in Anthropic revenue run rate, the millions of developers using Codex at Cisco, the Novo Nordisk scientists getting research in minutes instead of months — it’s all proof that the technology works.

What’s missing is the imagination to use it differently. And that, historically, is what designers and product people are for.

If there’s one takeaway from HumanX 2026, it’s this: stop waiting for a better model to make your AI product work. The model is good enough. The bottleneck is you, and that’s actually the most optimistic thing I heard all week.

References

1. HumanX 2026 — “How Databricks Plans to Bring AI to Every Team,” Ali Ghodsi in conversation with Deirdre Bosa, CNBC

2. HumanX 2026 — “Bret Taylor’s View from the Top,” Bret Taylor in conversation with Alex Heath, Sources

3. HumanX 2026 — “How OpenAI Builds,” Srinivas Narayanan in conversation with Rachel Metz, Bloomberg

4. HumanX 2026 — “The Agentic AI Inflection Point,” Matt Garman in conversation, AWS

5. HumanX 2026 — “The Best AI Products Haven’t Been Built Yet,” Mike Krieger in conversation with Ed Ludlow, Bloomberg

6. HumanX 2026 — “What It Really Takes to Build an AI-Ready Workforce,” Andrew Ng & Greg Hart in conversation with Sharon Goldman, Fortune

7. HumanX 2026 — “AI is a Five-Layer Cake,” Bryan Catanzaro (NVIDIA), Lin Qiao (Fireworks AI), Denis Yarats (Perplexity)

8. HumanX 2026 — “The Godmother of AI on What Comes Next,” Dr. Fei-Fei Li in conversation with Ed Ludlow, Bloomberg

9. HumanX 2026 — “What We Choose to Hyper-Scale,” Al Gore in conversation with Dr. Eric Topol

In early 2025, METR ran the most rigorous study of AI coding tools ever conducted. Sixteen experienced open-source developers were given real tasks from their own repositories — the kind of complex, context-laden work that defines actual professional software development. Half used AI tools. Half didn’t.

The result broke a lot of conventional wisdom: developers using AI were 19% slower than those working without it.

What made the finding even stranger? After the study, when researchers asked developers how AI had affected their productivity, the answer was: 20% faster. A 39-point gap between perception and reality, in the same experiment, among the same people.

METR’s February 2026 update showed improvement — a -4% slowdown in a newer cohort of 57 developers, and they acknowledged that tools have meaningfully matured. But the original finding still echoes. Because the productivity story isn’t about tool quality alone. It’s about workflow design.

The teams winning with AI right now aren’t using it more. They’re using it differently.

The Old Playbook Is Broken

For most of the past two years, the default approach to “AI-assisted development” has been additive: take your existing process and inject AI at the edges. Use Copilot for autocomplete. Use ChatGPT to unblock on a tricky function. Use Claude to draft your PRD.

This is how you get the productivity paradox. Faros AI analyzed over 10,000 developers and found that heavy AI users were creating 98% more pull requests per person — and yet PR review times ballooned by 91%. More output, not more outcomes. The bottleneck didn’t disappear. It migrated downstream.

By May 2026, 92% of US developers report using AI tools in some part of their workflow. And yet a parallel CEO survey found most organizations don’t feel the needle has moved on what actually matters: delivered value, not shipped code.

The problem isn’t AI. The problem is that the workflow hasn’t kept up with the tools.

The Workflow That Actually Works: Think, Test, Build, Ship

The teams consistently getting real leverage from AI have one thing in common: they’ve restructured the entire loop, not just patched it. Here’s how the four phases play out when AI is native to your process rather than bolted on.

1. Think

This is the phase AI can help with least — and the one that matters most.

When you can build anything you can describe clearly, clarity of description becomes the constraint. Winning teams treat the Think phase as sacred, non-compressible time. They’re answering: What is the actual problem? What does success look like in measurable terms? What’s the smallest thing we can ship that tells us whether we’re right?

Productboard put it plainly in a recent analysis of the post-AI product landscape: “As the cost of building drops, the responsibility to choose well increases. Velocity stops being the differentiator. Judgment is.”

This is a structural shift, not a sentiment. For years, the bottleneck in product development was we can’t build fast enough. That bottleneck is gone. The new one is we can’t think fast enough about what to build. Teams that don’t protect and invest in the Think phase are now just accelerating toward the wrong target.

2. Test (Before You Build)

The counterintuitive move is to test your assumptions before writing a line of code — and AI has made this dramatically cheaper.

Tools like Bolt.new, Lovable, and Cursor let you generate a working prototype from a natural language brief in minutes. The implication: there’s almost no excuse anymore to enter a full build cycle without having put something in front of a real user first. The cost of a throwaway prototype has collapsed.

But here’s the trap: teams are using AI-generated prototypes as launch artifacts, not as learning artifacts. The “generate and ship” mindset skips the feedback loop that prototypes exist to create. Testing isn’t a phase you do after building. In an AI-native workflow, it’s a phase you do instead of some building.

3. Build

This is where the tools are most mature — and most misused.

Anthropic hosted “Code with Claude” in San Francisco on May 6th, shipping a suite of capabilities that signal where agentic coding is heading. The headline feature: Dreaming — agents that review their own past sessions, extract lessons, and apply them to future tasks without human intervention. Multi-agent orchestration, where coordinated teams of agents work a codebase in parallel, is now available out of the box. Dario Amodei noted that Q1 2026 revenue and usage, on an annualized basis, grew 80x rather than the 10x they had planned for.

The practical implication: the Build phase is no longer a person-per-feature model. A senior engineer orchestrating multiple agents in parallel is now the benchmark for high-leverage output. But — and this is critical — that only works if the spec from the Think phase is unambiguous. Agents amplify clarity and confusion equally.

The best teams have also reintroduced what early vibe-coding adopters discarded: rigorous code review, testing, and architectural oversight. The “accept everything the AI generates” approach is now widely recognized as how you end up with a 23.7% increase in security vulnerabilities, per recent AI coding productivity research.

4. Ship

Shipping has been transformed not just in speed, but in size. The teams outperforming are shipping in smaller increments with tighter instrumentation. Every AI-assisted feature ships with metrics designed to answer the question from the Think phase.

This is the closing of the loop that most AI workflow guides miss. Speed without measurement is just faster failure. The winning pattern: ship a smaller slice, instrument it deliberately, let data inform the next cycle. AI compresses cycle time; judgment decides what to do with that compression.

What This Means for Designers and Product People

If you’re a designer or PM reading this, here’s the uncomfortable truth: your role has changed more than your job description acknowledges.

You are now responsible for the quality of the problem statement, not just the solution. When any reasonably-specified feature can be built by an agent in hours, the most valuable thing you bring is precision about what to build and why. Vague briefs don’t slow down AI — they accelerate the production of the wrong thing.

Protect the Think phase explicitly. Schedule it. Don’t let it get compressed by the availability of fast tools. Frameworks like Jobs-to-be-Done, assumption mapping, and structured problem briefs are more valuable now, not less — because the cost of being wrong about the problem has increased even as the cost of building has fallen.

Treat prototyping as a learning budget, not a deliverable. AI makes it cheap to generate. Make it mandatory to test. Before any greenfield feature goes into a full build cycle, it should have touched a real user in some form — even if that form is a landing page measuring intent or a clickable prototype.

Design for measurability, not just usability. Every feature needs a pre-defined success metric before it ships. McKinsey analysis found that 80% of features across 615 products were rarely or never used — representing $29.5 billion in wasted R&D. AI makes it faster to add features. Judgment determines whether you should.

The Question Worth Sitting With

Here’s what I keep returning to: AI has done something remarkable. It has collapsed the cost of execution so dramatically that the human advantage is now almost entirely in the thinking that precedes execution.

That’s genuinely new. For most of software history, being a great designer or engineer meant being good at both the thinking and the doing. Those were inseparable. Now they’re being pried apart by tooling.

The teams that figure out how to invest deeply in Think and Test — while letting AI carry more of the Build and Ship — are going to have an extraordinary structural advantage. Not because they’re using more AI, but because they’ve understood what AI actually changes about the nature of their work.

Speed is now cheap. The question is what you do with it.

What’s your current workflow for keeping the Think phase protected in an AI-accelerated world? I’d love to hear how your team is navigating this — drop it in the comments.

References

1. The AI Productivity Paradox: Why Developers Are 19% Slower — DEV Community

2. We Are Changing Our Developer Productivity Experiment Design — METR, February 2026

3. The AI Productivity Paradox Research Report — Faros AI

4. Why Product Judgment Matters More Than Velocity in the AI Era — Productboard

5. Anthropic’s Code with Claude Announces Managed Agents, Proactive Workflows — InfoQ, May 2026

6. Inside Claude Code Auto Mode: Anthropic’s Autonomous Coding System — InfoQ, May 2026

7. AI Coding Productivity Statistics 2026: Gains, Tradeoffs, and Metrics — Panto AI

8. The AI Velocity Paradox: Why Your Team Ships Slower When Developers Move Faster — Wawand.co

9. 2026 Agentic Coding Trends Report — Anthropic

10. How to Build Businesses Faster and Better with AI — McKinsey & Company

11. Vibe Coding in Product Teams: Reconfiguring AI-Assisted Workflows — arXiv

12. 3 AI Shockwaves Reshaping Product Management in 2026 — LogRocket

There’s a dirty little secret in the design community: many of us have terrible portfolio websites. Not because we lack taste, we obsess over other people’s products daily. But because building your own thing, for yourself, with no brief and no deadline, is uniquely paralyzing. You know too much. Every font choice feels consequential. Every layout feels like a statement.

I’ve had “redesign portfolio” sitting in my personal Notion for three years.

Then, over one weekend in April, I shipped it. Not a placeholder. Not a “coming soon” page. A real, live portfolio, using Claude and Framer as my co-builders. And the process revealed something bigger than a productivity hack: it’s a signal of where the design-to-web workflow is fundamentally heading.

The Stack That Actually Changes the Game

Before I walk you through how this worked, here’s what made it feel different from every other “just use AI to build your site” promise:

Framer has quietly matured into something genuinely impressive. It’s no longer just a prototyping tool with a publishing button bolted on. In 2026, Framer lets you describe what you want, tweak it visually, and publish, all without touching a code editor. Its AI site generation takes a plain-English prompt and returns a multi-page layout instantly. But the real magic is the visual editor underneath: the canvas feels like a design tool, not a block-dragging interface, which matters enormously when you care about how things actually look.

Claude, meanwhile, isn’t just a chat assistant you paste into anymore. Framer now has a native MCP plugin that creates a live connection between your Framer project and Claude. You can ask Claude to create custom code components and insert them directly into your canvas, update color styles across your entire project with a single command, or export Framer components as production-ready React code. That’s not a side workflow, that’s a full AI-in-the-loop design system.

And then there’s Framer Workshop, the built-in Claude integration that powers faster and smarter suggestions, and now runs on all code components, not only those created with Workshop. It updated to Claude 4.5 in March 2026, and the speed difference is noticeable.

How I Actually Built It

I started in Claude (the web interface, not Code) with a deceptively simple prompt: describe my background, the tone I wanted, editorial, not corporate, and link to a few reference sites I admired. Claude helped me map out the site architecture, draft section copy, and think through what case studies to feature and how to frame them.

This part matters more than people realize. Framer AI is brilliant at layout, but it can’t tell you what story your work should tell. That judgment, what to show, what to cut, what the through-line of your career actually is, that’s still entirely yours. What Claude does is help you externalize it faster, get it out of your head, and into structure.

Then I took that content foundation into Framer.

You open a new project, select “Generate with AI,” and type a prompt like “portfolio website for a freelance brand designer with a dark theme, project gallery, about section, and contact form.” What comes back isn’t a template, it’s a starting point that already reflects the brief. From there, the Figma-like canvas is where your design sensibility takes over. You’re not coding; you’re making real decisions about space, hierarchy, and motion.

For the parts that needed custom behavior, a scroll-triggered case study reveal, a work filter, I used the Framer MCP plugin with Claude. The setup is surprisingly straightforward: install the plugin, copy the MCP URL, and run a single command to connect Claude Code to your project. Once connected, you can describe what you want in natural language and watch it appear in the canvas. Not perfectly every time, but close enough that the iteration loop is fast.

The whole process, content architecture, copy, layout generation, custom components, polish, took a weekend. A focused weekend, but a weekend.

What This Means for How We Work

This isn’t just about speed. Something more interesting is happening structurally.

Claude Code can generate strong starting points fast, but detailed refinement usually means repeated prompt changes, code inspection, and redeploys. Framer bridges that gap, offering a visual-first workflow to refine and ship with total confidence. The implication: these tools aren’t competing, they’re complementary. Claude is strongest at the planning and logic layer. Framer is strongest at the design execution and publishing layer. Used in sequence, they cover each other’s gaps.

Framer produces the most beautiful designs for portfolios of any AI builder tested in 2026, and portfolios, it turns out, are the perfect use case for this workflow: visual-first, content-light, and deeply personal.

There’s also something worth naming about what still requires you. AI excels at structure; humans at nuance. Claude created a solid framework, but the personality, the sequencing of work, the decision about what to lead with, that came from judgment built over years of doing the work. The tool amplified that judgment; it didn’t replace it.

This is the thesis I keep coming back to across every AI tool I use: as execution gets faster, taste becomes the bottleneck. When anyone can ship a portfolio in a weekend, the ones that stand out are the ones with a clear point of view.

A Practical Framework for Designers

If you want to try this workflow, here’s how I’d approach it:

Phase 1 — Content (Claude): Before you touch Framer, use Claude to do the hard thinking. Feed it your resume, your case study notes, anything you’ve written. Ask it to help you identify the narrative arc of your career, suggest what to feature, and draft the copy for each section. Do multiple rounds of this. The quality of your Framer output is downstream of the quality of your content inputs.

Phase 2 — Structure (Framer AI): Use Framer’s AI generation to get a layout on screen quickly. Don’t fall in love with the first output — use it as a starting point to react to. What’s working? What feels off? Your design eye will know immediately.

Phase 3 — Polish (Framer canvas + Claude MCP): This is where the real work happens. Adjust the visual details in the Framer editor directly. For anything that needs custom code — interactions, filtering, dynamic content — use the Framer MCP plugin to bring Claude into the canvas.

Phase 4 — Ship, then iterate. The biggest trap with personal portfolios is treating them as finished objects. They’re not. Publish what you have. Add to it over time.

The Bigger Shift

What happened to me over that weekend is a preview of a broader change in how designers will work. The boundary between designing and building is collapsing — not because coding is becoming obsolete, but because the feedback loop between intention and output is getting dramatically shorter.

With the power of Framer combined with AI design workflows, we’re entering an era where creativity and speed converge — where designers and builders alike can focus on brand, strategy, and experience while the machine handles the heavy lifting of layout and responsiveness.

The question worth sitting with: if shipping no longer requires months of dev time or a five-figure freelance budget, what are you still waiting for?

The portfolio won’t build itself. But now, it almost can.

Are you using AI tools to build or iterate on your portfolio? I’m curious what’s working and what’s still broken, drop a comment below.

References

1. Brochu, A. (2025, November 9). Collaborating with Claude: How I Built a Portfolio Website with AI. Medium. https://medium.com/@alexis.brochu/collaborating-with-claude-how-i-built-a-portfolio-website-with-ai-and-lived-to-tell-the-tale-a5c3bd9d5b27

2. Mcinerney, L. (2026, April). Built a Portfolio Site With My Own AI Chatbot Using Claude Code. Medium. https://medium.com/@lovely.mcinerney/built-a-portfolio-site-with-my-own-ai-chatbot-using-claude-code-66ca39ae15b7

3. Framer. (2026). Framer MCP Plugin. https://www.framer.com/marketplace/plugins/mcp/

4. Framer. (2026, March). Workshop: Claude 4.5 Update. https://www.framer.com/updates/workshop-claude-4-5

5. Framer. (2026). Framer vs Claude Code. https://www.framer.com/compare/framer-vs-claude-code

6. FramertoAI. (2026). Framer to Claude Code Guide. https://framertoai.com/guides/framer-to-claude

7. Effloow. (2026, April). Framer Review 2026: The AI Website Builder Designers Actually Want. https://effloow.com/articles/framer-review-ai-website-builder-guide-2026

8. NxCode. (2026). AI Website Examples 2026. https://www.nxcode.io/resources/news/ai-website-examples-2026

9. Go-techsolution. (2025). Framer and AI: The Future of No-Code Website Building. https://go-techsolution.com/framer-and-ai-the-future-of-no-code-website-building-in-2026

10. Contra. (2026). Explore Framer MCP and Claude Code for Creative Design. https://contra.com/community/e9kpLE0s-explore-framer-mcp-and-claude-code

Imagine a laptop that washed ashore from a mermaid’s bedroom. Swirly gold accents, pearls tucked under the keyboard, a little fake moss for good measure — and humming inside all of it, a Raspberry Pi running Doom.

That’s the cyberdeck Annike Tan, known online as Ube Boobey, built and posted to TikTok in March. Her caption? “Fuck it. Cunty cyberdeck.” The video now has tens of millions of views. Her total DIY tech content has surpassed 32 million viewers. And she’s not alone, across TikTok and Instagram, young women are building homemade computers inside pearlescent minaudieres, Hello Kitty makeup cases, Dunkin’ Munchkin boxes, and pink seashell clutches. What started as a niche maker-community aesthetic has, in the past few weeks, exploded into something much more interesting: a design and cultural statement aimed squarely at the AI moment we’re all living through.

I’ve been watching this unfold, and I can’t stop thinking about what it means, not just as a social media trend, but as a signal about what people actually want from technology right now.

What Even Is a Cyberdeck?

The concept of a cyberdeck goes back to William Gibson’s 1984 novel Neuromancer, where the protagonist is a data thief jacking into corporate networks through a custom device wired to his brain. The word carried weight: it was anti-establishment by definition, a tool for accessing power that wasn’t meant for you.

In the decades since, the cyberdeck became a hobbyist artifact, mostly men, mostly utilitarian, mostly housed in Pelican briefcases and optimized for survival scenarios. Ham radio operators. Preppers. Hackers. The aesthetic was tactical and macho. You got the sense the builder was preparing for an apocalypse, not a dinner party.

What’s happening now is a complete subversion of that. The new generation of cyberdecks aren’t designed to survive nuclear winter. They’re designed to feel like you. Brianna, a 25-year-old software engineer in NYC, built hers inside a pink Dunkin’ promotional box and programmed a barista mini-game to run on it. A creator known as bossbratox built “Mermaid in the Shell”, a Raspberry Pi 3A+ and a tiny touchscreen installed inside a pink seashell clutch purse with a BB Q10 keyboard in white. Another creator made what she calls a “cyberduck,” an audio journal that lives inside a rubber duck. The ingenuity is wild, and the audience is overwhelmingly female, Tan says roughly three-quarters of her viewers are women.

This Is About More Than Aesthetics

Here’s what I think is really going on. These builds are a direct, embodied response to two forces that have been shaping tech culture for years: the homogenization of devices and the rise of generative AI.

Pick up any flagship laptop or phone today. The industrial design language is almost interchangeable. Aluminum or glass, rounded corners, minimal ports, muted colorways. Apple, Samsung, Microsoft, Google, all converging on the same platonic ideal of a “neutral” device. The joke used to be that you couldn’t tell the difference between a MacBook and a Xiaomi. Now it’s barely a joke.

Meanwhile, generative AI has introduced its own kind of sameness into software and creative work. Outputs that feel plausible but generic. Interfaces that optimize for efficiency but strip out personality. Tan articulated the backlash perfectly in a TikTok with nearly four million views: “What we should do with cyberdecks is gatekeep them from AI and megacorp.”

That’s not just a hot take. It’s a design philosophy. And it’s resonating because it names something a lot of people feel but haven’t said out loud: that the current trajectory of tech — faster, smarter, more automated — is also somehow less expressive. Less human. Less mine.

The cyberdeck trend is, at its core, a re-assertion of the maker’s identity over the device. And the fact that this energy is being led by women is its own kind of statement, a demographic that has historically been pushed to the margins of hardware culture is now driving one of its most viral moments.

Why This Matters to Designers and Product People

I spend a lot of time thinking about what AI is doing to the designer’s role. My own work building products with tools like Claude Code and Google AI Studio has taught me that speed of execution is increasingly not the hard part, judgment is. Taste is. The ability to know what something should feel like before you’ve built it.

The cyberdeck girls are exercising exactly that muscle, just with soldering irons instead of design software.

A few things stand out to me as genuinely instructive:

1. Constraint is a creative advantage. These builds use old Raspberry Pi boards that are, by any objective measure, underpowered for 2026. The Raspberry Pi 3A+ inside “Mermaid in the Shell” won’t run full desktop Linux gracefully. But that constraint forces creators to make deliberate choices about what their device is for. Tan loaded hers with offline files — music, books, maps, Wikipedia articles — making it intentionally less reliant on the internet. That’s a product decision with real design conviction behind it.

2. The enclosure is the experience. In traditional hardware design, the enclosure is often treated as an afterthought — the thing that protects the “real” product inside. These cyberdecks flip that. The seashell purse, the munchkin box, the Hello Kitty case — these are load-bearing narrative elements. They tell you who the device is for and what it values before you ever turn it on. That’s a lesson product designers should take seriously. The container shapes the meaning.

3. Imperfection is a feature. Exposed wires, asymmetrical hardware, visible seams — none of it signals incompetence. It signals authenticity. It says: a human made this. In an era where AI can generate images, text, and soon physical product designs that are technically flawless, the handmade artifact carries emotional weight precisely because of its imperfections. As one analysis of the trend put it, imperfection increasingly strengthens emotional connection. That’s a principle worth internalizing for any product or experience you’re designing.

4. Ownership of the stack matters. What these creators are doing is radically increasing their understanding of and control over their technology. They’re not just consumers of a device — they’re its architects. In an industry conversation dominated by “AI will do it for you,” there’s a countercurrent emerging: people who want to understand the thing they’re using. Designers who learn to code aren’t just trying to ship faster. They’re trying to close the gap between intention and execution — the same impulse driving someone to solder their own keyboard into a seashell.

The Broader Signal

I’ve written before about how “taste” is becoming the moat in an AI-assisted world. The cyberdeck movement is a vivid illustration of that thesis, but from an unexpected angle. These aren’t product designers or engineers making the argument, they’re Gen Z women on TikTok, building things that feel unmistakably theirs, and getting 32 million views for it.

The market for “personal” technology, devices that express identity rather than conform to a category, is a design space that mainstream hardware has almost entirely abandoned. Someone is going to build a business here. Maybe it looks like a customizable hardware platform. Maybe it’s a maker ecosystem targeted at the aesthetic sensibilities driving this trend. Maybe it’s something we can’t predict yet, because the people who would design it are currently too busy building their own seashell computers.

The cyberdeck girls aren’t waiting for a product that fits them. They’re building it.

That, to me, is the most important design lesson of the month.

What does “owning your technology” mean to you? I’d love to hear from designers, engineers, or anyone who’s ever felt the urge to take something apart just to make it yours. Drop a thought in the comments.

References

• Wired: “The Hottest Anti-AI Gadget Is a Cyberdeck” (April 28, 2026) — https://www.wired.com/story/cyberdecks-tiktok-ube-boobey-diy-computer-gadget/

• RUSSH Magazine: “Why Are the Coolest Girls You Know Building Cyberdecks?” (April 29, 2026) — https://www.russh.com/the-return-of-the-cyberdeck/

• Hackaday: “Mermaid Clutch-Purse Cyberdeck Is Unapologetically Girly” (May 11, 2026) — https://hackaday.com/2026/05/11/mermaid-clutch-purse-cyberdeck-is-unappologetically-girly/

• Adafruit Blog: “The Hottest Anti-AI Gadget Is a Cyberdeck” (May 12, 2026) — https://blog.adafruit.com/2026/05/12/the-hottest-anti-ai-gadget-is-a-cyberdeck/

• Newsweek: “What Is a ‘Cyberdeck’: Meet Gen Z’s New DIY Obsession” (April 6, 2026) — https://www.newsweek.com/what-is-a-cyberdeck-gen-zs-new-custom-computing-obsession-11787017

• Insight Trends World: “Cyberdeck Culture and DIY Tech Rebellion Are Reshaping Consumer Electronics” (May 2026) — https://www.insighttrendsworld.com/post/cyberdeck-culture-and-diy-tech-rebellion-are-reshaping-consumer-electronics

• Her Campus SJSU: “The Cyberdeck Trend Is Uplifting Women in Tech” (May 2026) — https://www.hercampus.com/school/sjsu/the-cyberdeck-trend-is-uplifting-women-in-tech/

• William Gibson, Neuromancer (1984) — Ace Books

On April 17, I watched a stock chart do something I’d never seen a design tool trigger before.

Anthropic launched Claude Design — a tool that turns a sentence into a working prototype — and Figma’s stock dropped seven percent the same day. Adobe slid. Wix and GoDaddy caught the downdraft too. Three days earlier, Anthropic’s chief product officer had quietly stepped off Figma’s board. The narrative wrote itself in about ninety minutes: the canvas is dead, the design tool is a commodity, just describe what you want and skip the pixels entirely.

I believed a softer version of it myself. I’d spent the previous month building a small app to help founding designers find suitable design systems for their product, bouncing between tools to see which one could take me from idea to shipped thing fastest. The gap between “I have a thought” and “I have a working screen” had collapsed so completely that the death-of-Figma story felt less like a hot take and more like a description of my Tuesday.

Then May happened, and the story fell apart in the most instructive way possible.

The plot twist nobody priced in

On May 15, Figma reported its Q1 numbers. Revenue was $333.4 million, up 46% year over year. Net dollar retention hit 139% — its highest in over two years. The company raised its full-year outlook. This is not what a disrupted business looks like. This is what a business looks like when the thing everyone thought would kill it turns out to be aimed at a slightly different target.

Five days later, on May 20, Figma shipped its own native AI design agent — one that lives directly on the canvas, reads your existing components and tokens, and edits your actual files instead of generating throwaway screens in a separate tab. You can even run several agents in parallel on the same multiplayer canvas.

So here’s the arc, start to finish, in about five weeks: a prompt-to-product tool launches, the market panics, the “disrupted” company posts a record quarter and then absorbs the disruptor’s core capability into its own surface. If you only read the April headlines, you got the story exactly backwards.

What the panic got wrong

The mistake was treating generation and coordination as the same problem.

Generating a screen is now nearly free. Claude Design, Google Stitch, Figma Weave, Canva’s AI 2.0 — every adjacent layer can now turn a prompt into something polished in seconds. That capability genuinely commoditized, fast, and the panic correctly sensed it.

But generating a screen was never the hard part of product work. The hard part is the part that happens around the screen: deciding which screen is worth building, keeping thirty people aligned on why, threading it through a design system, governing what ships, and holding the institutional memory of every decision that got you here. As one analyst put it after Figma’s earnings, generating an interface is getting cheaper everywhere — but coordinating what happens to that interface across a team of thirty people is still Figma’s problem to own.

That’s why Figma’s numbers went up during the exact window it was supposedly being killed. The generation layer got cheaper. The coordination layer — the multiplayer canvas, the shared system, the place 690,000 paying teams already live — got more valuable, because more raw output flowing through an organization means more need for somewhere to organize it.

The signal underneath the signal

There’s a quieter data point I can’t stop thinking about. A recent survey of 900 designers found that weekly AI usage for design tasks jumped from 54% to 91% in a single year, and that half of those surveyed — product and brand designers, not just engineers — have shipped AI-generated code to production. Even managers are shipping it, sometimes more than their individual contributors.

Read alongside the Figma story, that survey says something specific: AI didn’t replace the designer’s output, it relocated the designer’s attention. When generation is free, the scarce resource becomes judgment — knowing what’s worth generating, recognizing when the polished thing is wrong, and owning the decision to ship. The tools raced down to the canvas. The value floated up toward direction.

What I’m actually doing differently

A few takeaways I’d hand to anyone designing or building product right now:

Treat generation as a draft, not a deliverable. The first polished output is the cheapest part of the process and the easiest to fall in love with. The skill that’s appreciating is editing — knowing what to cut from something that already looks finished.

Invest in the layer that gets more valuable as output gets cheaper. For teams, that’s the system, the governance, the shared source of truth. For individuals, it’s taste and proximity to the real customer problem. Whatever survives commoditization is where to put your hours.

Stop asking which tool wins. Ask which layer you’re competing on. Claude Design and Figma weren’t actually fighting over the same thing — one optimized generation, the other coordination. Most “X kills Y” framings in AI are a category error in disguise.

Watch what companies do under pressure, not what markets do on launch day. The seven-percent drop was a vibe. The record quarter and the canvas agent were the answer.

The open question

Figma’s response to commoditized generation was to make generation native and keep owning coordination. It worked — this quarter. But the deeper question stays open: as AI gets better at the coordination layer too — at remembering decisions, aligning teams, governing what ships — does the durable moat move again?

My bet is that it keeps floating upward, toward the things that are hardest to specify in a prompt: knowing which problem deserves a product at all, and having the taste to recognize when the answer the machine handed you is confidently, beautifully wrong.

The month Figma was supposed to die turned out to be the month it proved where the value actually lives. The next disruption headline you read is worth running through the same test: is this tool competing on generation, or on judgment? Because only one of those is getting cheaper.

References

• VentureBeat — Anthropic just launched Claude Design, an AI tool that turns prompts into prototypes and challenges Figma (April 17, 2026): https://venturebeat.com/technology/anthropic-just-launched-claude-design-an-ai-tool-that-turns-prompts-into-prototypes-and-challenges-figma

• DesignRush — Anthropic Launches Claude Design AI Tool: https://news.designrush.com/anthropic-claude-design-launch-figma

• PYMNTS — After Claude Design Launched, Figma Raised Its Full-Year Outlook (May 15, 2026): https://www.pymnts.com/artificial-intelligence-2/2026/after-claude-design-launched-figma-raised-its-full-year-outlook/

• The Next Web — Figma builds its own AI assistant that can design alongside you on the canvas: https://thenextweb.com/news/figma-builds-its-own-ai-assistant-that-can-design-alongside-you-on-the-canvas

• Gadgetbond — Figma rolls out a native AI design agent that edits in your file (May 20, 2026): https://gadgetbond.com/figma-ai-design-agent-launch/

• Figma Learn — Release notes roundup: May 2026: https://help.figma.com/hc/en-us/articles/40219873508247-Release-notes-roundup-May-2026

• Designer Fund & Foundation Capital — AI in Design 2026: https://designerfund.com/blog/ai-in-design-2026

• The AI Insider — Figma Launches Native AI Design Agent as Revenue Surges 46%: https://theaiinsider.tech/2026/05/21/figma-launches-native-ai-design-agent-as-revenue-surges-46-amid-intensifying-competition/

My founder said something last week that I’ve been turning over ever since. Something to the effect of: designers need to be technical now. AI-native. As close to the code as possible.

My first reaction was defensive. I already annotated my specs. I already speak in tokens and components. I already sit in on engineering standups. Isn’t that close enough?

But the more I sat with it, the more I realized the gap my founder was pointing at wasn’t about syntax or terminal commands. It was about agency. The old handoff model — designer throws a Figma file over the wall, engineer interprets it, designer redlines it back — is breaking down. Not because the tools changed. Because the expectation changed. In a world where one person with Claude Code can ship a working feature in a day, a designer who can only participate in that process through screenshots and Slack messages is a bottleneck.

So I stopped being defensive and started asking a better question: what does it actually mean to be technical as a product designer in 2026?

Being Technical Doesn’t Mean Being an Engineer

The first thing to let go of is the idea that “technical” means writing production code. It doesn’t. What it actually means, for a product designer, is something closer to this:

You understand how the product is built well enough to make better decisions about how it should look and behave.

That’s it. Not shipping PRs independently. Not owning the database schema. Just closing the gap between design intent and engineering reality — which, historically, has been enormous.

According to a 2025 Figma report, 30% of designers now strongly agree that AI tools significantly enhance their efficiency, and that number is rising. But the designers getting the most out of these tools aren’t the ones using AI to generate prettier mockups. They’re the ones using it to collapse the distance between their decisions and their consequences.

There are a few concrete dimensions to this:

Reading the codebase, not just the product. Before designing a feature, open the repo. Not to understand every line — to understand shape. Where does this component live? What states already exist? What’s been built before that you could extend instead of reinvent? This is the kind of context that historically only engineers had, and it changes how you design.

Writing documentation that machines can read. Design systems are no longer just for humans. As one designer put it bluntly: if your tokens aren’t machine-readable, you’re leaving performance on the table. Your design decisions need to be expressed in a form that an AI coding agent can act on — not just a PDF that a developer reads once and ignores.

Prototyping in the medium that matters. A Figma prototype is a conversation starter. A working prototype in a browser, even a rough one, is evidence. The distance between those two things is where most product decisions go wrong.

Enter Claude Code, and Why It’s Different for Designers

Claude Code is an agentic coding tool that lives in your terminal. It reads your files, understands your project, makes code changes, and runs your app. It was built for engineers. But the designers who’ve figured out how to use it have found something interesting: it doesn’t require you to think like an engineer. It requires you to describe what you want clearly, which is something designers are already trained to do.

Meaghan Choi, the designer of Claude Code at Anthropic, doesn’t just use Claude Code as a user — she builds inside the actual codebase with it. She queries what states a component currently has, tests new features directly in production code, and explores micro-interactions at speed. Her framing is important: this isn’t about designers becoming engineers. It’s about gaining enough access to the real product that your design decisions have actual weight.

The mental model shift for designers is this: stop thinking of Claude Code as a tool that writes code for you. Think of it as a collaborator who knows the codebase and can execute what you describe.

The CLAUDE.md File: Your Most Important Design Artifact

Here’s the thing nobody tells designers when they start using Claude Code: the most important thing you’ll ever write isn’t a prompt. It’s a markdown file.

CLAUDE.md is a special file that Claude Code reads automatically at the start of every session. It’s your project’s persistent memory — the context you’d otherwise have to re-explain from scratch every single time. Think of it as the onboarding document for a new collaborator who shows up every day with no memory of yesterday.

For designers, this file is a superpower hiding in plain sight.

What to put in your CLAUDE.md:

Project overview. One sentence. What is this product? Who is it for? “This is a B2B SaaS dashboard for logistics coordinators managing last-mile delivery” tells Claude more than you think. It shapes every decision it makes.

Design system references. Where are the tokens? What are the component naming conventions? Point Claude at the source of truth. “Design tokens live in /tokens/. Always reference these — never hardcode colors or spacing values.”

Your role and context. This one matters more than it seems. Explicitly tell Claude you’re a designer, not an engineer. “I am a product designer. When I ask for code changes, explain what you’re doing in plain terms, break changes into small steps, and flag anything that might affect other components.” This single instruction changes the quality of every interaction.

Interaction and animation principles. If your product has a design language around motion — easing curves, transition durations, animation principles — document them here. Claude will apply them without being reminded every time.

What not to touch. The sections of the codebase that are off-limits or fragile. “Do not modify anything in /api/. Do not change shared layout components without flagging first.” This is your safety net as a non-engineer working in a live repo.

Known gotchas. Every project has them. The quirky workaround in the auth module. The component that’s being refactored and shouldn’t be extended. The thing that always breaks on Safari. Write them down. Claude will work around them.

The best advice on writing CLAUDE.md comes down to one principle: less is more. Don’t stuff it with everything you could possibly want Claude to know. Give it what it needs to do the work you’re actually doing, and tell it where to find the rest. A focused 100-line CLAUDE.md outperforms a bloated 500-line one every time.

Custom Slash Commands: Turning Repeated Work Into a Single Word

Once your CLAUDE.md is solid, the next unlock is custom slash commands. These are markdown files you store in .claude/commands/, and they become reusable prompts you can call with /command-name in any Claude Code session.

For designers, the use cases are obvious once you see them:

/component-audit — asks Claude to scan a specific component for inconsistencies against your design system. Spacing violations, hardcoded colors, and missing states. Run this before every design review.

/new-screen — a template prompt that walks Claude through creating a new screen: which tokens to use, which existing components to pull from, and what empty/error/loading states to include.

/copy-review — feeds a section of the UI to Claude and asks it to evaluate the copy against your brand voice guidelines (which live in your CLAUDE.md).

/accessibility-check — prompts Claude to evaluate a component against WCAG criteria and flag issues with contrast, focus states, or keyboard navigation.

The point isn’t to automate your judgment. It’s to stop spending cognitive energy on the scaffolding so you can spend it on the decisions that actually matter.

Drag, Drop, and Annotate: The Visual Workflow

One thing that surprises most designers when they start: Claude Code handles images well. You can drag a screenshot directly into the terminal window, annotate it by circling the area you want changed, and Claude will often fix it in one shot.

This changes how you use Figma in the workflow. Instead of the traditional handoff (Figma → spec → dev), you start working more like this:

1. Design the change in Figma (or sketch it)

2. Screenshot it

3. Drop it into Claude Code: “The spacing between the list items feels off — the design shows 16px, the current implementation has 8px. Fix this.”

4. Claude makes the change in the actual codebase

5. You check the live output, iterate

It’s not a replacement for careful design work. It’s a tighter feedback loop between your design decisions and their real-world consequences.

The Mindset Shift That Makes All of This Work

There’s a reason most designers stop at “I asked ChatGPT to make me a button.” The tools work. The mindset hasn’t caught up.

The designers getting the most out of Claude Code share a few things in common. They think in outcomes, not outputs — they describe what they want to happen, not how to code it. They maintain context deliberately — they invest time upfront in CLAUDE.md so they don’t waste time explaining the same things repeatedly. And they stay close to the real product — they’re not designing for a Figma file. They’re designing for the things users actually use.

Your founder’s challenge isn’t asking you to become an engineer. It’s asking you to stop designing at a distance. The tools to close that gap exist. The question is whether you’re willing to open a terminal.

A Week-One Checklist

If you’re starting this week, here’s the minimum viable version:

• Install Claude Code (desktop app or npm install -g @anthropic-ai/claude-code)

• Clone your product’s repo locally, think of it as duplicating a Figma file; you can’t break production

• Run /init In Claude Code to generate a starter CLAUDE.md

• Rewrite it from scratch with your own context: product overview, design system location, your role, what not to touch

• Make one small change — a color, a spacing value, a copy tweak — and watch it happen in the live codebase

• Create your first slash command for something you do repeatedly

One week. One terminal. One file. That’s the on-ramp.

The Open Question

Design has always been about closing the gap between intention and reality. We sketch to make ideas visible. We prototype to make interactions tangible. We test to make assumptions falsifiable.

Claude Code is another instrument in that process, one that closes the gap between design and production in a way nothing else has before.

The interesting question isn’t whether designers should use it. It’s what kind of designer you become when you do.

What’s one thing in your product you’ve always wished you could change yourself, without waiting on an engineer? Start there.

References

• Anthropic. Best Practices for Claude Code. https://code.claude.com/docs/en/best-practices

• Anthropic. Using CLAUDE.md Files: Customizing Claude Code for Your Codebase. https://claude.com/blog/using-claude-md-files

• Builder.io. How to Write a Good CLAUDE.md File (February 2026). https://www.builder.io/blog/claude-md-guide

• Builder.io. Claude Code for Designers (March 2026). https://www.builder.io/blog/claude-code-for-designers

• Christina Yang, Medium. Using Claude Code SMARTLY as a Product/UX Designer (July 2025). https://medium.com/@christina0w0

• David Robinson, Medium. AI in Product Design: Where We Are Now in 2026 (February 2026). https://davidrdesign.medium.com

• Figma. AI Data Report 2025. https://figma.com/reports/ai

• HumanLayer Blog. Writing a Good CLAUDE.md (November 2025). https://www.humanlayer.dev/blog/writing-a-good-claude-md

• Startup House. The Future of Product Design: Building AI-Native Digital Services (March 2026). https://startup-house.com/blog/future-of-product-design-ai-workflows-2026

• Tyler Burnam, Medium. How I Use Claude Code (June 2025). https://tylerburnam.medium.com/how-i-use-claude-code

It’s not that I forgot. It’s that the note was written for a past version of me, with no connective tissue to anything I was working on at the time. It sat there — inert, unlinked, slowly becoming irrelevant.

That’s the quiet failure mode of most knowledge systems for designers. We’re excellent at capturing. We’re terrible at accumulating.

The Post That Broke My Morning

In April 2026, Andrej Karpathy — former Director of AI at Tesla, co-founder of OpenAI, and one of the most trusted voices in the AI field — shared something unexpected. He tweeted that a large fraction of his recent AI usage had shifted away from code generation and toward building personal knowledge bases on research topics he cared about. Medium

The follow-up was a GitHub Gist: a single markdown file he called an “idea file.” The post went viral — 16 million views — and the Gist hit over 5,000 stars within days. It resonated because it solved a problem every knowledge worker quietly has: knowledge bases that collapse under their own maintenance weight. Starmorph

The core idea is deceptively simple. Instead of using AI primarily to write code, Karpathy was using it to compile and maintain an organized, summarized wiki from raw sources — articles, papers, notes — and then using Obsidian to read and navigate it. The AI writes the knowledge base. You read it. Medium

I read the thread at 7am and didn’t open Figma until noon.

What’s Actually Different Here

Most people interact with AI like a search engine. You ask something, get an answer, and move on. Nothing accumulates. Karpathy proposed something different: a plain text knowledge base — a personal wiki — fed directly to an LLM like Claude. No vector databases, no RAG pipelines. Just markdown files and a long context window. MindStudio

The architecture has three layers. Raw sources — your immutable reading material. A wiki — LLM-generated summary pages, cross-references, and concept maps. And a schema file (CLAUDE.md) that turns Claude from a generic chatbot into a disciplined wiki maintainer. Substack

At the time of his post, Karpathy’s wiki on a single research topic had grown to approximately 100 articles and 400,000 words — longer than most PhD dissertations — without him writing any of it directly. Starmorph

What makes this different from a Notion database or a Roam graph isn’t the technology. It’s the workflow inversion. You stop being the librarian. You become the curator.

Why This Matters Specifically for Designers

Designers are knowledge workers with an unusual problem. Our best thinking is scattered across multiple surfaces: Figma annotations, Notion docs, Miro boards, Slack threads, voice memos after a long commute. We generate a huge amount of insight — about users, systems, patterns, decisions — and almost none of it compounds.

The LLM wiki pattern changes that relationship directly.

Imagine a vault where every design critique you’ve ever written, every usability finding, every competitor teardown, every principle you’ve articulated — is stored as plain markdown and queryable by Claude. Not searchable by keyword. Queryable. You could ask: “What have I learned about onboarding flows across the three products I’ve worked on?” and get a synthesized answer grounded in your own work.

One product design leader described switching his entire note-taking workflow to Obsidian specifically because Claude Code could have direct access to his stash of saved articles — without MCP complexity, without data leaving his machine, and without vendor lock-in. Polgarp

For design engineers especially — people who are already comfortable in markdown, already thinking in systems — this is a natural extension of how we already work.

A Practical Starting Point (No Code Required)

You don’t need Claude Code or a terminal to start. The simpler version works in Claude’s chat interface and Obsidian’s free desktop app.

Step 1 — Build the vault structure. Create three folders: sources/ (raw articles, screenshots, research you clip), wiki/ (synthesized notes), and a root CLAUDE.md that tells Claude what kind of knowledge base this is and how to maintain it.

Step 2 — Define what goes in. Before ingesting anything, answer: what is this wiki about, and what sources will feed it? The answer shapes how Claude organizes everything that follows. For a founding designer, that might be: UX research methodologies, design system decisions, competitor product teardowns, and principles I keep returning to. Medium

Step 3 — Ingest and query. Drop a raw source into sources/. Paste its contents into Claude with the instruction: “Read this and add a wiki page to my design knowledge base. Cross-reference anything that connects to existing entries.” Paste the output back into your wiki/ folder as a new markdown file.

Step 4 — Ask it things. The real payoff comes when the wiki has 20–30 entries. Each new note makes Claude more useful. The system compounds. Ask it: “What are my recurring patterns in how I approach navigation design?” or “Synthesize everything I know about design handoff friction.” MindStudio

Obsidian’s canvas feature can turn your wiki into a spatial knowledge graph — nodes connected by relationships, visually navigable the way a whiteboard is. For visual thinkers, this is the interface that finally matches how design thinking actually works. Agrici Daniel

This Is Also a Personal Learning System

The pattern isn’t just for work. Karpathy’s insight connects to a 1945 vision by Vannevar Bush called the Memex — a personal, curated knowledge store where the connections between documents are as valuable as the documents themselves. Medium

For anyone trying to learn in the margins of a busy job — a designer picking up frontend skills, someone studying systems thinking, a founder trying to understand a new market — this is a more honest model than the typical “read more books” advice. You’re not just consuming. You’re building a structure that knows what you know.

The question worth sitting with isn’t whether Obsidian or Claude is the right tool. It’s what a system would look like where your learning actually accumulates — where the insight from a paper you read in 2023 shows up, connected, when you need it in 2026.

Most knowledge systems are landfills. This one is a library that builds itself.

A Forward-Looking Question

Karpathy framed the LLM wiki as the third phase of a shift in how humans and AI collaborate — after vibe coding and agentic engineering, this is the phase where AI manages knowledge, not just code. The human becomes a curator, not a writer. Starmorph

For designers, that reframing is worth taking seriously. We’ve spent years arguing that design is thinking, not making. Here’s a system that offloads the making of notes entirely — so the thinking can compound.

What would your design practice look like if every insight you’d ever had was one question away?

References

• Karpathy, A. (2026). llm-wiki.md [GitHub Gist].

• Joshi, U. (2026, April). Andrej Karpathy’s LLM Wiki: Create your own knowledge base. Medium. https://medium.com/@urvvil08/andrej-karpathys-llm-wiki-create-your-own-knowledge-base-8779014accd5

• Starmorph. (2026). How to Build Karpathy’s LLM Wiki: The Complete Guide. https://blog.starmorph.com/blog/karpathy-llm-wiki-knowledge-base-guide

• MindStudio. (2026). What Is Andrej Karpathy’s LLM Wiki? https://www.mindstudio.ai/blog/andrej-karpathy-llm-wiki-knowledge-base-claude-code

• Polgár, P.P.B. (2026, February). Knowledge workflow 2026 updates: Obsidian, Claude. https://polgarp.com/blog/Knowledge-workflow-2026-updates/

• Halpin, C. (2026, January). Using Claude Code for Product Design. https://clintonhalpin.com/blog/using-claude-code-for-product-design/

• AI Maker. (2026). How I Took Karpathy’s LLM Wiki and Built an AI-Powered Second Brain in Obsidian.

Yesterday, April 17th, Anthropic launched Claude Design — and if you blinked, you might have missed just how seismic the timing is.

Figma’s stock dropped 7%. Anthropic’s own Chief Product Officer resigned from Figma’s board just three days before the announcement. And designers across the internet simultaneously asked the same question I’ve been sitting with all morning: Is this the moment the pipeline finally becomes the product?

I’ve been living inside this question for a while. Over the past few months, I’ve been building a communication practice tool — an app to help founding designers rehearse high-stakes workplace conversations — using Claude Code as my primary build environment. The experience has been illuminating, sometimes frustrating, and deeply instructive. Claude Code plans thoroughly. It reasons about architecture before touching a file. But it also requires you to think like a systems designer, not just a visual one. The terminal is a cold place to start from a feeling.

That tension is exactly what yesterday’s launch is designed to resolve.

What Claude Design Actually Does (And Why It’s Different)

Claude Design is a new Anthropic Labs product that lets you collaborate with Claude to create polished visual work like designs, prototypes, slides, one-pagers, and more — powered by Claude Opus 4.7, the company’s most capable vision model.

But the feature that caught my eye isn’t the prompt-to-prototype generation. It’s the handoff.

When you’re happy with a prototype, Claude Design packages it as an implementation bundle — components, design tokens, copy, and interaction notes — which you pass directly to Claude Code for production implementation.

This is the missing link. For anyone who’s spent time in either tool independently, this feels less like a new product and more like a resolved argument. Claude Design gives you the visual scaffolding. Claude Code gives you the depth of execution. Together, they create something neither could do alone: a fluent, continuous pipeline from idea to shipped feature.

Teams at Brilliant reported compressing what typically required 20+ prompts in competing tools down to just 2 in Claude Design. Datadog described collapsing a week-long cycle of briefs, mockups, and review rounds into a single conversation.

Why the Handoff Has Always Been the Real Problem

Anyone who’s worked on a product team knows that the design-to-engineering handoff is where intent goes to die. A Figma file gets handed over, and the receiving engineer — doing their best — makes dozens of micro-decisions about spacing, behavior, and edge cases that the designer never specified. By the time it ships, the original vision has been translated, then re-translated, into something adjacent to what was imagined.

The problem isn’t skill. It’s medium. Figma communicates in statics. Jira communicates in tickets. Neither speaks fluently in intent.

For engineers, Claude Design bridges the design-to-code gap: you get HTML or component code that’s already been iterated on and approved. You’re not rebuilding a Figma mockup — you’re extending it. Implementing features, not reinterpreting specifications.

That’s a quiet revolution buried in a product announcement. The artifact is no longer a handoff. The artifact is the conversation.

What I’ve Learned Building With Claude Code (Before Yesterday)

My own experience with Claude Code revealed something I didn’t expect: the tool’s greatest strength isn’t speed. It’s planning depth.

When I’d prompt Claude Code to build a new feature for my practice tool, it would pause. Analyze the existing architecture. Propose a plan before touching a single file. Anthropic’s own internal testing found that unguided attempts succeed roughly 33% of the time — but a structured planning phase, where Claude drafts a spec before implementation begins, changes those odds dramatically. I felt that difference firsthand. The features that landed cleanest were the ones where I gave Claude Code room to think before it built.

The challenge was always the front door. Starting from a terminal with a vague creative idea — “I want this to feel warmer, more conversational” — is like trying to describe a painting over the phone. Claude Code can execute with precision. But you have to hand it something precise to execute on.

This is exactly where Google AI Studio had an edge in my earlier experiments. It generated a visually polished UI fast. Loose, sometimes — but fast. My practical takeaway became this: use quick visual tools to generate a brief, then hand that brief to Claude Code for depth. What Claude Design does is collapse that two-tool workaround into a single, intentional pipeline.

The Implications for Designers and Product People

Let me be direct about what this means practically, because the temptation is to either panic or dismiss it.

The skills that matter are shifting, not disappearing. You still need taste, judgment, and principles. You need people who understand human psychology and business strategy. You don’t need everyone to be a Figma expert — that bar moves. And the design-to-code handoff becomes a conversation, not a translation.

The founding designer role gets more leverage, not less. If you’re a designer who’s been learning to build — who’s gotten comfortable in a terminal, who can read a component tree — you’re about to have significantly more surface area to work with. The tools are catching up to the instinct you’ve already been developing.

Exploration becomes a professional advantage again. One of design’s dirtiest secrets is that constraint isn’t always philosophical — it’s often just time. Even experienced designers have to ration exploration; there’s rarely time to prototype a dozen directions, so you limit yourself to a few. Claude Design changes that calculus. When exploration is cheap, the quality of what you ship stops being limited by iteration speed and starts being limited by the quality of your judgment.

Treat the pipeline as a first-class design decision. The question is no longer “what tool do I use?” It’s “how do these tools talk to each other?” Designers who think in workflows — who are intentional about where ideation ends and execution begins — will build faster and more coherently than those who treat each tool in isolation.

The Open Question

Here’s what I’m still sitting with: Claude Design and Claude Code create a continuous pipeline from idea to code. But pipelines optimize for throughput, and design isn’t always a throughput problem.

Some of the best design decisions I’ve made came from friction — from spending a week in a single Figma file, moving things two pixels, arguing with myself about whether a button should say “Continue” or “Next.” Compression is powerful. But so is resistance.

The designers who thrive in this new environment won’t be the ones who adopt every tool fastest. They’ll be the ones who know when to let the pipeline accelerate and when to slow it down on purpose — when the friction is the point.

That’s not a skill any AI tool can give you. It’s the one you’ve been building all along.

What’s your experience been using Claude Code or similar AI tools in your design workflow? I’d love to hear what’s working — and what’s still frustrating — in the comments.

References

1. Anthropic. (2026, April 17). Introducing Claude Design by Anthropic Labs. https://www.anthropic.com/news/claude-design-anthropic-labs

2. Constant, A. (2026, April 17). Anthropic launches Claude Design, a new product for creating quick visuals. TechCrunch. https://techcrunch.com/2026/04/17/anthropic-launches-claude-design-a-new-product-for-creating-quick-visuals/

3. VentureBeat. (2026, April 17). Anthropic just launched Claude Design, an AI tool that turns prompts into prototypes and challenges Figma. https://venturebeat.com/technology/anthropic-just-launched-claude-design

4. Muzli Blog. (2026, April 18). Getting Started with Claude Design: A Collaborator for Your Design Workflow. https://muz.li/blog/getting-started-with-claude-design

5. Smart WebTech. (2026). Claude Code: Workflows and Best Practices 2026. https://smart-webtech.com/blog/claude-code-workflows-and-best-practices/

6. Yeh, K. (2026, March). A Designer’s Guide to Claude Code. Medium / Bootcamp. https://medium.com/design-bootcamp/a-designers-guide-to-organizing-ai-skills-and-tools-in-claude-code-f87477c35b82

Something quietly radical happened in a session at the Moscone Center in San Francisco last week. Amid a week of breathless announcements about agentic AI and billion-dollar infrastructure bets, one breakout session title cut through everything else on the agenda:

“AI Without Design Is Just Faster Dysfunction.”

It wasn’t a keynote. It wasn’t Jensen Huang or Dr. Fei-Fei Li. It was a roundtable, the kind that gets scheduled in parallel with five other things and fills up anyway, because people recognize the truth of a thing before they can articulate it. That sentence is the subtext of everything that happened at HumanX 2026.

I’ve been watching the AI conference circuit closely, and HumanX has carved out a distinct lane. Where other events still orbit model benchmarks and funding rounds, HumanX is fundamentally a conference for people who have to do something with AI in the real world. Over 6,700 leaders from 79 countries attended over four days. The vibe, as one attendee put it, was less “look what we built” and more “okay, now what.”

What emerged wasn’t a neat thesis. It was more like a collective exhale and a hard question: now that AI can execute, what exactly are we executing toward?

The Three Waves, and Why Wave Three Is a Design Problem

Jensen Huang’s framing of AI’s progression was the mental model everyone left with. He mapped it in three waves: Wave 1 was generative (can you produce?), Wave 2 was reasoning (can you think?), and Wave 3, where we are now, is agentic: can you take a goal stated in plain English and see it through end-to-end?

The implications are stark. Within one to two years, the argument goes, a non-technical founder will be able to describe a business problem and have an agent execute the solution, not draft a proposal, not outline a plan, but actually integrate systems, read documentation, iterate, and deliver.

Here’s what I keep turning over: if the execution layer collapses, what remains? The answer, which surfaced repeatedly across sessions, was taste. Inside OpenAI, engineers apparently no longer write code; they guide agents that write code. Eighty percent of their time is now judgment: knowing what the AI got wrong, what to try next, and whether the output is actually right.

That’s a designer’s job description. It has always been a designer’s job description.

What’s changing is that this judgment, this capacity to see the gap between what was produced and what was intended, is no longer a soft skill sitting adjacent to “real” technical work. It’s becoming the primary competency. The people who know what good looks like are suddenly in the most valuable seat.

The Clarity Crisis Is a Design Crisis

Another session that deserves more attention than it got: “The Clarity Crisis: Why AI Breaks Between Systems, Teams, and People.”

This is the quiet failure mode that doesn’t make headlines. Organizations are deploying AI at speed, and they’re discovering that their actual experience gaps — the places where the product breaks down, where users feel confused or abandoned, where the handoff between human and machine is jarring — don’t disappear. They amplify.

Speed doesn’t fix broken experience design. It scales it.

I’ve seen this firsthand working on AI-assisted products. When you use tools like Claude Code or Google AI Studio to build fast, you can ship a working prototype in hours. The risk isn’t that the AI gets the logic wrong — it’s that no one has thought about the experience at the seam. Where does the AI hand off to a human? What does the user see when the agent is “thinking”? How does the interface communicate uncertainty? These are design questions, and they’re being left on the floor because the teams moving fastest don’t have a designer in the room, or don’t have one in the right room.

The HumanX framing was pointed: experience design isn’t the cleanup. It’s the strategy.

The Model Is Commoditizing. The Problem Isn’t.

One of the sharpest takeaways from the conference came out of a discussion about Open Evidence — a company with 70 employees and a $12 billion valuation, where more than 60% of U.S. physicians reportedly use their product daily. They don’t own a model. They own a problem.

The venture investors on stage were explicit: the companies winning right now aren’t the ones with the best technology. They’re the ones closest to the customer problem. The ones who built backward from “what does this person actually need?” rather than “what can our model do?”

For designers, this is vindicating and clarifying at the same time. We’ve spent years arguing that user research and problem framing matter. The market is now structurally forcing that point. When the model improves weekly and any team can access the same foundation, the only durable advantage is a deeper understanding of the problem than your competitor has.

This is also a warning. If your product strategy is primarily “we have a better model,” that moat is evaporating. If your strategy is “we understand this user’s context more precisely than anyone,” you have something worth building on.

A Framework for Designers Navigating the Agentic Shift

Drawing from the week’s themes, here’s how I’d translate HumanX’s signal into a working frame for product designers:

1. Design the judgment layer, not just the interface. In agentic products, the user isn’t always in a dialogue with the AI — sometimes they’re reviewing outputs, approving actions, or overriding decisions. Design for those moments. The review screen is as important as the prompt box.

2. Map the seams. Where does AI stop and human start in your product? Those transitions are the highest-risk experience moments. Draw them explicitly. Prototype them. Don’t let engineering decide what they look like by default.

3. Treat taste as a competency, not a trait. If execution is being automated, your team’s ability to evaluate quality — to say “this isn’t right yet” and articulate why — becomes a measurable skill. Build processes that develop it. Create a critique culture. Do design reviews on AI outputs the same way you’d review a designer’s work.

4. Build from the problem, not the capability. Start every AI feature with: what is the user actually trying to accomplish, and what gets in their way? Not: what can our model do that we haven’t surfaced yet?

The Open Question

HumanX ended with more tension than resolution, which is probably appropriate. Al Gore warned the conference that knowledge-work jobs face genuine displacement. Startup founders argued AI is “freeing humans from work they don’t want to do.” Neither position is wrong. Both miss the harder design challenge: if AI reshapes what people do at work, someone has to design the new workflows, the new interfaces, the new mental models for how people understand their own agency.

That’s not an engineering problem. It’s not even purely a product problem.

It’s a design problem.

And if the industry doesn’t bring designers into that conversation at the strategy level — not at the cleanup stage, not at the “make it look nice” stage — we’ll build a very capable, very efficient, and deeply dysfunctional future.

The session title said it plainly. Now someone has to do something about it.

What’s the design challenge you’re seeing most in your AI products right now? I’d genuinely like to know — drop it in the comments.

References

• HumanX 2026 official agenda and session descriptions: humanx.co/agenda

• GTMnow Newsletter — “AI Conference HumanX Takeaways and Frameworks” (April 10, 2026): thegtmnewsletter.substack.com

• Bastille Post — “HumanX conference wraps up amid warnings on AI’s double-edged impact” (April 10, 2026): bastillepost.com

• HumanX session: “AI Without Design Is Just Faster Dysfunction: The CX and EX Conversation Nobody Is Having” — Customer Experience Peer [X]Change

• HumanX session: “The Clarity Crisis: Why AI Breaks Between Systems, Teams, and People” — Customer Experience Peer [X]Change

• Bloomberg — “Anthropic Dominates the Discussion at the HumanX AI Conference” (April 9, 2026)

• NVCA partnership announcement: nvca.org/event/humanx

I left Moscone Center on Thursday thinking about plumbing. Not literally — but about the invisible infrastructure that makes the things we design actually work, and what happens when that infrastructure becomes the product.

HumanX 2026 was the kind of conference where the most important conversation wasn’t the one on the main stage — it was the one happening in the hallway right after it ended. This year, that conversation was almost always about the same thing: inference. Not models. Not benchmarks. Not which foundation lab is winning the capability race. The question everyone kept circling back to was far more uncomfortable: how do you actually run this at scale without bleeding money?

For those of us who spend our days thinking in user flows and component libraries, the topic might feel distant. It isn’t. The economics of AI inference are quietly reshaping every product decision we make — from which features get built to how quickly users hear back from an AI assistant to whether a startup survives its Series A.

A Paradox That Should Alarm Every Product Person

Here’s the headline nobody put on a slide but everyone was living with: AI token costs have dropped by roughly 280x over the past two years, and yet the average enterprise AI budget has ballooned from $1.2 million annually in 2024 to $7 million in 2026. Some Fortune 500 companies are reporting monthly AI inference bills in the tens of millions of dollars.

The paradox is almost too clean: intelligence is getting cheaper. Deploying intelligence is getting more expensive. And the companies that don’t understand the difference between those two things are going to spend the next two years very confused about their burn rate.

“Don’t confuse the deflation of commodity tokens with the democratization of frontier reasoning.”

That line came from Gartner’s research published just weeks before the conference — and it echoed through basically every “AI in production” conversation I had at HumanX. The cheap tokens are for simple, high-frequency tasks. The expensive compute is for the agentic, reasoning-heavy workflows that teams actually want to build. And as agentic AI scales — where models don’t just answer questions but execute tasks end-to-end across live systems — the cost profile changes entirely.

Jensen’s Three Waves, and Why We’re at the Expensive One

One of the clearest frameworks to emerge from the conference was Jensen Huang’s articulation of three waves of AI, which GTMnow captured well in their post-conference recap. Wave one was extraction: “What is this? Where is that?” Wave two was reasoning: “summarize this, analyze that.” Wave three — where we are now — is autonomous execution: “build this for me, figure it out and report back.”

Each wave is exponentially more computationally demanding than the last. An extraction query might cost fractions of a cent. An agentic workflow that reads documentation, integrates with three APIs, iterates on a result, and then writes back to a system of record? That can consume hundreds of times more tokens — and that compute runs constantly, not just when a user clicks a button.

Deloitte puts inference at roughly two-thirds of all AI compute in 2026, up from one-third in 2023. And the market for inference-optimized chips is projected to hit $50 billion this year alone. We have moved from a world where the interesting infrastructure question was “can you train a model?” to one where it’s “can you serve a model efficiently at scale, to millions of users, 24 hours a day, without going broke?”

What This Looks Like in Practice

There were some fascinating real examples of this playing out. NVIDIA’s partnership with Together AI and Decagon — serving production inference for a multimodel voice stack on Blackwell GPUs — reportedly cut cost per query by 6x compared to proprietary closed-source models. The combination of speculative decoding, smart caching, and auto-scaling pushed response times under 400 milliseconds even under heavy load. That’s not a research result. That’s a deployed product.

Meanwhile, Anthropic (which apparently hit a $3 billion revenue run rate, per hallway conversations) is betting that owning silicon is the key to controlling cost-per-token at scale — partnering with Google and Broadcom to build custom AI chips. At their growth trajectory, that math starts to matter enormously.

The broader structural shift is this: we’re moving toward hybrid AI infrastructure — centralized data centers for heavy reasoning workloads combined with localized on-premise systems for lower-latency inference and redundancy. Open models are narrowing the gap with proprietary ones fast enough that running capable AI locally is now a realistic option for enterprises. A year ago that wasn’t really true.

Why Designers Should Actually Care About This

I’ll be honest: when I first started hearing inference economics discussed this intensely at a conference, I felt a familiar instinct to tune out. Infrastructure is for engineers. Tokens are for engineers. My job is the experience, the interface, the thing the user touches.

But spending a few days at HumanX, surrounded by product leaders and founders who are actually shipping AI products at scale, made me see this differently. The economics of inference are now a design constraint. And design constraints are exactly where designers do our best work.

Think about it this way. When you’re designing a feature that involves an AI-powered background agent, something that continuously monitors, synthesizes, and surfaces insights, you’re not just designing a UX pattern. You’re making decisions that have direct cost implications. An always-on monitoring agent consumes compute continuously, even when no user is actively in the product. The design choice of “this runs in the background” is also, invisibly, a line item on the infrastructure budget.

This is already changing how some product teams work. At the session “AI Without Design Is Just Faster Dysfunction” (which had the best title of the conference, honestly), the conversation kept returning to the same tension: teams are shipping AI features that their users love and that their finance team cannot explain. The experience and the economics are getting designed in separate rooms, and it shows.

For designers and product people: three things to act on

1. Learn the difference between token-cheap and token-expensive interactions. High-frequency, simple tasks (search, lookup, basic summarization) can and should route to smaller, cheaper models. Reserve frontier reasoning for the moments that genuinely require it. This is model orchestration, and it’s increasingly a product design decision, not just a backend one.

2. Design with cost as a feedback signal. If a feature’s inference costs scale faster than its user value, that’s a design problem, not just an engineering one. The most elegant AI features are often the ones that accomplish the most with the fewest tokens. Constraint is good design.

3. Understand what “always-on” really means. Agentic features that run continuously represent a fundamentally different cost model than on-demand features. Before shipping something that lives in the background, ask: What’s the hourly cost of this feature when nobody is actively using it? The answer might reshape what you build.

The Horizon

There’s something I keep coming back to from the week. At a conference called HumanX, you’d expect the conversations to be mostly about what AI can do for people. And they were. But the most honest, eyes-open conversations were about what it costs to actually build those things, and who’s going to pay for it.

Gartner forecasts that inference costs for frontier models will drop 90% by 2030. But in the same breath, they note that token consumption will rise faster than costs fall, meaning total inference spend will keep climbing. The commodity intelligence is becoming nearly free. The intelligence that actually matters, multi-step reasoning, agentic workflows, and spatial understanding, remains scarce and expensive.

What this means for designers is still unfolding. But I left Moscone with a working hypothesis: the most important design skill of the next few years might not be prototyping, or systems thinking, or even AI fluency in the abstract. It might be the ability to design intelligence frugally, to make AI products that feel effortless to the user while being genuinely efficient under the hood.

We’ve been designing for screens for decades. We’re about to start designing for compute budgets, too. And honestly? I think that’s going to make us better designers.

What’s your read on AI inference as a product constraint? I’d love to know what your team is navigating — leave a comment or find me on X.

References

1. Gartner (March 2026). By 2030, inference on a 1T-parameter LLM will cost 90% less than in 2025. gartner.com

2. GTMnow Newsletter (April 10, 2026). AI Conference HumanX Takeaways and Frameworks. thegtmnewsletter.substack.com

3. Deloitte (February 2026). Why AI’s next phase will likely demand more computational power, not less. deloitte.com

4. Oplexa (March 2026). AI Inference Cost Crisis 2026: Why Your AI Bill Is Exploding. oplexa.com

5. NVIDIA Blog (February 2026). Leading Inference Providers Cut AI Costs by up to 10x With Open Source Models on Blackwell. blogs.nvidia.com

6. Digitimes Asia (March 2026). AI shifts to inference as costs rise, memory constraints emerge. digitimes.com

7. VAST Data (December 2025). 2026: The Year of AI Inference. vastdata.com

8. HumanX 2026 (April 2026). Official conference agenda and tracks. humanx.co

9. LLM Stats (April 2026). AI Trends 2026 — LLM Statistics & Industry Insights. llm-stats.com

Google AI Studio gave me a beautiful UI in one click. Claude Code gave me a product worth using.

I wanted to build a communication practice tool for founding designers. The kind of app that lets you rehearse high-stakes conversations — pushing back on a CEO’s bad idea, negotiating with a skeptical engineer, defending a design decision to a board — before they happen in real life.

So I built it twice. Once in Google AI Studio. Once in Claude Code.

Same prompt. Same product idea. Completely different results, and not in the way I expected.

What Google AI Studio Got Right (and Fast)

Google AI Studio delivered a working, beautiful interface in one click. I’m not exaggerating. The dashboard it produced had a bold hero card with confident typography, metric widgets showing confidence scores and scenario progress, difficulty-tagged recommendation cards, and clean sidebar navigation. It looked like a product someone would pay for.

If I’d been presenting this to a stakeholder, I could have done it the same day I had the idea. That’s a genuinely remarkable thing. The speed of going from concept to something visually compelling used to take days. Now it takes minutes.

But then I tried to actually use the role-play feature.

The scenarios were thin. Three options total. No context about who you were talking to, what their personality was, what the stakes were, what a realistic outcome might look like. You’d pick a scenario title — “Push back on the CEO’s bad idea” — and get dropped into a conversation with almost no setup. It was hard to immerse. It felt more like a demo than a tool.

The UI had done its job — made the product look credible. The experience underneath hadn’t kept up.

What Claude Code Got Right (and Why It Took Longer)

Claude Code took more time to get started. There’s setup involved: you’re working in your terminal, against your actual codebase, with context files you write yourself. It’s not a one-click experience. But the planning behavior was immediately different.

Before building anything, Claude Code mapped the product. It thought through what a role-play scenario actually needs to work — not just a title, but full context: who is the other person, what do they want, what’s their working style, how resistant are they likely to be. It generated difficulty levels so you could calibrate the pressure. And it produced significantly more scenarios — enough that the feature felt like a real content library rather than a proof of concept.

The dashboard it produced was visually flatter. More functional than designed. If you put the two side by side, Google AI Studio’s version wins on aesthetics immediately. But when you use Claude Code’s role-play feature — when you actually sit down to practice a conversation — you can feel the difference in the thinking that went into it.

One version was designed to look like the product. The other was designed to be the product.

The Real Difference Isn’t UI vs. Logic

It would be easy to frame this as a design vs. engineering trade-off. Google AI Studio for visual execution, Claude Code for technical depth. But I think that undersells what’s actually happening.

The more accurate frame is execution speed vs. planning depth.

Google AI Studio optimizes for the feeling of progress. It produces something impressive, fast, and asks questions later. That’s genuinely useful — there are moments in product development where you need to make an idea feel real before you can get feedback, buy-in, or clarity on whether it’s even worth building.

Claude Code optimizes for the quality of the outcome. It slows down to think before it builds. It asks: what does this feature actually need to deliver on its promise? What are the edge cases? What would make a user come back? That thinking shows up in the output — not always visually, but functionally.

Neither approach is wrong. They serve different moments in the same building process.

A Framework for Founding Designers

If you’re a designer or PM building with AI tools, here’s how I’d now think about the two:

Use Google AI Studio when you need to make an idea real fast. Pre-stakeholder meeting. Early user testing. Validating whether the concept even resonates before you invest in the details. Its visual output is strong enough to generate a genuine reaction. Use that reaction as product research.

Use Claude Code when you need the idea to actually work. Once you know the concept is worth building, Claude Code will plan it more rigorously than you might on your own. Give it context — a short PRD, a list of user scenarios, a note on what the experience needs to feel like — and it will surface depth you didn’t ask for.

Treat the Google AI Studio version as a brief for Claude Code. The UI it generates is an excellent visual spec. The gaps it reveals — thin content, missing context, features that look good but don’t work — tell you exactly where Claude Code needs to go deeper.

The workflow that’s emerging among serious builders is roughly: prompt to prototype in AI Studio, then hand it to Claude Code to build the version that actually delivers. One tool for the idea. One tool for the product.

The Judgment Gap

Here’s what neither tool tells you, and what I keep coming back to after running this experiment.

Both tools will give you something that looks and functions like a product surprisingly quickly. The gap between “this exists” and “this is good” is yours to close. Google AI Studio’s version of my role-play feature looked credible. It just didn’t work as an actual practice tool — because making something immersive requires understanding what immersion means to the user, and that’s a product judgment no tool makes for you.

Claude Code got closer, because it was planned. But it still needed me to tell it what mattered.

As the “prompt to product” cycle keeps compressing, the real leverage for designers isn’t knowing which AI tool to use. It’s having a clear enough product instinct to know when the thing you’ve built is actually good — and when it just looks like it is.

That instinct is still entirely human. For now, it’s also the last real differentiator.

What does your two-tool workflow look like — and where do you feel the gap between “looks done” and “actually done” most acutely?

References

• Google Firebase Blog. “Vibe Code to Production with Google AI Studio.” March 2026. blog.google

• FindSkill.ai. “Google AI Studio vs Claude Code: Which Builds Full-Stack Apps Faster?” March 2026. findskill.ai

• Context Studios. “The Complete Guide to Vibe Coding in 2026.” February 2026. contextstudios.ai

• Builder.io. “Claude Code for Designers.” March 2026. builder.io

• Jock.pl. “Google AI Studio vs Claude Code, Anthropic’s Moment (Mar 2026).” March 2026. thoughts.jock.pl

• Stormy AI Blog. “The 2026 Founder’s Guide to the 10-Minute AI Playbook and Claude Code.” March 2026. stormy.ai

• Product Hunt. “The Best Vibe Coding Tools in 2026.” March 2026. producthunt.com