Inside Claude Code With Its Creator Boris Cherny

At Enthropic, the way

that we thought about it is we don't build for the model of today.

We build for the model six months from now.

That's actually like still my advice to to founders that are building on LLM.

Just try to think about like what is

that frontier where the model is not very good at today cuz it's going

to get good at it.

All of Quad Code has just been written

and rewritten and rewritten

and rewritten over and over

and over.

There is no part of Quad Code that was around 6 months ago.

You try a thing, you give it to users, you talk to users,

you learn, and then eventually you might end up at a good idea.

Sometimes you don't.

Are you also in the back of your mind thinking

that maybe like in 6 months you won't need to prompt

that explicitly?

Like the model will just be good enough to figure out on its own?

>> Maybe in a month, >> no more need for plan mode in a month.

>> Oh my god.

Welcome to another episode of the light cone

and today we have an extremely special guest,

Boris Churnney, the creator engineer of Claude Code.

Boris, thanks for joining us.

>> Thanks for having me.

>> Thanks for creating a thing

that has taken away my sleep for about 3 weeks straight.

>> I am very addicted to Cloud Code and uh it feels like rocket boosters.

Has it felt like this for people like for you know months at this

point.

I think it was like end of November is where uh a lot of

my friends said like something changed.

>> I remember for me I felt this way

when I first created Quad Code

and I didn't yet know

if I was on to something.

I kind of felt like I was on to something

and then that's when I wasn't sleeping.

>> Yeah.

>> And that was just like three straight months.

>> This was uh September 2024.

Yeah.

It was like three straight months.

I I didn't take a single day vacation.

Worked through the weekends.

Worked every single night.

I was just like, "Oh my god,

this is I think this is going to be a thing.

I don't know if it's useful yet because it it couldn't actually code yet."

>> If you look back on uh those moments to now,

like what would be like the most surprising thing about this moment right now?

>> It's unbelievable that we're still using a terminal.

That was supposed to be the starting point.

I didn't think that would be the ending point.

And then the second one is

that it's even useful cuz uh you know at the beginning it didn't really

write code.

Even in February when we G it wrote maybe like 10% of my code

or something like that.

I didn't really use it to write code. it wasn't very good at it.

I still wrote most of my code by hand.

Uh so the fact

that it it actually like our bets paid off

and it got good at the thing

that we thought it was going to get good at

because it wasn't obvious.

At Enthropic, the way

that we thought about it is we don't build for the model of today.

We build for the model 6 months from now.

And that's actually like still my advice to to founders

that are building on LLM is,

you know, just try to think about like what is

that frontier where the model is not very good at today. um

because it's going to get good at it

and you just have to wait.

>> Going back though, but when do you remember when you first got the idea?

Can you just talk us through that?

Like was it some like a spark

or what was even the first version of it in your mind?

>> You know, it's funny.

It was like it was

so accidental that it just kind of evolved into this.

Um you know as

as anthropic I think for Ant the bet has been coding for a long

time and the bet has been the path to save to safe AGI is

through coding >> and this is this has kind of always been the idea

and the way you get there is you you teach the model how to

code then you teach it how to use tools

then you teach it how to use computers um

and you can kind of see

that because the the first team

that I joined at Enthropic it was called the anthropic labs team uh

and it produced three products it was quadcode MCP

and in the desktop app.

So you can kind of see how these like weave together.

The particular product that we built, you know,

like no one no one asked me to build a CLI.

Um we kind of knew maybe it was time to build some kind of

coding product cuz it seemed like the model was ready,

but no one had yet really built the product that harnessed this capability.

So like still there's this insane feeling of product overhang.

But at the time it was just like even crazier cuz like no one

had built this yet.

And so I I started like hacking around uh and I was like, "Okay,

we build a coding product.

What do I have to do first?

I have to understand how to use the API

because I hadn't used anthropic API at

that point."

Um and so I I just built like a little terminal app to use

the API.

That's all that I did.

And it was a little chat app

because you know like you think about the you know AI applications of the

time and you know for non-coders today most what what are most people using

is just a chat app.

So that's what I built.

Uh and you know it was in a terminal.

I can ask questions.

I give answers.

Then I think tool use came out.

I just wanted to try out tool use

because I I don't really understand what this is.

I was like to use this is cool.

Is this actually useful?

Probably not.

Let me just try it.

>> You built it in terminal just

because it was the easiest way to get something up

and running.

>> Yes.

Cuz I didn't have to build a UI.

>> Okay.

>> It was just me >> at that point.

It was like the IDEs, Cursor, Windsurf taking off.

Were you sort of under any pressure or getting lots of suggestions of, hey,

like we should build this out

as a plugin or

as a as a fully featured ID itself?

There was no pressure because we didn't even know what we wanted to build.

Like the the team was just in explore mode, you know,

like we we didn't we know vaguely we wanted to do something in coding,

but it wasn't obvious what no one was high confidence enough.

That was like my job to figure out.

And so I g I gave the model uh the batch tool.

That was the first tool

that that I gave it just cuz I think

that was literally the example in our docs.

I just like took the example.

It was in Python.

I just ported it to TypeScript because that that's how I wrote it.

You know, I didn't know like what the model could do with bash.

So I asked it to like read a file.

It could like cat the file.

So like that was cool.

And then I was like, "Okay, like what can you actually do?"

And and I asked her, "What music am I listening to?"

He wrote some like Apple script to script my my Mac

and look up the music in my music player.

>> Oh my god.

>> And this was Sauna 3.5.

>> And you know, like I I didn't think the model could do that.

And that was my first I think ever fuel the AGI moment >> where

I was just like,

"Oh my god, the model it just wants to use tools.

That's all it wants."

>> That's kind of fascinating.

I mean it's very kind of contrarian

that clocker works so well in such an elegant simple form factor.

I mean terminals have been around for a really long time

and that seemed to be like a good design constraint

that allowed a lot of interesting developer experiences like it doesn't feel like working.

It just feels fun as a developer.

I don't think about files where everything is and that came by accident almost.

>> Yeah, it was an accident.

I remember so after the terminal started to take off internally.

Um and honestly like after building this thing I think like 2 days after

the first prototype I started giving it to my team just for dogfooting cuz

you know like you know

if you come up with an idea

and it seems useful the first thing you want to do is you want

to give it to people to see how they use it.

And then I came in the next day

and then Robert who sits across from me who's another engineer he he just

like had quad code on his computer

and he was like using it to code.

I was like I was like what what are you what are you doing?

Like this thing isn't ready.

It's just a prototype.

But yeah, it it was already useful in that form factor.

And I remember when we did our launch review to kind of launch quad

code externally,

this was in December, November, something like that in 2024.

Um Dario asked and he was like,

"The us chart internally like the the Dow chart is like vertical.

Are you like forcing engineers to use it?

Like why are you mandating them?"

>> And I was just like, "No, no, we didn't.

We I just like posted about it

and they they' just been like telling each other about it."

Honestly, it was it was just accidental.

We we started with the CLI

because it was the cheapest thing

and it just kind of stayed there for a bit.

>> So in that 2024 period, what how were the engineers using it?

Were they sort of shipping code with it yet

or were they using it in a different way?

>> The model is not very good at coding yet.

I I was using it personally for automating git.

Um I think at this point I I probably forgotten most of my git

because cloud code has just been doing it for

so long.

But yeah, like automating uh bash commands

that that was a very early use case

and like operating like Kubernetes

and kind of things like this.

People were using it for coding.

So there were some early signs of this.

I think the first use case was actually writing unit tests

because it's a little bit lower risk

and the model was still pretty bad at it >>

but people were were were kind of figuring it out

and and they were figuring out how to use this thing.

>> Um and one thing

that we saw is people started writing these markdown files for themselves

and then having the model read

that markdown file.

And this is where QuadMD came from.

Probably the single for me biggest principle in product is latent demand.

Um and the just every bit of this product is built through latent demand

after their initial CLI.

Uh and so quadmd is an example of that.

There's this other general principle

that I think is maybe interesting where you can build for the model

and then you can build scaffolding around the model in order to improve performance

a little bit and depending on the domain you can improve performance maybe 10

20% something like that

and then essentially the gain is wiped out with the next model.

So either you can build build the scaffolding

and then you know get some performance gain

and then rebuild it again

or you just wait for the next model

and then you kind of get it for free. the quantumd

and kind of the scaffolding is an example of

that and really I think that's why we stayed in the CLI is

because we felt there is no UI we could build

that would still be relevant in 6 months

because the model was improving

so quickly >> earlier we were saying like we should compare cloud MDs

but you said something very profound

which is you know yours is actually very short

which is almost like the opposite of what you know people might expect why

is that what's in your cloud MD >> okay

so I I checked this before we came

so my my cloud has two Um,

one is, uh, there it's just two lines.

So, the first line is whenever you put up a PR, enable automerge.

Um, so as soon as someone accepts it, it's merged.

That's just so I can like code

and I don't have to kind of go back

and forth with CR

or whatever.

And then the second one is whenever I put up a PR,

post it in our internal team stamps channel.

Uh, just so someone can stamp it and I can get unblocked.

Uh, and the idea is every other instruction is in our quadmd that's checked

into the codebase and it's something our entire team contributes to multiple times a

week.

And very often I'll see someone's PR

and they make some like mistake that's totally preventable

and I'll just literally tag Claude on the PR.

I'll just do like add quad, you know,

like add this to the quad MD and I'll do this, you know,

like many times a week.

>> Do you have to like compact the Claude MD?

Like I definitely reached a point where I got the message at the top

saying your cloud MD is like thousands of tokens now.

What do you do when you guys hit that?

>> So our quadm is actually pretty short.

I think it's like couple thousand tokens maybe something like that.

Um if if you hit this my recommendation would be delete your quadmd

and just start fresh.

>> Interesting.

>> I think a lot of people like they try to overengineer this right

and and really like the capability changes with every model.

And so the thing

that you want is do the minimal possible thing in order to get the

model on track.

And so if you delete your quadd

and then you know the model is getting off track,

it does the wrong thing.

That's when you kind of add back a little bit at a time.

And what you're probably going to find is with every model,

you have to add less and less.

For me, I consider myself a pretty average engineer to be honest.

Like I don't use a lot of fancy tools.

Like I I don't use like Vim.

I use, you know, VS Code because it's simpler.

Um I don't really >> Wait, really?

I would have assumed

that because you built this in the terminal

that you were sort of like a dieh hard ter terminal like Vim Vim

only person you know screw those VS code people you know >> well we

have people like that on the team there's you know like Adam Wolf for

example he's he's on the team he's like you will never take Vim for

my cold dead hands like yeah

so there's definitely a lot of people like

that on the team

and this is one of the things

that I learned early on is every engineer likes to hold their dev tools

differently they like to use different tools there's just no one tool

that works for everyone

but I think also this is one of the things

that makes it possible for quad code to be

so good because I kind of think about it

as what is the product

that I would use

that makes sense to me

and so to use quad code you don't have to understand Vim you don't

have to understand TMX you don't have to know how to like SSH you

don't have to know all the stuff you just have to open up the

tool and it'll guide you it'll it'll do all this stuff >> how do

you decide how verbose you want like sort of the terminal to be like

sometimes you have to go you know control O

and check it out

and is it like internal bike shed battles around like longer shorter I mean

every user probably has a for an opinion like how do you make those

sorts of decisions?

>> What What's your opinion?

Is it is it too verbose right now?

>> Oh, I love the verbosity cuz basically sometimes it just like goes off

the deep end and I'm watching

and then I can just read very quickly

and it's like,

"Oh, no, no, it's not that."

And then I escape

and then just stop it

and then it just like stops an entire bug farm like

as it's happening.

I mean, that's usually when I didn't do plan mode properly.

>> This is something that we probably change pretty often.

Um, I remember early on, this is maybe six months ago,

I tried to get rid of bash output just internally just to like summarize

it because I was like these giant long bash commands,

I don't actually care.

And then I gave it to anthropic employees for a day

and everyone just revolted.

I want to see my dash because it it actually is quite useful for,

you know, like for something like git output, maybe it's not useful,

but if you're running, you know, like Kubernetes jobs or something like this,

you actually do want to see it.

We recently hit the hid the file reads and uh file searches.

So you'll notice instead of saying, you know, like read food.md said,

you know, like read one file, search searched one pattern.

And this is something I think we could not have shipped six months ago

because the model just was not ready.

It would have, you know, it still read the wrong thing pretty often.

As a user, you still had to be there

and kind of catch it

and debug it.

But nowadays, I just noticed it's on the right track almost every time.

And because it's using tools so much,

it's actually a lot better just to summarize it.

Um, but then we shipped it.

Uh, we dog fooded it for like a month

and then people on GitHub didn't like it.

Uh so there was a big issue where people like no like I want

to see the details

and that was really great feedback.

Um and so we added a new verbose mode

and so that's just like in slash config you can enable verbose mode

and if you want to see all the file outputs you can continue to

do that and then I posted on the issue

and people still still didn't like it

which is again awesome

because like my favorite thing in the world is just hearing people's feedback

and hearing how they actually want to use it.

Um and so we just like iterated more

and more and more to get

that really good and to make it the thing

that people want.

I'm amazed like how much I enjoy uh fixing bugs now.

And then all you have to do is uh have really good logging

and then even just say like hey check out

that you know this particular object it messed up in this way

and it like searches the log.

It figures everything out.

It can like go into your you can make a production tunnel

and it'll look at your production DB for you.

It's like this is insane.

Bug fixing is just going to sentry copy markdown.

You know pretty soon it's just going to be straight MCP.

It's like an autobug fixing like

and test making sort of uh what's the new uh term they call it

like a making a startup factory.

Oh yeah.

>> Right.

There's like all these concepts now of rather than having to review the code,

you know, I'm I'm old school, so I like the verbosity.

I like to say, "Oh, well, you're doing this,

but I want you to do that."

Right?

But there's a totally different school of thought now

that says like anytime an a real human being has to look at code

uh that's bad.

>> Yeah.

Yeah.

Yeah.

>> Which is fascinating.

>> I think like Dan Chipper talks about this a lot

as kind of when whenever you see the model make a mistake try to

put in the quadmd try to put it in like skills

or something like that

so it's reusable.

But I I think there's this meta point

that I actually struggle with a lot.

And I people talk about like agents can do this, agents can do that,

but actually what agents can do, it changes with every single model.

And so sometimes there's a new person

that joins the team

and they actually use quad code more than I would have used it.

>> And I'm just constantly surprised by this.

Like for example, there was a we had like a memory leak

and we were trying to debug it.

Um and by the way,

like Jared Sumar has just been on this crusade killing all the memory leaks

and it's just been amazing.

But before Jared was on the team,

I had to do this and there was this memory leak.

I I was trying to debug it.

And so I I took a heap dump.

I opened it in DevTools.

I was looking through the profile.

Then I was looking through the code

and I I was just trying to figure this out.

And then another engineer on the team, Chris, he just like asked Quad Code.

He was like, "Hey, I think there's a memory leak.

Can you like run this?"

And then like try to figure it out.

And Quad Code like took the heap dump.

It wrote a little tool for itself to like analyze the heap dump.

And then it found the leak faster than I did.

And this is just something I have to constantly relearn

because my brain is still stuck somewhere six months ago at times.

>> So what would be some advice for technical founders to really become maximalists

at the latest model release?

It sounds like people off of fresh off of school

or that don't have any assumptions might be better suited than maybe sometimes engineers

who have been working at it for a long time.

And how do the experts get better?

I think for yourself it's kind of beginner mindset

and uh I don't know maybe just like humility like I feel like engineers

as a discipline we've learned to have very strong opinions

and senior engineers are kind of rewarded for this in my old job at

a big company when I hired like architects

and this kind of a type of engineer you look for people

that have a lot of experience

and really strong opinions

but it actually turns out a lot of this stuff just isn't relevant anymore

and a lot of these opinions should change

because the model is getting better um

so I think actually the biggest skill is people

that can think scientifically

and can just think from first principles.

>> How do you screen for

that when you try to hire someone now for for your team?

>> I sometimes ask about what's an example of when you're wrong.

It's a really good one.

You know, some of these like classic behavioral questions like not even coding questions

I think are quite useful

because you can see

if people can recognize their mistake in hindsight,

if they can claim credit for the mistake

and if they learn something from it.

And I think a lot of these like very senior people especially there there

are some founder types like this

but I think founders in particular are actually quite good at it.

Um but other people sometimes will never really take uh they'll never take the

blame for a mistake.

But I don't know like for me personally I'm wrong probably half the time.

Like half my ideas are bad

and you just have to try stuff

and you know you try a thing you give it to users you talk

to users you learn

and then eventually you might end up at a good idea.

Sometimes you don't.

And this is the skill

that I think in in the past was very important for founders,

but now I think it's very important for every engineer.

>> Do you think um you would ever hire someone based on the uh

claude code transcript of uh them working with the agent cuz we're actively doing

that right now.

We just added uh just

as a test like you can upload a transcript of you coding a feature

with cloud code or codeex

or whatever it is.

Personally, I think that like it's going to work.

I mean, you can figure out uh how someone thinks,

like whether they're looking at the logs or not,

like can they correct the agent if it goes off off the rails?

Like, does do they use plan mode?

You know, when they use plan mode,

do they make sure that there are tests or you know,

all of these different things that, >> you know, do they think about systems?

Do they even understand systems?

Like, there's just so much that's sort of embedded in that that I imagine.

I just want like a spider uh a spiderweb graph, you know,

like in those video games like NBA 2K.

It's like, oh, this person's really good at shooting or defense.

It's like you could imagine a spiderweb graph of like, you know,

someone's claude code skill level.

>> Yeah.

What would what would the skills be?

What would be those?

>> I mean, I think it's like systems testing must be like user behavior.

I mean, there's got to be a design part like product sense maybe also

just like automating stuff.

Mhm.

My favorite thing in CloudMD uh for me is I have a thing

that says for every plan decide whether it's overengineered,

underengineered, or perfectly engineered and why.

>> I think this is something that we're trying to figure out, too,

cuz I I think uh

when I look at engineers on the team

that I think are the most effective,

there's essentially two, it's very biodal.

Um there's one side where it's extreme specialists.

Um and so like I named Jared before,

like he's a really good example of this

and kind of the bun team is a really good example.

Just hyper specialist.

They understand dev tools better than anyone else.

They understand JavaScript runtime systems better than anyone else.

And then there's the flip side of kind of hyper generalists

and that's kind of the rest of the team.

And a lot of people they span like product

and info or product

and design um or you know like product

and user research,

product and business.

I really like to see people that just do weird stuff.

I think that's one of these things

that was kind of a warning sign in the past

because it's like can these people actually build something useful?

>> Um that's the limits test.

Yeah, that's what must

but but nowadays like for example an engineer on the team Daisy,

she was on a different team

and then she transferred onto our team

and the reason that I wanted her to transfer is she put up a

PR for Claude Code like a couple weeks after she joined

or something and the PR was to add a new feature to Claude Code

and then instead of just adding the feature what she did is first she

put up a PR to give Claude code a tool

so that it can test an arbitrary tool

and verify that that works.

And then she put up

that PR and then she had Quad write its own tool instead of herself

implementing it.

And I think it's this kind of out of the box thinking

that is is just

so interesting because not a lot of people get it yet.

You know, like we use the Quad agents SDK to automate pretty much every

part of development.

It automates code review, security review.

Uh it labels all of our issues.

It shephards things to production.

It does pretty much everything for us.

But I think externally I'm seeing a lot of people start to figure this

out,

but it's actually taken a

while to figure out how do you use LMS in this way?

How do you use this new kind of automation?

So it's kind of a new skill.

>> I guess one of the uh funnier things

that I've been having office hours with various founders about is um you have

like sort of the visionary founder who has like the idea they've like built

this like crystal palace of the product

that they want to build. they've totally loaded in their brain,

you know, who the user is

and what they feel

and what they're motivated by

and then they're sitting in claude code

and they can do like,

you know, 50x work

and then but they have engineers who work for them who like don't have

the,

you know, crystal memory palace of like the platonic ideal of the product

that the pro founder has

and they can only do like 5x work.

Are you hearing stories like that?

there's usually a person who's like the core like designer of a thing

and they're just like,

you know, trying to blast it out of their brain.

What's the nature of like teams like that?

You know, it seems like that's almost a stable configuration.

Like you're going to have the visionary who like now is unleashed,

but you know, maybe going back to the top of it,

like I'm experiencing this right now.

I was like, "Oh, well, I'm only a solo person and you know,

I need to eat and sleep and I have, you know, a whole job.

It's like, how am I going to do this?"

You know, >> you know, like we just launched quad teams and, you know,

this is a way to do it,

but you can also just build your own way to do it.

It's pretty easy.

>> What's the vision for cloud teams?

>> Just collaboration.

It's like there's this whole new field of like agent top apologies

that people are exploring.

Like what are the ways that you can configure agents?

There's this one sub idea which is uncorrelated context windows.

And the idea is just multiple agents,

they have fresh context windows

that aren't essentially polluted with each other's context

or their own previous context.

And if you throw more context at a problem,

that's like a form of test time compute.

Um, and so you just get more capability that way.

And then if you have the right topology on top of it,

so the agents can communicate in the right way,

they're laid out in the right way, then they can just build bigger stuff.

And so Teams is kind of like one idea.

There's a few more that are coming pretty soon.

Um, and the idea is just maybe it can build a little bit more.

I think the first kind of big example where it worked is our plugins

feature was entirely built by a swarm over over a weekend.

It just ran for like a few days.

There wasn't really human intervention.

And plugins is pretty much in the form

that it was when

when it came out.

>> How did you set that up?

Like did you spec out sort of the outcome

that you were hoping for

and then let it sort of figure out the details

and then like let it run?

>> Yeah. an engineer on the team just gave uh gave Quad a spec

and um told Quad to use a Asauna board

and then Quad just put up a bunch of tickets on a sauna

and then spawned a bunch of agents

and the agent started picking up tasks.

The main quad just gave it instructions

and they all just figured it out >> like independent um agents

that didn't have the context of the bigger spec.

Right.

>> Right.

If you if you think about the way

that uh you know like how our agents actually started nowadays

and you know I haven't pulled the data on this

but I would bet the majority of agents are actually prompted by quad today

in the form of uh sub agents cuz like a sub agent is just

like a recursive quad code that's all it is in the code

and it's just prompted by we call her mama quad >>

and that that's all it is

and I think probably

if you look at most agents they're launched in this way >> my claude

insights just told me to do this more for debugging

so that I get like I spend a lot of time on debugging

And it would just be better to have like multiple sub agents spin up

and like debug something in parallel.

And so then I just like added

that to my claude MD to just be like,

hey, like next time you try

and fix a bug like have one agent

that like looks in the log,

like one that looks in the code path.

That just seems sort of inevitable.

>> For weird scary bugs,

I try to uh fix bugs in plan mode

and then it seems to use the agents to sort of search everything.

Whereas like when you're just trying to do it in line, it's like, okay,

I'm going to do like this one task instead of search wide.

This is something I do all the time too.

I I just say if the if the test seems kind of hard,

this kind of research test,

I'll calibrate the number of sub aents I ask it to use based on

the difficulty of the task.

>> So if it's like really hard,

I'll say like use three or maybe five or even 10 sub aents,

research in parallel and then see what they come up with.

>> I'm curious.

So then why don't you put that in your clawed MD file?

>> It's kind of case by case, you know, like quadm like what is it?

It's just a it's a shortcut.

Like if you find yourself repeating the same thing over and over,

you put in the quad MD.

But otherwise, you don't have to put everything there.

You can just prompt quad.

>> Are you also in the back of your mind thinking

that maybe like in six months,

you won't need to prompt that explicitly?

Like the model will just be good enough to figure out on its own.

>> Maybe in a month.

>> No more need for plan mode in a month.

>> Oh my god.

>> I think plan mode probably has a limited lifespan.

>> Interesting.

>> That's some alpha for everyone here.

What would the world look like without plan mode?

Do you just describe it at the prompt level

and it would just do it?

One shot it?

Yeah, we've uh we've started experimenting with this

because quad code can now enter plan mode by itself.

I don't know if you've you guys have seen that.

>> Yeah.

>> So, we're trying to kind of get this experience really good.

So, it would enter plan mode the same point where a human would have

wanted to enter it.

So, I think it's like I think it's something like this,

but actually plan mode there's no there's no big secret to it.

All it does is it adds one sentence to the prompt that's like please

don't code.

>> That's all it is.

You can you can actually just say that.

>> Yeah.

So it sounds like a lot of the feature development for clock code is

very much a what we talk about a YC talk to your users >>

and then you come

and implemented it.

It wasn't the other way

that you had this master plan

and then implemented all the features.

>> Yeah.

Yeah.

I mean that that's all it was like plan mode was we saw users

that that were like hey quad come up with an idea plan this out

but don't write any code yet.

And there was kind of various versions of this.

Sometimes it was just talking through an idea.

Sometimes it was these very sophisticated specs

that that they were asking Claude to write,

but the common dimension was do a thing without coding yet.

And so literally like this was like Sunday night at 10 p.m.

I was I was just like looking at GitHub issues

and kind of seeing what people were talking about

and looking at our internal Slack feedback channel

and I just wrote this thing in like 30 minutes

and then uh shipped it

that night.

It went out Monday morning.

That was plan mode.

So do you mean

that there will be no need for plan mode to in the sense of

I'm worried that the model's going to do like it's going to do like

the wrong thing or head off in the wrong direction

but there will still be a need for

that.

You need to think through the idea

and figure out exactly what it is

that you want and you have to do

that somewhere.

>> I kind of think about it in terms of like kind of increasing

model capabilities.

So maybe 6 months ago a plan was insufficient.

So you get Claude to make a plan.

Let's say even with plan mode you still have to kind of sit there

and babysit cuz it can go off track.

Nowadays what I do is probably 80% of my sessions I say I say

plan mode has a limited lifespan

but I I'm a heavy plan mode user.

Um I probably 80% of my sessions I start in plan mode

and claude will you know it'll start it'll start making a plan.

I'll move on to my second terminal tab

and then I'll have it make another plan

and then when I run out of tabs I open the desktop app

and then I go to the code tab

and then I just start a bunch of tabs there

and they all start in plan mode probably know like 80% of the time.

Once the plan is good, and sometimes it takes a little back and forth,

they just get clawed to execute.

And nowadays, what I find with Opus 4.5,

I think it started with 4.6 it got really good.

Once the plan is good,

it just stays on track

and it'll just do the thing exactly right almost every time.

And so, you know,

before you had to babysit after the plan and before the plan,

now it's just before the plan.

So, maybe the next thing is you just won't have to babysit.

You can just kind of give a prompt and Quad will figure it out.

>> The next step is Claude just speaks to your users directly.

>> >> Yeah, it just bypasses you entirely.

>> It's funny.

This is actually the current stuff for us.

Our quads actually like they talk to each other.

They talk to our users on Slack, at least internally pretty often.

Um, my quad will like tweet once in a while.

>> No way.

>> Um, but I actually like delete it.

It's just like it's a little like cheesy.

Like I don't love the tone.

>> What does it want to tweet about?

>> Sometimes it'll just like respond to someone cuz I always have like co-work

in the background and it's like it's the co-work

that really loves to do

that because it likes using a browser.

>> That's funny.

A a really common pattern is I ask Quad to build something.

It'll look in the codebase.

Uh it'll see some engineer touch something in the git flame

and then it'll message

that engineer on Slack.

Um just like asking a clarifying question and then once it gets answer back,

it'll keep going.

>> What are some tips for founders now on how to build for the future?

Sounds like everything is really changing.

What are like some principles that will stay on and what will change?

>> So I think some of these are pretty are pretty basic,

but I think they're even more important now than they were before.

Um, so one example is latent demand.

Like I mentioned it a thousand times for me.

It's just like the single biggest idea in product.

It's a it's a thing that no one understands.

It's a thing I certainly did not understand my first few startups.

And and the idea is like people will only do a thing

that they already do.

You can't get people to do a new thing.

If people are trying to do a thing and you make it easier,

that's a good idea.

But if if people are doing a thing

and you try to make them do a different thing,

they're not going to do that.

And so you just have to make the thing

that they're trying to do easier.

And I think quad is going to get increasingly good at kind of figuring

out these kind of product ideas for you just

because it can look at feedback,

it can look at debug logs, it can kind of figure this out.

>> That's what you mean by plan mode was latent demand

that people were already like I don't know had their clawed chat window open

in a browser and were like talking to it to figure out like the

spec and and what it should do.

And now that like pi mode just became

that you just do it in claw code.

>> Yeah.

Yeah, that's it.

Some sometimes what I'll do is I'll just walk around the office on on

our floor and I'll just kind of stand behind people like I I'll say

like hi so it's not

and then um I'll I'll just see kind of like how they're using quad

code.

Um and this is also just something I saw a lot um

but it also came up in GitHub issues like people were talking about it.

It seems like so you're surprised how far the terminal has gone

and how far it's been pushed like how far do you think it has

left to go just given with this world of swore multiple agents like do

you think there's going to be a new a need for a different UI

on top of it?

>> It's funny if you asked me this a year ago I would have

said the terminal has like a threemonth lifespan

and then we're going to move on to the next thing.

Uh and you can see us experimenting with this right

because quad code started in a terminal

but now it's in you know it's on web you can like quadcode it's

in the desktop app you know we've had

that for you know like three months

or six months or something just in the code tab um it's in the

iOS and Android apps just like in the code tab it's in slack it's

in GitHub there's VS Code extensions there's Jet Brains extensions

so we're just like we're always experimenting with different form factors for this thing

to figure out what's the next thing I've been wrong

so far about the of the CLI.

So, I'm probably not the person to forecast that.

>> What about like your advice to DevTool founders?

Like, someone's building a DevTool company today.

Should they just like be building for engineers

and humans or should they be thinking more about like what Claude going to

think and want and build for sort of like the agent?

>> The way I would frame it is think about the thing

that the model wants to do

and figure out how do you make

that easier.

And that's something that we saw, you know,

like when I first started hacking on quad code,

I I realized like this thing just wants to use tools.

It just wants to interact with the world.

And how how do you how do you enable that?

Well, the way you don't do it is you put it in a box

and you're like,

here's the API, here's how you interact with me,

and here's how you interact with the world.

The way you do it is you see what tools it wants to use.

You see what it's trying to do,

and you enable that the same way that you do for your users.

And so, like for if you're building a dev tool startup,

I would think about like what is the problem you want to solve for

the user?

And then when you use when you apply the model to solving this problem,

what is the thing the model wants to do?

>> And then what is the technical

and product solution that serves the weight

and demand of both?

YC's next batch is now taking applications.

Got a startup in you?

Apply at y combinator.com/apply.

It's never too early and filling out the app will level up your idea.

Okay, back to the video.

Back in the day, more than 10 years ago,

you were a very heav heavy user and you wrote a book about TypeScript,

right?

Before Typescript was cool.

This is when everyone was a deep in JavaScript.

This is back in early 2010s, right?

>> Yeah, something like that.

>> Before Typescript was a thing because back then is a very weird language.

It's not supposed to do a lot of things with being typed in JavaScript

and now it's the right thing

and it feels like clot code in the terminal has a lot of parallels

with TypeScript at the beginning.

>> TypeScript makes a lot of really weird language decisions.

So if you look at the type system pretty much anything can be a

literal type for example

and this is like this is super weird cuz like even like like Haskell

doesn't even do this.

It's just like it's too extreme

or it has like conditional types

which I don't think any language thought of at all.

>> It was like very strongly typed.

>> Yeah, it was very strongly

and and the idea was like

when you know like

when Joe Pamer and Anders

and the early team was like building this thing,

the way they built it is we okay,

we have these teams with these big untyped JavaScript code bases.

We have to get types in there,

but we're not going to get engineers to change

that the way that they code.

You're not going to get JavaScript people to have like, you know,

15 layers of class inheritance like you would a Java programmer, right?

They're going to write code the way they're going to write it.

They're they're going to use reflection

and they're going to use mutation

and they're going to use all these features

that traditionally are very very difficult to type.

>> They're a very unsafe type to any strong functional programmer.

>> That's right.

That's right.

That's right.

And so the thing

that they did instead of getting people to kind of change the way

that they code,

they they built a type system around this.

And it was just it's brilliant

because there's all these ideas

that no one was thinking about even in academia like no one thought of

a bunch of these ideas.

It purely came out of the practice of observing people

and seeing how JavaScript programmers want to write code.

And so you know for for quad code it there there are some ideas

that are kind of similar in

that you know like you can use it like a Unix utility.

You can pipe into it.

You can pipe out of it.

Um in some ways it is kind of rigorous in this way

but in in almost every other way it's just the tool

that we wanted. like I I build a tool for myself

and then the team builds the tool for themselves

and then for anthropic employees

and then for users

and it just ends up being really useful.

It's not it's not this like principled

and academic thing which I think the the proof is actually in the results.

Now fast forward more than 15 years later not many codebases are in Haskell

which is more academic

and there's tons of them now on TypeScript

because it's way more practical >> right >>

which is interesting.

Yeah, it is interesting, right?

It's like TypeScript solves a problem.

>> I guess one thing that's cool, I don't know how many people know,

but the terminal is actually one of the most beautiful terminal apps out there

and is actually written with React terminal.

>> When I first started building it, you know,

like I I did front-end engineering for for a while.

So, and I was also like a, you know,

I'm I'm sort of like a hybrid,

like I do like design and user research and, you know,

write code and all this stuff.

And we love hiring engineers that are like this.

Um, so we just we love generalists.

So for me it's like okay, I'm building a thing for the terminal.

I'm actually kind of a shitty Vim user.

So like how do I build a thing for people like me

that um you know are are going to be working in a terminal.

And I think just the delight is so important.

And I feel like at YC this is something you talk about a lot,

right?

It's like build a thing that people love.

If the product is useful but you don't fall in love with it,

that's not great.

Um so it kind of has to do both.

Designing for the terminal honestly has been hard, right?

It's like uh it's like 80 by 100 characters

or whatever. you have like 256 colors,

you have one font size, you don't have like mouse interactions,

there's all this stuff you can't do,

and there's all these very hard trade-offs.

So, like a little known thing, for example,

is you can actually enable mouse interactions in a terminal.

So, you can enable like clicking and stuff.

>> Oh, how do you do that in cloud code?

I've been trying to figure out how to do this.

>> We don't we don't have it in cloud code

because we actually prototyped it a few times

and it felt really bad

because the trade-off is you have to virtualize scrolling

and so there's all these weird trade-offs

because like the way terminals work is like there's no DOM,

right?

It's like there's like anti- escape codes

and these kind of weird organically evolved specs since like the 1960s

or whatever.

>> Yeah.

It feels like BBS's.

It's like a BBS door game.

>> Yeah.

>> Oh my god.

>> That's like that's like a great compliment.

Yeah.

Yeah.

Like it should feel like you're discovering >> Lord of the Red Dragon.

It's fantastic.

Oh my god.

>> Yeah.

But we have we've had to just like discover all these kind of UX

principles for building the terminal cuz no one really writes about this stuff.

And if you look at the big terminal apps of, you know,

like the 80s or 90s or 2000s or whatever,

they use like ed curses

and they have all these like windows

and things like this.

And it just looks kind of like janky by modern standards.

It just looks too heavy and complicated.

And so we had to like reinvent a lot.

And you know, for example, something like the terminal spinner,

like just like the spinner words,

it's gone through probably I want to say like 50 maybe 100 iterations at

this point.

And probably 80% of those didn't ship.

So we tried it, it didn't feel good,

move on to the next one. try it, didn't feel good,

move on to the next one.

Uh, and this was like sort of one of the amazing things about quad

code,

right?

Is like you can write these prototypes

and you can just do like 20 prototypes back to back,

see which one you like,

and then ship that and the whole thing takes maybe a couple hours.

>> Whereas in the past,

what you would have had to do is like wen to use origami

or framer or something like this.

You built like maybe three prototypes, it took like two weeks.

It just took much much longer.

>> And so we have this luxury of we have to discover this new thing.

We have to build a thing.

We don't know what the right endpoint is,

but we can iterate there

so quickly and that's what makes it really easy

and that's what lets us build a product that's like joyous

and that people like to use.

>> Boris, you had other advice for for builders

and we kept interrupting you

because we have so many questions,

but >> I would say um so okay,

so maybe two pieces of advice

that are kind of weird

because it's like about building for the model.

So one is uh don't build for the model of today,

build for the model of 6 months from now.

This is like sort of weird, right?

Because like you can't find PMF if the product doesn't work.

But actually this is the thing

that you should do

because otherwise what will happen is you spend a bunch of work you find

PMF for the product right now

and then you're just going to get leaprogged by someone else um

because they're building for the next model

and a new model comes out every few months.

Use the model, feel out the boundary of what it can do

and then build for the model

that you think will be the model maybe 6 months from now.

I think the second thing is um you know actually in the in the

quad code where in the quad code area where we sit we have a

framed copy of the bitter lesson on the wall.

Um and this is this like rich sutton uh I like everyone should read

it if if you haven't uh

and the idea is the more general model will always be the more specific

model and there's a lot of corlaries to this

but essentially what it boils down to is never bet against the model.

Uh, and so this is just like a thing to

that that we always think about where we could build a feature into cloud

code.

We could make it better as a product and we call this scaffolding.

That's all this code that's not the model itself.

But we could also just wait like a couple months

and the model can probably just do the thing instead.

Um, and there's always this trade-off, right?

It's like engineering work now

and you can kind of extend the capability a little bit,

maybe 10 20% or whatever in whatever domain on this like, you know,

like the spider chart of what you're trying to extend.

Um, or you can just wait and the next model will do it.

So just always always think in terms of this trade-off where where do you

actually want to invest

and assume that whatever the scaffolding is it's just tech.

>> How often do you rewrite the code ways of uh clock code is

every six months with this with this >> is there scaffolding

that you've deleted because you don't need it anymore

because the model just improved.

>> Oh so much.

Yeah.

Like all of quad code has just been written

and rewritten and rewritten

and rewritten over and over

and over.

We unhip tools every couple weeks.

We add new tools every couple weeks.

There's no part of quad code that was around six months ago.

It's just constantly rewritten.

>> Would you say most of the code base for current cloud code is

only say 80% of it is only less than a couple months old.

>> Yeah, definitely.

It might it might even be like less than Yeah,

maybe like a couple months.

That that feels about right.

>> So it's like the life cycle of code now.

That's another alpha is expecting it to be the shelf life to be just

couple months.

>> Yeah.

>> For the best founders.

>> Do you see uh Steve Yaggi's uh post about how awesome working at

Anthropic is?

And I think there's a line in there

that says that an anthropic engineer uh currently averages 1,000x more productivity than a

Google engineer at Google's peak

which is really an insane number honestly like 1,000x like you know we're 3

years ago we were still talking about 10x engineers now we're talking about 1000x

on top of a Google engineer in the prime like this is unbelievable honestly.

Yeah, I mean internally if you if you look at like technical employees,

they all use quad code every day.

Um, and even non-technical employees,

I think like half the sales team uses quad code.

Um, they they've started switching to co-work

because it's a little easier to use.

It has like a VM, so it's a little bit safer.

But yeah, we actually we just pulled a stat

and the I think the team doubled in size last year,

but productivity per engineer grew something like 70%.

>> It's measured by >> just like the simplest stupidest measure, pull requests.

Um, but we also kind of cross check

that against like commits

and like uh the lifetime of commits

and things like this.

And since quad code came out, productivity per engineer at anthropic has grown 150%.

>> Oh my god.

>> Um, and this is crazy

because I in my old life I was responsible for code quality at Meta.

>> Um, and I was responsible for the quality of all of our code

bases across every product across like you know Facebook,

Instagram, WhatsApp, whatever.

>> And one of the things that the team worked on was improving productivity.

And back then seeing a gain of something like 2% in productivity

that was like a year of work by hundreds of people.

And so this like 100% this is just like unheard of just completely unheard

of.

>> What drove you to come over to Anthropic?

I mean basically as a builder you could go anywhere.

What was the moment

that made you say like actually this is the set of people

or this is the approach.

I was living in rural Japan

and I was opening up Hacker News every morning

and I was reading the news

and uh it was all it just started to be like AI stuff at

some point and uh I started to use some of these early products

and uh I remember like the first couple times

that I used it I was just like it just took my breath away.

That was like very cheesy to say,

but that was actually that was actually the feeling.

Like it was just like it was amazing like

as a as as a builder,

I've just never kind of felt felt this feeling like using these very very

early products.

That was like in the quad 2 days or you know something like that.

And so I I just talking started talking to friends at Labs um just

to kind of see what was going on.

Um and uh I met Ben man who's one of the founders at uh

at Anthropic and uh he just immediately won me over.

Um and as soon

as I met kind of the rest of the team at an it just

won me over and I think I think probably in two ways.

So one is it operates as a research lab.

Um so the product was teeny teeny tiny.

It's really all about building a safe model.

That's all that matters.

Um and so this idea of just being very close to the model

and being very close to development

and being not the most important thing

because the product isn't anymore.

It's just the model is the thing that's the most important.

Um that really resonated with me after building product for many years.

And then the second thing was just how missiondriven it is.

Um like I'm I'm a huge sci-fi reader.

My bookshelf is just like filled with sci-fi.

And so like I just know how bad this can go.

>> And when I kind of think about what's going to happen this year,

it you know it's going to be totally insane.

And in the worst case it can go very very bad.

>> Um and so I just wanted to be at a place

that really understood that

and kind of really internalized

that.

And at Ant, you know,

like if you overhear conversations in the lunchroom or in the hallway,

people are talking about AI safety. this is really the thing

that everyone cares about more than anything.

Um, and so I just wanted to be in a place like that.

I I know I know for me personally the mission is just so important.

>> What is gonna happen this year?

>> Okay.

So if you think back like six months ago

and uh kind of what are the predictions

that people are making?

So Daario predicted that 90% of the code at Anthropic would be would be

written by Quad.

This is true.

Um for me personally it's been 100% for like since Opus 4.5.

Um I just I uninstalled my IDE.

I don't edit a single line of code by hand.

It's just 100% quad code and Opus.

Um and you know I land you know like 20 PR a day every

day.

If you look at Enthropic overall it ranges between like 70 to 90% uh

you know depending on the team.

For a lot of teams it's also like 100% for a lot of people

it's 100%.

And I remember making this prediction back in May

when we ged cloud code

that you wouldn't need an ID to code anymore.

Uh and it was totally crazy to say.

I feel like people in the audience gasped >>

because it was such like a silly prediction at the time.

But really all it is is like you just like trace the you know

the exponential >> and this is just like

so deep in you know the DNA at cuz like you know three of

our founders were co-authors of the scaling laws paper they kind of they saw

this very early and

so this is just like tracing the exponential this is what's going to happen

and yes that happened.

So continuing to trace the exponential I think what will happen is coding will

be generally solved for everyone.

Um, and I think today coding is practically solved, you know,

for me and I think it'll be the case for everyone.

Um, you know, regardless of domain,

I think we're going to start to see the title software engineer go away.

And I think it's just going to be maybe builder, maybe product manager,

maybe we'll keep the title as kind of a vestigial thing,

but the work that people do, it's not just going to be coding.

It's software engineers are also going to be writing specs.

They're going to be talking to users. like this thing

that we're starting to see right now in our team where engineers are very

much generalists and every single function on our team codes like our PM's code,

our designers code, our EM codes,

our um like everyone our our finance guy codes like everyone on our team

codes.

We're going to start to see this everywhere.

So this is sort of uh this is kind of like the lower bound

if we just continue the trend.

The upper bound I think is a lot scarier.

Um, and this is something like, you know, we hit ASL4.

Um, and this, you know, at anthropic, we talked about these safety levels.

ASL3 is where the models are right now.

ASL4 is the model is recursively self-improving.

Um, and so if this happens, essentially,

we have to meet a bunch of criteria before we can release a model.

And so the the extreme is that, you know,

this happens um or there's some kind of catastrophic misuse like people are using

the model to design bioiruses,

design zero days, stuff like this.

Um, and this is something

that we're really really actively working on

so that doesn't happen.

I think uh it's just been honestly it's just been like

so exciting and humbling like seeing how people are using quad code like uh

you know I just wanted to build a cool thing

and it ended up being really useful uh

and that was so surprising

and so exciting.

>> My impression from Twitter

or just the outside is basically everyone went away over the holidays

and then like found out about Claude code

and it's just been crazy ever since.

Is that how it was for you at like internally?

Did you were you having like a nice Christmas break

and then came back

and like what happened?

Well, actually for all of December, I was traveling around.

Uh, and I I took a coding vacation.

So, we were kind of traveling around

and I was just like coding every day.

So, that was really nice.

Uh, and then I also started to use Twitter at the time cuz like

I I worked on Threads back

then way back when.

So, I've been a Threads user for a while.

So, I just like tried to see kind of like other platforms where people

are.

Yeah.

I think for a lot of people they kind of discovered

that was the moment where they discovered Opus 4.5.

I kind of already knew.

>> Mhm.

>> Uh, and internally quad code's just been on this like exponential tear for

many many months now.

So that just like it it became even more steep.

That's what we saw.

And if you look at cloud code now, you know,

there was some stat from Mercury

that like 70% of startups are you know choosing cloud

as their model of choice.

There was some other stat from like semi analysis

that 4% of all public commits are made by cloud code. um like of

all code written everywhere.

All the companies, you know,

use squad code from like the biggest companies to kind of, you know,

smallest startups, you know,

like it it wrote it it plotted the course for Perseverance like for like

the Mars rover.

This is just like this is the coolest thing for me.

And we like we even printed posters cuz the team was like, "Wow,

this is just like so cool that NASA chooses to use this thing."

So, yeah, it's just like it's humbling.

Um but it also feels like the very beginning.

What's the sort of interaction between uh claude code

and then co-work like you know was it a fork of cla code?

Was it like you had cla code look at the cloud code

and say let's make a new spec for nontechnical people

that you know keeps all the lessons

and then you know it sort of went off for a couple days

and did that.

What's the genesis of that and you know where do you think that goes?

>> This is going to be like my fifth time using the word wait

and demand.

It was just that I mean like we we were looking at Twitter

and there was like

that one guy that was using quad code to like monitor his tomato plants.

>> Mhm.

>> Uh there was like this other person

that was using it to like recover wedding photos off of a corrupted hard

drive.

There were people that using it for like uh for finance.

When we looked internally at anthropic,

every designer is using it all the entire finance team at this point is

using it.

The entire data science team is using it not for coding.

People are jumping over hoops to install a thing in the terminal

so that they could use this.

So we knew for a

while that we wanted to build something

and so we're experimenting with a bunch of different ideas

and the thing that kind of took off was just you know a little

cloud code wrapper in a guey in the desktop app

and that's all it is.

It's just quad code under the hood.

It's the same agent.

>> Oh wow.

>> Um and uh Felix and the team and Felix was early Electron contributor.

He kind of knows

that stack really well

and he was hacking on various ideas

and uh they they built it in I think something like 10 days.

It was it was just like 100% written by quad code.

Uh and it just felt ready to release.

There was a lot of stuff that we had to build for nontechnical users.

So it's a little bit different than a technical audience.

Uh it runs in a all the code runs in a virtual machine.

Uh there's a lot of delete uh protections for deletion and things like this.

There's a lot of permission prompting and kind of other guardrails for users.

Um yeah, it was honestly pretty obvious.

Boris, thank you so much for making something

that uh is taking away all my sleep,

but in return, it's making me feel creator mode again,

sort of founder mode again.

It's been an exhilarating 3 weeks.

I like can't believe I waited

that long since November to actually get into it.

Thank you so much for being with us.

Thank you for building what you're building.

>> Yeah, thanks for having me.

And uh send bugs.

>> Sounds good.

Come on now.