Stop saying you're AI-native: start showing it Cisco's VP of Design Jason Cyr explains what it really means to be AI-native JASON CYR SEP 20, 2025 14 2 Share Jason Cyr is the VP of Design at Cisco, leading the charge to make enterprise security intuitive through AI. He's looking for designers who build first and design second. The best way to understand AI's potential isn't to design for it—it's to build with it, break it, and push it until you discover what's actually possible. Recently, I was talking to a designer about their AI experience. They showed me some beautifully crafted chat experiences they'd designed. "Great," I said. "Now show me what YOU'VE built with AI. What agents have you created? What problems have you solved with Cursor? Which MCP servers are you running?" They were not sure how to respond. They'd been designing AI experiences for a couple of years but had never actually pushed these tools to their limits. They were painting pictures of cars without knowing how to drive. That conversation crystallized something I'd been sensing – AI-native isn't about your professional experience designing AI interfaces. It's about your personal obsession with utilizing AI tools to address real-world problems. The real AI-native test I've been posting a lot recently about AI-native experience, and this is what led to Josh and I discussing this important idea: AI-native isn't really about your professional experience designing for AI. It's more about your personal obsession with using AI tools. My original LinkedIn post about scaling the AI Design org at Cisco. Being AI-native means you can't help but experiment with every new model, build tools to solve your own problems, and push AI systems until they break—not because it's your job, but because you're genuinely curious about what's possible. I'm realizing quickly that our customers don't have this experience yet. They're still figuring out the basics of ChatGPT and other tools. That's exactly why we need designers, researchers, and Product Managers who've gone deep—who've been living in this world, breaking things, building things, forming opinions through hands-on experimentation. You develop taste by using AI constantly, not by designing interfaces for it. The Human in the Loop Practical insights for design leaders navigating AI By Jason Cyr The fundamental difference The distinction between designing for AI and being AI-native isn't subtle—it's fundamental. Designing AI experiences means creating chat interfaces, writing microcopy for bots, and making AI responses feel human. It's a job. Being AI-native is different. It's when you find yourself building agents to automate repetitive tasks, not because someone asked you to, but because you couldn't stand doing them manually anymore. It's having strong opinions about Claude vs GPT-4 vs Gemini because you've pushed each to their limits on real projects. It's using Cursor to write MCP servers for Claude Desktop because you need to connect it to your workflow. It's knowing which coding assistant works best for different tasks because you've actually struggled with their output and know their strengths and weaknesses. One is about making AI presentable. The other is about making AI indispensable to how you and others work. Join the 1800+ designers, engineers, and PMs leveling up their skills and subscribe! Subscribe How real transformation happens Let me share some of what's happening on our team at Cisco. We recently held what we called a "vibing with the customer" session with some of our security customers. Instead of showing them static prototypes, our research and design team set up live sessions using Vercel V0 prototypes. Customers didn't just get to comment on designs, they actively shaped them using natural language. V0 by Vercel is an AI-powered generative UI system that creates React components and full-stack applications from natural language prompts and Figma designs The results were incredible. Watching customers use language to iterate revealed their mental models in ways traditional research never could. But here's the key: our team could only run these sessions because they deeply understood the tools themselves. They knew what was possible, what would break, and how to guide the experience. We've also started monthly "AI in Design Showcase" meetings where designers share their experiments. No polished presentations—just raw learnings. One designer turned to AI for understanding incident responders' needs through "prompt chaining," building context layer by layer. Another got frustrated with how V0 rebuilds everything for small changes, so they built a command-line tool that structures better prompts. Someone else showed us Figma Make in action—what used to take 20-30 minutes now takes 2-3 minutes. The pattern is clear: designers who use AI to solve their own problems become infinitely better at designing AI experiences for others. An internal command-line tool that provides better-structured prompts, built by a member of my team. The questions that reveal true AI-fluency When I interview candidates now, I skip the theoretical discussions. Instead, I ask three questions that instantly reveal their real experience: Question 1: What's in your AI toolkit right now? The answers tell me everything. Someone truly AI-native will light up and start describing their setup—which MCP servers they're running, why they switched from Cursor to Windsurf (or vice versa), and how they use different models for different tasks. They'll have opinions formed through experience, not blog posts. Windsurf’s IDE creating a playable 2048 game. Someone who's AI-curious but not AI-native will mention ChatGPT and maybe one or two other tools they've "experimented with." There's no depth, no personal workflow, no strong opinions. Join Josh Cusick’s subscriber chat Available in the Substack app and on web Join chat Question 2: What broke you last week? This question reveals whether someone is actually building or just browsing. Real builders have war stories—they've hit context window limits, dealt with hallucinations in production, figured out workarounds for rate limits. They've pushed tools until they failed and learned from those failures. I, for example, spent about $50 in AI tokens on an n8n workflow that went into an endless loop. This alone has shaped how we think about agents having “budgets” for tasks and how we need to put guardrails to ensure this doesn’t happen to a customer. My terminal showing a mix of rate limiting, API timeouts, context window overflow, undefined property errors, invalid/expired tokens, model overload, and a local MCP server crash. Most issues point to too many requests, unhandled edge cases, and system overloads. Question 3: What are you building for yourself? This is the killer question. AI-native folks always have personal projects—an agent that organizes their notes, a tool that generates design variations, something that automates a workflow they hate. They're not waiting for permission or a project brief to start building. My latest project, for example, deals with the fact that I subscribe to all sorts of newsletters, podcasts, and thought leaders, but don’t have time to consume them all. I built an agent that goes through my Gmail every Saturday night, looks at all the content that has come in for the week, reviews it, summarizes it, prioritizes it, and then sends me a digest email Sunday morning with the content in priority order based on my interests. It not only gives me some rationale as to why it’s a priority for ME, but it also gives me some reflection prompts that I can use to make better notes or to more actively engage in the content so that it sticks. My daily digest summarizing publications I follow. Want another example? You can also check out my YouTube video that shows my experience building an agent. How to show your AI-native work in your portfolio Here's what most designers get wrong: they showcase the AI products they've designed but not the AI tools they've built. As a hiring manager, I'm looking for evidence that you've lived in this world, not just designed for it. Create an "AI experiments" section Don't bury your AI work in case studies. Create a dedicated section that shows your journey. Include things like: Your current AI stack with screenshots of your actual setup. Your Claude Desktop with MCP servers running. Screenshots of your Cursor workspace with AI-generated code. Your n8n workflows or Zapier automations. This isn't about being polished—it's about being real. Cursor’s IDE fetching data on a Figma file and creating a component with its context. Document your failures The best AI-native portfolios include a "What didn't work" section. Show me the agent who hallucinated customer data, the automation that broke after an API update, or the prompt that generated completely wrong outputs. Then show me how you fixed it. This demonstrates real experience more than any success story. Show your velocity Traditional portfolios show final outputs. AI-native portfolios show speed of iteration. Record a 2-minute video of yourself using V0 to go from idea to prototype. Show a time-lapse of building something with Cursor. Demonstrate how quickly you can test variations with AI. Velocity matters as much as quality in our new world. A Wordle clone built with a single prompt in v0. Share your opinions Write short posts about your tool preferences. "Why I switched from Cursor to Windsurf," or "Three ways Claude outperforms GPT-4 for design work," or "How I use different models for different tasks." These opinions, formed through experience, are incredibly valuable. They show you're not just using tools—you're thinking critically about them. Make it interactive If you've built tools, make them accessible. Host your automations on a simple site. Share your custom GPTs or Claude Projects with view links. Let me try your research synthesis tool or design variation generator. Nothing proves AI-native thinking like tools that other people can actually use. Update it constantly Your AI section should change often and show your progression. New experiments, new failures, new insights. An AI-native portfolio that hasn't been updated in six months suggests you've stopped experimenting. Show me what you learned last week, not last year. Why not build an agent that keeps it up to date for you? The goal isn't to impress with polish—it's to demonstrate active experimentation and real-world application. When I see a portfolio with documented AI experiments, tool comparisons, build processes, and honest failures, I know I'm looking at someone who truly gets it. Your 30-day journey to AI-native Becoming AI-native isn't about learning every tool or reading every newsletter. It's about solving real problems and developing intuition through experience. Here's a practical path: Week 1: Solve one real problem Pick something that annoys you daily. Maybe it's summarizing meeting notes, organizing research findings, or creating design variations. Choose one tool—Claude Desktop, Cursor, or V0—and solve that specific problem. Don't try to learn everything at once. Success looks like having one thing in your workflow that you couldn't imagine doing manually again. In Week 2: Connect your workflow Now expand. If you started with Claude, add an MCP server to connect it to your files or GitHub. If you use Cursor, try building something more complex. Create your first automation with Zapier or n8n. The goal is integration—making AI part of how you work, not a separate experiment. Image source: Zapier blog Week 3: Build for others Create something your team can use. A research synthesis tool, a design critique assistant, or an automated report generator. Getting feedback from others reveals blind spots and pushes you to think about reliability, edge cases, and user experience in new ways. Week 4: Form your opinions By now, you've hit walls, found workarounds, and developed preferences. Document what you've learned. Share it with your team or publicly. You're not claiming expertise—you're contributing to the collective learning. Your fresh perspective on what worked and what didn't has value. Staying current without drowning The AI space moves fast, but you don't need to follow everything. Focus on practitioners, not pundits. Lenny’s Podcast and Newsletter, Ethan Mollick's Substack, and Clair Vo’s How I AI podcast offer depth over hype. Join one community where people share what they're building—LocalLLaMA subreddit or a focused Discord. The goal isn't to know about every model release but to deeply understand the tools you actually use. Subscribe The truth about AI-native teams Here's what nobody talks about: becoming AI-native isn't just about individual skills. It's about transforming how teams work. When everyone can prototype ideas quickly, when researchers can synthesize vast amounts of data, when designers ship functional code, the entire dynamic changes. We're seeing designers educate themselves across domains, suddenly able to dabble in code or data visualization. Conversations between design, product, and engineering get richer because we can prototype ideas in minutes instead of weeks. The gap between idea and reality shrinks dramatically. But it's not all smooth sailing. Tools don't always integrate well. AI sometimes changes things you didn't want changed. Quality varies wildly between use cases. Being AI-native means navigating these challenges, not avoiding them. The bottom line We're building AI experiences for enterprise customers who don't yet know what's possible. We need people who do not because they've designed AI interfaces, but because they've lived in this world, pushed every boundary, and developed taste through thousands of experiments. If you get excited when new models drop, build tools to solve your own problems, have opinions about which AI coding assistant is best (and why), run experiments for fun, can't help but automate everything, and know what MCP is and why it matters—then you're on the right track. But if you're still just using ChatGPT to write emails and calling yourself "AI-native," you've got some building to do first. The future belongs to those who build with AI, not just for it. The question is: are you ready to make that shift? Leave a comment 14 Likes ∙ 2 Restacks 14 2 Share Previous Next