AI Engineer World's Fair 2025
Claude Code & the evolution of agentic coding
Read the talk
Claude Code and the changing interface of programming
As coding models improve, the interface around them must change too: from completion to delegation, tool use, persistent context, and feedback that lets an agent revise its work.
From a talk by Boris Cherny
Before you start: Basic familiarity with terminals, Git, and automated tests will help with the workflow examples.
What interface does a capable coding model need?
What should a programming tool look like when the model inside it improves faster than the product around it? Boris Cherny, Anthropic technical staff and creator of Claude Code, opens with that problem. Claude is becoming more capable at coding, but the team is still discovering which interfaces make that capability useful. Claude Code therefore starts with a deliberately small, unopinionated product: enough structure to do real work, without assuming that the right interaction has already been found.
At the time of the talk, Cherny points users to the Claude Code installation page or npm. He also announces that Claude Pro support arrived the previous day, alongside existing Max support. These are the entry points into the product as presented in the recording; the larger question is what happens after installation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From physical programs to software abstractions
Programming once meant manipulating physical objects. Cherny traces a broad progression from switchboards to punch cards, then makes that history tangible through his family: his grandfather programmed in the Soviet Union and brought stacks of cards home from work. Cherny’s mother would draw on them with crayons. The program was something a child could pick up and mark.
His historical sketch then moves through assembly, COBOL, typed languages, and C++, followed by the proliferation of language families associated with Haskell, JavaScript, Java, and Python. Each step raises the level at which a programmer describes work. By the time he reaches TypeScript, Rust, Swift, and Go, Cherny feels that many everyday abstractions have begun to converge. That is a characterization of the experience of using these languages, not a claim that their semantics or capabilities are interchangeable.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The interface follows the machine
The language and the interface for manipulating it evolve separately. Punch-card programming used a machine resembling a typewriter; later, text editors and integrated development environments changed how people interacted with software. Cherny’s distinction is that language abstractions appear to be leveling out while model capabilities—and the possible interfaces around them—are accelerating. The IBM 029 keypunch supplies the physical reference point: a substantial piece of equipment for turning keystrokes into holes in cards.
Next comes ed, Ken Thompson’s early Unix line editor at Bell Labs. It was not the first text editor: Dennis Ritchie’s history of QED describes predecessors and identifies Thompson’s contribution. What matters here is how closely ed fits its hardware. Built for teletypes that printed on paper, it had no screen cursor or scrollback to navigate. Its sparse command interaction was a practical response to a machine that could print output but could not redraw a screen.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From seeing code to delegating work
Moving past the innovations of Vim and Emacs, Cherny highlights Smalltalk-80 as a major graphical step. Its environment combined object-oriented programming with live interaction: changes could appear in a running system. His comparison with the effort sometimes required to configure React live reload makes a useful point—an older environment can still offer an interaction that newer stacks struggle to reproduce smoothly. He then presents Visual Basic as a major route by which graphical programming reached mainstream developers.
Eclipse adds another distinct mechanism: static-analysis completion. It indexes symbols, determines which are relevant, and ranks suggestions. That is different from generating code with a model. Its extension ecosystem also expands the environment beyond its built-in capabilities. Copilot then advances from single-line to multiline suggestions; Devin represents the next abstraction in Cherny’s account, where a natural-language request can initiate programming work without the user first writing the code.
| Interface | Programmer supplies | Tool contributes |
|---|---|---|
| Static completion | Code and local context | Ranked existing symbols |
| AI completion | A partially written program | Suggested lines or blocks |
| Natural-language delegation | A description of desired work | Work toward an implementation |
As the interface changes, verification must change alongside it. Cherny moves from manual debugging and physical inspection of outputs to techniques that explore behavior probabilistically, including fuzzing, vulnerability testing, and Netflix-style chaos testing. Generating more code does not remove the need to determine whether it behaves correctly.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A terminal leaves room for the model
Claude Code’s response is to start with the terminal and expose the model as directly as possible while remaining productive. It imposes relatively little interface scaffolding because Anthropic wants people to experience the model’s capabilities—and because the team does not yet know the best UX. Generality is the design choice: let the model use existing tools and fit into existing workflows instead of requiring every workflow to fit a new product structure.
Cherny connects this choice to Rich Sutton’s The Bitter Lesson, which he keeps displayed beside his workspace. Sutton’s argument concerns general methods, especially search and learning, that benefit from increasing computation. Cherny extends that intuition to product design: a general interface may benefit from model improvements more readily than elaborate special-purpose scaffolding. His expectation of exponential model and interface progress is his own framing, rather than a law established by the essay.
The practical result is one product with several surfaces. Run claude in iTerm2, WSL, an SSH connection, a tmux session, or the terminal inside VS Code or Cursor. Inside an IDE, Claude Code adds a small amount of integration: diffs appear in the editor instead of only inline in the terminal, and diagnostics enter the model’s context. Cherny acknowledges that this is less polished than Cursor or Windsurf, both of which he says he uses. The integration supplies useful editor feedback while preserving direct access to the model.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
GitHub and the Unix pipeline
The Claude Code Action moves that same capability into GitHub. The setup flow presented is short: open Claude Code, run /install-github-app, and select a repository. Cherny describes this as using the user’s existing compute and stack, with setup taking a few minutes. His accompanying statement that data stays on that compute needs a narrower interpretation: the action executes on a GitHub runner, but calls the selected model provider for inference. Runner execution does not mean that all processing is local or that no data leaves the runner.
The most flexible surface is what the talk calls the SDK: invoke claude -p programmatically and build the surrounding integration yourself. This removes the need to adopt the interactive terminal UI, IDE integration, or GitHub interface. Cherny’s concrete example is incident triage: pipe GCP logs into Claude, then process the result with jq. The model becomes one stage in a Unix pipeline, accepting input from one tool and returning output for another.
For a local export of GCP logs, that composition can be expressed in shell as:
bash
claude -p 'Analyze these GCP logs for incident triage. Return only a JSON object with summary, likely_causes, and next_checks.' \
< gcp-logs.json \
| jq .
Here the prompt requests JSON and jq parses the returned text; malformed JSON will fail at that boundary. The example retains the talk’s CLI-based integration rather than substituting a later SDK package. Cherny regards this use of models as Unix utilities as largely unexplored: the simple interface lets developers discover useful compositions without waiting for a dedicated product feature.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Ask about the code, then teach the tools
The easiest starting workflow is codebase Q&A. A new user can ask how a system works before asking the agent to change it. At Anthropic, Cherny says engineers learn Claude Code on their first day. Cherny estimates that internal onboarding fell from two or three weeks to perhaps two days after introducing Claude Code. This is an internal estimate, not a controlled productivity benchmark. The immediate benefit is that newcomers can investigate the repository without routing every question through a colleague.
The same retrieval capability helps with work already completed. Before the weekly Monday stand-up, Cherny asks what he shipped during the preceding week. Claude examines his Git commits and produces a work-history summary, so he does not have to maintain that account separately.
Tool integration also becomes a different kind of task. Traditional editors often require plugins written for their extension systems. An agent can instead learn to use an existing command-line tool:
- Make the CLI available through its shell tools.
- Ask Claude to run the CLI’s
--helpcommand. - Have it record the useful usage instructions in
CLAUDE.md.
The tool remains an ordinary CLI; the persistent instructions tell the agent how to operate it. Cherny also points to MCP tools for grouped capabilities and richer integrations, including streaming. A bespoke editor extension is not necessary for every tool the agent needs.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Gather evidence, then give the agent a target
These tools do more than write code, so an effective workflow need not start with implementation. Cherny first asks Claude to explore, make a plan, and bring that plan back for review before editing. The ordering matters for extended thinking too: use tools to gather relevant code and other evidence, then reason over that context. In his experience, thinking before the agent has gathered useful information can spend tokens without producing much value.
His second workflow is test-driven development. He finds it easier to sustain when the model performs the mechanical steps:
- Describe the required tests clearly and state that the implementation does not exist yet.
- Ask Claude to write the tests without running them at this initial stage, then commit them.
- Ask it to write the implementation, then commit the code.
The instruction not to run the tests yet is part of Cherny’s specific sequence: otherwise the agent may immediately try to run them and respond to the expected failures. Separating the test definition from implementation gives the subsequent work an explicit target.
An observable target makes iteration possible. Unit and integration tests are one form of feedback; screenshots from an iOS simulator or Puppeteer are another. In each case, the agent needs a way to inspect what its actions produced. Cherny extends the idea beyond software with a 3D-printer example: Claude could operate the printer and inspect its output through a camera. He reports that later attempts improved on the first. The mechanism is the feedback loop—produce an output, observe it, and revise—not a claim that a particular number of attempts guarantees success.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make approval and context explicit
Plan mode turns the explore-and-review workflow into a product affordance. Announcing its launch during the talk, Cherny demonstrates switching modes with Shift+Tab: Claude prepares a plan and waits for approval instead of carrying out the requested work. His instruction then was to restart Claude to receive the update. In the current interface, the shortcut cycles through modes; press it until Plan mode appears. The durable distinction is between a proposed action and an approved action.
Persistent context supplies the other half of the workflow. A repository-root CLAUDE.md carries project instructions; files in subfolders are pulled in on demand, and home-folder instructions can supply broader preferences. The talk also demonstrates reusable workflows as ordinary Markdown files in .claude/commands, which become available through the slash menu. These mechanisms separate information the agent should retain from instructions the user wants to invoke repeatedly.
For adding information to memory, the demonstrated version uses #: ask Claude to remember something, then choose the destination memory when prompted. Cherny closes the prepared talk by describing this memory interface as rough but functional. The team has a first version that works and wants feedback about where the interaction succeeds or fails. Persistent instructions introduce a new design problem for coding tools: users need to understand not just what the agent knows now, but where that knowledge will be stored for future work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
When several Claudes are working at once
The closing question moves from an individual agent to several concurrent delegations: how should someone work when ten sessions are active, each running for roughly ten minutes? Those numbers describe the question’s scenario, not a measured capacity or speed. Cherny recognizes the pattern among power users: multiple terminal tabs, with sessions operating in separate codebase checkouts or Git worktrees.
GitHub Actions offers another way to launch parallel work. Cherny says that most of these use cases do not require coordination between the agents. When they do, his proposed mechanism is simple: ask them to write to a Markdown file. Separate workspaces let sessions proceed independently; a shared written artifact gives them a place to communicate when their tasks actually depend on one another.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Rich Sutton's essay on why general methods that scale with computation succeed across AI tasks.
Official GitHub integration with setup instructions and examples for issue handling, pull requests, and automation.
Further reading
A firsthand history tracing QED's development and its descendants, including ed and vi.
Updates since the talk
Current guidance for planning, supplying context, using tools, and verifying agent work.
Current instructions for noninteractive CLI calls, log pipelines, structured output, and jq processing.
- Claude Code data usageDocumentation
Explains inference data flows, local and cloud execution, and account-dependent data policies.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hello.
- 0:21
This is awesome. This is a big crowd. Who here has used Claude Code before? [audience cheering]
- 0:26
Jesus. [audience laughing] Awesome. That's what we like to see.
- 0:30
Cool. So my name is Boris. I'm a member of technical staff at Anthropic and creator of Claude Code.
- 0:38
And, um [audience applauding] I was struggling with what to talk about for a audience that already knows Claude Code, already knows AI, and all the coding tools, and agentic coding, and stuff like that.
- 0:51
So I'm gonna zoom out a little bit, and then we'll zoom back in.
- 0:56
So here's my TLDR. The model is moving really fast. It's on exponential. It's getting better at coding very, very quickly, as everyone that uses the model knows. And the product is kinda struggling to keep up.
- 1:10
We're trying to figure out what product to build that's good enough for a model like this, and we feel like there are so many more products that could be built for models that are this good at coding, and we're kinda building the bare minimum, and I'll kind of talk about why.
- 1:22
And with Claude Code, we're trying to stay unopinionated about what the product should look like because we don't know.
- 1:33
So for everyone that didn't raise your hand, I think that's, like, 10 of you, uh, this is how you get Claude Code.
- 1:38
Um, you can head to claude.ai/code to install it. Uh, you can run this incantation to install from npm. Um, as of yesterday, we support Claude Pro plans, so you can try it on that.
- 1:49
Uh, we support Claude Max. So yeah, just try it out. Tell us what you think.
- 1:56
So programming is changing, and it's changing faster and faster. And if you look at where programming started back in, you know, the 1930s, '40s, there were, there was, like, switchboards, and it was this physical thing.
- 2:08
There was no such thing as software. And then sometime in the 1950s, punch cards became a thing. And my, uh, my, my grandpa actually in the Soviet Union, he was one of the first programmers in the, in the Soviet Union, and my mom would tell me stories about, like, you know, when she grew up in the 1970s
- 2:24
or whatever, he would bring these big stacks of punch cards home, and she would... Like, from work, and, and she would, like, draw all over them with crayons.
- 2:33
And that was growing up for her, and that, that's what programming was back, back in the 1950s, '60s, '70s even. But sometime in the late '50s, we started to see these higher level languages emerge.
- 2:43
So first there was Assembly. So programming moves from hardware to punch cards, which is still physical, to, to software. And then the level of abstraction just went up. So we got to COBOL, then we got to typed languages, we got to C++.
- 2:57
In the early '90s, there was this explosion of these new language families. There was, you know, the Haskell family and, um, you know, JavaScript and Java, the evolution of the C family, and then Python.
- 3:09
And I, I think nowadays if you kinda squint, all the languages sort of look the same. Like, when I write TypeScript, it kinda feels like writing Rust, and that kinda feels like writing Swift, and that kinda feels like writing Go.
- 3:18
The abstractions have started to converge a bit.
- 3:23
If we think about the UX of programming languages, this has also evolved. Back in the 1950s, you used something like a typewriter to punch holes in punch cards, and that was programming back in the day.
- 3:37
And at some point, text editors appeared, um, and then, uh, Pascal and all these different IDs, uh, appeared that let you interact with your programs and your software in new ways, and each one kinda brought something.
- 3:51
And I, I feel like programming languages have sort of leveled out, but the model is on a exponential, and the UX of programming is also on a exponential. And I'll talk a little bit more about that.
- 4:02
Does anyone know what was the first text editor?
- 4:09
Okay. I heard, I heard ed from someone. I think you read the screen.
- 4:14
Before... Well, before text editors, this is what programming looked like. So this was the IBM 029. This was kind of a, a top-of-the-line. This was, like, the MacBook of the time for programming punch cards.
- 4:22
Everyone had this. You can still find it in museums somewhere.
- 4:28
And yeah, this is ed. This is the, the first text editor. This was, uh, Ken Thompson at, at Bell Labs invented this. And, you know, it kinda looks familiar.
- 4:37
If you open your MacBook, you can actually still type ed. This is still, uh, still distributed on Unix, uh, as, as part of Unix systems, and this is crazy 'cause this thing was invented, like, 50 years ago.
- 4:47
And this is nuts. Like, there, there's no cursor. There's no scroll back. Uh, there's no fancy commands. There's no typeahead. There's pretty much nothing. This is the simple text editor of the time, and it was built for Teletype machines, which were literally physical machines that printed paper- on paper.
- 5:01
That's how your program was printed. And this is the first software manifestation of a UX for programming software. So it was really built for these machines that didn't support scroll back and cursors or anything like that.
- 5:15
Um, for all the Vim fans, I'm gonna jump a- jump ahead of Vim. Vim was a big innovation. Emacs was a big innovation around the same time. I think in 1980, Smalltalk-80 was a big, uh...
- 5:24
It was a big jump forward. This is one of the first, I think the first graphical interface for programming for software. And, um, for anyone that's tried to set up, like, live reload with React or Redux or any of the stuff, this thing had live reload in 1980, and it worked.
- 5:43
And we're still kinda struggling to get that to work with, like, React.js nowadays.
- 5:49
So this, this was a big jump forward. And obviously, like, the language, it had object-oriented programming and a bunch of new concepts, but on the UI side, there was a lot of new things too.
- 5:58
In '91, I think Visual Basic was the first code editor that introduced a graphical paradigm. To the mainstream. So before, people were using text-based editors. Vim and things like that were still very popular despite things like Smalltalk.
- 6:11
Um, but this kind of brought it mainstream. This is what I grew up with.
- 6:15
Eclipse brought type-ahead to the mainstream. This isn't using AI type-ahead. This is not Cursor or Windsurf. This is just using static analysis. So it's indexing your symbols, and then it can rank the symbols and re-rank them, and it knows what symbols to show.
- 6:27
I think this was also the first big third-party ecosystem for IDEs.
- 6:35
Copilot was a big jump forward with single line type-ahead and then multi-line type-ahead.
- 6:41
And I think Devin was probably the first IDE that introduced this next concept and this next abstraction to the world, which is to program, you don't have to write code.
- 6:52
You can write natural language, and that becomes code. And this is something people have been trying to figure out for decades. I think Devin is the first product that broke through and, and took this mainstream.
- 7:06
And the UX has evolved quickly, but I think it's about to get even faster.
- 7:14
We talked about, uh, UX, and we talked about programming languages, and verification is a part of this too. Um, so verification has started with manual debugging and, like, physically inspecting outputs.
- 7:23
Um, and now there's a lot of probabilistic verification, uh, like fuzzing and vulnerability testing and, uh, like Netflix's chaos, uh, testing and things like that.
- 7:35
And so with all this in mind, Claude Code's approach is a little different.
- 7:39
It's to start with a terminal and to give you as low-level access to the model as possible in a way that you can still be productive. So we want the model to be useful for you.
- 7:48
We also wanna get... We wanna be unopinionated, and we wanna get out of the way. So we don't give you a bunch of flashy UI. We don't try to put a bunch of scaffolding in the way.
- 7:58
Some of this is we're a model company at Anthropic and s- you know, we make models, and we want people to experience those models. But I think another part is we actually just don't know.
- 8:07
Like, we don't know what the right UX is, so we're starting simple.
- 8:11
And so Claude Code, it's intentionally simple. It's intentionally general. Um, it shows off the model in the ways that matter to us, which is they can use all your tools, and they can fit into all your workflows.
- 8:21
So you can figure out how to use the model in this world where the UX of using code and using models is changing so fast.
- 8:31
And so this is my second point. The model just keeps getting better. And this is the better lesson. I have it, uh, I have, I have this, like, framed and taped to the side of my wall
- 8:41
because the more general model always wins, and the model increases in capability exponentially, and there are many corollaries to this. Everything around the model is also increasing exponentially, and the more general thing, even around the model, usually wins.
- 8:59
So with Claude Code, there's one product, and there's a lot of ways to use it. Um, so there's a terminal product, and, you know, this is the thing everyone knows.
- 9:06
So you can install Claude Code, and then y- you just run Claude in any terminal. We're unopinionated, so it works in iTerm2. It works in WSL. Um, it works over SSH and Tmux sessions.
- 9:19
Uh, it works in your VS Code terminal, in your Cursor terminal. This works anywhere, in any terminal.
- 9:28
When you run, when you run Claude Code in a IDE, we do a little bit more. So we kinda take over the IDE a little bit and, you know, diffs instead of being inline in the terminal, they're gonna be big and beautiful and show up in the IDE itself.
- 9:40
Um, and we also ingest diagnostics. Um, so we kinda try to take advantage of that. And you'll notice this isn't as polished as something like, uh, again, like Cursor or Windsurf.
- 9:50
These are awesome products, and I use these every day. Um, this is to let you experience the model in a low-level, raw way, and this is sort of the minimal that we had to do to let you experience them.
- 10:06
We announced a couple weeks ago that you can now use Claude on GitHub.
- 10:10
Can I get a show of hands who's, who's tried this already?
- 10:14
Yeah. Cool. So for everyone that hasn't tried this, all you have to do is, uh, you open up Claude. You run this one slash command, install GitHub app. You pick the repo, and then you can run Claude in any repo.
- 10:25
Um, this is running on your compute. Um, your data stays on your compute. It does not go to us. Um, so it's, it's kind of a nice experience, and it lets you use your existing stack.
- 10:34
You don't have to change stuff around. Takes a few minutes to set up. And again, here we intentionally built something really simple because we don't know what the UX is yet, and this is the minimal possible thing that helps us learn but also is useful for engineers to do day-to-day work.
- 10:48
Like, I use this every day. The extreme version of this is our SDK, and this is something that you can use to build on Claude Code, uh, without, um...
- 11:02
If you don't wanna use, like, you know, the terminal app or the IDE integration or GitHub, you can just roll your own integration. You can build it however you want.
- 11:08
People have built all sorts of UIs, all sorts of awesome integrations. And all this is, is you run claude -p, and, uh, you can use it programmatically.
- 11:18
And so, like, something I use it for, for example, is, uh, for incident triage. I'll take my GitHub logs, uh, or my... Sorry, my GCP logs. I'll pipe it into Claude -p 'cause it's like, it's a Unix utility, so you can pipe in, you can pipe out.
- 11:30
Um, and then I'll, like, jq the result. So it's kinda cool. Like, this is a new way to use models. This is maybe 10% explored. No one has really figured out how to use models as a Unix utility.
- 11:41
This is another aspect of code as UX
- 11:45
that we just don't know yet. And so again, we just built the simplest possible thing so we can learn and so people can try it out and see what works for you.
- 11:55
Okay. I wanted to give a few tips for how to use Claude Code. This is a talk about Claude Code, so this is kinda zooming back in. Um, and, uh, this is actually true for, I think, a lot of coding agents, but this is kinda custom to the way that I personally use Claude Code.
- 12:09
So the simplest way to use this, um, it seems like most of this room is very familiar with Claude Code and similar coding agents. Um, but the simplest way to introduce new people that have not used this kind of tool before is do codebase Q&A.
- 12:22
And so on f- at Anthropic, we teach Claude Code to every engineer on day one, and it's shortened onboarding times from like two or three weeks to like two days maybe.
- 12:31
And also, I don't get bugged about questions anymore
- 12:34
'cause people can just ask Claude. And honestly, like, I'll just ask Claude too.
- 12:39
And then this is something that I do, uh, pretty much every day. On Monday we have a stand-up every week. I'll just ask Claude what did I ship that week.
- 12:45
It'll look through my Git commits, and it'll, it'll tell me so I don't have to keep track.
- 12:51
The second thing is teach Claude how to use your tools, and this is something that has not really existed before when you think about the UX of programming. Um, with every IDE, it, there's sort of like a plugin ecosystem.
- 13:02
You know, for Emacs there's this kind of wispy dialect that you use to make plugins. If you use Eclipse or VS Code, you have to make plugins. For this new kind of coding tool, it, it can just use all your tools.
- 13:11
So you give it batch tools, you give it MCP tools. Something I'll often say is, "Here's the CLI tool, Claude. Run --help. Take what you learn, and then put it in the claude.md."
- 13:22
And now Claude knows how to use the tool. That's all it takes.
- 13:26
You don't have to build a bridge. You don't have to build an extension. There's nothing fancy like that. Um, of course, if you have like groups of tools or if you have fancier functionality like streaming and things like this, you can just use MCP as well.
- 13:40
Traditional coding tools focused a lot on actually writing the code, and I think the new kinds of coding tools, they do a lot more than that. And I think this is a lot of where people that are new to these tools struggle to figure out how to use them.
- 13:53
So there's a few workflows that I've discovered for using Claude Code most effectively for myself. The first one is have Claude Code explore and make a plan and run it by me before it writes code.
- 14:06
Um, you can also ask it to use thinking. So typically we see extended thinking work really well if Claude already has something in context. So have it use tools, have it pull things into context, and then think.
- 14:15
If it's thinking upfront, you're probably just kinda wasting tokens and it's, it's not gonna be that useful. But if there's a lot of context, it does help a bunch.
- 14:25
The second one is TDD. Um, I know I try to use TDD. It's like [laughs] it's pretty hard to use in practice. But I think now with coding tools, it actually works really well.
- 14:34
Um, and maybe the reason is it's not me doing it, it's the model doing it.
- 14:39
And so the workflow here is tell Claude to write some tests and kind of describe it in. Just make it really clear. Like, the tests aren't gonna pass yet.
- 14:45
Don't try to run the test, 'cause it's gonna try to run the test. Tell it like, you know, it's not gonna pass. Write the test first, commit, and then write the code and then commit.
- 14:54
And this is kind of a general case of if Claude has a target to iterate against, it can do much better. So if there's some way to verify the output, like a unit test, integration test, uh, a way to screenshot in your iOS simulator, uh, a way to screenshot in Puppeteer, just some way to see its output.
- 15:09
Um, we actually did this for robots. Like, we taught Claude how to use a 3D printer, and then it has this little camera to see the output. If it can see the output and you let it iterate, the result will be much better than if it couldn't iterate.
- 15:20
The first shot will be all right, but the second or third shot will be pretty good. So gi- give it some kinda target to iterate against.
- 15:30
Today we launched Plan mode in Claude Code,
- 15:35
and this is a way to do the first kinda workflow more easily. So any time, hit Shift+Tab
- 15:42
and Claude will switch to Plan mode. So you can ask it to do something, but it won't actually do that yet. It'll just make a plan, and it'll wait for approval.
- 15:49
So restart Claude to get the update. Run Shift+Tab.
- 15:55
Okay, and then the final tip is, uh, give Claude more context. There's a bunch of ways to do this. claude.md is the easiest way. So take a, this file called claude.md, put it in the root of your repo.
- 16:04
You can also put it in subfolders. Those will get pulled in on demand. You can put it in your home folder. This will get pulled in as well. Um, and then you can also use slash commands.
- 16:12
Um, so if you put files, like just regular markdown files in these special folders, .claude/commands,
- 16:20
it'll be available under the slash menu. So pretty cool. This is useful for resu- uh, reusable workflows.
- 16:29
And then to add stuff to claude.md, um, you can always type the pound sign to ask Claude to memorize something, and it'll prompt you which memory this should be added to.
- 16:36
And you can see this is us trying to figure out how to use memory, how to use this new concept that is new to coding models, did not exist in previous IDEs, how to make the UX of this work.
- 16:46
And you can tell this is still pretty rough. This is our first version, but it's the first version that works. And so we're gonna be iterating on this, and we really want to hear feedback about what works about this UX and what doesn't.
- 16:59
Thanks. [audience applauding]
- 17:08
Thank you, Boris. Unfortunately, we only have one minute left, so someone sent a question on Slack. The question is, "As I delegate more and more to Claude Code, as it runs for 10 minutes and I have 10 of these active, how do I use the tool?"
- 17:22
You got 50 seconds. [laughs] [laughs]
- 17:26
Yeah. This is, it's, it's pretty cool. I think this is something that we se- actually see in a lot of our power users, that they tend to like multi-Claude.
- 17:32
You don't just have a single Claude open, but you have a couple terminal tabs, either with a few checkouts of Claude or, uh, or of your codebase, or it's the same codebase but with different worktrees, and you have Claude doing stuff in parallel.
- 17:44
This is also a lot easier with GitHub Actions 'cause you can just spawn a bunch of actions and get Claude to do a bunch of stuff. Typically, we don't like need to coordinate between these Claudes, I think for most use cases.
- 17:53
If you do want to coordinate, the best way is just ask them to write to a markdown file. Um, and that's it.
- 18:00
Awesome.
- 18:00
Yeah.
- 18:00
Well-
- 18:00
The whole thing works
- 18:01
... thank you so much. And once again, give it up for Boris from Anthropic. [upbeat music]