Andrew Ambrosino: commitment

Transcript context

…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. 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. 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? 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.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.