the engineer who built Claude Code just dropped a 28-minute video on how to write prompts

Hello.

Everyone,

uh I'm Boris. I'm a member of technical

staff here at Anthropic, and I created

Quad Code.

And here to talk to you a little bit

about some practical tips and tricks for

using Quad Code.

Um it's going to be very practical. I'm

not going to go too much into the

history or the theory or anything like

this.

Uh and yeah, before we start, actually,

can we get a quick show of hands, who

has used Quad Code before?

Yeah. All right, that's what we like to

see.

For everyone that didn't raise your

hands, uh I know you're not supposed to

do this while people are talking, but if

you can open your laptop and type this.

And this will help you install Quad

Code, uh just so you can follow along

for the rest of the talk.

All you need is Node.js. If If you have

it, it should work.

Yeah, if you Well, you don't have to you

don't have to follow along, but if you

don't have it yet, yeah, this is your

chance to install it so you can follow

along.

So, what is Quad Code? Quad Code is a

new kind of AI assistant, and there's

been different generations of AI

assistants for coding. Most of them have

been about completing, you know, like a

line at a time, completing a few lines

of code at a time.

Quad Code is not for that. It's fully

agentic. So, it's meant for building

features, for writing entire functions,

entire files,

fixing entire bugs at at the same time.

And what's kind of cool about Quad Code

is it works with all of your tools, and

you don't have to change out your

workflow. You don't have to swap

everything to start using it. So,

whatever IDE you use, if you use VS Code

or if you use Xcode, or if you use uh

JetBrains IDEs,

there's some people at Anthropic that

you can't pry them from their cold, dead

hands, but they use Quad Code

because Quad Code works with every

single IDE, every terminal out there.

It'll work locally, over remote SSH,

over tmux, whatever environment you're

in,

you can run it.

It's general purpose, and this is

something where if you haven't used

these kind of free-form coding

assistance in the in the past, it can be

kind of hard to figure out how to get

started cuz you open it up and you just

see a prompt bar, and you might wonder

like what do I what do I do with this?

What do I type in?

It's a power tool, so you can use it for

a lot of things, but also because it can

do so much, we don't try to guide you

towards a particular workflow. Because

really, you should be able to use it

however you want as an engineer.

As you open up Quad Code for the first

time, there's a few things that we

recommend doing

to get your environment set up. And

these are pretty straightforward. So,

run terminal setup. This will give you

shift enter for new lines, so you don't

have to do like backslashes to enter new

lines. This is, you know, it it makes it

a little bit nicer to use.

Do /theme to set light mode or dark mode

or Daltonize themes.

Um you can do /install GitHub app. So,

today when we announced a GitHub app,

where you can at-mention

uh Claude on any GitHub issue or pull

request. So, to install it, just run

this command in in your terminal.

Um you can customize the set of allowed

tools that you can use, so you're not

prompted for it every time. This is

pretty convenient um for stuff that I'm

prompted about a bunch, I'll definitely

customize it in this way, so I don't

have to accept it every time.

And something that I actually do is for

a lot of my prompts, I won't hand type

them into a Quad Code. If you're on

macOS, you can go into your system

settings under accessibility is

dictation, and you can enable it. And

so, something I do is you just hit like

that dictation key twice, and you can

just speak your prompt.

And it helps a lot to have specific

prompts. So, this is actually pretty be

You can just talk to Quad Code and like

you would another engineer and you don't

have to type a lot of code.

So, when you're starting out with Claude

code, it's so free form and it can do

everything. What do you start with? The

thing I recommend above everything else

is starting with code base Q&A. So, just

asking your question asking questions to

your code base.

This is something that we teach new

hires at Anthropic. So, on the first day

in technical onboarding, you learn about

Claude code, you download it, you get it

set up and then you immediately start

asking questions about the code base.

And in the past when you're doing

technical onboarding, it's something

that taxes the team a lot.

Right? You have to ask other engineers

on the team questions.

You have to look around the code and

this takes a while. You have to figure

out how to use the tools. This This

takes a long time.

With Claude code, you can just ask

Claude code and it'll explore the code

base, it'll answer these kind of

questions. And so, at Anthropic,

onboarding used to take about two or

three weeks for technical hires, it's

now about two or three days.

What's also kind of cool about Q&A is we

uh we don't do any sort of indexing. So,

there's no remote database with your

code. We don't upload it anywhere. Your

code stays local. We do not train

generative models on the code.

So, it's there, you control it, there's

no indices or anything like this.

And what that means is also there's no

setup. So, you start Claude, you

download it, you start it, there's no

indexing, you don't have to wait, you

can just use it right away.

This is a technical talk. So, um I'm

going to show some very specific prompts

and very specific code samples that you

can use and hopefully improve and up

level your Claude code experience.

So, some kind of questions that you can

ask is uh you know, like how is this

particular piece of code used or how do

I instantiate this thing? And Claude

code, it won't just do like a text

search and try to answer this. It'll

often go a level deeper and it'll try to

find examples of how is this class

instantiated? How is it used?

And it'll give you a much deeper answer.

So, something that you would get out of

a wiki or documentation instead of just

like command F.

Something that I do a lot also is ask

about Git history.

So, for example, you know, why does this

function have 15 arguments and why are

the arguments named this weird way?

And this is something I bet in all of

our code bases, you have some function

like this or some class like this.

And Cloud Code can look through Git

history and it'll look to figure out how

did these arguments get introduced and

who introduced them and what was the

situation? What are the issues that

those commits link to? And it'll look

through all this and summarize it. And

you don't have to tell it that in all

these in all this detail.

You just ask it. So, just say look

through Git history and it'll know to do

this.

The reason it knows it, by the way, is

not because we prompted it to. There's

nothing in the system prompt about

looking through Git history. It knows it

because the model was awesome. And if

you tell it to use Git, it'll know how

to use Git.

So, we're lucky to be building on such a

good model.

I often ask about GitHub issues. So, you

know, it can use web fetch and it can

fetch issues and look up context on

issues, too, and this is pretty awesome.

And this is something that I do every

single Monday in our weekly stand-up is

I ask what did I ship this week and

Cloud Code looks at the log, it knows my

username and it'll just give me a nice

readout of everything I I shipped. And

I'll just copy and paste that into a doc

somewhere.

So, yeah, that's tip number one for

people that have not used Cloud Code

before. If you're just showing it to

someone for the first time, onboarding

your team, the thing we definitely

recommend is start with code base Q&A.

Don't start by using fancy tools, don't

start by editing code, just start by

asking questions about the code base and

that'll teach people how to prompt. And

it'll start teaching them this boundary

of like what can Cloud Code do? What is

it capable of versus what do you need to

hold its hand with a little bit more?

What can be one-shotted? What can be

two-shotted, three-shotted? What do you

need to use interactive mode for in a

repl?

Once you're pretty comfortable with Q&A,

you can dive into editing code.

This is the next thing.

And the cool thing about uh any sort of

agentic,

you know, like using a LLM in a agentic

way is you give it tools and it is just

like magical. It figures out how to use

the tools.

And with Quad Code, we give it a pretty

small set of tools. It's not a lot.

And so, it has a tool to edit files. It

has a tool to run bash commands. It has

a tool to search files. And it'll string

these together to explore the code,

brainstorm, and then finally make edits.

And you don't have to prompt it

specifically to use this tool and this

tool and this tool. You just say, you

know, do this thing and it'll figure out

how to do it. It'll string it together

in the right way that makes sense for

Quad Code.

There's a lot of ways to use this.

Something I like to do sometimes is

before having Quad jump in to write

code, I'll ask it to brainstorm a little

bit or make a plan.

This is something we highly recommend

and something I see sometimes is people,

you know, they take Quad Code and they

ask it, "Hey, implement this enormous

like 3,000 line feature." And sometimes

it gets this right on the first shot.

But sometimes what happens is the thing

that it builds is not at all the thing

that you wanted.

And the easiest way to get the result

you want

is ask it to think first. So, brainstorm

ideas, make a plan, run it by me, ask

for approval before you write code.

And you don't have to use plan mode. You

don't have to use any special tools to

do this. All you have to do is ask Quad.

And it'll know what to do this. So, just

say, "Before you write code, make a

plan." That's it.

This is also I want to think with this

one this commit push here. This is a

really common incantation that I use.

There's nothing special about it, but

Quad is kind of smart enough to

interpret this. So, it'll make a commit.

It'll push it to the branch, make a

branch, and then make a pull request for

me on GitHub. You don't have to explain

anything. It'll look through the code.

It'll look through the history. It'll

look through the git log by itself to

figure out the commit format and all the

stuff. And it'll make the commit and

push it the right way.

Again, we're not system prompting it to

do this. It just knows how to do this.

The model was good.

As you get a little bit more advanced,

you're going to want to start to plug in

your team's tools. And this is where

Quad Code starts to really shine.

And there's generally two kinds of

tools. So, one is bash tools. And an

example of this, I just made up this

like barley CLI. This isn't a real

thing.

Um but you can say use this CLI to do

something. And you can tell Quad Code

about this. And you can tell it to use,

for example, like {dash} {dash} help to

figure out how to use it. And this is

efficient.

If you find yourself using it a lot, you

can also dump this into your quad MD,

which we'll talk about in a bit. So,

Quad can remember this across sessions.

But this is a common pattern we follow

at Anthropic. And we see external

customers use, too.

And same thing with MCP. Um Quad Code

can use bash tools. They can use MCP

tools. So, you know, just tell it about

the tools. And you can add MCP tool, and

you can tell it how to use it, and it'll

it'll just start using it.

And this is extremely powerful cuz when

you start to use code on a new code

base, you can just give it all of your

tools, all the tools your team already

uses for this code base, and Quad Code

can use it on your behalf.

There's a few common workflows.

And this is the one that I talked about

already. So, kind of do a little bit of

exploration, do a little bit of

planning, and ask ask me for

confirmation before you start to write

code.

These other two on the right are

extremely powerful.

When Quad has some way to check its

work, so for example, by writing unit

tests or screenshotting in Puppeteer or

screenshotting the iOS simulator,

then it can iterate.

And this is incredible because if you

give it, for example, a mock and you say

build this web UI, it'll get it pretty

good. But if you let it iterate two or

three times, often it gets it almost

perfect.

So, the trick is give it some sort of

tool that it can use for feedback to

check its work. And then based on that,

it will iterate by itself, and you're

going to get a much better result.

So, for whatever your domain is, if it's

unit test or integration test or

screenshots for apps or web or anything,

just give it a way to see its result and

it'll iterate and get better.

So, these are the next steps. Teach Quad

how to use your tools and figure out the

right workflow. If you want Quad to jump

in a code, if you want it to brainstorm

a little bit, make a plan, if you want

it to iterate, kind of have some sense

of that so you know how to prompt Quad

to do what you want.

As you go deeper, beyond tools, you want

to start to give Quad more context. And

the more context, the smarter the

decisions will be because as an engineer

working in a code base, you have a ton

of context in your head about your

systems and all the history and and

everything else. So, you can there's

different ways to give this to Quad.

And as you give Quad more context, it'll

do better.

There's different ways to do this. The

simplest one is what we call Quad MD.

And quad.md is the special file name.

The simplest place to put it is in the

project root. So, the same directory you

start Quad in,

put a quad.md in there and that'll get

automatically read into context at the

start of every session. And essentially,

the first user turn will include the

quad.md.

You can also have a local quad.md and

this one you don't usually check into

source control. So, quad.md you should

check into source control, share with

your team so that you can write it once

and share it with your team.

This one you don't check in. It's just

for you.

The kinds of things you put in quad.md,

it's like common bash commands, common

MCP tools,

architectural decisions, important

files, anything that you would kind of

typically need to know in order to work

in this code base.

Try to keep it pretty short cuz if it

gets too long, it's just going to use up

a bunch of context and it's usually not

that useful. So, just try to keep it as

short as you can.

And for for example, in our code base,

we have uh

common bash commands, we have a style

guide, we have a few core files, kind of

things like that.

All the other quad MDs, you can put them

in other nested child directories, and

quad will pull them in on demand.

So, these are the quad MDs that will get

pulled in automatically. Um but then

also you can put in put quad MDs in

nested directories, and those will get

put those will get automatically pulled

when quad works in those directories.

Um and of course, if you're, you know, a

company, maybe you want a quad MD that's

shared across all the different code

bases, and you want to manage it on

behalf of your users, and you can put it

in your enterprise root, and that'll get

pulled in automatically.

There's a ton of ways to pull in

context. I actually had a lot of trouble

putting this slide together just to

communicate the breadth of ways you can

do this.

But, quad MD is pulled in automatically.

You can also use slash commands. So,

this is dot quad slash commands, and

this can be in your home directory, or

it can be checked into your project. And

this is for slash commands.

And over here,

we have a few examples of the slash

commands that we have in quad code

itself.

And so, for example, if you're in the

quad code repo, and you see issues

getting labeled, that's actually this

workflow running here. It's label GitHub

issues.

And we have a GitHub action running, the

same one we talked about this morning,

where quad code will run this command,

and it's just a slash command. It'll

run, and it'll label the issues, so

humans don't have to. It just saves us a

bunch of time.

And of course, you can add mention files

to pull them into context. Um and like I

said before, quad MDs in a nested

directory get pulled in when quad works

in that directory.

So, give quad more context, and it's

definitely worth taking the time to tune

context. You can run it through a prompt

improver, consider

who the context is for, if you want to

pull it in every time, if you want to

pull it in on demand, if you want to

share it with a team, if it's a personal

preference.

Definitely take the time to tune it.

This will improve performance

dramatically

uh if you do it right.

As you get more advanced,

you're going to want to think about this

a little bit more of this kind of

hierarchy of different ways to pull in

everything. So like not just Quad MD,

but also config and

uh

kind of everything about Quad you can

pull in in this hierarchical way.

So projects uh are specific to your Git

repo, and this you can check in or you

can make it just for you.

You can also have global configs that

are for across all your projects, or you

can have enterprise policies. And this

is essentially a global config that you

roll out for all of your employees,

everyone on your team automatically.

And this slide is like pretty

information dense, but the point is this

applies to a lot of stuff. So you can do

this for slash commands, you can do it

for permissions. So for example, if you

have a bash command that you would run

for all your employees, uh like all your

employees use this like test command for

example,

you can actually just check it into this

enterprise policies file,

and then any employee when they run this

command, it will be auto-approved, which

is pretty convenient.

And you can also use this to block

commands. So for example, let's say

there's a URL that should never be

fetched, um just add it to this config,

and that'll make it so an employee

cannot override it. And that that URL

can never be fetched.

So pretty convenient both to unblock

people and also just to keep your code

base safe.

And then same thing for MCP servers.

Have a MCP JSON file, check it into the

code base, that way anytime someone runs

Quad code in your code base, they'll be

prompted to install the MCP servers. And

share it with the team.

If you're not sure which of these to

use, this is like a kind of an insane

matrix cuz we support a lot of stuff,

and engineer workflows are very

flexible, and every company is

different, so we kind of want to support

everything. So if you're not sure how to

get started, I would recommend start

with shared project context.

You write this once, and then you share

it with everyone on the team, and you

get this kind of network effect where,

you know, someone does a little bit of

work, and everyone on the team benefits.

There's a lot of tools built into Quad

to manage this. Uh so, as an example, if

you run {slash} memory, you can see all

the different memory files that are

getting pulled in. So, maybe I have an

enterprise policy, I have my user

memory, I have project Quad MD, and then

maybe there's a nested Quad MD. That's

only pulled in for certain directories.

And then, similarly, when you do {slash}

memory, you can edit particular memory

files. When you type pound sign to

remember something, you can pick which

memory you want it to go to.

So, yeah, that's the next tip. Take the

time to configure

Quad MD, MCP servers, all the stuff that

your team uses, so that you can use it

once, configure it once, and then share

it with everyone.

Um an example of this is uh in our apps

repo uh for Anthropic, this is like the

repo that we have all of our web and

apps code in. There's a Puppeteer MCP

server, and we share this with the team.

Um and there's an MCP JSON checked in,

so any engineer working in that repo can

use Puppeteer in order to pilot

end-to-end tests and to screenshot

automatically and iterate, so that every

engineer doesn't have to install it

themselves.

This is a talk about pro tips, so I I

just want to take a quick interlude to

talk about some common key bindings that

people may not know. It's a It's very

hard to build for a terminal. It's also

very fun. It feels like rediscovering

this new design language. But, something

about terminals is is It's extremely

minimal. And so, sometimes it's hard to

discover these key bindings. And here's

just a quick reference sheet. So,

anytime, you can hit shift tab to accept

edits.

Uh and this switches you into auto

accept edits mode. So, bash commands

still need approval, but edits are auto

accepted. And you can always ask Quad to

undo them later.

Um for example, I'll do this if I know

Quad's on the right track, or if it's

writing unit tests and iterating on

tests, I'll usually just switch into

auto accept mode, so I don't have to

okay every single edit.

Anytime you want Claude to remember

something, so for example, if it's not

using a tool correctly and you want it

to use it correctly from then on, just

type the pound sign and then tell it

what to remember and it'll remember it.

It'll incorporate it into Claude MD

automatically.

If you ever want to drop down to bash

mode, so just run a bash command, you

can hit the exclamation mark and type in

your command. That'll run locally, but

that also goes into the context window.

So, Claude will see it on the next turn.

Um and this is pretty good for

long-running commands if you know

exactly what you want to do or any

command that you want to get into

context. And Claude will see the command

and the output.

You can @ mention files and folders. Uh

anytime you can hit escape to stop what

Claude is doing. Um no matter what

Claude is doing, you can always save if

we hit escape. It's not going to corrupt

the session. It's not going to mess

anything up. So, maybe Claude is doing a

file edit. I'll hit escape. I'll tell it

what to do differently. Or maybe it

suggested a 20-line edit and I'm like,

"Actually, 19 of these lines look

perfect, but one line you should

change." I'll hit escape. I'll tell it

that and then I'll tell it to redo that

edit.

Uh you can hit escape twice to jump back

in history.

Um and then after you're done with the

session, you can start Claude with the

resume to resume that session if you

want. Um or dash dash continue.

And then anytime if you want to see more

output, hit control R and that'll show

you the entire output, the same thing

that Claude sees in its context window.

The next thing I want to talk about is

the Claude Code SDK. So, we talked about

this at the top. Uh right after this,

Sid is doing a session, I think just

across the hallway and he's going to go

super deep on the SDK. If you hadn't

played around with this, if you use the

dash P flag in Claude, this is what the

SDK is.

And we've been adding a bunch of

features over the last few weeks to make

it even even better.

Um so yeah, you can you can build on top

of this. You can do cool stuff. This is

exactly the thing that Claude Code uses.

It's exactly the same SDK.

And so for example, something you can do

is quad-p. So this is the the CLI SDK.

You can pass up you can pass a prompt.

You can pass some allowed tools which

could include specific bash commands.

And you can tell it which format you

want. So you might want JSON or you

might want streaming JSON if you want to

process this somehow.

So this is awesome for for building on.

We use this in CI all the time. We use

this for incident response. We use this

in all sorts of pipelines. So really

convenient. Just think of it as like a

Unix utility. You give it a prompt, it

gives you JSON. You can use this in any

way. You can pipe into it, you can pipe

out of it.

The piping is also pretty cool. So you

can use like for example get status and

pipe this in and you know use JQ to

select the result. It

The combinations are endless and it's

sort of this new idea. It's like a super

intelligent Unix utility. And I think

we've barely scratched the surface of

how to use this. We're just figuring

this out.

You can read from like a GCP bucket,

read you know like a giant log and pipe

it in and tell quad to figure out what's

interesting about this log.

Um you can fetch data from like the

century uh CLI. You can also pipe it in

and have quad do something with it.

The final thing and this is probably

like the most advanced use cases we see.

I'm sort of a quad normie. So I'll have

usually like one quad running at a time

and maybe I'll have like a few terminal

tabs for a few different repos running

at a time. When I look at power users in

and out of Anthropic,

almost always they're going to have like

SSH sessions. They'll have uh like tmux

tunnels into their quad sessions.

They're going to have a bunch of

checkouts of the same repo so that they

can run a bunch of quads in parallel in

that repo. Or they're using Git

worktrees to have some kind of isolation

as they do this.

And we're actively working on making

this easier to use, but uh

for now like these these are some ideas

for for to do more work in parallel with

Cloud. You can run as many sessions as

you want.

Uh and there's a lot that you can get

done in parallel.

So, yeah, that's it. I wanted to also

leave some time for Q&A.

So, I think this is the last slide that

I have. And yeah, if folks have

questions, there's mics on both sides.

And yeah, would love to answer any

questions.

>> [applause]

>> Skip the file command.

>> [laughter]

>> I did. Slide five.

>> [laughter]

>> Hey Boris. Um thanks for building a

Cloud Code. And I was wondering what was

the hardest implementation like part of

the implementation for you

of building it?

I think there's a lot of tricky parts.

Um I think one part that is especially

tricky is the things that we do to make

bash commands safe.

Um bash is inherently pretty dangerous

and it can change system state in

unexpected ways. But at the same time,

if

you have to manually approve every

single bash command, it's super annoying

as an engineer and you can't really be

productive cuz you're just constantly

approving every command.

And just kind of navigating how to do

this safely in a way that that scales

across the different kinds of code bases

people have cuz not everyone runs their

code in a Docker container.

Um was was pretty tricky. And

essentially the thing we landed on is

there's some commands that are

read-only. There's some static analysis

that we do in order to figure out which

commands can be combined in safe ways.

And then we have this pretty complex

tiered permission system so that you can

allow list and block list commands at

different levels.

Hi Boris.

You mentioned uh giving an image to

Cloud Code which made me wonder if

there's some sort of multimodal

functionality that I'm not aware of. Is

that Are you just pointing it at an

image on the file system or something?

Yeah, so Claude code is fully

multimodal. Um it has been from the

start. It's in a terminal, so it's a

little uh hard to discover.

Uh but yeah, you can take a image and

just drag and drop it in. That'll work.

Uh you can give it a file path. That'll

work. Um you can copy and paste the

image in and that works, too.

Um so I'll use this pretty often for if

I have like a mock of something, I'll

just drag and drop drop in the mock.

I'll tell it to implement it. I'll give

it a puppeteer server so it can iterate

against it. And yeah, it's just fully

automated.

Um hey, uh

why did you build a CLI tool instead of

an IDE?

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

think there's probably two reasons. One

is uh

we started this at Anthropic and at

Anthropic people use a broad range of

IDEs. And some people use VS Code, other

people use Zed or Xcode or Vim or Emacs.

And it was just hard to build something

that works for everyone. And so terminal

was just the common denominator.

The second thing is at Anthropic, we're

uh

we see up close how fast the model is

getting better.

And so I think there's a good chance

that by the end of the year people

aren't using IDEs anymore.

And so we want to get ready for this

future and we want to avoid

over-investing in UI and other layers on

top given that

the way the models are progressing, it

just it might not be useful work pretty

soon.

Yeah.

How much have you I don't know if this

is Is this on?

How much have you Claude code for

machine learning modeling and almost

that auto ML experience? I was curious

what the experience has been so far with

that. Yeah, I think I think the question

was how much are we using Claude code

for machine learning and and modeling.

We actually use it for this a bunch, so

both engineers and researchers at

Anthropic use Claude code every day. Um

I think about 80% of people at Anthropic

that are technical use Claude code every

day.

And hopefully you can see that in the

product and kind of the amount of love

and dogfooding we've put into it.

Um but this includes researchers who use

tools like the notebook notebook tool to

edit and run notebooks.

Okay, very cool. Thank you.

All right, I think that's it. Thanks.

[applause]

>> [music]

[music]