Head of Claude Code: What happens after coding is solved | Boris Cherny

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,

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

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

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

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

has doubled. Boris is also just a really interesting thoughtful deepinking human. And during this conversation, we

human. And during this conversation, we discover we were born in the same city in Ukraine. That is so funny. I had no

in Ukraine. That is so funny. I had no idea. A huge thank you to Ben Man, Jenny

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

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

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.

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

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

centry.io/lenny and use code Lenny for $100 in Sentry credits. That's s n t r y.io/lenny.

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

left Anthropic. You joined Curser and then two weeks later, you went back to Anthropic. What happened there? I don't

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.

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

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

mission. And it was, you know, it's all about safety. And when you talk to

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

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

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

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

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

point. Um these are also just public commits. So we actually think if you

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

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

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

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

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

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

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

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

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

"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

from users. Um so that's just been the best I' I've been surprised so many times. It's incredible how fast

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

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

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

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.

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

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

my code. And it only crossed 100% in November. So it took a while. But even

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

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

cloud code. Um, I am a fairly prolific coder. Um, and this has been the case

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

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

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

engineering. That felt like a crazy milestone. Now it's just like of course

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

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

little bit. So I think at this point it's safe to say that coding is largely solved. At least for the kind of

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

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

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,

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

that one?" I'm like, "Yeah." Have you noticed that it is getting much better at this? Because this is kind of the

at this? Because this is kind of the holy grail, right? Now it's like, "Cool, building solved." Code review became

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

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.

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

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

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

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

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

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

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

over. So I think that's kind of like one principle is underfunding things a little bit. I think another principle is

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

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

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

companies. Like if you join you get unlimited tokens. This is a thing I very

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

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

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

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,

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

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

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

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

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

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

happens. I I don't worry about it too much personally. I think for me like

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

punch cards. Before that it was switches. Before that it was hardware.

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

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

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

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

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,

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

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

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

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

quite hard. It takes an education system. It takes free time. You it takes

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

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

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.

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

this. People that have no technical experience can do exactly what you're describing. Like I'm I've been doing a

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

everyone. It was just inherently democratizing. Everyone started to be

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

knowledge spreading. It was about like written records that people used to communicate. Um, you know, cuz there

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

time. So, it's about like what does this enable next? And I think that's the very

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,

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

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?

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

advice? Is it, you know, play with AI tools, get really proficient at the latest stuff? Is there anything else

latest stuff? Is there anything else that you recommend to help people uh stay ahead? Yeah, I think that's pretty

stay ahead? Yeah, I think that's pretty much it. Uh, experiment with the tools,

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

them. um just you know dive in try them be on the bleeding edge beyond the frontier. Maybe the second piece of

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,

disciplines. So on the quad code team, everyone codes. You know, our product

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

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

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

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

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

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

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

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

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

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

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

coding. So you just download the desktop app. There's a code tab. Uh it's right

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

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

engineers. And really, this is back to bringing the product to where the people are. You don't want to make people use a

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

different workflow. You don't want to make them go out of their way to learn a new thing. It's whatever people are

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

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

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

this. And so the first thing was buy and sell groups. So kind of special purpose

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

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

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

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

hard drive. It was like uh wedding photos. Uh there was someone that was

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

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

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

crazy. And then the next week all the data scientists were doing the same thing. So when you see people abusing

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

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

it. Here's the way that you're going to interact with these tools and APIs and whatever. And for cloud code, we

whatever. And for cloud code, we inverted that. We said the product is

inverted that. We said the product is the model. We want to expose it. We want

the model. We want to expose it. We want

to put the minimal scaffolding around it. Give it the minimal set of tools.

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

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

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

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

that worked. And so over 10 days they just completely use quad code to build it. Uh and you know co-work is actually

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

right thing. It doesn't go off the rails. So for example we ship an entire

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

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

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

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

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

it's activating. Um and so this is just this is alignment this is mechanistic interpretability. It's like the lowest

interpretability. It's like the lowest layer. The second layer is evolves and

layer. The second layer is evolves and this is essentially a laboratory setting. The model is in a petri dish

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

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

world. And so, that's why we release a little early. That's why we call it a

little early. That's why we call it a research preview. Um, but yeah, it's

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

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

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

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

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

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

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

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

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

want. Just like let them experiment. You

also shared just advice generally of just build towards the model where the model is going, not to where it is today. What other advice do you have for

today. What other advice do you have for folks that are trying to build AI products?

>> I'd probably share a few more things.

So, one is don't try to box the model in. Um I I think a lot of people's

in. Um I I think a lot of people's instinct when they build on the model is they try to make it behave a very particular way. They're like this is a

particular way. They're like this is a component of a bigger system. I I think some examples of this are people layering like very strict workflows on the model for example you know to say like you must do step one then step two then step three and you have this like

very fancy orchestrator doing this. But

actually almost always you get better results if you just give the model tools you give it a goal and you let it figure it out. I think a year ago you actually

it out. I think a year ago you actually needed a lot of the scaffolding but nowadays you don't really need it. So,

you know, I I don't know what to call this principle, but it's like, you know, like ask not what the model can do for you. Maybe maybe it's something like

you. Maybe maybe it's something like this. Just think about how do you give

this. Just think about how do you give the model the tools to do things. Don't

try to overcurate it. Don't try to put it into a box. Don't try to give it a bunch of context up front. Give it a tool so that it can get the context it needs. You're just going to get better

needs. You're just going to get better results.

I think a second one is um maybe actually like a a more even more general version of this principle is just the bitter lesson.

Uh and actually for the quad code team we have a you know hopefully hopefully um listeners have have read this but Rich Sutton had this blog post maybe 10 years ago called the bitter lesson. Uh

and it's actually a really simple idea.

His idea was that the more general model will always outperform the more specific model and I think for him he was talking about like self-driving cars and other domains like this but actually there's

just so many corlaries to the bitter lesson. And for me, the biggest one is

lesson. And for me, the biggest one is just always bet on the more general model and you know over the long term like don't don't try to use tiny models for stuff. Don't try to like fine-tune.

for stuff. Don't try to like fine-tune.

Don't try to do any of this stuff.

There's like some applications you know there's some reasons to do this but almost always try to bet on the more general model if you can if you have that flexibility.

Um and so these workflows are essentially a way that uh you know it's it's not it's not a general model. It's

putting the scaffolding around it. And

in general what we see is maybe scaffolding can improve performance maybe 10 20% something like this but often these gains just get wiped out with the next model. Uh so it's almost

better to just wait for the next one.

And I think maybe this is a final principle and something that quad code I think got right in hindsight. From the

very beginning, we bet on building for the model six months from now, not for the model of today.

And for the very early versions of the product, it just wrote so little of my code cuz I I didn't trust it cuz, you know, it was like sonnet 3.5, then it was like 3.6 or forget 3 3.5 new,

whatever whatever whatever name we gave it. Um, these models just weren't very

it. Um, these models just weren't very good at coding yet. Um, they were they were getting there, but it was still pretty early. So back then the model did

pretty early. So back then the model did uh you used git for me it automated some things but it it really wasn't doing a huge amount of my coding and so the bet with quad code was at some point the

model gets good enough that it can just write a lot of the code and this is a thing that we first started seeing with opus 4 and sonnet 4 and opus 4 was our first kind of ASL3 class model uh that

we released back in May and we just saw this inflection because everyone started to use quad code for the first time and that was kind of when our growth really went exponential and like I said it's kind of it stayed there. So I think this

is some this is advice that I actually give to to a lot of folks especially people building startups. It's going to be uncomfortable cuz your product market fit won't be very good for the first 6

months but if you build for the model 6 months out when that model comes out you're just going to hit the ground running and the product is going to click and and start to work. And when

you say build for the model 6 months out what is what is it that you think people can assume will happen? Is it just generally it will get better at things?

Is it just like okay, it's like almost good enough and that's a sign that it'll probably get better at that thing. Is

there any advice there?

>> I think that's a good way to do it.

Like, you know, obviously within an AI lab, we get to see the specific ways that it gets better.

>> So, it's a it's a little unfair, but we we also we try to talk about this. So,

you know, like one of the ways that it's going to get better is it's going to get better and better at using tools and using computers.

This is a bet that I would make. Uh,

another one is it's going to get better and better for long for running for long periods of time. And this is a place, you know, like there's all sorts of studies about this, but if you just trace the trajectory or, you know, maybe

even like for my own experience when I used Sonnet 3.5 back, you know, a year ago, it could run for maybe 15 or 30 seconds before before it started going off the rails and you just really had to

hold its hand through any kind of complicated task. But nowadays with Opus

complicated task. But nowadays with Opus 4.6, fix, you know, on average it'll run maybe 10, 30, 20, 30 minutes unattended and I'll just like start another quad and have it do something else. And you

know, like I said, I always have a bunch of quads running. Uh, and they can also run for hours or even days at a time. I

think there are some examples where they ran for many weeks. And so I think over time this is going to become more and more normal where the models are running for a very very long period of time and you you don't have to sit there and babysit them anymore.

>> So we just talked about tips for building AI products. Any tips for someone just using cloud code say for the first time or just someone already using cloud code that wants to get better? What are like a couple pro tips

better? What are like a couple pro tips that you could share?

>> I will give a caveat which is there's no one right way to use quad code. So I I can share some tips but honestly this is a dev tool. Developers are all different. Developers have different

different. Developers have different preferences. They have different

preferences. They have different environments. So there's just so many

environments. So there's just so many ways to use these tools. There's no one right way. Um you you sort of have to

right way. Um you you sort of have to find your own path. Luckily you can ask Quad Code. Uh it's able to make

Quad Code. Uh it's able to make recommendations. It can edit your

recommendations. It can edit your settings. It kind of knows about itself.

settings. It kind of knows about itself.

So, it can help it can help with that. A

few tips that generally I find pretty useful. So, number one is just use the

useful. So, number one is just use the most capable model. Um, currently that's Opus 4.6. I have maximum effort enabled

Opus 4.6. I have maximum effort enabled always. The thing that happens is

always. The thing that happens is sometimes people try to use a less expensive model like sonnet or something like this. But because it's less

like this. But because it's less intelligent, it actually takes more tokens in the end to do the same task.

Um, and so it's actually not obvious that it's cheaper if you use a less expensive model. often it's actually

expensive model. often it's actually cheaper and less token intensive if you use the most capable model because it can just do the same thing much faster with less correction, less uh less handholding and so on. So that's the

first tip is just use the best model.

The second one is use plan mode. I start

almost all of my tasks in plan mode, maybe like 80%. And plan mode is actually really simple. All it is is we inject one sentence into the model's prompt to say please don't write any

code yet. That's it. like there's

code yet. That's it. like there's

there's actually like nothing fancy going on. It's just the simplest thing.

going on. It's just the simplest thing.

>> Um, and so for people that are in the terminal, it's just shift tab twice and that gets you into plan mode. Uh, for

people in the desktop app, there's a little button. On web, there's a little

little button. On web, there's a little button. It's coming pretty soon to

button. It's coming pretty soon to mobile also. Uh, and we just launched it

mobile also. Uh, and we just launched it for the SWAC integration, too. Uh, so

plan mode is the second one. And uh,

essentially the model would just go back and forth with you. Once the plan looks good, then you let the model execute. I

auto accept edits after that because if the plan looks good, it's just going to oneshot it. It'll get it right the first

oneshot it. It'll get it right the first time almost every time with Opus 4.6.

And then maybe the third tip is just play around with different interfaces. I

think a lot of people when they think about cloud code, they think about a terminal. Um, and you know, of course,

terminal. Um, and you know, of course, we support every terminal. We support

like Mac, Windows, you know, like whatever terminal you might use, it works perfectly. But we actually support

works perfectly. But we actually support a lot of other form factors too like you know, we have like iOS and Android apps.

We have a desktop app. There's uh you know the Slack integration. There's all

sorts of things that we support. So I

would just like play around with these.

And again it's like every engineer is different. Everyone that's building is

different. Everyone that's building is different. Just find the thing that

different. Just find the thing that feels right to you and and use that. You

don't have to use a terminal. It's the

same quad agent running everywhere.

>> Amazing. Okay. Just a couple more questions to round things out. What's

your take on Codeex? How do you feel about that product? How do you feel about where they're going? Just kind of competing in this very competitive space uh in coding agents. Yeah, I actually

haven't really used it, but uh I I think I did use it maybe when it came out. It

looked a lot like Quad Code to me, so that was kind of flattering. It's I

think it's actually good, you know, to have more competition cuz people should get to choose and hopefully it forces all of us to like do a even better job.

Honestly, for our team though, we're just focused on solving the problems that users have. Um so for us, you know, we don't spend a lot of time looking at competing products. We don't really try

competing products. We don't really try the other products. I you know you kind of you want to be aware of them. You

want to know they exist but for me I just I love talking to users. I love

making the product better. Um I I love just acting on on feedback. So it's

really just about building a building a good product.

>> Maybe a last question. So I talked to Ben man co-founder of Anthropic. What

what to talk to you about. He had a bunch of suggestions which I've integrated throughout our chat. One

question he had for you is what's your plan post AGI?

What do you think you're going to be doing? What's your life like once we hit

doing? What's your life like once we hit AGI? whatever that means.

AGI? whatever that means.

>> So before I joined Anthropic, um I was actually living in rural Japan and it was like a totally different lifestyle.

Um I was like the only engineer in the town. I was the only English speaker in

town. I was the only English speaker in the town. It was just like a totally

the town. It was just like a totally different vibe. Like a couple times a

different vibe. Like a couple times a week I would like bike to the farmers market. Uh and you know you like bike by

market. Uh and you know you like bike by like rice patties and stuff. It was just like a totally different speed than just complete opposite of San Francisco. One

of the things that I really liked is a way that we got to know our neighbors and we kind of built friendships is by trading like pickles.

So in that in the town where we lived, it was actually like everyone made like miso. Everyone made pickles. Uh and so I

miso. Everyone made pickles. Uh and so I actually got like decently good at making miso. Um and you know I made a

making miso. Um and you know I made a bunch of batches and um this is something that I still make. Uh miso is this interesting thing where it teaches you to think on these longtime skills.

That's just very different than engineering cuz like uh you know like a batch of white miso takes like at least three months to make and a red miso is like you know 2 3 4 years. You just have to be very patient. You kind of mix it

up and then you just like wet it sit.

You have to be very very patient.

>> So I the thing that I love about it is just thinking in these longtime skills.

Uh, and yeah, I think postGI or if I wasn't at anthropic, I'd probably be making miso.

>> I love this answer. Uh, Ben asked me to ask you about what's the deal with you and miso and so I love that you answered it. Okay, so the future the future might

it. Okay, so the future the future might be just going deep into miso, getting really good at get making miso. Uh,

amazing. Uh, Boris, this was incredible.

I feel like we're we're brothers now from Ukraine. Uh before we get to a very

from Ukraine. Uh before we get to a very exciting lightning round, is there anything else that you wanted to share?

Is there anything you want to leave listeners with? Anything you want uh you

listeners with? Anything you want uh you want to double down on?

>> Yeah, I I think I would just like underscore, you know, like for for anthropic since the beginning, this idea of like starting at coding, then getting to tool use, then getting to computer use has just been the way that we think

about things. And we this is the way

about things. And we this is the way that we know the models are going to develop or, you know, the way that we want to build our models. And it's also the way that we get to learn about safety, study it, and improve it the

most. So, you know, everything that's

most. So, you know, everything that's happening right now around, you know, just like Quad Code becoming this huge, you know, multi-billion dollar business and, you know, like now all of my friends use Quad Code and they just text

me about it all the time. Uh, so just like, you know, this thing getting kind of big and in some ways it's a total surprise because this isn't kind of the we didn't know that it would be this product. We didn't know that it would

product. We didn't know that it would start in a terminal or anything like this. But in some ways, it's just

this. But in some ways, it's just totally unsurprising because this has been our belief as a company for for a long time. At the same time, it just

long time. At the same time, it just feels still very early, you know, like most of the world still does not use quad code. Most of the world still does

quad code. Most of the world still does not use AI. So, it just feels like this is 1% done and there's so much more to go.

>> Yeah. Man, that's insane to think seeing the numbers that are coming out. You

guys just raised a bazillion dollars. Uh

I think Cloud Code alone is making$2 billion dollars in revenue. you think

Anthropic, I think the number you guys put out, you're making 15 billion in revenue. It's uh insane to just think

revenue. It's uh insane to just think this is how early it still is and just the numbers we're seeing.

>> Yeah. Yeah. Yeah. It's crazy. And and I mean like the the way that Quad Code has kept growing is honestly just the users.

Like we so many people use it. They're

so passionate about it. They fall in love with the product and then they tell us about stuff that doesn't work, stuff that they want. And so like the only reason that it keeps improving is because everyone is using it. Everyone

is talking about it. Everyone keeps

giving feedback and this is just the single most important thing and you know for me this is the way that I love to spend my day is just talking to users and making it better for them >> and making me so

>> and making me so well the you know the miso is like not super involved it just you just got to wait you just got to wait >> well Boris with that we've reached our very exciting lightning round I've got

five questions for you are you ready >> let's do it first question what are two or three books that you find yourself recommending most to other people >> I I'm a greeter. Uh I would start with

the technical book one is it it is functional programming in Scola. This is

the single best technical book I've ever read. It's very weird because you're

read. It's very weird because you're probably not going to use Scola and I don't know how much this matters in the future now but there's this just elegance to functional programming and thinking in types and this is just the

way that I code and the way that I can't stop thinking about coding. So you know you could think of it as a historical artifact. You could think of it as

artifact. You could think of it as something that will level you up.

>> I love this neverbeforementioned book.

My favorite.

>> Oh, amazing. Amazing. Uh, okay. Second

one is uh Accelerondo by Straws. This is

probably, you know, like my my big genre is uh is sci-fi. Uh like probably sci-fi and fiction. Accelerondo is just this

and fiction. Accelerondo is just this incredible book and it it it's just so fast-paced. The pace gets faster and

fast-paced. The pace gets faster and faster and faster. And I just feel like it captures the essence of this moment that we're in more than any other book that I've read. Just the speed of it.

And it starts as a liftoff is starting to happen and you know starting to approach the singularity and it ends with like this like collective lobster consciousness orbiting Jupiter. Um and

you know this happens over like the span of a few decades or something. So the

the pace is just incredible. I I really love it. Maybe I'll I'll do one more

love it. Maybe I'll I'll do one more book. Uh the wandering earth uh

book. Uh the wandering earth uh wandering earth by uh sishlu. So he's

the guy that did uh three body problem.

I think a lot of people know him for that. I actually I think your body

that. I actually I think your body problem was awesome, but I actually liked his short stories even more. So,

Wandering Earth is one of the short story collections and it just has some really really amazing stories and it it's also just quite interesting to see uh Chinese sci-fi because it has a very different perspective than Western

sci-fi and kind of the way that um at least he as a writer thinks about it.

So, it's just really really interesting to read and just beautifully written.

It's so interesting how sci-fi has prepared us to think about where things are going. Just like it creates these

are going. Just like it creates these mounts to models of like okay I see I've read about this sort of world. Yeah. I

think I think for me this is like the reason that I joined anthropic actually cuz uh you know like like I said I was living in this rural place. I was

thinking these longtime skills because everything is just so slow out there at least compared to SF. Um and just like all the things that you do are based around the seasons and it's based around this food that takes many many months.

That's the way that kind of like social events are organized. That's the way you kind of organize your time. You like you go to the farmers market and it's like it's pimmen season and you know that because there's like 20 pimmen vendors

and then the next week the season is done and it's like grape season and you kind of see this. So it's like these kind of longtime skills and I was also reading a bunch of sci-fi at the time and just like being in this moment I was like you know just thinking about these

long time scales. I know how this thing can go and I just I felt like I had to contribute to it going a little bit better and that's actually why I ended up at Ant and Ben man was also a big part of that too.

>> I feel like I want to do a whole podcast just talking about your time in Japan and the journey of Boris through Japan to anthropic but we'll keep it we'll keep it short. Uh I'll quickly recommend

a sci-fi book to you if you haven't read it. Have you read Fire Upon the Deep?

it. Have you read Fire Upon the Deep?

>> Uh this is Ving, right? Yeah. It's

great.

>> Yes. Okay. That one's like it's like so interesting from a AI AGI perspective.

Uh so few people have read that so um I myself >> Yeah. It's like a lot.

>> Yeah. It's like a lot.

>> Yeah. Yeah. Yeah. I like Deepness in the Sky also. I think those sequels, right?

Sky also. I think those sequels, right?

Or >> Yeah.

>> Yeah. Yeah. Yeah. I think so.

>> Yeah. It's very long and like complex to get into but so good. Okay. We'll keep

going through a lightning round. Uh do

you have a favorite recent movie or TV show you really enjoyed?

>> So, I actually don't really watch TV or movies. I just don't really have time

movies. I just don't really have time these days. Um, I did watch I I I'm

these days. Um, I did watch I I I'm going to bring up another sishloo, but the three body problem series on Netflix I I really loved. Um, I thought that was like a great rendition of the book series.

>> So, the common pattern across uh AI leaders is no time to watch TV or movies, which I completely understand.

Uh, is there a favorite product you've recently discovered that you really love?

>> I'm going to like chill a little bit and just say co-work cuz this is legitimately the the one product that's been pretty life-changing for me. uh

just because I I have it running all the time and uh the the Chrome integration in particular is just really excellent.

Uh so it's been like it paid a traffic fine for me. It like canceled a couple subscriptions for me. Uh just like the amount of like tedious work it gets out of the way is awesome. I I also don't know if it's a product, but maybe I'll

I'll uh also another podcast that I really love obviously besides uh besides Venny is >> obviously >> Yeah, it's uh it's the acquired uh podcast by Ben Ben and David.

>> Uh it's it's just like super it's super awesome. Um, I feel like the way that

awesome. Um, I feel like the way that they get into like business history and bring it alive is is really really good.

And I would start with a Nintendo episode if uh if you haven't listened to it.

>> Great tip uh with co-work just so people understand if they haven't tried this like basically you type something you want to get done and it can launch Chrome and just do things for you. I saw

one of the someone went on pat leave from anthropic and he had it fill out these like medical forms for him. these

like really annoying PDFs where it just like loads up the browser, logs in, fills them out, and bits them.

>> Yeah, exactly. Exactly. And and it actually just kind of works. Like we

tried this experiment like a year ago and it didn't really work cuz the model wasn't ready, but now now it actually just works. And it's amazing. I think a

just works. And it's amazing. I think a lot of people just don't really understand what this is because they haven't used agent before. And it it just feels very very similar to me to quad code a year ago. Um but like I

said, it's just growing much faster than quad code did in the early days. So, I

think it's starting to it's starting to break through a bit.

>> And there's also this Chrome extension that you mentioned that you could just use stand alone that sits in Chrome and you could just talk to Claude uh looking at your screen at your browser and have it do stuff, have it tell you about what you're looking at, summarize what you're

looking at, things like that.

>> Exactly. Exactly. For for people that are like just starting to use co-work, the thing I recommend is so you download the Quad Desktop app, you go to the co-work tab. It's right next to the code

co-work tab. It's right next to the code tab. Um the thing that I recommend doing

tab. Um the thing that I recommend doing is like start by having it use a tool.

So like clean up your desktop or like summarize your email or something like this or you know like respond to the top three emails like it actually just responds to emails for me now too. The

second thing is connect tools. So like

if you connect like if you say look at my top emails and then send slack messages or you know like put them in a spreadsheet or something or for example like I use it for all my project management. So we have a single

management. So we have a single spreadsheet for the whole team. there's

like a row per engineer. Every week

everyone fills out a status and every Monday co-work just goes through and it messages every engineer on Slack that hasn't filled out their status and so I don't have to do this anymore. And this

is just one prompt. It'll do everything.

And then the third thing is just run a bunch of quads in parallel. So we can co-work you can have as many tasks running as you want. So it's like start one task, you know, I have this project management thing running, then I'll have it do something else, then something

else and I'll kick these off and then I just go get a coffee while it runs.

There's a post I'll link to that shares a bunch of ways people use uh what was previously cloud code and now just you could do through code work because a lot of this is just like oh wow I hadn't thought I could use it for that and once

you see like these examples I think are what people need to hear of just like oh wow I didn't know I could do that >> so >> yeah I think a lot of this was also >> some of this was also inspired by you any

>> you you had this post about uh it was like 50 non-technical use cases for quote or something like this >> so we actually one of our PMs used that as a way to evaluate co-work before we released it. Um, and I think at the

released it. Um, and I think at the point where we hit where Coowork was able to do like 48 out of the 50, they were like, "Okay, it's pretty good."

>> Wow. I did not know that. That is

awesome. Uh, it's I've become an eval.

>> Yeah. How does that feel?

>> Amazing.

I feel like I'm valuable to the future of AI.

>> This is like reverse breaking through.

>> Wow, that is so cool. Wow. Okay. I

wonder what those last two are. Anyway,

okay, two more questions. Um, do you have a favorite life motto that you often come back to in work or in life?

>> Use common sense.

I think a lot of the failures that I see in especially in a work environment is people just failing to use common sense.

Like they follow a process without thinking about it. Um, they just do a thing without thinking about it or they're working on a product that's like not a good product or not a good idea and they're just following the momentum and not thinking about it. I think the best results that I see are people

thinking from first principles and just developing their own common sense. Like

if something smells weird, then you know it's probably not a good idea. So I

think I think just this this is the single advice that I give, you know, to co-workers more more than anything too.

And >> I feel like that alone could be its own podcast conversation. What is common

podcast conversation. What is common sense? How do you build? But we'll keep

sense? How do you build? But we'll keep this short. Uh final question. Uh so

this short. Uh final question. Uh so

you've been got more active on Twitterx.

I'm curious just uh why and just what's your experience been with with Twitter, the world of Twitter? Uh because you get a lot of engagement on on Twitterx.

>> So for a long time I used Threads exclusively because I actually helped build threads a little bit back in the day. Um and I also just like the design.

day. Um and I also just like the design.

It's like a very clean product. I I just really like that.

>> I started using Threads cuz actually I was bored. Um so in in December I was in

was bored. Um so in in December I was in Europe.

>> You started using Twitter, you mean?

>> Oh yeah. Yeah. Yeah. I started I started using uh Twitter because I was bored. So

my my wife and I were uh we were traveling around in in Europe for December. We're just kind of nomading

December. We're just kind of nomading around. We went to like Copenhagen, went

around. We went to like Copenhagen, went to like a few different countries. Um

and for me it was just like a coding vacation. So every day I was coding and

vacation. So every day I was coding and that's like my favorite kind of vacation just to just like code all day. It's the

best. And at some point I just kind of got bored and like I ran out of ideas for you know like a few hours. I was

like okay what do I want to do next? And

so I opened Twitter. I saw some people like tweeting about quad code and then I just started responding and then I was like okay maybe actually I think I should do is just like look for people look for bugs that people have maybe

people have like bugs or kind of feedback they have and so kind of introduce myself ask for if people had a bunch of bugs and feedback and I think they were kind of surprised by like the pace at which we're able to address

feedback nowadays. Um, for me it's just

feedback nowadays. Um, for me it's just like so normal like if someone has a bug like I can probably fix it within a few minutes because I just sort of quad and as long as the description is good it'll just go and do it and then I'll I'll go

do something else and answer the next thing. But I think for a lot of people

thing. But I think for a lot of people was pretty surprising. So that was really cool and yeah the experience on Twitter has been pretty great. It's it's

been awesome just engaging with people and seeing what people want uh hearing hearing about bugs, hearing about features. I saw complaints to Nikita

features. I saw complaints to Nikita Beer the other day on Twitter of just you they're like posting many threads and it was breaking and just like oh man what's going on here.

>> Yeah. Yeah. Yeah. There there was a bug.

I hope it's fixed now. Amazing. Oh man,

Boris, I could chat with you for hours.

Uh I'll let you go. Thank you so much for doing this. Uh you're wonderful. Um

where can folks find you online? How can

listeners be useful to you?

>> Yeah, find me on threads or on Twitter.

That's the that's the easiest place. And

please just tag me on stuff. Um, send

bugs, send feature requests, what's missing, what can we do to make the products better? What do you like? What

products better? What do you like? What

do you want? Um, I I love love hearing it.

>> Amazing. Boris, thank you so much for being here.

>> Cool. Thanks, Funny.

>> Bye, everyone.

>> Thank you so much for listening. If you

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

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

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

See you in the next episode.