Lenny's Podcast: Product | Career | Growth - Why humans are AI’s biggest bottleneck (and what’s coming in 2026) | Alexander Embiricos (OpenAI Codex Product Lead)
Episode Date: December 14, 2025Alexander Embiricos leads product on Codex, OpenAI’s powerful coding agent, which has grown 20x since August and now serves trillions of tokens weekly. Before joining OpenAI, Alexander spent five ye...ars building a pair programming product for engineers. He now works at the frontier of AI-led software development, building what he describes as a software engineering teammate—an AI agent designed to participate across the entire development lifecycle.We discuss:1. Why Codex has grown 20x since launch and what product decisions unlocked this growth2. How OpenAI built the Sora Android app in just 18 days using Codex3. Why the real bottleneck to AGI-level productivity isn’t model capability—it’s human typing speed4. The vision of AI as a proactive teammate, not just a tool you prompt5. The bottleneck shifting from building to reviewing AI-generated work6. Why coding will be a core competency for every AI agent—because writing code is how agents use computers best—Brought to you by:WorkOS—Modern identity platform for B2B SaaS, free up to 1 million MAUs: https://workos.com/lennyFin—The #1 AI agent for customer service: https://fin.ai/lennyJira Product Discovery—Confidence to build the right thing: https://atlassian.com/lenny/?utm_source=lennypodcast&utm_medium=paid-audio&utm_campaign=fy24q1-jpd-imc—Transcript: https://www.lennysnewsletter.com/p/why-humans-are-ais-biggest-bottleneck—My biggest takeaways (for paid newsletter subscribers): https://www.lennysnewsletter.com/i/180365355/my-biggest-takeaways-from-this-conversation—Where to find Alexander Embiricos:• X: https://x.com/embirico• LinkedIn: https://www.linkedin.com/in/embirico—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Introduction to Alexander Embiricos (05:13) The speed and ambition at OpenAI(11:34) Codex: OpenAI’s coding agent(15:43) Codex’s explosive growth(24:59) The future of AI and coding agents(33:11) The impact of AI on engineering(44:08) How Codex has impacted the way PMs operate(45:40) Throwaway code and ubiquitous coding(47:10) Shipping the Sora Android app(49:01) Building the Atlas browser(53:34) Codex’s impact on productivity(55:35) Measuring progress on Codex(58:09) Why they are building a web browser(01:01:58) Non-engineering use cases for Codex(01:02:53) Codex’s capabilities(01:04:49) Tips for getting started with Codex(01:05:37) Skills to lean into in the AI age(01:10:36) How far are we from a human version of AI?(01:13:31) Hiring and team growth at Codex(01:15:47) Lightning round and final thoughts—Referenced:• OpenAI: https://openai.com• Codex: https://openai.com/codex• Inside ChatGPT: The fastest-growing product in history | Nick Turley (Head of ChatGPT at OpenAI): https://www.lennysnewsletter.com/p/inside-chatgpt-nick-turley• Dropbox: http://dropbox.com• Datadog: https://www.datadoghq.com• Andrej Karpathy on X: https://x.com/karpathy• The rise of Cursor: The $300M ARR AI tool that engineers can’t stop using | Michael Truell (co-founder and CEO): https://www.lennysnewsletter.com/p/the-rise-of-cursor-michael-truell• Atlas: https://openai.com/index/introducing-chatgpt-atlas• How Block is becoming the most AI-native enterprise in the world | Dhanji R. Prasanna: https://www.lennysnewsletter.com/p/how-block-is-becoming-the-most-ai-native• Goose: https://block.xyz/inside/block-open-source-introduces-codename-goose• Lessons on building product sense, navigating AI, optimizing the first mile, and making it through the messy middle | Scott Belsky (Adobe, Behance): https://www.lennysnewsletter.com/p/lessons-on-building-product-sense• Sora Android app: https://play.google.com/store/apps/details?id=com.openai.sora&hl=en_US&pli=1• The OpenAI Podcast—ChatGPT Atlas and the next era of web browsing: https://www.youtube.com/watch?v=WdbgNC80PMw&list=PLOXw6I10VTv9GAOCZjUAAkSVyW2cDXs4u&index=2• How to measure AI developer productivity in 2025 | Nicole Forsgren: https://www.lennysnewsletter.com/p/how-to-measure-ai-developer-productivity• Compiling: https://3d.xkcd.com/303• Jujutsu Kaisen on Netflix: https://www.netflix.com/title/81278456• Tesla: https://www.tesla.com• Radical Candor: From theory to practice with author Kim Scott: https://www.lennysnewsletter.com/p/radical-candor-from-theory-to-practice• Andreas Embirikos: https://en.wikipedia.org/wiki/Andreas_Embirikos• George Embiricos: https://en.wikipedia.org/wiki/George_Embiricos: https://en.wikipedia.org/wiki/George_Embiricos—Recommended books:• Culture series: https://www.amazon.com/dp/B07WLZZ9WV• The Lord of the Rings: https://www.amazon.com/Lord-Rings-J-R-R-Tolkien/dp/0544003411• A Fire Upon the Deep (Zones of Thought series Book 1): https://www.amazon.com/Fire-Upon-Deep-Zones-Thought/dp/1250237750• Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity: https://www.amazon.com/Radical-Candor-Kick-Ass-Without-Humanity/dp/1250103509—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. To hear more, visit www.lennysnewsletter.com
Transcript
Discussion (0)
Do lead work on Codex?
Codex is opening eyes coding agent.
We think of Codex as just the beginning of a software engineering teammate.
It's a bit like this really smart intern that refuses to read Slack.
It doesn't check data dog unless you ask it to.
I remember Carpathy tweeted the gnarliest bugs that he runs into,
that he just spends hours trying to figure out nothing else has solved.
He gives it to Codex, lets it run for an hour and it solves it.
Starting to see glimpses of the future where we're actually starting to have Codex be on call for its own training.
Codex writes a lot of the code that helps, like, manage its training run,
the key infrastructure. And so we have a Codex code review. It's like catching a lot of mistakes.
It's actually caught some like pretty interesting configuration mistakes. One of the most
mind-blowing examples of acceleration to SORA Android app, like a fully new app. We built it in
18 days and then 10 days later, so 28 days total we went to the public. How do you think you win in
this space? One of our major goals with Codex is to get to productivity. If we're going to build
a super system, it has to be able to do things. One of the learnings over the past year is that
for models to do stuff, they are much more effective when they can use a computer. It turns out the best
way for models to use computers is simply to write code. And so we're kind of getting to this idea
where if you want to build any agent, maybe you should be building a coding agent. When you think about
progress on Codex, I imagine you have a bunch of e-vows and there's all these public benchmarks. A few of us
are like constantly on Reddit. You know, there's a praise up there and there's a lot of complaints.
What we can do as a product team, just try to always think about how are we building a tool so that
it feels like we're maximally accelerating people rather than building a tool that makes it more
unclear what you should do as the human. Being at Open AI, I can't not ask about how far you think we are from
The current underappreciated limiting factor is literally human typing speed or human multitasking speed.
Today, my guest is Alexander Mbikos, product lead for Codex.
OpenAI is incredibly popular and powerful coding agent.
In the words of Nick Turley, head of Chatjibati and former podcast guest, Alex is one of my all-time
favorite humans I've ever worked with, and bringing him and his company into OpenAI
ended up being one of the best decisions we've ever made.
Similarly, Kevin Wheel, OpenAI, CPO, said Alex is simply the best.
In our conversation, we chat about what it's truly like to build product at OpenAI,
how Codex allowed the SORA team to ship the SORA app,
which became the number one app in the app store in under one month.
Also, the 20x growth codex is seeing right now and what they did to make it so good at coding,
why his team is now focused on making it easier to review code, not just write code,
his AGI timelines, his thoughts on when AI agents will actually be really useful,
and so much more, a huge thank you to Ed Bays, Nick Turley, and Dennis Yang for suggesting topics
for this conversation.
If you enjoy this podcast,
don't forget to subscribe and follow it
in your favorite podcasting app or YouTube.
And if you become an annual subscriber
of my newsletter,
you get a year free of 19 incredible products,
including a year free of Devon, lovable,
replet, bolt, n-8-m, linear, superhuman,
de-script, busper flow, gamma, perplexity,
warp, granola, magic patterns,
rickash, chirpired, D, mobbin, post, hog,
and stripe atlas.
Head on over to lenniesnusnetter.com
and click product pass.
With that, I bring you Alexander M. Birikos,
after a short word from our sponsors.
Here's a puzzle for you.
What do OpenAI, Cursor, Perplexity, Versal, Platt, and hundreds of other winning companies have in common?
The answer is they're all powered by today's sponsor, WorkOS.
If you're building software for enterprises, you've probably felt the pain of integrating single sign-on, skim, R-back, audit logs, and other features required by big customers.
WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS.
Whether you're a seat-stage startup trying to land your first enterprise customer or a unicorn expanding globally,
WorkOS is the fastest path to becoming enterprise-ready and unlocking growth.
They're essentially strike for enterprise features.
Visit WorkOS.com to get started or just hit up their Slack support where they have real engineers in there who answer your questions super fast.
WorkOS allows you to build like the best with delightful APIs, comprehensive docs, and a smooth developer experience.
Go to workOS.com to make your app,
enterprise ready today.
This episode is brought to you by Finn, the number one AI agent for customer service.
If your customer support tickets are piling up, then you need Finn.
Finn is the highest performing AI agent on the market with a 65% average resolution rate.
Finn resolves even the most complex customer queries.
No other AI agent performs better.
In head-to-head bakeoffs with competitors, Finn wins every time.
Yes, switching to a new tool can be scary, but Finn works on any help desk with no might
integration needed, which means you don't have to overhaul your current system or deal with delays
and service for your customers. And Finn is trusted by over 6,000 customer service leaders and
top companies like Anthropic, Shutterstock, Synthesia, Clay, Vanta, lovable, Monday.com, and
more. Because Finn is powered by the Finn AI engine, which is a continuously improving system that
allows you to analyze, train, test, and deploy with ease, Finn can continuously improve your results
too. So if you're ready to transform your customer service and scale your support, give Finn a try.
for only 99 cents per resolution.
Plus, Finn comes with a 90-day money-back guarantee.
Find out how Finn can work for your team at f-in.a-I-I-slash-Lenny.
That's fin.com.
Alexander, thank you so much for being here,
and welcome to the podcast.
Thank you so much.
I've been following for ages, and I'm excited to be here.
I'm even more excited.
I really appreciate that.
I want to start with your time at OpenAI.
So you joined OpenAI about a year ago.
Before that, you had your own startup.
for about five years, before that you're a product manager at Dropbox.
I imagine Open AI is very different from every other place you've worked.
Let me just ask you this.
What is most different about how Open AI operates?
And what's something that you've learned there that you think you're going to take with
you wherever you go, assuming you ever leave?
By far, I would say the speed and ambition of working at Open AI are just like dramatically
more than what I can imagine.
And, you know, I guess it's kind of an embarrassing thing to say because, you know,
everyone who's a startup founder thinks, like, oh, yeah, my startup moves super fast and the talent
bar is super high and we're super ambitious. But I have to say, like, working in opening, I just
kind of like made me reimagine what that even means. We hear this a lot about, you know,
it feels like every AI company is just like, oh my God, I can't believe how fast they're moving.
Is there an example of just like, wow, that wouldn't have happened this quickly anywhere else?
The most obvious thing that comes to mind is just like the explosive growth of Codex itself.
I think it's while since we bumped our stern number, but, like, you know, it's like the 10xing
of Codex's scale was just like super fast in a matter of months and it's like well more since then
and you know like once you've lived through that or at least speaking for myself like having lived
through that now I feel like any time I'm going to spend my time on like you know building tech
product there's that kind of that speed and scale that I now need to to meet if I think of like what
I was doing in my startup it moved like way slower and I you know there's always this balance with
startups of like how much do you commit to an idea that you have versus like find out that it's
not working and then pivot. But I think one thing I've realized that Open AI is like the amount
of impact that we can have and in fact need to have to do a good job is so high that it's a
I have to be like way more ruthless with how I spend my time now. Before we get to Codex,
is there a way that they've structured the org or I don't know the way that open AI operates that
allows the team to move this quickly because everyone everyone wants to move super fast.
I imagine there's a structural approach to allowing.
this to happen? I mean, so one thing is just the technology that we're building with has like just
transformed so many things, you know, from like both how we build, but also like what kinds of
things we can enable for users. And, you know, we spend most of our time talking about like the
sort of improvements in the foundation models. But I believe that even if we had no more progress today
with models, which is absolutely not the case. But even if we had no more progress, we are way behind
on product. There's so much more product to build. So I think like just like,
the moment is ripe, if that makes sense.
But I think there's a lot of sort of counterintuitive things that surprised me when I arrived
as far as like how things are structured.
One example that comes to mind is like when I was working on my startup and before that
when I was a drop box, it was like very important, you know, especially as a PM to like
always kind of rally the ship and it was kind of like make sure you're pointed in the right
direction and then you can like accelerate in that direction.
But here I think because we don't exactly know like what capabilities will even come up
soon and we don't know what's going to work technically.
And then we also don't know what's going to land, even if it works technically.
It's much more important for us to be very humble and learn a lot more empirically and
just try things quickly.
And like the org is set up in that way to be incredibly bottoms up.
You know, this is again, one of those things that like, as you were saying, everyone
wants to move fast.
I think everyone likes to say that they're bottoms up or at least a lot of people do.
But open AI is like truly, truly bottoms up.
And that's like being a learning experience for me.
that now, like, it'll be interesting if I ever work at, like, I don't think it'll ever,
it'll even make sense to work at a non-AI company in the future.
I don't even know what that means.
But if I were to imagine it or go back in time, I think I would like run things totally.
What I'm hearing is kind of this ready fire aim is the approach more than ready aim fire.
And there's something, and as you processed that, because that may not come across well,
but I actually have heard this a lot at AI companies is because you don't know, and Nick Turley
should, I think the same sentiment. Because you don't know how people will use it. It doesn't make
sense to spend a lot of time making it perfect. It's better to just get it out there in a primordial
way, see how people use it and then go big on that use case. Yeah. It's like, okay, to use this
analogy a little bit, I feel like there is an aim component, but the aim component is much fuzzier.
You know, it's kind of like roughly, what do we think can happen? Like someone I've learned a ton
from working here is a research lead. And he likes to say that like an open AI,
we can have really good conversations about something that's like a year plus from now.
And, you know, there's a lot of ambiguity and what will happen, but, like, that's a right
sort of timeline. And then we can have really good conversations about what's happening, like,
in like low months or weeks. But there's kind of this, like, awkward middle ground,
which was like as you start approaching a year, but you're not at a year where it's like very
difficult to reason about, right? And so as far as like aiming, I think we want to know, like,
okay, what are some of the futures that we're trying to build towards? And like, a lot of the
problems we're dealing with in AI, like such as alignment or problems you need to be thinking
out, like, really far out into the future. So we're kind of aiming fuzzily there. But when it comes
down to the more tactically like, oh, yeah, like what product will we build and therefore, how
will people use that product? That's the place where we're much more like, let's find out
empirically. That's a good way of putting it. Something else that when people hear this,
they, people sometimes hear companies like you're saying, okay, we're going to be bottoms up,
we're going to try a bunch of stuff. We're not going to have exactly a plan of where it's going
in the next few months.
The key is you all hire the best people in the world.
And so that feels like a really key ingredient in order to be the successful at bottoms
up work.
It's just super resonantly.
I was just like, again, surprised or even shocked when I arrived at like the level of like
individual like drive and like autonomy that everyone here has.
So I think like the way that opening I runs like many, you can't like read this or be on
listen to a podcast and be like, I'm just going to deploy this.
to my company.
You know, maybe this is a hard thing to say, but I think, like, yeah, very few companies
have the talent caliber to be able to do that.
So it might need to be, like, adjusted if you were going to implement this.
Okay, so let's talk Codex.
You lead work on Codex.
How is Codex going?
What numbers can you share?
Is there anything you can share there?
Also just not everyone knows exactly what Codex is.
Explain what Codex is.
Totally, yeah.
So I had the very lucky job of living in the future and leading products on Codex.
And Codex is opening eyes coding agent.
So super concretely, that means it's an IDE extension,
the VS code extension, that you can install,
or a terminal tool that you can install.
And when you do so, you can then basically pair with Codex
to answer questions about code, write code,
you know, run tests, execute code,
and do a bunch of the work in sort of that like thick middle section
of the software development lifecycle,
which is all about, you know, writing code
that you're gonna get into production.
More broadly, we think of codex as like, what it kindly is is just the beginning of a software engineering teammate.
And so, you know, when we use a big word like teammate, like some of the things we're imagining are that,
it's not only able to write code, but actually it participates like early on in like the ideation and planning phases of writing software
and then further downstream in terms of like validation, deploying and like maintaining code.
To make that a little more fun, like one thing I like to imagine is like if you think of what code,
is today, it's a bit like this like really smart intern that like refuses to read Slack and
like doesn't check data dog or like century unless you ask it to. And so like no matter how smart
it is, like how much you're going to trust it to write code without you also working with it, right?
So that's how people use it mostly today as they pair with it. But we want to get to the point
where, you know, it can work like just like a new intern that you hire, you don't only ask them
to write code, but you ask them to participate across the cycle. And so you know that like even
if they don't get something right the first try, they're eventually going to be able to iterate
they're right there.
I thought the point about not reading Slack and did dog was it's just not distracted,
it's just constantly focused and is always in flow.
But I get what you're saying there is it doesn't have all the context on everything that's
going on.
And like that's not only true when it's performing a task, but again, if you think of like
the best team and teammates, like you don't tell them what to do, right?
Like maybe when you first hire them, you have like a couple meetings and you're like, hey,
you kind of learn like, okay, this is these prompts work for this teammate, these prompts
don't, right?
This is how to communicate with this person.
then eventually you give them some starter tasks, you delegate if you tasked.
But then eventually you just say, like, hey, great, okay, you're working with this set of people
in this area of the code base.
You know, feel free to work with other people and other parts of the codebase too, even.
And yeah, you tell me what you think makes sense to be done.
Right.
And so, you know, we think of this as like proactivity and like one of our major goals with codex
is to like get to productivity.
I think this is, like, critically important to like achieve the mission of opening
which is to deliver the benefits of AI to all humanity.
you know, I like to joke today that like AI products, and it's a half joke.
They're actually like really hard to use because you have to like be very thoughtful about
when it could help you.
And if you're not prompting a model to help you, it's probably not helping you at that time.
And if you think of how many times like the average user is prompting AI today, it's probably like tens of times.
But if you think of how many times people could actually get benefit from a really intelligent
of entity, it's thousands of times per day. And so a large part of our goal with Konex is to figure out,
like, what is the shape of an actual teammate agent that is sort of helpful by default?
When people think about cursor and even cloud code, it's like IDE that helps you code and
kind of auto completes code and maybe does some agentic work. What I'm hearing here is the vision is
different, which is it's a teammate. It's like a remote teammate, a building code for you that you talk to
and ask to do things. And it also does.
does IDE auto complete and things like that.
Is that a kind of a differentiator in the way you think about Codex?
It's basically this idea that like we want the way, like if you're a developer and you're
trying to get something done, we want you to just feel like you have superpowers and you're
able to move much, much faster.
But we don't think that in order for you to reap those benefits, you need to be sitting
there constantly thinking about like, how can I invoke AI at this point to do this thing?
We want you to be able to sort of like plug it in to the way that you work and have it just
start to do stuff without you having to think about it.
Okay. I have a lot of questions along those lines, but
just how's it going? Is there any stats, any numbers you can share about how Codex is doing?
Yeah, it's been,
codex has been growing, like, absolutely explosively since the launch of GPT5 back in August.
There's definitely some interesting, like, product insights to talk about as to, like,
how we unlock that growth if you're interested.
But, again, the last stat we shared there was, like, we were, like, well over 10x
since August.
In fact, it's been, like 20x since then.
Also, the Codex models are serving,
many trillions of tokens a week now, and it's basically like our most served coding model.
One of the really cool things that we've seen is that the way that we decided to set up the
Codex team was to build a really tightly integrated product and research team that are iterating
on the model and the harness together. And it turns out that lets you just do a lot more and try
many more experiments as to how these things will work together. And so we were just
training these models for use in our first party harness that we were very opinionated about.
And then what we've started to see more recently, actually, is that other major sort of API coding customers are now starting to adopt these models as well.
And so we've reached a point where actually the Codex model is the most served coding model in the API as well.
You hinted at this what unlocked this growth.
I am extremely interested in hearing that.
It felt like before, I don't know, maybe this was before you joined the team, it just felt like Cloud Code was killing it.
Just everyone was sitting on top of Cloud Code.
It was by far the best way to code.
And then all of a sudden, Codex comes around.
I remember Carpathy tweeted that he just, like, has never seen a model like this.
I think the tweet was the gnarliest bugs that he runs into,
that he just spends hours trying to figure out nothing else has solved.
He gives it to Codex, lets it run for an hour, and it solves it.
What did you guys do?
We have this strong sort of mission here at OpenEI to, you know, basically to build AGI.
And so we think a lot about what, how can we shape the product so that,
it can scale, right?
You know, earlier I was mentioning like,
hey, like if you're an engineer,
you should be getting help from AI,
like thousands of times per day.
And so we thought a lot about the primitives for that
when we launched our first version of Codex,
which was Codex Cloud.
And that was basically a product that had its own computer,
it lived in the cloud, you can delegate to it.
And, you know, the sort of the coolest part about that
was you could run many, many tasks in parallel.
But some of the challenges that we saw
are that it's a little bit harder to,
set that up, both in terms of like environment configuration, like giving the model the tools
it needs to validate its changes and to learn how to prompt in that way. And sort of my analogy
for this is going back to this teammate analogy. It's like if you hired a teammate, but you're
never allowed to get on a call with them and you can only go back and forth, you know, asynchronously
over time. Like that works for some teammates. And eventually, that's actually how you want to spend
most of your time. So that's still the future. But it's hard to initially adopt. So we still have
that vision of like, that's what we're trying to get you to, a teammate that you delegate
to and then is proactive. And we're seeing that growing. But the key unlock is actually first,
you need to land with users in a way that's like much more intuitive and like trivial to get
value from. So the way that most people discover, like the vast majority of users discover Codex
today is either they download an IDE extension or they run it in their CLI. And the agent works
there with you on your computer interactively. And it works within a sandbox, which is actually like a
really cool piece of tech to help that be safe and secure, but it has access to all those dependencies.
So if the agent needs to do something, like it needs to run a command, it can do so within the
sandbox. We don't have to set up any environment. And if it's a command that doesn't work in the
sandbox, it can just ask you. And so you can get into this like really strong feedback loop using
the model. And then over time, like our team's job is to like help turn that feedback loop into
you sort of as a byproduct of using the product, configuring it so that you can then be delegating
to it down the line. And again, now,
keep going back to it, but like if you hire a teammate and you ask them to do work,
but you just give them like a fresh computer from the store, it's going to be hard for them
to do their job, right? But if as you work with them side by side, you can be like, oh, you don't
have a password for this service we use. Here's the password for the service. You know, yeah,
don't worry, feel free to run this command. Then it's like much easier for them to then go off
and do work for hours without you. So what I'm hearing is the initial version of Codex was almost
too far in the future. It's like a remote in the cloud agent that's coding for you, async
And what you did is, okay, let's actually come back a little bit. Let's integrate into the way
engineers already integrate into IDs and locally and help them kind of on-ram to this new world.
Totally. And it was quite interesting because we dog food product a ton at Open AI. So, you know,
dog food, as in we use our own product. And so Codex has been accelerating Open AI over the course of
the entire year. And the cloud product was a massive accelerants of the company as well.
It just turns out that this is one of those places where the signal we got from dog fooding
is a little bit different from the signal you get from like the general market because at OpenEI,
you know, we train reasoning models all day.
And so we're very used to this kind of prompting and like, you know, think up front, run things massively in parallel.
And, you know, it would take some time and then come back to it later asynchronously.
And so, you know, now when we build, we still get a ton of signal from dog footing internally.
but, you know, we're also very cognizant of, like, the different ways of different audiences
use the product.
That's really funny.
It's like live in the future, but maybe not too far in the future.
And I could see how everyone opening eyes living very far in the future.
And sometimes that won't work for everyone.
Yeah.
What about just, like, intelligence training data?
I don't know.
Is there something else that helped Codex accelerate its abilities actually code?
Is it, like, better, cleaner data?
Is it more just models advancing?
Is there anything else that really helped accelerate?
Yeah, so there's like a few components here.
I guess you were mentioning models and the models have improved a ton.
In fact, just last Wednesday, we shipped GPD 5.151 Codex max, a very accurately named model.
That is that is awesome.
It is awesome both because it is for any given task that you were using GPD 5.1 Codex for.
it's like, you know, roughly 30% faster at accomplishing that task.
But also it unlocks a ton of intelligence.
So if you use it at our higher reasoning levels, it's just like even smarter.
And, you know, that that feedback or that tweet you were saying like Carpathie made about like,
hey, give this your gnarliest bugs.
Like, you know, obviously there's a ton going on in the market right now.
But like Codex Max is definitely like carrying that mantle of, you know, tackling the hardest bugs.
So that is that is super cool.
But I will say it's like some of what.
how we're thinking about this is evolving a little bit from being like,
yeah, we're just going to think about the model and like,
let's just like train the best model to really thinking about like,
what is an agent actually overall?
Right.
And, you know, I'm not going to try to define agent exactly,
but at least the stack that we think of it as having is it's like,
you have this model, really smart reasoning model,
that knows how to do a specific kind of task really well,
so we can talk about how we make that possible.
But then actually, we need to serve that model through an API into a harness.
And both of those things also have a really big role here.
So for instance, one of the things they're really proud of
is you can have GP5.1 Codexx work for really long periods of time.
That's not like normal, but you can set it up to do that
or that might happen.
But now routinely we'll hear about people saying like,
yeah, it ran like overnight or ran for 24 hours.
And so for a model to work continuously for that amount of time,
it's going to exceed its context window.
And so we have a solution for that, which we call compaction.
But compaction is actually a feature that
uses all three layers of that stack.
So you need to have a model that has a concept of compaction.
And I was like, OK, as I start to approach this context window,
I might be asked to prepare to be run in a new context window.
And then at the API layer, you need an API that like understands this concept and
like has an endpoint that you can hit to do this change.
And at the harness layer, you need a harness that can like prepare the payload for
this to be done.
And so like shipping this compaction feature that now just like made this behavior possible
to like anyone using codex, actually been working across all three things.
And I think that's like increasingly going to be true.
Another maybe like underappreciated version of this is,
if you think about all the different coding products out there,
they all have like very different tool harnesses
with like very different opinions on how the model should work.
And so if you want to train a model to be good at like all the different ways it could work,
like, you know, maybe you have a strong opinion that it should work using semantic search,
right? Maybe you have a strong opinion that it should like call the spoke tools.
Or maybe you have like in our case a strong opinion that it should just use like the shell,
work in the terminal, you know, you can be much, you can move much faster if you're just
optimizing for one of those worlds, right? And so the way that we built codex is that it just
uses the shell. But in order to make that like safer and secure, we have a sandbox that the
model is used to operating in. So I think one of the biggest accelerants to go all the way
back to your answer regression is just like, we're building all three things in parallel
and like kind of tuning each one and, you know, constantly experimenting with how those
things work with like a tightly integrated product and research team. How do you
think you win in this space, do you think it'll event, it'll always be this kind of like race
with other models constantly kind of leapfrogging each other? Do you think there's a world where
someone just runs away with it and no one else can ever catch up? Is there like a path to just
we win? Again, comes back to this idea of like building a teammate and not just a teammate
that, you know, participates in team planning and prioritization, not just the teammate that,
you know, really test its code and like helps you maintain and deploy it. But even a teammate, you
like, if you think, again, an engineering teammate, they can also like schedule a calendar invite,
right, or move stand up or do whatever, right? And so in my mind, if we just imagine that
every day or every week, some like crazy new capability is just going to be deployed by a research
lab, it's just impossible for us, like, you know, as humans to keep up and, like, use all this
technology. And so I think we need to get to this world where you kind of just have like an AI
teammate or super assistant that you just talk to and it just knows how to be helpful like on its own,
right? And so you don't have to be like reading the latest tips for how to use it. You're just like,
you plugged it in and it just provides help. And so that's kind of the shape of what I think we're
building. And I think that will be like a very sticky like winning product if we can do so. So the
shape that in my head at least I have is that we build, you know, maybe a fun topic is like is chat the
right interface for AI. I actually think chat is a very good interface when you don't know,
what you're supposed to use it for.
In the same way that if I think of
I'm on MS teams or in Slack with a teammate,
chat is pretty good.
I can ask for whatever I want.
It's kind of the common denominator for everything.
So you can chat with a super assistant
about whatever topic you want,
whether it be coding or not.
And then if you are like a functional expert
in a specific domain such as coding,
there's like a GUI that you can pull up
to go really deep and like look at the code
and like work with the code.
So I think like what we need to build
as opening up,
is basically this idea of like you have chat chat sputee and not as a tool that's like ubiquitously
available to like everyone you start using it even like outside of work right to just help you you
become very comfortable with the idea of being accelerated with AI and so then you get to work and you
just can naturally just yeah i'm just going to ask it for this and i don't need to know about all the
connectors or like all the different features i'm just going to ask it for help and it'll surface to me
the best way that it can help at this point of time and maybe even chime in when i didn't ask it for help
So in my mind, if we can get to that, I think that's how we really build like the winning product.
This is so interesting because with my chat with Nick Charlie, the head of Chad GPT,
I think you shared that the original name for ChatGPT was Super Assistant or something like that.
Yeah. And it's interesting that there's like that approach to the Super Assistant and then there's this Codex approach.
It's almost like the B2C version and the B2B version.
And what I'm hearing is the idea here is, okay, you start with coding and building.
And then it's doing all this other stuff for you scheduling meetings.
I don't know, probably posting in Slack.
I don't know.
Shipping designs.
I don't know.
Is the idea there this is like the business version of chat GPT in a sense?
Or is there or is there something else there?
Yeah.
So we're getting to the like one year time horizon conversation.
A lot of this might happen sooner.
But in terms of fuzziness, I think we're at the one year.
So I'll give you like a contention in like a plausible way we get there.
But as for how it happens, who knows?
So basically.
if we're going to build a super assistant, it has to be able to do things.
So like, we're going to have a model and it's going to be able to do stuff affecting your world.
And one of the learnings I think we've seen over the past year or so is that for models to do stuff,
they're much more effective when they can use a computer.
Right.
Okay.
So now we're like, okay, we need the super assistant that can use a computer, right, or many computers.
And now the question is, okay, well, how should it use the computer?
Right.
And there's lots of ways to use a computer.
you know, you could try to hack the OS and use accessibility APIs,
maybe a bit easier as you could point and click.
That's a little slow, you know, and unpredictable sometimes.
And another way, it turns out the best way for models to use computers is simply to write code.
Right.
And so we're kind of getting to this idea where like, well, if you want to build any agent,
maybe you should be building a coding agent.
And maybe to the user, a non-technical user, they won't even know they're using a coding agent,
the same way that no one thinks about, are they using the internet or not?
It's just they're more just like, is Wi-Fi on?
Right. So I think that what we're doing with Codex is we're building a software engineering teammate.
And as part of that, we're kind of building an agent that can use a computer by writing code.
And so we're already seeing like some pull for this. It's like quite early.
But we're starting to see people like who are using Codex for like coding adjacent product purposes.
And so as that develops, I think we'll just naturally see that like, oh, it turns out like we should just always have the agent write code if there is a coding way to solve a problem instead of.
even if you're doing a financial analysis, right,
like maybe write some code for that.
So basically, like, you know, you were like,
hey, there's like the two ends of this product
for the super assistant, right, of chat GPT.
In my mind, like just coding is a core competency
of any agent including Chachapit.
And so what really, what we think we're building
is like that competency.
But so here's, here's like the really cool thing
about agents writing code is that you can import code.
Right?
Code is like composable, interoperable, right?
Because if we, you know, one very reductive view
we could have for an agent is it's just going to be given a computer and it's just going to like
point and click and you know go around. But, you know, that is the future. And then how we get there
is difficult to sort of chart a path because a lot of the questions around building agents aren't like
can the agent do it. But it's more about, well, how can we help the agent understand the context that
it's working in? And like the team that's using it, you know, probably has a way that they like to do
things. They have guidelines. They probably want certain deterministic guarantees about what the agent
can or cannot do, or they want to know that the agent understands sort of this detail.
Like an example would be, you know, if we're looking at a crash reporting tool, hitting
a connector for it, every sub team probably has a different meta prompt for like how they want
the crashes to be analyzed.
Right.
And so we start to get to this thing where like, yeah, we have this agency in front of a
computer, but we need to make that configurable for the team or for the user, right?
And let them like stuff that the agent does often.
we probably just want to build in as a competency that this agent has that it can do.
So I think we end up with this generalizable thing that you were saying of like an agent
that can just write its own scripts for whatever it wants to do.
But I think that the really key part here is can we make it so that everything that the agent
has to do often or that it does well, we can just like remember and store so that the agent
doesn't have to write a script for that again, right?
Or maybe like if I just joined a team and you are already on the same team as me, I can
like use all those scripts that the agents had written already.
Yeah, it's like if this is our teammate, we can, they can share things that it's learned
from working with other people at the company.
It just makes sense as a metaphor.
Yeah.
It feels like you're in the Carpathie camp of agents today are not that great and mostly
slop and maybe in the future they'll be awesome.
Does that resonate?
I think, so I think coding agents are pretty great.
I think that feels right.
That feels right.
Yep.
And then I think like agents outside of coding, it's still like very early.
and this is just my opinion,
but I think they're going to get a whole lot better
once they can use coding too in a composable way.
This is kind of the fun part of when you're building for software engineers,
at my startup, we were building for software engineers too
for a lot of that journey.
And they're just such a fun audience to build for
because they also like building for themselves
and are often even more creative than we are
in thinking about how to use the technology.
And so by building for software engineers,
you get to just observe a ton of emergent behavior.
and things that you should do
and build into the product.
I love how you say that
because a lot of people building for engineers
get really annoyed because the engineers
ever so, they're just always complaining about stuff.
They're like, ah, that sucks.
Why'd you build it this way?
I love that you enjoy it,
but I think it's probably because you're building
such an amazing tool for engineers
that can actually solve problems
and just, you know, code for them.
Kind of along those lines, you know,
there's always this talk of what will happen,
jobs, engineers, coding.
Do you have to learn coding, all these things?
Clearly the way you're describing it is
it's a teammate, it's going to work with you, make you more superhuman.
It's not going to replace you.
What's the way you just think about the impact on the field of engineering,
having this super intelligent engineering teammate?
I think there's two sides to it.
But the one we were just talking about is this idea that maybe every agent
should actually use code and be a coding agent.
And in my mind, that's just like a small part of this like broader idea that like,
hey, as we make code even more ubiquitous.
I mean, you could probably claim it's ubiquitous today,
even pre-AI, right?
And as we make code even more ubiquitous,
it's actually just going to be used for many more purposes.
And so there's just going to be a ton more need for people with this,
like humans with this competency.
So that's my view.
I think this is like quite a complex topic.
So, you know, it's something we talk about a lot and we have to kind of see how it pans out.
But I think what we can do, what we can do basically as a product team building in the space
is just try to always think about how are we building a tool so that it feels like
we're like maximally accelerating people, you know,
rather than building a tool that makes it like more unclear
what you should do as the human, right?
Like I think like to, to, you know, give an example right now,
like nowadays when you work with a coding agent,
it writes a ton of code, but it turns out writing code
is actually one of the most fun parts of software engineering
for many software engineers.
And so then you end up reviewing AI code, right?
And that's often a less fun part of the job
for many software engineers.
Right? And so I actually think like we see that like this, this comes out, plays out all the time in like a ton of micro decisions.
And so we as a product team are always thinking about like, okay, how do we make this more fun? How do we make you feel more empowered?
Whereas it's not working. And I would argue that like reviewing agent written code is like a place that today is like less fun.
And so, you know, then I think, okay, what can we do about that? Well, we can ship a code review feature that like helps you build confidence in the air written code. Okay, cool.
You know, another thing we could do is we can make it so that the agents like better able to validate its work.
And you know, it gets all the way down into like micro decisions.
Like if you're going to have the agent capability to validate work and let's say you have like,
I'm thinking of Codex Web right now, like you have a pain that sort of reflects the work the
agent did.
What do you see first?
Do you see the diff or do you see the image preview of the code it wrote?
Right.
And you know, I think if you're thinking about this from perspective, like how do I empower
the human?
How do I make them feel like as accelerated as possible?
Like you obviously see the image first, right?
You shouldn't be reviewing the code unless first, you know, you've seen the image
unless maybe it's being reviewed by an AI,
and now it's time for you to take a look.
When I had Michael Churrell, the CEO of Curser, on the podcast,
he had this kind of vision of us moving to something beyond code.
And I've seen this rise of something called spec-driven development
where you kind of just write the spec,
and then the code, you know, the AI writes code for you.
And so you kind of start working at this higher abstraction level.
Is that something you see where we're going,
just like engineers not having to actually write code or look at code,
and there's going to be this higher level of abstraction that we focus on?
Yeah, I mean, I think there's like constantly these levels of abstraction and they're actually already played out today.
right? Like today, like coding agents, mostly it's like prompts to patch, right? We're starting to see people
doing like spec-driven development or like planned and driven development. That's actually one of the
ways when people ask like, hey, how do you run codex on a really long task? Well, it's like often
collaborate with it first to write like a plan.md, like a markdown file that's your plan. And once
you're happy with that, then you ask it to go off and do work. And if that plan has verifiable
steps, it'll like work for much longer. So we're totally seeing that. I think spectraving
Development is like an interesting idea.
It's not clear to me that it'll work out that way because a lot of people don't write like
writing specs either.
But it seems plausible that some people work that way.
You know, like a bit of a joke idea though is like if you think of like the way that many teams work today, they often like don't necessarily have specs, but the team is just really self-driven and so stuff just gets done.
And so almost that is like, I'm coming up with this on the spot.
So it's, you know, not a good name, but like chatter driven development.
where it's just like stuff is happening, you know, on social media and like in your team
communications tools. And then as a result, like code gets written and deployed. Right. So,
yeah, I think I'm a little bit more oriented in that way of, you know, I don't even necessarily
want to have to write a spec. Like sometimes I want to only if I like writing specs. Right.
Other times I might just want to say like, hey, here's like the customer, you know, service channel
and like tell me what's interesting to know. But if it's a small bug, just fix it. I don't have to
respect for that, right? I have this sort of hypothetical future that I like to share
sometimes with people as a provocation, which is like, in a world where we have like truly
amazing agents, like, what does it look like to be a solo printer? And, you know, one terrible
idea for how it could look is that it's actually, there's a mobile app. And every idea that
the agent has to do is just like vertical video on your phone. And then you can like swipe left
if you think it's a bad idea and you can like swipe right if it's a good idea.
And like you can press and hold and like speak to your phone if you want to get feedback on the idea before you swipe.
You know, and in this world like basically what your job is just like plug in this app into like every single like signal system, you know, system of record.
And then you just sort of sit back and like swipe.
I don't know.
And love this.
So it's like Tinder meets TikTok meets codex.
It's pretty terrible.
No, this is great.
So the idea here is this thing is this agent is watching and right listening to you and things.
paying attention to the market, your users, and it's like, cool, here's something I should do.
It's like a proactive engineer, just like, here, we should build this feature, fix this thing.
Exactly.
I think it's a really good idea.
It's communicating with you in, like, the lowest effort.
Yeah, and like the modern way we communicate.
Swipe left or right and vertical feed.
And then the SORA video, okay, so I see how this all connects now.
I see.
Yeah.
To be clear, we're not building that, but like, you know, it's a fun idea.
I mean, you know, like in this example, though, like one of the things that it's
doing is it's consuming external signals, right?
I think the other really interesting thing is, like, if we think about, like, what is
the most successful, like, AI product to date, I would argue, it's funny, actually not
to confuse things at all, but, like, the first time we used the brand Codex at OpenAI was
actually the model powering GitHub co-pilot.
This was, like, way back in the day years ago.
And so we decided to reuse that brand recently because it's just so good, you know,
code execution.
But I think actually like auto completion in IDE's is like one of the most successful AI products today.
And part of what's so magical about it is that when it can surface like ideas for helping you really rapidly.
When it's right, you're accelerated.
When it's wrong, it's not like that annoying.
It can be annoying, but it's not that annoying.
And so you can create this like mixed initiative system that's like contextually responding to like what you're attempting to do.
And so in my mind, this is like a really interesting thing for us as open AI as we're building.
So for instance, you know, when I think about launching a browser, which we did with Atlas, right, like in my mind, one of the really interesting things we can then do is we can then like contextually surface like ways that we can help you as you're going about your day.
Right.
And so we break out of this like, you know, we're just looking at code or we're just in your terminal into this idea that like, hey, like a real teammate is dealing with a long.
more than just code, right? They're dealing with a lot of things that are web content. So like,
you know, how can we help you with that? Man, there's so much there. I love this. Okay,
so autocomplete on the web with the browser. That's so interesting. Just like, here's all the
things that we can help you with as you're browsing and going about your day. I want to talk about
Atlas. I'll come back to that. Codex, code execution. Did not know that. That's really
clever. I get it now. Okay. And then this chatter. What is a chatter-driven development?
I had a, no, this is a really good idea. But it reminds me,
had John G. Donji on the podcast, CTO of Block, and they have this product called Goose,
which is their own internal agent thing. And he talked about an engineer at Block, just has Goose
watch him with like his screen and listens to every meeting and proactively does work that he
should probably want to do. So ships to PR, sends an email, drafts a Slack message. So he's
doing exactly what you're describing in kind of a very early way.
Yeah, that's super interesting.
And, you know, I bet you the, so if we went and ask them what the bottleneck to that productivity is, did they share what it is?
Probably looking at it, just making sure this is the right thing we do.
Yeah.
Yeah.
So like we see this now.
Like we have a Slack integration for Codex.
People love, you know, if there's like something that you need to do quickly, people will just like at mention Codex.
Like, why do you think this bug is happening, right?
Doesn't have to be an engineer even like maybe, you know, data science is often here are using Codex a ton to just like answer questions.
It's like, why do you think this metric moved?
What happened?
So questions, you get the answer right back in Slack.
It's amazing, super useful.
But as for when it's writing code,
then you have to go back and look at the code, right?
And so the real, like, I think bottleneck right now
is like validating that the code worked
and like writing code review.
So in my mind, if we wanted to get to something like,
you know, a friend you were talking about world,
I think we really need to figure out
how to get people to configure their coding agents
to be much more autonomous on those later stages of the work.
It makes sense.
Like you said, writing code.
I used to be an engineer as an engineer for 10 years.
Really fun to write code.
Really fun to just get in the flow, build architect test.
Not so fun to look at everyone else's code
and just have to go through and be on the hook
if it is doing something dumb that's going to take down production.
And now that building has become easier.
What I've always heard from companies that are really at the cutting edge of this
is the bottleneck is now figuring out what to build.
And then it's at the end of like, okay,
we have all 100 PRs to review.
who's going to go through all that.
Right.
Yeah.
This episode is brought to you by Jira Product Discovery.
The hardest part of building products isn't actually building products.
It's everything else.
It's proving that the work matters, managing stakeholders, trying to plan ahead.
Most teams spend more time reacting than learning, chasing updates,
justifying roadmaps, and constantly unblocking work to keep things moving.
Jira product discovery puts you back in control.
With Jira product discovery, you can capture insights
and prioritize high-impact ideas.
It's flexible, so it adapts to the way your team works,
and helps you build a roadmap that drives alignment, not questions.
And because it's built on GERA,
you can track ideas from strategy to delivery, all in one place.
Less chasing, more time to think, learn, and build the right thing.
Get GERA product discovery for free at Atlassian.com slash Lenny.
That's atlasian.com slash Lenny.
What has the impact of Kodak's been on the way you operate
as a product person as a PM. It's clear how engineering is impacted. Code has written for you.
What is it done to the way you operate and the way PMs operate at OpenAAA?
Yeah, I mean, I think mostly I just feel like much more empowered. I've always been sort of more
technical leaning PM. And especially when I'm working on products for engineers, I feel like
it's necessary to like, you know, dog food the product. But even beyond that, I just feel like I can do
much, much more as a PM.
And, you know, Scott Beltsky talks about this idea of, like,
compressing the talent stack.
I'm not sure if I'm phrased that right.
But it's basically this idea that, like,
maybe the boundaries between these roles are a little bit, like,
less needed than before because people can just do much more.
And every time you, someone can do more,
you can, like, skip one communication boundary and make the team, like,
that much more efficient, right?
So I think, I think we see it, you know, in a bunch of functions now.
but I guess since you asked about like products specifically,
you know, now like answering questions much, much easier.
You can just ask Codex for thoughts on that.
A lot of like PM type work understanding what's changing.
Again, just ask Codex for help with that.
Prototyping is often faster than writing specs.
This is something that a lot of people have talked about.
I think something that I don't think it's super surprising,
but something that's slightly surprising is like we see like we're mostly building
code to write code that's going to be deployed to production.
But actually, we see a lot of throwaway code written with Codex now.
It's kind of going back to this idea of like, you know, ubiquitous code.
So you'll see, you know, someone wants to do an analysis.
Like if I want to understand something, it's like, okay, just give Codex a bunch of data,
but then ask it to build like an interactive like data viewer for this data.
Right?
That's just like too annoying to do in the past.
But now it's just like totally worth the time of just getting an agent to go do something.
Similarly, I've seen like some pretty cool prototypes on our design team about like if you want to
Well, like a designer basically wanted to build an animation, and this is the coin animation codex.
And it was like, normally it'd be too annoying to program this animation.
So they just vibe coded an animation editor.
And then they used the animation editor to build the animation, which they didn't check into the repo.
Actually, our designers are, there's a ton of acceleration there.
And like, speaking of compressing the town stack, I think our designers are very PME.
So, you know, they do a ton of product work.
And like, they actually have like an entire like vibe coded.
of side prototype of the Codex app.
And so a lot of how we talk about things is like,
we'll have like a really quick jam
because it's like 10,000 things going on.
And then design will like go think about how this should work.
But instead of like talking about it again,
they'll just like vibe code a prototype of that
in their like standalone prototype.
We'll play with it if we like it.
They'll vibe code that prototype into,
or vibe engineer that prototype into an actual PR to land.
And then depending on their comfort with the code base,
like codex sealize and rust is a little harder.
Maybe they'll like land it themselves
or they'll like get close and then an engineer can
help them like land the PR.
You know, we recently shipped the SORA Android app.
And that was one of the most sort of mind-blowing examples
of acceleration, actually.
Because the usage of the codex internally
at opening is obviously really, really high.
But it's been growing over the course of the year,
both in terms of like now it's basically like all technical staff
use it.
But even like the intensity and know-how of how
to make the most of coding agents has gone up by a ton.
And so the SOR Android app, right, like a fully new
app. We built it in 18 days. It went from like zero to launch to employees. And then 10 days later,
so 28 days total, we went to just like GA to the public. And that was done just like with
the help of Codex. So pretty insane velocity. I would say it was like a little bit. I don't want
to say easy mode, but there is one thing that Codex is really good at if you're a company
that's like building software and multiple platforms. So you've already figured out like some of the
underlying APIs or systems, asking Codex to port things over is really effective because it has
like something you can go look at. And so the engineers on that team were basically having Codex,
go look at the iOS app, produce plans of work that needed to be done, and then go implement those.
And it was kind of looking at iOS and Android at the same time. And so, you know, basically it was like
two weeks to launch employees, four weeks total, insanely fast. What makes that even more insane is
it became the number one app in the app store. I don't know.
This just boggles the mind.
Okay.
So, yeah.
So imagine, remember what happened on the app store with like a handful of engineers?
I think it was like two or three possibly in a handful of weeks.
Yeah.
This is absurd.
So, yeah.
So that's a really fun example of acceleration.
And then like Atlas is the other one that I think Ben did a podcast, the engine lead on Atlas.
sharing a little bit about how we built there.
Atlas is actually, I mean, it's a browser, right?
And building a browser is really hard.
And so we had to build a lot of difficult systems in order to do that.
And basically we got to the point where that team has a ton of power users of Codex right now.
And, you know, got to the point where they were basically, you know,
we were talking to them about it because a lot of those engineers are people I used to work with before my startup.
And so they'd say, before this would have taken us
two to three weeks for two to three engineers.
And now it's like one engineer, one week.
So massive acceleration there as well.
And what's quite cool is that we shipped Atlas on Mac first,
but now we're working on the Windows version.
So the team now is ramping up on Windows,
and they're helping us make Codex better on Windows 2,
which is admittedly earlier.
Like just the model we shipped last week
is the first model that natively understands PowerShell.
So, you know, PowerShell being the native like shell language on Windows.
So, yeah, it's been really awesome to see like the whole company getting accelerated by Codex, like, from.
And, you know, most obviously also research and like improving how quickly we train models and how well we do it.
And then even like design as we talked about and marketing.
Like actually we're at this point now where my product marketer is often also making string changes just directly from Slack.
Or like updating docs directly from Slack.
These are amazing examples.
You guys are living at the bleeding edge of what is possible, and this is how other companies
are going to work.
Just shipping, again, what became the number one app in the app store and just beloved
all over the, it just like took over the, I don't know, the world for at least a week,
built, you said, at 28 days and like, I don't know, 10 days, 18 days just to get like the
core of it working.
Yeah, so like 18 days we had a thing that employees were playing with.
Yeah.
And then 10 days later, we were out.
And you said just a couple engineers.
Yeah.
Two or three.
Okay.
And then Atlas, you said it took a week to build.
No, no, no.
So Atlas is not the whole week.
Atlas was like a really meaty project.
Yeah.
And so I was talking to one of the engineers on Atlas about like, you know, just how, what they use codex for.
And it's basically like, we use codex for absolutely everything.
I was like, okay.
Like, you know, how would you measure the acceleration?
And so basically the answer got back was previously it would have taken two to three weeks for two, three engineers.
and now it's like one engineer one week.
Do you think this eventually moves to non-engineers doing this sort of thing?
Does it have to be an engineer building this thing?
Could sort of been built by, I don't know, a PM or a designer.
I think we will very much get to the point where, well, basically where the boundaries are a little bit blurred.
Right.
Like, I think you're going to want someone who's like understands the details of what they're building,
but what details those are will evolve.
Kind of like how now, like, if you're writing Swift, you don't have to speak assembly.
You know, there's a handful of people in the world,
and it's really important that they exist
and speak assembly,
maybe more than a handful, right?
But that's like a specialized function
that, like, most companies don't need to have.
So I think we're just going to naturally see,
like, an increase in layers of abstraction.
And then the cool thing is now
we're entering, like, the language layer of abstraction,
like natural language.
And the natural language itself is really flexible.
Right?
Like, you could have engineers talking about, like, a plan,
and then you could have engineers talking about a spec,
and then you could have engineers talking about just, you know,
product or an idea. So I think we can also like start moving up those layers of
abstraction as well. But you know, I do think this is going to be gradual. I don't
think it's going to go up to like all of a sudden like nobody ever writes anything and like,
you know, any code and it's just specs. I think it's going to be much more like, okay,
we've set up our coding agent to be really good at like previewing the build or like at running
tests. Maybe that's the first part right that most people have set up and it's like, okay,
now we've set it up so that it can like execute the build and it can like see the results of
of its own changes, but we haven't yet built a good integration harness so that it can like,
in the case of Atlas, like, by the way, I don't know if they've done any of this or not.
I think they've done a lot of this.
But, you know, maybe the next stage is like enable it to like load a few sample pages to see
how well those work.
So then, okay, now we're going to like set up to that.
And I think for some time at least we're going to have humans kind of curating like
which of these connectors or systems or components that the agent needs to be good at talking
to.
And then, you know, in the future there will be an even greater unlock where Codex tells you
how to set it up or maybe sets itself up in a repo.
What a while time to be alive.
Wow.
I'm curious just the second order effects of this sort of thing,
just how quickly it is to build stuff.
What does that do?
Does that mean distribution becomes much, much more important?
Does it mean ideas are just worth a lot more?
It's interesting to think about how quick, how that changes.
I'm curious what you think.
I still don't think ideas are worth as much as maybe a lot of people think.
I still think execution is really hard, right?
like you can build something fast, but you still need to execute well on it.
Still needs to make sense and be a coherent thing overall.
Yeah.
And distribution is massive.
Yeah.
Just feels like everything else is now more important.
Everything that isn't the building piece, which is coming up with an idea, getting to market, profit, all that kind of stuff.
Yeah.
I think we might have been in this weird temporary phase where, you know, for a while, like, you could, you could just, it was so hard to build product that you, you, most, you.
Mostly just had to be really good at building product and it maybe didn't matter if you had an intermittent understanding of a specific customer.
But now I think we're getting to this point where actually like if I could only choose like one thing to understand it would be like really meaningful understanding of like the problems that a certain customer has
If I could only if I could only go in with one like core competency
So I think that that's that's ultimately still what's gonna matter most right like if you're starting in your company today and you have like a real
really good understanding and network of customers that are currently underserved by AI tools,
I think you're like, you're set.
Whereas if you're like good at building like, you know, websites, but you don't have
any specific customer to build for, I think you're in for a much harder time.
Bullish on vertical AI startups is what I'm hearing.
Yeah, I completely agree.
There's like, you know, there's like the general thing that can solve a lot of problems.
And then there's like, we're going to solve presentations incredibly well.
And we're going to understand the presentation problem better than anyone.
and we're going to plug into your workflows
and all these other things that matter
for a very specific problem.
Okay, incredible.
When you think about progress on Codex,
I imagine you have a bunch of e-vals
and there's all these public benchmarks.
What's something you look at to tell you,
okay, we're making really good progress.
I imagine it's not going to be the one thing,
but what do you focus on?
What's like something you're trying to push?
What's like a KPI or two?
One of the things that I'm constantly reminding myself of
is that a tool like Codex
sort of naturally is a tool that you would become a power user of.
Right? And so we can accidentally spend a lot of our time thinking about features that are like very
deep in the user adoption journey. And so we can kind of end up over solving for that.
And so I think it's like just critically important to like go look at like your like D7 retention,
right? Just go try the product. Like sign up from scratch again. I have a few too many like chat
to pt Pro accounts that I've just like, in order to maximally correctly dog food like signed up for
my Gmail and they charge me like 200 bucks a month.
I need to expense those.
But, you know, like, I think just like the feeling of being an user and the early retention
stats are still like super important for us.
Because as much as this category is taking off, I think we're still in the very early
days of like people using them.
Another thing that we do that might be, I think we might be the most like user feedback
slash social media pill team out there in this space.
There's like a few of us are like constantly on Reddit and Twitter and you know, there's a
there's a praise up there and there's a lot of complaints but we take the complaints like
very seriously and look at them. And I think that again because you can use like coding
agent for so many different things. It often is like kind of broken in many sort of ways for like
specific behaviors. And so we actually monitor a lot just like what the vibes are on
social media pretty often especially I think for for Twitter X
it's a little bit more hypey.
And then Reddit is a little more negative but real, actually.
So I've started increasingly paying attention to how people are talking about using codex on Reddit actually.
This is important for people to know.
Which the subreddits do you check most?
Is there like an R codex?
I mean, the algorithm is pretty good at surfacing stuff, but like R slash codex is there.
Okay.
I'll take.
Very interesting.
And then if people tag you on Twitter, you still see that, but maybe not as powerful as
seeing it on Reddit. Well, yeah, and the interesting, well, the thing with Twitter is it's a
little bit more one-to-one, even if it's, like, in public, whereas, like, with Reddit,
there's, like, really good uploading mechanics, and, like, maybe most people are still not
thoughts, unclear. So you get, you get, like, good signal on what matters and what other people
think. So, interestingly, Atlas, I want to talk about that briefly. You guys launched Atlas.
I tweeted, actually, that I tried Atlas, and then I don't love the AI-only search experience
as just, like, I just want Google sometimes or whatever.
Like just waiting for it.
I had to give me an answer.
I'm like, I don't want to.
And there was no way to switch.
I just tweeted, hey, I'm switching back.
I don't know.
It's not great.
And I feel like I made some PMs at Open AI sad.
And I saw someone tweet, okay, we have this now.
Which I imagine was always part of the plan.
It's probably an example of we just ship.
We got to ship stuff.
See how people use it.
And then we figured out.
So I guess one is that, I don't know.
Is there anything there?
And two, I'm just curious.
Why are you guys building a web browser?
So I worked on that list for a bit.
I don't work on it now.
But, you know, like the,
A bit of the narrative here for me, just to tell my story a bit, was like, I was working on this, like, screen sharing, like, pair programming startup, right? And then we joined Open AI. And so the idea was really to build a contextual desktop assistant. And the reason I believe that's so important is because I think that it's really annoying to have to give all your context to an assistant and then to figure out how it can help you. Right. And so if it could just like understand what you are trying to do, then it could maximally accelerate you. And so I would, you know, I still think of, you know, I still think of.
Codex actually is like a contextual assistant from a little bit of a different angle, like starting with coding tasks.
But some of the some of the thinking, at least for me personally, I can't speak for the whole product,
but was that a lot of work is done in the web. And if we could build a browser, then we could be
contextual for you, but in a much more first class way. We weren't hacking like other desktop software,
which have like very varied support for like what content they're rendering to the accessibility tree.
wouldn't be relying on screenshots, which are a little bit slower and unreliable.
Instead, we could be in the rendering engine, right, and like extract whatever we needed to
to help you. And also, I like to think of like, you know, video games, like, I don't know,
if you've played like, I don't know, say Halo, right? Like, you walk up to an object. I mean,
this is true for many games. You press, man, it's been a long time. This is embarrassing.
Press X. And it just does the right thing, right? And I was one of those guys who always read
the instruction manual for every video game that I bought.
Now, I remember the first time I read about a contextual action and I just thought it was like this really cool idea.
And, you know, the thing about a contextual action is we need to know what you are attempting to do.
We have a little bit of context and then we can and then we can help.
And I think this is critically important because, you know, imagine this world that we reach, right?
We have agents that are helping you thousands of times per day.
Imagine if the only way we could tell you that we helped you is if we could like push notify you.
So you get a thousand push notifications a day of an AI saying like,
hey, I did this thing, do you like it?
It'd be super annoying, right?
Whereas imagine going back to software engineering,
like I was looking at a dashboard and I noticed some like key metric had like gone down.
And you know, at that point in time,
and then I could like maybe go take a look and then surface the fact that it has an opinion
on why this metric went down and maybe a fix right there,
right when I'm looking at the dashboard.
Right?
That would be like, that would much more keep me in flow and enable the,
agents take action on many more things.
So in my mind, like, part of why I'm excited for us to have a browser is that I think we have
then like much more context around like what we should help with.
Users have much more control over what they want us to look at.
It's like, hey, if you want to open, if you want us to like take action on something, you can
open it in your AI browser.
If you don't, then you can open in your other browser.
Right.
So like really clear control and boundaries.
And then we have the ability to build U.X that's like mixed initiative so that we can
surface contextual actions.
to you at the time that they're helpful, as opposed to just like randomly notifying you.
Hearing the vision for Codex being the super assistant, it's not just there to code for you.
It's trying to do a lot for you as a teammate and as this kind of super teammate, and that makes you awesome at work.
So I get this.
Speaking of that, are there other non-engineering common use cases for Codex?
Just ways that non-engineers, we talked about designers prototyping and building stuff.
Are there any kind of fun or unexpected ways people are using codecs that aren't engineers?
I mean, there's a load of unexpected ways,
but I think most of what we're seeing,
like real traction with people using things
are still for now, like, very like,
I would say coding adjacent or like sort of tech oriented,
places where there's like a mature ecosystem,
or maybe you're doing data analysis or something like that.
I personally am expecting that we're gonna see a lot more of that over time.
But for now, like, we're keeping the team like very focused
on just coding for now because there's so much more work to do.
For people that are thinking about trying out codex, is there like, does it work for all kinds of codebases?
What code does it support?
If you're like, I don't know, SAP, can you add codex and start building things?
What's kind of like the sweet spot where does it start to not be amazing yet?
I'm really glad you asked this question, actually, because the best way to try codex is to give it your hardest tasks, which is a little different than some of the other coding agents.
Like, you know, some tools you might think, okay, let me like start easy.
or just like, you know, like vibe code something random and decide if I like the tool.
Whereas like we're really building codex to be the like professional tool that you can give your like hardest problems to.
And you know that writes like high quality code in your like enormous code base that is in fact not perfect right now.
So yeah, I think if you're going to try codex, you want to try it on like a real task that you have and not necessarily like dumb that task down to something that's like trivial.
But actually like, you know, like a good one would be like like a good one would be like a real task.
like you have a hard bug and you don't know what what's causing that bug and you ask codex to
like help figure that out or like to implement that you know the fix.
I love that answer.
Just give it your hardest problem.
I will say like, you know, if you're like, hey, okay, well, the hardest problem I have is
that I need to build like a new unicorn business.
Like obviously they're, you know, it's not going to work.
Not yet.
So I think it's like give it like the hardest problem, but something that is still like one
like question, right, or one task to start.
That's if you're testing.
And then over time, you can learn how to use it for like bigger things.
Yeah.
What languages does it support?
Basically, the way we've trained codex is like there's a distribution of languages that
we support and it's like fairly aligned with like the frequency of these languages
in the world.
So unless you're writing some like very esoteric language or like some private language,
it should do fine in your language.
If someone was just getting started, is there a tip you could share it to help them be
successful?
Like if you could just whisper a little tip into someone just setting up Codex for the first
time to help them have a really good time, what's something you would
I might say try a few things in parallel, right?
So you could try giving it a hard task, maybe ask it to understand the code base, formulate
a plan with it around an idea that you have and kind of build your way up from there.
And like sort of the meta idea here is it's again, it's like you're building trust
with the new teammate.
And so you wouldn't go to a new teammate and just give them like, hey, do this thing.
Here's zero context.
You would start by like first making sure they understand the code base and then you would
like maybe align on an approach and then you would have them go off and do bit by bit.
Right. And I think if you use codex in that way, you'll just sort of naturally start to
understand like the different ways of prompting it because it is a super powerful like agent
and model, but it is it is a little bit different to prompt codex than other models.
Just a couple more questions. One, we touch on this a little bit. As AI does more and more
coding, there's always this question of should I learn to code and why should I spend time doing
this sort of thing. For people that are trying to figure out what to do with their career,
especially if they're into software engineering computer science, do you think there's specific
elements of computer science that are more and more important to lean into, maybe things they
don't need to worry about? Like, what do you think people should be leaning into skill-wise as this
becomes more and more of a thing in our workplace? I think there's like a couple
angles you could go at this from. I think the, well,
The easiest one to think of at least is just like be a doer of things.
I think that, you know, with coding agents getting better and better over time,
it's just what you can do as even like someone in college or a new grad is just like so much more than what that was before.
And so I think you just want to be taking advantage of that.
And definitely when I'm looking at like hiring folks who are earlier career,
it's like definitely something that I think about is how productive are they using the latest tools.
they should be like super productive.
And if you think of it in that way,
they actually have like less of a handicap than before
versus a more senior career person
because, you know, the divide is actually getting smaller
because they've got these amazing coding agents now.
So that's one thing, which is like,
I guess the thing, the advice is just like,
learn about whatever you want,
but just make sure you spend time doing things,
not just like fulfilling homework assignments, I guess.
I think the other side of it, though,
is that it's still deeply worth understanding
like what makes a good,
like overall software system.
So I still think that like skills like really strong system
is engineering skills or even like really effective
like communication and collaboration with your team.
Skills like that I think are are important or continue to matter
for quite some time.
Like I don't think it's gonna be like all of a sudden
the AI coding agents are just able to build like perfect systems
without your help.
I think it's gonna look much more gradual
where it's like, okay, we have these AI coding agents
they're able to validate their work.
It's still important.
And like, for example, like, I'm thinking of an engineer who was working on Atlas since we were talking about it.
He set up codex so that it can like verify its own work, which is a little bit non-trivial
because of the nature of the Atlas project.
So the way that he did that was he actually prompted codex like, hey, why can't you verify your work, fix it?
And like did that on a loop, right?
And so you still like at various phases are going to want a human in the loop to like help
configure the coding agent to be effective.
And so I think like you still want to be able to reason about that.
So maybe it's like less important that you can like type really fast and like you understand exactly how to write.
Not that anyone writes a four each loop or something, right.
But it is or you know, you don't need to know how to implement like a specific algorithm.
But I think you need to be able to reason about the different systems and like what makes like effective a software engineering team effective.
So I think that's the other really important thing.
And then like maybe the last angle that you could take is I think if you're on the frontier of knowledge,
for a given thing, I still think that's like deeply interesting to go down.
Partially because that knowledge is still going to be like, you know, agents aren't
going to be as good at that, but also partially because I think that like by trying to
advance the frontier of a specific thing, you'll actually like end up like being forced to
take advantage of coding agents and like using them to accelerate your own workflows as you go.
What's an example that when you talk about being at the frontier?
So Codex writes a lot of the code that helps like manage its training runs, the
infrastructure, you know, we move pretty fast. And so we have a CodeC review. It's like catching
a lot of mistakes. It's actually caught some like pretty interesting configuration mistakes. And,
you know, we're starting to see glimpses of the future where we're actually starting to
have Codex even like be on call for its own training, which is pretty interesting. So there's lots
there. Wait, what does that mean to be on call for its own training? So it's running,
it's training and it's like, oh, something broke. Someone needs and it, it does it like alert people?
It's like here, I'm going to fix the problem and restart.
This is an early idea that we're like figuring out.
But the basic idea is that, you know, during a training run,
there's like a bunch of graphs that like today like humans are looking at and it's like
really important to like look at those.
We call this babysitting.
Because it's very expensive to train, I imagine and very important to move fast.
Exactly.
And there's a lot of, there's a lot of systems underlying the training run.
And so like a system could go down or there could be an error somewhere that gets
introduced.
And so we might need to like fix it or pause things or I don't know, there's lots of actions
we might need to take. And so basically having codex run on a loop to like evaluate how those charts
are moving over time, this sort of this idea that we have to like how to enable us to like train
like way more efficiently. I love that. This is very much along the lines of this is the future of agents.
Its codex isn't just for building code and write. It's it's a lot more than that. Yeah.
Okay. Last question. Being at OpenAI, I can't not ask about your AGI timeline and how far you
think we are from AGI. I know this isn't which you work on, but there's a lot of opinions,
a lot of, I don't know, timelines. How far do you think we are from a humanly, human version
of AI, whatever that means to you? For me, I think that it's a little bit about like, when do
we see the acceleration curves, kind of go like this, or I don't know which way I'm mirrored here, right?
When do we see the hockey stick? And I think that the current limiting factor, I mean, there's many,
but I think a current underappreciated limiting factor is like literally human typing speed
or human multitasking speed on like writing prompts.
Right? And like you know, you were talking about it's like you can have an agent like watch
all the work you're doing but if you don't have the agent also validating its work,
then you're still bottlenecked on like can you go review all that code, right? So my view is
that we need to unblock those productivity loops from like humans having to prompt
and humans having to like manually validate all the work. And so for,
we can like rebuild systems to let the agent like be default useful, we'll start unlocking
hockey sticks.
Unfortunately, I don't think that's going to be binary.
I think it's going to be very dependent on what you're building.
Right.
So like I would imagine that like next year, if you're a startup and you're building a new,
new pieces like, you know, some new app or something, it'll be possible for you to set it up
on a stack where agents are like much more self sufficient than not, right?
But now let's say, I don't know, you mess into SAP, right?
Let's say you work in SAP.
Like they have many like,
complex systems and they're not going to be able to just like get the agent to be self-sufficient
overnight in those systems.
So they're going to have to slowly like maybe replace systems or update systems to allow
the agent to like handle more of the work end to end.
And so basically my sort of long answer to your question, maybe boring answer, is that I think
starting next year we're going to see like early adopters like starting to like hockey
stick their productivity.
And then over the years that follow, we're going to see larger and larger companies like
hockey stick that productivity.
And then somewhere in that fuzzy middle.
is like when that hockey sticking will be like flowing back into the AI labs and that's when
we'll basically be at the AGI tier.
I love this answer.
It's very practical.
And it's something that comes up a lot on this podcast.
Just like the time to review all the things AI is doing is really annoying and a big bottleneck.
I love that you're working on this because it's one thing to just make coding much more efficient
and do that for people.
It's another to take care of that final step of, okay, is this actually great?
And that's so interesting that your sense is that's the limiting factor.
It comes back to your earlier point of even if AI did not advance anymore, we have so much more potential to unlock as we learn to use it more effectively.
So that is a really unique answer.
I haven't heard that perspective on what is the big unlock human typing speeds review basically what AI is doing for us.
So good.
Okay.
Alexander, we covered a lot of ground.
Is there anything that we haven't covered?
Is there anything you wanted to share, maybe double down on before we get to our very exciting lightning round?
I think one thing is that the Kodak's team is growing.
And as I was just saying, we're still somewhat limited by human thinking speed and human typing speed.
We're working on it.
So if you're an engineer or a salesperson or I'm hiring a product person, please hit us up.
I'm not sure the best way to give contact info.
but I guess you can go to a jobs page
or do they have contact for you
actually do listeners have contact for you
before they send me like hey I want to apply it to Kodak's
I do have a contact forum at Lenny Richettsie.com
I'm afraid of all the amazing people
that are you paying me but there we could try that
let's see how that goes.
Yeah or another maybe an easier version we can edit all that out
or give up up to you but yeah or I would just say
you can drop us a DM for example
I'm Mboreko on Twitter and hit me up
if you're interested in joining the team.
What a dream job for someone.
many people, what's a sign they will, I don't know, what's like a way to filter people a little
bit so they're not flooding your inbox. So specifically if you want to join the Codex team,
then you need to be a technical person who uses these tools. And I think I would just ask yourself
the question, hey, let's say, you know, I were to join Open AI and work on Codex over the next six
months, you know, and crush it. What does the life of a software engineer look like then? And I think
if you have an opinion on that, you should apply. And if you don't have an opinion on that and have
to think about it first, you know, depending on how long you have to think about it, I guess,
that would be the filter, right? Like, I think there's a lot of people thinking about the space.
And so we're very interested in folks who sort of have already being thinking about, like,
what the future should look like with agents. And like, we don't have to agree on where we're going.
But I think we want people who, like, are very passionate about the topic, I guess.
It's very rare to be working on a product that has this much impact and is at such a bleeding edge of where it's possible.
It's what a cool role for the right person.
So it's awesome that you have an opening and this audience is a really good fit potentially for that role.
So I hope we find someone that would be incredible.
With that, we've reached our very exciting lightning round.
I've got five questions for you, Alexander.
Are you read?
I don't know what these are, but I'm excited.
Let's do it.
They're the same questions ask everyone except for the last one.
So probably not a surprise.
I should probably make them more often a surprise.
Okay, first question, what are a couple books that you recommend most to other people,
two or three books that come to mind?
I have been reading a lot of science fiction recently,
and I'm sure this has been recommended before, but the culture,
I think it's Ian Banks is the name of the author.
Part of why I love it is because it's like basically relatively,
recent writing about a future with AI, but it's an optimistic future with AI.
And I think a lot of sci-fi is like fairly dystopian.
But this is like people, sort of the joke at least on the culture subreddit is that
let me see if I can get this right. It is a like space communist utopia or like I think
it's a gay space communist utopia. And I just think it's like really fun to think about
like to use the culture as a way to think about like what kind of world can we usher in and like what decisions can we make today to help usher in that world.
Wow. I don't think anyone's recommended that. I know you're reading you mentioned before I started recording Lord of the Rings right now.
If you want another AI-ish sci-fi book, have you read Fire Upon the Deep?
No, I haven't.
Okay. It's incredibly good. It's like a sci-fi space opera sort of epic tale with super intelligence.
Cool. Yeah, somewhat
mostly not optimistic, but somewhat optimistic.
Okay, next question.
Is there a favorite recent movie or TV show that you've really enjoyed?
Yeah, there's an anime called Jiu-Zikaisen, which I really like.
Again, it's got kind of a slightly dark topic of like demons.
But what I love about it is that the hero is really nice.
And I think there's this new wave of like anime and cartoons where the protagonists are
really friendly and like people who care about the world
rather than being like sort of like
if you look at like some older anime like that started the genre
like you know those there's like Evangelion or Akita
and like those characters the protagonists are like deeply flawed
like quite unhappy
they didn't start the genre but it was like a trend for a while
to sort of poke fun at the idea that in these in these cartoons
the protagonist was very young but being given a ridiculous amount of
responsibility to like save the world. And so there was kind of a wave of like,
content that was like critiquing this by making the character like basically go
through like serious like mental issues in the middle of the show. And I'm not saying
this is better, but at least it's quite fun to have like these like really positive protagonists
are just trying to help everyone around them. I love how much we're learning about your
personality hearing these recommendations. Nice protagonists, optimistic futures. I think, you know,
If you don't believe it, you can't roll it into existence.
So you need a balance.
This is your training data.
Is there a product you recently discovered that you really love?
Could be an app, could be some clothing, could be some kitchen gadget, tech gadget, a hat?
Yeah.
So I have been like quite into, you know, combustion engines and cars.
Actually, the reason I came to America initially was because I wanted to work on like U.S. aircraft.
But now I work in software.
And so for the longest time, I've basically only had quite old sports cars, old just because they were more affordable.
And then recently, we got a Tesla instead.
And I have to say that I find the Tesla software quite inspiring.
In particular, it has the self-driving teacher.
And I've mentioned a few times today, like, I think it's really interesting to think about how to build mixed
initiative software that makes you feel maximally empowered as a human,
maximally in control, but yet you're getting a lot of help.
And I think they did a really good job with enabling sort of the car to drive itself,
but all these different ways that you can adjust what it's doing without turning off the
soft driving.
So you can accelerate, you know, it'll like listen to that.
You can turn a knob to change its speed.
You can steer slightly.
I think it's actually a masterclass in like building an agent that still leaves the human
in control.
This reminds me Nick Turley's whole mantra was, are we maximally accelerated?
Yeah.
It feels like it's completely infiltrated everything at opening eye, which makes sense.
That tracks.
Two more questions.
Do you have a life motto that you often think about, come back to in work or in life that's been helpful?
I don't know if I have a life motto, but maybe I can tell you about the number one value, company value from my startup.
Love it.
Which is still something that sticks with me, which is to be kind and candid.
That tracks.
Kind and candid.
Wow.
Yeah.
And we had to put it together because we as founders realized that we often would be nice.
And it wasn't actually the right thing to do.
We would delay the difficult conversations and we were not candid.
And so every time we would like remind ourselves of this motto and then we would become more candid.
And then six months later, we would realize that we were in fact not candid six months ago.
and we need to be even more candid.
So then the question is like, okay, how should we be candid?
It was like, okay, well, let's think of being candid as an act of kindness,
but also think of that both in terms of doing it and willing ourselves to do it,
but also in terms of how we frame it's people.
That is a beautiful way of summarizing how to lead well.
What's the book about challenge directly, but care deeply?
Radical candor.
Yeah, yeah, yeah, right.
Yeah, so it's like another way of thinking about radical candor.
Okay, last question.
I was looking up your last name just like, hey, what's the story here? So your last name is
Ambirikos, and I was talking to Jad GPD, and it told me the most famous individuals with the surname
are the influential Greek poet and psychoanalyst Andreas Ambirikos and his relative, the wealthy
shipping magnate and art collector George Ambirikos. So the question is, which of these two do you
most identify with? The Greek poet and psychoanalyst, or the wealthy shipping magnate and art
collector. I think it's it's going to have to be the poet because he uh he loved the island that
our families from. Wait, you know those city people. Okay. This is not news to you. Okay. Well, I mean,
it's an enormous family, but it's like Greek. So, you know, these big families, everyone's,
like everyone's your uncle. You know what I mean? Like my mother's Malaysian and also like everyone is
my uncle or aunt in Malaysia too, if that makes sense. Yeah. But yeah, he he loved this island that the
family sort of like initiated from. I believe I don't actually know where that's
shipping magnate lived. I think it was New York or something. But anyway, we all came from
this island called Andros, which is a really beautiful place. And it's like there's
more like livestock there than, than humans. Not too many tourists go there. But I
think he like part of what I think is really cool is like he published a lot and a lot of
his writing is about like the beauty of that island, which I think is super cool. Wow.
That was an amazing answer. Two more questions. Where can folks find you if they want
follow you online and maybe reach out and then how can listeners be useful to you?
I'm one of those people who has social media only for the purposes of having work.
You know my phone turns black and white at like 9 p.m. at night.
But yeah, so Twitter or X at NBrico.
And yeah, if you post in R slash codex, I'll probably see it.
So you can go there.
How can listeners be useful?
I would say please try codex.
Please share feedback.
Let us know what to improve.
We pay a ton of attention to feedback.
I think it's like, honestly, like, the growth has been amazing, but it's still very early times.
So we still pay a lot of attention and hope to do so forever.
And also, I would say, if you're interested in working on the future of coding agents and then agents generally, then please apply to our job site and or message me in those social media places.
Alexander, this was awesome.
I always love meeting people working on AI because it always feels like this very very.
I don't know, sterile, scary, mysterious thing.
And then you meet the people building these tools.
And they're always just so awesome.
And you especially, just so nice.
And as you, like the examples, you shared,
optimism and kindness, you know, this is what we want to be.
These are the kinds of people we want to be building these tools that are going to drive
the future.
So I'm really thankful that you did this.
I'm grateful to have met you.
And thank you so much for being here.
Yeah.
Thanks so much for having.
This is fun.
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 Lenny's Podcast.com.
See you in the next episode.
