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, [laughter]

>> 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. [laughter]

>> 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. [laughter]

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

[laughter] 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 [laughter] 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

[laughter]

>> 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 [laughter] 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.

[laughter]

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, [laughter] 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. [laughter]

>> 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. [snorts]

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

>> [laughter]

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

[laughter] 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 [laughter]

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 [music]

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

[laughter] 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

[laughter]

>> 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 [laughter]

>> 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 [laughter] 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?

[laughter]

>> 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 [clears throat] 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. [laughter]

>> Sounds good.

Come

on now.

[music]