Decoding Anthropic's Talk: Models Are Absorbing Your Scaffolding Code

The Core Argument: The Scaffolding You Hand-Rolled Last Year Now Ships with the Model

At Anthropic's Code with Claude conference, research product manager Lucas delivered a talk with a single, sharp thesis: the scaffolding you had to hand-roll last year is now built directly into the model and ships with it.

His advice to developers: shift your mental model. Stop thinking of the model as a pure "input/output" LLM black box, and start treating it as an expanding toolkit that grows around the model and continuously extends its capabilities. This means vast amounts of retry logic, routers, output validators, and context compression code are being "absorbed" by the model itself — freeing developers from tedious engineering wrappers so they can focus on what they actually want to accomplish.

The entire talk used a "before / after" comparison structure, covering four capability areas: tool use, context management, code execution, and computer use. Each section came with practical tips, plus dedicated advice for Claude Code users.

Tool Use: Goodbye to Fragile Routers and Retry Decorators

Building an agent a year ago essentially meant "building wheels around the model." You probably needed a router to pick the right tool, retry loops to handle failures, output validators as a safety net — and before you'd written a single line of product code, you'd already stacked hundreds of lines of scaffolding.

Lucas was blunt: the old string-matching, heuristic-based tool routers were fundamentally "using if-statements to guess user intent." They were brittle and fragile — typically the first thing to break whenever you added a new tool.

In the new paradigm, the model is smart enough to search through a toolset and select the right tool on its own. Tool selection accuracy is now high enough that pre-filtering and routers actually make things worse. When a tool call fails, Claude can see the error, recover on its own, and retry — no external retry decorators needed.

He offered one high-value practical tip here: most developers only tell Claude about a tool's input parameters, but you can also provide a description of the tool's output schema. For example, a search_docs tool that returns an ID, title, summary, and score — tell Claude about that upfront, and the model will know there's a score field available when it needs to rank results, saving a round-trip through your harness. For Claude Code users, he recommended using pre/post tool use hooks to programmatically intercept or log tool calls before and after they happen.

---

Scaffolding refers to the engineering code layer developers build around LLM calls to compensate for model limitations or instability. Typical scaffolding includes: tool routers (deciding which tool to call based on user intent), retry decorators (catching failures and automatically retrying), output validators (checking whether model responses match an expected format), and planners (breaking complex tasks into multi-step subtasks for sequential execution). Early large language models had weak tool-calling accuracy and fault tolerance, making this scaffolding a necessary condition for production viability. As model capabilities have improved — especially with the maturation of native function calling and tool use — the necessity of these external code layers is rapidly declining, as models begin internalizing this logic into their own reasoning.

Pre/Post tool use hooks are programmatic interception points provided by Claude Code. They allow developers to inject custom logic before (pre) or after (post) a tool is called — for example, logging audit trails, applying security filters to tool parameters, or reformatting return values — without modifying the tool's own implementation.

---

Context Management: From Custom Memory Systems to a Few Lines of Config

Long-running agents used to mean building your own memory system from scratch: chunking, RAG, calling a separate model every N turns to generate summaries, manually moving cache breakpoints to save money… all of it was essentially "extending the model's context window by other means."

Lucas said all of this has been dramatically simplified. A 1-million-token context length with unified pricing eliminates most window pressure upfront; combined with server-side compaction and context editing, the remaining work shrinks down to a few lines of configuration. This is the source of the "near-infinite context window" feeling mentioned in the conference keynote.

For practical tips, he suggested proactively clearing tool results every N turns — screenshots, search results, file reads, and other "stale tool outputs" consume enormous amounts of context, but the decisions Claude made based on them are already written into the transcript. Keeping only core tasks and decisions can save a significant number of tokens in real time. For Claude Code users, he strongly recommended running the /context command, which displays a color-coded grid showing exactly how much space is used by messages, tool results, system prompts, and MCP definitions, along with optimization suggestions.

---

RAG (Retrieval-Augmented Generation) is a technique for extending the model's accessible knowledge when context windows are limited: external documents are chunked and stored in a vector database, and before each conversation turn, the most relevant chunks are retrieved using the user's query and injected into the context. When context windows were commonly 4K–32K tokens, RAG was the dominant solution for working around window constraints — but it introduced additional retrieval latency, embedding costs, and recall accuracy issues.

Server-side compaction means the API provider automatically summarizes or truncates long conversation histories on the server side, so developers don't need to call a separate model to perform "rolling summarization" themselves. Context editing allows developers to delete or replace historical messages mid-session — for example, proactively removing outdated tool call results — saving tokens and reducing the chance of the model getting confused by stale information. Together, these features reduce what once required hundreds of lines of custom memory management code to just a small amount of API configuration.

---

Code Execution and Computer Use: The Loop Now Lives Inside a Single API Call

The old "write code → run → fix" loop was a real burden: find a VM provider, spin up a sandbox, drop the model's output code into it, parse the error, feed it back to the model, and repeat until it worked.

Anthropic now offers a code execution tool that automatically gives Claude a server-hosted sandbox. The entire loop described above now happens within a single API turn — no more back-and-forth between Claude and a VM. Lucas suggested thinking of it as "giving Claude its own dedicated computer" — capable of stateless computation, data analysis, and installing custom libraries without polluting your local filesystem. Claude only reaches back into the "real world" when it needs to access a local repository or Python environment.

Computer use showed the most dramatic improvement. Previously, to have Claude operate a 1080p screen, you had to downsample the image to fit the model's pixel limits, record the scaling factor, then scale the model's click coordinates back up to the original resolution — all wrapped in retry logic and validators. Opus 4.7 can now capture native-resolution screenshots and return 1:1 pixel coordinates, supporting up to 1440p, covering the vast majority of display resolutions. The scaling math is gone entirely.

He also shared a key data point: on the OS World benchmark — which measures a model's ability to complete complex tasks in professional and consumer software — Claude scored below 50% less than 12 months ago. Opus 4.7 has now reported 78%, closing in on the 80% mark. For 4K and higher resolutions, local downsampling is still recommended; for 1440p and below, he encouraged developers to experiment with different resolutions and image formats (JPEG/PNG/WebP) to find the optimal combination.

---

OS World is an academic computer-use benchmark that requires models to complete complex tasks in real operating system environments (Windows/macOS/Linux) using professional and consumer applications — for example, performing spreadsheet operations in LibreOffice or executing multi-step web tasks in a browser. It is considered one of the more authoritative measures of "general-purpose computer agent" capability, because its wide task coverage requires both visual understanding and precise action in coordination, making it more reflective of real-world generalization than simple UI-clicking benchmarks. The benchmark scores out of 100%, with human expert performance estimated in the 72–80% range — meaning Opus 4.7's reported 78% puts the model at or near human expert level on this evaluation, marking a significant milestone in computer use.

---

Claude Code in Practice: The Browser Tests and Fixes Itself

Lucas demonstrated a remarkably self-contained loop: Claude Code, using a Chrome browser session (via the Claude in Chrome extension), can let the agent browse the web and test a local development environment on its own.

In the demo, a project management dashboard had two bugs: the "new" button couldn't add cards, and dragging a card would drop it in the wrong column. Claude's approach was nearly identical to a human QA engineer — open Chrome, reproduce the issue, notice that the input fails, go into the code to fix it, retest and confirm card creation works; then test the drag-and-drop feature, notice that "review PR" got dragged to "to do" by mistake, identify it as a drag-and-drop bug, write the fix in real time, and re-run the entire flow from the start.

The value of this loop is straightforward: most software today is designed for humans, so it has to be tested in a human-like way. Give Claude a browser and computer use capabilities, and it can reproduce, diagnose, and fix bugs in human-facing software on its own — without the developer needing to hand-hold it through the problem and solution.

Conclusion: Stop Writing Patches for Model Unreliability

Lucas closed with a single line — and the most important principle to take away from the entire talk:

Any code written to compensate for model unreliability has a half-life of a few months.

Retry logic, routers, planners, validation loops — these are being absorbed by models now and will continue to be. That work should be left to Anthropic. What's truly valuable, and what compounds over time, is the code that connects the model to your world: your custom tools, your data, your authentication, and your proprietary context. "Models can't absorb what they can't see," so giving them these things is far more meaningful than patching the model's weaknesses.

He went further to predict that the entire ecosystem is evolving in the same direction — in the future, every piece of software will open a "front door" for agents. The interesting work, then, isn't making models more reliable — it's what you put on the other side of your agent's front door that no one else can replicate.