“…The benefit of Figma in the past was that it was the fastest way to get an idea realized. And that's no longer the case.” PJ Onori · Design System Office Hours
User Experience · September 2026
Onori has been arguing that designers who direct an agent are not really working in code, and that the field now has three tools to choose from rather than two. The line is his diagnosis of Figma's problem: its advantage was speed to a realized idea, and he thinks that advantage is gone and starting to erode the tool's value. He says he would not want to be in their position.
Transcript
I agree. On that note, how are your, how's your design work thinking about using these different tools? Because the more I think about it, I don't necessarily think it's design versus code in this case. I think a lot of designers. Are going to be not necessarily using code. They're going to be using an agent to produce code. And I think those are different things. I think there's you yourself designing in Figma, you yourself designing in code, and then you using an agent to design in code, which I think is a completely different thing altogether. But I'm curious to hear your take on that.
So when I say that I'm coding, whether it be vibe coding or whatever we call it, agent coding, I don't know what we call it these days. It's like AI-assisted coding, right? So it's, I guess, the best way to think about it is I'm not, and I'm not one to do one-shot type stuff. My work takes multiple shots. A lot of times I'm hitting the backboard, I'm clanking on the RAM. Sometimes it goes straight in, but it's a pair program, like pairing with an agent. Oftentimes, I think I've gotten in the, a lot of this is, I think a lot of this conversation is about breaking habits, whether they're good habits or bad habits and trying something different. So I think it was about a year ago. So a year ago, this time, I remember was the last time I went to visit our Etlassium home base and we had a big kickoff to introduce us to getting comfortable with using our specific harness for design-oriented things. And I think things in August of last year are much different in terms of model capability. There wasn't the ability as much to create components, or we had the understanding of tokens and obviously some more nuanced design system-y things, but it was more on the primitive level. I think at that time, my thing was I wanted to try to use it every day to try to see if I could do something. So that was the time when I was doing a lot more tooling, creating things around how I could speed stuff up in Figma or how I could sync tokens from code to Figma and then back. I think the what is the FOMO piece? And I think what stresses people out or makes people anxious is that this stuff is changing constantly. I don't want to say things are changing daily, but they're changing week to week, right? So if you're not playing around in the tools, whatever the tools may be, or Arnises or models or whatever, it may be seemed like you're left behind, but I wouldn't think about that. There's enough material out there, like on Twitter, LinkedIn, even people at work are just recording lots of demos. I think the fun part of that from being an earlier adopter, I'm not saying we were like the earliest of adopters, is we're able to figure out how we could use the models in the best way with how our design system works now. For instance, like the first type of automation that I was writing last August, September, was writing a Bitbucket pipeline to sync the tokens. Now, there's not a lot of information about Bitbucket pipelines online. So that was a little bit hairy. I think the benefit of that was I was using an internal Robo Atlassian harness. It had better knowledge of Bitbucket. So I kind of stumbled my way there. And that is one specific project that I would say maybe every like quarterly, I would revisit it. And as the models change, I would just refactor the code like over time. So that's changed my way of working. I found that I'm spending less time in Figma, but I'm also, I think that's also the nature of my role now. I'm supporting more design language, tokens, theming, that sort of thing. I'm not designing components. So I think that does take me, gives me the opportunity to go further into code.
It'll be interesting because I do get a little nervous when designers say that they're now working in code when they're not writing any code. I would say that they're working with an agent and the agent is producing the code. But if there isn't an understanding of how that code works, I would say you're not working with code. It's more of acting like a manager or an art director than a person directly on the work. There's strengths and weaknesses to that, right? If you're directing it, you're less partial to the output of it. So you can be a little more critical and less biased of what you try to evaluate and figure out how to break it down and describe what the intent is. But there's also a lot of learning that happens as you are directly working on the thing. The cliche happy accidents or, oh, I didn't even consider this thing. Just trying to solve, work through a problem is really important, understanding the constraints. So it's almost like we have three tools now to choose from. Each has their own strengths and weaknesses. The benefit of Figma in the past was that it was the fastest way to get an idea realized. And that's no longer the case. And it starts to erode the value. Of it. And so, if I was Figma, I'd be trying to figure out how to get back to the path of least resistance to getting idea ready to review. Not an easy problem to solve, but I think something that they're going to have to figure out quickly.
Yeah, the early findings, like when we've, I, and I'm just using this as like a third-person assessment. I haven't gotten a chance to test like the code layers or like the local make, but I think that's very early days. Uh, code layers is more or less like just an iframe that pipes in your components onto Canvas. And then the local make, aside from it using make, which isn't preferable for us, is on the slower side to render. I think there's some improvements there and in order to make it enterprise-friendly. It would be great if there was a Figma light that's a canvas that's more or less like the this is like the imagine like you're in Z VS Code and you have one pane open and then you have another browser pane that's within that. So imagine if that was like Figma, right? Or it's Canvas Lights and it's just an interactable canvas. That's also the view of the outcome.
Yeah, I think it's going to be an interesting place for Figma to try to figure out. I don't, I wouldn't want to be in their position, is what I'm saying. Because while I think that there are three separate tools and that a lot of designers aren't working in code, they're working with the agents. I think, I don't think that's the majority opinion. I think a lot of designers that are using Claude or Gemini to produce code are thinking that they're working in code and that they've already made that mental shift, whether that's accurate or fair. And I think that's working against Figma because now they're quote closer to the code than they've ever been when they're not because they don't know what any of that code does. It's still an abstraction on top of the code. But I think they're also working against public perception, which is a tough one.
Oh, like I've been playing this. This is a tangent. So I've been getting into cozy gaming. Have you heard of that term? No. I just found out about this. It's like Stardew Valley, games that are very long, very calming. That's what we're doing, where we're watching our avatar NPC code and we're interacting with the code. Oh, no, then we have to break and fix this code. Let me go break this. Oh, I need what resources do I need to fix this code? Let me go over here and do that. Oh, now it needs to run CI. I should actually create, maybe I'll create a game that's like a software engineer.