Passer au playerPasser au contenu principal
♾Stéphane Aknin
🚨 Une ressource incontournable pour tous ceux qui souhaitent mieux exploiter Claude Code.

L’ingénieur à l’origine de Claude Code vient de publier une vidéo de 28 minutes particulièrement riche, dédiée aux techniques de prompting réellement efficaces.

Au programme : structuration de fichiers `CLAUDE.md`, gestion de la mémoire, sessions parallèles et méthodes de prompting encore trop peu utilisées.

Que vous soyez développeur, débutant en IA ou déjà utilisateur régulier de Claude, cette vidéo peut transformer votre manière de travailler dès aujourd’hui.

À enregistrer, regarder et partager à votre réseau. 🎯

🚨 An essential resource for anyone looking to get more out of Claude Code.

The engineer behind Claude Code has just released a highly valuable 28-minute video on prompting techniques that actually deliver results.

Topics include: structuring `CLAUDE.md` files, memory management, parallel sessions, and underused prompting strategies.

Whether you’re a developer, just getting started with AI, or already a regular Claude user, this video could transform the way you work from today.

Save it, watch it, and share it with your network. 🎯


#ClaudeCode #IntelligenceArtificielle #IA #PromptEngineering #DeveloppementWeb #Developpeur #Productivite #Tech #Innovation #Coding #Programmation #NoCode #Automatisation #OutilsIA
Transcription
00:03Hello. Hey everyone. I'm Boris. I'm a member of technical staff here at Anthropic and I created
00:10QuadCode. And here to talk to you a little bit about some practical tips and tricks for using
00:14QuadCode. It's going to be very practical. I'm not going to go too much into the history or the
00:20theory or anything like this. And yeah, before we start, actually, can we get a quick show of hands
00:25who has used QuadCode before? Yeah, that's what we like to see. For everyone that didn't raise your
00:33hands, I know you're not supposed to do this while people are talking, but if you can open your
00:37laptop and type this, and this will help you install QuadCode just so you can follow along
00:46for the rest of the talk. All you need is Node.js. If you have it, this should work.
01:01Yeah, you don't have to follow along, but if you don't have it yet,
01:05yeah, this is your chance to install it so you can follow along.
01:11So what is QuadCode? QuadCode is a new kind of AI assistant, and there's been different
01:17generations of AI assistants for coding. Most of them have been about completing a line at a time,
01:23completing a few lines of code at a time. QuadCode is not for that. It's fully agentic. So it's meant
01:29for building features, for writing entire functions, entire files, fixing entire bugs at the same time.
01:37And what's kind of cool about QuadCode is it works with all of your tools, and you don't have to
01:42change out your workflow, you don't have to swap everything to start using it. So whatever IDE you
01:47use, if you use VS Code, or if you use Xcode, or if you use JetBrains IDEs, there's some people
01:54at Anthropic that you can't pry them from their cold, dead hands, but they use QuadCode. Because
01:59QuadCode works with every single IDE, every terminal out there. It'll work locally over remote SSH,
02:06over Tmux, whatever environment you're in, you can run it.
02:12It's general purpose, and this is something where if you haven't used these kind of free-form coding
02:17assistants in the past, it can be kind of hard to figure out how to get started. Because you open
02:22it up and you just see a prompt bar, and you might wonder, like, what do I do with this?
02:25What do I
02:25type in? It's a power tool, so you can use it for a lot of things. But also, because it
02:31can do so much,
02:31we don't try to guide you towards a particular workflow. Because really, you should be able to
02:35use it however you want as an engineer.
02:42As you open up QuadCode for the first time, there's a few things that we recommend doing
02:46to get your environment set up. And these are pretty straightforward. So run terminal setup,
02:51this will give you shift enter for new lines, so you don't have to do, like, backslashes to enter
02:55new lines. This is, you know, it makes it a little bit nicer to use.
02:58Do slash theme to set light mode or dark mode or daltonize themes.
03:04You can do slash install GitHub app. So today we announced a GitHub app where you can add mention
03:11Cloud on any GitHub issue or pull request. So to install it, just run this command in your terminal.
03:18You can customize the set of allowed tools that you can use so you're not prompted for it every time.
03:23This is pretty convenient. For stuff that I'm prompted about a bunch, I'll definitely customize it in this
03:27way so I don't have to accept it every time. And something that I actually do is for a lot
03:32of
03:32my prompts, I won't hand type them into QuadCode. If you're on macOS, you can go into your system
03:37settings under accessibility as dictation and you can enable it. And so something I do is you just
03:42hit, like, that dictation key twice and you can just speak your prompt. And it helps a lot to have
03:48specific prompts. So this is actually pretty awesome. You can just talk to QuadCode and, like you would,
03:52another engineer and you don't have to type a lot of code.
03:59So when you're starting out with QuadCode, it's so freeform and it can do everything. What do you
04:04start with? The thing I recommend above everything else is starting with codebase Q&A. So just asking
04:09your question, asking questions to your codebase. This is something that we teach new hires at
04:14Anthropic. So on the first day in technical onboarding, you learn about QuadCode, you download it,
04:19you get it set up, and then you immediately start asking questions about the codebase.
04:23And in the past, when you were doing technical onboarding, it's something that taxes the team a
04:27lot. You have to ask other engineers on the team questions, you have to look around the code,
04:32and this takes a while, you have to figure out how to use the tools, this takes a long time.
04:37With QuadCode, you can just ask QuadCode and it'll explore the codebase, it'll answer these kind of
04:41questions. And so at Anthropic, onboarding used to take about two or three weeks for technical
04:45hires, it's now about two or three days. What's also kind of cool about Q&A is we don't do
04:53any
04:53sort of indexing. So there's no remote database with your code, we don't upload it anywhere,
04:58your code stays local, we do not train generative models on the code. So it's there, you control it,
05:04there's no indices or anything like this. And what that means is also there's no setup. So you start
05:09Quad, you download it, you start it, there's no indexing, you don't have to wait, you can just use it
05:12right away. This is a technical talk, so I'm going to show some very specific prompts and very specific
05:20code samples that you can use and hopefully improve and up level your QuadCode experience.
05:25So some kind of questions that you can ask is, you know, like how is this particular piece of code
05:29used or how do I instantiate this thing? And QuadCode, it won't just do like a text search and try
05:34to
05:34answer this, it'll often go a level deeper and it'll try to find examples of how is this class
05:39instantiated? How is it used? And it'll give you a much deeper answer, so something that you would
05:44get out of a wiki or documentation instead of just like command F. Something that I do a lot also
05:50is
05:51ask it about git history. So for example, you know, why does this function have 15 arguments and why are
05:57the arguments named this weird way? And this is something I bet in all of our code bases you have
06:01some function like this or some class like this. And QuadCode can look through git history and it'll look to
06:07figure out how did these arguments get introduced and who introduced them and what was the situation?
06:11What are the issues that those commits link to? And it'll look through all this and summarize it.
06:15And you don't have to tell it that in all these in all this detail, you just ask it. So
06:20just say look
06:20through git history and it'll know to do this. The reason it knows, by the way, is not because we
06:25prompted it to. There's nothing in the system prompt about looking through git history. It knows it because the model
06:30is awesome.
06:31And if you tell it to use git, it'll know how to use git. So we're lucky to be building
06:35on such a good model.
06:38I often ask about GitHub issues. So, you know, it can use webfetch and it can fetch issues and look
06:45up context on issues too, and this is pretty awesome. And this is something that I do every single Monday
06:51in our weekly standup is I ask what did I ship this week? And QuadCode looks to the log, it
06:56knows my username,
06:56and it'll just give me a nice readout of everything I shipped. And I'll just copy and paste that into
07:01a doc somewhere. So yeah, that's tip number one. For people that have not used QuadCode before,
07:09if you're just showing it to someone for the first time, onboarding your team, the thing we definitely
07:13recommend is start with codebase Q&A. Don't start by using fancy tools, don't start by editing code,
07:18just start by asking questions about the codebase. And that'll teach people how to prompt. And it'll start
07:23teaching them this boundary of what can CloudCode do, what is it capable of, versus what do you need
07:28to hold its hand with a little bit more? What can be one-shotted, what can be two-shotted, three
07:31-shotted,
07:32what do you need to use interactive mode for in a REPL?
07:38Once you're pretty comfortable with Q&A, you can dive into editing code.
07:41This is the next thing. And the cool thing about any sort of agentic, you know, like using LM in
07:49agentic ways, you give it tools, and it's just like magical. It figures out how to use the tools.
07:53And with QuadCode, we give it a pretty small set of tools. It's not a lot. And so it has
07:58a tool to edit files.
07:59It has a tool to run bash commands. It has a tool to search files. And it'll string these together
08:04to explore
08:04the code, brainstorm, and then finally make edits. And you don't have to prompt it specifically to use this tool
08:11and this tool and this tool. You just say, you know, do this thing, and it'll figure out how to
08:14do it.
08:15It'll string it together in the right way. That makes sense for QuadCode.
08:22There's a lot of ways to use this. Something I like to do sometimes is before
08:26having Quad jump in to write code, I'll ask it to brainstorm a little bit or make a plan.
08:32This is something we highly recommend. And something I see sometimes is people, you know,
08:36they take QuadCode and they ask it, hey, implement this enormous like 3,000 line feature.
08:42And sometimes it gets this right on the first shot. But sometimes what happens is the thing
08:46that it builds is not at all the thing that you wanted. And the easiest way to get the result
08:50you
08:50want is ask it to think first. So brainstorm ideas, make a plan, run it by me, ask for approval
08:57before you write code. And you don't have to use plan mode, you don't have to use any special tools
09:01to do this. All you have to do is ask Cloud and it'll know to do this. So just say,
09:06before you write code,
09:06make a plan. That's it. This is also, I want to think for this one, this commit push PR, this
09:13is
09:13a really common incantation that I use. There's nothing special about it, but Quad is kind of
09:17smart enough to interpret this. So it'll make a commit, it'll push it to the branch, make a branch,
09:21and then make a pull request from me on GitHub. You don't have to explain anything. It'll look
09:24through the code, it'll look through the history, it'll look through the Git log by itself to figure
09:28out the commit format and all the stuff. And it'll make the commit and push it the right way.
09:34Again, we're not system prompting it to do this. It just knows how to do this. The model is good.
09:41As you get a little bit more advanced, you're going to want to start to plug in your team's tools.
09:46And
09:46this is where Quad code starts to really shine. And there's generally two kinds of tools. So one is
09:50batch tools. And an example of this, I just made up this like barley CLI, this isn't a real thing.
09:56But you can say, use the CLI to do something. And you can tell Quad code about this. And you
10:01can tell
10:01it to use, for example, like dash dash help to figure out how to use it. And this is efficient.
10:06If you find yourself using it a lot, you can also dump this into your Quad MD, which we'll talk
10:10about
10:10in a bit, so Quad can remember this across sessions. But this is a common pattern we follow at Anthropic,
10:15and we see external customers use too. And same thing with MCP. Quad code can use bash tools,
10:22it can use MCP tools. So, you know, just tell it about the tools. And you can add the MCP
10:26tool,
10:26and you can tell it how to use it, and it'll just start using it. And this is extremely powerful,
10:32because when you start to use code on a new code base, you can just give it all of your
10:36tools,
10:37all the tools your team already uses for this code base, and Quad code can use it on your behalf.
10:47There's a few common workflows. And this is the one that I talked about already. So kind of do a
10:53little
10:53bit of exploration, do a little bit of planning, and ask me for confirmation before you start to
10:58write code. These other two on the right are extremely powerful. When Cloud has some way to
11:04check its work, so for example, by writing unit tests or screenshotting in Puppeteer or screenshotting
11:09the iOS simulator, then it can iterate. And this is incredible, because if you give it, for example,
11:15a mock, and you say, build this web UI, it'll get it pretty good. But if you let it iterate
11:20two or
11:20three times, often it gets it almost perfect. So the trick is give it some sort of tool that it
11:26can use
11:26for feedback to check its work. And then based on that, it will iterate by itself, and you're going
11:31to get a much better result. So whatever your domain is, if it's unit tests or integration tests or
11:35screenshots for apps or web or anything, just give it a way to see its result, and it'll iterate and
11:41get better. So these are the next steps. Teach Quad how to use your tools and figure out the right
11:50workflow. If you want Quad to jump into code, if you want it to brainstorm a little bit, make a
11:54plan,
11:54if you want it to iterate, kind of have some sense of that so you know how to prompt Quad
11:58to do what you
11:59want. As you go deeper, beyond tools, you want to start to give Quad more context. And the more
12:08context, the smarter the decisions will be, because as an engineer working in a codebase, you have a
12:12ton of context in your head about your systems and all the history and everything else. So there's
12:17different ways to give this to Quad. And as you give Quad more context, it'll do better.
12:23There's different ways to do this. The simplest one is what we call QuadMD. And
12:27Quad.md is the special file name. The simplest place to put it is in the project root. So the
12:33same directory you start Quad in, put a QuadMD in there. And that'll get automatically read into
12:39context at the start of every session. And essentially, the first user turn will include
12:43the QuadMD. You can also have a local QuadMD. And this one, you don't usually check into source control.
12:51So QuadMD, you should check into source control, share with your team so that you can write it once and
12:55share it with your team. This one, you don't check in. It's just for you. The kinds of things you
13:01put
13:02in QuadMD, it's like common bash commands, common MCP tools, architectural decisions, important files,
13:08anything that you would kind of typically need to know in order to work in this codebase. Try to keep
13:13it pretty short, because if it gets too long, it's just going to use up a bunch of context. And
13:17it's
13:17usually not that useful. So just try to keep it as short as you can. And for example, in our
13:22codebase,
13:23we have common bash commands, we have a style guide, we have a few core files, kind of things like
13:28that.
13:29All the other QuadMDs, you can put them in other nested child directories,
13:32and Quad will pull them in on-demand. So these are the QuadMDs that will get pulled in automatically,
13:39but then also you can put QuadMDs in nested directories, and those will get automatically
13:44pulled when Quad works in those directories. And of course, if you're a company, maybe you want
13:51QuadMD that's shared across all the different codebases, and you want to manage it on behalf
13:54of your users, and you can put it in your enterprise route, and that will get pulled in automatically.
14:03There's a ton of ways to pull in context. I actually had a lot of trouble putting this slide
14:06together just to communicate the breadth of ways you can do this. But QuadMD is pulled in automatically.
14:12You can also use slash commands. So this is .quad slash commands, and this can be in your home
14:16directory, or it can be checked into your project. And this is for slash commands. And over here,
14:23we have a few examples of the slash commands that we have in Cloud Code itself. And so, for example,
14:30if you're in the Cloud Code repo, and you see issues getting labeled, that's actually this workflow
14:34running here. It's labeled GitHub issues. And we have a GitHub action running, the same one we talked
14:39about this morning, where Cloud Code will run this command, and it's just a slash command. It'll run,
14:45and it'll label the issues so humans don't have to. It just saves us a bunch of time.
14:50And of course, you can add mention files to pull them into context. And like I said before,
14:55QuadMDs in a nested directory get pulled in when Quad works in that directory.
15:03So give Quad more context. And it's definitely worth taking the time to tune context. You can run it
15:09through a prompt improver. Consider who the context is for. If you want to pull it in every time,
15:14if you want to pull it in on-demand, if you want to share it with a team, if it's
15:17a personal
15:17preference, definitely take the time to tune it. This will improve performance dramatically,
15:22if you do it right.
15:27As you get more advanced, you're going to want to think about this a little bit more,
15:31this kind of hierarchy of different ways to pull in everything. So like,
15:34not just QuadMD, but also config and kind of everything about Quad you can pull in in this
15:41hierarchical way. So projects are specific to your Git repo, and this you can check in,
15:46or you can make it just for you. You can also have global configs that are across all your projects,
15:51or you can have enterprise policies. And this is essentially a global config that you roll out for
15:55all of your employees, everyone on your team automatically.
15:59And this slide is like pretty information dense, but the point is this applies to a lot of stuff.
16:04So you can do this for slash commands, you can do it for permissions. So for example, if you have
16:08a bash command that you would run for all your employees, like all your employees use this like
16:13test command, for example. You can actually just check it into this enterprise policies file,
16:18and then any employee, when they run this command, it will be auto-approved, which is pretty convenient.
16:23And you can also use this to block commands. So for example, let's say there's a URL that should never
16:27be
16:27fetched. Just add it to this config, and that'll make it so an employee cannot override it. And
16:33that that URL can never be fetched. So pretty convenient, both to unblock people and also just
16:37to keep your code base safe. And then same thing for MCP servers. Have a MCP JSON file, check it
16:44into
16:44the code base. That way, any time someone runs quad code in your code base, they'll be prompted to
16:48install the MCP servers and share it with the team.
16:55If you're not sure which of these to use, this is like a kind of an insane matrix, because we
16:59support
16:59a lot of stuff, and engineer workflows are very flexible, and every company is different. So we
17:03kind of want to support everything. So if you're not sure how to get started, I would recommend
17:07start with shared project context. You write this once, and then you share it with everyone on the
17:11team, and you get this kind of network effect where, you know, someone does a little bit of work,
17:15and everyone on the team benefits. There's a lot of tools built into quad to manage this.
17:23So as an example, if you run slash memory, you can see all the different memory files that are
17:27getting pulled in. So maybe I have an enterprise policy, I have my user memory, I have project quad
17:33MD, and then maybe there's a nested quad MD that's only pulled in for certain directories.
17:39And then similarly, when you do slash memory, you can edit particular memory files. When you type
17:44pound sign to remember something, you can pick which memory you wanted to go to.
17:51So yeah, that's the next step. Take the time to configure quad MD, MCP servers, all the stuff
17:58that your team uses, so that you can use it once, configure it once, and then share it with everyone.
18:04An example of this is in our apps repo. For Anthropic, this is like the repo that we have
18:10all of our web and apps code in. There's a Puppeteer MCP server, and we share this with the team.
18:16And there's an MCP JSON checked in, so any engineer working in that repo can use Puppeteer in order
18:21to pilot end-to-end tests and to screenshot automatically and iterate so that every engineer
18:25doesn't have to install it themselves.
18:31This is a talk about pro tips. I just want to take a quick interlude to talk about some common
18:35key
18:35bindings that people may not know. It's very hard to build for terminal. It's also very fun. It feels
18:40like rediscovering this new design language. But something about terminal is it's extremely minimal.
18:46And so sometimes it's hard to discover these key bindings. And here's just a quick reference sheet.
18:51So any time, you can hit shift tab to accept edits. And this switches you into auto accept
18:57edits mode. So bash commands still need approval, but edits are auto accepted. And you can always
19:01ask Claude to undo them later. For example, I'll do this if I know Claude's on the right track,
19:06or if it's writing unit tests and iterating on tests, I'll usually just switch into auto accept mode.
19:10So I don't have to okay every single edit. Any time you want Claude to remember something,
19:16so for example, if it's not using a tool correctly and you want it to use it correctly from then
19:20on,
19:20just type the pound sign and then tell it what to remember. And it'll remember it. It'll incorporate
19:24it into Claude MD automatically. If you ever want to drop down to bash mode, so just run a bash
19:30command,
19:30you can hit the exclamation mark and type in your command. That'll run locally, but that also goes
19:34into the context window. So Claude will see it on the next turn. And this is pretty good for long
19:40running commands if you know exactly what you want to do or any command that you want to get into
19:44context.
19:44Claude will see the command and the output. You can add mention thousand folders. Any time you can hit
19:52escape to stop what Claude is doing. No matter what Claude is doing, you can always safely hit escape.
19:56It's not going to corrupt the session. It's not going to mess anything up. So maybe Claude is doing
20:00a file edit. I'll hit escape. I'll tell it what to do differently. Or maybe it suggested a 20 line
20:05edit,
20:05and I'm like, actually 19 of these lines look perfect, but one line you should change. I'll hit escape. I'll
20:10tell it
20:10that. And then I'll tell it to redo that. You can hit escape twice to jump back in history.
20:17And then after you're done with the session, you can start Claude with a resume to resume that session
20:21if you want. Or dash dash continue. And then any time if you want to see more output, hit control
20:28R.
20:28And that'll show you the entire output, the same thing that Claude sees in its context window.
20:39The next thing I want to talk about is the Claude code SDK. So we talked about this at the
20:43top.
20:43Right after this, Sid is doing a session, I think just across the hallway, and he's going to go super
20:48deep on the SDK. If you hadn't played around with this, if you used the dash P flag in Claude,
20:54this is
20:54what the SDK is. And we've been planning a bunch of features over the last few weeks to make it
20:58even
20:58even better. So yeah, you can build on top of this. You can do cool stuff. This is exactly the
21:04thing
21:04that Claude code uses. It's exactly the same SDK. And so for example, something you can do is Claude
21:10dash P. So this is the CLI SDK. You can pass a prompt. You can pass some allowed tools which
21:17could
21:17include specific bash commands. And you can tell it which format you want. So you might want JSON or you
21:23might want streaming JSON if you want to process this somehow. So this is awesome for building on
21:28we use this in CI all the time. We use this for incident response. We use this in all sorts
21:33of
21:33pipelines. So really convenient. Just think of it as like a Unix utility. You give it a prompt. It
21:37gives you JSON. You can use this in any way. You can pipe into it. You can pipe out of
21:41it.
21:45The piping is also pretty cool. So you can use like, for example, git status and pipe this in and,
21:51you know, use jq to select the result. The combinations are endless. And it's sort of this new idea. It's
21:57like a super intelligent Unix utility. And I think we've barely scratched the surface of how to use
22:01this. We're just figuring this out. You can read from like a GCP bucket. Read, you know, like a giant
22:07log and pipe it in and tell Claude to figure out what's interesting about this log. You can fetch data
22:13from like the Sentry CLI. You can also pipe it in and have Claude do something with it.
22:23The final thing, and this is probably like the most advanced use cases we see, I'm sort of a Claude
22:28normie. So I'll have usually like one Claude running at a time. And maybe I'll have like a few terminal
22:32tabs for a few different repos running at a time. When I look at power users in and out of
22:37Anthropic,
22:38almost always they're going to have like SSH sessions. They'll have like Tmux tunnels into their
22:43Claude sessions. They're going to have a bunch of checkouts of the same repo so that they can run
22:48a bunch of Claude in parallel in that repo. Or they're using Git work trees to have some kind of
22:52isolation as they do this. And we're actively working on making this easier to use. But
22:57for now, like these are some ideas for how to do more work in parallel with Claude. You can run
23:02as
23:03many sessions as you want. And there's a lot that you can get done in parallel.
23:10So yeah, that's it. I wanted to also leave some time for Q&A. So I think this is the
23:15last slide
23:16that I have. And yeah, if folks have questions, there's mics on both sides. And yeah, we'd love to
23:22answer any questions.
23:35You skipped the bind command.
23:39I did.
23:46Hey, Boris. Thanks for building a cloud code. And I was wondering what was the hardest
23:50implementation, like part of the implementation for you of building it?
23:56I think there's a lot of tricky parts. I think one part that is especially tricky is the things
24:04that we do to make bash commands safe. Bash is inherently pretty dangerous and it can change
24:09system state in unexpected ways. But at the same time, if you have to manually approve every single
24:17bash command, it's super annoying as an engineer. And you can't really be productive because you're just
24:20constantly approving every command. And just kind of navigating how to do this safely in the way
24:25that scales across the different kinds of code bases people have. Because not everyone runs their
24:29code in a Docker container was pretty tricky. And essentially the thing we landed on is there's some
24:35commands that are read-only. There's some static analysis that we do in order to figure out which
24:39commands can be combined in safe ways. And then we have this pretty complex tiered permission system
24:44so that you can allow list and block list commands at different levels.
24:50Hi Boris. You mentioned giving an image to cloud code, which made me wonder if there's some sort of
24:57multimodal functionality that I'm not aware of. Are you just pointing it at an image on the file
25:01system or something? Yeah, so cloud code is fully multimodal. It has been from the start. It's in a
25:06terminal, so it's a little hard to discover. But yeah, you can take an image and just drag and drop
25:11it in.
25:12That'll work. You can give it a file path. That'll work. You can copy and paste the image in. And
25:18that
25:18works too. So I'll use this pretty often for if I have like a mock of something, I'll just drag
25:24and
25:24drop in the mock. I'll tell it to implement it. I'll give it a puppeteer server so it can iterate
25:28against it. And yeah, it's just fully automated. Hey, why did you build a CLI tool instead of an IDE?
25:40Yeah, it's a good question. I think there's probably two reasons. One is we started this
25:45adanthropic. And adanthropic people use a broad range of IDEs. And some people use VS Code,
25:50other people use Zed or Xcode or Vim or Emacs. And it was just hard to build something that works
25:57for
25:57everyone. And so terminal is just the common denominator. The second thing is adanthropic,
26:04we see up close how fast the model is getting better. And so I think there's a good chance that
26:09by the end of the year, people aren't using IDs anymore. And so we want to get ready for this
26:14future. And we want to avoid over-investing in UI and other layers on top, given that the way the
26:20models are progressing, it just, it may not be useful work pretty soon.
26:28Yeah. How much have you, I don't know if this is, is this on? How much have you used
26:33cloud code for machine learning modeling and almost that auto ML experience? I was curious
26:39what the experience has been so far with that. Yeah, I think, I think the question was,
26:43how much are we using cloud code for machine learning and modeling? We actually use it for this a bunch.
26:49So both engineers and researchers at Anthropic use cloud code every day. I think about 80% of people
26:56at Anthropic that are technical use cloud code every day. And hopefully you can see that in the
27:00product and kind of the amount of love and dog fooding we've put into it. But this includes researchers
27:05who use tools like the notebook, notebook tool to edit and run notebooks. Okay, very cool. Thank you.
27:13All right. I think that's it. Thanks.
27:14All right.

Recommandations