- The scaffolding developers built around models last year — routers, retry loops, memory systems, sandbox loops, image-scaling glue — now ships inside the model and the API itself, so you can focus on outcomes instead of plumbing.
- Lucas (research PM at Anthropic) walks through before/after pairs for four capabilities: tool use, context management, code execution, and computer use, plus quick tips for each and Claude Code-specific shortcuts.
- The guiding rule: any code that compensates for model unreliability has a half-life of months and should be left to Anthropic, while code that connects the model to your unique tools, data, and context compounds in value.
The expanding toolkit
- Tool routers and pre-filtering built from string matching and heuristics are now usually counterproductive; the model is intelligent enough to search through tools, pick the right one, see errors, and retry on its own.
- A powerful tip for tool use: describe the tool's output schema (not just its input parameters) in the description so Claude knows what to expect and can save round trips — e.g. knowing a
scorefield is returned lets it rank results immediately. - Context management is simplified by 1 million token context at flat pricing, server-side compaction, and context editing, turning hand-rolled memory systems into a few lines of config; clear stale tool results (screenshots, search dumps, file reads) every turn while keeping the decisions they informed.
- The code execution tool gives Claude a hosted server-side sandbox so the write/run/fix loop happens inside a single API turn, with no harness round trips to a VM; treat it as Claude's own computer for stateless compute and data analysis, separate from your local bash.
- Computer use no longer needs image-scaling glue: Opus 4.7 takes native-resolution screenshots and returns 1:1 pixel coordinates up to 1440p, and its OSWorld score has jumped from below 50% under a year ago to 78%.
- Claude Code shortcuts shared: pre/post-tool-use hooks in settings,
/contextto visualize what fills the context window,/schedulefor cron-triggered autonomous runs, and using a Claude in Chrome session so Claude Code can drive the browser to test and debug software like a human QA. - The closing principle: leave reliability work (retries, routers, planners, verification loops) to Anthropic because the model absorbs it; invest instead in the custom tools, data, and context only you can give the model — every piece of software will eventually get a "front door for agents."
Tool routing — Logic (often heuristic if-statements) that decides which tool to expose to or call for a model; now largely handled by the model itself.
Context window — The model's working memory; the span of tokens it can actively process at once.
Server-side compaction — API-level summarization/condensing of conversation history so context stays manageable without custom code.
Context editing — Programmatically pruning or clearing stale tool results from context to save tokens while preserving decisions made.
Code execution tool — A capability that gives Claude a hosted sandbox on the server to write, run, and fix code within a single API turn.
Computer use — The model's ability to perceive a screen and control a computer with clicks, typing, and drag actions.
OSWorld — A benchmark measuring how well a model completes complex tasks on professional and consumer software.
Hooks — Pre- and post-tool-use callbacks defined in Claude Code settings that run programmatically around tool calls.
Front door for agents — The idea that every piece of software will expose an agent-friendly interface for autonomous use.
Hello everybody. How are folks doing today? My name is Lucas. I'm a research PM here at Anthropic. And today I'll be talking about the expanding toolkit. But first of all, I want to say thank you everybody for joining us at our Code with Claude conference. We're very grateful you're here and we love speaking directly to our users.
So, what am I going to talk about today? The overarching theme of today's talk is that the scaffolding that you had to build last year actually ships with the model today. So, I want you all to think of the model no longer as just an input-output LLM box, but rather as a series of tools around that model that expands its capabilities and leads to better performance. In other words, we see the model itself as an expanding toolkit. This talk will be a series of befores and afters. On the left side, you'll see basically what things looked like previously. And on the right side, you'll see what that same task looks like now in 2026. Most of this will be heavily simplified. What you'll notice is not just better reliability, but also much simpler development. You have to focus less on the actual retries, wrappers, and so forth, and more on just getting the outcome that you're looking for. We'll be covering tool use, context management, code execution, and computer use. Then I'll share some practical tips for each, and for the Claude Code fans in the audience, I'll also have quick tips specific to Claude Code.
So a year ago building an agent really meant building around the model. You might have routers to pick the right tools. You might have retry loops, output validators, context compaction. You might even have to do some coordinate math if you're doing computer use. You'd have a hundred lines of code, hundreds of lines of scaffolding before you even build any product. Now, that scaffolding hasn't disappeared, but it moved. It now ships with the model itself. So the point isn't really that the work went away, it's that you don't have to own it anymore.
So, the first capability that I want to talk about is tool use. Specifically tool routing and retries. On the left side, you can see what this looked like previously. You couldn't really trust the model with the full tool set. It would eat into the context window, so you'd have to build a router. The way you might build this router is through string matching and heuristics. You might say, "Oh, if the model mentions SQL, then give it the database tool." And then you also needed a retry decorator on top of that because the tools failed often enough that you needed back off. Well, routers like those are basically guesses about user intent written in conditional if-statements. They're brittle, and they're the first thing that breaks when you try adding a new tool. Now, on the right, we have the new paradigm. The model can actually search through tools and pick the right tool itself. The model's intelligent enough and tool selection accuracy is now high enough that tool routers and pre-filtering usually make things worse, not better. We want the model to make decisions about what tools are relevant in the context it's working in. And when a tool errors, you can actually trust that Claude will see that error, recover on its own, and call the tool again. So, no more pesky tool re-routers, no more heuristics around when to bring in certain tools. That's all built into the model today.
Now, as promised, a quick tip for tool use. This one is very powerful and one that I actually use quite frequently. When you're giving a tool to Claude, most developers typically give the input to that tool to Claude — here are the parameters you need in order to call this function. But actually, what you can do is give Claude a description of the output schema as well. In the example I have here, I outlined that this search docs tool will search the docs and return the ID, title, snippet, and score. By doing this, you let Claude know what to expect from this tool call. So, for example, if Claude wanted to rank the outputs of this tool, it already knows that a score will be returned, effectively saving it a round trip from the harness. By doing this, you get more efficient and more intelligent outputs from Claude. And now for a Claude Code quick tip, another one I like to use frequently: you can use pre- and post-tool-use hooks defined in your Claude settings. This means before Claude calls a specific tool or after Claude calls a specific tool, you can have something happen programmatically. You might do this to block certain tool calls in specific situations, or to analyze and log outputs programmatically after the tool call's made.
Next I'll be speaking about context management. Long-running agents previously meant that you had to build your own memory system. You might do chunking. You might even do RAG, something very popular, especially to manage those pesky context windows. You might call another model to summarize what's going on after every N turns or N tokens. Again, the idea is you were building scaffolding so that you could practically extend the model's context window. You might even have cache breakpoints that you had to move by hand in order to save on cost and cache previous turns. Now we've simplified all of that tremendously. By offering 1 million context length at flat pricing, that already reduces most of the window pressure. Then you pair that with server-side compaction as well as context editing, and it basically turns the rest of that into just a few lines of config. This is how we get much closer to the feeling of an infinite context window that was mentioned at the morning keynote today. Again, this is just another example of how a lot of scaffolding you previously had to build is now completely built into the API and just a single API call away. So now for a quick tip on context management. We actually recommend that every turn you clear tool results. By pruning stale tool outputs — things like screenshots, search results, or file reads — you can save tremendously on context while keeping the decisions that they informed, which Claude mentions in its transcript. Imagine you have a transcript where the model read a huge file, got a screenshot, made a decision based on that, then had a search that dumped a ton of text. By clearing those results and just keeping the core task, the decision that was made, and the results the agent analyzed itself, you can save on tokens in real time. And for the Claude Code fans, this quick tip — I suspect a lot of you might already know it, but I like it a lot — if you have Claude Code open right now, do /context to get this live colored grid breakdown of what's filling your context window. That's a great way to viscerally see how much space messages, tool results, system prompts, and MCP definitions take in your context window. You'll also see some optimization suggestions there.
Next up is code execution. Previously the write, run, and fix loop used to be the developer's job. You might find a VM provider, spin up a sandbox, have the model output some code, put that code on the VM, run it, parse the feedback and traceback, feed it back into the model, and run that on repeat until the model succeeded at the task. We wanted to massively simplify that. So now we offer a code execution tool, which automatically gives Claude a hosted sandbox on the server side. This means that entire loop effectively happens inside a single API turn. No more harness round trips between Claude and whatever VM you're using. Claude can just on the API side tap into that separate computer being used just for Claude's scratch pad and work. This one is maybe less of a tip and more of a mental model for how to think about code execution versus your local bash. When we give Claude the code execution tool, it basically gets its own computer to do stuff on. Think about it like giving Claude a little calculator, except it's an entire computer that it can use. This means Claude can use this computer for stateless compute, data analysis, installing custom libraries — all without disrupting or cluttering your local file system. Then, when Claude does need to access something that only exists on your local computer, maybe your repo or a Python venv you have installed, it can go back to the real bash on your computer, and it intelligently knows which of the two to use. For another Claude Code quick tip, you can use /schedule to schedule cron-triggered autonomous runs. Think about this self-iteration loop, but now on a timer, happening exactly when you need it, completely autonomously done by Claude.
Last but certainly not least, an area where I spend a lot of my time: computer use. Previously, let's say you wanted Claude to drive your laptop. Most laptops have a 1080p screen, and you had to send that image to Claude. In order to have reliable clicks, you needed a pile of image glue. You first take your 1080p image, downscale it to fit Claude's pixel limits, track the factor of that downscaling, then when the model sampled a click, you'd scale that click back up to your original resolution. You'd have to write all that code and wrap it in retries and verify statements. Well, this was a very big pain point, and we've heard the feedback, so Opus 4.7 can now take native resolution screenshots and return one-to-one pixel coordinates up to 1440p, which captures the vast majority of display resolutions. So the scaling math is completely gone and you can simply send your image and trust that Claude will click exactly where it needs to. We're really excited about this capability because computer use as a capability is something that over the last 12 months has made great leaps and bounds. Our headline evaluation here is called OSWorld. That's an eval that tracks how well the model can complete complicated tasks on professional and consumer-grade software. Less than 12 months ago, Claude was scoring below 50% on this eval — it could not complete half the tasks asked of it. Now we're about to hit 80% on this eval, and we just reported 78% on Opus 4.7. Making computer use easier is something that's very exciting for us as we see it as an aspiring capability just now at the cusp of broad usability. As I mentioned, we support resolutions up to 1440p, but we really encourage developers to experiment across resolutions and formats. If you're doing really high-res stuff like 4K, we still recommend you downscale on your side. However, for anything up to 1440p, we recommend you try different resolutions to see what works best, as well as different image formats like JPEG, PNG, or WebP. Each of these compresses images differently and creates different compression artifacts. By testing it on your use case and the kinds of UIs you're trying to automate, you can find what works best. A Claude Code quick tip here is that Claude Code can actually leverage your Chrome browser session itself. If you're in Claude Code and you have Claude in Chrome installed, which you can get at claude.ai/chrome, your Claude Code session — that agent's harness — can start to use and navigate the web. This includes local development as well.
So now we're going to do a short demo. I'll show a short pre-recorded demo of an agentic coding loop with Claude Code and you'll see computer use in action with the Claude in Chrome extension. What we have here is a Claude Code session, and we've been working on a project management dashboard, but it has a couple bugs. The first bug is that the new button isn't actually adding a card. So we asked Claude to open it in Chrome and try it itself. We'll see this dashboard load as soon as Claude decides to open the browser. You can see Claude is connected through Claude in Chrome here. The first thing Claude's going to do is reproduce the issue. It spun up Claude in Chrome and it's going to test this live board itself. First Claude is trying to type something. You can see in the bottom left of the dashboard, Claude's trying to type something, but it's seeing some issues. In real time, Claude is both testing and debugging side by side, the same way you might do QA and engineering in order to fix these bugs. It tried typing something, didn't work. Now Claude will go into the code and make the code changes to wire up the card creation successfully. And now you can see that Claude has successfully created the card. It found the issue by actually testing it, tried it, and fixed it. With creation working, Claude is also going to check other features, for example whether these cards can be correctly dragged across columns. Claude just tried to drag the review PR into done, but it accidentally landed in to-do. It recognizes that's a bug, has the insight within Claude Code, diagnoses that drag-and-drop bug, and writes the fix in real time. Then it retests the flow from the ground up, so it'll once again create the new item. That's working. And now it'll test the drag-and-drop flow with that review PR now correctly going into the done section. From there, Claude will recap the fixes it made and summarize all its changes. We think this is a really powerful loop because most software today is created for humans, so it has to be tested in a human-like way. Giving Claude the capability to do browser use and computer use during its development cycle allows it to close that loop where it can create human-focused software and solve bugs itself directly without the developer needing to handhold Claude to the bug and the solution.
So, to wrap up and bring it back to the main point. The rule you should have in your mind is: any code that you are writing that is compensating for model unreliability will have a half-life of just months. You should leave that work to us. We will continue to make Claude more reliable and more capable through this expanding toolkit that comes with the model. So things like retry logic, routers, planners, verification loops — all of these are going to get absorbed in the model, and they have been getting absorbed in the model as I've shown you in the prior slides. Versus code that connects your model to your world — that code tends to compound. Your custom tools, your data, your auth, your specific context. The model can't absorb what it can't see. So giving it that is much more valuable than compensating for any model shortcomings today. We believe the ecosystem is moving in the same direction. We believe that in the near future every agent, every piece of software, will be getting a front door for agents. The interesting work is no longer making the model more reliable. The interesting work is what you put on the other side of your agent front door that nobody else can. Thank you very much for coming to my talk and for coming to the Code with Claude conference. My name is Lucas and I'll be walking around if you have any additional questions. Thank you all very much.
TL;DR
- The scaffolding developers built around models last year — routers, retry loops, memory systems, sandbox loops, image-scaling glue — now ships inside the model and the API itself, so you can focus on outcomes instead of plumbing.
- Lucas (research PM at Anthropic) walks through before/after pairs for four capabilities: tool use, context management, code execution, and computer use, plus quick tips for each and Claude Code-specific shortcuts.
- The guiding rule: any code that compensates for model unreliability has a half-life of months and should be left to Anthropic, while code that connects the model to your unique tools, data, and context compounds in value.
Takeaways
- Tool routers and pre-filtering built from string matching and heuristics are now usually counterproductive; the model is intelligent enough to search through tools, pick the right one, see errors, and retry on its own.
- A powerful tip for tool use: describe the tool's output schema (not just its input parameters) in the description so Claude knows what to expect and can save round trips — e.g. knowing a
scorefield is returned lets it rank results immediately. - Context management is simplified by 1 million token context at flat pricing, server-side compaction, and context editing, turning hand-rolled memory systems into a few lines of config; clear stale tool results (screenshots, search dumps, file reads) every turn while keeping the decisions they informed.
- The code execution tool gives Claude a hosted server-side sandbox so the write/run/fix loop happens inside a single API turn, with no harness round trips to a VM; treat it as Claude's own computer for stateless compute and data analysis, separate from your local bash.
- Computer use no longer needs image-scaling glue: Opus 4.7 takes native-resolution screenshots and returns 1:1 pixel coordinates up to 1440p, and its OSWorld score has jumped from below 50% under a year ago to 78%.
- Claude Code shortcuts shared: pre/post-tool-use hooks in settings,
/contextto visualize what fills the context window,/schedulefor cron-triggered autonomous runs, and using a Claude in Chrome session so Claude Code can drive the browser to test and debug software like a human QA. - The closing principle: leave reliability work (retries, routers, planners, verification loops) to Anthropic because the model absorbs it; invest instead in the custom tools, data, and context only you can give the model — every piece of software will eventually get a "front door for agents."
Vocabulary
Tool routing — Logic (often heuristic if-statements) that decides which tool to expose to or call for a model; now largely handled by the model itself.
Context window — The model's working memory; the span of tokens it can actively process at once.
Server-side compaction — API-level summarization/condensing of conversation history so context stays manageable without custom code.
Context editing — Programmatically pruning or clearing stale tool results from context to save tokens while preserving decisions made.
Code execution tool — A capability that gives Claude a hosted sandbox on the server to write, run, and fix code within a single API turn.
Computer use — The model's ability to perceive a screen and control a computer with clicks, typing, and drag actions.
OSWorld — A benchmark measuring how well a model completes complex tasks on professional and consumer software.
Hooks — Pre- and post-tool-use callbacks defined in Claude Code settings that run programmatically around tool calls.
Front door for agents — The idea that every piece of software will expose an agent-friendly interface for autonomous use.
Transcript
Hello everybody. How are folks doing today? My name is Lucas. I'm a research PM here at Anthropic. And today I'll be talking about the expanding toolkit. But first of all, I want to say thank you everybody for joining us at our Code with Claude conference. We're very grateful you're here and we love speaking directly to our users.
So, what am I going to talk about today? The overarching theme of today's talk is that the scaffolding that you had to build last year actually ships with the model today. So, I want you all to think of the model no longer as just an input-output LLM box, but rather as a series of tools around that model that expands its capabilities and leads to better performance. In other words, we see the model itself as an expanding toolkit. This talk will be a series of befores and afters. On the left side, you'll see basically what things looked like previously. And on the right side, you'll see what that same task looks like now in 2026. Most of this will be heavily simplified. What you'll notice is not just better reliability, but also much simpler development. You have to focus less on the actual retries, wrappers, and so forth, and more on just getting the outcome that you're looking for. We'll be covering tool use, context management, code execution, and computer use. Then I'll share some practical tips for each, and for the Claude Code fans in the audience, I'll also have quick tips specific to Claude Code.
So a year ago building an agent really meant building around the model. You might have routers to pick the right tools. You might have retry loops, output validators, context compaction. You might even have to do some coordinate math if you're doing computer use. You'd have a hundred lines of code, hundreds of lines of scaffolding before you even build any product. Now, that scaffolding hasn't disappeared, but it moved. It now ships with the model itself. So the point isn't really that the work went away, it's that you don't have to own it anymore.
So, the first capability that I want to talk about is tool use. Specifically tool routing and retries. On the left side, you can see what this looked like previously. You couldn't really trust the model with the full tool set. It would eat into the context window, so you'd have to build a router. The way you might build this router is through string matching and heuristics. You might say, "Oh, if the model mentions SQL, then give it the database tool." And then you also needed a retry decorator on top of that because the tools failed often enough that you needed back off. Well, routers like those are basically guesses about user intent written in conditional if-statements. They're brittle, and they're the first thing that breaks when you try adding a new tool. Now, on the right, we have the new paradigm. The model can actually search through tools and pick the right tool itself. The model's intelligent enough and tool selection accuracy is now high enough that tool routers and pre-filtering usually make things worse, not better. We want the model to make decisions about what tools are relevant in the context it's working in. And when a tool errors, you can actually trust that Claude will see that error, recover on its own, and call the tool again. So, no more pesky tool re-routers, no more heuristics around when to bring in certain tools. That's all built into the model today.
Now, as promised, a quick tip for tool use. This one is very powerful and one that I actually use quite frequently. When you're giving a tool to Claude, most developers typically give the input to that tool to Claude — here are the parameters you need in order to call this function. But actually, what you can do is give Claude a description of the output schema as well. In the example I have here, I outlined that this search docs tool will search the docs and return the ID, title, snippet, and score. By doing this, you let Claude know what to expect from this tool call. So, for example, if Claude wanted to rank the outputs of this tool, it already knows that a score will be returned, effectively saving it a round trip from the harness. By doing this, you get more efficient and more intelligent outputs from Claude. And now for a Claude Code quick tip, another one I like to use frequently: you can use pre- and post-tool-use hooks defined in your Claude settings. This means before Claude calls a specific tool or after Claude calls a specific tool, you can have something happen programmatically. You might do this to block certain tool calls in specific situations, or to analyze and log outputs programmatically after the tool call's made.
Next I'll be speaking about context management. Long-running agents previously meant that you had to build your own memory system. You might do chunking. You might even do RAG, something very popular, especially to manage those pesky context windows. You might call another model to summarize what's going on after every N turns or N tokens. Again, the idea is you were building scaffolding so that you could practically extend the model's context window. You might even have cache breakpoints that you had to move by hand in order to save on cost and cache previous turns. Now we've simplified all of that tremendously. By offering 1 million context length at flat pricing, that already reduces most of the window pressure. Then you pair that with server-side compaction as well as context editing, and it basically turns the rest of that into just a few lines of config. This is how we get much closer to the feeling of an infinite context window that was mentioned at the morning keynote today. Again, this is just another example of how a lot of scaffolding you previously had to build is now completely built into the API and just a single API call away. So now for a quick tip on context management. We actually recommend that every turn you clear tool results. By pruning stale tool outputs — things like screenshots, search results, or file reads — you can save tremendously on context while keeping the decisions that they informed, which Claude mentions in its transcript. Imagine you have a transcript where the model read a huge file, got a screenshot, made a decision based on that, then had a search that dumped a ton of text. By clearing those results and just keeping the core task, the decision that was made, and the results the agent analyzed itself, you can save on tokens in real time. And for the Claude Code fans, this quick tip — I suspect a lot of you might already know it, but I like it a lot — if you have Claude Code open right now, do /context to get this live colored grid breakdown of what's filling your context window. That's a great way to viscerally see how much space messages, tool results, system prompts, and MCP definitions take in your context window. You'll also see some optimization suggestions there.
Next up is code execution. Previously the write, run, and fix loop used to be the developer's job. You might find a VM provider, spin up a sandbox, have the model output some code, put that code on the VM, run it, parse the feedback and traceback, feed it back into the model, and run that on repeat until the model succeeded at the task. We wanted to massively simplify that. So now we offer a code execution tool, which automatically gives Claude a hosted sandbox on the server side. This means that entire loop effectively happens inside a single API turn. No more harness round trips between Claude and whatever VM you're using. Claude can just on the API side tap into that separate computer being used just for Claude's scratch pad and work. This one is maybe less of a tip and more of a mental model for how to think about code execution versus your local bash. When we give Claude the code execution tool, it basically gets its own computer to do stuff on. Think about it like giving Claude a little calculator, except it's an entire computer that it can use. This means Claude can use this computer for stateless compute, data analysis, installing custom libraries — all without disrupting or cluttering your local file system. Then, when Claude does need to access something that only exists on your local computer, maybe your repo or a Python venv you have installed, it can go back to the real bash on your computer, and it intelligently knows which of the two to use. For another Claude Code quick tip, you can use /schedule to schedule cron-triggered autonomous runs. Think about this self-iteration loop, but now on a timer, happening exactly when you need it, completely autonomously done by Claude.
Last but certainly not least, an area where I spend a lot of my time: computer use. Previously, let's say you wanted Claude to drive your laptop. Most laptops have a 1080p screen, and you had to send that image to Claude. In order to have reliable clicks, you needed a pile of image glue. You first take your 1080p image, downscale it to fit Claude's pixel limits, track the factor of that downscaling, then when the model sampled a click, you'd scale that click back up to your original resolution. You'd have to write all that code and wrap it in retries and verify statements. Well, this was a very big pain point, and we've heard the feedback, so Opus 4.7 can now take native resolution screenshots and return one-to-one pixel coordinates up to 1440p, which captures the vast majority of display resolutions. So the scaling math is completely gone and you can simply send your image and trust that Claude will click exactly where it needs to. We're really excited about this capability because computer use as a capability is something that over the last 12 months has made great leaps and bounds. Our headline evaluation here is called OSWorld. That's an eval that tracks how well the model can complete complicated tasks on professional and consumer-grade software. Less than 12 months ago, Claude was scoring below 50% on this eval — it could not complete half the tasks asked of it. Now we're about to hit 80% on this eval, and we just reported 78% on Opus 4.7. Making computer use easier is something that's very exciting for us as we see it as an aspiring capability just now at the cusp of broad usability. As I mentioned, we support resolutions up to 1440p, but we really encourage developers to experiment across resolutions and formats. If you're doing really high-res stuff like 4K, we still recommend you downscale on your side. However, for anything up to 1440p, we recommend you try different resolutions to see what works best, as well as different image formats like JPEG, PNG, or WebP. Each of these compresses images differently and creates different compression artifacts. By testing it on your use case and the kinds of UIs you're trying to automate, you can find what works best. A Claude Code quick tip here is that Claude Code can actually leverage your Chrome browser session itself. If you're in Claude Code and you have Claude in Chrome installed, which you can get at claude.ai/chrome, your Claude Code session — that agent's harness — can start to use and navigate the web. This includes local development as well.
So now we're going to do a short demo. I'll show a short pre-recorded demo of an agentic coding loop with Claude Code and you'll see computer use in action with the Claude in Chrome extension. What we have here is a Claude Code session, and we've been working on a project management dashboard, but it has a couple bugs. The first bug is that the new button isn't actually adding a card. So we asked Claude to open it in Chrome and try it itself. We'll see this dashboard load as soon as Claude decides to open the browser. You can see Claude is connected through Claude in Chrome here. The first thing Claude's going to do is reproduce the issue. It spun up Claude in Chrome and it's going to test this live board itself. First Claude is trying to type something. You can see in the bottom left of the dashboard, Claude's trying to type something, but it's seeing some issues. In real time, Claude is both testing and debugging side by side, the same way you might do QA and engineering in order to fix these bugs. It tried typing something, didn't work. Now Claude will go into the code and make the code changes to wire up the card creation successfully. And now you can see that Claude has successfully created the card. It found the issue by actually testing it, tried it, and fixed it. With creation working, Claude is also going to check other features, for example whether these cards can be correctly dragged across columns. Claude just tried to drag the review PR into done, but it accidentally landed in to-do. It recognizes that's a bug, has the insight within Claude Code, diagnoses that drag-and-drop bug, and writes the fix in real time. Then it retests the flow from the ground up, so it'll once again create the new item. That's working. And now it'll test the drag-and-drop flow with that review PR now correctly going into the done section. From there, Claude will recap the fixes it made and summarize all its changes. We think this is a really powerful loop because most software today is created for humans, so it has to be tested in a human-like way. Giving Claude the capability to do browser use and computer use during its development cycle allows it to close that loop where it can create human-focused software and solve bugs itself directly without the developer needing to handhold Claude to the bug and the solution.
So, to wrap up and bring it back to the main point. The rule you should have in your mind is: any code that you are writing that is compensating for model unreliability will have a half-life of just months. You should leave that work to us. We will continue to make Claude more reliable and more capable through this expanding toolkit that comes with the model. So things like retry logic, routers, planners, verification loops — all of these are going to get absorbed in the model, and they have been getting absorbed in the model as I've shown you in the prior slides. Versus code that connects your model to your world — that code tends to compound. Your custom tools, your data, your auth, your specific context. The model can't absorb what it can't see. So giving it that is much more valuable than compensating for any model shortcomings today. We believe the ecosystem is moving in the same direction. We believe that in the near future every agent, every piece of software, will be getting a front door for agents. The interesting work is no longer making the model more reliable. The interesting work is what you put on the other side of your agent front door that nobody else can. Thank you very much for coming to my talk and for coming to the Code with Claude conference. My name is Lucas and I'll be walking around if you have any additional questions. Thank you all very much.