B (3:25)

Yeah, exactly. If you don't have a point of view, then the stakeholders or the users will define your point of view. Right, exactly. Yeah.

A (3:33)

And I think it's fine to have some interplay there. In fact, it's really good to listen to users and customers to get to all sorts of local maximum. But point of view I think is maybe global maximum or it's going to get you to the next local maximum rather, or the first one. And otherwise you're just kind of iterating around sort of where you're locally are. I think that it's always interesting to ask designers about taste or ask them what good design is. And you know, first of all, just the number of definitions you can get about design itself from any number of designers is amazing. But also, you know, if you do a design crit with like really experienced designers and you have five in a room and you kind of like argue through from aesthetic standpoint or from a UX standpoint or both, you know, what is the best design here on the table? You know, you might get like a hundred different answers from those five designers. And so I think it's a sort of thing where there's just so many different places you can go and then it's about like, how do you actually narrow down that possibility space and traverse that tree properly?

B (4:44)

And I guess like you kind of develop the point of view and taste just from obviously talking to users and like kind of your past experiences. It's kind of like, you know, you're kind of giving context to AI to a certain extent. Like it's kind of your own personal context, right?

A (4:56)

Yeah, I think that over time, absolutely you can. But there's also always the cultural influences of any given moment that I think really matter. And I would just say that I Find that the most interesting points of inflection are where you're kind of on a frontier and you're pushing further than anyone else has pushed already. And then you're kind of like rapidly updating real time and then you get a few observations out, whether it be on design aesthetic or strategy, and then you kind of of make a leap rather than try to iterate one step locally, if that makes any sense.

B (5:33)

Got it. I guess I'll share a specific example. I started using OpenCloud a couple weeks ago and it's a pretty janky product. It doesn't always work all the time, it keeps breaking. But it definitely kind of warped my mind on, oh, these agents can actually do basically whatever I wanted to do. So maybe instead of making people come to this website that I'm building, maybe they just get their agent to come and do their stuff instead. That was kind of totally warmed my mind.

A (6:01)

Yeah. And I don't know if it's the funny thing about OpenClaw is you don't know who posting about it is actually. Especially if you don't know the person who is actually larping being an agent or who's actually reflecting on what the agent actually did.

B (6:16)

Yeah, it's hard to wrap your head around it for sure.

C (6:19)

This episode is brought to you by Linear. When engineers use tools like cursor, clock, code and codecs, a lot of work happens invisibly. Someone can go from a bug report in Slack to a shipped fix without creating any record of what happened outside

B (6:34)

of the code editor.

C (6:34)

And that's fine for speed, but it makes coordination harder as you scale. Linear integrates with the very best agent coding tools directly, like cursor and codecs. That way anyone can see what an agent is working on and who assigned them to the task. You get the speed of agents without losing visibility across.

B (6:52)

Across the team.

C (6:53)

Product teams at OpenAI, ramp and blog are all using linear to collaborate with AI agents. And I use linear myself to run my creator business. So check it out at Linear App Agents. That's Linear App Agents. Now back to our episode.

B (7:10)

Do you think agents and AI can learn taste? Like, like, like, you know, I can if I'm a really good designer. I can just like put like a cloud code scale or something and like here's some principles I have and here's kind of what you do and not do and maybe it can stop doing purple slop after that. But do you think you can actually. Do you think we can train our agents to learn this stuff?

A (7:30)

I think that Models have already gone to a place where their visual output, for example, with the Gemini 3.0 release, let alone 3.1. But even 3.0, I thought if you prompted it the right way, complex prompt for sure. But if you gave it references, it understood and you push it hard enough, you could get to some pretty incredible outputs. And so I think those, those outputs are again, like you're lighting up this possibility space. You're, you're creating these different places that you could explore. And then from there though, I think it's. I never found myself as I explored what I could do with it or sport. I give you 3.1 feeling like, oh great, I got my answer. One shot done. Like even more than sort of an average output that you might see or what you're referring to as purple slop. Like I think I actually had more opinions about the thing with point of view and that actually had a direction to it than I did about the purple slop. You know, purple slop or average output, you're just like, cool, it does the thing. You know, there's a lot more I would push it to do myself or a lot more expression I could have here visually or experientially and you know, but, but it works. And once you actually go another step further and you have some intent behind it, I think that's the point at which you get to interesting places where that dynamic loop starts to occur and you really want to go push it further yourself. And prompting is not always like the way to do it. I think a lot of times actually what you need to do is push it forward as a human and in order to actually iterate to the right place, that's necessary.

B (9:18)

I see. And I think a really good designer is not just going to before. It's not just going to be like, hey, here's a prompt and here's the code and okay, I'm going to go with this website that I built, right. They need to explore divergent perspectives and then converge again. That's kind of what good designers should do. So I'm curious because basically trying to get from idea to product, that's basically trying to do. And there's a lot of intermediate steps. And back then, dude, when I was working at Microsoft and some of these companies, we had to write 16 page PRDs and all this kind of crap. There's a lot of intermediate artifacts that had to happen before even the product. But now code is basically free and you can kind of do this stuff. So yeah, even internally in Figma teams How do you guys go from idea to product now? Do you prototype a bunch of variations first and then go to the Figma or like. It depends.

A (10:07)

Yeah, I think it totally depends. I think there are times that we start with deep discussion. There are times where one of us is just ideating away with pencil and paper and notebook. I think there are times where we're in design or, you know, in a collaborative brainstorm, or we're like, literally in code or, you know, making designs. And there's so many different ways that I think you can start now, including from an existing setup or website or app that you already have. And I think that wherever you start, our job is to make sure that as you hop around between the different stages of. Or what were stages? I think in a linear process before, between ideation and alignment and design and actual production, you can start anywhere. But you might want to go everywhere in that process. And I want to make sure that we can enable that fully on the FIGMA platform. That's what I see happening more and more, is it's not even right to call it a loop, because, you know, it's not like you're always looping back to the same thing, but it's all these hops that could occur as you're really trying to explore, and that includes a lot of divergence and convergence. But it's those diamond shapes, they stack on top of each other, and they could be from any point to any other point in terms of where the artifact is or what it is.

B (11:46)

Yeah. People keep asking me, hey, Peter, is a design done or is it spec done? It's never done, man. It's never done to the product ships or even afterwards.

A (11:55)

I mean, that's the beauty of digital, is that you never have to say it's done. And if you talk to people that are trained in, you know, industrial design or, you know, the physical world, you know, they. They try to really make sure that they go through a process that can complete. And at the end of the process, it's like you're shipping it off. And if you don't like it, too bad, because, like, you cannot update this thing. And then in the software world of bits instead of atoms, we get to update constantly. It's an amazing, amazing world to live in. And what a luxury to be able to do that. But also, yeah, very much the case that now the velocity, or perception of velocity even increasing, you want to be able to push further, faster. And I think it's just really important to not make it so that you're just running towards something you need to run, but you need to run towards the right thing. So keep the velocity, but have some sense of cardinality, like know where you're going.

B (12:58)

Yeah. You don't want to run in circles, I guess.

A (13:01)

Yeah, yeah.

B (13:02)

And like, along the same lines, like, I think, you know, Figma mcp, great product, and now you can go from, you know, code back to the Figma canvas. Right. And some people online are like, you know, why did Figma ship this? Why would I want to go from code to Figma canvas?

A (13:19)

Right.

B (13:19)

And I think it is kind of going back to those, like, diamond shapes and stuff. Right. Maybe you can explain why you guys should ship that.

A (13:25)

I mean, I think that you might start in design, you might start in code or somewhere else. And if you're in code as a place to start making a prototype, just to get something built that you can play with. Cool. You can do that in so many ways. And we want to make it so that you're then able to go at some point and diverge and to actually use Figma for the stuff that is better to use Figma with, for example, anything from spacing to color to properties of the canvas that you can directly manipulate and being able to have that rapid feedback loop where you're able to do that, direct manipulation on the canvas is just clearly superior to prompting. I would say code editing itself is superior to prompting and probably design direct manipulation is superior to code editing when you're adjusting things like that. And then in terms of the breadth, I think the canvas is a natural place. I mean, it's an infinite canvas where you can go and see all the possibilities of flows of different ways that you could iterate on a screen and you can do it all in the same spot. And I think that it's important to be able to go from design to code, from code to design. That round trip. We have to make as high quality as. As possible, as efficient as possible, and really important to advance that forward and have that be really tight no matter where you start.

B (14:49)

Got it.

C (14:49)

And.

B (14:50)

And maybe like, hopefully nothing gets lost along the way. Like still.

A (14:53)

Yeah, yeah. I mean, the high quality part, like, we are always increasing the quality and making sure it gets better and better.

B (14:58)

Okay, all right, I'm gonna ask you a tough question now. So there's some startup, there's some startups out there that kind of look like Figma and. And then they have these like, things where I saw this thing the other day, where you can put in a prompt like design a Dog Cafe website or something. And then it has these swarm of AI agents that come in, just starts designing stuff and it looks pretty impressive, man. And you can also manually edit the stuff afterwards. And I'm wondering just since Figma is kind of the go to design tool, like, how do you think about stuff like that, do you think at the same time, I think a lot of designers are kind of very averse to prompt to design. Right. They're kind of like, you're kind of threatening my job or my craft. So I guess it's a tough situation. But how do you think about all this?

A (15:48)

Again, I think it's a mistake to think of output of a prompt as a final result.

B (15:56)

That's right, yeah.

A (15:58)

And whether it's something like exploring divergent possibilities through lots of agents on a canvas that are, you know, going to paint the possibility space of it for you and then you're going to go iterate from there with something. Some of the possibilities you like, that could be visual style, it could be, you know, different structures of ia, it could be different flows. It's limited by how good is the agent at this. Ultimately, you're the judgment in the system. You're the one that's going to figure out what is good and worth exploring because the possibilities are likely almost infinite. And so you're the one who's trying to figure out what path should I look at. And if you can do even more exploration with the help of agents, great. I also think that similar sort of story is with Weavy wearing a shirt right now, the W. But I think that it's really important to also think about this with media generation and when you're actually doing work that's creative, you're again, not going to take the first prompt and it's not going to be your final result. Instead, you're going to take that first prompt and it's like clay that you mold, that you shape, and you're going to try to put it through a process where you get to the spot that you want. And there's a lot of things that are possible when you actually think about these workflows like that as an iterative process, you're going through divergent and then you're going to cut off some of the branches of the tree post hoc and then you're going to continue on and refine.

B (17:34)

Yeah, I think some of the vibe coding tools are like, you just put in a prompt and I'll build the full stack for you, I'll build the backend, the database and everything. And then boom, here's the app. And it never gets it right, man. It never gets it right in one shot. And then it's actually more work for me to try to change it afterwards because has all this code that's actually not necessary to explore the problem space and associate space.

A (17:56)

Yeah. I think the opportunity with something like Figma make is how do we both make it more powerful and make it so that it's able to be more divergent. Right now, it's something that's very linear. It's the opposite of what I'm saying. And you look at the Figma canvas and that's very divergent and lets you explore by default. That's the gravitational pull. And I think that ultimately it's like, how do you combine the power of code and canvas so that it's an and not an or? It's like there needs to be a way to bring them together rather than be like, oh, yeah, you could, like be in code or you could design, you know, which one will it be? You know, instead you want to have that tight loop.

B (18:37)

Got it? Yeah. So I guess you're not really opinion about whether people should start in the canvas or make or whatever is just like, whatever it takes to explore the idea.

A (18:44)

I think it's just start. Just start, like, do something, get something on paper in a doc, put a design together, make a prototype, whatever. As soon as you get started, you're going to really make it better. At least I do. As my perception, when I see something, it's like, great. How can we make it better? And there's a question of, okay, is it the right time to make it better? Should we get it out? What do you have to push on? And what are the things that are actually. What's the right way to approach this? But having any stake in the ground that you can try and use can be helpful. I mean, even with. I had a design review this week where the start of the week, one of our designers brought me and our chief design officer, Lord Ana, who's amazing, a bunch of concepts of, you know, very structurally different ways to explore a problem that we're excited about addressing. And we basically said, look, you're actually. You're really thinking about this holistically. That's great. But like, okay, stop. Like a third of the way through that, what you just showed us, you know, those two thirds of the design, you might end up there. But like, this first one third that you explored, like, that is enough to go prototype now, and you're going to learn from using it. So go make it. It'll be fast to make. And then go and explore more options from there once you know, sort of the physics of the system that you're creating.

B (20:12)

Yeah, maybe we can talk about company culture a little bit too. I always kind of hesitate when there's a lot of internal exploration without talking to a real user or showing this stuff to real customers. And there's like a natural tendency to do that, man, just like, oh, we're going to present the deadhead, so let's do five rounds of internal reviews before he sees any. And then you never know if this is the right thing or not. Like, how do you, how do you manage this? Like, how do you, do you, how do you discourage this? Or do you think this is the right thing to do? Or like, how do you get the customer feedback loop going faster, man?

A (20:44)

Never talk to customers. 20 rounds of internal review. Yeah, great. Yeah, I mean, like Apple said, I think that we're always talking with customers. We're always trying to make sure that designers, non designers alike, are having a chance to learn about what customer needs are. We have an amazing research team, we have an amazing support team, we have an amazing sales team. There's so many functions outside of product engineering design that are functionally part of product engineering design. I think research should be included in that set for sure. And then if you get sales to be operating the right headspace, support to be operating in the right headspace, they're bringing insights too. I mean, I'm seeing our research team use Figma MAKE in incredible ways so that they can rather than just like, here are my insights, I've made a report. It's like, here's a functioning prototype for what I think would address the needs that users have right now. Or maybe not even just one. It needs like five prototypes that we could explore or you know, here's an eval that we're considering adding. And on the support side, people are building like internal tools and figuring out how to actually advance processes and sales as well is really getting familiar with the ways to go build here. I mean, you know, something like 60% of these designs are being created by non designers. And I think that it's really exciting about make how more PMs are getting involved in the process too. You know, if you're a PM and you think that your job is to make documents and slide decks for upwards review and alignment, like, you know, you're going to love this new world that we're in, you get to make things too. And you know, you don't have to think about yourself that way anymore. How many cultures are different. I respect and acknowledge that. And I think what I will say though is that so many are changing. I think that people need to see that the leaders in their organization are making things too. And that is what inspires and actually creates the inflection.

B (23:02)

So how do you like, like encourage the product teams to like not, you know, like to talk to customers or maybe it's not happening already, but to like not go crazy on the internal prep to have a review with you? How do you, how do you do that?

A (23:18)

Yeah, I mean, whenever I hear about lots of rounds or whatever, I mean, even if it's just two or three, it's like just, just bring it directly as long as I'm not the rate limiter. And also I think there's not, I don't have to see everything. You know, if you're actually gonna go fast, you, you can't have one person be the bottleneck on everything. Right. There's some stuff that if we change will really affect a lot of users. So like, you know, if you're going to change like a core thing about the product for figment design. Yeah, I should see it and make sure that just because I've got a lot of context there, that we're doing the right thing for our customers. And you know, you'll make that loop fast. And I'm always trying to get faster, but I think that the best times where you're iterating fastest and the team is learning the most are when the team is able to be in just rapid cycles. So if you're putting like a block in the cycle, that is not ideal. And I'm not saying that we're perfect. Like we are updating and learning just like everybody else is. That's my push, is to try to determine where we need to do what and how to get to that rapid cycle overall of learning. And I think structurally finding ways for teams to create prototypes internally and share them, have less pressure about getting in front of users in a way that's going to be like a long term commitment. That is one hack. I think that, you know, making lots of things is another hack. You know, if you're not sure about the direction you should go. Lots of prototyping is one way to learn. And then you can, it's the opposite. You can put them right in front of customers. It's like, here are five ideas. What do you think? And you'll get a lot of feedback. And no one will think that you're committed forever to going this direction because you just showed them five different ideas. So you can go in either direction there. But you just have to maximize learning.

B (25:12)

Got it. And Figma Config is one of my favorite conferences and there's always some big product announcements there. But I think lately the world is changing so fast that I'm curious how long your roadmap actually is. Because people keep saying, hey, you got to have a two year roadmap. And I just have no idea what the hell is going to happen in two or three years, you know? Or do you still have to have a point of view of the vision or how do you balance the long term or short term?

A (25:38)

I think that there's like areas of our company where we're working in these very long term ways on projects that are very hard and very deterministic.

B (25:48)

Got it.

A (25:49)

And they might have like a non deterministic component, but much more deterministic than not. And those are ones where, you know, you can actually kind of plan for the long term. And then on the other side it's like, yeah, there's, there's stuff where you just have to be watching what's developing and reacting really, really rapidly. And the faster you can react, the better you have to set yourself up to be able to do that. I think the velocity that we had last year was really strong. I mean, I think we did. We should have something like 200 features. And we spent our product line quite a bit as well. And that's all learning. And this year I think we're going to do a lot more, you know, at least in terms of magnitude, perhaps there'll be some initiatives that are bigger and because it's not enough to say, oh yeah, you know, 200 features and this year we'll do a thousand features. Like that's. No one wants to hear that. That could be unnecessary complexity.

B (26:40)

Yeah, yeah.

A (26:41)

But I think the magnitude of what we do will be even greater than last year in terms of its impact on users.

B (26:47)

Awesome. Yeah, that's. That's pretty exciting. I have a, I have a quick product feedback for you. So as a pm, and I've tweeted about this before, so it's probably not a surprise. And this might be a hot take for designers, but I feel like stuff like design systems and even auto layout, it kind of just constrains my ability as a beginner in Figma to actually move stuff around and do crazy things. And I understand the point. It's like, make it consistent and make it easy to use. But do you kind of feel this tension between creativity and consistency and kind of like this kind of or even designers versus other types of users?

A (27:23)

Yeah, I think that the more structure that is there, unless you know how to navigate, makes it so that you're not able to work as fluidly as if you were just in a world where everything's flat and you can just move things around. So that's like an inherent tension. And whatever structure is in an auto layout frame or nested auto layouts, that is less structure than you probably have in your code base at the same time. So there's levels to this. But I think that's the core tension that I think matters is how do you let people be as freeform as possible and be in as much data flow as they can possibly be in, while also creating ways for folks to structure things the way that they will actually work and to be more productive? You know, I think that with auto layout, you definitely see how someone experience with it. In experience, you can build that experience very fast. It is a learning curve, but it's a fast learning curve. And at the same time, you know, it can both intimidate and it can make it so that you can work a lot faster as well. So, you know, my perfect world is one where you're able to, you know, kind of go in and out of auto layout as fast as you can, and you're able to like, you know, kind of ignore it, flatten it, and then you can, like, reapply it. Um, we haven't gotten there quite yet, but that would be the ideal is if you're able to not be bound by it, but get all the utility. But, you know, some stuff is hard to get your cake needed too, and this is one of them.

B (29:02)

Yeah, I mean, it does improve my relationship with my designer because I have to ask her for help all the time to move the box around. So that helps.

A (29:08)

I mean, that's not ideal.

B (29:10)

Yeah, that's not ideal. Yeah. Yeah, okay, that makes sense. How about everyone's talking about being AI native and all this stuff. How are you guys operating differently or type of people that you hire? How has that changed with this whole AI thing? Are you looking for people who think of stuff, who use AI on the side? How has it changed?

A (29:33)

Yeah, I think probably as long as you're not totally averse to AI, if you're someone that likes to make things and you're someone that likes to learn about technology, then if you don't have philosophical opposition, then yes, you're going to go lean in and try to figure out how to use AI to your benefit. And what I think is interesting too is that we're just now getting to a point, I would say in we're talking February 27, 2026. And I feel like it's like the last month or two that for someone that's a good engineer or a very good engineer, that they're starting to really understand the utility of AI on the coding side and how it is like obviously better than them at some, not all things, but some things and how they can deploy it. Because, you know, the very good engineers could oftentimes still work faster then you know, they might be able to then managing like a bunch of or even a few agents that might end up writing things that then they have to redo. And so now we're applying on the code side where if you know the model well enough, you know the setup well enough, you can know how to direct it and have it do some level of task for you. Now in some code bases or some setups might well have it do a lot for you. And some it's less. But yeah, I think that it's just a skill to learn, just like anything else. And ultimately you still need the basics and the wisdom that can be accumulated over years of building software systems in order to guide the model properly as well. And I think that when we're looking on the more product side or design side, we're looking for people who are technical, but also people that have craft and have that judgment. And I think that the judgment is extremely important. So I'm always trying to figure out as well who are the folks that are really bleeding edge and are consistently navigating these new paradigms in the right way and coming up with new approaches. Because that is something I think is really exciting when you find folks who are just like inspiring in their thinking and the way they can push these technologies in sort of inventive ways that others haven't yet. But overall, I mean, I think that there is a lot of engineering work that can be done through design now. And ultimately, as I fast forward even more, I think we're entering a world where design is the new code you'll be designing in a visual first way and you'll be able to do a pull request right to production. And that doesn't mean that everyone will prefer that method and doesn't mean your pull request will not be reviewed, but I think you'll be able to do it straight from Figma. I think it's coming. So I think that's where we're headed.

B (32:31)

Yeah, that's why I like wipe coding, man. Because my little apps never need any pull requests. I just merge to prod directly. So yeah, that's how I get in the zone. It just keeps going.

A (32:46)

Yeah, we have a larger team, the established code base. Not saying that everyone should just go right to prod, no poll requests, but I think there's always room to learn from others. But also yeah, I think that there's no reason why the value doesn't move the stack in terms in the ability to actually go influence a complex system cannot be done from the level of the blueprint rather than sort of like the very, very detailed specification that is code. Yeah.

B (33:16)

And I think hopefully teams will get smaller. Like three or four people can just build a really good product. Because I don't like this whole trend towards hyper specialization where you have someone who just edits copy and someone who only does design and then you can't if you wear multiple hazards like oh, why you step on my toes? It just doesn't feel fun, man. It's more fun when everyone's just a builder and can just do a little bit of everything.

A (33:41)

Yeah, I go back and forth, I mean for decade or so I was always thinking that it'd be merging of roles because that's what I was seeing was early signs that might be happening this before AI even. And I feel like more what I'm seeing right now, despite more talk than ever about merging of roles, is more merging of responsibilities. So more people wearing lots of hats but still like kind of specializing in one area. So yeah, I think it's. It is the case that like there is a craft that you can apply if you are an expert in an area. You know, for example, you said UX writing. Like I have worked with UX writers that and do work with UX writers that are. Are just incredible. And it is a very hard thing to figure out how to create a string that is like the right amount of space and communicates with the right sort of feeling what you're trying to do and what you're trying to get across the user. I mean it's tough. At least for me it's tough. So yeah, I think at the same time, you know, if you have that sense of what is the type of copy you want to create and what are the sort of style, what's the style guide of your copy then yes, you could probably have a bunch of stuff that is pre populated with a skill. That doesn't mean you're going to get to the like last final answer there. You might still want to like actually really push it forward past the ideas that are there. But it's a starting point. And so I think that this mindset of using AI as a starting point, push with craft and intention and care towards the final output that you want to get to. It's applicable for pretty much all the disciplines. And that's mainly what I'm trying to get across here.

B (35:36)

Yeah, Maybe you can collaborate with AI on 90% and the last 10% is still manual taste and craft. Right.

A (35:41)

That's kind of, I mean, I think it depends. It depends on the problem and what you're trying to achieve. Writing is an example for just more general, longer form writing. Like when I'm writing something, I do often use AI, but oftentimes it's for or most all times actually it's. It's really to understand like what are the obvious cliche ways of saying something. It's getting that blank page problem fixed.

B (36:07)

Yeah.

A (36:07)

Like I don't know about you, but I find it very hard to start a piece of writing. And so for some reason, if I can just like, you know, ramble, type, you know, what I'm trying to get across in a kind of incoherent way and then say, what are the 10 obvious ways to say this? You know, almost never do I use the result of that in any form, but it always gets me going and gets my brain spinning on, okay, what is the right way to say this? Yeah, because you know, the cliche stuff is not what I want to go do, but I want to say something that's unique or at least is helping express like a point of view that I have. And usually when I'm writing something longer form, I am trying to say something that's not been said before.

B (36:48)

That's right, yeah. Cool. Well, I mean, I mean, Dylan, let me ask you one last question. I don't want to respect your time, but let's just imagine like a year from now, like end of the year, like 2027. Where do you think we'll be with these tools? Like with Figma or maybe you can't share too much, but with Figma or some of these tools that we use to create and maybe also personally, what are you thinking with now in the AI space?

A (37:14)

It's really this entire conversation what I'm exploring most, which is just not only for design, but also for ideation and arbitrary problems. Just how do you get to the most divergent space possible? And how do you properly use AI to really explore possibilities, but at a more abstract level too? And yeah, that's something that I had a really a good time just enjoying the exploration of that and, you know, figuring out systems for myself to help solve problems. And I hope they're applicable to figma too. So we'll see. But I think if we fast forward a year or more and we're in end of 2027, we're in a world where, yeah, wherever you start, Figma is a place where you can bring things together. And whether it's building a digital product or creating ways to reach customers and express your point of view, I think that there's so many different forms that it can take, so many ways we can bring the ideas from your head onto a screen and enable all of them. And whether you're doing that all in FIGMA or you're doing it with figma and other tools, a number of other tools, want to make it so that you can have those loops of divergence convergence and really push forward and create more unique things in the world.

B (38:33)

Yes, it's kind of surprising how many of these AI tools don't do this divergence convergence thing. It's just like these. I haven't done it. I can force the model to be like, hey, give me five variations and here's the descriptions. But it doesn't make it easy, man. Yeah, don't think about this.

A (38:51)

There's a lot to explore. We're at the very start and I think that the industry as a whole is going to look back on this time and be like, wow, it was like so early to the world of AI still and how that fits into just the products that we're building. And I think that at the end of the day, to go back to the start of the conversation, I mean, we were talking about agents and how, you know, it might be interesting to think about the design implications of, you know, what does it mean to design for an agent? But, um, I think at the end of the day it's about designing for humans too. And actually humans are the most important case still, even for agents. You gotta audit them, you have to understand what they're doing, you know, and maybe if it's how you're using OpenClaw, I don't think you're probably having it fire off your PRDs or your design materials for your team, you know, to some like, review or whatever. Um, yeah, yeah, you probably are giving a lot of feedback on things and your digital twin is not doing it for you. And I think that, yeah, I think that we're all going to just push the world forward a lot more with the tools available. And I'm hoping that as we move ahead, the world gets a lot more visually interesting, too, aesthetically. I think we've been in a bit of a rut for a while as a design industry, and there's something wrong with the styles that tech companies have explored, but I think there's so much more out there that we could push towards and so many more interaction paradigms and ways that we could really craft amazing experiences for people. And I'm hopeful that this will be like a renaissance period for that.

B (40:33)

Yeah, because it's going to be cheaper to explore stuff and more people will be able to explore stuff because, you know, there's not. The technical barrier has come. Come down. So it's going to be very exciting, I think.

A (40:43)

I think so, too.

C (40:44)

Cool.

B (40:45)

Dylan. Well, thanks so much, man. Keep going, dude. I can't wait to hear what you announce at.

A (40:50)

Thanks, man. Well, we're going to launch a lot of stuff before then, too. I hope so. Keep tuned. Thank you so much.

B (40:56)

Thank you.