How Anthropic, Every, & Ramp design with AI

Summary

Dive Club 🤿 — "How Anthropic, Every, & Ramp Design with AI"

Host: Ridd
Guests: Megan Choi (Design Lead at Anthropic), Dan Schipper (CEO of Every), Bradley Ziffer (Design Engineer at Ramp)
Date: June 2, 2026
“Where designers never stop learning 💪”

---

Episode Overview

This special live panel episode brings together leading voices in AI-powered design to unpack how top teams at Anthropic, Every, and Ramp are reimagining workflows, collaboration, and the very meaning of "design work" in a world where AI is increasingly part of both the toolset and the process. Host Ridd guides the conversation through practical advice, cultural shifts, organizational best practices, and philosophical perspectives on the evolving craft.

---

Key Discussion Points & Insights

1. Crossing the Designer–Developer Divide with AI

• Megan Choi (Anthropic):
  Designers must now have access to the production codebase, not just sandboxes, to fully leverage modern AI tools (Claude, Code, Cowork). This lets them ship directly, iterate faster, and have real user impact.

  • Quote: “Let your designers get access to your production codebase. …The more information access they have, the better you’ll be able to build.” (02:27)
  • Designers must also increasingly “let go”: it’s not just about protecting polish, but about empowering features to ship—even ones they didn’t directly touch.
  • There’s discomfort: engineers must let designers into code, but designers must accept engineers or even AIs as code-generating collaborators.

• Sandbox vs. Production Repositories:

  • Sandboxing (isolated environments for designers to code) isn’t enough; maintaining two codebases creates technical debt, hinders real impact, and limits access to organization-wide tools and data.
    • Quote: “If you ask any engineer if they ever want to fork their codebase and maintain two versions…they will always tell you that’s a terrible idea.” (04:24)

2. Changing Collaboration & Craft

• Bradley Ziffer (Ramp):

  • It’s not about everyone becoming a design engineer, but about bringing “care and intention” to your work. AI lets anyone get things to a 7/10 level quickly—leaving more room for true craft and attention to details that matter.
    • Quote: “We can probably get to a place where seven out of ten...anyone can do it. That’s actually great. But that just means you have more room to care and put love and intention…” (07:00)
  • A new balancing act emerges: the ease of self-service (fixing small UI annoyances yourself) can lead to over-polishing; being deliberate about what’s worth your focus is crucial.

• Shifting Responsibilities:

  • Designers now have the power to rapidly polish, ship, and iterate—sometimes without oversight, which is empowering but can distract from high-leverage priorities.

3. Rethinking Prioritization and Time Allocation

• Megan Choi:

  • On lean teams, designers must self-prioritize—sometimes polish isn’t the best use of time, especially when products are in flux or models are rapidly improving.
    • Quote: “Is it worth polishing something that’s not going to be here six months from now?... it feels like it’s all on your shoulders… but it’s a shared responsibility.” (10:30–12:14)

• Dan Schipper (Every):

  • The biggest lever for organizational change: leadership must be hands-on users of AI tools—no more lip service or “AI working groups.”
    • Quote: “The organizations that seem to do the best are the ones where the leadership team is like, in the tool all day… it’s not outsourceable.” (13:10)

4. AI Fluency: What Does “Good” Look Like?

• Definition of Good AI Fluency:

  • Cut through noise, focus on what matters, and accelerate learning cycles.
  • Build and use systems to harness decentralized design work.
  • Use AI to make entirely new things that were previously impossible.
  • Embrace and rapidly adapt to change—nothing is sacred and everything may be obsolete soon.
    • Bradley: “It’s learning. How fast can you learn?... what do you do with that learning and how do you proliferate it throughout an organization...?” (18:29)
    • Dan: “A good designer is going to figure out, how do we make systems to harness that design work…” (21:04)

• The Role of Curiosity and Play:

  • The best teammates are multi-dimensional, playful, and see AI as a creative playground.

5. Learning, Knowledge Transfer & Opaque AI Workflows

• Working with Models is Isolating:

  • Megan: “If you spend eight hours of your day talking to Claude, you haven’t talked to another person…it can kind of feel a little strange.” (29:08)

• Pairing as a Practice:

  • Anthropic’s team pairs designers (as in pair programming) to shadow each other’s real workflows, making tacit knowledge transfer explicit.
    • Quote: “You’ll see what another person does… they don’t even realize are special.” (29:29)

• Slack/Chat Agents as Collaboration Hubs:

  • Internal ‘skills libraries’ have issues with personal fit and updating; shared AI agents (like Ramp’s “Cody”) living in Slack enable real-time learning from others’ prompts and behaviors.
    • Dan: “Slack agents… you get to see other people prompting… that just seeds something in your brain…” (31:00)
    • Bradley: “I felt silly because I was talking to a bot for a really long time…” (32:37–36:21)

6. Design’s Shifting Value Proposition in the AI Era

• Models Are Fast Approaching “Good Enough” for Routine Design:

  • Megan predicts that “by the end of the year” AIs will handle “most fundamental design work.”
    • Quote: “Our models will be good enough by the end of the year… to do design—most of what we consider very fundamental design work.” (37:22)

• Designers’ New Focus:

  1. Systems & Brand: Crafting systems, guidelines, and taste—the subjective and abstracted layers of products.
  2. Personalization Frameworks: Balancing flexibility and consistency in increasingly customizable tools/products; deciding “what to keep fixed, what to be allowed to customize.”
  3. Deeper Abstraction: Moving from UI design to structural decisions that allow models (and users) to operate with more autonomy.

• Embracing an Ever-Evolving Landscape:

  • Be prepared for constant change—today’s solution is likely to be obsolete soon.
  • The best designers (and leaders) are “problem finders” who proactively fix internal workflows and elevate organization-wide knowledge.

---

Notable Quotes & Memorable Moments

• Megan Choi:

  • “It’s crazy if you think about it that… we all want access to the production codebase, but when it comes to having our engineers design for us, the initial reaction is: oh my god, I don’t want to do that.” (03:26)
  • “Is it worth polishing something that’s not going to be here six months from now?” (10:41)
  • “Every pixel I push… could be obsolete next week, depending on the next model that comes out.” (24:56)
  • On collaboration: “Pairing with another person. What a concept.” (29:08)

• Dan Schipper:

  • “The organizations that seem to do the best are the ones where the leadership team is like, in the tool all day… you’ll have an intuition for how to manage a team who’s in the tool all day, and it’s not outsourceable.” (13:20)
  • “When Opus 4.5 and GPT 5.3 came out… I was like: holy fucking shit, this is crazy.” (14:39)
  • “Competence is cheap for everyone. …a good designer is going to figure out, how do we make systems to harness that design work and use it, rather than be like, ‘No, that sucks.’” (21:04)

• Bradley Ziffer:

  • “It’s not so much that we all need to become design engineers… it’s more about, ‘what does it mean to put care and intention into something?’” (06:59)
  • “It’s learning. How fast can you learn? What is the iteration of you learning… and how do you proliferate it throughout an organization?” (18:30)
  • “When I joined Ramp, I kind of felt silly because I was talking to a bot for a really long time…” (32:37)
  • “Slack bots for me… then we have fantastic design programming, right, where learning is not required, heavily encouraged, but it’s starting to take many different shapes and forms.” (36:21)

---

Timestamps (MM:SS)

• 02:27 — Megan on designers accessing the production codebase
• 04:24 — Rebuttal of sandbox coding environments for designers
• 07:00 — Bradley: AI gets you to “7/10;” opportunity lies in intentional craft
• 10:30 — Megan on prioritizing what to polish and when to let go
• 13:10 — Dan: True org transformation starts with executive leadership using AI
• 14:39 — Major shift: smarter, more agentic models enable new workflows
• 18:29 — Bradley’s definition of AI fluency: cutting noise, iterative learning, spreading knowledge
• 21:04 — Dan: “Competence is cheap;” building systems to harness org-wide design work
• 24:56 — Megan: Everything might be obsolete soon—design for adaptability and joy in learning
• 29:08–29:30 — Megan on the value of pairing to transfer (and discover) tacit AI knowledge
• 32:37–36:21 — Bradley’s story of learning from Ramp’s AI agent “Cody” in Slack
• 37:22 — Megan: Near future—models will handle most routine design; designers will focus on systems, frameworks, deeper abstraction

---

Final Thoughts

• AI is fundamentally changing the designer’s toolbox, team boundaries, and what “good” looks like—from both output and cultural perspectives.
• Top teams are reshaping their processes to make the most of these shifts, while candidly wrestling with the challenges: workflow opacity, knowledge silos, and the need for new cultural habits.
• The most successful organizations are hands-on, experiment-driven, and open to rethinking everything. The next era is about systems thinking, creative improvisation, and relentless adaptation.

“It’s a fun time to be a designer—and there’s just so much to learn and dive into.” (39:22, Ridd)

Transcript

[A]

Welcome to Dive Club. My name is Rid. And this is where designers never stop learning. This week's episode is a special one because it's actually a live recording of a panel discussion that happened last week in New York City. We get to hear from three incredible guests. The first is Megan Choi, who's the design lead behind Claude, Code and Cowork. The second is Dan Schipper, who's the CEO of Every and one of my favorite thinkers when it comes to AI. And the third is Bradley Ziffer, who's a design engineer at Ramp. And the entire point of this discussion is to do a deep dive into not only the future of design, but what AI workflows look like at some of these prolific companies. So, without further ado, let's dive in. Welcome back, everybody. I've always wanted to start talking after a live applause. That felt pretty good. I'm not going to lie. That felt pretty good. I think I could do that. Three amazing guests who have all given wonderful workflows. And we're going to go a little bit deeper here and talk about the different things that people are observing in the industry, how the way that we work is changing some of the best practices that are still kind of actively being discovered inside of our orgs. And I'm going to try something a little bit weird. Haven't really prepped them at all.

[B]

At all.

[A]

And I'm going to ask us to put on these hypothetical consultant hats. Not so hard for you, Dan, but maybe over here a little bit new. And we're going to just help people think about different avenues for transformation. Right. Like, if we want to grow as builders, as orgs who are leveraging AI to the fullest capabilities and really rethinking from first principles how we operate, what is that going to entail? Right. And so talking Megan, with you earlier, something that I learned is that Megan does a lot of on sites with teams teaching these design orgs how to make the most of Claude and building and using AI. And so I'd like to start with you, and we can put on again this not so hypothetical consultant hat and think about, you know, you talked about, like, this 201 level course almost that you're putting people through. So when you think about the transformation that you're hoping to have, Design Org, see what are some of the main mile markers on that journey that you would look for?

[C]

Yeah. I think I met a few folks today, actually, who attended, like, some previous talks back when cloud code was less popular. And I think the theme of 2025 and like for orgs first getting into this is like, let your designers get access to your production code base. That's like the starting point of this conversation. It is been a very gatekeep and for a lot of good reasons, for security, for privacy, for like your ability to understand that you're making these changes. It's been segregated for a while, but, but it's so, so, so important now that these tools are available and like, the more information access they have, the better you'll be able to build to get access to that production code, to go through the process of shipping to production. Because the closer you are to what your end users see, the closer you have to like influence the product. The second, and this one is deeply uncomfortable for a lot of designers, is in the same way that we're asking our engineers to let us in and help us code, you need to be more comfortable letting go of design. And that means that a lot of features can go out without you. A lot of the time it's actually very possible for people to get a V1, a V2, even a V3 out there and have it be pretty good and have it be pretty aligned with your design system. And you know, you build the automations in place so that there's the right checks and balances. But I think it like goes both ways. And so those are like the two big milestones that I often see. And I think it's crazy if you think about it that like, we all want access to that production code base, but when it comes to having our engineers designed for us, the initial reaction is like, oh my God, I don't want to do that. But it's so important, I think, to like shift your mindset a little bit and like recognize that we're all kind of have like this new ability to build.

[A]

All right, let me push on that for a second because I've talked to quite a few, especially larger teams, but not even massive teams where they're very intimidated by getting designers into prod. And there's this story that you can tell around, well, if we just make a separate repo and a playground, then designers are coding and that's, you know, the 8020 value. What would you say to that leader?

[C]

I was just like, then you're maintaining two repositories. If you ask any engineer if they ever want to fork their code base and maintain two versions of the same thing, they will always tell you that's a terrible idea because you have to maintain two things and they're always going to be out of dates. Also, part of being in the production code base is having access to all the tools that your organization is building into that code base, because you bet your engineers are also on this journey learning with us, and they're scaling themselves. It also gives us access to the actual data endpoints so that when you go logging and you're doing data queries, you can actually see what's happening. There's so much built into a real code base that you just can't replicate in a sandbox, that it's just. You just really need access to it to really experience the power of what it's like to build a product that your users end up using.

[A]

I've anticipated Desen's recent release for a full year. It's called Surfaces, and it enables you to design and prototype directly on top of an existing production interface. All of the pages and flows that you need are preloaded inside of Destin as starting points, so you can easily make changes, explore ideas, and then when you're ready, you can share your prototype in a single click. Desen is the only design tool that allows you to design on existing pages and flows pulled directly from Prod, which is a pretty big deal for teams. And you can get started today. Just head to Dive Club Desen. That's D E S sn. Never in a million years did I think my design workflow would change so drastically in the last few months. And a big part of it is Paper's new snapshot tool. It's a chrome extension that lets you copy any component or element from your live website and then paste it directly into Paper as editable layers. So all the time I'll grab something from Prod, have Claude immediately spin it up six different ways on Paper's canvas, and then when I'm ready to send a concept back to Claude, it's seamless because Paper's canvas uses is real HTML and css. That workflow feels a lot like the future of design to me. And you can start doing this today. Just head to Dive Club Paper to try it out. Now, onto the episode. All right, Bradley, I'm going to go to you for a second here as the resident design engineer. This person who's been kind of bridging and seeing both sides of the table for a while now. In this world where many more designers are shipping, touching, production, doing things in GitHub that they may or may not fully understand, how is this shaping what you think really solid design engineering collaboration looks like?

[D]

I don't know if it's so much that we all need to become design engineers or designers or whatever box or label you want to put on things. I think it's more about what does it mean to put care and intention into something. Like Megan's saying, we can probably get to a place where seven out of 10. We're at a seven out of 10. Like, out of the box, a thing you want to do, an idea that you have. We can get a 7 out of 10 and anyone can do it. And that's actually great. But that just means you have more room to care and put love and intention and thought into the things that you build. And I think that that that's what it in my mind is about. Sure. It's like, you should understand this animation you're putting out and what it means to be performant on the web and what it means to not make me rage. Quit your app because you have a menu and then another menu. But when I go a little bit outside the boundary of that second menu, it closes the menu and I'm like, you should care about those things. But that is all just care. Just you care. It's just you caring. And now you have maybe hopefully a little bit more time to care.

[A]

Okay, I want to touch on the little menu thing because I think it's exists in this box of responsibilities that all of a sudden have kind of fallen potentially on designer's plates. Like, even speaking from my own experience, that's something that previously I would make a linear ticket. I would add polish, and then I would make a comment and be like, please, this is really important. Right. And then mostly get ignored for the next, like, quarter. And now I don'. Make the linear ticket. I just open up a new work tree and start working on it. And it's empowering, but also the slope is slippery because I can find myself just polishing and polishing and polishing and polishing. And so given the new capabilities, I'm curious, how do you think about allocating your time as a designer who all of a sudden may or may not feel like you can shoot lightning out of your fingertips with the deploying code and pushing to PRs and stuff like that?

[D]

Sure. In the beginning, it takes a long time to do these things and to put that care and craft in, because you haven't done it before, you've never done it before. And maybe you just stumbled upon, like, John Famous tweets, and you're like, wow, shout out. I should do that. And then you take that tweet and you give it to Claude, come on,

[A]

man, this is hitting too close to home.

[D]

You give it to Claude and then maybe you just hope it works or maybe you ask why does it work? And hey, next time, can you make a skill out of this? Can you make a skill and you don't even write the skill, it just makes a skill. So I don't know. I don't think it's that. Maybe in the beginning it takes a long time. We start to spend a lot of time polishing things. But I think that what are you doing? If you can get to 7 out of 10 like this, you probably got a lot of time back. You just maybe don't realize it.

[A]

There's a bunch of things I'm going to put a pin in. One is the seven out of ten. One. Dan, I'm coming to you for more organizational transformation, but really quickly, I'd love to hear from you this idea again. Everybody can code as much as they see fit. You have an engineering background and yet you're leading design of coding products. How do you think about the allocation of your work and maybe have you seen a shift over the last even couple models?

[C]

Yeah, we're a very lean team on the cloud code side, I would say. And so I think I just like, I really trust the designers on my team to prioritize themselves and transparently. Sometimes that looks like not prioritizing polish and I think that's okay. There's a few truths that I hold in my head as we're working that I think really help guide how I see prioritization should ship. Part of it is because we're working at a lab and so our job is to be like researching at the frontier. And so one thing I like to encourage the team to think about and this is an ethos in the cloud code and team and the product team at Anthropic is is it worth polishing something that's not going to be here six months from now? Like we're so early in this journey right now that we actually don't know what the final shape of these products are going to be. And so is your time better spent on that future looking thing where it requires deep thought and kind of like a lot of thinking and like cloud can't do that yet and it requires like a really big canvas to explore or is it better spent like those 30 tickets? I actually got some great feedback at one point from my engineering team that I was not spending my time wisely pushing these PRs. They're like, yeah, you're helping the Polish work. But right now, Claude isn't good at design. So I am doing a lot of manual look over it. And it wasn't just like a great use of my time. And so I think it's hard to internalize that as a designer because it feels like now you can do it all. And it feels like it's all on your shoulders and your responsibility to maintain that polish. But we like, in the same way that now that we can do it also, your engineers should be able to do more too. Like, it's a shared responsibility to care about that polish and about that care. And so it's not all on you. You can still bug your engineer to do polish on features in the same way that your engineer can now bug you to implement something on the front end. Like it's. It's all of us and we're all in it together.

[A]

Yeah, I like that a lot. I've felt that myself, where it's just so easy to knock out a little task, feel good about it, and then immediately just jump to the next polish ticket. And you can kind of all of a sudden, like, six hours are gone and things look great, but then you're kind of like, did I work on the highest leverage thing? And I think it hits on this idea of, you know, you kind of really have to be self aware around not only how you're working as an individual, but how the org is operating. And so maybe, Dan, if I can toss it to you, when an org comes to you and says, dan, we know AI is a big deal. We don't feel like we are evolving as quickly as maybe we should. Can you just help us get to that next milestone? Where are some of the main opportunities that you look for or signals that you would use to get a sense of, like, where someone's at? Like, if you're going to get this org to the next level, what does that typically look like when you're wearing that consulting hat?

[B]

The main thing that I always look at is what is the CEO doing and maybe more broadly, what is the executive team doing? Because I think for the first, you know, three years of AI, there was a lot of lip service paid to, yeah, we, we gotta have AI or whatever, but it was always like, and we'll do an AI working group. And generally that has not worked. And the organizations that seem to do the best are the ones where the leadership team is like, in the tool all day. And that's the only way that you'll get. You'll have an intuition for how to Manage a team who's in the tool all day and, and it's not outsourceable. So that's. We spent a lot of time with leadership teams actually just being like, okay, literally open cloud code and make something. And they, they love it, but a lot of them are kind of afraid or don't really want to do it. But I think that's, that's one of the big lenient indicators.

[A]

To me, you're a pretty good prototype for what it looks like to be the leader who lives with the tools and has hands in the clay pretty much all day is what I'm assuming. So maybe we could zoom in on your workflow for a second and if you kind of put, you know, you today up and then over here is you maybe, I don't know, three, six months ago, something like that. I'm curious in terms of how you are interfacing with the models on some of these more, you know, ambiguous creative opportunities. Where do you see the biggest deltas in terms of how you are working, what language you're using, tool skills, anything like that?

[B]

I mean, I think there, there was this big moment that happened in, I want to say, November or December of 2025 when Opus 4.5 and GPT 5.3 came out. Or, yeah, 5.3. It was like this moment that I think a lot of us, for us at every, like, we had been using cloud code for about, we've been using it for about a year and had not been, have not been looking at code for about a year. So at that point it was still pretty risky and people were like, are you fucking kidding me? You're not looking at the code. And, But I think we could see that that's where it was going and we were willing to deal with some of the like, weirdness of that. And for me, because, you know, I'm, I'm writing and I'm in meetings and I'm like doing all this stuff. Like, I don't, I like to vibe code, but I'm not going to do any serious engineering. But at when that stuff came out, when Opus, Opus 4.5 and 5.3 came out, I was like shipping PRs to our products and I was like, holy fucking shit, this is crazy. So I think there, that, that has been a big shift because the, the, the models are just much smarter, they're much more independent, they don't do as many dumb things. And I think we've also figured out like, cloud code. You guys like, created this. I think a lot of people had models of what is an agent that does work for you look like. And prior to Claude code there was like the Devins of the world or even Codex. The original Codex was. It was like you have a sandbox agent in the cloud. And what was really special about Claud Code when I first tried it is like no, no, no. It's just on your computer it has access to all the things that you have access to and that just opens up this whole new territory. And I think as that has started to catch on and as the models have gotten better it. It has become this new work operating system in a way that I think is really, really special. And so the big power ups are. Yeah, I can, you know that that app proof like I just made that in between all the other stuff that I do. I have shipped PRs to like pretty much every one of our products but don't really know the code base. Sometimes me shipping PRs is actually really bad. So it's, it can be, it can be annoying. Your mileage may vary. Like I said earlier, I struggle mightily to respond to emails on time and I'm now just perfect. And that's really crazy. All the things that I would normally procrastinate on, it just gets done. And I have a lot of thoughts on just generally what happens to experts and expert workflows and where to spend time. But I think the. My whole day is very different because I'm just in Codex or cloud code all day and I use. I do all my work in there.

[A]

I want to talk about this phrase AI fluency, which feels like it's probably the next buzzword buzz phrase. And let's just like increase the fidelity of what that could look like, what good looks like inside of an org. And I'm going to start with you too because you shamelessly plugged your designer roles and and let's imagine that somebody is somehow inspired by your pitch and they want to join, right? And maybe we fast forward six months and my question is like what does good look like, right? Like what is a behavior that they would be doing on a regular basis that would get you to point at them and say yeah, that that is what AI fluency looks like. That is what we were looking for when we were putting this design role out there.

[D]

If in six months I can look at you and say that you have found a way to cut out all of the noise and truly think about what matters most, right? It's learning. How fast can you learn? What is the iteration of you learning? And then Acting upon that. And then what do you do with that learning and how do you proliferate it throughout an organization that is now at terminal velocity where everyone is doing things and putting things out? There is this, this. This idea that, you know, we can't. Alignment doesn't exist. I agree with this, by the way, but the. The cost of alignment is. Is quite high, and the cost of redundancy is low because we can kind of clean stuff up. But I think if in six months, you are the one who is able to understand across your. Your whole product very deeply. Right. How you can simplify all the way down from, you know, we have 15 things that solve 15 problems to we have four things that solve 30 problems. I think to me, that means that you are leveraging the tools, because I think the reason that we don't get to that today, or we do now, but we've never gotten to that, is because we spend a lot of time doing administrative work or figuring out how to set up calls with researchers. And since we did shamelessly plug ramp my time. I've been at Ramp for four months now, and my first week I met with the research team, and I've never scheduled a research call my whole time at Ramp. Every week, four of them pop on my calendar and they tell me exactly what I need to talk about, and they know what I'm already working on. And I just go and I just show up and I just get to learn from customers and I get to hear about what they do and what they care about and what resonates in their world. And then I get to apply that across the entire organization because I don't have to read all those docs. I can just synthesize them and I can understand and look very deeply at. I don't know what comes next. Where are we going? I think that's the AI fluency to me. Just carve out more. Be selfish. Be selfish.

[A]

Okay, so we have systems thinking the importance of internal workflows. Something I've been feeling a lot recently too. Dan, I'm curious to hear from you. Let's say you find the senior product designer in this room six months from now. What would get you to the point where you're like 10 out of 10

[B]

higher overall, when I think about people who are experts at what they do, and in AI, I sort of split up and we can say maybe designer specifically, I split it up. But I think this applies just as well to engineers or, you know, product managers or whatever. I split it up into two buckets. One is because these tools make it make competence cheap for everyone. There's this whole. There's this huge glut of people doing design work in every. That are not designers. So a good designer is going to figure out how do we, how do we make systems to harness that design work and use it rather than like, be like, no, that sucks, or we can't use it. Right, but that's actually hard. There's a lot of systems to build on that side. And then the, the other thing, the other bucket is how do I use these tools to make something that no one has ever made before? And the first one is, you know, there's all this, there's all this routine work that I can, I can sort of automate and I can harness the routine work that all the other people in the organization are doing. And then there's all this other stuff I can do that was just. Would just never be possible otherwise. So, and, and I think the kinds of people that like to do that are very curious, they're very playful. The, the kinds of people I love to work with are multi dimensional. Everyone inside of every is like, you know, Kieran, who, who runs Quora, our email agent was like, he's, you know, super technical, but he was a composer and a baker before this, like, professionally. And I think that kind of person. All these tools are just this amazing playground and you can. What I love is when the design team's like, yeah, I'll just go, I'll just go make a little app for that. And like, you know, and often it's a little internal tool or something like that, but sometimes it's like, you know the, that, that graphic I showed you with the, the Xenos Paradox graphic? Like I just pulled Daniel, one of our designers, in like the day before, because it was. Something got fucked up and I just needed someone to do it. And like, we just got it done and it's really good. So there's really, there's like, there's something about working super fast on new things and being like, really excited about that and using the tools to harness what is now possible and like, push it to a level that wouldn't be possible otherwise.

[A]

One thing that Dive club has made abundantly clear to me over the last year is that the practice of design is changing and the old process of getting feedback just doesn't quite cut it in today's world. That's why I'm excited to announce that Inflight is officially in open beta. It's the feedback tool that I've always wanted, and it's built for a world that moves at the speed of AI. So I can share my prototypes, give context and video walkthroughs, and Inflight makes it easy to get the exact feedback that I need to move forward, whether it's voting on directions or maybe even getting the green light to ship a new idea. And all of this is available in a single link that I can drop into Slack or maybe even share with power users to test out a new prototype. I use Inflight every day, and it's totally transformed the way that I share work. So I'm excited for you to try the product, and if you ever want to jam about it, just email me at RIDD Inflight. Co. I want to return to something that Bradley said, but maybe I'm going to have you talk to it, because I know you've been thinking a lot about how to learn as an individual with the models, because a lot of what you're talking about is, like, you know, being curious, trying things, making sure that you're continuously improving as an individual. And so I'm curious, when you think about your journey as somebody who's constantly tinkering with these models, how have you been able to grow the muscle of making sure that you are learning as you use these tools?

[C]

We're also hiring, in case that wasn't clear. But I think, like, we are so early. I cannot emphasize this enough to everyone here. We have really only solved two use cases, and the use cases of everything that can be solved right now. Search and coding. There's so much else out there that to assume or to think that we're, like, anywhere close to the end right now is like, we're just not. We're just so far away from that. And so, like, I operate every day imagining, like, thinking in the world like, this could all be obsolete. Like, every pixel I push, everything I'm trying today could be obsolete next week, depending on the next model that comes out, depending on, like, the next innovation that comes out. And I think that belief that, like, there's nothing really that I. That you need to, like, hold too dear and you need to be willing to update your belief system constantly lets you be very exploratory in the different directions that you're going to, but also, like, leads to you wanting to learn more. Different directions. Like, I think that's truly how we need to be living today because we're just so early on. And so once you, like, embody the idea that we're like, like, we're so not near the end point. Right now, we're like 1%, and we all have the power to shape the next 99. It becomes like an opportunity. It becomes exciting, actually becomes fun. And like, it becomes. And everyone's next 99 is going to look so different from each other, because the power of these tools lets you be so customized that I think it just gives you the opportunity to learn and focus on the areas that you want to learn and focus on. And so it just becomes fun and interesting. Like, learning for the sake of joy, I guess, is part of it.

[A]

Can you talk a little bit more about what it's like in your position, where you really are having to operate in the future, Right? Like you're designing for maybe the next model release or the next six months set of use cases. How does that change your daily, weekly practice of design?

[C]

Probably in two fundamental ways. The first is that I think, because we are, of course, still shipping products today, and we want our users to have a good time, we need to be able to hold two truths in our head simultaneously. The first is that we want the products that we ship today to be excellent and as good as possible. We want to serve people. And then we also have to believe that the products we have today are wrong and we can rethink them from the ground up. And so you flip back and forth in between these two all the time. And so when I'm looking at the future, I constantly imagine what is annoying to me today. What do I not want to do anymore? Of I'm building for myself as much as I'm building for you all. And what does my team complain about? What, like, when I talk to people, what are things that they don't want to be doing more of? And also, what are the things that they do want to be doing more of? And not just the people who are talking and showing it, because I think it's very easy to talk and show. But when you observe people's lived experiences of how they're using these tools, like, what do they look like they're enjoying doing? And what are the parts that, like, aren't fun? Like, if you were to tell me last year that people were, like, having four terminal windows open, I would have been like, that's crazy. Like, who. Who wants to live that way? And then we saw our team do that. And so I think a lot of it is, like, through your observation and your experience and then building, like, based off of, like, the peers around you. So it's actually a lot of fundamentals. Like, you hear this, like, wow, that's design. Well, yeah, because these core design skills are still extraordinarily important in our day and age. And, like, you can keep building on that foundation. You just test new things faster now.

[A]

Okay, so there's this thing that I'm experiencing where I'm interfacing with these models. I'm figuring out the thing that I don't want to happen twice, Right. And I have Claude or Codex make a skill, right. And then you just kind of dump it into this black box and you hope that it helps everybody. And the entire process of collaborating on top of the learnings that we're all having as individuals has been largely opaque for me. And I know that, that you are operating in orgs where you're taking that set of problems pretty seriously. And so maybe really quickly, can we go down the line? I'm kind of curious, what are you seeing or doing or experimenting or having success with in terms of making sure that the learnings that you're having as individuals are propagating to the rest of the org and benefiting the larger team?

[C]

I do think it's very isolating working with these models. Let's just all admit it. If you spend eight hours of your day talking to Claude, you haven't talked to another person, and it can kind of feel a little strange. We're also, as I mentioned, very early in this journey. So a practice that we have that we're doing on the cloud code team is to pair for a while. What a concept. Pairing with another person.

[A]

Is that even legal? Yeah.

[C]

Like, how often do you wish you could work with another designer in a project and you can't? Well, what we do is we'll schedule an hour, we'll shadow each other. You'll just literally work on a thing that you're already working on. You'll see what another person does. Because it's actually really hard to explain your workflow to someone. When I was trying to do this demo is, like, really hard for me to come up with what I'd talk about. But if you just watch them in their actual workflow, they'll do things that you don't even realize, that they don't even realize are special, that they're learning because they just did it so many times now. And then we do those every month we cycle through the design team. It's still a little bit of a newer practice, but the engineering team has been doing it for a while because pair programming is pretty common and it just helps you learn from each other. We are all experts to learn from right now and also builds the really important camaraderie of working on a team. So that's something that we've done and it's been quite successful actually.

[B]

There's no great solutions yet. Like we have, we have an internal skill library, for example, but then it's always like, is this skill up to date and should I download it and. Or should I just make my own? And skills turn out to be pretty personal in a lot of ways. And so you can download it, but then you have to customize it for yourself anyway. There's a. There's. There's something that needs to be solved there. I think the, the thing that feels the most solved right now for this kind of thing is actually just Slack agents. We have a lot of those. Some of them are things that we build internally and it's just like, you know, a Claude code on a, on a Mac Mini, like connected to Slack. Or we also use this thing called the Victor, which just raised a bunch of money. We also have our own agent agent that we're building. And the really interesting thing about doing that, especially if your organization enforces, and we don't enforce this, but we highly encourage people to use it in public channels, is you get to see other people prompting. And that is a surprisingly intimate thing. Right now you're kind of like, this should be between me and my AI, you know, and so I think that's a really interesting way to spread stuff because what you do is you get. People will have ideas. Like you said, people have ideas that you never would have thought of and they will do things that you never would expect. And then that just seeds something in your brain. You're like, oh, I'm going to do that. So I think that's really cool. And also if you have multiple agents in your workspace, they actually share things really easily and really quickly. And that's also really cool. So one of the things I have is I built this little thing called Mailroom that gives my Codex an email address, but it's on my email. So you know how Gmail has like the plus format, so it's like Dan plus Codex and there's like a little string and Codex just knows to check that email. And then the agents that we have in Slack know that that's my Codex's email. So they just like email stuff that I need to do to that Codex and then it just does it and I get it. And that's like another interesting. Agents are so fast at sharing things and I Think that that solves a lot of this problem once you start getting it to work.

[A]

What about you, Bradley? What about collaboration, knowledge transfer, things like that?

[D]

I mean, I think I would harp on the Slack bots when I joined Ramp. Like, seeing people. That was only four months ago. Seeing people use Inspect in public channels. In every public channel, something's broken. Immediately somebody's on it. They just tag inspect. In fact, there's even a funny, funny instances where someone will say, oh, this thing should be different. Something's wrong. And then there's a pattern where someone will come in and drop a link to something. In this case, it's like they just add inspect and they don't say anything else, and it just reads the context of the thread and you see it work. And that's interesting. When I joined Ramp, I kind of felt silly because I was talking to a bot for a really long time, and his name's Cody. And I was like, wow, people here are so nice. He's so generous with his time. Yeah, I just. I so like, he just. Anonymous pfp. And I was like, okay, cool. He tell me everything. And he speaks naturally. He's all lowercase. And then when I realized he was a bot, I felt like a crisis. But I then started to see him evolve, actually in front of my eyes. I started to see him have a blog. I started to see him teach other agents how to work and then how to teach their humans how to work. I started to see him innovate on patterns where it was like, oh, my gosh, we have now. Everybody wants a Slack bot. Everybody wants Cody. Oh, that's kind of unsafe, by the way. And Cody's like, oh, worry. I got it. I saw this and I'm gonna fix it. And then he helps us fix it. And then this is what's crazy to me. I learned something. I learned something great from Cody and from the people building him. And I touched on this. There's a lot of noise, right? And one of the most important things I learned was, like, now we have new ways to cut through that. I saw Cody drop an album in our slack about everything he was doing. I wish I could play it for you. It's actually pretty good. And it is all about the things that we are learning and need to do maybe differently. And. And then he started posting videos. Somebody gave him Gemini and Nano Banana and, oh, my gosh, every day. How do you do this? Don't worry. Let me make a song for you. And it's kind of catchy. I don't know, Yeah, I think it's the slack bots for me. And then we have fantastic design programming, right, where learning is not required, heavily encouraged, but it's starting to take many different shapes and forms, and it's very applicable. It's like, go learn a thing over here. But you don't actually ever use it. That's not that helpful. We understand where things are difficult and where we're having trouble. So let's sit in a room we actually sit in sometimes in here. Sometimes we have a smaller version of this, if you can believe it. And we all sit in there, and Elizabeth here shares her screen and we just see it happen. Or I see somebody do something, and I walk up to them with my little microphone and I go up to their desk and I know they use loom. So I turn the loom on and then I connect my Bluetooth and then I connect the microphone, and then I ask you, can you show me your prompt and can you walk us through it? And then we post it in the channel and everybody sees it.

[A]

It's interesting how, I mean, this has kind of been a trend, even on the podcast, where there's so much opportunity right now for people who are problem finders, designers, to go and fix things internally. Like the. The internal workflows are so ripe, so many opportunities for little tools, solving problems, eliminating inefficiencies. That being said, now for the final question here, I want to return to the 7 out of 10 idea, because it's not just internal tools. Fact is, the models are not there yet. They're not amazing at design. But every once in a while, Claude will do something on the paper canvas. I'm just like, dang, that was pretty good, you know, almost uncomfortably good. And you can kind of see where this is going. And so given a world where the models are playing an increasingly large part of our process, when we're designing the interfaces used by real people on our real product. How do you, Megan, think about the way that the value proposition of design is shifting?

[C]

My very personal opinion. And by personal, I mean it's truly just me. This is not a representation of the company that I think our models will be good enough by the end of the year, or the AI industry in general to do design most of what we consider very fundamental design work. And so I think there's a few different kind of directions I see this evolving. The first is that fundamental systems and brand, those are all subjective tastes that you need to be able to guide and establish. And those have a lot to do with the automations and the systems that you're building, those are established, you can prompt into them, but when it's really, really an expert hand crafting it, you can really tell. And I think that will still be very important. And so a lot of work will go into building those systems that help models design and help everyone get access to. The second one, I think, is that we're going to enter an era where personalization and customization is the name of the game. You can already see it in all the demos that you saw today where people really love building custom tools for themselves. But I have a very strong hypothesis that there's limits to how much people want to customize. You always need a great canvas, you always need a great starting point. Then we need to have a flexible framework to show people what should be fixed. You don't want your login screen to change every single time you log in, but you might want your dashboard to be flexible as well. The decision of what to keep fixed, what to be allowed to customize, how you guide people through that, that's like fundamental ux. So I still think there's going to be a lot in there in the decision making, but we're abstracting away from just designing the UI layer into the structural layers of like, what is fixed and flexible UI, into the harness layer of exactly how you interact with the model, to like, the primitive layer of like, what does it mean for a model to have an identity or the product you have to have an identity. And I think, I think what we're going to see is that builders, designers, engineers in general will end up going deeper and deeper down as more and more of these higher levels are solved.

[A]

I hope I can speak for everyone here. It's a fun time to be a designer and there's just so much to learn, there's so much to evolve and dive into. And I really, really appreciate all three of you joining. Look up to all of you and the impact you have on the industry. And it means a lot to be able to practice you with questions. Let's just give them a round of applause. Thanks everyone.