100% of my code is written by quad code.

I have not edited a single line by hand

since November. Every day I ship 10, 20,

30 p requests. So at the moment I have

like five agents running while we're

recording this.

>> Yeah. Yeah. Do you miss writing code?

>> I have never enjoyed coding as much as I

do today because I don't have to deal

with all the minutia. Productivity per

engineer has increased 200%.

>> There's always this question, should I

learn to code? In a year or two, it's

not going to matter. Coding is largely

solved. I imagine a world where everyone

is able to program. Anyone can just

build software anytime. What's the next

big shift to how software is written?

>> Quad is starting to come up with ideas.

It's looking through feedback. It's

looking at bug reports. It's looking at

telemetry for bug fixes and things to

ship a little more like a co-orker or

something like that.

>> A lot of people listening to this are

product managers and they're probably

sweating. I think by the end of the

year, everyone's going to be a product

manager and everyone codes. The title

software engineer is going to start to

go away. It's just going to be replaced

by builder and it's going to be painful

for a lot of people.

Today my guest is Boris Churnney, head

of Claude Code at Anthropic. It is hard

to describe the impact that Claude Code

has had on the world. Around the time

this episode comes out will be the

one-year anniversary of Claude Code. And

in that short time, it has completely

transformed the job of a software

engineer and it is now starting to

transform the jobs of many other

functions in tech which we talk about.

Cloud code itself is also a massive

driver of anthropic overall growth over

the past year. They just raised a round

at over $350 billion. And as Boris

mentions, the growth of Claude Code

itself is still accelerating. Just in

the past month, their daily active users

has doubled. Boris is also just a really

interesting, thoughtful, deepinking

human. And during this conversation, we

discover we were born in the same city

in Ukraine. That is so funny. I had no

idea. A huge thank you to Ben Man, Jenny

Wen, and Mike Griger for suggesting

topics for this conversation. Don't

forget to check out lennisprodpass.com

for an incredible set of deals available

exclusively to Lenny's newsletter

subscribers. Let's get into it after a

short word from our wonderful sponsors.

Today's episode is brought to you by DX,

the developer intelligence platform

designed by leading researchers. To

thrive in the AI era, organizations need

to adapt quickly. But many organization

leaders struggle to answer pressing

questions like which tools are working?

How are they being used? What's actually

driving value? DX provides the data and

insights that leaders need to navigate

this shift. With DX, companies like

Dropbox, Booking.com, Adion, and

Intercom get a deep understanding of how

AI is providing value to their

developers and what impact AI is having

on engineering productivity. To learn

more, visit DX's website at

getdx.com/lenny.

That's getdx.com/lenny.

Applications break in all kinds of ways.

Crashes, slowdowns, regressions, and the

stuff that you only see once real users

show up. Sentry catches it all. See what

happened where, and why, down to the

commit that introduced the error, the

developer who shipped it, and the exact

line of code all in one connected view.

I've definitely tried the five tabs and

Slack thread approach to debugging. This

is better. Sentry shows you how the

request moved, what ran, what slowed

down, and what users saw. Seir, Sentry's

AI debugging agent, takes it from there.

It uses all of that Sentry context to

tell you the root cause, suggest a fix,

and even opens a PR for you. It also

reviews your PR and flags any breaking

changes with fixes ready to go. Try

Sentry and SER for free at

centry.io/lenny

and use code Lenny for $100 in Sentry

credits. That's s n t r y.io/lenny.

Boris, thank you so much for being here

and welcome to the podcast.

>> Yeah, thanks for having me on.

>> I want to start with a a spicy question.

About 6 months ago, I don't know if

people even remember this, you actually

left Anthropic. You joined Curser and

then two weeks later, you went back to

Anthropic. What happened there? I don't

think I've ever heard the actual story.

It's the fastest job change that I've

ever had.

Um, I joined Cursor because I'm a big

fan of the product and honestly I met

the team and I was just really

impressed. Uh, they're an awesome team.

Uh, I still I still think they're

awesome and they're just building really

cool stuff and kind of they they saw

where AI coding was going I think before

a lot of people did. So the idea of

building good product was just very

exciting for me. I think as soon as I

got there, what I started to realize is

what I really missed about Ant was the

mission. And that's actually what

originally drove me to Ant also cuz uh

but before I joined Anthropic, I was,

you know, I was working in big tech and

then I was at some point I wanted to

work at a at a lab to just help shape

the future of this crazy thing that that

we're building in some way. And the

thing that drew me to anthropic was the

mission. And it was, you know, it's all

about safety. And when you talk to

people at Enthropic, just like find

someone in the hallway, if you ask them

why they're here, the answer is always

going to be safety. Um, and so this kind

of like missiondrivenness just really

really resonated with me. And I just

know personally it's something I need in

order to be happy. Um, and I that's just

a thing that I really missed. And I

found that, you know, whatever the work

might be, no matter how exciting, even

if it's building a really cool product,

it's just not really a substitute for

that. Um, so for me it was actually u it

was pretty obvious that that I was

missing that pretty quick.

>> Okay. So let me follow the thread of

just coming back to anthropic and the

work you've done there. This podcast is

going to come out around the year

anniversary of launching cloud code. So

I'm going to spend a little time just

reflecting on the impact that you've

had. There's um this report that

recently came out that I'm sure you saw

by semi analysis that showed that 4% of

all GitHub commits are authored by cloud

code now. and they predicted it'll be a

fifth of all code commits on GitHub by

the end of the year. The way they put it

is while we blinked, AI consumed all

software development.

The day that we're recording this,

Spotify just put out this uh headline

that their best developers haven't

written a line of code since December

thanks to AI. More and more of the most

advanced senior engineers, including

you, are sharing the fact that you don't

write code anymore, that it's all AI

generated. and many aren't even looking

at code anymore is how far we've gotten

in large part thanks to this little

project that you started and that your

team has scaled over the past year. I'm

curious just to hear your reflections on

on this past year and the impact that

your work has had. These numbers are

just totally crazy, right? Like four 4%

of all commits in the world is just way

more than I imagined and like like you

said, it still feels like the starting

point. Um these are also just public

commits. So we actually think if you

look at private repositories, it's quite

a bit higher than that. And I I think

the craziest thing for me isn't even the

number that we're at right now, but the

pace at which we're growing because if

you look at Quad Code's growth rate kind

of across any metric, it's continuing to

accelerate. Um so it's not just going

up, it's going up faster and faster.

When I first started Quad Code, it was

just going to be a like it was just

supposed to be a little hack. Um you

know we we broadly knew at Enthropic

that we wanted to get a we wanted to

ship some kind of coding product and you

know for enthropic for a long time we

were building the models in this way

that kind of fit our mental model of the

way that we build safe hi where the

model starts by being really good at

coding then it gets really good at tool

use then it gets really good at computer

use roughly this is like the trajectory

uh and you know we've been working on

this for a long time and when you look

at the team that I started on it was

called the anthropic labs team uh and

actually Mike Kger and you know Ben man

they just kicked this team off again uh

for kind of round two the team built

some pretty cool stuff so we built quad

code we built MCP we built the desktop

app so you can kind of see the seeds of

this idea you know like it's coding then

it's tool use then it's computer use and

the reason this matters for anthropic is

uh because of safety it's kind of again

just back to that AI is getting more and

more powerful it's getting more and more

capable the thing that's happened in the

last year is that for at least For

engineers, the AI doesn't just write the

code. It it's not just a conversation

partner, but it actually uses tools. It

acts in the world. Um, and I think now

with co-work, we're starting to see the

transition for non-technical folks also.

Um, for a lot of people that use

conversational AI, this might be the

first time that they're using the thing

that actually acts. It can actually use

your Gmail, it can use your Slack, it

can do all these things for you and it's

quite good at it. Um, and it's only

going to get better from here. So I

think for anthropic for a long time

there was this feeling that we wanted to

build something but it wasn't obvious

what and so uh when I joined ant I spent

one month kind of hacking and you know

built a bunch of like weird prototypes

most of them didn't ship and you know

weren't even close to shipping it was

just kind of understanding the

boundaries of what the model can do then

I spent a month doing post- training um

so to understand kind of the research

side of it and I think honestly that's

just for me as an engineer I find that

to do good work you really have to

understand the layer under the layer at

which you work. And with traditional

engineering work, you know, if you're

working on product, you want to

understand the infrastructure, the

runtime, the virtual machine, the

language kind of whatever that is, the

system that you're building on. But, uh,

yeah, if you're like if you're working

in AI, you just really have to

understand the model to some degree to

to do good work. So, I took a little

detour to do that and then I came back

and just started prototyping what

eventually became quad code. Uh, and the

very first version of it, I I have like

a there's like a video recording of the

summer because I recorded this demo and

I posted it. It was called QuadCLI back

then. And I just kind of showed off how

it used a few tools and the shocking

thing for me was that I gave it a batch

tool and uh it just was able to use that

to write code to tell me what music I'm

listening to when I asked it like what

music am I listening to? And this is the

craziest thing, right? cuz it's like

there's no we I I didn't instruct the

model to say, you know, use, you know,

this tool for this or kind of do

whatever. The model was given this tool

and I figured out how to use it to

answer this question that I had that I

wasn't even sure if it could answer.

What music am I listening to?

And so I I I started prototyping this a

little bit more. Um I made a post about

it and I announced it internally and it

got two likes. That's the that was that

was the extent of the reaction at the

time because I think people internally

you know like when you think of coding

tools you think of like you think of IDE

you think about kind of all these pretty

sophisticated environments no one

thought that this thing could be

terminal based um that's sort of a weird

way to design it and that wasn't really

the intention but uh you know from the

start I built it in a terminal because

you know for the first couple months it

was just me so it was just the easiest

way to build uh and for me this is

actually a pretty important product

lesson right is like you want to

underresource things a little bit at the

start. Then we started thinking about

what other form factors we should build

and we actually decided to stick with

the terminal for a while and the biggest

reason was the model is improving so

quickly. We felt that there wasn't

really another form factor that could

keep up with it. And honestly this was

just me kind of like struggling with

kind of like what should we build you

know like for the last year quad code

has just been all I think about. And so

just like late at night, this is just

something I was thinking about like,

okay, the model is continuing to

improve. What do we do? How can we

possibly keep up? And the terminal was

honestly just the only idea that I had.

And uh yeah, it ended up catching on

after after I released it pretty

quickly. It became a hit at Anthropic

and you know, the the daily active users

just went vertical. And really early on,

actually before I launched it, Ben man

uh nudged me to make a DAU chart and I

was like, you know, it's like kind of

early maybe, you know, should we really

do it right now? and he was like,

"Yeah." And so the the chart just went

vertical pretty immediately. Uh and then

in February, we released it externally.

Actually, something that people don't

really remember is Quad Code was not

initially a hit when we released it. It

it got a bunch of users. There was a lot

of early adopters that got it

immediately, but it actually took many

months for everyone to really understand

what this thing is. Just again, it's

like it's just so different. And when I

think about it, kind of part of the

reason quad code works is this idea of

latent demand where we bring the tool to

where people are and it makes existing

workflows a little bit easier, but also

because it's it's in a terminal. It's

like a little surprising. It's a little

alien in this way. So you have to you

have to kind of be open-minded and you

had to learn to use it. And of course

now you know quad code is available you

know in the iOS and Android quad app.

It's available in the desktop app. It's

available on the website. It's available

as IDE extensions in Slack and GitHub.

you know all these places where

engineers are it's a little more

familiar but that wasn't the starting

point

so yeah I mean at the beginning it was

kind of a surprise that this thing was

even useful and uh you know as the team

grew as the product grew as it started

to become more and more useful to people

just people around the world from you

know small startups to the biggest fang

companies started using it and they

started giving feedback and I think just

reflecting back it's been such a

humbling experience cuz we just we keep

learning from our users and just the

most exciting thing is like you know

none of us really know what we're doing.

Um and we're just trying to figure out

along with everyone else and the single

best signal for that is just feedback

from users. Um so that's just been the

best I' I've been surprised so many

times. It's incredible how fast

something can change in today's world.

You launched this a year ago and it

wasn't the first time people could use

AI to code but uh in a year the entire

profession of software engineering has

dramatically changed like there's all

these predictions oh AI is going to be

written 100% AI's code is going to be

written by AI everyone's like no that's

crazy what are you talking about now

it's like

>> of course it's happening exactly as they

said it's just so things move so fast

and change so fast now

>> yeah it's really fast back at uh back at

code with quad back in May that was like

our first uh you know like developer

conference that we did as Enthropic. Um

I did a short talk and in the Q&A after

the talk people were asking what are

your predictions for the end of the year

and my prediction back in May of 2025

was by the end of the year you might not

need an ID to code anymore and we're

going to start to see engineers not

doing this and I remember the room like

audibly gasped. It was such a crazy

prediction but I think like at anthropic

like this is just the way the way we

think about things is exponentials and

this is like very deep in the DNA. Like

if you look at our co-founders like

three of them were the first three

authors on the scaling laws paper. Um so

we really just think in exponentials and

if you kind of look at the exponential

of the percent of code that was written

by quad at that point if you just trace

the line it's pretty obvious we're going

to cross 100% by the end of the year

even if it just does not match intuition

at all. Um, and so all I did was trace

the line and yeah, in November that, you

know, that happened for me personally

and that's been the case since and we're

starting to see that for a lot of

different customers too. I thought was

really interesting what you just shared

there about kind of the journey is this

kind of idea of just playing around and

seeing what happens. This came up comes

up with open claw a lot just like Peter

was playing around and just like a thing

happen. And it feels like that's a

central kind of ingredient to a lot of

the biggest innovations in AI is people

just sitting around trying stuff to

pushing the models further than most

other people.

>> I mean this the thing about innovation

right like you can't uh you can't force

it. There's no road map for innovation.

Um you just have to give people space.

You have to give them maybe the word is

like safety. So it's like psychological

safety that it's okay to fail. It's okay

if 80% of the ideas are bad. Um you also

have to hold them accountable a bit. So

if the idea is bad, you you know you cut

your losses, move on to the next idea

instead of investing more. Uh in the

early days of quad code, I had no idea

that this thing would be useful at all.

Cuz even in February when we released

it, it was writing maybe I don't know

like 20% of my code, not more. And even

in May, it was writing maybe 30%. I was

still using you know curtzer for most of

my code. And it only crossed 100% in

November. So it took a while. But even

from the earliest day, it just felt like

I was on to something. And I was just

spending like every night, every weekend

hockey on this. And luckily my, you

know, my wife was very supportive. Um,

but it it just felt like it was on to

something. It wasn't obvious what. And

and sometimes, you know, you find a

thread, you just have to pull on it.

>> So at this point, 100% of your code is

written by cloud code. Is that is that

kind of the current state of your

coding?

>> Yeah. So 100% of my code is written by

cloud code. Um, I am a fairly prolific

coder. Um, and this has been the case

even when I worked back at Instagram. I

was like one of the top few most

productive engineers. Um and that's

actually that's still the case uh here

at Anthropic.

>> Wow. Even as head of head of the team.

>> Yeah. Yeah. Do still do a lot of coding.

Um and so every you know every day I

ship like 10 20 30 p requests something

like that

>> every day.

>> Every day. Yeah.

>> Good god.

>> Uh 100% written by quad code. I have not

edited a single line by hand since uh

November.

And yeah, that that's been it. I do look

at the code. So I I don't think we're

kind of at the point yet where you can

be totally hands-off, especially when

there's a lot of people, you know, like

running the program. You have to make

sure that it's correct. You have to make

sure it's safe and so on. Um, and then

we also have Quad doing automatic code

review for everything. Um, so here at

Enthropic, Quad reviews 100% of poll

requests. Um, there's still layer of

like human review after it, but you kind

of like you still do want some of these

checkpoints like you still want a human

looking at the code. um unless it's like

pure prototype code that you know it's

not going to run it's not going to run

anywhere it's just a prototype.

>> What's kind of the next frontier? So at

this point 100% of your code is being

written by AI. This is clearly where

everyone is going in software

engineering. That felt like a crazy

milestone. Now it's just like of course

this is the world now. What's what's

kind of the next big shift to how

software is written that either your

team's already operating in or you think

will head towards? I think something

that's happening right now is Quad is

starting to come up with ideas. Um so

Quad is looking through feedback. It's

uh looking at bug reports. It's looking

at um you know like telemetry and and

things like this and it's starting to

come up with ideas for bug fixes and

things to ship. So it's just starting to

get a little more um you know like a

little more like a co-orker or something

like that. I think the second thing is

we're starting to branch out of coding a

little bit. So I think at this point

it's safe to say that coding is largely

solved. At least for the kind of

programming that I do, it's just a

solved problem because quad can do it.

And so now we're starting to think about

okay like what's next? What's beyond

this? There's a lot of things that are

kind of adjacent to coding. Um and I

think this is going to be coming. But

also just you know general tasks, you

know, like I use co-work every day now

to do all sorts of things that are just

not related to coding at all and just to

do it automatically. Like for example, I

had to pay a parking ticket the other

day. I just had co-work do it. um all of

my project management for the team uh

co-work does all of it. It's like

syncing stuff between spreadsheets and

messaging people on Slack and email and

all this kind of stuff. So I think the

frontier is something like this and I I

don't think it's coding because I think

coding is you know it's pretty much

solved and over the next few months I

think what we're going to see is just

across the industry it's going to become

increasingly solved you know for every

kind of codebase every tech stack that

people work on.

>> This idea of helping you come up with

what to work on is so interesting. A lot

of people listening to this are product

managers and they're probably sweating.

How do you use Claude for this? Do you

just talk to it? Is there anything

clever you've come up with to help you

use it to come up with what to build?

>> Honestly, the simplest thing is like

open quad code or co-work and point it

at a Slack thread. Um, you know, like

for us, we have this channel that that's

all the internal feedback about Quad

Code. Since we first released it, even

in like 2024 internally, it's just been

this fire hose of feedback. Um, and it's

the best. And like in the early days,

what I would do is anytime that someone

sends feedback, I would just go in and I

would fix every single thing as fast as

I possibly could. So like within a

minute, within 5 minutes or whatever.

And this just really fast feedback

cycle, it encourages people to give more

and more feedback. It's just so

important cuz it makes them feel heard

cuz you know like usually when you use a

product, you give feedback, it just goes

into a black hole somewhere and then you

don't give feedback again. So if you

make people feel heard, then they want

to contribute and they want to help make

the thing better. Um, and so now I kind

of do the same thing, but Quad honestly

does a lot of the work. So I pointed at

the channel and it's like, "Okay, here's

a few things that I can do. I just put

up a couple PRs. Want to take a look at

that one?" I'm like, "Yeah." Have you

noticed that it is getting much better

at this? Because this is kind of the

holy grail, right? Now it's like, "Cool,

building solved." Code review became

kind of the next bottleneck. All these

PRs, who's going to review them all? The

next big open question is just like,

okay, now we need to now now humans are

necessary for figuring out what to

build, what to prioritize. And you're

saying that that's where claude code is

starting to help you. Has it has it

gotten a lot better with like say Opus

46 or what's been the trajectory there?

>> Yeah. Yeah, it's improved a lot. Um I

think some of it is kind of like

training that we do specific to coding.

Um so you know obviously you know best

coding model in the world and you know

it's getting better and better like 4.6

is just incredible but also actually a

lot of the training that we do outside

of coding translates pretty well too. So

there is this kind of like transfer

where you teach the model to do you know

X and it kind of gets better at Y. Um

yeah and the the gains have just been

insane like at anthropic over the last

year like since we introduced quad code

we probably I don't know the exact

number we probably like 4x the

engineering team or something like this

but productivity per engineer has

increased 200%.

in terms of like pull requests and like

this number is just crazy for anyone

that actually works in the space and

works on deaf productivity because back

in a previous life I was at Meta and you

know one of my responsibilities was code

quality for the company. So this is like

the all of our code bases that was my

responsibility like Facebook, Instagram,

WhatsApp all this stuff. Um and a lot of

that was about productivity because if

you make the code higher quality then

engineers are more productive and things

that we saw is you know in a year with

hundreds of engineers working on it you

would see a gain of like a few

percentage points of productivity

something like this. Um and so nowadays

seeing these gains of just hundreds of

percentage points it's is just

absolutely insane. What's also insane is

just how normalized this has all been

like we hear these numbers like of

course AI is doing this to us. It's just

it's so unprecedented the amount of

change that is happening to software

development to building products to just

this the world of tech. It's just like

so easy to get used to it. But it's

important to recognize this is crazy.

This is something like I have to remind

myself once in a while. There's sort of

like a downside of this because the

model changes so well there's actually

like there's many kind of downsides that

that we could talk about but I think one

of them on a personal level is the model

changes so often that I sometimes get

stuck in this like old way of of

thinking about it and I even find that

like new people on the team or even new

grads that join do stuff in a more kind

of like AGI forward way than I do. So

like sometimes for example I I I had

this case like a couple months ago where

there was a memory leak and so like what

this is is you know like quad code the

memory usage is going up and at some

point it crashes. This is like a very

common kind of engineering problem that

you know every engineer has debugged a

thousand times and traditionally the way

that you do it is you take a heap

snapshot you put it into a special

debugger you kind of figure out what's

going on you know use these special

tools to see what's happening. Um, and I

was doing this and I was kind of like

looking through these traces and trying

to figure out what was going on. And the

engineer that was newer on the team just

uh had Quad Code do it and was like,

"Hey Quad, it seems like there's a leak.

Can you figure it out?" And so like Quad

Code did exactly the same thing that I

was doing. It it took the heap snapshot.

It wrote a little tool for itself so it

can kind of like analyze it itself. Um,

it was sort of like a just in time

program. Uh, and it found the issue and

put up a pull request faster than I

could. So it's it's something where like

for those of us that have been using the

model for a long time, you still have to

kind of transport yourself to the

current moment and not get stuck back in

an old model because it's not sonnet 3.5

anymore. The new models are just

completely completely different. Uh and

just this this mindset shift is is very

different. I hear you have these very

specific principles that you've codified

for your team that when people join you

you kind of walk them through them. I

believe one of them is what's better

than doing something having Claude do

it. And it feels like that's exactly

what you describe with this memory leak

is just like you almost forgot that

principle of like okay let me see if

Claude can solve this for me. There's

this uh there's this interesting thing

that happens also when you um when you

underfund everything a little bit uh

because then people are kind of forced

to clify and this is something that we

see. So you know for work where

sometimes we just put like one engineer

on a project and the way that they're

able to ship really quickly because they

want to ship quickly. This is like an

intrinsic motivation that comes from

within is just wanting to do a good job.

One if you have a good idea you just

really want to get it out there. No one

has to force you to do that. That comes

from you. Um and and so if you have

claude, you can just use that to

automate a lot of work. Uh and that

that's kind of what we see over and

over. So I think that's kind of like one

principle is underfunding things a

little bit. I think another principle is

just encouraging people to go faster. So

if you can do something today, you

should just do it today. And this is

something we we really really encourage

on the team. Early on it was really

important because it was just me and so

our only advantage was speed.

that's the only way that we could ship a

product that would compete in this very

crowded coding market. But nowadays,

it's still very much a principle we have

on the team. And if you want to go

faster, a really good way to do that is

to just have Claude do more stuff. Um,

so he it just very much encourages that.

This idea of underfunding, it's so

interesting because in general there's

this feeling like AI is going to allow

you to not have as many employees, not

have as many engineers. And so it's not

only you can be more productive. What

you're saying is that you will actually

do better if you underfund. It's not

just that AI can make you faster. It's

you will get more out of the AI tooling

if you have fewer people working on

something. Yeah. If you if you hire

great engineers, they'll figure out how

to do it. And uh especially if you

empower them to do it. This is something

I actually talk talk a lot about with uh

you know with like CTO's and kind of all

sorts of companies. My advice generally

is don't try to optimize. Don't don't

try to cost cut at the beginning. Start

by just giving engineers as many tokens

as possible. And now now you're starting

to see companies like you know at

Anthropic we have you know everyone can

use a lot of tokens. We're starting to

see this come up as like a perk at some

companies. Like if you join you get

unlimited tokens. This is a thing I very

much encourage because um it makes

people free to try these ideas that

would have been too crazy and then if

there's an idea that works then you can

figure out how to scale it and that's

the point to kind of optimize and to

cost cut figure out like you know maybe

you can do it with haiku or with sonnet

instead of opus or whatever but at the

beginning you just want to throw a lot

of tokens at it and see if the idea

works and give engineers the freedom to

do that. So the advice here is uh just

be be loose with your tokens with this

the cost on on using these models.

People hearing this may be like of

course he works at Anthropic. He wants

us to use as many tokens as possible.

But you're what you're saying here is

the the most interesting innovative

ideas will come out of someone just kind

of taking it to the max and seeing

what's possible.

>> Yeah. And I and I think the reality is

like at small scale like you know you're

not going to get like a giant bill or

anything like this. Like if it's an

individual engineer experimenting, it's

the token cost is still probably

relatively low relative to their salary

or you know other costs of running the

business. So it it's actually like not

not a huge cost as the thing scales up.

So like let's say you know they build

something awesome and then it takes a

huge amount of tokens and then the cost

becomes pretty big. That's the point at

which you want to optimize it. But don't

don't do that too early.

>> Have you seen companies where their uh

token cost is higher than their salary?

Is that a trend you think we're going to

find and see?

>> You know, at Anthropic, we're starting

to see some engineers that are spending,

you know, like hundreds of thousands a

month in in tokens. Um, so we're

starting to see this a little bit. Um,

there's some companies that are we're

starting to see similar things. Yeah.

>> Going back to coding, do you miss

writing code? Is this something you're

kind of sad about that this is no longer

a thing you will do as a software

engineer? It's funny for me, you know,

like when when I learned engineering,

for me it was very practical. I learned

engineering so I could build stuff

and for me I was I was selftaught, you

know, like I studied economics in

school, but um I didn't study CS, but I

I taught myself engineering kind of

early on. I was programming in like

middle school and from the very

beginning it was very practical. So I

actually like I learned to code so that

I can cheat on a math test. That was

like the first thing we had these like

graphing calculators and you know I just

programmed the answer into

>> TI83.

>> T83 plus. Yeah. Yeah. Exactly.

>> Plus. Yeah. So like I programmed the

answers in and then the next like math

test whatever like the next year that it

was just like too hard. Like I couldn't

program all the answers in because I

didn't know what the questions were. And

so I had to write like a little solver

so that it it was a program that would

just like solve these like uh you know

these al algebra questions or whatever.

And then I figured out you can get a

little cable, you can give the program

to the rest of the class and then the

whole class gets A's. But then we all

got caught and the teacher told us to

knock it off. But from the very

beginning it's it's always just been

very practical for me where programming

is a way to build a thing. It's not the

end in itself.

At some point I personally fell into the

rabbit hole of kind of like the the

beauty of of programming. Um so like I I

wrote a book about TypeScript. Um, I

started the actually at the time it was

the world's biggest uh, TypeScript

meetup just because I fell in love with

the language itself. Uh, and I kind of

got in deep into like functional

programming and and all this stuff. I

think a lot of coders they get

distracted by this. For me, it was

always sort of um they there is a beauty

to programming and especially to

functional programming. There's a beauty

to type systems. Um, there there's a

certain kind of like this like buzz that

you get like when you solve like a

really a really complicated uh math

problem. It's kind of similar when you

kind of balance the types or you know

the program is just like really

beautiful but it's really not the end of

it. Um I think for me coding is very

much a tool and it's a way to do things.

Uh that said not everyone feels this

way. So for example you know like

there's one engineer uh on the team Lena

who you know was still writing C++ on

the weekends by hand because you know

for her she just really enjoys writing

C++ by hand. And so everyone is

different and I think even as this field

changes, even as everything changes,

there's always space to do this, there's

always space to enjoy the art um and to

and and to kind of do do things by hand

uh if you want.

>> Do you worry about your skills atrophing

as an engineer? Is that something you

worry about or is it just like, you

know, this is just the way it's going to

go?

>> I think it's just the way that that it

happens. I I don't worry about it too

much personally. I think for me like

programming is on is on a continuum and

you know like way back in the day you

know like software actually is like

relatively new right like if you look at

the way programs are written today like

using software that's running on a

virtual machine or something this has

been the way that we've been writing

programs since probably the 1960s so you

know it's been you know like 60 years or

something like that. Before that it was

punch cards. Before that it was

switches. Before that it was hardware.

And before that it was just you know

like literally pen and paper. It was

like a room a room full of people that

were doing math on on paper. And so, you

know, programming has always changed in

this way. In some ways, you still want

to understand the layer under the layer

because it helps you be a better

engineer. And I think this will be the

case maybe for the next year or so. Um,

but I think pretty soon it just won't

really matter. It's just going to be

kind of like the the assembly code wring

running under the programmer or

something like this.

uh at an emotional level, you know, I I

feel like I've always had to learn new

things. And as a programmer, it's

actually not it doesn't feel that new

because there's always new frameworks,

there's always new languages. It's just

something that we're quite comfortable

with in the field. But at the same time,

I you know, this isn't true for

everyone. And I think for some people,

they're going to feel a greater sense

of, I don't know, maybe like loss or

nostalgia or atrophy or something like

this. I don't know if you saw this, but

Elon was saying that uh why isn't the AI

just writing binary straight to binary?

Uh because what's the point of all this,

you know, programming abstraction in the

end?

>> Yeah, it's a good question. I mean, it

totally can do that if you wanted to.

>> Oh, man. So, what I'm hearing here is in

terms there's always this question,

should I learn to code? Should people in

school learn to code? Uh what I heard

from you is your take is in like a year

or two, you don't really need to. My

take is I think for for people that are

using um there that are using quad code

that are using agents to code today you

still have to understand the layer under

but yeah in a year or two it's not going

to matter. I I was thinking about um

what is the right like historical analog

for this cuz like like somehow we have

to situate this thing in history and and

kind of figure out when have we gone

through similar transitions. What's the

right kind of mental model for this? I

think the thing that's come closest for

me is the printing press. And so you

know if you look at Europe in uh you

know like in the in the mid the mid400s

literacy was actually very low. Uh there

was sub 1% of the population it was

scribes that uh you know they were the

ones that did all the writing. They they

were the ones that did all the reading.

They were employed by like lords and

kings that often were not literate

themselves. And so you know it was their

job of this very tiny percent of the

population to do this. And at some point

the you know Gutenberg and and the

printing press came along and there was

this crazy stat that in the 50 years

after the printing press was uh built

there was more printed material created

than in the c in the in the thousand

years before

and so the the volume of printed

material just went way up. Uh the cost

went way down. It went down something

like 100x over the next 50 years. And if

you look at literacy, you know, it

actually took a while because learning

to read and write is, you know, it's

quite hard. It takes an education

system. It takes free time. You it takes

like not having to work on a farm all

day so that you actually have time for

education and things like this. But over

the next 200 years, it went up to like

70% globally. So I think this is the

kind of thing that we might see is a

similar kind of transition. And there

was uh there was actually this

interesting um historical document where

there was an interview with some like

scribe in the 1400s about like how do

you feel about the printing press? And

they were actually very excited because

they were like actually the thing that I

don't like doing is copying between

books. The thing that I do like doing is

drawing the art in books and then doing

the book binding. And I'm really glad

that now my time is freed up. And it's

interesting like as an engineer I sort

of felt like a peril with this. It's

like this is sort of how I feel where I

don't have to do the tedious work

anymore of coding because this has

always been sort of the detail of it.

It's always been the tedious part of it

and kind of like messing with like git

and kind of using all these different

tools. That that was not the fun part.

The fun part is figuring out what to

build and coming up with this. It's uh

it's talking to users. It's thinking

about these big systems. It's thinking

about the future. It's collaborating

with you know other people on the team.

And that's what I get to do more of now.

And what's amazing is that the tool

you're building allows anybody to do

this. People that have no technical

experience can do exactly what you're

describing. Like I'm I've been doing a

bunch of random little projects and any

it's just like anytime you get stuck

just like help me figure this out and

you get on block. Like I used to I was

an engineer for early in my career for

10 years and I just remember spending so

much time on like libraries and

dependencies and things and just like oh

my god what do I do and then looking on

stack overflow and now it's just like

help me figure this out and here's step

by step one two three four okay we got

this.

>> Yeah exactly exactly I was talking to an

engineer earlier today they're like

they're writing some service and go and

you know it's been like a month already

and they they built up the service like

it's working quite well and then I was

like okay so like how do you feel

writing it? He was like, you know, like

I I still don't really know Go, but

and I think we're going to start to see

more and more of this. It's like if you

know that it works correctly and

efficiently, then you you don't actually

have to know all the details. Clearly,

the life of a software engineer has

changed dramatically. It's like a whole

new job now as of the past year or two.

What do you think is the next role that

will be most impacted by AI within

either within tech like you know product

managers, designers or even outside tech

just like what do you think where do you

think AI is going next?

>> I think it's going to be a lot of the

roles that are adjacent to engineering.

Um so yeah it could be like product

managers, it could be design, could be

data science. It is going to expand to

pretty much any kind of work that you

can do on a computer because the model

is just going to get better and better

at this. Um, and you know, like this is

the co-work product is kind of the first

way to get at this, but it's just the

first one. And

it's the thing that I think brings AI to

a agentic AI to people that haven't

really used it before, and people are

starting just to to to get a sense of it

for the first time. When I think back to

engineering a year ago, no one really

knew what an agent was. No one really

used it. But nowadays, it's just the way

that, you know, we do we do our work.

And then when I look at non-technical

work today um so you know like or maybe

semi-technical like product work and you

know like data science and things like

this when you look at the kinds of AI

that people are using it's all it's

always these like conversational AI it's

like a chatbot or whatever but no one

really has used an agent before and this

word agent just gets thrown around all

the time and it's just like so misused

it's like lost all meaning but agent

actually has like a very specific

technical meaning which is it's a it's a

AI it's a LM that's able to use tools.

So it doesn't just talk, it can actually

act and it can interact with your system

and you know this means like it can use

your Google docs and it can it can send

email. It can run commands on your

computer and do all this kind of stuff.

So I think like any kind of job where

you do you use computer tools in this

way. I think this is going to be next.

This is something we have to kind of

figure out as a as a society. This is

something we have to figure out as an

industry. Um and I think for me also

this is one of the reasons it it feels

very important and urgent to do this

work at anthropic because I think we

take this very very seriously. Um and so

now you know we have economists we have

uh policy folks we have social impact

folks this is something we just want to

talk about a lot so as society we can

kind of figure out what to do because it

shouldn't be up to us.

>> So the big question which you're kind of

alluding to is jobs and job loss and

things like that. There's this concept

of Jevans paradox of just as we can do

more we hire more and it's not actually

as scary as it looks. What have you

experienced so far I guess with AI

becoming a big part of the engineering

job? Just are you hiring more than if

you didn't have AI and just thoughts on

jobs?

>> Yeah, I mean for our team we're we're

hiring. Um so quadco team is hiring. Um

if you're interested just check out the

jobs page on on anthropic. Personally,

it's, you know, all this stuff has just

made me enjoy my work more. I have never

enjoyed coding as much as I do today

because I don't have to deal with all

the minutia. So, for me personally, it's

been quite exciting. This is something

that we hear from a lot of customers

where they love the tool, they love Quad

Code because it just makes coding

delightful again. Uh, and that's just

that's just so fun for them. But it's

hard to know where this thing is going

to go. And I again I just like I have to

reach for these historical analoges. Uh

and I I think the printing press is just

such a good one because what happened is

this technology that was locked away to

a small set of people like knowing how

to read and write became accessible to

everyone. It was just inherently

democratizing. Everyone started to be

able to do this. And if that wasn't the

case then something like the Renaissance

just could never have happened because a

lot of the Renaissance it was about like

knowledge spreading. It was about like

written records that people used to

communicate. Um, you know, cuz there

were no phones or anything like this.

There was there was no internet at the

time. So, it's about like what does this

enable next? And I think that's the very

optimistic version of it for me. And

that's the part that I'm really excited

about. It's just unimaginable, you know,

like we couldn't be talking today if the

printing press hadn't been invented.

Like our microphones wouldn't exist.

None of the things around us would

exist. it just wouldn't be possible to

coordinate such a large group of people

if that wasn't the case. And so I

imagine a world, you know, a few years

in the future where everyone is able to

program. And what does that unlock?

Anyone can just build software anytime.

And I have no idea. It's just the same

way that, you know, in the 1400s, no one

could have predicted this. Um, I think

it's the same way. But I do think in the

meantime, it's going to be very

disruptive and it's going to be painful

for a lot of people. Um, and again, as a

society, this is a conversation that we

have to have and this is a thing that we

have to figure out together.

>> So, for folks hearing this that want to

succeed and, you know, make it in this

crazy turmoil we're entering, any

advice? Is it, you know, play with AI

tools, get really proficient at the

latest stuff? Is there anything else

that you recommend to help people uh

stay ahead? Yeah, I think that's pretty

much it. Uh, experiment with the tools,

get to know them, don't be scared of

them. um just you know dive in try them

be on the bleeding edge beyond the

frontier. Maybe the second piece of

advice is try to be a generalist more

than you have in the past. For example,

in school a lot of people that study CS

they learn to code and they don't really

learn much else. Maybe they learn a

little bit of systems architecture or

something like this. But some of the

most effective engineers that I work

with every day and some of the most

effective, you know, like product

managers and so on, they cross over

disciplines. So on the quad code team,

everyone codes. You know, our product

manager codes, our engineering manager

codes, our designer codes, our finance

guy codes, our data scientist codes.

Like everyone on the team codes. And and

then if I look at particular engineers,

people often cross different

disciplines. So some of the strongest

engineers are hybrid product and

infrastructure engineers or product

engineers with really great design sense

and they're able to do design also or an

engineer that has a really good sense of

the business and can use that to figure

out what to do next. or an engineer that

also loves talking to users and can just

really channel what what users want to

figure out what's next. So I think a lot

of the people that will be rewarded the

most over the next few years, they won't

just be AI native and they don't just

know how to use these tools really well,

but also they're curious and they're

generalists and they cross over multiple

disciplines and can think about the

broader problem they're solving rather

than just the engineering part of it. Do

you find these three separate

disciplines still useful as a way to

think about the team? They're, you know,

engineering, design, uh, product

management. Do you find like those, even

though they are now coding and

contributing to thinking about what to

build, do you feel like those are three

roles that will persist long term, at

least at this point? I think in the

short term it'll persist, but one thing

that we're starting to see is there's

maybe a 50% overlap in these roles where

a lot of people are actually just doing

the same thing and some people have

specialties. for example, I code a

little bit more versus cat RPM does a

little bit more, you know, coordination

or planning or, you know, forecasting or

things like this.

>> Stakeholder alignment.

>> Stakeholder alignment. Exactly. I I do

think that there's a future where I

think by the end of the year what we're

going to start to see is these start to

get even murkier murkier where I think

in some places the title software

engineer is going to start to go away

and it's just going to be replaced by

builder or maybe it's just everyone's

going to be a product manager and

everyone codes or something like this.

Who says hiring has to be fair? Every

founder and hiring manager I've been

speaking with these days is feeling the

same pressure. Hire the best people as

fast as possible. But recruiting is time

consuming, alignment is hard, and

competition for great talent keeps

getting tighter. That's why teams like

11 Labs, Brex, Replet, Deal, and 5,000

other organizations use MetaView, the AI

company giving high performance teams a

real unfair advantage in hiring. They

give you a suite of AI agents that

behave like recruiting co-workers. They

find candidates for you based on your

exact criteria, take interview notes

automatically, gather insights across

your hiring process, and help you

identify the best candidates in your

pipeline. AI handles the recruiting toil

and gives you a real source of truth.

That means hours saved per hire and a

team focused on what matters most,

winning the right candidates. Don't let

your competitors outhire you. Metav

customers close roles 30% faster. Try

Metaview today for free and get an extra

month of sourcing at metaview.ai/lenny.

That's me.

Lenny. You talked about how you're

enjoying coding more. I actually did

this little informal survey on Twitter.

I don't know if you saw this where I

just asked I did three different polls.

I asked engineers, are you enjoying your

job more or less since adopting AI

tools? And then I did a separate one for

PMs and one for designers. And both

engineers and PMs, 70% of people said

they are enjoying their job more and

about 10% said they're enjoying their

job less. Designers, interestingly, only

55% said they are enjoying their job

more and 20% said they're enjoying their

job less. Thought that was really

interesting.

>> That's super interesting. I' I'd love to

talk to these people uh you know, both

in the more bucket and the less bucket

just to understand. Do did you get to

follow up with any of them? They a few

people replied and we're actually doing

a follow poll that we'll link to in the

show notes of going deeper into some of

the stuff, but a lot of there's like,

you know, the factors that make it more

fun and less fun. The designers, they

didn't share a lot actually of just like

the people that are actually asked just

like why are you enjoying your job less?

And I didn't hear a lot. So, I'm curious

what's going on there.

>> Yeah, I I'm seeing this a little bit

with uh at anthropic. I think everyone

is fairly technical.

This is something that we screen for,

you know, when when people join. We have

there there's a lot of technical

interviews that people go go through

even for non-technical functions.

Uh and you know our designers largely

code. So I think for them this is

something that they have enjoyed from

what I've seen because now instead of

bugging engineers they can just like go

in and code. And even some designers

that didn't code before have just

started to do it and for them it's great

cuz they can unblock themselves. But I'd

be really interested just to hear more

people's experiences cuz I I I bet it's

not uniform like that.

>> Yeah. So maybe if you're listening to

this, leave a comment if you're finding

your jobs less fun and enjoying your job

less cuz what you're saying and what I'm

hearing from most people, 70% of PMs and

engineers are loving their job more.

That's like if you're not in that

bucket, you could something's going on.

>> Yeah. Yeah. We do see that people use

also different tools. So for example,

our designers, they use uh the cloud

desktop app a lot more to to do their

coding. So you just download the desktop

app. There's a code tab. Uh it's right

next to co-work and it's actually the

same exact quad code. So it's like the

same agent and everything. We've had

this for, you know, for many, many

months. Uh and so you can use this to

code in a way that you don't have to

open a bunch of terminals, but you still

get the power of quad code. And the

biggest thing is you can just run as

many, you know, quad sessions in

parallel as you want. We, you know, we

call this multi-quading.

>> So this is a it's it's a little more

native, I think, for folks that are not

engineers. And really, this is back to

bringing the product to where the people

are. You don't want to make people use a

different workflow. You don't want to

make them go out of their way to learn a

new thing. It's whatever people are

doing, if you can make that a little bit

easier, then that's just going to be a

much better product that people enjoy

more. And this is just this principle of

latent demand, which I I think is just

the the single most important principle

in product.

>> Can you talk about that actually because

I was going to go there. Explain what

this principle is and and and just what

happens when you unlock this latent

demand. Latent demand is this idea that

if you build a product in a way that can

be hacked or can be kind of mi misused

by people in a way it wasn't really

designed for to do kind of something

that they want to do then this helps you

as the product builder learn where to

take the product next. So an example of

this is uh Facebook marketplace. So the

the manager for the team Fiona she she

was actually the founding manager for uh

the marketplace team and she talks about

this a lot.

Facebook Marketplace. It started based

on the observation back in uh this must

have been like 20 2016 or or something

like this that 40% of posts in Facebook

groups are buying and selling stuff. So

this is crazy. It's like people are

abusing the Facebook groups product to

buy and sell. And it's not it's not

abuse in kind of like a security sense.

It's abuse in that no one designed the

product for this, but they're kind of

figuring it out because it's just so

useful for this. And so it was pretty

obvious if you build a better product to

let people buy and sell, they're going

to like it. And it was just very obvious

that marketplace would be a hit from

this. And so the first thing was buy and

sell groups. So kind of special purpose

groups to let people do that. And the

second product was marketplace.

Uh Facebook dating I think started in a

pretty similar place. And I think that

the observation was if you look at

people looking if you look at uh profile

views so people looking at each other's

profiles on Facebook 60% of profile

views were people that are not friends

with each other that are opposite

gender. And so this is this kind of like

you know like traditional kind of dating

setup but you know people are just like

creeping on each other. So maybe if you

can build a product for this it's you

know it might work. Um and so this idea

of latent demand I think is just so

powerful. And for example this is also

where co-work came from. We saw that for

the last 6 months or so a lot of people

using quad code were not using it to

code. There was someone on Twitter that

was using it to grow tomato plants.

There was someone else using it to

analyze their genome. Someone was using

it to uh recover photos from a corrupted

hard drive. It was like uh wedding

photos. Uh there was someone that was

using it for uh I think like uh they

they were using it to analyze a MRI. So

there there's just all these different

use cases that are not technical at all.

And it was just really obvious like

people are jumping through hoops to use

a terminal to do this thing. Maybe we

should just build a product for them.

And we saw this actually pretty early

back in maybe May of last year. I

remember walking into the office and our

data scientist Brendan was had a quad

code on his uh computer. He just had a

terminal up and I was like I was

shocked. I was like Brendan what what

are you doing? Like you you figured out

how to open the terminal which is you

know it's a very engineering product.

Even a lot of engineers don't want to

use a terminal. It's just like a it's

like just like the lowest level way to

to do your work. Um just really really

uh kind of in the weeds of the computer.

And so he figured out how to use the

terminal. He downloaded Node.js. He

downloaded quad code and he was doing

SQL analysis in a terminal and it was

crazy. And then the next week all the

data scientists were doing the same

thing. So when you see people abusing

the product in this way, using it in a

way that it wasn't designed in order to

do something that is useful for them,

it's just such a strong indicator that

you should just build a product and and

people are going to like that. It's

something that's special purpose for

that. I think now there there's also

this kind of interesting second

dimension to latent demand. This is sort

of the traditional framing is look at

what people are doing, make that a

little bit easier, empower them. The

modern framing that I've been seeing in

the last 6 months is a little bit

different and it's look at what the

model is trying to do and make that a

little bit easier.

And so when we first started building

quad code, I think a lot of the way that

people approached designing things with

LLMs is they kind of put the model in a

box and they were like, here's this

application that I want to build. Here's

the thing that I wanted to do. model,

you're going to do this one component of

it. Here's the way that you're going to

interact with these tools and APIs and

whatever. And for cloud code, we

inverted that. We said the product is

the model. We want to expose it. We want

to put the minimal scaffolding around

it. Give it the minimal set of tools.

So, it can do the things. It can decide

which tools to run. It can decide in

what order to run them in and so on. And

I I think a lot of this was just based

on kind of latent demand of what the

model wanted to do. And so, in research,

we call this being on distribution. Uh

you want to see like what the model is

trying to do. In product terms, latent

demand is just the same exact concept

but applied to a model.

>> You talked about co-work something that

I saw you talk about when you launched

that initially is you your team built

that in 10 days.

>> That's insane. Uh I it came out I think

it was like you know used by millions of

people pretty quickly something like

that being built in 10 days. Uh anything

there any stories there other than just

it was just you know we use cloud code

to build it and that's it.

>> Yeah it's funny. Uh cloud code like I

said when we released it was not

immediately a hit. it became a hit over

time and there was a few inflection

points. So one was you know like Opus 4

uh it just really really inflected and

then in November it inflected and it

just keeps inflecting. The growth just

keeps getting steeper and steeper and

steeper every day. But you know for the

first few months it wasn't a hit. Uh

people used it but a lot of people

couldn't figure out how to use it. They

didn't know what it was for. The model

still like wasn't very good. Co-work

when we released it was just immediately

a hit much more so than cloud code was

early on. I think a lot of the credit

honestly just goes to like Felix and and

Sam and the and Jenny and the the team

that built this. It's just an incredibly

strong team. And again, the the place co

came from is just this latent demand.

Like we saw people using quad code for

these non-technical things and we're

trying to figure out what do we do? And

so for a few months the team was

exploring they were trying all sorts of

different options and in the end someone

was just like okay what what if we just

take quad code and put it in the desktop

app and that's essentially the thing

that worked. And so over 10 days they

just completely use quad code to build

it. Uh and you know co-work is actually

there's this very sophisticated security

system that's that's built in and

essentially these guard rails to make

sure that the model kind of does the

right thing. It doesn't go off the

rails. So for example we ship an entire

virtual machine with it. And quad code

just wrote all of this code. So we just

had to think about all right how do we

make this a little bit safer a little

more self-guided for uh people that are

not engineers. It was fully implemented

with quad code. took about 10 days. We

launched it early. You know, it was

still pretty rough and it's still pretty

rough around the edges. But this is kind

of the way that we learn um both on the

product side and on the safety side is

we have to release things a little bit

earlier than we think so that we can get

the feedback so that we can talk to

users. We can understand what people

want and and that will shape where the

product goes in the future.

>> Yeah, I think that point is so

interesting and and it's so unique.

There's always been this idea release

early, learn from users, get feedback,

iterate. The fact that it's hard to even

know what the AI is capable of and how

people will try to use it is like is a

unique reason to start releasing things

early that'll help you as you exactly

describe this idea of what is the latent

demand in this thing that we didn't

really know. Let's put it out there and

see what people do with it.

>> Yeah. And in philanthropic as a safety

lab, the other dimension of that is

safety because um you know like when you

think about model safety, there's a

bunch of different ways to study it.

Sort of the lowest level is alignment

and mechanistic interpretability. So

this is when we train the model, we want

to make sure that it's safe. We at this

point have like pretty sophisticated

technology to understand what's

happening in the neurons to trace it.

And so for example like if there's a

neuron related to deception we can start

we're starting to get to the point where

we can monitor it and understand that

it's activating. Um and so this is just

this is alignment this is mechanistic

interpretability. It's like the lowest

layer. The second layer is evolves and

this is essentially a laboratory

setting. The model is in a petri dish

and you study it and you put in a

synthetic situation and just say okay

like model what do you do and are you

doing the right thing? Is it aligned? Is

it safe? And then the third layer is

seeing how the model behaves in the

wild. And as the model gets more

sophisticated, this this becomes so

important because it might look very

good on these first two layers but not

great on the third one. We released

cloud code really early because we

wanted to study safety and we actually

used it within anthropic for I think

four or 5 months or something before we

released it because we weren't really

sure like this is the first agent that

you know the first big agent that I

think folks had released at that point.

um it was definitely the first uh you

know coding agent that became broadly

used and so we weren't sure if it was

safe and so we actually had to study it

internally for a long time before we

felt good about that and even since you

know there's a lot that we've learned

about alignment there's a lot that we've

learned about safety that we've been

able to put back into the model back

into the product and for co-work it's

pretty similar uh the model's in this

new setting it's you know doing these

tasks that are not engineering tasks

it's an agent that's acting on your

behalf it looks good on alignment it

looks good on evals we try to internally

it looks good we it with a few

customers, it looks good. Now, we have

to make sure it's safe in the real

world. And so, that's why we release a

little early. That's why we call it a

research preview. Um, but yeah, it's

just it's constantly improving. Um, and

this is really the only way to to make

sure that over the long term the model

is aligned and it's doing the right

things. It's such a wild space that you

work in where there's this insane

competition and pace. At the same time,

there's this fear that if you get some

if the the you know the god can escape

and cause damage and just finding that

balance must be so challenging. What I'm

hearing is there's kind of these three

layers and I know there's like this

could be a whole podcast conversation is

how you all think about the safety piece

but just what I'm hearing is there's

these three layers you work with. Uh

there's kind of like observing the model

thinking and operating. There's tests

eval that tell you this is doing bad

things and then releasing it early. I

haven't actually heard a ton about that

first piece. That is so cool. So you

guys can there's an observability tool

that can let you peek inside the model's

brain and see how it's thinking and

where it's heading. Yeah, you should uh

you should at some point have Chris Ola

on the podcast because uh he he's just

the industry expert on this. He he

invented this field of uh we call it

mechanistic interpretability. Uh and the

the idea is uh you know like at its core

like what is your brain? Like what are

what is it? It's like it's a bunch of

neurons that are connected. And so what

you can do is like in a human brain or

animal brain you can study it at this

kind of mechanistic level to understand

what the neurons are doing. It turns out

surprisingly a lot of this does

translate to models also. So model

neurons are not the same as animal

neurons but they behave similarly in a

lot of ways. And so we've been able to

learn just a ton about the way these

neurons work, about, you know, this

layer or this neuron maps to this

concept, how particular concepts are

encoded, how the model does planning,

how it how it thinks ahead, you know,

like a long time ago, we weren't sure if

the model is just predicting the next

token or is doing something a little bit

deeper. Now, I think there's actually

quite strong evidence that it is doing

something a little bit deeper. And then

the structures that were to do this are

pretty sophisticated now where as the

models get bigger, it's not just like a

single neuron that corresponds to a

concept. A single neuron might

correspond to a dozen concepts. And if

it's activated together with other

neurons, this is called superposition.

And uh together it represents this more

sophisticated concept. And it's just

something we're learning about all the

time, you know, and philanthropic as as

we think about the way this space

evolves,

doing this in a way that is safe and

good for the world is just this is the

reason that we exist and this is the

reason that everyone is at anthropic.

Uh, everyone that is here, this is the

reason why they're here. So, a lot of

this work we actually open source. Uh,

we publish it a lot. Um and you know we

publish very freely to talk about this

just so we can inspire other labs that

are working on similar things to do it

in a way that's safe and this is

something that we've been doing for

cloud code also we call this the race to

the top uh internally and so for cloud

code for example we released an open

source sandbox and this is a sandbox

they can run the the agent in and it

just makes sure that there's certain

boundaries and it can't access like

everything on your system. Uh, and we

made that open source and it actually

works with any agent, not just quad code

because we wanted to make it really easy

for others to do the same thing. Um, so

this is just the same principle of race

to the top. Um, we we want to make sure

this thing goes well and this is just

the this is the lever that we have.

>> Incredible. Okay, I definitely want to

spend more time on that. I I will follow

up with this suggestion. Something else

that I've been noticing in the in the

field across engineers, product

managers, others that work with agents

is there's this kind of anxiety people

feel when their agents aren't working.

There's a sense that like, oh man, Nza

has a question, I need to answer or it's

like blocked on something or it's or I

just like I I'm like there's all this

productivity I'm losing. I can't like I

need to wake up and get it going again.

Is that something you feel? Is that

something your team feels? Do you feel

like this is a a problem we need to

track and think about? I always have a

bunch of agents running. So like at the

moment I have like five agents running

and at any moment like you know like I I

wake up and I I stored a bunch of

agents. Like the first thing I did when

I woke up is like oh man I I want I

really want to check this thing. So like

I opened up my phone quad iOS app code

tab uh you know like agent do do blah

blah blah cuz I I wrote some code

yesterday and I was like wait did did I

do this right? I was like kind of double

double guessing something and it and it

was correct. But now it's just like so

easy to do this. So I don't know, there

is this little bit of anxiety. Maybe I

personally haven't really felt it just

cuz I have agents running all the time.

Um, and I'm also just like not locked

into a terminal anymore. Maybe a third

of my code now is in the terminal, but

also a third is uh using the desktop app

and then a third is the iOS app, which

is just so surprising cuz I did not

think that this would be the way that I

code uh in even in 2026. I love that you

describe it as coding still, which is

just talking to the to cloud code to

code for you essentially. And it's

interesting that this is now like this

is now coding. Coding now is describing

what you want, not writing actual code.

>> I I I kind of wonder if uh the people

that used to code using punch cards or

whatever, if you show them software,

what they would have said. Isn't that

crazy? And I I remember reading

something this was maybe like very early

versions of like ACM uh like like

magazine or something where people were

saying no it's not the same thing like

this isn't this isn't really coding uh

and you know like they called it

programming I think coding is kind of a

new word

>> but I kind of think about this like in

the back in the you know my family is

from the Soviet Union I you know I I was

born in Ukraine um and my grandpa was

actually one of the first programmers in

the Soviet Union and he programmed using

punch cards And uh you know like he he

told my mom uh growing up told these

stories of like or she she told these

stories that when she was growing up he

would bring these punch cards home and

there was these like big stacks of punch

cards and for her she would like draw

all over them with crayons and that was

like her childhood memory but for him

that was like his experience of

programming and he actually never saw

the software transition but at some

point it did transition to software and

I think there's probably this older

generation of programmers that just

didn't take software very seriously and

they would have been like well you know

it's not really coding.

But I I think this is a field that just

has always been changing in this way.

>> Uh I don't think you know this, but I

was born in Ukraine also.

>> Oh, I don't know. Yeah. Which time?

>> I'm I'm from Odessa.

>> Oh, me too.

>> What?

>> Yeah, that's crazy.

>> Wow. Incredible. What a moment. Uh maybe

related in some small way.

>> Uh what year did your home did you leave

and your family leave?

>> Uh we came in 95.

>> Okay. We left in ' 88. a little earlier.

>> Oh, yeah.

>> What a different life that would have

been to not to not leave, huh?

>> Yeah. I just I feel I feel so lucky

every day that uh get get to grow up

here.

>> Yeah. My family anytime there's like a

toaster or a meal, they're just like to

America.

It's like, okay, enough about that. But

you get it, you know, once you start

really thinking about what life could

have been.

>> Yeah. Yeah. Exactly. Yeah. We do we do

the same toast, but it's still vodka.

>> It's still vodka. Absolutely.

Oh, man. Okay. Let me ask you a couple

more things here. You shared some really

cool tips for how to get the most out of

AI, how to build on AI, how to build

great products on AI. One tip you shared

is give your team as many tokens as they

want. Just like let them experiment. You

also shared just advice generally of

just build towards the model where the