Stephen Haney - The 2026 AI Design Field Report (tools, process, and what's working)

There's been a heck of a debate around the future of coding and design tools lately, but what's actually happening inside of today's top teams? I've been talking to designers at Alassian, at Shopify, or Cell, Notion, like all these companies. What I see these companies actually doing is not necessarily matching up to what you'll read on Twitter. Where's all this headed? And how does the future of our tools shape the rule of a designer? What I saw was actually companies are all pretty much doing the same thing. If you're looking to work at a top company, you should probably think it starts scaling up in a way that fits into this world. Welcome to dive club. My name is Rid, and this is where designers never stop learning. Today's episode is with Stephen Haney, who's the founder of a new design tool called Paper. And for the last few months, he's done a heck of a lot of research into how today's top teams are actually using AI, everything from tooling to process to prototyping. So he's going to share his findings with us today and how that's impacting his product strategy for Paper. It's pretty fun to have a new version of Should Designers code. And it's like the AI era version of it. It's a little bit more like Should Designership, or Should Designers Build. And as always, the answer is yes, if you want to. The more skills you have, the more powerful you can be, of course. I really enjoyed it. I thought a lot of great points on both sides. I think when we started Paper, Paper is a design tool. We love design. We started Paper because we love design and it's what we want to work on. So we're maybe a little bit biased towards the craft side of things. And a lot of things that Kari was saying are very much the same way that I think about how design works and how building things works. But I think that clearly AI is like an amazing tool for, especially, stateful prototyping, interactive prototyping. I don't know if you've noticed this, but prototyping in Figma is not the best experience in the world. Like drawing noodles and you have multiple versions of things. It takes a really long time. It's kind of limited in what you can do. And so I think very clearly to me, like prompting the explosion of cloud code over the holidays was really cool to see. Like everyone was trying it. So I think like lead into that stuff, especially if you need to make stateful things, you know, things that have state, like when you click something, something else happens and then you want to show where the focus goes or what pops up or how the data loading state should work. It's amazing, amazing for that stuff. I think very clearly to me also design and engineering are not the same thing that was like one of the claims I saw on Twitter. And I think I posted, "I should get it." Let me pop this tweet. This is actually the same thing. So right at one point said, "It's the same thing so we put them back together in cursor." And I think like a core philosophy that we have is, sure, we should all be building, of course. And if you want to do both design and engineering, great, you should. It's great to do both. And a lot of them highest performing people do both. But I think that fundamentally the reason design exists as a, as a specialty and the reason engineering exists as a specialty are different and specialization is good. I think design is very much an expansion of problem space. It's exploring the problem space. I think a car you posted design is a search. And I hadn't thought about it that way, but I think I agree. It's what should we do? You got to study prior art. You need to experiment visually. You got to try 10 versions right next to each other. You need to communicate. A big reason that Figma won was how much they helped us show collaboration being important. And not sharing final, final, underscore V2 and Dropbox. And interesting thing is we've actually lost that. When you go to local dev and you're using Cloud Code or using Curse here, we're actually now back in local space. It's actually a little more friction to share things again. So talk a little bit more later. So I kind of always have this thought of building projects as kind of a continuum. And so I made this real quick little continuum chart in paper. And on one side of this is kind of like a very low fidelity. Like we should do something. We have this idea of how to make a better product, how to help people more. Here's an idea that we should do. And it's going to work. And that's oftentimes a visionary role, like a founder, CEO, PM. And then as you proceed through the project through time, you have to answer all these questions of like, how are we going to do this? Why are we doing it? How should it work? What's the flow? And that's traditionally been more of a product design role. As you define some of those things, then typically you do start getting into building. And then you start thinking about, there's pixel precision and hardware animations. And that's kind of like, we've seen design engineering become more of a role. As you go through the project, you actually get like more information and more fidelity. So you might start with wireframes. And then you have stateless design and Figma. And then you start building it and you have an actual prototype you can play with. And that has more information about how things click through and flows. And then you really start getting very specific. You're like, the backend is going to use redis instead of the database for these scalability reasons. And in mobile Safari at 368 pixels, it's going to work this way. So it's like really dialed in now. And then of course, at the far end, you got to keep it up. And then you see how you start wearing pages and stuff. This is a continuum. I think design and engineering are obviously there's lots of mix in the middle and, and, you know, handoff is still a thing that we're dealing with. But when you start to see, you know, what is it I help in designers with? The designers are going to start wearing pages, right? I don't think they should. I think it's a different job. Real quick message and then we can jump back into it. Don't be the person with the portfolio that doesn't have a custom domain. The framers latest release, you don't have that excuse anymore because they partnered with hover to provide a seamless flow where you can select free or discounted domains that will automatically be connected to your frame or site after purchase. You heard me right. Frame are offering free custom domains for the first year when you upgrade your site to a yearly plan. So definitely don't miss out on this offer. You can head to dive.club/framer to claim your domain today. Your legitimately might not be a tool that the design industry agrees on more than mobbing. Over one million designers from companies like Airbnb, Uber, Headspace all use mobbing for design inspiration. And it makes sense. It's one of the highest ROI investments that you can possibly make as a designer. I use mobbing almost every single day to look at real world examples of how different products handle specific UI patterns and flows. It's invaluable to my practice and I can't recommend the product enough. So head to dive.club/mobbing to check it out today. That's M-O-B-B-I-N. Okay. Now onto the episode. I read the designer's search and Carie's articles and I guess I kind of agree with both sides in different ways. And here's my lens and you can kind of tell me how you think about it because I look at this full spectrum that you have up here going all the way from like the visionary to the reliability. And sometimes I am operating on that entire spectrum as a designer. And when I do 100% you better believe I'm not jumping into code. Sometimes I'm just sketching in my book, you know, or a lot of times it's just me typing on a canvas. I really like words as a way to think. So most of my early stage exploration is words and then arrows to connect words and I create these little words maps. And that's my favorite way to work. But a decent percentage dare I say like at least half of the design work I do actually does have a pretty clearly defined problem because it's not greenfield. In fact, it might just be me operating on top of something that is already shipped. And it's like, hey, we ship this thing. We learn this thing. Let's make it better or we need to add this thing. I do find myself skipping some of the vector tools and exploration processes because I'm already kind of narrowed in and I never talk about double diamond ever. I'm not a part of it. The first point in my initial post was AI and cursor and cloud code are giving us these new tools for a specific part of design. Basically, my take is any tool that removes constraints that lets you be more free and exploring more rapidly and explore the problem space is good for design. I think AI is good for interactive prototyping. It's easier to do interactive prototyping. Clearly, it's easier to start from your production app where your production app is and just ask for a change. That's so much better than drawing pictures of it. I see people taking screenshots of their production app all the time and pasting them in Figma and drawing on top. Clearly, prompting is nicer than that. I was talking to a designer at Shopify who's using cursor quite a bit. He was saying, "Gosh, I didn't realize when you open new models, the focus is always going to the wrong place in our app. Now I can show the engineers where it should go. Great, easily." I think stuff like that is great. That's really cool because the designer is the person who cares and can see it and can understand it. Describing is UX. But historically, as a product of our tools and capabilities, we haven't included it in the set of deliverables, even though it's so clearly key to these experience. Oh, 100% agree. 100% agree. And that's been a tooling limitation, right? The designers are always cared and has always probably seen it in prod and tried to write a note or something. I'm really excited about that particular area of the AI. At the same time, the hype and the follow-up of the Twitter and the doing podcasts we're doing here is to say things like, you know, We don't need them anymore. Canvas tools are gone. of the same thing and so just use cursor. I don't think that's true at all. I think that's like excitement about the current moment and the new capabilities we have, which may be fair. We can get into this more later, but our vision for the future is basically agents are going to be doing a lot of the work, especially on building. And you're going to have different tools that are kind of like different input methods to the coding agents. So if you want to prompt the agent, use text. If you want to fine tune edit the code, use an IDE. If you want to draw a picture for the agent to look at, use a Canvas tool. And so I think that you're going to have these different input tools to kind of like a centralized agent probably, which is going to look like Cloud Code, at least for the next few years, who knows after that. And so that's kind of how we're going to start moving paper is we're going to build a desktop app so that it has local file system access. And it'll still have real time multiplayer, all synced to the Cloud. Very cool. You can do offline files if you want, but then that's a different thing. It'll have built an MCP. And the reason for this is, imagine, you have cursor open, you have paper open, you have terminal with Cloud Code, whatever you want to do. And they can all talk to each other. And they can all see what's in the other screen. And so if you need to draw something, you can do it in paper and then just tell Cloud, hey, can you look at what I just did in paper and do that? I think it's a really powerful workflow. And then if you need to edit the code, you can use your IDE to edit the code that it did, review the code. So I think increasingly, IDE's development environments are going to become for code review. And in reviewing what the agent did, they're really good at that. But I think we need this tool, this free form, expressive drawing tool that has just the right amount of structure, like a Figma sketch amount of structure is really good for this type of stuff. That the agent can talk to you and the agent can see. And then it still needs to be able to do multiplayer real-time collaboration, all these things that we learned from the Figma era that are really good. So I'm excited about this. This is like what we're building. I think it's become very clear in the last few weeks even how these workflows are going to work in the future and kind of the battlegrounds between different tools and everyone's kind of posturing now. Because I think we can all start to see how it's going to benefit people who are building software. One of the cool things about making a tool like paper is everyone will talk to me. Everyone wants to get on a call and tell me about what they're doing or to see if paper can help them. And so I've been talking to designers at Alasian, at Shopify, or Cell, Notion, like all these companies. And I kind of like, I've come to you to share when I've learned. It's kind of like a field report. Because I think there's a ton of hype and fomo and people saying things on Twitter. And what I see these companies actually doing is not necessarily matching up to what you'll read on Twitter, right? And I think as a designer, as you think about what should you skill up in? How should you invest your skill points in your time? You know, optimizing for the things that these companies are actually finding useful is probably a good idea. - Okay, so I want to dig into some of your research then. What are some of the main signals that you've noticed that you've latched onto that have kind of informed some of this strategy that you're talking about? - Again, there's so much stuff happening on Twitter and the hype and the fomo that I just wanted to get ground truth. As a product maker, I can't make decisions based off the hype on Twitter because I'll make the wrong thing. It's not real, it's not true. And so I just wanted to talk to these executives at these companies, these designers, at these companies that are actually using AI and getting benefit from them. And this is all anonymous. So I'm not gonna say any specific company is doing any specific thing, of course. I don't wanna do that, but this is kind of my takeaway. And what I saw was actually companies are all pretty much doing the same thing. So I think this is like, if you're looking to work at a top company, you should probably think it starts skilling up in a way that fits into this world. The first big takeaway is that AI usage is being mandated in performance reviews for designers. Full stop, 100% of designers need to use a collod code, a cursor in their work. And I think this is because companies want to encourage exploration. You're used to how you do things and how you've gotten things done in the past. And learning a new tool takes time. And maybe you have to ship something next week and you don't have time to learn something new. And so I think companies are mandating it because they wanna remove that friction. That's a very real thing that's like brand new. That wasn't happening a year ago at all. And so that's a world brand. We talked about this a bit, like a stateful and interactive prototyping. That's the big unlock that companies are getting. And it's because it hasn't been great in Figma in the past. Figma sketch are great at design that doesn't have any state. They're not so great for explaining state or focus, or things like this, hover states. You gotta draw three copies of something to explain. And then you can't really show animation or transitions, right? So prompting is great for this. And it's how these companies are using it. Is they're taking their production out. They're actually forking it. Pretty universally, what I'm seeing is nobody is PRing to prod. Designers at these kind of companies are not PRing to prod. AI is not suddenly people are coding and building and shipping at these kind of companies. No, it's that they've actually created designer copies of their repos for designers to-- it's like a designer playground. The reason for that is that there's a lot of problems if you're actually just trying to design in a code base. There's like, what to have this frame about new friction, like environment variables and local databases and linting and deploys. And they've sometimes the build fails. And none of that is useful for design. So that's why they're creating these designer playgrounds. And these forks of the code base. Can I ask you a clarify question here? Because you talked about the AI mandate. Then you talked about tools like cursor, cloud code, the forks of the code base. When I read forks of the code base, I basically do just tie that to cursor, cloud code. How much are you seeing more of these isolated prototyping tools make lovable that kind of a thing? Is there a trend that you're noticing between the types of AI exploration? Because it's very different. Which path you take, but a lot of times I can just kind of get looped together in the same conversation. I'm seeing a lot more cloud code and cursor than lovable Replic V0. I think that the one company I talked to is using Replic. And it was when I heard it, I was like, oh, wow, that's for some of her that actually. Replic I think is maybe trying a little bit harder than some of the others to court enterprise and to court bringing your existing design system in. The big difference though, really the big difference between Closer, Cloud Code, local development, local prompting versus these cloud hosted solutions is when you're local, you're using your actual code base or you're using a fork of your code base. And so that starting place that you get, and I keep hearing everyone's using the word starting place when I talk to them, that starting place that you get is your real app. It's your real app. It's like you don't have to recreate the screen that you had before because it's already there in your app and you can just ask to change it. Whereas if you use a lovable V0 Replic whatever, Replic is doing a nice job of like cloning your design into Replic components, but you still need to, it doesn't have your real app in there, so you still need to rebuild screens from scratch. You're starting more from scratch on those flows. And that's not a knockout Replic. That's just kind of like how I see it working. People are working on things with GitHub integrations. We're working on something like this to kind of pull your design into the tool, which is great too. But that's the big difference of local dev. It's one of the reasons we're making a desktop app is to have access to your repo because I think it just empowers all new types of flows. So at these kind of style companies, so here's the biggest claimant, right? At startups designers, probably already coding, like startups are like seed stage startups are a whole different ball game. At these kind of companies where you get this kind of specialization because the jobs are so big that you need to have multiple people working on it, they are using local Cloud Code cursor much more than the Cloud Hosted stuff. Another big thing is like, it's still hand off. I've seen some claims like hand office dead, designers can code now. I'm not seeing that at all. These are still specs. They are specs with a lot more information inside of them. And that's a good thing, you know? But designers are still sitting down with developers and they're still, here's how it should work. And I drew this prototype for you. There's some exceptions to this of course, but I'm really not seeing much PR into production. And I'm not even seeing designers wanting to PR into production, like when I asked you, do you want to, they're like, yeah, like it may be nice to like change a color or change some copy, you know, like it's minor tweaks. But again, as a designer, do you want to start wearing a page or like, of course not, like that's not your job. And you need to be thinking about all the things that are your job. And so PR into production comes with maintenance burdens, it comes with a different type of accountability for making sure that you didn't break something else, you know? And I think maybe over time, we'll see that break down, you know, as AI empowers people to do more and more. But this isn't a tooling problem. Once you're deploying something live and you're wearing the page here and you're making sure it stays up, it's just a different job. There's a job friction or specialization there that nothing to do with tooling. And so I don't think tooling's going to change it. What do you think about that? Does that make sense to do that? - I'm biased, I'm biased. I'm literally like the seed stage startup and I'm my own boss. So I can do whatever the hell I want. And I want to build and own a lot of the things. And so like a flow that is typical for me is, I will do more of the Greenfield exploration on a canvas. It's very traditional handoff with annotations and like engineer will wire something up and it'll look pretty good. But in the past where I would then have, you know, maybe a bunch of GitHub comments or linear tickets of all the little things that like are not quite right, I don't make any of those anymore. I just make a PR. And I fix all of them and then like tighten up whatever we just shipped. And then what it ends up in like the final state is what I made in code with the disclaimer being like small team. - Yeah, 100%. I mean, and again, this is like big companies with teams that are specialized. I think the startup-- - Shopify had last year or working differently. - Yeah. I mean, in a paper like everyone codes, everyone ships, people who's title is designer, they're opening PRs. But they would have done that before it had to, right? So like there's, I think, and probably same for you, right? Like you were probably already wanting to own that stuff, pre-AI, right? I might make some people mad. I think working at a startup is harder than working at a big company. They're harder in different ways, of course. Yeah, yeah, yeah, yeah. - But like how it take indeed. - You have to do a lot more, you have to do it a lot more quickly and you have to wear more hats and you have to be like more horizontal. And that's a good thing. I think if you like it, I like the challenge of it. And so I encourage people to like lean in and do multiple things. Like yeah, do the engineering, yeah, do the design, you know, like go ahead and do the reliability. If you want to get into databases, I think the most fun people to follow on Twitter are they blog about stuff, they'll blog about a shader and then they'll blog about like how databases work the next day. You know, don't get locked into thinking you can only do one part of this piece. - Really granular question is, I'm interested in this trend that you're seeing where designers have their own forks of the code base to play around with. with and make a mess with. Because I find so much value in being able to just start on top of whatever is in production, because I have been that person that's been taking screenshots and then widening things out. It's just horrible, right? As code has kind of run away with AI, the amount of time that I've spent trying to just like catch up and work with something that feels at least close enough to a source of truth is incredibly annoying. Yeah. That being said, I'm somewhat technical and the idea of figuring out how to like fork a code base and make my own sandbox, like that kind of goes beyond me. So are you seeing teams that are empowering designers and setting this up for them? Like is this an intentional time down investment that companies have to make? Yes, 100%. And it reminds me of how we've all been maintaining two copies of our design system, like one in Figma and one code for many years. And now it's like, well, now we're going to maintain two copies of our app, like the real copy and then the designer copy and that one might fall out of date or like we got to somebody's got to maintain it. So 100%. So one of the things I was looking at is like, we're going to the new problems because we've solved some stuff for prototyping, but we've also given up some things from the previous year. We moved away from local design for a reason, right? Like the benefits of sharing for design are so huge. Collaboration, part of your job is making sure stakeholders are signed off or engineers know what to do. And so having your file in the cloud is really helpful for that and having real time cursors is really helpful for that. When you're prototyping with like a cloud code, if you're forking your repo, like you have to set up your local environment, right? And like that's not helpful. We talked about this. Linting is something I keep hearing about. Like people are like, oh, I just don't care. It's got to squiggly, but like it works. Like why do I have to fix this thing? And that's like an engineering problem, right? It's for long term maintainability of the code base. It's not useful for prototyping. Sharing is really painful. There's no real time collaboration. And companies are building. I don't know if they've talked about this publicly. So I won't say who, but like one of the companies is as built this entire like vibe code sharing platform where designers can literally, it's like a FTP server. Like they drag and drop their files from the GitHub repo into this FTP server and then like it deploys a preview for them. So 100% companies are building tooling around these flows. But somebody has to build that, right? Like that's a cost that they're investing in and maintaining. Hey, really quickly, let me tell you about the all new dive talent network. I've hand assembled over 100 of the most talented designers in builders that I know so I can recommend them to my favorite companies. So if you're listening to this and you're opening new opportunities, the talent network is anonymous and super low pressure. It's just an easy way to see what's out there without having to post on social media. So if you're interested in joining or maybe you're looking for your next hire, head to dive.club/talent. The last few design deliverables that I've had have been more in this iteration second diamond. I don't actually really know how to share them. It could seem so silly, but it's like, did I really got to sit here and wait for this like for sale deployment link? And then which of the tag links in that model do I actually share? It's like, it's just, it's not built for me. It's like not a flow that is built for me. And I've definitely been feeling that frustration lately. Exactly. That flow is built for engineering, right? And so there's just parts of it that are not helpful for design that I think will shave off over time. And for sale preview links, by the way, are the class of engineering preview sharing. That's the best it gets for sharing repo previews. But it just doesn't compare to being an economist. Like I can send you this URL right now. You can hop in here and edit it. It's just a different modality of sharing. So we need to find a way to bring this back. He's kind of might take away two prototyping flows. One of the things we didn't talk about is people are prompting their own tools in real time, which is really cool. So like they will prompt a version picker into the lower left hand corner. Like, Claud, please make me a version, because I have two different versions. I want my stakeholder to see and I can make a little control like live. One person I talk to, they prompted, can you make a markdown file that just lists all the permutations of my state of the dialogue as a handoff? So they're like prompting a handoff tool. Then so smart. Here's like, can you make this markdown file control the state of my app of my prototype? And so that now he's like editing the markdown file to actually like change, which is funny, because at some point you start like reinventing your own design tool in the prototype. But it's really cool. You can kind of like real time load these tools, whatever you need. The flip side of that is everyone's like prompting the same tools over and over and prompting takes time and money. And so people are spending a lot of time making these version pickers, making these ways to like share that are more inherent to the way we've been doing design in the past. And then we talked about the maintaining a designer fork of the code basis. Somebody's got to do it. And then again, take time away from somebody else. I think there's one more thing here too, which nobody's talking about this. This is kind of my takeaway. We're a designer at one of these big companies might have just spent four weeks building a prototype that's like really dialed in and has a lot of information about it. Was that actually faster than the old way? Not sure, not sure. And I think there's a lot of excitement and people are able to do these new capabilities and executives are getting rewarded if they get their teams to use AI. And so they're forcing their teams to use AI. And then everyone's really excited if it looks like it's working, which is good. And I think because we have all this exploration, we will find new flows that work and are actually advantageous. That's something I've noticed and something like a couple people have mentioned to me is like, is this software that's being produced actually better, like higher quality? And is it actually being produced quicker? And I don't think that anyone is like sure about that yet. I haven't seen that. And I feel that myself too, like I use Opus, I use cloud all the time. I'm not sure that I'm actually faster. It's certainly easier. But in an app like paper, there's so much complexity that you get into that you have to review all the code. You can't just trust it, right? We're not vibe coding paper. And so is it actually faster? Like, I don't know. We're not 100% sure about that yet. So these are kind of like the new problems. I mean, what's your take on that? Have you sped up doing these the new ways that you're working? - I have so many takes. I'll give two of them that are parallel to each other. One is I have definitely fallen into the trap of chasing the shiny thing for the sake of tinkering and exploration, which I do think is a good thing in general. If you figure out the way that you shouldn't do it again, great, you learn something. But I have spent two full days, like full working days on a fully interactive prototype, like in Loveable, when this was like before I was even using Cloud Code, for instance. And it was amazing. And it felt like I was shooting electricity out of my fingertips. And when I zoom out to like a two month time span, I wasn't even solving the right problem. (laughing) So there's like, I feel a lot of, Cari's pushback, for instance, was, you know, we're just compressing the process, but we don't want to compress the thinking part just because we can jump right to execution. That type of logic makes a heck of a lot of sense to me. And I'm trying to be a little bit more sensitive to it. I think Tommy yesterday tweeted, I'm gonna botch it a little bit. - Well, I'm gonna get this to you, 'cause I think it's so funny. I think it's so funny. And we're gonna read it exactly. He says, "Working with designers is way more fun than working with AI to design, but working with AI to code is way more fun than working with engineers." (laughing) - I love it. I just like, yeah, and, you know, I'm an engineer, right? I do both, but like most of my backgrounds and engineering, so as an engineer, I fully agree. That's probably not gonna change. We're working really hard to make it more fun to work with AI and design. Yeah, that's kind of what paper's working on, but there's something inherent there that's not about tooling. That's more about solving the right problems and how you solve the right problems, the philosophy of building things that I think's really interesting. Sorry, point two. - Okay, yeah. This is my second take that is kind of a little bit separate, but it's something I'm thinking a lot about. And, you know, we have so many different text stacks. Me working on a new B2B startup. My experience is so different than somebody working on legacy banking infrastructure. We're both writing a lot of code and solving interface level problems, but like it's pretty different, right? That gap is about to increase by an order of magnitude where it will almost feel like a different profession. And I think we're already seeing that just a little bit. My engineer said something to me last night that kind of shook me a little bit. He's like, your last PR, I just played with it. Like I knew there weren't gonna be any massive infrastructure level changes. All I did was play with it. It felt good and then I approved it and that was it. And it's solely because he trusts Opus way more than the last models. Like that feels like a step change. And it really is only possible because we're doing the typical TypeScript, Tailwind, SuperBase, Snacks, like that kind of thing. And there's such a network effect happening right now around that modern web stack because the models are so good at it, which makes more people wanna go to it, which makes the models better. I think that flywheel is about to spin out of control where if you're building in that bubble, the way teams operate, the way software is built will look so incredibly different than what we're used to. 'Cause I think it's on its own kind of trajectory. Curious if you have a take on there. That's something I've been thinking a lot about. I don't remember who tweeted this yesterday too. They were talking about is this peak library? Are we never gonna make more libraries? Because the libraries that exist right now are kind of like the network effects are just like locking them in, right? Tailwind, Radix, maybe base UI we'll be able to get in with Radix, I don't know. These libraries are just gonna like lock in everyone's building with them and because everyone's building with them, the AI trains on them more, it gets better at them. It'll be really interesting. I don't know how that's gonna shake out. My take is like, yeah, it looks like they're gonna lock in and we're not gonna probably get you primitives. Some of that is that the primitives are good enough now that they actually are letting AI do this. And so really if you really wanna think about it is like, why did the primitives get good enough just in time for AI to arrive too? It's kind of this convergence of like, you know, tailwind and these unstyled component libraries and it worked out pretty well, right? So I do think that's true. And then I think the teams that are working this way are going to look, the tooling is gonna look different. The job titles, that's really interesting. The job titles we're gonna look a lot. a lot different than if it were working on some legacy app where you can't use these tools. I kind of get excited about what can we do that's new. And so I like leaning into the new world. I also think that as a tool builder, a lot of people are like, you can't build stuff for old flows because people have solved them. Even if there's like pain in those flows, they feel like they're solved enough. Jobs have been created, people have been hired to do certain jobs. And so in a way they're solved. An example of this is maintaining design systems in Figma. A big thing that I think is really cool in papers that we can render real reactive components. And so you don't have to maintain two copies of your design system. I thought this was gonna be like, I thought I'd be in sales calls and people would be like, no way, that's amazing. And everyone's just kinda like, yeah, cool. We got a team that does that though. We already have a team that does that. So that's not really about that. That's an example of you can't fix old flows necessarily. You need to lean in and build new stuff that is just a totally new flow that works better. So that's why I kind of spend more of my time thinking about what can we do in this new world, I guess. - Let's talk a little bit about that then. Like where do you point given? 'Cause I can't remember how long it's been since we talked. It's like under a year and yet it feels like a lifetime given how much has changed. And so I'm really interested in hearing how your views on your own product strategy have evolved just based off of the rate of change and these things that you're learning from research. - We started paper, it's only been about 14, 15 months now. And when we did it, like what I could see was everyone's in Figma, Figma's the dominant player. Some of their technical choices they had to make eight years ago with using a WebGL Canvas are gonna start looking constraining in the age of AI because AI is really good at code. It's not really good at drawings that are a proprietary Figma API. And so I think you see people struggling a bit with the Figma MCP server and it's like, why isn't it working better? And I think part of that is that the data in Figma just isn't code. It's like they're made up data format. And at the time they had to do that for performance. I mean, God, I'm glad they did 'cause they've done so much for the design community. But we saw like, wow, they're gonna have some technical constraints. I think they went public pretty recently. So they're getting a lot more corporate themselves and a little more enterprise focused. And so we just wanted to come in as like a tool for designers that just, we all love design. We're super focused on design. We wanna make the tool that we want. I didn't know exactly how. I was like, I know we wanna do this. I know Figma's gonna start looking a little old soon. And I don't know exactly how or what, or who is the next thing yet. And so let's get in the game. Let's start building a great tool. And like, I'm gonna be talking to people every day. I'm gonna learn from it. And yeah, like I said, over the last few months, and even the last few weeks, it's really crystallized. Like this new flow. I was very anti-MCP at first. Yeah, I was like, this is such a hype thing. Like no one's using it. I actually think the need for MCP is real. Whether it's MCP or something else. The idea that your tools can see each other. See into each other. You know, Figma is a wild garden very much. Like, they lean into that. We wanna make paper very open and very like programmable. And everything's an API. Like a frame can be an API if you wanna script against it. A frame can be an API. If you want your coding agent to script against it, which is gonna happen, that's actually what's gonna happen. So we're gonna build this desktop app. And it'll be, you know, it'll sink to the cloud just like any of our files do. So you'll have the real-time multiplayer. You're coding agent. You'll be able to prompt, to cloud, and the terminal, and be like, you know, if I have this selected, and I go to cloud and terminal, and I'm like, hey, can you just grab this text that I have selected? Like that's all you're gonna have to say. And it's gonna be able to go into paper and pull it out and use it and you're designed. And so I see in the future, again, I see like, maybe it's a terminal, maybe it's not whatever, but that coding agent is gonna kind of be this central orchestration. And then you're gonna have these tools that are different input methods to talk to it. And building a canvas is really hard. It's like very hard to make this canvas that does all these things in a great way. And so I think that this is something that's like one of the input methods we will have to these AI agents. And another one will be an IDE and made the terminals currently the other input method to them. I think this is gonna be like really fun. I think it's gonna be so cool to just have your drawing tool, to have your IDE, to have your agent, and they can all talk to each other and they can all see each other. And if you need to talk to your agent in a drawing, where you can like alt drag the clone, you can do that. And if you wanna talk to your agent in code, if you wanna write it a quick example, you can do that in your IDE. So it's like whatever you need to do in that moment, you'll have the right tool to like, talk to your coding agent. - And the coding agent on in this situation just so I can be super clear. - Is that, are you talking about cloud code or whatever that becomes? - Yeah, so I think right now we're gonna use MCP because that lets us kind of, whatever agent you're using that can use it MCP will be able to talk to paper. We're also building an agent in paper. So I'm just gonna like, you know, so it'll be like probably replacing the layer tree. If you wanna go into agent mode, it'll replace the layer tree 'cause you're not probably not gonna be using your layers as much. - Sure. - And then you can prompt a canvas-aware agent. So if that agent's gonna be able to see all of the things on your canvas, your colors, any you could paste in a reference design, you'll be able to get context into the agent like super easily. One of the things that canvas tools are so great for is having a bunch of context in one place. And so I think paper will also become this context management tool. Maybe you're pasting in videos and gifts and text and colors and design system stuff. The agent you're prompting can just like reference all of it really easily. So it'll be this communication method for you to get information into the agent. You know, a terminal's not so great for that. Like I don't know how agents are gonna look in terms of like, is it gonna be in the terminal for a long time? I'm not sure. But I think making a tool that's like programmable and open and like whatever agents themselves shake out and whichever agent you prefer, you will have this canvas input method to it. This way to draw pictures for your agent, whichever agent you wanna use. It's kind of the engine there. And then I think there's this other layer too of this starting place. And that's we're going to add stateful prototyping. So into paper and because you can bring in your actual repo and your actual code components, you can get that starting place and then do stateful interactive prototyping. In an environment that's like multiplayer and like collaborative and automatically, if you wanna just send it to your PM, you can just send them a link and they can come in and look at your prototype, right? I think it's like trying to combine the best parts of the new world and like that previous world. Which is a shift. It's a shift from the last time that we talked 'cause I remember that was like an answer to what you were specifically deprioritizing. A large part of it is like the core engine is much further along now. Like we have all of these things, editing tools that we didn't have before. You know, you can do like text wrap pretty and if you're using a variable font, we support variable fonts now. There's a bunch of design tool table stakes that we needed to build to make a really great design tool and this is by the way stuff that will never exist in a terminal or will never exist in an IDE, right? They're not gonna build a variable font. It's very complicated. You need to be a designer to even know how to build this. So we post this build log. You can check it out, paper.design/build log. A big part of it is just like the core engine of paper is like getting more mature now. And so we have less work on the core engine and we have more ability now to start working on AI flows. And part of our strategy was like, when we get there, it'll be more obvious what to do with AI. And I think that's like, yeah, that's now. - That works. - That's how. (laughing) It's like, oh, no, don't go too late. We need to move on it now. I guess a part of this that's still a little bit hazy in my mind and I know you don't have all the answers, but I'm kind of just curious to hear you talk about it is. If at least for some subset of users or use cases, paper is this kind of context layer that is powering maybe a separate coding agent, are we in all worlds racing towards this existence where design kind of does lag behind code as a source of truth? And maybe it's actually less of a prioritization to have this one-to-one match of what is in production on a canvas. Is that something that we're just gonna let go of? Is it solved in other ways? Are you gonna be like pulling stuff down from GitHub or are you still envisioning a world where like, yeah, actually, most people aren't going to be just pulling context out and it is gonna be more like, quote unquote polished designs that someone else would inherit. Talk to me a little bit about that relationship because that's like one of the big question marks I have. For years, I put so much emphasis on keeping Figma up to date and now I'm like, I just gave up. I just gave up. It's not even a thing I think about anymore. Tell me really, tell me. When we were building modules, my previous company designer has really felt, everyone felt like the source of truth of design was in Figma and I just feel like no one thinks that anymore. Maybe there's still some teams that maintain design systems or whatever, but like, design is being disposable is like a good thing. My paper, my notes from today's conversation, I'm gonna throw this in the trash after, right? I don't need it anymore, but I think also that LLMs, they break down the differences between formats too and so the ability to bring stuff back where it is like which tool it's in or what format it's in is going to matter less in the future because the AI can translate between them really well, which I think is really good. So it'll allow you to be disposable if you want to be disposable, it'll allow you to bring things back from production and work on them on top of them if you want to work on top of them. I think that being really interchangeable, production code versus in your design tool and everything's just flowing between them is a little bit further out. I think that's on the order of years. Okay, I know where it's really seamless. Maybe we can do it faster, I hope so. The coding agent is going to do translation, but you're gonna still feel a little bit of there's your canvas with things like colors and then there's your code with things like components that are like stateful. And I think that the thing we need to solve is getting the stateful components back into a canvas environment that's still a little muddy for everybody. So I think we're gonna get there though. It's gonna feel so much more free flowing to be able to just like take things from prod, get them onto a canvas, edit them, PR them if you want to, get them to an engineer if you want to, like the breakdown of formats is just going, it's like not gonna matter what format your thing is in anymore. It's just like what information is contained inside of it and is it useful for the other tool to use. Can you talk to me a little bit about the tailwind partnership? I saw the tweet, I saw what Adam wrote. It was one of those things where it was very clear to me, like okay, this is a big deal, but I also, like entirely sure I wanted to unlock. So help designers think a little bit about why that was something that you went after and how it could impact the way that we work. Well, so LMS uses tailwind, like 100% of the time, right? Back to the network of LMS. Yeah, never come to the list. Tailwind's great. We use it, there's a lot of advantages to tailwind. There's a lot of technical benefits to using it too. And top of just like what it lets you do as a designer. or an engineer. I really like them. We're friends, we get along, we have some of the same philosophies, and I think having them involved in paper is going to help make sure that the choices we make are really aligned with how tailwind works and how front and end engineering works. The feedback they give us, they get all of our early builds. One thing we're shipping like this week is SVG editing of colors. Right now, a big limitation paper. You can't edit colors in SVG yet, so we're going to ship that. They're like, "How do you make me?" They're like, "Where is it? Where is it? Where is it?" So just having them be a part of our inner circle is really helpful. We're discussing various ways of building a tailwind to wear agent, like an agent that can build using tailwind as a source of design inspiration and an idiomatic tailwind design agent is one thing where we're like, "Hash it out." But then another big thing is just bringing tailwind in an important export idiomatic tailwind code. So anything you build in paper is already a React component and you can copy it out as tailwind and you paste it and get tailwind classes. This is great. A lot of times what people are doing with this is they're actually just putting it into an LLM. They take this and then they paste it into cursor or paste it into cloth. But it's already like in tailwind. So we're going to add our theming and our tokens are going to be based on the tailwind ways of doing tokens and theming and things like this. That's just because why have design and engineering be separate on these things? Why have a proprietary Figma token system and then the engineering has a token system that's just as good. In fact, engineering's token system is better. It's more powerful. Let's bring that into the design tool but in a way that's friendly for everyone to work with. That's what we're going after. And I think over time you're just going to see more and more benefits of that partnership and just having them in the room with us helping us design decisions. What else? What have we talked about that's kind of rattling around in your brain based off of you spending probably an ordinary amount of time just dreaming about the future where this is all going and what your strategy is to navigate these waters. So we recently had a daughter, something like father mode now. So like father Stevens advice to designers. Lean into it. Have fun. Skill up like 100% skill up. Find time to go play with these tools. Even if you don't need to use them in your job yet, they are going to matter. The ability to do interactive prototyping is certainly better than it ever has been before. You need if the jobs are going to require that. So definitely lean into that. Don't buy into the hype too much. You know, you're probably not left behind. Everyone's exploring. No one has the answers right now. Like, you know, we're trying to figure this out on the fly for the product. We're building everyone's trying to figure this out on the fly as a group. Like all of our explorations are going to uncover kind of new ways of working that are really cool. So like just just be part of that and enjoy it. And then also like watch out for people selling you stuff. You know, a lot of the FOMO, a lot of the people that drive the hype cycles, they want you to use their product in particular. I'm sure we probably do some of that too. We want you to use paper, of course. But always keep an eye out on like whenever you do see that FOMO stuff. Who's in the replies? Like, are the replies full of high quality crafts people that have been building great stuff for years? Maybe listen to what that person saying. Are the replies a bunch of AI bots and like, you know, people maybe they're just saying random stuff. You know, maybe you think that one might be more FOMO. And so that's kind of how I try to sort the noise from single. I love the ability to do AI prototyping. It's so easy. The powers you get are limited. But what you do get until you hit those limits is just so effortless. And I think that's great for design. That effortlessness to produce ideas to explore. That's great for design tooling. So building on top of that, something that I've seen or at least maybe like a strawman that people create to not play and to not explore with these tools is they point at like some of the use cases where it just doesn't make any sense to do AI prototyping. I'm like, you're totally right. Like we're not taking an old, in my opinion, much more rigid, predictable process and totally replacing it with something new. It's just all of a sudden a big part of my practices of designers kind of at each new release or feature a project, however I'm working is taking a second to think about what's my process for this initiative because it might look completely different than the last thing I did versus the last thing I did. And I'm finding so much more diversity in how I'm operating as a designer. And I'm having to put more thought into like, what's my path for this thing that I'm trying to accomplish? And how is that different than the thing that I did last week? And that delta is much, much, much larger than it was a few years ago. Like night and day, whereas before I could have given a very straight answer when, you know, if you were interviewing me for a role, be like, talk to me a little bit about your design process. I would have had a rehearsed answer that I just kind of run with little deviation. And now you'd ask me that question, I'll be like, shoot, I don't know. Yeah. Well, I think there's two ways to look at that. And one is to see it as a lot of work and kind of like be a little crumbuginy about it. And like I know my way and I'm going to do it my way. By the way, there's going to be tons of jobs that do things the way that they've been done forever. There's always those kind of jobs to the other way to look at it is like, what can we do? Well, let's explore. Let's have fun. If we find new ways to do things that are useful, gosh, that's great. You know, and then we can share those with everybody. So I see it as a very exciting time. And I think where people are, you know, where people get into trouble is on either side of the extreme. Like design tools are dead. Everyone's going to be prompting for design and probably not true. We've covered all the reasons why Canvas tools are very useful. Papers, still useful. Pens are still useful. And then the other side of that is like, hey, I's very bad at visuals. I refuse to use it, you know, for very whatever reasons you have. And some of those things are true. But like, this is a new capability that we have. Like, let's explore it. Let's see what it works. And very much so the companies are doing that because I think companies are good at this. They are saying, here's a new tool. Let's explore it. And that's where you start to see things like mandated and performance reviews. Just make sure that we're exploring these things fully. And those are the times with the greatest opportunity times of change times where people can make a name for themselves. They can, they can find things that the community really values. And they can do new workflows that are really valuable at work too. So yeah, my advice is more to lean into it. But try not to like, you know, worry that you're missing out or anything like that. I saw a lot of tweets over the holidays. Like, I'm behind somebody very not behind was tweeting. I feel it's more behind than I've ever felt in my life. I know the tweet you're talking about. It was the, it's like the old like VP of engineering test or something. Oh, Carpathy. Yeah, exactly. He's like the least behind person in the entire world. His mental models of AI are incredible. He's the only person on Twitter that I have notifications turned on for when he posts. No way. Wow. That's amazing. It's because his, his understanding of his mental models are just like incredible for piercing the complexity of AI. And if he's saying he feels behind like everyone feels that. So like, you know, I think the flip side of that is just trying to find your excitement and your joy and exploration and building stuff. And I loved what I saw over the holidays with people building, you know, synthesizers and games. And you know, that's a great way to explore and have fun. I've been sent three different test flights by designers who didn't write like hand write a single land of code. And they built entire mobile apps over the Christmas break. And it's cool, man. You know, it's like, it's cool. Are there all kinds of pros and cons in a lack of nuance conversation? You bet. But it's undeniably cool. And I'm appreciative of you kind of coming in and honestly, just kind of being an open book. You know, you have a lot of incentives to not share all of this and to come in and say, like, no, no, I did all this research. This is what I learned. And this is how I'm acting on it means a lot. Yeah. 100%. I mean, we want paper to be like I said, an open platform and open tool. And I also want to hear where I'm wrong. So if you if I said something today that like you as a listener disagree with, like shoot me DM, my DMs are open. I want to hear about how this is evolving too and be a part of it. So, yeah, thanks as always, it's awesome to see you and great to catch up. Before I let you go, I want to take just one minute to run you through my favorite products, because I'm constantly asked what's in my stack. Framer is how I build websites. Genway is how I do research. Grenola is how I take notes during crit. Jitter is how I animate my designs. Lovable is how I build my ideas in code. Mobbing is how I find design inspiration. Paper is how I design like a creative and raycast is my shortcut every step of the way. Now, I've hand selected these companies so that I can do these episodes full time. So by far, the number one way to support the show is to check them out. You can find the full list at dive.club/partners.