Lenny's Podcast: Product | Career | Growth
00:12:24 · Andrew Ambrosino, S1
[00:12:24] S0: Yeah. [00:12:24] S1: Rarely is it like, "This is it, they nailed it." And it's always like, "Oh, this is Claude Design, this is Codex Design." Why do you think AI and the top frontier models are just not good at design today? And do you think they'll get there? Do you think we'll get to a place of like, "Holy moly, we're done."
00:12:40 · Andrew Ambrosino
[00:12:40] S0: Yeah. I tend to think that there are some practical reasons why it's lagged and also some harder problems to crack. I'm not in our research org, I'm sure I'll get yelled at for saying us. I think design's a little bit harder to grade than software. And that creating a loop where you can train the model and what's good design and what's bad design is just a little bit more tedious and onerous than does the code compile, does it do what it's supposed to? Because the human aspect of taste is part of the feedback mechanism you need. I also think that the labs historically invest in making their models good at things that accelerate AI research. And that in the early era of coding models, it was very clear that the model being able to write correct code would accelerate research. In a way that you can't really make the same case for design. Not that getting good at design isn't important, it's that it's not directly in that flywheel. Those are practical reasons and those will go away. These models will get pretty good at design. There are some kind of murkier things that is going to be really tough. I have kind of a short list of them. One is there is an aspect of culture to what is considered good design. In that you remember it was probably what last year where every new website that came out was just a copy of Linear's website. Linear's website, great design, great taste. If a model did that, I'd be like, "Wow, this is incredible leaps here." If I have a model that outputs Linear's website every time, that's not the challenge here. There's an amount of novelty that is more important in design than it actually is in software engineering. Software engineering, you must want it to over-index unknown patterns. Whereas design, it's like, "No, there's an element of randomness here and novelty." To me, I spent a lot of time writing code or supervising code on the early Codex app. And even as the models get good at design, there's sort of an abstraction layer that is an interplay between the software design and the code that's being written. This thing over here in this corner should share X, Y, and Z in the code base with this thing down here. And that's a little bit different than saying the model needs to be a better designer. Especially that is visual design, but it is significantly deeper.
00:15:24 · Andrew Ambrosino, S1
It's about the abstractions in that like, "Oh, if tomorrow our company did a rebrand, the shallow version of this is that we have to update 263 components one by one." The deep version is the semantics between these two things that look different. They're both in list that have this style, that convey this interaction pattern to the user. And I think that is still feeling a little bit out of reach with the current technology, that abstraction layer. So I think as we've gone through this process of, we started the Codex app in November. And we weren't using it full-time, now we use it for everything. That's been a journey. But now it's like the things that we actually do while using it are different things. So what was the question? [00:16:17] S1: I know, that was an amazing answer. Speaking of design and being creative, the Codex app when it came out, it's like such a new thing that nobody had seen before. It's not a terminal thing, it's not an ID thing. It's like this chat thing that codes and you could see code. To your point, it feels like it'd be hard for AI to be like, "Here's a whole new paradigm for how to code." And that feels like where human brains continue to be valuable for now is creativity almost in coming up with something new versus patterns of things that have been done before. [00:16:47] S0: Yeah, I mean, I totally hear you. Let's give it up for the human brain.
00:16:47 · Andrew Ambrosino, S1
[00:16:47] S0: Yeah, I mean, I totally hear you. Let's give it up for the human brain. [00:16:50] S1: For now. As we were getting ready for this, you said that you were listening to the episode with Jenny who does the head of design for Claude Code and Cowork and such. And she had this whole kind of thesis that the design process is dead. There's no time for design. Things are moving too fast. Just build now and design is kind of steering things as things move along. You're implying you have kind of a different perspective on the design process. [00:17:13] S0: We probably agree on a lot of this, Jenny and I. I wasn't a fan of the design. The design process proper, I agree with her take that it is dead. I genuinely was not a fan of this process before AI. [00:17:27] S1: Can you describe the process real quick just from people think about the design? What does that mean?
00:17:31 · Andrew Ambrosino
[00:17:31] S0: Yeah. So I mean, when I ran a startup a number of years ago, we would do design hiring. And there was this sort of snarky article that came out about the case study factory. And it was like mid-SERP era stuff and it was that designers were being taught about this process and valuing that above all else, above all outcomes even. And if something went through this process that two things were true. One, it would be good and the process would guarantee quality and guarantee impact. And also that if something, the thing was good if it went through that process, even if you don't like it and nobody uses it. And it's like the process of user research and the divergence and the convergence, it's the right framework. It was always a little academic. But I think this is really exposing some areas where it falls down, especially because of the speed of implementation. And once again, that process is sort of predicated on the assumption that implementation is expensive and that you can really only afford to build once. And so you need to fully, exhaustively go through the problem space and the solution space before implementing. And then we saw with Figma and Origami and all of these tools that you can fast-forward some of the insights by pulling interactive prototypes earlier into the process. That you can simulate production. And there ended up being sort of a meme about executives just being like, "Well, can we just do a prototype and then expect it to work?" But this thing was real that this became part of the design process proper. We pulled prototyping into that. The problem now is that you can pull all of the implementation into that and there's a mismatch between, I think a lot of assumptions. Again, you see this fully polished prototype that looks like it's ready to go out the door. And enough people at a company see that and they're like, "Can we release this now?" But the appropriate, we're actually in that early design process stage and nobody's just saying that. This is where we are with a bunch of multiplayer exploration. 90 people will have this idea. It'll look really polished, but it's like, "No, this is actually..." That's the design process now. Tying the design process to mediums, media, that's the scary part. It's that designers have more tools now to do this process with.
00:20:05 · Andrew Ambrosino, S1
You can put stuff into the current product and you can A/B test it or just use that as a prototype. Many companies right now have this idea of a baby version of the product. Like baby Cursor, you've seen this on Twitter. We have baby Codex, a dramatically simplified code base that approximates all of the interactions of the production app. And therefore is a lot quicker to vibe code over. Because you can be like, "Well, what if the sidebar worked like this? Or what if a pane came in and had a group chat here? What if X, Y, Z?" That's a huge tool that's part of the design process. So to say that the design process is dead, I feel like it's both true and false. It's that if you are tied to the tools and the exact day-to-day specifics of the process, then yeah, it's dead. You're not going to have a good time. But to throw the process out completely or throw the overlay of the process, the like, "Hey, we are at this point in the process." That is still more important than ever. [00:21:11] S1: It's really interesting because you have a background in every function. If people look at your LinkedIn, it's like engineer, designer, product manager, founder. Now you oversee the desktop app. And I think design is not under your purview, is that right? Is there a separate design team or are they under your? [00:21:25] S0: Depends on the week. [00:21:26] S1: Okay. [00:21:27] S0: We worked very closely together. We believe in, while sitting together, being embedded. Reporting line, I don't know. [00:21:35] S1: They shift weekly. What does the design process look like on the Codex app?