OpenAI Codex lead on the new shape of product work | Andrew Ambrosino

90% of people at Opening Eye use Codex.

Not 90% of engineers. That's 90% of the entire company.

Yeah. This tweet the other day where you said that you intend to make Codex the best desktop app that has ever existed.

Yeah. The quality bar for Codex had to be so high that there was never like a hesitation that you have opening this app to do the next thing that this was your natural choice. Just like people have kind of come to open a browser tab, right?

That's true. I know there's numbers constantly coming out about the records you guys are setting for usage.

I don't know. Like we'll see. A lot of people seem to like the app.

Why do you think AI and the top frontier models are just not good at design?

I think design's a little bit harder to grade because the human aspect of taste is like part of the feedback mechanism you need. That is still feeling a little

you need. That is still feeling a little bit out of reach with the current technology.

What does the shape of product team look like now versus a couple years ago?

Everybody at OpenAI is very agentic, has great ideas, and so everybody's building everything. And it's not that people are

everything. And it's not that people are doing fundamentally different roles or focusing on different things. It's that

it's backwards. The implementation is actually not the expensive part anymore.

It's dare I say taste.

You feel like there's this collapse coming where everyone's everything and that's just the future or do you think we're going to continue to be mostly divided up?

There are some things that I'm afraid of. I've heard a lot of companies be

of. I've heard a lot of companies be like we're getting rid of the product role and everybody's just going to be a builder and then what happens is today my guest is Andrew Ambercino,

product and engineering lead for the Codex app at OpenAI. Codeex is quickly becoming people's go-to app for building products and also for non-product work like organizing files in your computer,

drafting documents, doing data analysis, reading your emails, and a lot more. If

you stick around for the end of this episode, we actually have a little clip from after we stopped recording where the producer in the room started talking about how he uses Codeex in his editing

work. Since this January, Codeex usage

work. Since this January, Codeex usage has grown 6x. They currently have over 5 million weekly active users. I suspect

this number is quickly going to be out of date. Internally at OpenAI, nearly

of date. Internally at OpenAI, nearly 100% of their employees use Codeex weekly. And that is not just the

weekly. And that is not just the engineers. Andrew is a designer turned

engineers. Andrew is a designer turned engineer turned product manager who is building the app that more and more of the world is using to build their own products. Before we get into it, don't

products. Before we get into it, don't forget to check out lenny's productpass.com for a year free of the hottest and most well-crafted AI products in the world available exclusively to Lenny's

newsletter subscribers. With that, I

newsletter subscribers. With that, I bring you Andrew Ambersino.

Andrew, thank you so much for being here. Welcome to the podcast.

here. Welcome to the podcast.

Thank you for having this is a rare in-person podcast. I rarely do this kind

in-person podcast. I rarely do this kind of thing. We'll see how it goes.

of thing. We'll see how it goes.

We'll see.

We'll see people like these more. When

we were preparing for this chat, I asked you what's the biggest thing you want people to get out of this conversation and you said that it was how AI is changing the shape of product work.

You're working at maybe the most bleeding edge AI pill software team there is. So you have a really

there is. So you have a really interesting lens into where things are heading, where other teams are going to be and in a year or two or or more. What

does the shape of product team look like now versus a couple years ago? One of

the the hardest things to do right now as a leader building these products is just sort of the inversion of the process in my mind which I think a lot of people have

talked about which is that anybody can build anything right like I I generally believe now that starting from scratch if you talk to these models ours anybody

else's really um you can stand up whatever feature you want right And that's not necessarily a hard part of software, but that's like

that's really cool. And I think that has created an environment where people are making all of this, right?

You give people unlimited tokens.

Everybody at OpenI, OpenAI is is very agentic, has great ideas, and so everybody's building everything. Whereas

I think, you know, you look back at product process that we've all run for a long time, and it's been a little bit opposite, right? It's been kind of

opposite, right? It's been kind of research ideation maybe there was some prototyping but it was you know even when we got past waterfall it was still

kind of flavored of like the implementation is expensive and so you what you want to do is you want to derisk all implementation up front through documents through research

through prototypes because prototypes and designs are cheaper was kind of the the assumption there uh and that's changed that's like totally changed and

right now I'm sure there are 90 different explorations for there's this feature that we desperately need to do that I'm sure there are 90 different uncoordinated teams like implementing

and trying, right?

Um, so I guess the short answer is like it's it's backwards and it's not that people are doing fundamentally different roles or focusing on different things or that even skill sets have vanished or that

roles have just disappeared. It's that

it's backwards, right? The

implementation is actually not the expensive part anymore. It's dare I say taste. Um but it's the curation process.

taste. Um but it's the curation process.

It's like of those 90 attempts like what's good about these? What should we fold into other aspects of this? Right?

How should we frame this? Should it be part of this other feature? Right? How

many segments should be in the toggle?

Um you know all of those things. This

episode is brought to you by our season's presenting sponsor, WorkOS.

What do OpenAI, Anthropic, Cursor, Versell Replet Sierra Clay and hundreds of other winning companies all have in common? They are all powered by work OS. If you're building a product

work OS. If you're building a product for the enterprise, you've felt the pain of integrating single signon, skim, arback, audit, logs, and other features required by large companies. Work OS

turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SAS.

Literally every startup that I'm an investor in that starts to expand up market ends up working with Work OS. And

that's because they are the best.

Whether you are seedstage startup trying to land your first enterprise customer or a unicorn expanding globally, work OS is the fastest path to becoming enterprise ready and unblocking growth.

It's essentially Stripe for enterprise features. Visit works.com to get started

features. Visit works.com to get started or just hit up their Slack where they have actual engineers waiting to answer your questions. Work OS allows you to

your questions. Work OS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to works.com to

developer experience. Go to works.com to make your app enterprise ready today.

Taste such a such a buzz word. I want to come back to that. Uh this idea of 90 prototypes. So interesting. So just to

prototypes. So interesting. So just to make sure I understand that. So there's

an idea out there floating around OpenAI. What people used to do is write

OpenAI. What people used to do is write docs. Yeah. Here's what we're going to

docs. Yeah. Here's what we're going to build. Here's the feature. Here's the

build. Here's the feature. Here's the

strategies. P. Today what you're describing which makes all the sense is people just create a prototype and what you're saying is people across the company have kind of similar ideas and now instead of a dock they create their

little prototype and that leads to kind of 90 different things people can look at and maybe pick here's a direction we want to go down. Is that idea?

There's a lot of this um and you know it's not just happening here like you've seen many product leaders say PRDS are dead prototypes are in and I actually don't believe this at all. I think that

one of the interesting things that is happening right now is that because implementation has gotten so cheap across every medium. It's very tempting

to jump straight to a prototype, especially if you're not an engineer, right? Especially if you've never been

right? Especially if you've never been able to write code or never been interested or never had the time. It's

really tempting to say like PRDs are dead. Let me just show you what I mean.

dead. Let me just show you what I mean.

Right? What I've also noticed though is that for engineers, it's really tempting to write a lot of documents, a lot of documents that are not worth reading.

Um, this is no shade on people writing documents. It's that if implementation

documents. It's that if implementation is abundant, then it's really important to pick the right format for the point you're trying

to make. If that point is product

to make. If that point is product clarity around a vague area, then it might actually be a document. If what

you're trying to do is get something in people's hands to try out and to stress test an interaction pattern, it's a prototype. But I think like this is kind

prototype. But I think like this is kind of the funny thing now, which is that like it's really important to pick the medium.

There's this uh term that a podcast guest shared that I think about when you say this uh which is it's called the primal mark. when a designer or a

primal mark. when a designer or a painter or an artist just creates the first mark on on a painting or a piece of art, that mark is what you start to respond to. And so everything kind of trickles

to. And so everything kind of trickles down from that first mark you make. And

what I'm hearing you saying is sometimes the prototype is the wrong first thing to do because then you're just responding to this prototype versus a different idea versus a bigger idea. So

I love hearing this. So like everyone's just like, "Okay, forget it. No more

writing, no more docs, no more purviews." You're saying they're

purviews." You're saying they're actually still useful for specific use cases.

Yeah. I I I think too there's this part of the previous world was that the medium implied it had baked in a lot of

a lot of signal around where in the process something was right. So if

you're seeing something that feels like the app in production that means that it's late in the process that assumptions have been derisked that you know design is looked at this that this

is a good business goal right and now those things are sort of divorced right and the reason it was that way is because it was hard to get resources to build the thing until it was properly derised and now that's like just out the

window right and so I think it's really important to start saying look we can have prototypes we can have documents Is it are we clear around what this is doing? Right? Because to your point, you

doing? Right? Because to your point, you do not want to over anchor on this thing that was meant to be an exploration, but now it looks so production ready that like, oh, visually it's ready for prod,

but it's not actually the right model of of where the research is going or what users are asking for or what's right for the business, right? Not to overdo the taste thing, but it's like it's once

again it's like the taste to know like what to work on, how to present that information, like how to achieve the goals, what medium to use is emerging as

like the most important thing to do. And

that's it. That's that's in every field.

What is taste when you talk about good taste? Is it is it what you describe

taste? Is it is it what you describe deciding here's the thing we're going to invest in? Is it also once you have a

invest in? Is it also once you have a thing, is this right? Is this the thing to ship? talk about when you think about

to ship? talk about when you think about what is good taste, good judgment, what is what does that concretely? Cuz people

hear this word, they're like, "Oh, I have good taste. I know it. What does it look like in practice?"

Yeah. Um, it's funny. There was a tweet I'm too online. There there was a tweet, I think it was yesterday from the head of product at linear. I might be getting that wrong. Sorry to anybody who said

that wrong. Sorry to anybody who said people overemphasize the aesthetic part of what taste means. and they used um Paul Graham's Craig, but they used him

as an example saying Paul Graham clearly has great taste and wears cargo shorts, right? Like, you know, we gota we got to

right? Like, you know, we gota we got to like tease out what taste means a little bit. Um and and there's a lot of nuance

bit. Um and and there's a lot of nuance here. I think it's all of the above to

here. I think it's all of the above to to what you mentioned. It's it's the like there is an aesthetic part to it.

Um but there's also a a systems thinking part of it. Like how does this fit in the system? There's a where are we going

the system? There's a where are we going and how like what what theme is this part of? There's how to present this. A

part of? There's how to present this. A

lot of it is wider context and you know obviously there are parts of taste that are like okay this interaction animation doesn't fit in the semantic meaning it's supposed to, right? Like it's too snappy

for what it's actually trying to convey.

And that's incredibly important and I focus probably too much on that. Um, but

there's there's like the the like what should what should this be like if we can build anything like what's what's the what's the goal here and how do we how do we get there that I think is like

actually the real taste question here.

When I when I hear things like this I always wonder where will human brains continue to be valuable as AI becomes stronger and better and doing and doing more of of the work and it feels like taste is is a part of it. Something I

think about along these lines is just AI is still very bad at actual design.

Like the output of AI is not great.

Yeah.

Rarely is it like this is it, they nailed it. Y and it's always like, oh,

nailed it. Y and it's always like, oh, this is cloud design. This is codeex design. Why do you think AI and the top

design. Why do you think AI and the top frontier models are just not good at design today? Yeah.

design today? Yeah.

And do you think they'll get there? Do

you think we'll get to a place of like, holy moly, we're done?

Yeah. I tend to 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 or like I'm sure I'll get yelled at for saying this. I

think design's a little bit harder to grade um than than software and that you know creating a loop where you can train the model on like what's good design and what's bad design is just a little bit more tedious and ownorous than you know

does the code compile does it you know do do what it's supposed to right it because the human aspect of taste is is like part of the feedback mechanism you

need I also think that uh the labs historically invest in making their models good at things that accelerates AI research and that in the era the

early era of coding models is very clear that the model being able to write correct code would accelerate research right in a way that

you can't really make the same case for design. Not that getting good at design

design. Not that getting good at design isn't important, it's that it's not directly in that that flywheel, right?

Um those are practical reasons and I you know those will go away like these models will get pretty good at design.

There are some kind of murkier things that is is going to be really tough. Um

like I have kind of a short list of them. One is there is an aspect of of

them. One is there is an aspect of of culture to what is considered good design in that you remember it was probably what last year where like every

new website that came out was just a copy of linear's website right like linear's website great design great taste like if a model did that I'd be like wow this is incredible leaps here

right if I have a model that outputs linear's website every time that's not the challenge here right um there's 's an amount of like novelty that is more important in design than it actually is

in software engineering. Like software

engineering, you almost you almost want it to overindex unknown patterns, right?

Whereas design it's like no, there's an element of randomness here and and novelty, right? There's also the you

novelty, right? There's also the you know to me like I I spent a lot of time writing code or you know supervising code on the early codeex app and even as

the models get good at design there's sort of a an abstraction layer that is an interplay between the software design and the code it's being written. Like

this thing over here in this corner should share x y and z in the codebase with this thing down here. Right? And

that's a little bit different than saying the model needs to be a better designer especially on the like you know that's not visual 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 you know update 263 components one by one. The deep version is like the

semantics between these two things that look different like they're both in list that have the like this style that convey this interaction pattern to the user and I think like that is still

feeling a little bit out out of reach with the current technology right that abstraction layer. So I think you know

abstraction layer. So I think you know as as we've gone through this process right of you know we started the Codex app in uh 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?

things. So what was the question?

I know that was that was an amazing answer. Uh, speaking of design and being

answer. Uh, speaking of design and being creative, the Codex app when it came out, it's like such a new thing. Yeah.

That nobody has had seen before. It's

like not a terminal thing. It's not an ID thing. It's like this chat thing that

ID thing. It's like this chat thing that codes and you could see code.

Yeah.

To your point, it feels like it'd be a 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 like creativity almost and coming up with something new versus like a patterns of things that have been done before.

Yeah. I mean, I totally agree. Let's

give it up for the human brain for now. As we were getting ready for

for now. As we were getting ready for this, you said that you were listening to the episode of Jenny, who is the head of design for clock code and co-work 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.

Uh, 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.

We probably agree on on a lot of this, Jenny and I. I wasn't a fan of the design like the design process proper. I

agree with with her take that it is it is dead and I genuinely was not a fan of this process before AI like I I can you describe the process real quick just from people think about the design.

So I mean I when I read a startup a number of years ago, we we would you know do design hiring and there was this sort of snarky article that came out about like the case study factory and it

was it was like midsurp era stuff, right? And it was that designers are

right? And it was that designers are being taught about this process and valuing that above all else, above all outcomes even, right? 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. It's like

the process was you know of of user research and the divergence and the convergence. It's the right framework.

convergence. It's the right framework.

It was always a little academic, but I think I think this is really exposing some areas where it falls down, especially because of the speed of implementation.

And like once again, like 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 like

once. And so you need to fully like exhaustively go through the problem space and the solution space before implementing, right? And that you and

implementing, right? And that you and and then like kind of we saw with like you know 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, right? that you can, you know,

process, right? that you can, you know, simulate production and like, you know, there ended up being sort of a meme about executives just being like, well, can we just do a prototype and then like expect it to, you know, work. But, but

this thing was real, right? That this

became part of the the design process proper, right? We pulled prototyping

proper, right? We pulled prototyping into that. The problem now is that you

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 like 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 can we release this now but the appropriate like we're actually in that early design process stage and nobody's just saying that right like this is this is where we are

with like a bunch of like multiplayer exploration right you know 90 people will have this idea it'll look really polished but it's like no this is actually that that's the design process

now, right? Tying the design process to

now, right? Tying the design process to mediums, media, uh like that's the scary part. It's that designers have more

part. It's that designers have more tools now to do this process with, right? You can put stuff into the

right? You can put stuff into the current product and you can AB test it or just, you know, use that as a prototype. Um many companies right now

prototype. Um many companies right now have this idea of like a baby version of the product like baby cursor. You've

seen this on Twitter like we have baby codecs, right? a dramatically simplified

codecs, right? a dramatically simplified codebase that approximates all of the interactions of the production app and therefore is a lot quicker to vibe code over, right? Because you can be like,

over, right? Because you can be like, well, what if the sidebar worked like this or what if a pain came in and had like a group chat here? What if XYZ, right? That's like a huge tool that's

right? That's like a huge tool that's part of the design process. So to say the design process is dead, I feel like it's both true and false, right? It's

that if you are if you are tied to the tools in the ex like the spec the exact like day-to-day specifics of the process then yeah it's dead like you're not going to have a good time but to throw

the process out completely or throw like the overlay of the process the like hey we're at this point in the process like that is still more important than ever it's 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 uh now You oversee the desktop app and I think design is not under your perfume. Is that right? Is there like a

perfume. Is that right? Is there like a separate design team or are they under your depends on the week?

Okay, good.

We work very closely together. Like we

believe in all sitting together being embedded like I reporting lane. I don't

they sh the shift weekly. What does the design process look like on on the codeex?

Yeah, there's been a lot written about ro collapse, existential role collapse.

There are no roles anymore. We haven't

seen that. Um we've we have seen more role collapse in the codeex org um than I think other parts of the company and other parts of the economy. I think part

of this is that this was a technical product for engineers and so our designers speak engineer right our product managers speak technical

language and write code. Alexander has a master's degree in computer science, which is I do not have a master's degree in computer science. Like, so we've seen a lot of role collapse and and I think

that, you know, one of one of the ways that we describe how the groups work together is that there's significantly more overlap in the roles

than there used to be. And everybody's

sort of defined less by the fence and the boundaries of where design stops and engineering starts, but more the average of where they're working, right? So

like, you know, if you average up all of the things that somebody on our design team does, there's plenty of codew writing things. There's plenty of things

writing things. There's plenty of things that are product work, but on average, like their dots over here, right? If you

draw you draw it out on a diagram, and this sort of speaks to the process, too.

Um, especially because the entirety of the critics app has been informed by the dog fooding loop. There

is a desire among all of us to try to do as much as possible in the app even when it's not the best tool so that it can become the best tool. And so a lot of

design we all work on by using the app and say okay what's broken about this?

This is a whole thing we do which is that we we often don't improve our process so that we can make the product better to do it which is a deeply like uncomfortable place to be in but you

know week to week it's changing. I love

this point so much that uh like what are you? It's your role is the average of

you? It's your role is the average of what you spend your time on. If most of your work is PM work, then okay, you're a PM for now.

Yeah.

If it's engineering, you're an engineer for now.

I feel like was OpenAI the first company to uh call people member of technical staff.

No, I I believe that this this might have started with Xerox. First company I interned at, it was a company called Up There did the same thing.

This has been around, but it's it's it's much more common now. you know, it is kind of a tradition in research focused companies, right? Okay, got it. So, it emerged from

right? Okay, got it. So, it emerged from research, but I feel like it's such a I don't know sign of where things might be headed. This idea of uh we're just going

headed. This idea of uh we're just going to call everyone me member of technical staff. Your function isn't set. You're

staff. Your function isn't set. You're

not like in this bucket of the PM or theorg of the design or do you feel like that's where we all head long term? Do

you feel like functions will continue to exist? Like there's still the PM skill

exist? Like there's still the PM skill set and the NG skill set and the design skill set.

Yeah.

And people are I'm a designer or do you think this is like like people call it builder? Do you feel like there's this

builder? Do you feel like there's this collapse coming where everyone's everything and that's just the future or do you think we're going to continue to be mostly divided up in? There are there are some things that I'm afraid of. And

I think that, you know, some some companies like to be very extreme about getting onto the bandwagon of whatever people

say is going to happen. And I think part of the danger in eliminating the concept of roles is that it can dangerously

eliminate the idea that things are specialties with knowable best practices, right? I I've heard a lot of

practices, right? I I've heard a lot of companies be like, we're getting rid of the product role, which I think is, by the way, a terrible idea. Um, and

everybody's just going to be like a builder. And then what happens is they

builder. And then what happens is they don't like this whole discipline of product that's been built up and has like real best practices, real things that have been tried and failed and like

real processes like that just gets abandoned because people are like, "Oh, I wrote some code, right?" Like that's not a great place to be in. I think that

the boundary of like so and so like this isn't your lane. I I welcome that part going away, but there's a balance here

where it's like not everyone can work on everything for one, both in terms of breath and depth, right? Like this is why managers are not going to go away.

Um, not everybody can work on everything and also like every discipline has a skill component to it, which I think a lot of engineers are guilty of not

recognizing that like well engineering is a skill to it. it's writing code and like other roles are just people vibing.

It's like no that's not how it works, right? Um like yes, you can use Excel

right? Um like yes, you can use Excel you but you cannot work on the finance team, right? That is like that kind of

team, right? That is like that kind of stuff right?

Yeah. I think there's also just like do you want to be doing this work? Do I

want to be I think more of it that actually now is like it's easier to switch roles. It's

easier to learn the best practices. It's

easier to not tie your effectiveness in a role with the ability to use the exact tool, right? It's more of like can you

tool, right? It's more of like can you get yourself into this mindset, learn which things work and which don't and

then like focus on it, right? Like I I spent so long feeling like I should not be a software engineer because I didn't

care about like assembly language or memorizing TypeScript syntax, you know?

And it's like there have always been parts of these roles that are that sort of gatekeeping that are like, well, no, this like being good at this role is being good at this tool. And I think

that's what's kind of starting to erode.

I just don't I I think people take this they hyperbolize all of this.

What does your team look like on on on the Codeex team? How many engineers, designers, PMS? What's kind of like the

designers, PMS? What's kind of like the makeup of the team right now?

Every time people ask me like how many people are on the Codex team, do you remember my answer to this? Yeah, I I'm like it's somewhere between 10 and a few thousand. I mean, it's like a fake

thousand. I mean, it's like a fake answer, but it's it's real in that we do see this as the culmination of what everybody works on here. Like

everything that goes into model research, everything that goes into how you know models are good at kua and browser use, everything about how you know model personality, all of the

product work around you know front-end infrastructure, all of the user like all of it is this product. At the same time we are not accepting PRs daily from thousands and thousands of people on

whatever they want. Um so we got a team uh double digits of engineers probably half that on the design side. um you

know few product people although you know product tier is kind of more of his own defense play and I think one thing that is very common around among

everybody on the codics side or or on the desktop side is agency and taste right a lot of former founders or people who were at larger companies doing

founder shaped things um a lot of people with with immense taste at openi we let teams get very large so we haven't that hey there's no management but like the

teams are quite large right it's mostly IC's um and I think that's good you use this term zone defense for product work and I think that's really interesting it kind of maps to the design kind of shift also just like

you're there to kind of manage and coordinate talk a little bit more about what that looks like what does zone defense look like for a product person yeah and I I have had a lot of conversations with with Alexander about this this analogy which is that like if

two product people are working too closely that's often not a good signal And that like you kind of want like as a

product or you sort of want to do this like forced directed activity where you're like where are the gaps especially in this new world where curation and like you know steering and alignment is a lot of things where

you're like there's a ton of chaos happening on people throwing ideas all over the place right the whole like top down you know year-long planning thing not going to work and so now it's like

we need the taste makers to guide things from incept ception to what the product should be. And that means you basically

should be. And that means you basically want company coverage. And so you spread out and you say, "All right, who's like who's best at what? Let's create some space between us so that we got full coverage, right?" And that's kind of how

coverage, right?" And that's kind of how it goes. And then you fill in the gaps

it goes. And then you fill in the gaps and you're like, "Look, like we want to hire engineers who are product minded.

Like we don't we don't want it to be that, you know, we've got a bunch of people writing a bunch of code that needs like full team reviewing it for like product coherence, right? Like we

want everyone to have these skills, but I think like what people go deep on has to change, right?

This is definitely a thread I've been noticing over and over with talking to folks like you is the the most valuable person right now, one of the most valuable is someone that could take an

idea from idea to done with the taste to know this is great. Just like shephering throughout this obsession with making it awesome like this kind of high agency, high taste person. Exactly. as you

described, is that is that kind of the way you think about here's who we're hiring, here's who's going to do really well in this new world?

Yeah, I think that that's that's the core piece right now. And it it also speaks to how I sort of see IC versus management, which is that it's not that

management is going away. It's not that everyone's an IC, but like everyone's kind of both now, right? If you're an IC, you're not typing code out character

by character, right? like you are managing something you're managing agents you're managing you know like you're managing work that is happening right that comes together to do a

certain thing if you're a manager of teams you're doing the same thing just at a different like different granularity right I generally look for

like obviously command over the discipline but then the taste to say like hey you're going to have unlimited tokens and I don't like we can't just be doing slop like you need to be able to

determine what's signal, what's noise, like in a world of just infinite content.

Mentioned planning uh at the pace things are moving. It's become very hard to

are moving. It's become very hard to plan road maps. Yeah,

I imagine especially in our world.

Uh people are very frustrated with me all the time on this. Yes.

Because things are just constantly shipping, things are changing, right?

How do you plan on on on your team?

What's kind of like how far ahead are you thinking and what does a plan look like? Is it like a spreadsheet? Is it an

like? Is it like a spreadsheet? Is it an MD file? What what's kind of the output

MD file? What what's kind of the output of a plan? Yeah, I I don't think we do anything revolutionary on that. We're

not clever about planning. I think like the basic gist is the shorter term something is, the more detail it needs.

And then it's not that we don't plan for 9 months out, it's that that just has to stay very hazy because any amount of precision that you add to a 9-month plan right now is false precision. And like

you're just going to waste time. Like

you can say stuff, right? But like

nothing that we planned. I think

research is different. So I'm not speaking for research here but like on the applied side when we do product like anything that you could have planned in November may have been true for December

but like isn't what happened right so it's hard like it is really hard to do planning we generally need to know like what do we think models are able to do

on what timeline and my last company I kind of saw this shift where we were starting to use the models to drive

features and the product process fell down. It basically had to be like, let's

down. It basically had to be like, let's list out all of the things that we think we are interested in doing for the next year or two. Let's prototype all of

them, decide which things are ready now, and then just let the others sit and bake, and then every time there's like a new leap in models, let's try that thing again with it swapped out. because like

the whole premise of whether features were good or not were based on whether they were smart enough, not the shape of them.

So this is a great story about the Codex app. I like I am very confident that the

app. I like I am very confident that the Codex app that we released in February, if that had been ready in November, it would have absolutely failed in the

market and that that the only difference was the models between November and February, right? And I I think like

February, right? And I I think like there's a lot to that that this product with the exact same shape I think would have like it's it's outcomes were

totally different depending on just a few months of timing. This episode is brought to you by Mercury. Radically

different banking loved by over 300,000 entrepreneurs and now with command. I've

been a customer of Mercury's for over 6 years. I have never once thought about

years. I have never once thought about leaving. Mercury is basically what

leaving. Mercury is basically what happens when banking is built by product people, not by bankers. They make it so easy, dare I say fun, to send invoices,

move money around, set up virtual cards for folks on my team. Does your bank have an API, a terminal native CLI or an AI ready MCP server? I don't think so.

And just recently, they launched Command, a conversational interface built directly into Mercury, which acts as your financial operator. I've been

using Command to transfer money around to figure out what categories I've been spending the most money in, analyze my cash flows, and just today I used it to find out how much I've made from a

specific sponsor over the past year. I

just ask, "How much have I made from X over the past year?" 10 seconds later, I have an answer. It is so freaking cool.

Visit mercury.com to learn more and apply online in minutes. Mercury is a fintech company, not an FDICsured bank.

banking services provided through Choice Financial Group and column NA members FDIC.

This is definitely a thread on this podcast is build things that are not yet working then will work when the model gets better. And there's this kind of

gets better. And there's this kind of other thread of ambition. Be more

ambitious with the things you take on.

So is this just like a way you approach things just like let's just build a bunch of things that may not work yet.

We'll just have them around and wait for a model to catch up. Is that kind of the approach?

Yeah, I think we have a lot of that. I

think sometimes the challenge is like you have to be very clear again about what stage of the design process that's in. People still have this muscle memory

in. People still have this muscle memory of like, oh, I wrote the code for this thing, therefore we should put it out there. It's like, no, no, no, that means

there. It's like, no, no, no, that means you have an artifact now that we can test against for into future models, right? Um, this happened with the inapp

right? Um, this happened with the inapp browser in the app that we have, right?

Like we had a a kind of a working version. I mean, go back to Atlas, we

version. I mean, go back to Atlas, we had agent working inside of Atlas and, you know, that was pretty cool. We had

operator before that in chatbt, right?

That didn't work out. Very cool idea.

Like there's some thread that you can draw between operator atlas codeex chatbt that's like fundamentally the same feature, but the re-releasing of it

with different intelligence totally changes the outcome here. And so I push people not to be stubborn about like no this isn't working so it's a bad feature. Like no, it might not be ready

feature. Like no, it might not be ready yet. Um there's also this aspect of

yet. Um there's also this aspect of especially in research there's always a desire to be the most ambitious and to say okay but at the limit the model can

just do this and it just doesn't work on the product side like if you if you go back to the original Codex release basically what it was is it said it was codex web and it wasn't good for

interacting with it was like you give the model a task and it's going to go off do the task come back to you with finished like doesn't sound that radical. The problem is like it didn't

radical. The problem is like it didn't do the task that well. Like it wrote code. It was it was it was good but it

code. It was it was it was good but it was like that form factor was too early and then the cloud code comes out totally local like not hooked up to the cloud. Um doesn't pretend to be as it's

cloud. Um doesn't pretend to be as it's not as agipel right it's like going to ask you questions it's going to sit there you can't just delegate your life to it. That worked way better right

to it. That worked way better right because that's the point that the models were at there right? So we were like we were too agi pilled for the moment. And

I think like I I think about that lesson a lot on this stuff. It used to be that you know Bailey and market told you all these things about the shape of the product about the communication of the

product and now it's like no you might need to release this thing six different times before it works and that might like the shape might not change at all.

There's like it's so interesting to hear about all the variables you have to think about building product. Now

there's the timeline for the models and the research and how smart it gets.

there's like people's ability to even understand this is how you could build software in the cloud and this is the future like get people prepared for this new future and then just uh what you can build as a team and I love that codeex

example cuz comes back to this idea of ambition and I want to hear if there's anything there for you of just this threat of just be more ambitious because these models can do so much more than you even imagine and sometimes it's too ambitious for the market and they're not

ready for it but you think about that at all just like pushing your team to be more ambitious because it's so much easier to just do things that may be felt crazy hard in a fast.

Yeah, this is a core challenge. Once

once there's a product that exists or a feature that exists, it's really easy for people to find paper cuts and optimize and they should and people on Twitter like to remind us of this and I thank them for that. Like people should be

focused on the features that exist and making them more reliable and better.

But this, you know, this is why we also have a culture of bottoms up exploration here because sometimes in the same way the Codex app came and disrupted Chachup T in some way, right? This thing will

get disrupted by a future effort and that's that's part of the design is that like you can't always as one team be good at both the disruptive piece and

the like maintaining a product and its quality piece. Some point to design a

quality piece. Some point to design a process that allows for both. kind of

zooming out a little bit. If you think about the progression that we've been on of uh AI impacting how we build product, it's like insane how far we've come from, as you said, we used to write all

our code by hand, like artisally created human code to AI writing 100% of our code to you actually put it this way that now like coding is steering the AI

and like when you think about what percentage of my code is written by AI, it's almost like how many times did I have to steer it in the right direction is the AU version of coding. And now

that there's like agents and loops and all these things, what's kind of the latest frontier from what you've seen of how people are building is is it loops?

Is there something else of just like the most AI AI forward teams? Here's how

they operate now that people may not be aware of.

Yeah, I mean loops are so last week, man. I mean, we we talked about this.

man. I mean, we we talked about this.

Um, you know, one of the big questions is always, well, how much of the product is AI written? And

it's always hard to answer that question cuz if you're using the goalposts from last year, it's like, well, 100% of our product right now is AI written code. So

the question is more like, well, okay, fine. Is is the code written supervised

fine. Is is the code written supervised versus unsupervised, right? And that's

like a totally different thing. I

welcome the moving of goalposts because that means we're making product progress. There have been a lot of

progress. There have been a lot of explorations here around like autonomous autonomously developed software. um a

lot of like harness engineering stuff, a lot of different explorations. I'm like,

okay, well, what if you came in overnight and did garbage collection of the codebase to clean it up, right? One

thing that I think all models suffer with right now is just they they usually increase complexity. If research is

increase complexity. If research is listening at any company, please make the models better at deleting code. Um

but you know, that becomes a problem right now when you try to put development completely on autopilot. Um,

and it's both on the the human side and the codebase side. So like feature requests, right? You know, how do you

requests, right? You know, how do you teach a model which features to build, which ones to ignore, which ones to kind of like group together and reframe a little bit? How do you teach a model how

little bit? How do you teach a model how to build the right abstractions, right?

Like all of this is getting better. Um,

I don't think we're at a place yet where we're like, we're just got to set up a loop that's like improve the app, you know, and listens to Twitter and listens

to Slack and listens to email and like we're not there yet, but we are we are we're trying to make it happen.

Do you think we'll get there? Do you

think we'll get to a place where it's just like grow like win slashgoal make money like make me a billion dollars?

Win win the market.

I don't know, man. Like I

I am not in the business of saying never or always or whatever.

Yeah. How are you using AI in your work as product leader, engine leader?

What are some ways that you use it that maybe people may not be aware they can use the app for?

Yeah, I I think I have the best job in in the world right now. Um, but one of the things that makes it very fun is that when we were developing the original codeex app, the goal for me

personally was to make it the thing that I wrote the code with, right? I was

like, I need to make this so good at development that I can build the code app with this. And the codeex app at that time was a development tool, right?

And we did that like super quick dog fooding loop because you got your personal dog fooding loop where you're like, oh, like I can't do this thing. I

should fix that. so that I can do the thing. Now I can do the thing. Now I can

thing. Now I can do the thing. Now I can do more things, right? Um you know we released that and then the next challenge was hey people are starting to do some different shaped things with this right and now I you know need to

grow this and so I need to hire a few people and help. So then like my role changed at the same time that the role of the app needed to change. So I'm like okay I need to do more product discovery here. I need to figure out the right

here. I need to figure out the right loops for seeing what everybody's working on and steering things that are off track. And so all of a sudden that's

off track. And so all of a sudden that's what I started using the Codex app for, right? I did still write code. Like I've

right? I did still write code. Like I've

I've tried to align my own usage of it with the problem that we're trying to solve, right? And now I'm like, I need

solve, right? And now I'm like, I need to build a spreadsheet that models this out. I need to kind of do a, you know,

out. I need to kind of do a, you know, internal deep research on all of the efforts that have gone into this area of research for the next version of this.

There's a release or a series of releases in Mayish that introduced the inapp browser computer use and artifact creation to the Codex app. That was I

think our Codex's for almost everyone release and everybody knows the term vibe coding. I think that was like our

vibe coding. I think that was like our first five coordinated release where like I had a a you know notion doc somewhere with everything that needed to happen and I was like automating like

going out to gather updates from pull requests from Slack channels and like updating the status tracker and like now this is pretty common place. Um but at the time I felt like I was at the

bleeding edge of like how to manage a product release. In short, like the way

product release. In short, like the way that I use the Codex app is basically like what what has my job grown into and how do I make this thing able to do

everything I need to do? Um, I will get up in the morning, I will see the daily brief that I have from like everything from the 3,000 Slack channels that I'm in, like which things need my attention.

I can kind of message back and be like, "All right, give me five questions and I'll answer them and I can, you know, do that."

that." How do you set that up? what's like the workflow to for somebody to set that up because that sounds amazing.

Again, I I think we're still in the like discovery phase on on a lot of this. And

and so right now it's like I'm making an automation that says or scheduled task that says like I go through my Slack channels. These are the things that I

channels. These are the things that I care about and think are most important, you know. So I'm still kind of defining

you know. So I'm still kind of defining that like these are things to watch out for different categories like here's some context and you know I'll I'll you know that'll get set up as a automated

task and then first few times it runs it might need some steering and luckily with this app you know I don't have to find out how to edit the instructions I can just be like hey next time this runs like can you please worry about this

instead or can you deemphasize this workstream or hey this thing happened and it didn't come up in a brief like can you make sure that stuff in the shape so I can kind coach it along the

way. It'll update the way that it it

way. It'll update the way that it it notifies me, stuff like that. Amazing. I

think in the future though, like this is this has been a core problem with the the chatbot shape, right? Is that I know how to set this up. I have time to set this up because for me it's product

discovery to set it up. But if you're not working at OpenAI, not developing this, like you don't want to have to figure out all this stuff. Like we we we need to like figure out that that shape of things.

Yeah. What I'm hearing is I don't think people realize that uh your app can act a lot like open claw.

Yeah.

You was was people were so excited about like you just talk to it, set up this thing, check on this thing for me every day and then tell me what's going on like like it's starting to become a part of all these all the products.

Uh which is amazing. So the way somebody would set this up is they just talk within the app and say I want to set up an automation to do this. Look at my Slack and these are the things I I want to do.

Yeah. Great.

Yeah. And the app will say you know Yeah. It'll set it up for you. If it

Yeah. It'll set it up for you. If it

doesn't have a Slack connector, it'll say, "Can I add the Slack connector?"

Yes or no? You can hit yes to that. Like

the least that we can do is make it so that if you don't know how to do something in the app, they can just ask it, right? Yeah.

it, right? Yeah.

I don't think that's enough, but I think that's the least we can do.

Yeah. A good example is I built this little app that filters spammy email forbox. So every email that comes in and

forbox. So every email that comes in and I built this in codeex. Uh every email that comes in, it looks at it and decides is this uns unsolicited kind of cold email stuff that I don't want to look at and labels it and puts it

somewhere else. And to set that up, one

somewhere else. And to set that up, one of the steps was you have to go into like the Google cloud console and set up all these pups subhub API things and triggers. I don't know if you've ever

triggers. I don't know if you've ever used that interface. It's like so annoying and slow, right? So I was like, wait, what if I ask you to do it? And I

was like, okay, cool. Do this for me.

And it just you describe computer use.

I've never actually seen this happen on my computer before. It just takes over my computer and starts going there.

It's like I don't care if you don't have a connector, man. I'll just start clicking.

Yeah. And it figures it out. It's crazy

just to like watch it doing its thing.

Designing the decision boundary between connectors. When to use the inapp

connectors. When to use the inapp browser versus your Chrome extension that's connected versus computer is interesting and all done through just like feeling it out. I saw a great

Twitter thread the other day where they describe all these three and what you use it for.

Yeah.

So, this person described it really well.

These personal workflows are really interesting because some of them really click like some of you know people are trying all sorts of stuff. Everybody's making these personal

stuff. Everybody's making these personal systems. You ask everybody here what they do and everything's going to be different and then like certain themes arise and we're like you know what that should be a first a first class experience on the app. like we should

take this thing that everybody seems to be setting up and just make that work.

And I think memory is sort of in the shape where we've had a lot of people and a lot of people at other companies too are like well I set up an obsidian base or a notion area and I tell it how

to basically build my mind palace and how to put it's like I don't know if everyone like you shouldn't have to do that like there should be a memory feature that does that for you right that's pretty generic. So that's you know that's one but then there are other

things like they're your process of your job and there's something that like yeah you should set that up but I think this is we're constantly waiting through like what's working for individual people like what should what should enter the

product versus stay like no that's just how you do your job right what should become a primitive what shouldn't um yeah this is the the taste and judgment you spoke of earlier you know citing

these things I want to talk about this browser use piece a little bit because I think people don't realize how powerful this is and what it could be used for.

Reminds me, I don't know if you watched uh when Dan Shipper was on the podcast, he had this from every he had this prediction that we're going to start using codeex to run our SAS apps inside.

Yeah.

So, instead of going in Chrome, I know he slacks me about this every day asking for stuff.

Do you feel like this is where things go where we're just working within the codeex app using notion and linear and Salesforce inside with your agent kind of helping you along or do you think

that's a kind of a different direction?

It's been Yeah, it's been really interesting because obviously we've had a few attempts at browser shaped activity, right? And operator and tragic

activity, right? And operator and tragic de agent mode and atlas and now we have the inapp browser inside of the desktop app. We also have the the ability to

app. We also have the the ability to install a Chrome extension where the app connects to Chrome. Like we've had a lot of shapes at this and I think we've we've learned a lot of different things.

There's there's a lot at play. There's a

lot of really boring things at play.

Like you know, we originally launched the app. It's an Electron app. The

the app. It's an Electron app. The

things that you can do with inapp browsers and there it's it's like kind of janky. So we had the the inapp

of janky. So we had the the inapp browser was for development. It was for testing your front end on development.

And we were like it's not really for anything else, guys. like it's it's a developer tool, right? And then we we switched over to our owl owl stack which had powered the Atlas browser and so now

you know multitab and we've got enterprise security so that you can actually log into all your websites if you're you know so uh we've been iterating on this. I think the tough thing has always been what should the

shape of this browser be like is this something that is only for the agent right that like you've got Chrome you open Chrome you you know do your thing in Chrome if you ask the desktop app it

opens up this browser that it can control really quickly doesn't have the latency of playright whatever but that you know or are we trying to say this app is for everything and like we want

you to use this as a browser and those have a lot of trade-offs it's not super you know welltraveled path, right? Like most browsers are

path, right? Like most browsers are browsers at the top level that got browser tabs. Um, this creates a lot of

browser tabs. Um, this creates a lot of really boring but tedious problems like keyboard shortcuts, right? Are we trying to do key mapping to VS Code or to Chrome or to our own thing or to linear

or like, you know, we want to have some sort of muscle memory that carries over but got all these things that have shape like subshapes of different products out on the market. What do we do? And this

just highlights how extra challenging this app is where you have to allow it to work for somebody that's never built anything from like the more basic user to like

power like Peter Open Claw trying to code with it.

I I'm not convinced I'm going to get Peter to use the app. I think he might be the last terminal terminal hold out.

Okay.

But I'm going to I'm going to keep trying.

Okay. Let me uh let me zoom out for a moment and talk about kind of the big picture of where you're taking all this.

What's the what's kind of the vision for for Codex? Where does this go? What's it

for Codex? Where does this go? What's it

going to look like? You know, I don't know, a year or two, 10 years.

We had Codeex as a CLI, right? And then

we decided to build this app. And, you

know, we were we were a little uncertain about the app and um but had a lot of conviction in what it could be as to start a developer tool, right? That

Yeah.

and it wasn't going to be an IDE. It was

going to be this right-sized surface where it was like sort of a chatbot, but it was more than that and you could see the code, but we weren't going to let you edit the code. There's a really interesting thing that happened at

OpenAI in January in February, and it was before we actually released the Codex app, which is that we'd started to dog food the Codex app. And

what we were finding like we were converging on some pretty clear internal PMF on engineering right and research workflows. They were thrilled. They were

workflows. They were thrilled. They were

loving it. We were like all right we just got to get the quality bar up before we release it to the world. We're

convinced that this will be a thing. But

then at the company we spun up a few other workflows to say hey like this Codex effort is onto something with these coding agents and we have people from marketing from comms from finance

from legal from basically every discipline who are using this codeex app even though it is actively hostile to these people right it is like trying to show them code it's trying to ask for

approval to run RG on the you know it's like it's doing all of these things that are actively not the right product surface for them. So why don't we take our other surfaces and add codecs to

them? Like let's add it to the chatd

them? Like let's add it to the chatd desktop app. Let's add it to the atlas

desktop app. Let's add it to the atlas browser, right? And let's essentially

browser, right? And let's essentially take the lessons of codeex and make it more general for a general knowledge work tool, right? And those efforts went for a little bit and the the most

annoying problem happened which is nobody would leave the Codex app for the apps that were allegedly for these other personas. And I think the lesson in all

personas. And I think the lesson in all of this was just that like the whole developer tool versus general knowledge work tool like there's a lot of nuance here that isn't just one or the other.

And I think we really we believe really strongly in this and that there are certainly in the same way that we talk about the average of your role is like what your role is now. This is true on

the product side too. People who are doing Excel work don't want to see git repository information. We know that.

repository information. We know that.

But we also know we can tell a lot from what they're doing about what kind of work they do and we can start simple grow the product complex as we feel is needed. Right? Doesn't mean we don't

needed. Right? Doesn't mean we don't have modes, right? You might want some modes for organizing your stuff and to sort of be like legible about the the ways that you enter the experience,

right? But we really believe strongly

right? But we really believe strongly that what we've built here is the right shape to take take on like really deep

vertically focused things, right? We

work deeply with our finance team with our team working on science team working on legal, right? And and we say like if we can build the right extensibility

primitives in the right general model, then you can do anything with this, right? And then our challenge is well

right? And then our challenge is well how do you you know how do you generalize it? But this is kind of going

generalize it? But this is kind of going back to like the best desktop app that we can build like what does that look like? Um and so you know was Codex the

like? Um and so you know was Codex the developer tool chatpt like where does this go? This is how we think about it.

this go? This is how we think about it.

It is so interesting the point you made that the Codex app was so like you did such a good job getting people to be aware it existed and so good to use and fun to use that everyone's starting to use that versus the chat GPT app. So

clearly the direction is combine them so that you're not creating this confusion which I know is you know things people have been talking about this idea of com bringing them together.

Somebody called it a super app and wish they hadn't said that cuz now I have to hear about the super app all day every day. We'll get past it. Great.

day. We'll get past it. Great.

Okay. But is that is that kind of the not let's not call it a super app but the idea is like one place people go to do all the things. Is that the general idea or TBD?

Yeah. I think what we see here is that it's a great home base. It's a great place to keep track of all of the things that you have to do across different surfaces and some of those things you do

all of it in the app. Some of those things the app opens other apps to to do right the app can connect to Excel so that you know yes it has a spreadsheet

editor inside the app. Is that good enough for people doing financial modeling at OpenAI for raising billions of dollars? Like probably not. Um, and

of dollars? Like probably not. Um, and

so the app talks directly to the addin in Microsoft Excel on your desktop. When

it's done, you can close Excel, right?

And so it's not just about, hey, we're drawing a rectangle on the screen and everything needs to happen in that rectangle. It's this thing should be a

rectangle. It's this thing should be a home for you where you start work, you end work, you automate work, and it uses whatever you need to do. Right? There's

a there's a great story about we had some videos that we shot in this room for the original launch of the Codex app and our in-house DX videographer Brent

then was tasked with editing all these videos, right? And he edited all the

videos, right? And he edited all the videos with Codex which was one of the early like whoa what are people doing with this thing, right? And the process for why he decided to start using Codex

was really interesting. He started just because he was curious if Codex could edit videos. And so Codex is not a video

edit videos. And so Codex is not a video editor per se, right? It doesn't have any of that UI in it, but um it was able to understand that he used Premiere Pro.

It could do some edits by editing the files that were backing what was on screen in Premiere Pro, but it couldn't do everything. So naturally, what Codex

do everything. So naturally, what Codex then did was built itself an extension that could be installed into Premiere Pro that it could then talk to and say,

"Hey, Premiere Pro extension, can you please change this marker inside of the Premiere Pro app." That was pretty nuts when we saw that happening. Um,

it's a great model, right? there are

these like specialty tools that specialize in things and so we're trying to do two things at once with Codex and with now with chatgbt one is how can we seamlessly

interact with these tools that you're already using and say like we don't we don't need to build a better video editor for you right but like codeex and chatd can use that video editor right it can interact can hand stuff off to it

right so how can we do that and that's often through um connectors or computer use or even extensions in this case right And then there is, you know, Dan Shepard's thing, which is, hey, I have

these web apps that you can click around and use, but I want to be able to open these in codecs and have codeex do extra stuff with it, right? And so those are kind of like two models that are almost

inverse of each other that we're doing a lot with both at the same time.

This premiere story is interesting to me because it's another example of just be more ambitious with these AI jobs. Like

you may may not know, maybe they could do this thing. It's almost just like go try go try out see if it figures it out.

I'm going to take us to a recurring corner on the podcast that I call fail corner.

And so the question for you is people see people like you just like killing it, just growing. Everything's winning.

Codeex is doing so great. This crazy

career, everything's up and to the right. People may not see the times that

right. People may not see the times that things didn't work out and things that you launched that were failures. And so

these stories are really important for people to hear that it's not all just a win all the time. What's a story of a time you failed in your career that taught you something really important?

It's funny to hear that description played back at me and like this is perhaps the first time I've I've not felt like I was failing. I mean, I was a

startup founder for a long time. I ended

up selling the company for parts essentially, right? And it was just it

essentially, right? And it was just it was years. It was a slog. It was heavily

was years. It was a slog. It was heavily regulated spaces. The whole thing felt

regulated spaces. The whole thing felt like a constant failure. Um I went to this other startup and we were trying to do some AI tools and in this also like

pretty locked down regulated industry and that felt like just time after time of trying things and it not working. So

to me it's been like I've failed actually quite a lot and you know sometimes it's just a point in time where things line up like skill set

passion point in the market line up we know with this project to bring what we've learned with the codeex app and

marry it with chachi bt there have been I don't know how many micro failures on this where we're like this is the shape it should look like and then throw that in slack and there's like a 2,000

message thread about how stupid we are and it's like that this is the thing I love about opening eye is people will just tell us that right there's there's no uh there's no holding back on like when we fail with product things

internally it's why the external product has been pretty great is because it goes through these cycles of like 2000 this sucks I failed for like I don't know somewhere between 10 and 15 years before getting

to this point so I'm still surprised every day that things are going well like and I know it I like but I think this is really important for people to that you can have a lot of things not work out and then things start to work

out super well and it's just keep going and keep learning I imagine is is a lesson. Well, with that we're uh we

lesson. Well, with that we're uh we reached our very exciting lightning round. I've got five questions for you.

round. I've got five questions for you.

Great. Here we go. Uh what are two or three books that you find yourself recommending most to other people?

See man, I'm I'm a parent now. I'm a

parent of young kids, so I I'm like I don't know. There's one called The Gruff

don't know. There's one called The Gruff to my kids. I Oh my god. Our kid just got obsessed with the Gruff.

Yes.

Uh we have like a a bedtime chart and now it's like pajamas, brush teeth, books, gruff uh on blankie.

Yeah.

Yeah. It's so good.

So other books I'm reading right now are like that style. I'm like actually The Gruff is not a terrible one. I feel like there's some less.

So sweet. Yeah. Although every kids book is about death. Like someone's eating someone, someone's killing. There's

always like bad like murder.

Yeah. Yeah. And and destruction like violence even when it doesn't feel like violence to them that like the words that there's like it creates like an arc and excitement.

Yeah.

Yeah. Okay. Great choice, Gruffle.

I currently have a book backlog. I I

need like I need to read all of them.

Any other children's books that that your kid likes?

Okay. So, yes, actually um I am well versed on children's space. My favorite

children's book ever is a very old one and it's called The Big Orange Spot or some something along those lines. Look

it up. It's great. Go get it. Um if you hate HOAs, go get it. It's about um this guy, Mr. Plumbing, who lives on a street where all the houses are the same. It's

very neat street and then one day a bird drops a large can of orange orange paint on his house and he says, "F it." Like

I'm going all in. So he goes to the store, he gets paint, hammocks, alligators, and he like totally redo his house, and the neighbors like they're up in arms, right? Like, you know, HOA

property value, whatever, whatever. Um,

it's not about HOAs, but I very anti-HOA person. It's just really cool. And then

person. It's just really cool. And then

like one by one, the neighbors go talk to them, have uh what they refer to as lemonade, but like it's a very convincing lemonade because one by one, they all start redoing their house. Like

one guy does like a boat, right? I think

I think that's a good book. I think

people need to read this when they're especially, you know, newbies.

What I hear from this is agency.

Agency. Exactly. You can just do things.

Just do things. Amazing. Okay, we'll

keep going. Uh favorite recent movie or TV show you really enjoyed if you've had any time.

So, The Magic School Bus is back um on Netflix. It's It's a new animated. It's

Netflix. It's It's a new animated. It's

got Kate McKinnon because Miss Frizzle is now Professor Frizzle and she's, you know, around but she's not the main Frizzle now. Kate McKinnon plays the

Frizzle now. Kate McKinnon plays the main Miss Frizzle. Yeah, I always liked the magic school bus.

I've never used it.

Personally, like I don't have time for movies. So, what I do is watch hourong

movies. So, what I do is watch hourong Netflix things back to back. You know

that thing that people do like Oh, I couldn't sit I couldn't sit down and watch a whole movie and then like watch hourong episodes and keep Yeah, I did. Some There's something addicting

I did. Some There's something addicting about that.

Favorite product you've recently discovered that you really love.

What was a terrible answer? I feel like I'm discovering our product every day.

Beautiful.

That's so I think linear linear does a great job.

Like linear until until this linear was like my favorite at least software product.

Is that what you guys used to to plan in?

Well, in theory.

Do you have a favorite life motto that you find yourself coming back to in work or in life? I want to ask everyone who works with me this because I I I feel like I'm not a motto person and then

people tell me stuff I say all the time.

Yeah. Like when we were chatting ahead of this, there's so many little nuggets that stood out to me that I've integrated into this chat. So I I totally hear that. Okay, last question.

You've been a PM, you've been a designer, you've been an engineer. Which

is the toughest role of the three? Which

is like the hard to start a war?

Yes. I know. I I think they're all very different. I the things that make it

different. I the things that make it tough for one person make it easy for others. There's a lot there's so much so

others. There's a lot there's so much so many takes on this and like this triad.

What's going to happen with this triad?

Like designers are done or like should designers code? Are PMs cooked? Like are

designers code? Are PMs cooked? Like are

engine do we not need engineers anymore because PMs are going to write all the code? Or are designers going to PM now?

code? Or are designers going to PM now?

And like everybody's cooked and everybody's so back and I don't know like there's some convergence. There's

some fluidity that is being introduced that I think is refreshing and great especially for people with agency that want to be able to just like do the thing that needs to get done. Um and at

the same time like we talked about there are some things that shouldn't go away but I think people should find the stuff that's worth working on and go figure out what to do on those things. That is

a beautiful way to end it. Andrew, thank

you so much for being here.

Thank you. Bye everyone.

Thank you so much for listening. If you

found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also,

please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You

can find all past episodes or learn more about the show at lennispodcast.com.

See you in the next episode.

I love that thing about Brent in the Premiere.

Yeah, that's cool. I've actually used edit

that's cool. I've actually used edit edits as well. It's basically

simple stuff like, oh, could you just cut this into the three breaks, you know, like if there's a pause in conversation like the second and CEX

understands it. Basically, every job we

understands it. Basically, every job we feel like starts with a story like this, which is the product's not designed for it, but it's sort of a blank chatbot that can write code. So, it can do

everything, but like what what are the useful things for it to do, right? I mean, people just have to have

right? I mean, people just have to have curiosity about the project. They they

have to, you know, have an in an intentional outcome and use codeex as the platform for that just to see what happens, you know, because there's no risk at all, right? just a few tokens.

right? just a few tokens.

Few tokens.

But of course, if you're working for OpenAI, there's less risks on that regard.

Yeah. You asked um one of them like what or a lot of them actually like what skills are important and like then then you've also had conversations about like the cracked new grad versus the

like I don't know if you're married to the exact process you have right now like that. I don't know what advice to ever

that. I don't know what advice to ever give, but if there's one piece, it's like do not get married to your exact process. Get married to like the

process. Get married to like the outcomes that you are uniquely able to deliver and then do things like change your process to try things. Like

you just keep I'm the best at understanding Figma auto layout like right what are you doing, right? Cuz AI is going to be better at

right? Cuz AI is going to be better at that also.

You just keep spouting interesting things.

Keep it in. It's crazy the level of self-awareness that's required to like be successful with AI.

It is.

Yeah.

It's also why I'm nervous to ever say like this is how something's going to be cuz I think about like my parents are open-minded people. They are into their

open-minded people. They are into their careers but just like the stuff that works here is just not going to it's not going to work with everybody. There's no

nice way of saying that, you know, but like the people who are here are self- selecting for like, oh, I'm somebody who just figures out the next thing to do and that's just

not like most of the population will not be an early adopter of things.

And there's also just like it's kind of like a a bummer to have to relearn things all the time. Yeah.

You know, it's like god damn it just to learn a new thing again.

Yeah. Like I I hate repetition. This is

like a me thing. I don't. This is why I'm like not ever the best media person either cuz I just like I hate repeating myself.

Perfect.

Um sucks to be a founder when you hate repeating yourself cuz you you like have to repeater and chief.

Um and so like to me I'm like if I can come in and do my job in a different way every day. Love it.

every day. Love it.

But like that's not You found product market fit for your job.

Yes. Yeah. No, that's how that's I like can't negotiate because I'm like well I don't want other jobs.

Amazing, man.