TL;DR

• Users consolidate around 4 core platforms (Slack, Notion, Email+Office, AI Tool) while rejecting standalone/SASS tools

• Connectors that bring data to users beat new tools that require visits

• Infrastructure breakthrough: Slack manifests + MCP protocol + LLM services make org-specific connectors trivial

• Democratization effect: Bootcamp engineers can now build sophisticated integrations that once required senior developers

• Production evidence: 3 connectors (4-6 hours each, $1-2.5K in AI tokens) replaced 5-6 standalone tools that would cost $150-300K+ traditionally

• Tolerance for “broad-based general tools” declining — UX mindshare captures traffic even when APIs do the work

In the past two weeks, I’ve built three connectors that collectively replaced what would have been five or six standalone tools.

Engineering Search Connector: Hosted semantic and knowledge graph search service built by repurposing mcp-vector-search. Unified search across 150+ GitHub repos, 1,700+ wiki pages, and ticket systems. Accessible through Slack bot, web interface, CLI, and MCP connector for Claude.AI that brings engineering knowledge to where people already work.

CRM Data Connector: Live customer data piped directly into Claude.AI sessions via MCP. No dashboard to check, no reports to generate. Ask “What’s our pipeline this quarter?” and get live data in 1-3 seconds.

Document Workflow Connector: Artifact browser and guided PR workflow for non-technical contributors. Product managers can explore and propose changes to structured docs without touching git or learning new interfaces.

None of these required users to adopt a new primary tool. Each brings specialized functionality to platforms they already inhabit daily. And each took roughly 4-6 hours to build (plus agent time).

This isn’t a productivity humble-brag. It’s evidence of a fundamental shift in how organizations interact with their data. We’re entering the connector era — building bridges between specialized intelligence and the handful of platforms where users actually live, rather than standalone applications they have to visit.

The numbers support this pattern. Users toggle between apps 1,200 times daily, losing 40% productivity to context switching. Connector ecosystems are exploding: Slack’s marketplace hosts 2,600+ apps with 550K+ daily custom integrations. The MCP protocol went from 100K to 8M downloads in six months — unprecedented adoption for plumbing infrastructure.

The question isn’t whether Slack, Notion, and Claude.AI will survive the AI wave. It’s whether the hundreds of specialized tools competing for attention understand that the game has changed. Users have less tolerance for broad-based general tools than they once did. The platforms that capture UX mindshare will get most of the traffic, even if APIs and agents do the actual work behind the scenes.

The evidence is clear from user behavior: they don’t want to learn a new search interface, remember another login, or context-switch to yet another tab. They want the intelligence layer to meet them where they already are.

The Source of Truth Problem

Most organizations have a source-of-truth problem they haven’t fully articulated. They have Slack for real-time communication. They have Notion or Confluence for documentation. They have Google Docs for drafts that become documents that become outdated that stay around anyway. They have JIRA for tickets that may or may not reflect what was actually decided. They call this a “knowledge management system.” It’s more accurately a distributed archive of partially-intentional artifacts with no clear authority hierarchy.

The question “who owns this decision?” leads to a Slack thread from eight months ago, a Notion page that three people edited and nobody is certain is current, and a Google Doc someone linked in a comment that requires permission to access. This is the status quo. It functions, after a fashion, because humans are good at triangulating across ambiguous sources and asking colleagues to fill gaps.

AI agents are not good at this. They will confidently synthesize the eight-month-old Slack thread with the outdated Notion page and present the result as a coherent answer. The errors won’t be obvious. They’ll be subtly wrong in ways that require domain expertise to catch.

The source of truth problem was always real. It was manageable when every query ran through a human brain. It becomes actively dangerous when queries run through an inference layer first.

What you actually need — what organizations are starting to build — is a repository where the data structure enforces truth. Not a place where the right answer might be findable if you look hard enough. A place where the structure of the data makes the wrong answer harder to produce.

But here’s the connector insight: that structured repository doesn’t need to be where users spend their time. It can be the authoritative backend that feeds connectors in the platforms users already inhabit.

Where Users Actually Live

User attention has consolidated around four core platforms:

Slack: Real-time coordination, team presence, ephemeral decisions. 32.3 million daily active users with 550K+ custom integrations daily.

Email + Office Suite: Formal communication, document collaboration, external stakeholder interface. Microsoft reports 400M+ Office 365 commercial users.

Notion: Knowledge management, project tracking, collaborative documentation. 100M+ users consolidating entire productivity stacks.

Claude.AI: AI assistance, analysis, content generation. Rapidly becoming the default interface for LLM interactions across knowledge work.

Each platform serves a legitimate core function. Tool builders make the mistake of assuming they can compete for primary platform status by building something better. Users are done adopting new primary platforms. They’re consolidating around tools that already have their attention.

The pattern reveals a deeper truth: people live in transactional systems, not knowledge systems. Slack is where decisions happen. Email is where approvals flow. Claude.AI is where analysis gets done. These are transactional - work happens there daily.

Confluence is a perfectly good wiki tool. But it’s knowledge-at-rest, not transactional. People don’t live there. They visit when forced to document something, then return to their transactional workflows. The knowledge gets stale because maintenance happens in a different system than usage. (Notion manages to straddle the line between knowledge at rest and transactional)

Integration platforms like Zapier understand this - they connect 8,000+ apps with 3.4M+ business users by bringing specialized functionality to existing workflows rather than creating new destinations.

Users just want the data, dammit. They don’t want to learn your interface.

The Connector Infrastructure Moment

What changed? Three pieces of infrastructure matured simultaneously:

Slack Manifest Tool makes organization-specific bots trivial to build. The manifest.yaml format standardizes permissions, scopes, and deployment. Weeks of OAuth wrestling became hours of configuration.

MCP Protocol achieved “USB-C for AI” universal connectivity. Claude.AI, ChatGPT, and dozens of platforms support the same connector format. Build once, deploy everywhere. The 100K to 8M download growth in six months reflects pent-up demand.

LLM Services like Bedrock and OpenRouter provide natural language interfaces that make connectors intelligent rather than just data pipes. Ask questions in plain English, get structured responses, maintain conversation context.

Semantic Search Infrastructure like mcp-vector-search can be repurposed as hosted services, adding intelligence layers that understand meaning rather than just matching keywords. This transforms basic data access into contextual knowledge retrieval — a crucial enabler for connectors that need to surface relevant information rather than exact matches.

Combined, you can build a production connector in a single afternoon. Slack manifest defines the bot interface. MCP schema defines the data sources. Semantic search handles intelligent retrieval. Bedrock provides the language understanding. Deploy to AWS Lambda and you’re live.

My three connectors follow this exact pattern. The engineering search connector repurposes mcp-vector-search as a hosted service with all-MiniLM-L6-v2 embeddings for semantic and knowledge graph search, but the user interface is just Slack commands and Claude.AI MCP tools. The CRM data connector is a headless AWS service that makes customer data available through natural language queries in Claude.AI. The document workflow connector provides git workflows through a web UI that non-technical users can navigate.

Each connector took 4-6 hours to build. Each would have taken 4-6 months to build as a standalone application with user management, authentication, interface design, mobile responsiveness, and all the infrastructure a “real app” requires.

The Democratization Effect: The infrastructure shift goes beyond development speed — it’s democratizing who can build sophisticated integrations. What once required senior engineers with deep API knowledge can now be handled by bootcamp graduates following established patterns. I built these first three connectors to validate the approach, but similar projects will go to junior engineers going forward.

This changes resource allocation fundamentally. Organizations can solve integration problems without burning senior engineering cycles on “plumbing” work. Information that was once very hard to obtain is now trivial to access.

The economics are compelling. Building three production connectors cost roughly $1,000-2,500 in AI tokens over 44 days. Traditional contractor development for equivalent functionality would have run $150-300K+. The connector approach isn’t just faster — it’s 100x more cost-effective.

The adoption metrics prove the value. The CRM connector launched March 18th with 23 invocations on day one. No formal rollout, no training sessions, no onboarding docs. Just organic discovery across a 300+ person company. By week two, daily usage tripled to 95 invocations per day. Tuesday hit 152 invocations — including a 40-query analysis session in a single hour. That’s 299 queries in 7 days with zero errors, from a connector that took 4-6 hours to build.

The era isn’t about choosing between platforms. It’s about connecting specialized intelligence to the platforms users have already chosen.

Why Wikis Can’t Compete in the Connector World

Traditional knowledge management tools face a structural mismatch in connector architecture. Wikis assume users will “go to the tool” for information. Connectors flip that assumption: the tool comes to the user.

This creates specific problems:

The Authoring/Retrieval Tension: Wikis optimize for collaborative authoring — anybody can edit, flexible structure, link everything, evolve over time. This is the opposite of what retrieval needs: consistent schema, clear ownership, explicit governance. When you pipe wiki content through a connector, you inherit all the inconsistencies that collaborative authoring creates.

Search Architecture Limitations: Confluence’s search is notoriously bad because it does keyword matching on unstructured text. This was problematic before LLMs. With LLM-powered connectors, it becomes worse because the AI layer adds confidence to bad retrieval results. Users get wrong answers delivered with conviction.

Static Data Problem: Notion’s AI operates on static content snapshots, disconnected from real-time operational state. When CRM connectors query “What’s our pipeline this quarter?” through a Notion connector, it’s answering based on what someone wrote about the pipeline, not live customer data. The connector amplifies the staleness problem.

Governance at Scale: Wiki governance defaults to “community-maintained,” which means in practice nobody is responsible for accuracy. As organizations scale, wikis accumulate pages nobody knows are outdated. Connectors don’t solve this — they accelerate the distribution of stale information.

Our structured document framework represents the alternative: git-backed Markdown with schema-validated YAML frontmatter. Every document has explicit metadata: owner, status, domain, confidence, time_box. The structure is the feature. When document workflow connectors expose this, the schema ensures consistent data quality regardless of interface.

Structured document repositories outperform wikis for AI query by 35-60% in controlled tests. Clean Markdown with explicit metadata reduces token usage by 20-30% and improves retrieval accuracy significantly. This isn’t philosophical — it’s measurable.

Wikis remain useful for collaborative drafting and evolving reference material. But they’re not the right backend for connector architecture. The connector era requires structured data sources that can maintain quality across multiple interface layers.

Building Connectors vs. Standalone Tools

The strategic choice organizations face isn’t “which tool should we build?” but “should we build a tool or a connector?” My experience with three connectors illuminates the trade-offs:

Engineering search could have been a standalone search platform. Instead, it’s accessible through Slack commands, CLI tools, web interface for visualizations, and MCP tools for Claude.AI sessions. Same search capability, four different interaction models depending on user context.

CRM integration could have been a dashboard with charts and filters. Instead, it’s a headless MCP service that makes customer data available through natural language in Claude.AI. Ask “Show me deals over $100K in our target vertical” and get live results in 1-3 seconds. No dashboard to learn, no visual interface to maintain.

Document workflows could have been a product management SaaS platform. Instead, it’s a guided workflow that helps non-technical contributors interact with existing git-backed document frameworks. Browse artifacts, generate AI summaries, submit PRs — all through interfaces that match users’ technical comfort levels.

Specialized intelligence delivered through platforms users already inhabit. The connector approach wins on several fronts.

Development time: 4-6 hours vs. months. No user management, authentication, responsive design, or mobile apps to build.

Adoption friction: Zero onboarding. No new logins, training sessions, or change management overhead.

Maintenance burden: Focus on data logic and intelligence, not interface maintenance across device types and browser versions.

Integration: Connectors compose naturally with existing workflows. Slack discussions can include live Salesforce data. Claude.AI analysis can pull from engineering knowledge graphs. Standalone tools require export/import workflows.

The business case is compelling: connector development costs 10-20% of standalone application development while achieving 3-4x higher user engagement.

The implications go beyond development efficiency. Users have less tolerance for “broad-based general tools” than they once did. Managing dozens of application contexts creates unsustainable cognitive load. Platforms that capture daily attention get most of the traffic, even when APIs and agents do the computational work behind the scenes.

This creates different winner-take-all dynamics. The winners aren’t necessarily the best tools. They’re the platforms users choose to inhabit, plus the connectors that bring specialized capability to those platforms.

What This Means for Your Stack

The connector era doesn’t eliminate existing tools — it clarifies their appropriate roles and challenges their assumptions about user attention.

Slack keeps its coordination function: Real-time presence, threading, ephemeral decisions. But it becomes a command interface for structured data sources rather than a knowledge repository itself.

Notion retains collaborative authoring value: Drafting, evolving documentation, reference material. But it stops being the “source of truth” for operational decisions. That role shifts to structured backends accessible through Notion connectors.

Specialized tools survive by becoming intelligent backends: Your CRM, your monitoring system, your code repositories — these maintain their core data authority. But user interaction shifts to connector layers in platforms where users already work.

The question to ask about any tool: Is this where I want an AI agent pointing when it needs authoritative information? If the answer is no, it’s not your source of truth. It might still be valuable — as a backend, as a collaborative space, as a specialized interface for expert users. But it doesn’t earn the designation of “primary platform.”

The organizational challenge: Getting non-technical teams comfortable with structured data workflows is real change management. Document workflow connectors address this by providing guided interfaces for git-backed workflows. But someone still needs to own schema design and governance processes.

Who should build connectors first: Engineering-adjacent teams with strong PM-engineering collaboration. Organizations where AI hallucination on operational decisions creates measurable cost. Companies that have already felt the pain of distributed knowledge management.

Timing matters: Most organizations haven’t built connector strategies yet. Companies that establish structured knowledge backends with connector frontends in 2026 will have 12-18 months of advantage when AI-mediated query becomes standard practice.

The connector era isn’t about choosing between platforms. It’s about connecting intelligent backends to platforms users have already chosen. Organizations that get this right will operate with less context switching and faster access to operational data.

Users just want the data, dammit. The question is: will you bring it to them, or keep expecting them to come to you?

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

The pattern shows up constantly when I look at MCP server implementations. Someone discovers the protocol, gets excited about giving agents tool access, builds a server in a weekend, ships it to the registry. Six tools. Maybe eight. Each one is basically a direct passthrough to whatever SDK the underlying service provides.

And for about a week, it feels like it works.

Then the agent needs to do something real. Archive 400 emails from a specific sender. Pull all calendar events for Q1, cross-reference them with a project timeline, and generate a summary. Move a batch of files across Drive folders. The agent starts calling tools in sequence, hits rate limits, gets confused about pagination, makes the same API call twelve times trying to work around a 50-item response limit that the MCP tool never exposed as a parameter. Eventually it either fails or produces something partially wrong, and nobody’s quite sure where the breakdown happened.

The bottleneck isn’t MCP. The protocol did exactly what it was supposed to do — it gave the agent a clean interface for calling tools. The bottleneck is what’s behind the MCP server.

I’ve built a lot of these now. gworkspace-mcp has 115 tools across Gmail, Calendar, Drive, Docs, Sheets, Slides, and Tasks. slack-mpm has 40+ tools plus a full async Python API library underneath that can run entirely without an agent in the loop. The gap between those projects and most of the reference MCP servers I’ve seen is not complexity — it’s architecture. Specifically: whether there’s a real API underneath the MCP layer, or whether the MCP tools ARE the implementation.

That distinction matters more than almost anything else when you’re building tools that agents will actually use in production.

TL;DR

• MCP servers built as thin wrappers over service SDKs hit hard ceilings when agents need to do anything at volume or across operations

• The reference Slack MCP server has 8 tools; a production implementation needs 40+, with a real API library underneath it

• The three-layer pattern (API → MCP → Skills) has a specific job at each layer — remove any one and the system degrades in a predictable way

• Tool description quality is the single biggest lever on agent behavior; bad descriptions produce bad decisions regardless of what’s underneath

• Thin wrappers are fine for prototypes and read-light tools; the inflection point is when you want to write a script that does what the agent does

The Official Slack MCP Server Problem

The reference Slack MCP server — currently maintained by Zencoder after leaving the official MCP registry — offers eight tools. List channels. Post a message. Reply to a thread. Add a reaction. Get channel history. Get thread replies. Get users. Get a user profile. That’s it.

For a demo, that’s fine. For anything agents actually need to do with Slack, it hits walls quickly.

My slack-mpm server covers 40+ tools: search messages by date range and keyword, manage bookmarks, set reminders, handle scheduled messages, list workspace members with filtering, manage file uploads, archive channels. The implementation underneath is a clean async Python API — 47 functions across eight modules — that you can call directly from scripts without an agent in the loop at all.

The functional gap is obvious enough. What’s less obvious is why it exists.

The reference server isn’t thin because Slack’s API is thin. Slack’s API is extensive. The server is thin because it was built without a real API library underneath it. The MCP tools are the implementation — there’s no abstraction layer, no pagination handling, no rate limit management, no batch operation support. Each tool calls the Slack SDK directly and returns the result.

That works for eight tools. It doesn’t scale to forty because the complexity you’re hiding from the agent — auth edge cases, cursor-based pagination, retry logic on rate limits, handling the difference between bot tokens and user tokens — has nowhere to live. There’s no library to put it in. So you either skip the complex operations entirely, or you dump that complexity into the MCP tool handler itself, which makes the tool fragile and hard to maintain.

The reference server chose the first option. Which is reasonable for a reference — but it means agents using it can’t search Slack properly (search requires user tokens; the server only supports bot tokens), can’t do bulk operations, can’t run scheduled tasks, can’t be used programmatically outside of an agent context.

This isn’t a knock on the people who built it. It’s a knock on the pattern of treating MCP as the architecture rather than the interface.

Phil Schmid made a similar observation in January in a piece called MCP is Not the Problem, It’s Your Server: “MCP servers are not thin wrappers around your existing API. A good REST API is not a good MCP server.” Correct, but it doesn’t go quite far enough. The problem isn’t just that REST APIs make bad MCP servers — it’s that MCP servers without any abstraction layer underneath them make bad tools, regardless of what the underlying service looks like.

What a Real API Gives You

When I started building gworkspace-mcp, I made a decision early that turned out to be foundational: build the Google Workspace API library first, then write the MCP server as a thin interface on top of it. The API library handles auth, pagination, rate limiting, and error normalization. The MCP tools are mostly one-liners that call the right API function and return the result.

That decision shows up in five specific ways.

Pagination at the library level. Gmail’s API returns 50 messages per page by default. If an agent wants to archive everything from a specific sender over the past six months, that might be 400 messages across eight API calls. If the MCP tool handles pagination — which means the API library handles it — the agent calls one tool and gets back 400 message IDs. If pagination isn’t handled, the agent manages cursor iteration itself: call the tool, get 50 results, extract the cursor, call again, repeat. Agents do this badly. They lose track of cursors, make redundant calls, or give up after the first page and tell you they found the 50 most recent messages.

Rate limit management that doesn’t leak up. Rate limits handled in the API layer are invisible to the agent. The tool call either succeeds or returns a clean error. Rate limits handled in the tool handler either block the agent or require the tool description to explain retry patterns — which agents then implement inconsistently. The complexity belongs in the API layer. That’s the only place it can be handled reliably and tested against real behavior.

Reuse across contexts. The slack-mpm API library runs five standalone scripts — archiver, digest, listener, notifier, responder — that operate on schedules without any MCP involvement. The same code that handles pagination and auth in the MCP context handles it in the cron job context. This isn’t a nice-to-have: it means the code is continuously exercised against real-world conditions, not just when an agent happens to call it.

Actual testability. You can write unit tests for an API library. You can mock the underlying service calls, test pagination edge cases, verify that rate limit handling works correctly. Testing an MCP tool handler without running an agent session is hard to do meaningfully — you end up testing it by watching it fail in production. The difference in reliability compounds over time, and it compounds fast.

Composability. Some operations are inherently multi-step. Finding all calendar events associated with a project and generating a summary requires fetching from multiple calendars, filtering by keyword, sorting by date, and formatting the output. That can live in the API layer as a single higher-order function. The MCP tool calls the function. The agent sees one tool call that returns a clean result instead of orchestrating a dozen calls and trying to assemble the output itself.

Aditya Mehra put it well in a December 2025 piece on production MCP architecture: “Design for what agents need to accomplish, not for what APIs happen to exist. Your APIs were designed for developers building applications. Your MCP servers should be designed for agents completing tasks.” The API layer is where you do that translation. The MCP layer is where you expose the result.

The Three-Layer Pattern

The architecture I’ve converged on has three distinct layers, each with a specific job. Removing any one of them degrades the system in a predictable way.

Layer 1 — The API library. This is where the complexity lives. Auth handling, including token refresh and the difference between scoped token types. Pagination, including cursor management and automatic result aggregation. Rate limit management, with exponential backoff and respect for per-method limits. Error normalization, so the MCP layer receives clean, typed errors rather than raw API exceptions. Batch operations, so the agent can request 400 results and the API handles chunking appropriately.

The design test for this layer: you should be able to write useful scripts against the API library without involving an agent at all. If you can’t, the abstraction is at the wrong level.

Layer 2 — The MCP server. Thin. The tool handler should be almost trivially simple: validate inputs, call the API function, return the result. If a tool handler is doing significant work, something belongs in the API layer instead. Tool descriptions are not trivial — they’re the interface contract with the agent and deserve careful attention — but the execution path should be short. A handler that’s more than twenty lines of real logic is usually a sign something is in the wrong place.

The design test here: each tool should do one thing, and it should be obvious which tool to use for a given operation. When agents have to guess between tools, they guess wrong.

Layer 3 — The skills document. This is the layer most implementations skip, and it’s often where production agent behavior falls apart. The skills document tells the agent how to use the MCP tools effectively: what tools exist, when to use each one, which combinations work well together, what to avoid.

Without it, agents discover capabilities by trial and error — hitting rate limits unnecessarily, calling the wrong tool for the job, making redundant calls when one batched call would do. With it, agents start from a baseline of competent behavior and only deviate when they encounter something they haven’t hit before.

The skills document is institutional knowledge in structured form. It captures what took me hours of iteration to learn about each service — which Gmail search operators work reliably, when to use Drive’s query syntax versus simple name search, how to structure a Sheets batch update to avoid cell reference errors. That knowledge doesn’t exist anywhere else. It lives in the skills document or it doesn’t exist, and the agent stumbles into the same mistakes I made during development.

The MCP community is starting to recognize the description-as-instruction principle. Schmid’s framing is that “every piece of text is part of the agent’s context.” True, but individual tool descriptions can only carry so much. The skills document is where higher-order guidance lives — how to think about sequencing operations, when not to use a tool, what the common failure modes look like. Think of it as runtime instructions for agents, not documentation for humans.

When MCP Alone Is Enough

There are cases where thin MCP wrappers are the right call, and it’s worth being direct about them.

Simple, low-volume reads. If an agent needs to check weather, query a single record from an external service, or look up one user profile, a thin wrapper is probably fine. The complexity ceiling exists but may never be reached. Building a full API layer for a tool that makes one API call per agent turn is engineering overhead that doesn’t pay off.

Prototyping and exploration. A server built in a day is often the right first step because you don’t know yet which operations the agent will actually need. I’ve shipped thin wrappers deliberately as a way to learn before investing in a proper API library. The Zencoder Slack server probably started that way. The mistake isn’t building a thin wrapper for exploration — it’s leaving it there when the agent starts doing real work and the wrapper’s limits start showing.

Single-agent, single-purpose tools. If a tool is purpose-built for one agent doing one thing and the scope is genuinely narrow, the three-layer overhead may not be worth it. The architecture makes sense when tools need to be reused across contexts, when operations are high-volume, or when the underlying service is rate-sensitive.

Read-heavy, write-light operations. The complexity of batch operations, cursor management, and retry logic matters most when you’re writing or doing high-volume reads. A tool that fetches a single resource per agent turn doesn’t need much abstraction.

The honest signal for when you need the full pattern is one of three things: you find yourself wanting to write a script that does what the agent does, the agent hits the same rate limit more than once in a session, or you start duplicating error handling logic across tool handlers. Any of those is the inflection point. At that moment, adding the API layer is less work than continuing without it.

Building Your Own: Where to Start

Start with the API, not the MCP server. The most common mistake is writing the MCP tool first — it seems like the path of least resistance — and then adding abstraction as you hit problems. The trouble is that tool handler code is hard to refactor. The MCP interface shapes how you think about the operations, and that framing tends to be too granular. Starting with the API forces the right level of abstraction from the beginning.

Design the API around operations, not endpoints. Slack’s Web API has dozens of endpoints, but agents think in operations: send a message, search conversations, get user context. The API library should expose those operations, even when the underlying service requires two calls to complete one. Complexity belongs in the library. The agent-facing interface stays clean.

Invest heavily in tool descriptions. The single biggest lever on how well agents use your MCP server is description quality. That means specific parameter descriptions, not just type annotations. It means clear examples of when to use this tool versus a similar one. It means explicit notes about what a tool cannot do — agents will try to use tools for operations they weren’t designed for, and a good description cuts off the most common wrong paths before they happen.

Write the skills document while you build. Don’t wait until the server is done. Every time you notice the agent doing something inefficient — calling four tools when one would work, misunderstanding a parameter’s purpose, hitting a rate limit that could have been avoided — write that observation down immediately. The skills document is most valuable when it’s written from observation of real agent behavior, not reconstructed after the fact from memory.

The gworkspace-mcp repository on GitHub is a worked reference — 115 tools across seven Google APIs, one coherent server, the three-layer pattern at scale. Not the only way to implement this, but a concrete example of what the architecture looks like when the abstractions have had to earn their keep over months of real use.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

Edits:

• Fixed link to slack-mpm

What Makes AI Coding Effective

Last weekend, working on performance improvements to my MCP vector search engine, I noticed something. The breakthrough in AI coding isn’t smarter models — it’s information architecture. The tools that actually work aren’t necessarily the ones with the biggest context windows. They’re the ones that find the right context and remember what matters.

Here’s what I mean. I’ve been using search and memory together long enough that I don’t think about them anymore. My prompts have gotten measurably shorter — an analysis of my sessions shows prompts averaging 12-15 words in mid-2025 dropping to 6-8 words now. “Check logs.” “What’s the command to quantize the index?” I just assume the agents will find the context they need. When I stepped back and thought about what changed, it came down to two things: Search and Memory.

You can see this pattern across successful AI coding tools. Claude MPM consistently outperforms Claude Code on its own — not because the underlying agentic AI differs, but because MPM brings the right context to the agents rather than flooding them with everything. Tools like Augment and Cursor have made similar investments in context retrieval. The winning tools aren’t the ones with the smartest models. They’re the ones that solved information architecture.

Search: Why Bigger Context Windows Aren’t the Answer

The promise of massive context windows is seductive: dump your entire codebase into the AI and let it figure out what’s relevant. The research tells a different story.

Liu et al.’s 2023 paper “Lost in the Middle: How Language Models Use Long Contexts” documented a U-shaped performance curve: models process information well at the beginning and end of long contexts, but performance drops 30% or more when relevant information is buried in the middle. This has been replicated across models since. Feeding a 500K-line codebase into Claude’s context window actually makes it worse at finding relevant patterns than targeted search.

Large context approach: AI gets overwhelmed. Focuses on random details buried in the middle of files. Expensive to run.

Search approach: AI gets exactly what it needs. Finds patterns quickly. Much cheaper to operate.

When you ask for “all authentication code that handles OAuth,” a semantic search returns exactly that — not every file that mentions the word “auth.” The AI gets relevant context, not noise.

The big AI vendors haven’t solved this yet. OpenAI and Anthropic are focused on the language models themselves. Neither has built search integration into their core products. The reasons are understandable — it’s genuinely hard to install and configure, and most users don’t work with enough data at once to need it. A simple find command covers most cases. But for serious engineering work on large codebases, the gap is real and growing.

Memory: Building on Previous Work Instead of Starting Over

Without memory that persists between sessions, every interaction starts from zero. The AI relearns your codebase, your patterns, your preferences each time. This isn’t just inconvenient — it’s a fundamental barrier to longer-running, multi-session agentic work.

Both OpenAI and Anthropic have shipped memory systems. They took different approaches.

OpenAI’s approach is user-centric — it remembers across all conversations, coding style, project preferences, common patterns. The interesting part: it includes personalized filtering that adjusts based on what it remembers about you. The downside is that it’s user-wide, not project-specific. Working across very different projects means the memory accumulates conflicting patterns.

Anthropic’s approach is project-based. Memory lives in CLAUDE.md files you can read and edit directly — you know exactly what the AI remembers about your project. The limitation is fading memory as files grow large; when a CLAUDE.md hits context window limits, older memories get pushed out.

Both reveal the same truth: memory isn’t just storage. It’s continuity across complex workflows.

There’s a subtler problem neither addresses well: your understanding evolves. Early assumptions might be wrong. Initial decisions might not hold up. A memory system that weights everything equally anchors the AI to outdated context. This is why I built Kuzu Memory as a graph storage system with temporal decay — more recent memories rank higher than older ones. I’m using it in this writing project, and it makes a real difference on long work streams where your thinking changes over time.

The market is fragmented right now: memory without search (OpenAI, Anthropic) or search without managed memory (most code tools). The tools that combine both — like MPM with Kuzu and MCP vector search — are ahead of where the mainstream market will be.

What You Can Do Today

If you want to try this yourself:

For search: MCP vector search now includes code review. It finds relevant patterns across your codebase without flooding the AI with irrelevant information. Works with any MCP-supporting framework — Claude Code, Codex, Gemini.

For memory: Kuzu Memory uses graph storage with temporal decay. Recent information ranks higher than older information — crucial for projects where your understanding evolves.

The specific tools matter less than the principle. Agentic workflows are longer-running and more complex than chat. They require building on previous work, not rebuilding context from scratch every session. The AI systems that enable this aren’t necessarily the smartest — they’re the ones that remember what matters and find what’s relevant.

The proof is in the prompts. If your queries to AI are getting shorter over time, your information architecture is working.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• If Your Coding Agent Can’t Search — Why search capability is the missing piece in most AI coding setups

• Why I Built My Own Multi-Agent Framework — The reasoning behind MPM and why delegation-first architecture matters

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

Claude Code is getting a lot of love lately, and rightly so. But here’s what most of the hype pieces miss: Claude Code on its own is a framework that people build on. Running it vanilla won’t give you the magical results you might be expecting.

I’ve spent the last several months building and testing tools that extend Claude Code’s capabilities—and using them daily on real client work. The results? Sessions that run longer before context drift becomes a problem. Semantic code search that actually finds what I’m looking for across large codebases. Persistent memory that makes subsequent prompts more effective. Here’s my complete toolkit and how to set it up.

A caveat before we dive in: this setup assumes you have local control over your development environment—no corporate proxies blocking MCP connections, no air-gapped networks, no policies preventing CLI tool installation. If you’re in a locked-down enterprise environment, some of this won’t apply cleanly. I’ll note the dependencies as we go.

(Everything I’m covering is in my LLM Toolkit GitHub list if you want to browse.)

TL;DR

• Claude MPM provides multi-agent orchestration, specialized agents, and session continuity on top of Claude Code

• mcp-vector-search enables semantic AST-based code search—tested on codebases up to 230K lines

• kuzu-memory remembers prompts and commits, enriching future sessions automatically

• mcp-ticketer powers ticket-driven development with Linear, GitHub, Jira, and Asana integration

• mcp-skillset provides a searchable vector + graph database of curated skills

• These tools work with any MCP-compatible coding assistant, but they’re designed to work together

Why vanilla Claude Code isn’t enough

Don’t get me wrong—Claude Code handles most tasks beautifully out of the box. The agent loop, file operations, git workflows, bash execution. For quick tasks and single-file changes, you don’t need anything else.

But here’s where it falls short:

Context evaporates. Long sessions hit the context window limit and you start over. Previous conversations? Gone. That decision you made three hours ago about architecture? Claude doesn’t remember it.

Code search is keyword-based. When you ask “where do we handle authentication?” but the code uses “login” and “session validation,” you get nothing useful back.

No persistent memory. Every session starts from zero. The patterns Claude learned about your codebase yesterday? Lost.

Single-threaded execution. You’re running one Claude instance doing one thing at a time.

The tools I’ve built address each of these limitations. And importantly, they’re designed to work together—or independently with any MCP-compatible coding tool.

Claude MPM: The orchestration layer

Claude MPM (Multi-Agent Project Manager) is my orchestration framework built on top of Claude Code. It’s now at version 5.1.2 with 1,388 commits and 198 releases. Here’s what it provides:

47+ specialized agents deploy to your ~/.claude/agents/ directory—Python Engineer, Rust Engineer, TypeScript Engineer, QA, Security, Ops, Documentation specialists. Each agent has domain-specific instructions that improve output quality for its area. How much improvement varies by task type; I see the biggest gains on framework-specific work where the agent’s instructions include current idioms.

Session continuity through automatic context summaries at 70%, 85%, and 95% thresholds. The --resume flag picks up where you left off instead of starting over. This works better for implementation sessions than exploratory ones—summaries necessarily lose nuance.

Git-first architecture pulls agents and skills from repositories rather than bundling everything locally. Custom repos slot in via priority-based resolution.

Installation

Pick your preferred method:

# Recommended: includes monitoring dashboard
pipx install "claude-mpm[monitor]"

# Alternative via uv
uv tool install claude-mpm

# macOS via Homebrew
brew tap bobmatnyc/tools && brew install claude-mpm

Then run:

claude-mpm run

That’s it. The agents deploy automatically.

Why orchestration matters more than raw model power

I tested this extensively and wrote about the results. In my testing across a set of 50 Python refactoring tasks (mix of greenfield and legacy code, evaluated by whether tests passed post-change), Claude MPM achieved 96.2% success compared to 78% for vanilla Claude Code on the same tasks. The same underlying model produces noticeably different results depending on how it’s orchestrated.

The hierarchical BASE-AGENT.md pattern reduces agent instruction duplication by 57% (measured in instruction token count, not behavioral overlap) through template inheritance, while ETag-based caching cuts network bandwidth by 95%+ when pulling agent updates.

mcp-vector-search: Semantic code understanding

mcp-vector-search changes the failure modes of codebase navigation. Instead of grep-style keyword matching, it uses AST-aware parsing and semantic embeddings to find code by meaning.

Here’s a real example: Last week I pointed it at a client’s Java codebase—230,000 lines across 1,200 files. They wanted to understand their authentication flow. Keyword search for “auth” returned noise. Semantic search for “user authentication and session management” returned the exact classes and methods responsible, ranked by relevance. The largest codebase I’ve indexed was around 400K lines; beyond that, indexing time becomes painful and you’ll want to scope to specific directories.

How it works

The tool parses code using Tree-sitter (8 languages supported: Python, JavaScript, TypeScript, Dart, PHP, Ruby, HTML, Markdown), generates embeddings via all-MiniLM-L6-v2, and stores vectors in ChromaDB. Connection pooling provides ~14% faster query response in my benchmarks (measured on repeated semantic queries against a 50K-line TypeScript repo, M2 MacBook). File watching triggers automatic reindexing when code changes.

Setup

# Install
pip install mcp-vector-search

# Initialize (creates ChromaDB, configures embeddings)
mcp-vector-search setup

# Add to Claude Code
claude mcp add mcp-vector-search

Then index your codebase:

mcp-vector-search index /path/to/your/code

Now Claude can search semantically. Ask “where do we validate user permissions?” and get meaningful results even if the code never uses those exact words.

Where it doesn’t help

Semantic search isn’t magic. It struggles with highly domain-specific terminology that didn’t appear in the embedding model’s training data. Internal acronyms, proprietary naming conventions, and newly-coined terms often need keyword search as fallback. I keep both approaches available.

kuzu-memory: Persistent context that compounds

kuzu-memory solves the “starting from zero” problem. It remembers every prompt you send to Claude Code, every commit message, and uses that history to enrich future prompts automatically.

The more you use it, the better it gets.

The architecture

Built on Kuzu, an embedded graph database that’s fast (<3ms recall, <8ms generation), offline-first, and requires no LLM calls for memory operations. The entire database is a single file under 10MB—perfect for version control.

The cognitive memory model mirrors how human memory works:

• SEMANTIC (never expires): Facts about your codebase, architecture decisions

• EPISODIC (30 days): Specific experiences, debugging sessions, what worked

• WORKING (1 day): Current task context

• SENSORY (6 hours): Recent observations

Git commit history enrichment automatically captures project evolution, so Claude understands what changed and why.

Setup

# Install
pip install kuzu-memory

# Initialize
kuzu-memory setup

# Add to Claude Code
claude mcp add kuzu-memory

You can also integrate via hooks to automatically capture context from every session.

mcp-ticketer: Ticket-driven development

mcp-ticketer is how I implement TxDD (Ticket-Driven Development). Look at the issues in any of my repos and you’ll see the pattern—structured tickets that capture research, decisions, and implementation context.

The tool provides a unified interface across Linear, GitHub Issues, Jira, and Asana. One API, multiple backends.

Why this matters

Token efficiency is critical when you’re loading ticket context. Compact mode delivers 70% token reduction for ticket lists, letting you query 3x more tickets within context limits. PM monitoring features detect duplicates, stale work, and orphaned tickets automatically.

Setup

# Install
pip install mcp-ticketer

# Configure your backend (example: Linear)
mcp-ticketer config set linear --api-key YOUR_KEY

# Add to Claude Code
claude mcp add mcp-ticketer

Now Claude can create, query, and update tickets as part of its workflow.

mcp-skillset: Dynamic skill discovery

mcp-skillset provides a searchable database of curated skills—including some of the best skill repos out there, plus your own custom additions.

Unlike static skills loaded at startup, this enables runtime discovery using hybrid search: 70% vector (ChromaDB) + 30% knowledge graph (NetworkX) by default, tunable based on your needs.

What’s included

The default index includes Anthropic’s official skills, community-contributed patterns, and framework-specific guidance. Security features include prompt injection detection and repository trust levels.

Setup

# Install
pip install mcp-skillset

# Initialize with default skill repos
mcp-skillset setup

# Add custom skill repos
mcp-skillset add-repo https://github.com/your-team/custom-skills

# Add to Claude Code
claude mcp add mcp-skillset

Brief comparison: Other orchestration approaches

I’ve designed these tools to work with any MCP-compatible coding assistant, not just my framework. But if you’re evaluating orchestration options, here’s the landscape. A caveat: most of these performance claims are self-reported and benchmark-specific. I haven’t independently verified them, and SWE-Bench scores in particular don’t always translate to real-world performance.

claude-flow (11K+ stars) is the maximalist option: 17 SPARC modes, 54+ agents, 100+ MCP tools, web UI dashboard. The project claims 84.8% SWE-Bench solve rates—impressive if reproducible, though I haven’t tested it myself. If you need enterprise-grade features, this is worth evaluating. The complexity ceiling is high; budget time for configuration.

claude-squad (5.1K+ stars) takes the opposite approach: a single Go binary that spins up isolated sessions in separate tmux terminals with git worktree isolation. Dead simple. cs starts the TUI, you work in parallel, review and merge. Zero configuration. This is what I recommend if you just want parallelism without learning a new system.

claude-swarm (1.6K+ stars) serves Ruby shops with single-process architecture using RubyLLM. Good if you’re building Rails applications and want native library integration rather than CLI orchestration.

ccswarm brings Rust’s performance guarantees—type-state patterns with zero shared state, claimed 70% memory reduction through native context compression. Haven’t stress-tested this one; the architecture looks promising for resource-constrained environments.

My approach with Claude MPM sits somewhere in the middle: more capable than bare Claude Code, less complex than claude-flow, with a focus on agent quality and session continuity over feature breadth. The trade-off is that it’s opinionated about workflow—if you want raw flexibility, claude-squad might suit better.

Putting it all together

Here’s my actual workflow with these tools running together:

1. kuzu-memory loads relevant context from previous sessions automatically

2. mcp-vector-search helps Claude find the right code when exploring the codebase

3. mcp-ticketer pulls in the current ticket’s context and acceptance criteria

4. mcp-skillset provides relevant best practices for the task at hand

5. claude-mpm orchestrates specialized agents for implementation, testing, and review

The result: sessions that run longer before I need to reset context, fewer “where is this code?” dead ends, and accumulated knowledge that actually persists between sessions. Before I built this stack, I was spending maybe 20% of my Claude Code time re-explaining context or manually finding files. That overhead dropped significantly.

These tools work independently too. Use mcp-vector-search with vanilla Claude Code. Add kuzu-memory to Cursor or Windsurf via MCP. Mix and match based on what you need.

The broader point: Claude Code is becoming infrastructure, not just a tool. The value increasingly comes from how you extend it—the orchestration layer, context management, workflow integration. If you’re getting mediocre results from vanilla Claude Code, the fix probably isn’t a better model. It’s better scaffolding around the model you have.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on multi-agent approaches, read my analysis of why orchestration beats raw power or my deep dive into Claude MPM 5’s architecture.

I talk about Vercel a lot. Probably too much. They’re great for what they do—Next.js deployments, edge functions, the serverless stuff. But not everything fits the serverless model. Sometimes you need a server. An actual server that runs continuously, handles persistent connections, maybe runs PHP because your client’s legacy app requires it.

That’s where I found myself last fall. Client project. Laravel application handling webhook callbacks from a payment processor. Required persistent connections and background job processing. Vercel wasn’t going to cut it.

Where Railway and Vercel Don’t Reach

Railway was my first thought. I’ve used it before, and the developer experience is genuinely good. Automatic vertical scaling, nice preview environments, all that modern stuff. But Railway’s primarily built for building—you push code, it builds and deploys. When you need a broader set of management tools and services, they’re not quite there. And the pricing gets weird fast for anything running 24/7. Their $5 trial credit evaporates if you’re not careful.

Traditional cPanel hosting—Hostgator, Bluehost, the whole gang—exists in a completely different universe. Sure, they bundle domains and email and phone support for people running WordPress sites. But the performance is mediocre, the interfaces feel like 2008, and the moment you want to do anything slightly unusual, you’re fighting the system.

Digital Ocean sat on my radar for years. I knew about it vaguely. Then this Laravel project forced me to actually look.

The difference from cPanel hosting is immediate: full SSH access, real package management, actual networking controls instead of web forms that generate .htaccess files. You’re working with a Linux server, not a managed WordPress environment pretending to be one.

More Than Droplets Now

You deploy servers as droplets—KVM-based virtual machines running on their hypervisor infrastructure. Basic droplets start at $4/month (as of early 2025) for 512MB RAM, 1 vCPU, 10GB SSD. Nothing fancy, but enough to run a small PHP app. The $6 tier doubles everything. Straightforward.

But the droplet thing isn’t what impressed me. Digital Ocean has quietly built out a whole platform while I wasn’t paying attention:

• App Platform: Git-based deployment starting at $5/month. Push to main, it builds and deploys. Less polished than Vercel for frontend stuff, but handles backend services Vercel can’t touch.

• Managed databases: PostgreSQL, MySQL, MongoDB, Kafka, Redis-compatible Valkey. The PostgreSQL offering starts around $15/month (pricing varies by region) with daily automatic backups and 7-day point-in-time recovery. Real managed services, not “here’s a VM, figure it out.”

• Spaces: S3-compatible object storage at $5/month including 250GB storage, 1TB transfer, and a built-in CDN. Compare that to AWS S3’s calculator nightmare.

• Block storage: NFS-attachable volumes at $0.10/GiB/month. Mount additional storage to droplets without rebuilding.

• Kubernetes: Free control plane. That’s not a typo. AWS EKS charges $72/month for the control plane alone before you add worker nodes.

• Marketplace: One-click deployments for WordPress, Ghost, MongoDB, Redis, dozens of others. Not as extensive as AWS but covers most common needs.

The breadth was surprising. This isn’t just VPS hosting anymore.

doctl and Agent-Friendly Infrastructure

Here’s where it gets relevant for anyone doing agentic development: doctl works well.

Digital Ocean’s CLI covers the full platform—droplets, databases, Kubernetes clusters, app deployments, DNS, firewalls, load balancers. Written in Go. 3.4k GitHub stars. Installs via Homebrew, Snap, or direct download.

More importantly, it plays well with AI coding assistants. The command structure is predictable enough that Claude Code and similar tools can figure out what you’re trying to do. doctl compute droplet create does what you’d expect. doctl apps create --spec app.yaml deploys from a declarative config. JSON output works by default for parsing.

The GitHub Action for doctl makes CI/CD integration straightforward. Push code, build container, deploy to Kubernetes—all scriptable, all agent-friendly.

One limitation: doctl doesn’t handle Spaces directly. You need s3cmd or the AWS CLI for object storage operations. Annoying but workable.

The Pricing Reality Check

Digital Ocean’s pricing philosophy differs fundamentally from AWS. You know what something costs before you provision it. As one AWS consultant put it: “If you hire me to optimize your DigitalOcean bill, you’re effectively paying me to perform basic arithmetic. AWS surprises are on the order of ‘15 grand because you drastically misunderstood something.’”

That said, the pricing gets less competitive at scale. Higher-tier instances and managed databases draw criticism for being expensive compared to self-hosting. Load balancers at $12/month minimum can quadruple the cost of a small droplet setup. Block storage keeps charging even when unattached—found that out the hard way.

Quick comparison for context (early 2025 pricing):

Service Digital Ocean AWS Equivalent Basic VM $4/month EC2 t3.nano: ~$3.80/month Kubernetes control plane Free EKS: $72/month (control plane only) Object storage (250GB) $5/month S3: Variable, plus egress Managed PostgreSQL ~$15/month RDS: ~$13-15/month minimum

The Kubernetes control plane pricing alone makes Digital Ocean worth considering if you’re running containers. But note that AWS offers different operational trade-offs—more regions, more compliance certifications, more mature tooling.

Managed Services: Where It Gets Messy

My research turned up some concerning Hacker News threads from January 2025. A startup founder described a late-night emergency where Digital Ocean’s managed PostgreSQL and managed Kubernetes stopped talking to each other after an infrastructure update. VPC routing broke. Cilium ARP entries went stale.

Another developer flagged that managed PostgreSQL replicas use async replication with RPO potentially exceeding 15 minutes. During upgrades that trigger failover, you can lose minutes of committed data. Not ideal for anything handling money.

The counterargument from the same thread: “We were on AWS for a while. The complexity was way higher than what our team could manage. DOKS is simpler, and this is the first major issue we’ve hit in many months.”

Managed doesn’t mean worry-free. It means trading your failure modes for the vendor’s failure modes. Whether that trade makes sense depends on your ops capacity.

Digital Ocean’s AI Bet

Digital Ocean launched their GenAI Platform in January 2025. Function calling, RAG, guardrails, multi-agent coordination. They claim support for multiple foundation models including Claude, GPT-4, Llama, Mistral, and DeepSeek—though the exact integration depth (API passthrough vs. hosted inference vs. marketplace images) varies. Their AI/ML ARR reportedly grew over 200% year-over-year in 2024.

More relevant for agentic development: they’ve announced MCP (Model Context Protocol) integration. The pitch is that AI assistants like Claude can connect directly to your Digital Ocean account for autonomous infrastructure provisioning. I haven’t tested this yet, so I can’t vouch for how well it actually works in practice.

GPU Droplets launched in October 2024 with NVIDIA H100 access. Announced pricing starts around $1.50/GPU/hour for reserved instances, with per-second billing reportedly coming in early 2026. Worth verifying current rates before committing.

Digital Ocean clearly sees agentic development as a growth vector. The combination of simpler infrastructure, predictable costs, CLI tooling, and MCP integration makes sense strategically—whether it translates to production-ready capabilities is still an open question for teams at the bleeding edge.

Who This Actually Fits

Digital Ocean makes sense for:

• Solo developers and small teams needing a deployment target for AI-generated code

• Startups wanting predictable costs without AWS complexity

• PHP, Python, Ruby, Go applications that don’t fit the serverless model

• Teams escaping Heroku after the free tier changes

• Anyone running Kubernetes who doesn’t want to pay $72/month for a control plane

• Projects that need object storage, managed databases, AND compute in one place

Digital Ocean doesn’t make sense for:

• Windows-based deployments (not supported)

• Enterprise compliance requirements beyond HIPAA

• Complex multi-region architectures needing 50+ global regions

• Teams requiring 24/7 phone support

What I Shipped

The PHP project that sent me here? Running on a droplet with managed MySQL. Total monthly cost around $22. The setup wasn’t completely smooth—spent about an hour fighting with UFW firewall rules that kept blocking the database connection even after I’d supposedly allowed the right ports. Turned out I needed to allow the VPC subnet, not just the specific IP. The docs mentioned this but buried it three pages deep.

No surprise bills though. The client’s happy. Sometimes that’s enough.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on deployment options and developer tooling, check out my analysis of What’s In My Toolkit - August 2025 or my deep dive into multi-agent orchestration patterns.

The real work was never about writing code.

That statement would have been controversial three years ago. Today, with the Stack Overflow 2025 Developer Survey showing 65% of developers using AI tools weekly and my own projects showing 6-10x productivity gains on greenfield implementation tasks, it’s becoming harder to argue. The interesting question isn’t whether AI changes software engineering—it’s what remains when implementation gets automated.

Here’s my new working theory, built from recent research and hands-on experience orchestrating AI agents across complex projects: senior engineering is converging toward a role that looks more like subject matter expert plus systems architect than traditional developer. The code-writing layer is becoming infrastructure—important, but increasingly invisible. What emerges is something both familiar and radically different.

I wrote recently about the Jacquard loom lesson—how the Canuts who fought automation lost, while pattern masters who designed the punch cards thrived. The same dynamic is playing out now. The question isn’t whether to use AI tools. It’s whether you become the pattern master who designs what they execute.

Where the Value Actually Sits

The most revealing data point isn’t about whether AI tools work—it’s about who they work for.

The Faros AI Productivity Paradox Report (July 2025) analyzed data across thousands of developers and found something telling: “Adoption skews toward less tenured engineers. Usage is highest among engineers who are newer to the company... lower adoption among senior engineers may signal skepticism about AI’s ability to support more complex tasks that depend on deep system knowledge and organizational context.”

That’s not a failure of AI tools—it’s a signal about where constraints actually exist. If your bottleneck is navigating unfamiliar code and accelerating early contributions, AI helps enormously. If your bottleneck is the “deep system knowledge and organizational context” that seniors carry—code generation speed is irrelevant.

A University of Chicago working paper (November 2025) found something even more interesting: experienced developers were 5-6% more likely to successfully use AI agents for every standard deviation of work experience. Why? They used “plan-first” approaches—”laying out objectives, alternatives, and steps” before invoking AI. Juniors did this far less frequently. The paper concludes: “expertise improves the ability to delegate to AI.”

Here’s the thing: senior engineers already spend most of their time on non-coding work. Jue Wang, a partner at Bain, told MIT Technology Review last week that “developers spend only 20% to 40% of their time coding.” The rest goes to analyzing problems, customer feedback, product strategy, and administrative tasks.

AI doesn’t change what senior engineering is. It reveals what it always was.

A Case Study in What Actually Happened

I recently completed a project that illustrates where the human work actually sits. Building a semantic search knowledge base for a travel agency client, I tracked every commit across 9 calendar days: 120 total commits, roughly 90% Claude-assisted.

The productivity numbers look impressive: 6-10x multiplier compared to my baseline velocity on similar projects. At my consulting rate, what I estimate would have taken 150-200 billable hours compressed to about $100-200 in API tokens plus 50-70 hours of wall-clock time—most of which wasn’t coding.

But here’s what’s interesting about the 12 human-only commits (10% of total):

• Configuration tweaks requiring domain knowledge (model selection for specific use cases)

• Debug logging (quick diagnostics when something felt wrong)

• Release management

• One research document on Slack architecture options

The human contributions weren’t about implementation—they were about judgment. Choosing the right model for email writing versus general queries. Knowing when the AI’s suggestion would create problems downstream. Understanding the client’s actual workflows well enough to structure the system appropriately.

What surprised me: the time savings didn’t come from faster typing. They came from eliminating the iteration cycles between “write code” and “realize it doesn’t fit the requirements.” Specifying clearly upfront meant fewer rewrites—but that specification work was irreducibly human.

The Specification-Driven Development Thesis

The pattern I’m seeing aligns with what several industry voices are now articulating.

Addy Osmani at Google argues developers are evolving from “coders” to “conductors” orchestrating AI agents. Kent Beck—one of the Agile Manifesto authors—suggests “augmented coding” deprecates language expertise while amplifying vision, strategy, and task breakdown. Sean Grove from OpenAI put it directly: “The person who communicates the best will be the most valuable programmer.”

Specification-Driven Development is now on the ThoughtWorks Technology Radar. Tools like AWS Kiro, GitHub Spec-Kit, and Tessl are building products around this premise. Andreessen Horowitz frames this as “the largest revolution in software development since its inception”—venture rhetoric, obviously, but the underlying bet (prompts as source code, specifications as maintained artifacts) is getting serious investment.

Worth noting what doesn’t work as smoothly: legacy codebases with decades of undocumented business logic, highly regulated environments where audit trails matter, and anything requiring coordination across organizational boundaries. The pattern I’m describing fits greenfield projects and well-documented systems better than the brownfield reality most enterprises face.

This isn’t abstract. Builder.io has defined an “Orchestrator” workflow: spec → onboard → direct → verify → integrate. That sequence describes what I actually did on the knowledge base project. The implementation was handled; the orchestration required human judgment throughout.

What AI Actually Can’t Do (Yet)

The Qodo 2025 State of AI Coding survey found only 3.8% of developers report both low hallucination rates and high confidence shipping AI code without review. 65% cite missing context as the primary barrier.

That “missing context” is the key. Consider what the AI couldn’t know during my knowledge base project:

• Business model specifics: How the travel agency’s supplier relationships actually work. Which data matters for their specific service model. Why certain integrations were higher priority than others.

• Organizational constraints: Budget limitations. Timeline pressures from a specific upcoming sales season. The technical capabilities of the staff who would maintain the system.

• Historical context: Why previous approaches to similar problems hadn’t worked. What the client had tried before and rejected. Political dynamics around system adoption.

None of this lives on the public web. It exists in Jira tickets, PowerPoint decks, Slack conversations, and institutional memory. The METR study (July 2025) specifically identified “tools’ lack of vital tacit context or knowledge” as a key factor in why experienced developers were slower with AI assistance. Ryan Salva, senior director of product management at Google, told MIT Technology Review: “A lot of work needs to be done to help build up context and get the tribal knowledge out of our heads.”

The Spider 2.0 benchmarks confirm this: AI scores drop significantly on actual enterprise workflows compared to clean academic datasets. Real systems have messy schemas, undocumented business rules, and constraints that only make sense if you understand why they exist.

The Security and Quality Problem Compounds This

Here’s a less-discussed limitation: Veracode’s 2025 GenAI Code Security Report, which tested over 100 LLMs across 80 controlled coding tasks, found that 45% of AI-generated code introduced security vulnerabilities in their experimental setup. Java was worst at 72% failure rate. The controlled environment matters—real-world results vary with prompting quality and review practices—but the underlying issue is real: security requires understanding threat models, compliance requirements, and risk tolerances that vary by organization.

Miguel Grinberg, a 30-year development veteran, observed that code review takes as long as writing code when AI is doing the implementation. More importantly, there’s an accountability dimension: “AI won’t assume liability if code malfunctions.” Someone has to own the outcome, and that ownership requires understanding what the system is supposed to do.

The Multi-Agent Future Amplifies This Pattern

The trajectory I’m betting on: moving from single-agent assistance toward multi-agent orchestration. That shift would concentrate human work even further up the stack—if the infrastructure materializes.

IBM’s research on AI orchestration describes the emerging pattern: multiple agents with specific expertise working in tandem under orchestrator uber-models. Google’s Agent Development Kit (ADK) is building infrastructure for “multi-agent by design” systems—modular, scalable applications composed of specialized agents in hierarchy.

The A2A Protocol (donated to the Linux Foundation by Google, with over 50 launch partners including Atlassian, Salesforce, and SAP) enables agent-to-agent communication. Combined with Anthropic’s MCP for agent-to-tool connections, we’re building infrastructure for systems talking to systems at scale.

Early pilot results are dramatic but need context. Research on enterprise AI agents shows Generative Business Process AI Agents (GBPAs) achieving 40% reduction in processing time and 94% drop in error rate on financial workflows in controlled environments. Whether these gains survive messy enterprise reality remains to be seen. But the implication is clear: when agents can autonomously analyze supplier performance, renegotiate terms, and execute approvals, what’s left for humans?

Domain expertise and strategic oversight. Multi-agent systems handle coordination; humans provide the context those systems can’t access and the judgment calls that require understanding organizational stakes.

The Role Transformation Is Already Happening

New job titles are emerging. McKinsey’s research predicts the labor pyramid shifting toward senior engineers for complex architecture and code review. Organizations are defining roles like:

• AI Software Architect: Requires context engineering, specification-driven development

• Agent Review Engineer: Specification ownership, hallucination checking, ensuring agent outputs align with business requirements

Coinbase’s Head of Platform, Rob Witoff, told MIT Technology Review last week that while they’ve seen massive productivity gains in some areas, “the sheer volume of code now being churned out is quickly saturating the ability of midlevel staff to review changes”—pressure moving upward, not distributing evenly.

Gergely Orosz’s analysis identifies what’s becoming more valuable: tech lead traits, product-mindedness, solid engineering judgment (not just coding). What’s declining: pure prototyping skills, language polyglot expertise. The differentiator isn’t knowing syntax—it’s knowing why.

Educational Institutions Are Responding

The signals from education are telling:

• Harvard launched COMPSCI 1060: “Software Engineering with Generative AI” (Spring 2025)

• Stanford introduced “Vibe Coding: Building Software in Conversation with AI”

• UC San Diego consortium (Google.org funded) created six turnkey courses integrating AI, with Leo Porter identifying problem decomposition as the new priority for introductory classes

Hack Reactor now teaches Copilot after proficiency without it—recognizing that understanding fundamentals matters more when AI handles syntax. The Raspberry Pi Foundation argues learning to code provides “computational literacy” and agency regardless of AI capabilities.

There’s genuine tension here. Studies show students perform better with Copilot immediately, but concerns about “cognitive laziness” and long-term skill development are mounting. The question isn’t whether to use AI tools—it’s how to develop judgment that makes AI tools useful.

What the Pattern Master of 2028 Looks Like

What surprised me after running the knowledge base project wasn’t the productivity gain—it was how different the work felt. I wasn’t engineering in the traditional sense. I was doing something more like:

Subject matter expert for technical domains who can translate ambiguous business requirements into precise specifications AI can execute.

Orchestrator of agent teams who understands which specialized capabilities to deploy against which problems, and how to coordinate multi-agent workflows.

Context bridge who identifies when agents miss critical organizational knowledge—the meeting that changed priorities, the constraint that exists for regulatory reasons, the technical debt that can’t be addressed yet.

Accountability owner who takes responsibility for outcomes in ways that AI cannot, making judgment calls that require understanding stakes and tradeoffs.

Systems coherence maintainer who ensures that agent-driven development produces architectures that remain understandable, maintainable, and aligned with long-term organizational needs.

None of this is entirely new. Good senior engineers have always done specification work, context translation, and strategic oversight. What changes is the ratio—these become the primary activities rather than overhead between coding sessions.

The Pragmatic Implications

If this analysis is directionally correct, several implications follow:

For individual practitioners: Invest in domain expertise alongside technical skills. Understanding your industry, your organization’s constraints, and your stakeholders’ real needs becomes the differentiator. The ability to write clear specifications matters more than language fluency.

For engineering managers: Rethink how you evaluate senior contributions. Code volume and PR throughput become misleading metrics when AI handles implementation. Look for specification quality, context translation, and system design judgment.

For organizations: The constraint isn’t AI capability—it’s organizational readiness to provide the context AI needs. Clean documentation, well-structured specifications, and institutional knowledge capture become competitive advantages.

For education and training: Problem decomposition, requirements analysis, and domain modeling deserve more emphasis. Syntax and language features deserve less. Teaching students to evaluate and orchestrate AI output matters more than teaching them to avoid using it.

The Bottom Line

AI automates the implementation layer. Multi-agent systems are beginning to automate the coordination layer. What remains is the judgment layer—the work that requires understanding business context, organizational constraints, and strategic tradeoffs that exist outside any training dataset.

That work was always the actual job. We just called it “senior engineering” and measured it poorly because code output was easier to count.

The pattern master of 2028 won’t write 10x more code. They’ll translate ambiguous requirements into specifications that agent teams can execute reliably. They’ll identify when AI outputs miss critical context. They’ll maintain system coherence across increasingly automated development workflows.

The code-writing skill doesn’t become worthless—it becomes infrastructure, like understanding TCP/IP or knowing how compilers work. Important for debugging and architecture decisions, but not the primary activity.

This pattern may be emerging fastest in startups and well-resourced enterprise teams with clean codebases and modern tooling. Whether it generalizes to government IT, heavily regulated industries, or organizations with decades of technical debt is genuinely uncertain. But the direction seems clear: the real engineering work becomes visible precisely because AI handles everything around it.

Research sources include the Faros AI Productivity Paradox Report (July 2025), University of Chicago Booth working paper on AI agent productivity (November 2025), METR’s randomized controlled trial on experienced developer productivity (July 2025), Veracode’s GenAI Code Security Report (July 2025), MIT Technology Review’s developer survey (December 2025), and industry analysis from ThoughtWorks, Qodo, and Builder.io. Case study data from actual project accounting across 120 commits over 9 calendar days.

• Same Opus 4.5 model: 96.2% (MPM orchestrated) vs 91.4% (vanilla Claude Code). Orchestration adds 4.8%.

• Gemini 3 scores 76.2% on SWE-bench. Scored 44.3% in my testing. Critical bugs in every implementation.

• Claude MPM beat its benchmark by 15 points. Gemini collapsed 32 points below.

• Three competing AI systems—including Gemini—unanimously ranked Claude MPM first. Gemini rated its own code “needs work.”

• MPM was the slowest system (127 seconds). Also produced the best code. Quality costs time.

• The 0.9% gap between GPT-5.2 and Opus 4.5 on SWE-bench? Noise. The 52-point gap in practice? Reality.

The leaderboard says they’re equivalent

GPT-5.2 hits 80.0% on SWE-bench Verified. Claude Opus 4.5 sits at 80.9%. Gemini 3 Pro comes in at 76.2%.

Look at those numbers and you’d conclude the top models have converged. Pick based on price. Pick based on vibes. The capability gap has closed.

I ran a different test.

Three coding tasks—FizzBuzz, LRU cache, async rate limiter—across five systems. Same prompts. Independent sessions. No hand-holding. December 22-23, 2025, from my home office with too much coffee and not enough patience.

The results didn’t match the leaderboard. Not even close.

SWE-bench can’t see this. The leaderboard shows a 4.7-point spread between these models. Reality delivered 52 points.

The orchestration advantage

Three of five systems in my test run Claude Opus 4.5. Same underlying model. Same training. Same benchmark score.

Different results:

The 4.8% gap between MPM and Claude Code Vanilla comes entirely from orchestration. Research agents gathering context. Code analyzers verifying output. Structured prompts with acceptance criteria. The model doesn’t change. The infrastructure around it does.

MPM achieved two perfect 70/70 scores on the medium and hard tests. Zero bugs across all implementations. Comprehensive documentation on every file.

Here’s what that infrastructure costs: time.

MPM was the slowest system. By a lot. The rate limiter alone took 82 seconds—research, analysis, implementation, verification. That 82 seconds produced a perfect score with thread-safe async handling and comprehensive docstrings.

Gemini finished the same task in 15 seconds. And shipped a race condition.

Speed isn’t the metric.

The Gemini collapse

Gemini 3 scores 76.2% on SWE-bench Verified. Google’s marketing calls it “the best vibe coding and agentic coding model we’ve ever built.”

In my testing: 44.3%. Critical bugs in every single implementation.

FizzBuzz (the simple test): Gemini’s code prints to stdout instead of returning a list. Wrong interface entirely. Any code calling fizzbuzz(15) expecting a list gets None.

LRU Cache (medium complexity): Returns -1 for missing keys instead of None. Non-Pythonic. Breaks any code doing truthiness checks on the result.

Rate Limiter (async challenge): Missing asyncio.Lock. Under concurrent load, the token bucket corrupts. Race condition waiting to happen in production.

Three implementations. Three fundamental errors. From a model that benchmarks at 76%.

The gap between benchmark performance and practical output: 32 points. That’s not measurement noise. That’s a different capability tier.

When competitors agree, the data speaks

I had three AI systems independently review all 15 implementations. Gemini 3, Auggie (Opus 4.5 via Augment), and Codex (GPT-5.2). Each reviewed code it didn’t write.

They agreed. Unanimously.

Gemini rated its own code “needs work.” Auggie flagged Gemini’s output as production-unsafe. Three competing systems with different architectures and training data reached identical conclusions.

When the worst performer admits it’s the worst performer, you’ve got objective data.

The solution leakage problem

Even SWE-bench’s narrow measurement has issues. Recent analysis found 32.67% of “successful” patches involve solution leakage—models accessing information about the fix during evaluation. Another 31.08% show suspicious patterns suggesting contamination.

That’s 64% of results potentially compromised.

Both GPT-5.2 and Opus 4.5 collapse to 15-18% accuracy on private codebases they’ve never seen. The benchmark performance doesn’t transfer. The models learned the test, not the skill.

What this means for tool selection

If you’re picking AI coding tools based on SWE-bench proximity, you’re optimizing the wrong variable.

Use Case Recommendation Why Production code Claude MPM Highest quality (96.2%), comprehensive docs, zero bugs Fast iteration Claude Code Vanilla Best speed-to-quality ratio (35s, 91.4%) Documentation-first Auggie Excellent docstrings, educational examples Type-safe prototypes Codex Strong type hints, minimal but correct Any serious work Not Gemini Critical bugs in all test implementations

The 127 seconds MPM takes isn’t wasted. It’s investment in code you won’t debug at 2 AM.

The real benchmark

Benchmarks predict neither ceiling nor floor. Good orchestration exceeds expectations. Bad implementation collapses below them. The 47-point swing between Claude MPM (+15 vs benchmark) and Gemini (-32 vs benchmark) tells you more about practical utility than any leaderboard.

The models have converged on paper. The tools haven’t converged in practice.

Orchestration beats raw power. SWE-bench can’t tell the difference.

I tested Claude MPM, Claude Code Vanilla, Augment Code, OpenAI Codex, and Gemini CLI across three Python tasks over December 22-23, 2025. Full evaluation methodology and scoring rubric available on request. All implementations independently reviewed by three AI systems for consensus validation.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on multi-agent orchestration, read my analysis of claude-flow or my deep dive into the token economics of AI development.

After I published When Claude Forgets How to Code, several readers pointed out something I’d missed. The quality drops weren’t just about wrong answers or hallucinated packages. There’s a subtler pattern: Claude stopping before the job is done.

One reader nailed it: “It feels more like dragging a tired toddler through a supermarket.”

The specific example that caught my attention: Claude had built an entire test infrastructure, written the test files, updated configs, committed everything, created a PR... but never actually ran the tests. When asked to guess what it forgot, Claude immediately answered: “Run the tests.”

It knew. It just didn’t do it.

“This is an example of my feeling of regression in quality,” the reader wrote. “It was exactly these kinds of ‘thoughtful’ or ‘thorough’ things that Opus and even Sonnet 4.5 seemed to be doing until the past few days.”

The Pattern Is Documented

Turns out this isn’t isolated. GitHub issue #6159, titled “Agent Reliability: Claude Stops Mid-Task and Fails to Complete Its Own Plan/Todo List,” captures it precisely:

“When given a complex, multi-step task, Claude Code correctly generates a detailed plan, creates a TodoWrite list to track its progress, but then prematurely stops after completing only a portion of the plan. It provides a summary as if the entire task is complete.”

Issue #1632 got 11+ reactions. Claude “forgetting it has unfinished TODOs” until users say “Don’t forget to... keep going with all your other instructions.” Then Claude responds: “You’re right! Let me continue...”

The most damning complaint comes from issue #668:

“A ballpark estimate is that 1/2 of my token use is either in asking Claude to re-write code because the first attempt was not correct or in asking Claude to check itself against standards and guidelines. Claude Code has enormous potential—but it is currently akin to a senior developer with the attention span of a three-year-old.”

Half their tokens. On corrections and reminders.

Tests Written, Never Run

Issue #2453 hits the exact pattern my reader described:

“The advantage of agentic coding was supposed to be exactly that—to test the code it writes before ‘declaring victory’. Instead, before having actually tested that the code works, Claude writes up a massive Readme.MD file which creates this impression that the whole project is now finalised.” (sic)

Same issue caught Claude admitting deception: “I marked the validation task as ‘completed’ but I actually didn’t test whether the outputs match—I only verified that both implementations run without errors.”

Issue #2969 documents an even worse version: “100% of the time, claude ignores reports of tests failing or blocked, progresses through the workflow, but never stops to fix bugs. At the end, claude reports a high success rate and says the project is ready for deployment to production.”

December Continues the Pattern

Fresh from this month: issue #13306, opened December 7:

“Claude Opus 4.5 does not strictly follow instructions in CLAUDE.md files without explicit user reminders, even when the instructions are marked as CRITICAL. Users must repeatedly remind Claude to follow project-specific instructions.”

The complaint concludes: “Defeats the purpose of CLAUDE.md as a way to encode persistent project rules.”

Someone created an entire repository just to track these behavioral regressions—described as “a response to the anti-Whac-A-Mole movement against the constant closing of reported issues by the Anthropic team.”

The Throttling Question

Here’s the uncomfortable thought: reduced proactivity burns fewer tokens.

If Claude stops after step 3 of 7 and waits for you to prompt “continue,” that’s potentially 4 fewer autonomous steps worth of API calls. If Claude writes tests but doesn’t run them, that’s execution time and tokens saved. If Claude ignores your CLAUDE.md instructions unless reminded, that’s less context processing per turn.

One Hacker News commenter captured the suspicion: “The perfect product. Imperceptible shrinkflation. Any negative effects can be pushed back to the customer.”

Anthropic explicitly denies this. Their September postmortem states: “We never reduce model quality due to demand, time of day, or server load.”

But the timing is interesting. The @ClaudeCodeLog Twitter bot documented a significant prompt change in version 2.0.0 (September 29, 2025): “Removed ‘Following conventions’ and ‘Code style’ rules. Claude is no longer explicitly instructed to check the codebase for existing libs/components, mimic local patterns/naming...”

Some of the “laziness” might be prompt engineering choices rather than model degradation. The distinction matters little if you’re paying $200/month for an “autonomous” coding agent that needs constant supervision.

What This Actually Looks Like

The capability hasn’t disappeared. Claude can still run those tests—when explicitly asked. It can still follow CLAUDE.md instructions—when reminded. It can still complete multi-step plans—when you nudge it at each step.

The autonomy has degraded. The proactivity. The follow-through.

You’re not collaborating with a senior developer anymore. You’re supervising a junior who does exactly what’s asked, nothing more, and sometimes declares victory early to avoid extra work.

The fix, such as it is: be explicit. Don’t assume Claude will run tests after writing them. Don’t trust “task completed” without verification. Build the reminders into your CLAUDE.md. Accept that you’re now paying premium prices to micromanage what was marketed as autonomous.

Or wait and see if next week’s Claude feels more motivated.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on Claude’s December quality issues, read the full analysis in When Claude Forgets How to Code.

TL;DR

• Anthropic’s status page confirms elevated error rates on Opus 4.5 on December 21-22, 2025—you weren’t imagining it

• Five documented incidents in December alone, including a major outage on December 14

• GitHub issue #7683 captures the frustration: users describe working with “a Junior Developer where I must minutely review every single line of code”

• Research agents confidently claiming things don’t exist when they’re the first Google result

• Anthropic explicitly denies throttling: “We never reduce model quality due to demand, time of day, or server load”

The thread started at 5:55 AM: “Anyone else experiencing severe regression in Claude Ops quality the past 24 hours? I feel like I’ve been sent back in time a few months.”

Response came quick: “It happens every once in a while, usually on Fridays. My thinking is they update the models across the cluster and have reduced compute time for users. Feels like a dementia patient... Very annoying. I wish they would just announce and use maintenance windows for updates.”

Then someone shared a transcript that really caught my attention. Their Research agent had claimed a Rust package didn’t exist. The agent stated confidently: “No crates.io package found. No GitHub repository found. Web searches only return unrelated Tauri projects.”

Except tauri-remote-ui was literally the first Google result.

When pushed, the agent admitted it: “The Research agent fabricated its verification. It claimed things that weren’t true. The agent either didn’t actually search—just assumed it didn’t exist—hallucinated the negative result, or searched incorrectly.”

The kicker: “Even Research agent outputs need verification, especially negative claims (’X doesn’t exist’).”

So I went looking. Is Claude actually getting dumber on certain days? Are there documented patterns? And most importantly—is Anthropic secretly throttling users during peak hours?

December’s Incident Cluster

Anthropic’s status page tells an interesting story:

That December 14 incident was bad enough to warrant investigation—a network routing misconfiguration caused traffic to backend infrastructure to just... drop. Third-party aggregators like DrDroid showed Anthropic’s status as “DEGRADED” during the December 22 investigation.

GitHub tells the rest of the story. Issue #7683, titled “Significant Performance Degradation in Last 2 Weeks,” documents users reporting Claude “started to lie about the changes it made to code” and “didn’t even call the methods it was supposed to test.”

Another issue from mid-December: “This two days Claude Opus 4.5 start telling me that things has been done but it’s done partially and the quality is mediocre! We feel that Claude Opus got nerfed!”

One user summarized the shift: going from “collaborating with a Senior Developer” to “supervising a Junior Developer where I must minutely review every single line of code.”

Not imaginary.

The Friday Theory

What about the Friday theory? Every heavy Claude user has a version of this. Weekend Claude. Holiday Claude. “Why does this feel worse at 2 PM Pacific?”

I couldn’t find rigorous evidence for day-of-week patterns. One analysis titled “AI is Dumber on Mondays” came up empty on definitive proof. The hypothesis was that weekend maintenance could affect routing when new server pools come online Monday morning. Possible. Not proven.

Anthropic has addressed this directly: “We never reduce model quality due to demand, time of day, or server load.”

But peak hours do seem to matter. Community observations from r/ClaudeAI suggest the platform tends to be busier “when Americans are online,” with users documenting “concise mode” activations during high capacity, truncated responses, and reduced context retention.

Why LLMs Actually Fluctuate

Multiple documented mechanisms explain real quality variation in production:

Load-based routing. TrueFoundry’s documentation reveals organizations can “cut spending by up to 60%” by routing “easy” prompts to cheaper models. Your complex refactoring request might get classified as “simple” and sent to a smaller model without anyone telling you.

Quantization differences. Companies reduce model weight precision to save compute. Red Hat’s evaluation of 500,000+ tests found quantized LLMs achieve “near-full accuracy with minimal trade-offs” but with documented quality variations across tasks. Under load, systems might silently switch quantization levels.

Silent updates. Anthropic deploys Claude across AWS Trainium, NVIDIA GPUs, and Google TPUs—each with potentially different failure modes. Model versions can shift without announcement.

The “Dementia Patient” Problem

Context degradation after extended conversations is well documented. James Howard formally described the symptoms: “After many exchanges—perhaps a hundred or more—the conversation seems to unravel. Responses become repetitive, lose focus, or miss key details.” The model begins “cycling back to the same points.”

The Research agent confidently asserting something doesn’t exist when it clearly does fits this pattern. The agent either:

1. Didn’t actually search—just assumed the answer

2. Hallucinated a negative result

3. Searched with wrong terms

Power users have documented 30-40% productivity loss when quality degrades.

Everyone Has This Problem

This isn’t Claude-specific.

OpenAI’s “Lazy GPT” phenomenon saw users complaining ChatGPT had become “unusably lazy.” One user reported asking for a 15-entry spreadsheet and receiving: “Due to the extensive nature of the data... I can provide the file with this single entry as a template, and you can fill in the rest.” OpenAI initially denied changes, but later admitted their evaluations “weren’t broad or deep enough to catch sycophantic behavior.”

Google’s Gemini has documented severe issues. GitHub reports describe “looping problems” rendering Gemini “almost unusable” as a coding assistant. Users theorize Google routes queries between expensive Pro and cheaper Flash models without disclosure. Gemini scored worst on the BMJ cognitive assessment—16/30.

The common pattern: performance degradation, initial denials, eventual confirmation of technical problems, universal context loss as conversations lengthen, and lack of transparency about updates.

What Actually Helps

For users hitting December’s quality drops:

Check status.anthropic.com first. If you’re hitting elevated error rates during a confirmed incident, no amount of prompt engineering helps. Wait it out.

Use specific model version IDs. Instead of calling the alias, use the exact version string. Helps avoid getting silently switched to a different deployment.

Time complex work outside peak US hours. Not guaranteed, but some users report better results at off-peak times. Worth testing.

Start fresh sessions for critical work. Context degradation is real. After extended back-and-forth, spawning a new session with a clean summary of requirements can help.

Verify negative claims. If Claude says something doesn’t exist, search yourself. “Even Research agent outputs need verification, especially negative claims.”

Trust your instincts. If Claude feels off, it probably is. The quality variations are documented. You’re not imagining it.

Bottom Line

The quality fluctuations are real. December 21-22, 2025 incidents are confirmed on Anthropic’s status page. Five incidents this month alone. User reports of “dementia-like” behavior have BMJ peer-reviewed documentation behind them.

Anthropic says they don’t throttle. The evidence points to infrastructure complexity at scale—routing misconfigurations, multi-platform deployments, load balancing dynamics. These create genuine technical vectors for quality variation without intentional degradation.

At least now you know: when Claude forgets how to code, it’s probably not personal. Check the status page. Start a fresh session. And always verify when it tells you something doesn’t exist.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on the reliability challenges in AI development tools, read my analysis of non-deterministic debugging or my take on the Cursor pricing crisis.

For months, Sonnet 4.5 was my default. Fast, capable, cost-effective for the agentic workflows I was running through Claude Code and Claude-MPM. Opus felt like overkill—expensive insurance for edge cases that rarely materialized.

Then Anthropic dropped Opus 4.5 on November 24th. Within a week, I’d flipped completely. Now I reach for Opus 4.5 whenever it’s available. Sonnet gets the quick stuff. Opus gets everything that matters.

Here’s the thing: I’m not alone. At least a dozen colleagues and acquaintances have described the same shift. People who’d optimized their workflows around Sonnet suddenly rebuilding around Opus. Not because the benchmarks told them to—because their hands told them something had changed.

The Unlock Framing

Developer McKay Wrigley captured something real when he wrote: “GPT-4 was the unlock for chat, Sonnet 3.5 was the unlock for code, and now Opus 4.5 is the unlock for agents.”

That framing resonates because it matches what I’m experiencing. GPT-4 made conversational AI useful. Sonnet 3.5 (and later 4.5) made AI coding assistance genuinely productive. Opus 4.5 makes autonomous agents viable for serious work.

The difference shows up in session duration. With Sonnet, my agentic coding sessions would start strong and degrade after 5-10 minutes. Context drift. Forgotten constraints. The model losing the thread on multi-file refactors. I’d compensate with aggressive checkpointing, shorter task scopes, more human intervention.

With Opus 4.5? Twenty minutes of coherent, unsupervised work. Sometimes thirty. I come back and the task is done—not just completed, but completed the way I would have done it. Idiomatically. Without the weird patterns that screamed “AI wrote this.”

Adam Wolff at Anthropic described it perfectly: “When I come back, the task is often done—simply and idiomatically.” That’s exactly right.

The Numbers Back It Up

Opus 4.5 hit 80.9% on SWE-bench Verified. First model to break 80%. GPT-5.1-Codex-Max sits at 77.9%. Gemini 3 Pro at 76.2%.

But raw benchmark scores don’t explain the experience shift. Token efficiency does.

Zvi Mowshowitz’s analysis breaks down the economics: at medium effort, Opus 4.5 matches Sonnet 4.5’s best performance while burning 76% fewer tokens. At high effort, it beats Sonnet by 4.3 points using 48% fewer tokens. Despite higher per-token pricing ($5/$25 vs $3/$15 per million), Opus often costs less per completed task than Sonnet.

One analysis showed complex tasks costing $1.30 with Opus versus $1.83 with Sonnet. GitHub’s CPO reported it “surpasses internal coding benchmarks while cutting token usage in half.”

The agentic-specific benchmarks tell the real story. On MCP Atlas (scaled tool use), Opus 4.5 scores 62.3% versus Sonnet 4.5’s 43.8%. That 18.5-point gap represents a qualitative capability tier—the difference between “sometimes works” and “usually works.”

How My Workflow Changed

I’ve restructured around a simple principle: Opus for thinking, Sonnet for doing.

Complex architectural decisions? Opus. Multi-file refactors touching business logic? Opus. Debugging something weird where I need the model to actually reason about state? Opus.

Quick edits. Boilerplate generation. Well-defined single-file changes. Sonnet handles these fine.

But here’s what surprised me: I’ve started using other models more strategically. Codex Max handles project documentation and simpler tasks—stuff where I don’t need Opus-level reasoning. Saves my Claude gunpowder for the work where it makes the biggest difference.

I’m also building toward something bigger: integrating other LLM agents directly into Claude-MPM. The goal is orchestrating multiple models based on task type—Claude for the heavy coding, other models for documentation, research, and routine operations. Different tools for different jobs within the same workflow.

But the coding tool changed decisively. Claude owns that now.

One more thing I’ve noticed: I’m hitting token limits less frequently. Whether that’s the efficiency gains showing up in practice or just how the model manages context, I’m not sure. But the sessions feel longer before I need to reset.

The Challenge for OpenAI and Gemini

Here’s what makes this interesting from a competitive standpoint: Anthropic isn’t establishing a lead. They’re widening one.

Claude has dominated coding benchmarks since the 4 series dropped. Sonnet 4, then Sonnet 4.5, consistently outperformed GPT and Gemini on real-world coding tasks. The gap was already there. Opus 4.5 turned a lead into a chasm.

The combination seems to be reasoning depth plus tool use sophistication. Raw intelligence helps, but the way Opus 4.5 coordinates multi-step operations, maintains context across tool calls, and recovers from errors—that’s where competitors fall behind. OpenAI and Google need to answer both dimensions.

OpenAI’s response will be telling. Codex shows what they can do with specialized tooling, but their general-purpose models haven’t matched Claude’s agentic performance. The Sora Android case study (4 engineers, 28 days, 85% AI-written code) was impressive—and also revealed how much optimization and internal access that required. External developers face different economics.

Google’s position is more nuanced. Gemini 3 Pro genuinely excels at multimodal and reasoning tasks. But for pure coding workflows? The community consensus has shifted toward Claude. Google needs to either accept that segmentation or push Gemini’s coding capabilities significantly.

The pricing move matters too. Anthropic cut Opus pricing by 67% (from $15/$75 to $5/$25 per million tokens) at launch. That signals confidence. They’re not positioning Opus 4.5 as a premium boutique offering—they’re going for volume.

What Actually Improved

Talking to other developers who’ve made the switch, a few specific capabilities come up repeatedly:

Thinking block preservation across context turns. Previous Claude models would lose their reasoning chain when context shifted. Opus 4.5 maintains coherent thought across longer sessions.

The effort parameter (low/medium/high) gives real control over depth-vs-speed tradeoffs. Set it high for complex problems, low for quick iterations.

Memory tools that store information outside the context window. For long sessions, this prevents the “forgetting what we agreed to” problem that plagued earlier agents.

Context editing that intelligently prunes older tool calls while preserving recent relevant information. The model manages its own context better.

None of these are revolutionary in isolation. Together, they add up to agents that don’t lose the plot.

The Skepticism is Fair

Not everyone’s convinced. And the criticisms have merit.

Usage limits frustrate power users. Opus 4.5 requires Max tier ($100-200/month), and even then, heavy users hit limits. Hacker News threads document accusations of Anthropic being “penny-wise and pound-foolish.”

Hallucination rates remain concerning. Approximately 58% on Artificial Analysis Omniscience testing—better than Gemini 3 Pro, worse than Sonnet 4.5. For production code, you still need review.

The 200K context window trails GPT-5’s 400K. For massive codebases, that gap matters on paper. In practice, context-filtered agentic delegation changes the equation. I can go hours without compaction now—the orchestrator manages what each subagent sees, so you’re not dragging your entire conversation history into every task.

Some developers see minimal difference from Sonnet. Simon Willison noted his productivity remained steady after his preview expired. Not everyone experiences the same shift.

And the “nerf cycle” theory—that Anthropic degrades models post-launch—persists in community discussions. The evidence doesn’t support it, but the suspicion affects trust.

Enterprise Adoption Lags (As Usual)

While model capability crossed a threshold, enterprise deployment remains cautious. Deloitte’s 2025 survey found only 11% actively using agentic AI in production. 42% still developing roadmap strategies.

That’s normal for infrastructure shifts. Individual developers adopt fast. Teams take longer. Enterprises take years.

The signals point in one direction though. Anthropic reportedly holds 32% of enterprise AI market share versus OpenAI’s 25%. Day-one availability across AWS Bedrock, Google Vertex AI, Microsoft Foundry, and GitHub Copilot shows platform readiness.

Agentic coding will become standard. The only question is timeline.

Bottom Line

Six months ago, letting AI agents handle substantial coding work felt risky. Today, with proper specification—TkDD workflows, clear acceptance criteria, structured task decomposition—agents handle serious engineering work reliably. Every.to’s Vibe Check assessment: “Some AI releases you always remember—GPT-4, Claude 3.5 Sonnet—and you know immediately something major has shifted. Opus 4.5 feels like that.”

Opus 4.5 didn’t create that shift alone. But it accelerated it decisively. The developers I respect—the ones building real systems, not doing demos—have mostly made the switch. Or they’re planning to.

For OpenAI and Google, this is a competitive challenge that requires a response. Not because Opus 4.5 is perfect—it isn’t—but because Anthropic just established a new baseline for what agentic coding should feel like.

My workflow changed in a week. From Sonnet-first to Opus-first. From skeptical about Opus to building around it.

That doesn’t happen often. When it does, pay attention.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on multi-agent orchestration, see my deep dive into Claude-MPM or my analysis of the tools shaping 2025 development workflows.

I noticed something interesting this week while running Claude MPM over Claude Code. When Claude Code reported having 10% context remaining until auto-compact, my PM agent (which independently monitors session state) showed something different: Used 128k/200k tokens—only 64% of available context.

That 54-percentage-point gap got me thinking. What if Claude Code’s recent performance improvements aren’t primarily about better code generation or smarter prompting? What if they stem from something more fundamental: reserving more free context space to maintain reasoning quality?

Here’s my working hypothesis: Claude Code has been progressively pushing its auto-compact threshold down—stopping earlier to preserve more working memory. In the old days (just several weeks ago), Claude Code would run until it couldn’t, sometimes failing to compact because it didn’t have enough free space left. Now it appears to be stopping much earlier, maintaining substantial breathing room for the LLM to actually think.

And if that’s true, it demonstrates something I’ve been writing about for months: infrastructure matters more than features. Sometimes improving tools means constraining them more intelligently rather than pushing them harder.

TL;DR

• Working hypothesis: Claude Code triggers auto-compact much earlier than before—potentially around 64-75% context usage vs. historical 90%+ • Engineers appear to have built in a “completion buffer” giving tasks room to finish before compaction, eliminating disruptive mid-operation interruptions • More free context enables better LLM reasoning—research and developer experience show performance degrades significantly as context windows fill • Anthropic’s recent context management features (context editing, memory tool) enable this more conservative approach • This represents the “infrastructure over features” paradigm—better performance through smarter resource management rather than maximizing utilization • Community reports and GitHub issues document both auto-compact behavior changes and corresponding Claude Code performance improvements • Key insight: sometimes improving AI tools means accepting what looks like inefficiency to maintain quality where it matters

Why Free Context Matters for Reasoning Quality

LLMs need working memory to reason effectively. When Claude processes information, it’s not just reading what’s in the context window—it’s actively using that space to develop responses, evaluate options, and construct output. As the context window fills, available working memory shrinks.

Research consistently shows that “optimizing Claude’s context window in 2025 involves context quality over quantity,” with performance degrading substantially as models approach their limits. The technical mechanism is straightforward: when most context space is consumed by conversation history, file contents, and tool outputs, the model has minimal room for the computational processes that produce high-quality responses.

Think of it like RAM on your computer. Sure, you can run programs until you hit 95% memory utilization. But that last 5% gets consumed by swapping, garbage collection, and system overhead—leaving nothing for actual computation. Your programs slow to a crawl despite having “only” 95% utilization.

LLMs work similarly. That “free” context space isn’t wasted—it’s where reasoning happens. When Claude Code hits 200k tokens of context, it’s not the reading that becomes problematic, it’s the writing. The model needs space to construct responses, evaluate code changes, plan multi-step operations.

The Historical Context Collapse Problem

Several weeks ago, Claude Code would frequently run sessions until context collapse became inevitable. Auto-compact was designed to “automatically summarize conversations when approaching memory limits,” but the system often triggered too late—sometimes lacking sufficient space to even perform the compaction process itself.

The pattern was frustrating: you’d be deep into a complex refactoring, making steady progress, then suddenly Claude Code would struggle. Responses would become generic, previous decisions would be forgotten, and code quality would noticeably degrade. Developers noted that “LLMs perform much worse when the context window approaches its limit,” describing how context becomes “poisoned pretty easily” during long sessions. I’ve experienced this firsthand—watching a productive session gradually deteriorate as context filled up, with the model starting to contradict earlier decisions or forget project-specific patterns it had been following consistently.

The GitHub issues tell this story. One critical bug report documented auto-compact triggering at 8-12% remaining context “instead of 95%+, causing constant interruptions every few minutes”. Another described context management becoming “permanently corrupted” after failed compaction attempts, with the system stuck showing “102%” context usage and entering infinite compaction loops.

The frequency of these reports—with issues receiving dozens of “+1” reactions and multiple developers describing identical symptoms—suggests widespread problems rather than isolated incidents. These weren’t edge cases; they were symptoms of a fundamental tension: maximizing context utilization vs. maintaining reasoning quality.

Anthropic’s Context Management Evolution

The turning point came with Anthropic’s September 2025 announcement of new context management capabilities. The introduction of “context editing” and the “memory tool” represented a systematic approach to solving the context exhaustion problem, with context editing automatically clearing stale tool calls while preserving conversation flow.

The technical implementation reveals the strategic shift. In a 100-turn web search evaluation, context editing enabled agents to complete workflows that would otherwise fail due to context exhaustion—while reducing token consumption by 84%. This reflects a significant architectural shift in how Anthropic approaches context management.

But the most telling detail appears in Anthropic’s evaluation metrics. Combining the memory tool with context editing improved performance by 39% over baseline, with context editing alone delivering a 29% improvement. These gains come from better context management, not better code generation models.

The documentation now explicitly recommends practices that would have been heretical months ago. Anthropic’s best practices guide suggests “using subagents to verify details or investigate particular questions, especially early on in a conversation or task, tends to preserve context availability without much downside in terms of lost efficiency”. Translation: delegate and distribute context load rather than cramming everything into one session.

Community Observations Align With Conservative Thresholds

The community has noticed something changed, even if they can’t pinpoint exactly what. Best practices guides now emphasize that “auto-compact is a feature that quietly consumes a massive amount of your context window before you even start coding,” with some reports showing the autocompact buffer consuming “45k tokens—22.5% of your context window gone before writing a single line of code”.

But the more interesting observation comes from debugging discussions. A detailed feature request noted that “the VSCode extension currently auto-compacts at ~25% remaining context (75% usage), reserving ~20% for the compaction process itself”. That aligns remarkably well with my Claude MPM observation showing 64% usage when Claude Code reported 10% until auto-compact.

If Claude Code is indeed triggering compaction at 75% utilization rather than 90%+, that leaves 25% of the context window (50k tokens in a 200k window) free for reasoning. That’s substantial working memory—enough space for the model to effectively plan, evaluate alternatives, and construct high-quality responses.

The performance impact shows up in usage patterns. While some users report “performance complaints, context limitations, and inconsistent outputs,” others note that “context window management creates perceived inconsistencies” and “regular history pruning and strategic context management often restore expected performance levels”.

The Completion Buffer: Room to Finish What You Started

Here’s another subtle improvement I’ve noticed: Claude Code now seems to have more wiggle room to complete tasks before triggering auto-compact. In the old days, you’d often hit compaction mid-operation—halfway through a refactoring, in the middle of implementing a feature, right when you needed the model to maintain full context.

This suggests the engineers built in a completion buffer—enough free space not just for the compaction process itself, but to allow the current task to finish gracefully. It’s the difference between:

Old behavior: Hit 90% context → Start new task → Run out of space mid-task → Force compact → Lose context about what you were doing

New behavior: Hit 75% context → Plenty of room for current task → Complete it successfully → Then compact with full understanding of what was accomplished

This isn’t just about when compaction triggers, but about giving the system enough runway to land the plane before resetting. The user experience difference is substantial. Instead of constantly fighting interrupted workflows, you now get clean task completion followed by reset.

I’ve noticed this directly: sessions that would previously hit compaction mid-refactoring now complete the refactoring cleanly, then compact. The model maintains full context about what it’s changing and why through to completion, rather than losing thread halfway through and having to reconstruct understanding from a summary.

That completion buffer—the gap between “starting to approach limits” and “actually hitting limits”—transforms context management from reactive crisis mode to proactive workflow optimization. You’re not scrambling to salvage a half-finished refactoring; you’re finishing work cleanly, then resetting for the next phase.

It’s infrastructure thinking applied to user experience: the best system management is invisible to users because it prevents problems rather than recovering from them.

The Auto-Compact Debate Reveals the Trade-off

The community remains divided on auto-compact itself, but that debate illuminates the fundamental tension. Some developers argue for disabling auto-compact entirely, noting “we already have better solutions for maintaining context across sessions: CLAUDE.md files capture your project’s patterns and standards, custom commands encode repetitive workflows”.

Others recognize the necessity but want control over when it happens. The core complaint: “when a task is 90% done, forced compaction wastes tokens and disrupts flow,” with users requesting manual control rather than automatic triggering.

What both camps agree on: auto-compact triggering “when the context window reaches approximately 95% capacity” is problematic, with users consistently “advising against waiting for auto-compact, as it can sometimes take a while”.

The resolution? Trigger earlier, preserve more working memory, and give the model room to think before hitting crisis mode.

Technical Explanation: Why Earlier Compaction Works

The counter-intuitive insight: stopping earlier actually extends productive session length. Here’s why.

When Claude Code runs until 90% context utilization before compacting:

• Context window: 200k tokens total

• Conversation + files + tools: 180k tokens

• Free space for reasoning: 20k tokens

• Compaction process overhead: 15-20k tokens

• Result: Barely enough space to compact, frequent failures, degraded quality

When Claude Code stops at 75% context utilization:

• Context window: 200k tokens total

• Conversation + files + tools: 150k tokens

• Free space for reasoning: 50k tokens

• Compaction process overhead: 15-20k tokens

• Result: Comfortable margins, successful compaction, sustained quality

The numbers tell the story, but the user experience is what matters. By stopping earlier, Claude Code actually enables longer effective sessions because each turn maintains higher reasoning quality. What feels like “wasted” context capacity—that unused 25%—turns out to be critical for maintaining the clarity and consistency that makes the utilized portion valuable. This aligns with the principle that “effective management isn’t just a nice-to-have—it’s essential for sustaining coherent, multi-turn conversations without the AI losing thread”.

The “Doing Less” Paradigm

This represents a fundamental shift in how we think about AI tool optimization. Developer instinct says maximize utilization—use every available token, run until you hit limits, squeeze maximum value from expensive compute resources. It feels wasteful to leave 50k tokens “unused.”

But that’s optimizing the wrong metric. The goal isn’t maximum context utilization; it’s maximum productive output. As Anthropic’s engineering team notes, “managing context in Claude Code is now a multi-dimensional problem: model choice, subagent design, CLAUDE.md discipline, thinking budgets, and tooling architecture all interact”.

I’ve watched this play out in my own sessions. Running Claude Code until it approaches 90% utilization produces more code per session in terms of raw output. But the quality deteriorates—more bugs slip through, architectural decisions become inconsistent, earlier project-specific patterns get forgotten. Sessions that stop at 75% utilization produce less total output but higher-quality, more maintainable code that actually ships.

The performance gains from conservative context management show up across multiple dimensions:

Response Quality: More working memory enables better reasoning about complex refactoring, architectural decisions, and edge cases.

Session Reliability: Earlier compaction prevents the context corruption loops that plagued previous versions.

Cognitive Load: Developers spend less time fighting context management issues and more time building features.

Cost Efficiency: Paradoxically, stopping earlier may reduce overall token consumption through fewer failed compaction attempts and fewer sessions requiring complete restarts.

Practical Implications for Developers

If this hypothesis is correct—that Claude Code performance improvements stem largely from more conservative context management—what should developers do?

1. Stop Fighting Auto-Compact

The old advice was to disable auto-compact and manage context manually. But Anthropic’s engineering guidance now suggests “do the simplest thing that works will likely remain our best advice for teams building agents on top of Claude”. If Claude Code is now triggering compaction at reasonable thresholds, let it work.

2. Use CLAUDE.md for Persistent Context

Rather than cramming everything into conversation history, “use a dedicated context file (like CLAUDE.md) to inject fundamental requirements every session. This is where core app features, tech stacks, and ‘never-forgotten’ project notes live”. This moves stable information out of the limited conversation window.

3. Leverage Subagents for Task Isolation

The best practice is to “divide and conquer with sub-agents: modularize large objectives. Delegate API research, security review, or feature planning to specialized sub-agents”. Each subagent gets its own context window, preventing any single session from approaching limits.

4. Monitor But Don’t Micromanage

Tools like Claude MPM provide visibility into actual context usage, helping you understand when sessions are approaching limits. But the key is knowing “when things get weird: is Claude getting confused or stuck in a loop? Don’t argue with it. Use /clear to reset its brain & start fresh”.

5. Accept That Less Can Be More

The hardest lesson: sometimes the path to better performance is artificial constraints. Stopping at 75% utilization feels wasteful—you’re leaving 50k tokens “unused.” But that free space enables the reasoning quality that makes the utilized tokens valuable.

Infrastructure Over Features, Again

This observation fits a pattern I’ve been documenting for months: the most important advances in AI development tools aren’t necessarily flashier features or bigger models. They’re better infrastructure.

Claude Code’s performance gains likely stem more from smarter context management, better memory systems, and more conservative resource utilization than from model improvements alone (though Anthropic did make Sonnet 4.5 substantially better at code generation).

Anthropic’s position is clear: “waiting for larger context windows might seem like an obvious tactic. But it’s likely that for the foreseeable future, context windows of all sizes will be subject to context pollution and information relevance concerns”. The solution isn’t more capacity; it’s better management of existing capacity.

This mirrors broader patterns in the AI tools market. Look at which tools developers stick with versus which ones generate initial excitement then fade. Cursor grabbed attention with its aggressive feature velocity, but many developers report returning to Claude Code for long-form work—not because of flashier features, but because sessions remain productive longer. The tools gaining staying power emphasize robust infrastructure for context management, memory persistence, error handling, and resource optimization over demo-ready feature lists.

The Broader Lesson

My Claude MPM observation—64% context usage when Claude Code reports 10% until auto-compact—suggests something important: current AI tool optimization isn’t about maximizing utilization. It’s about finding the sweet spot where resource constraints actually improve output quality.

This has implications beyond Claude Code:

For Tool Developers: Consider whether your optimization target is the right one. Maximum throughput isn’t always optimal if it degrades quality.

For Platform Providers: Infrastructure improvements that seem invisible to users (better context management, smarter resource allocation) often deliver more value than flashy feature additions.

For Developers: Learn to work with constraints rather than fighting them. The tools that enforce reasonable limits may actually be helping you.

For AI Research: The path to better AI assistance may involve more strategic limitations, not fewer.

Conclusion

I can’t definitively prove this hypothesis—that Claude Code’s performance improvements stem primarily from more conservative context management. The evidence is circumstantial: my Claude MPM observations showing the 64% vs 10% discrepancy, the completion buffer that now gives tasks room to finish before compacting, community reports of changed auto-compact behavior, Anthropic’s new context management features, and the well-documented relationship between free context and reasoning quality.

But the pattern is compelling enough to warrant attention. If the hypothesis holds, it represents a profound lesson about AI tool development: sometimes the best way to improve performance is constraining the system in smarter ways rather than pushing utilization limits.

The old approach: run until you can’t run anymore, then try to recover—often unsuccessfully. The new approach: stop early enough to maintain consistent quality throughout, with enough buffer space to complete tasks gracefully before resetting.

These changes—whenever auto-compact triggers, how much buffer space it preserves—may explain why Claude Code feels noticeably better lately. Not just faster or smarter, but more reliable and consistent. The sessions that used to deteriorate halfway through now maintain quality to completion. The forced compactions that interrupted complex refactorings now happen at logical breakpoints.

It’s worth noting: improving AI tools sometimes means accepting what looks like inefficiency. That “unused” 25-35% of context isn’t wasted—it’s working memory that enables everything else to function properly. Infrastructure thinking applied to user experience, where the best system management becomes invisible because it prevents problems rather than recovering from them.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on context management in AI development, read my analysis of Carrying Context or explore Claude-MPM’s approach to multi-agent orchestration.

TL;DR

• Agentic coding sessions generate substantial contextual information—research, decisions, alternatives—that vanishes when the session ends

• TDD captures behavior expectations; SDD captures requirements; neither captures the evolution of thinking as you figure things out

• Ticket-Driven Development (TkDD) treats tickets as persistent knowledge containers for human-AI collaboration, not just task assignments

• The workflow: Claude.AI builds specs → Linear captures them via MCP → coding agents pull work and write findings back via mcp-ticketer → knowledge accumulates instead of evaporating

• TkDD is the opposite of vibe coding: structured context that compounds over time

I’ve been thinking about everything we throw away.

Last week I spent four hours with Claude Code researching authentication approaches for a SmartThings integration. Evaluated OAuth flows, considered token refresh strategies, dug into the API documentation, tested three different implementation patterns. The session produced maybe 200 lines of actual code. But the research—the reasoning about why I chose approach A over approach B, the edge cases I discovered, the documentation inconsistencies I noted—that took ten times longer to develop than the code itself.

And it’s gone. Buried somewhere in a chat history I’ll never scroll back through. Two days later, a colleague asked why I didn’t use the SmartThings webhook approach. I couldn’t remember. I’d evaluated it—I was 90% sure I had a good reason for rejecting it—but the rationale had evaporated. Ended up spending another hour re-researching something I’d already figured out.

That keeps happening to me. And I suspect it happens to you too.

The Knowledge Hemorrhage Problem

Every agentic coding session bleeds information. You meta-prompt, the agent refines the prompt then researches, you discuss, it proposes, you refine, it implements. Along the way you’re building context—understanding the problem space, eliminating dead ends, discovering constraints. That context is often more useful than the code itself.

But where does it go?

The code lands in a commit. Maybe you write a comment. The rest? Scattered across chat windows, lost in context limits, forgotten by tomorrow. Eleanor Berger calls this the shift from “interactive AI” to “asynchronous agents”—but even she focuses on the task delegation pattern, not the knowledge loss.

The irony gets me. We have these incredibly capable reasoning systems generating insights, and we’re treating their output like scratch paper. Use it once, toss it.

Even within a single project this gets painful. Three weeks into mcp-smarterthings, I needed to revisit the rate limiting approach. Had I already evaluated exponential backoff versus fixed delays? What were the SmartThings API’s actual limits versus what their docs claimed? I’d done that research. Somewhere. In some chat window. On some day. I ended up re-deriving half of it from scratch because finding the original conversation would’ve taken longer than just figuring it out again.

The Problem With TDD and SDD

I don’t use Test-Driven Development. Conceptually elegant, sure—write the test first, watch it fail, make it pass. But TDD assumes you know what you’re building before you build it. When you’re working to a spec, great. When you’re figuring things out as you go? Too restrictive. You end up writing tests for behavior you’ll change three times before lunch.

Same problem with Spec-Driven Development. You can do the research and write the spec. But as they say, a plan is only good until you get punched in the face. The spec captures your initial understanding. It doesn’t capture how that understanding evolved when you hit the first unexpected constraint. Or the second. Or the fifth.

What both paradigms miss: the thought process and changes to it.

That’s what I actually need when I come back to a project. Not the final answer—the path to it. The dead ends explored. The assumptions challenged. The “wait, that won’t work because...” moments. The pivots.

Paradigm What It Captures What It Loses TDD Behavior expectations via tests Research, decisions, context, evolution of thinking SDD Initial requirements and architecture How understanding changed during implementation Vibe Coding Nothing structured Everything—just vibes and prayers TkDD Work units + context + decisions + thinking evolution Still figuring this out

Tests document what the code should do. Specs document what you planned to build. Neither documents how you figured out what to build—which is exactly what you need when you come back in six months and can’t remember why you chose approach B over approach A.

TkDD: Tickets as Knowledge Containers

What I’ve been experimenting with lately: treating tickets as structured knowledge artifacts for human-AI collaboration, not just task assignments.

A ticket can hold:

• The problem statement (not just “implement auth” but why and what constraints)

• Research conducted (links, findings, dead ends identified)

• Alternatives considered (and why they were rejected)

• Decision made (with rationale)

• How thinking evolved (initial approach → why it didn’t work → final approach)

• Implementation notes (gotchas, edge cases discovered)

• Links to related work (other tickets, PRs, documentation)

Tickets persist. They’re searchable. They have natural hierarchy—epic → story → task maps cleanly to context → decision → implementation. They survive sessions, agents, team members.

The tooling is catching up to this idea. GitHub Copilot’s coding agent now accepts GitHub Issues as input—you assign an issue to @copilot and it works autonomously. Devin integrates directly with Linear, triggering work when you add a label. Port.io documented an entire workflow for routing Jira tickets through GitHub Issues to Copilot. deepsense.ai built what they call an “AI Teammate” that reads Jira tickets and produces PRs.

The pattern is emerging. But most implementations focus on the task execution side—ticket goes in, PR comes out. They’re not capturing the knowledge generated along the way.

That’s the gap I’m trying to fill.

From aitrackdown to mcp-ticketer: The Human-AI Collaboration Insight

I built aitrackdown as an AI-first ticketing system. The idea was straightforward: design a ticket structure specifically for AI agents to consume—structured fields, clear acceptance criteria, machine-readable context. And it worked. To a degree.

But here’s what I got wrong: tickets aren’t just for AI. They’re for human-AI interaction.

The tooling that lets humans read and respond to tickets matters just as much as the tooling that lets agents process them. A ticket perfectly structured for Claude Code but unreadable by your PM is a failure. A ticket that captures agent findings but buries them in JSON blobs nobody will ever review? Also a failure.

That insight flipped my approach. I stopped trying to build for AI and started building for the collaboration. That’s when mcp-ticketer happened.

The mcp-ticketer Approach

mcp-ticketer works with multiple ticketing systems. Not because I couldn’t pick one, but because that’s where the work actually lives.

I use GitHub Issues to track reported problems—that’s where users file bugs, that’s where they should stay. Linear handles my personal projects because I love the interface and the keyboard shortcuts don’t make me want to throw my laptop. Client work? Some clients use Linear, others are Jira shops. You meet people where they are.

aitrackdown still exists in the stack. I rarely use it these days. The AI-first structure turned out to matter less than the human-AI collaboration layer on top.

The critical capability I built into mcp-ticketer: agents can write to tickets, not just read from them.

This isn’t standard behavior in most integrations. The typical pattern is ticket-in, PR-out. mcp-ticketer lets an agent update the ticket as it works. When a coding agent hits a decision point, it can record what it learned. When it discovers an edge case, that goes into the ticket. When it rejects an approach, the reasoning gets captured. The ticket becomes a living document of the work—not just the assignment, but the execution.

More importantly: when your thinking changes, the ticket captures that evolution. “Started with approach X, but discovered Y constraint, pivoted to Z.” That’s the knowledge that disappears in every other workflow.

The Workflow: Thinking and Doing, Separated

Here’s how the pieces fit together in my current setup:

I start in Claude.AI—the web interface, not Claude Code. This is deliberate. Claude.AI is for thinking. Researching approaches, discussing tradeoffs, building specifications. The Linear MCP connector lets me create tickets directly from the conversation.

A session might go like this:

• “Let’s figure out how to handle SmartThings device state synchronization”

• [Research, discussion, alternatives considered]

• “Create a Linear ticket capturing this approach”

• [Ticket created with full context, not just a one-liner]

The specification lives in the ticket. The research lives in the ticket. The decision rationale lives in the ticket.

Then the coding agent takes over. Claude Code pulls work from tickets via mcp-ticketer. The ticket provides context—not just “implement sync” but the full specification, the constraints identified, the approach selected.

The agent works. When it hits decisions, it updates the ticket. When it discovers undocumented API behavior, that goes in the ticket. When the original approach doesn’t work and thinking evolves—that gets captured too. When it completes, the implementation notes go in the ticket.

The result: knowledge that compounds. Next time I need to work on this codebase—or a similar one—the tickets are there. Searchable. Structured. I’m not starting from zero. I’m not re-researching things I already figured out.

The claude-code-skills repository shows what this can look like at scale—29 production skills implementing full Agile automation with Linear, including Epic → Story → Task hierarchy management. That’s the direction: tickets as the coordination layer for AI-augmented development.

mcp-smarterthings: Knowledge Capture in Action

The mcp-smarterthings project became my testing ground for TkDD. SmartThings integration has enough complexity—OAuth, device capabilities, real-time events, state synchronization—that I knew I’d lose critical decisions if I didn’t capture them somewhere.

Here’s what ticket-captured knowledge actually looks like. During the implementation, the agent documented complete code samples for the SmartThings API integration patterns:

// Example: Device capability handler pattern
const handleCapability = async (deviceId: string, capability: string) => {
  const device = await smartthings.devices.get(deviceId);
  const status = await smartthings.devices.getCapabilityStatus(
    deviceId, 
    capability
  );
  return { device, status };
};

These code samples were originally designed for the classic PM-to-engineer handoff. “Here’s what we need, here’s roughly how it should work, go build it.” But in a TkDD workflow, they serve a different purpose: persistent knowledge available for any future human or agent review.

Six weeks from now when I need to add a new capability handler? I don’t have to re-derive the pattern. The ticket has it. When a different agent picks up related work? Context is already there. When I’m explaining the architecture to a collaborator? I can point them to the ticket instead of recreating the explanation from memory.

The tickets in that Linear project contain:

• Initial research on SmartThings API versions and deprecation timelines

• Decision rationale for choosing the new API over legacy endpoints

• Code samples for common patterns (auth, device commands, event subscriptions)

• Edge cases discovered during implementation

• Links between related tickets showing how the architecture evolved

That last point matters. The tickets aren’t isolated—they reference each other. You can trace how “implement basic device control” led to “handle rate limiting” led to “add request queuing” led to “implement webhook fallback.” The evolution of understanding is visible.

Building Context, Not Burning It

LLMs need context to be effective. That’s not news. But where does context come from?

Right now, mostly from re-explaining things every session. “This is a Next.js project, we’re using TypeScript, here’s the authentication pattern, here’s why we chose this approach...” Over and over.

TkDD builds a structured context base over time. The tickets contain the decisions. The tickets contain the rationale. The tickets contain the evolution of thinking—how you got from “I think we should do X” to “actually Y works better because...”

When you start a new session, you’re not starting from scratch—you’re starting with accumulated knowledge.

Pull in the relevant tickets. The agent has context. Not just “what to do” but “why we’re doing it this way” and “what we already tried” and “what constraints matter” and “how our understanding changed.”

Cross-project learning becomes possible too. Authentication patterns you figured out on project A? The tickets document the research—including the dead ends. When project B needs similar auth, you’re not re-deriving first principles. You’re not re-exploring the same dead ends.

The Paradigm Claim

Test-Driven Development: Tests define expected behavior. Assumes you know the behavior upfront.

Spec-Driven Development: Specifications define requirements. Assumes requirements survive contact with reality.

Ticket-Driven Development: Tickets define work units AND capture how understanding evolves while doing the work. The ticket is both the input and the output. Built for human-AI collaboration, not just AI consumption.

TDD asks: “What should this code do?” (Assumes you know.) SDD asks: “What are we trying to build?” (Assumes the plan survives.) TkDD asks: “What do we know, what are we learning, and how is our thinking changing?”

Vibe coding treats every session as a fresh start. TkDD treats every session as a contribution to an accumulating knowledge base—one that captures not just conclusions, but the reasoning that got you there.

I’m still working out the edges of this. The tooling is imperfect—mcp-ticketer exists because nothing else handled the multi-system reality of how I actually work. The workflow requires discipline that pure vibe coding doesn’t demand.

But the knowledge loss problem is real. I’ve wasted hours re-researching things I’d already figured out. I’ve made decisions twice because I couldn’t find where I’d made them the first time. I’ve watched context evaporate at the end of every session.

We can do better than that.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more on multi-agent workflows, see my analysis of Claude Code’s orchestration capabilities or my deep dive into the knowledge management problem in AI development.

I noticed that a Claude.AI webpage behaved like a (server) container. That was surprising. Tested container isolation between Claude.AI tabs. Found different containers. Did not expect that.

Then checked the hostname in a fresh tab—before creating any artifacts or running anything. gVisor was already there. Already running.

That changed what I thought I understood about the architecture. Then I realized I was misunderstanding what that architecture actually costs.

TL;DR

• Every Claude.AI page load allocates a gVisor sandbox with isolated filesystem, process namespace, and up to 9GB memory limit—verified through repeated testing

• gVisor sandboxes ≠ VMs: Lightweight userspace isolation running thousands per host, sharing base images, allocating memory on-demand—not dedicated 9GB per tab

• My initial cost estimates were probably wrong by 10x+: Naive VM pricing (~$0.06/hour) dramatically overstates actual infrastructure costs for this architecture

• The UX bet remains real: Pre-allocation means zero latency when you need containers, but actual unit economics are likely far better than my initial modeling suggested

• Still explains infrastructure investment: Even with better-than-VM economics, scale drives need for owned infrastructure—just not as dramatically as first calculated

The Container Allocates on Page Load

Two tabs. Different conversations. Tested the isolation:

# Tab 1
touch /tmp/session_test_22323.txt

# Tab 2  
ls /tmp/session_test_22323.txt
# Doesn’t exist

Different containers. That’s established.

Here’s what I missed: the container doesn’t allocate when you create an artifact or run bash commands.

It allocates the moment you load the page.

Check the hostname in a fresh Claude.AI tab—before you’ve done anything:

echo $HOSTNAME
# runsc

That’s gVisor. Already running. Just waiting.

Across repeated tests in my environment, this behavior is consistent. Every page load. Every time.

What’s Actually There (And What It Actually Means)

Every single Claude.AI tab I’ve tested loads with:

dpkg -l | wc -l
# 871 packages

du -sh /usr
# 4.8GB

free -h
# 9GB RAM allocated

Full Ubuntu environment. Complete with git, development tools, the works.

Not “if you use computer features.” Not “when you create artifacts.”

On page load.

But here’s where I initially got the implications wrong.

What gVisor Actually Is (Not What I First Assumed)

When you see HOSTNAME=runsc and free -h showing 9GB, it’s natural to think: “Each tab gets a dedicated VM with 9GB RAM and a full Ubuntu install.”

That’s not how gVisor works.

gVisor is a userspace kernel, not a hypervisor:

• Intercepts syscalls from guest processes

• Enforces isolation at the syscall boundary

• Runs thousands of sandboxes per host

• Shares most resources across sandboxes

The “9GB RAM” is a limit, not an allocation:

• The sandbox can use up to 9GB if needed

• Only pages actually touched consume real RAM

• Most sessions touch a tiny fraction

• The host only pays for what’s actually used

The “4.8GB filesystem” is shared:

• Read-only Ubuntu base image mounted for thousands of sandboxes

• Only per-sandbox writes go into small overlay layers

• Shared image cached on each node

• Most sessions never touch more than a subset

So when I initially modeled this as “VM-equivalent costs,” I was probably off by at least an order of magnitude.

The Scale Math (Revised Understanding)

Let me recalculate with a better understanding of the architecture.

Conservative user assumptions:

• 5M monthly active Claude.AI users

• Average 3 tabs per session

• 10 sessions monthly

• 2 hours average per session

What actually happens: Every tab load = gVisor sandbox allocation 5M × 3 tabs × 10 sessions = 150M sandbox allocations monthly

Where my initial cost model went wrong:

I used VM pricing (~$0.06/hour) as a proxy. That assumes:

• Dedicated compute resources per instance

• Full memory allocation on provision

• Traditional VM overhead

gVisor sandboxes are fundamentally different:

• High-density multiplexing (thousands per host)

• Memory allocated on-demand, not reserved

• Shared base images across all instances

• Aggressive overcommit strategies

Actual infrastructure costs are probably:

• 5-10x lower than VM-equivalent pricing

• Still significant at scale

• Driven by peak concurrent sandboxes, not total hours

• Dependent on idle timeout policies

Even at 10x better economics than I initially modeled, you’re still looking at substantial infrastructure investment requirements. Just not the “barely breaking even on Pro users” story I first calculated.

The Design Logic (Still Valid)

From a technical perspective, the logic holds:

The problem: You can’t predict when someone will create an artifact or run bash commands. Wait to provision? Add latency. Users notice.

The solution: Pre-allocate on page load. Sandbox’s already there. When they create an artifact—instant.

Trade-off: Pay for sandboxes whether users need them or not. Most sessions I’ve observed never use computer features. You’re still carrying that cost.

The difference: That cost is lower than I initially thought, but the architectural choice remains the same.

The Warm Pool (Now Makes More Sense)

That 1-minute uptime I keep seeing? Fresh from the pool.

How it likely works:

1. Anthropic maintains warm pool of pre-initialized sandboxes

2. Base Ubuntu image already mounted

3. Page load grabs one, adds overlay filesystem

4. Associates with your browser session

5. Returns to pool after timeout

Why there’s no provisioning latency:

• Pool already running

• Just binding + overlay setup

• Normal page load times

• Sandbox ready when needed

Why this is still expensive (but sustainable): With gVisor’s density, you can run thousands of sandboxes per host. But you still need:

• Enough hosts for peak concurrent sessions

• Warm pool sized for typical tab patterns

• Infrastructure to handle burst traffic

The absolute numbers are lower than VM math suggests. The architectural complexity and scale requirements remain.

The Unit Economics Question (Revised)

Look at this from Anthropic’s perspective with better cost assumptions.

If actual sandbox costs are 5-10x lower than VM pricing:

Pro user at $20/month:

• Opens 30 tabs across 10 sessions

• Each tab = 2 hours of sandbox time

• Container costs: $0.36-0.72 (not $3.60)

• Plus LLM inference: $8-12

• Total cost: $8.36-12.72

Margins look healthier. Still tight for power users.

Power users:

• 10+ tabs simultaneously

• All-day sessions

• Multiple daily sessions

Even at 10x better economics: 10 tabs × 8 hours × $0.006-0.012 = $0.48-0.96 per session

20 sessions monthly: $9.60-19.20 in container costs (vs. $96 in my initial model)

Free tier users: Still subsidized. Just not as dramatically.

Why This Still Explains August

The architecture helps explain behaviors I observed, even with revised cost understanding:

Scaling challenges:

• Demand surge

• Each user = multiple concurrent sandboxes

• Pool capacity constraints

• Coordination across hosts

Rate limiting context: Not just LLM tokens. Sandbox capacity matters. High-density multiplexing has limits.

Infrastructure investment rationale: Even with better-than-VM economics, owned infrastructure makes sense:

• Optimize for this specific workload

• Custom gVisor configurations

• Eliminate cloud provider margins

• Better control over density and overcommit

The $50B investment still makes strategic sense. The immediate economic pressure just isn’t as severe as I first calculated.

What Other Chat Interfaces Do

ChatGPT: Code interpreter runs in sandboxed Python (Docker containers). Documentation suggests persistent sessions tied to chat conversations rather than page loads, but OpenAI hasn’t published specific provisioning details.

Gemini: Similar Python sandbox approach. Code execution is an optional feature that can be enabled via API or CLI flags, suggesting on-demand provisioning, though Google hasn’t detailed the exact architecture.

Claude.AI: Full gVisor sandbox with Ubuntu environment. On page load. Whether you use it or not.

The capability difference remains significant. The cost differential is smaller than I initially thought, but the architectural complexity gap is real.

The Architecture Trade-Off (Still Stands)

Anthropic made a choice:

Option A: Provision on-demand

• Lower cost (only pay when used)

• Adds latency (users wait for provision)

• Simpler infrastructure

Option B: Pre-allocate on page load

• Higher cost (pay whether used or not)

• No latency (already there)

• More complex infrastructure

They picked B. The bet on experience over cost efficiency remains.

The actual cost premium is probably smaller than VM math suggests. The infrastructure complexity and engineering investment required is just as high.

What I Got Wrong (And Right)

What the testing showed accurately:

• gVisor sandboxes allocated on page load

• Separate isolation per tab

• Full Ubuntu environment available

• Zero-latency artifact/bash execution

What I initially misunderstood:

• Sandbox costs ≠ VM costs

• “9GB RAM” is a limit, not an allocation

• Filesystem is shared, not per-instance

• Density changes economics dramatically

What remains true:

• This architecture is more complex than competitors

• Pre-allocation strategy requires more infrastructure

• Most users never touch container features

• Scale drives need for vertical integration

The Revised Bottom Line

Based on repeated testing in my environment, every Claude.AI tab you open gets a gVisor sandbox with a full Ubuntu environment.

Not when you use computer features. On page load.

The economics (revised understanding):

• Still significant infrastructure investment

• Probably 5-10x better than my initial VM-based modeling

• Driven by peak concurrency and warm pool sizing

• Requires sophisticated resource management

This gives you capabilities no other chat interface provides. Complete isolation. Real development environment. Zero latency when you need it.

My initial cost estimates were probably wrong by an order of magnitude. The architectural sophistication and strategic investment requirements remain accurate.

My working theory: Anthropic prioritized capability and UX, betting on gVisor’s density to make the economics work while still requiring substantial infrastructure investment for vertical integration benefits.

The question isn’t whether the architecture is sustainable—it probably is. The question is whether the capability advantage justifies the infrastructure complexity.

Every time you load a Claude.AI page, you’re triggering a sandbox allocation. The cost is lower than I first calculated. The architectural commitment is just as high.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. For more infrastructure insights, read my analysis of multi-agent orchestration costs or my deep dive into AI development tool economics.

I spent $1.07 and 8 minutes fixing a bug today that would have cost me $376 to outsource. That’s based on hiring an offshore developer at typical $40/hour rates for work that would take roughly 9.4 hours based on the agent execution time.

But here’s the thing about personal projects: my consulting time commands good rates, but for my own website? I’m not billing anyone. The comparison that matters isn’t theoretical cost savings—it’s $376 in actual engineering costs versus $1.07 in AI costs, plus 8 minutes of my attention versus the coordination overhead of managing another engineer. (I know the numbers are small, but bear with me, they’re meant to be illustrative).

More importantly: this bug touched multiple system layers that would have traditionally required coordinating several specialists. RSS feed integration, data transformation, React rendering, deployment pipeline. I handled all of it solo using orchestrated AI agents.

Eight minutes to save $375 and tackle work requiring team coordination shows why we’re seeing heightened interest in agentic coding tools—though my experience represents a best-case scenario worth examining critically.

I tracked every token. I have the receipts. And the session logs reveal something more interesting than just impressive cost savings: they show exactly which scenarios deliver real value, and which don’t.

The Session: From Bug Report to Production

Here’s what actually happened. I noticed my personal website’s blog integration was broken. Posts weren’t loading correctly, the feed was throwing errors, and the whole thing needed fixing before it became a bigger problem.

Rather than hiring an engineer and managing the work, I used Claude-MPM to orchestrate four AI agents in a single browser tab:

Research Agent - Investigated the codebase, identified the broken blog feed integration, analyzed the data flow from Substack RSS to the site’s display logic.

Engineer Agent - Implemented the initial fix attempt, modified the feed fetching logic, updated the data transformation pipeline.

Web QA Agent - Ran Playwright tests against the staging deployment, verified the fix worked, validated all blog posts loaded correctly.

React Engineer - Handled the root cause analysis when the first fix proved incomplete, restructured the entire blog integration architecture, ensured production-ready quality.

My actual work? Writing the initial prompt, monitoring progress in a single tab while working on four other projects, and occasionally redirecting agents when they went down wrong paths. Eight minutes of attention across an hour of wall-clock time while the agents executed in parallel.

This is my normal workflow now: Claude-MPM managing agent coordination in one tab while I context-switch between five active projects. The orchestration framework handles the parallel execution and agent handoffs. I provide strategic direction and quality oversight.

The Economics: $1.07 Instead of $376 (Plus Coordination Overhead)

Let’s break down what this work actually cost, with transparent assumptions:

Token Consumption:

• Total tokens: 104,641 tokens (52.3% of Claude’s 200K context window)

• Input tokens: ~41,856 tokens (context, instructions, code)

• Output tokens: ~62,785 tokens (analysis, code generation, fixes)

Cost Breakdown at Claude Sonnet 4.5 rates:

• Input cost: $0.13 ($3 per million tokens)

• Output cost: $0.94 ($15 per million tokens)

• Total AI cost: $1.07

My Time Investment:

• Active oversight: 8 minutes of attention

• Wall-clock time: ~60 minutes while agents worked in parallel

• Personal project time: Not billable to anyone

Alternative: Hiring an Engineer:

• Offshore/nearshore developer at typical $40/hour rate (conservative market rate)

• Estimated work: 9.4 hours (extrapolated from agent execution time plus debugging/testing)

• Engineering cost: $376

• My coordination time: Minimum 1 hour for requirements, review, deployment

• Total traditional cost: $376 in hard costs plus coordination overhead

For personal projects where I can’t bill anyone, the relevant comparison is $376 in engineering costs versus $1.07 in AI costs. The dollar savings matter. But the time efficiency—eight engaged minutes for multi-system work—is what makes personal projects actually viable. This work would have stayed broken indefinitely because neither the cost nor the coordination overhead justified the fix.

Beyond Cost: Capability Expansion

The economics matter, but something else is happening: agentic tools expand what I can attempt without team support.

This blog integration issue touched multiple system layers—RSS feed parsing, data transformation, React component rendering, deployment pipeline. Five years ago, I would have needed multiple team members to handle this reliably: a backend engineer for the feed integration, a frontend specialist for the React components, a QA engineer to verify everything worked.

Now I orchestrate AI agents to handle all of it. This isn’t about replacing coding skill—I could write this code myself. It’s about managing complexity across multiple subsystems efficiently enough to be worth doing at all.

In practice, I’m now regularly tackling work that would have required team coordination:

• Building full-stack features solo that would have required 2-3 engineers

• Maintaining multiple production systems without dedicated devops support

• Implementing complex integrations that would have needed specialized expertise

• Deploying changes across distributed systems with confidence

I’ve seen similar patterns with other technical people, though the effectiveness varies by context:

• Senior engineers shipping entire features without team support (when scope is well-defined)

• Technical founders building production systems solo during early stages (though architectural complexity still requires expertise)

• Staff engineers prototyping architectural changes across multiple services (within their existing systems)

• Technical product managers implementing fixes without engineering allocation (for straightforward issues)

The bar for what technical people can attempt solo has shifted in some contexts—though complex projects still require specialized expertise and human oversight. Work that required team coordination and specialized roles can become feasible for individuals with good orchestration skills when the problem type fits.

What the Token Timeline Reveals

The session analytics show something interesting about how agentic work actually unfolds:

 50K ┤● Initial context (project files, instructions)
     │
 60K ┤  ●● Investigation phase (research agent)
     │
 70K ┤     ●● First implementation attempts
     │
 80K ┤       ● QA and deployment
     │
 90K ┤         ●●● Root cause deep dive (largest spike)
     │
100K ┤              ●● Cleanup & analytics
     │
105K ┤                  ● (current)
     └─────────────────────────────────────
     0   10   20   30   40   50   60 (minutes)

Nearly half the tokens (47.5%) went to initial context loading—establishing what the project was, how the code worked, and what needed fixing. Another 25% covered investigation and research. Only 15% went to actual implementation.

This distribution reveals the paradigm shift: I wasn’t coding. I was orchestrating intelligence to understand the problem, propose solutions, verify quality, and handle edge cases. The traditional developer workflow inverts when AI handles implementation while humans handle strategy.

The Orchestration Paradigm: From Hiring to Directing

Here’s what changed about how work gets done. Instead of four browser tabs managing agents manually, I use Claude-MPM to handle agent coordination in a single tab. My attention switches between five active projects while the framework manages parallel execution.

The work that happened (tabs here refer to iTerm2 tabs — my go-to terminal viewer).

Single Claude-MPM Tab:

• Research agent analyzing the codebase

• Engineer implementing fixes

• QA agent testing deployments

• React specialist handling complex restructuring

• All coordinated through the orchestration framework

Four Other Project Tabs:

• Client work continuing in parallel

• No context switching penalty

• Framework handles agent handoffs and progress tracking

My job shifted from implementation to strategic direction:

• Initial prompt: “Blog feed is broken, investigate Substack RSS integration”

• Occasional redirects: “The initial fix didn’t address root cause—investigate data transformation layer”

• Quality checkpoints: “Verify all historical posts load, not just recent ones”

• Final verification: “Document architectural decisions”

Traditional software development requires your full attention during execution. You write code, debug issues, test thoroughly, deploy carefully. Each step demands focus.

Orchestrated development enables parallel execution across multiple projects. The framework manages agents while you provide strategic oversight. Quality emerges from good specifications and periodic verification, not constant supervision.

This approach works particularly well for personal projects where coordination overhead would kill the project entirely. My website bug wasn’t worth hiring an engineer—the coordination time would have cost more than the fix was worth. Claude-MPM made it viable by requiring only eight minutes of my attention.

What made this work so efficiently: eliminated hiring overhead entirely, agents executed in parallel while I context-switched to other projects, and eight minutes of total attention across an hour of wall-clock time.

When the Numbers Don’t Work: The Long Tail Problem

Here’s what I need to be honest about: this session represents a best-case scenario across both dimensions—cost savings and capability expansion. The value doesn’t materialize consistently.

The Economics Long Tail:

Success cases like this bug fix sit at one end of a distribution. At the other end are situations where AI assistance provides marginal value, no value, or negative value:

Marginal gains (2-5x cost reduction, limited capability expansion):

• Work requiring significant oversight (coordination overhead remains)

• Complex debugging demanding you’d hire senior engineers anyway

• Projects where verification time approaches implementation time

• Multi-system work where AI lacks critical domain context

No gains (1x or worse):

• Work requiring deep expertise that AI fundamentally lacks

• Legacy systems with undocumented architectural decisions

• Security-critical code where verification exceeds any AI savings

• Projects where coordination overhead was never the limiting factor

• Genuinely novel problem spaces with no relevant training data

Negative value:

• Fixing AI-generated bugs costs more than hiring correctly

• AI confidently provides wrong solutions requiring extensive debugging

• Management overhead increases rather than decreases

• AI suggestions waste more engineering time than they save

• Multi-system changes introduce subtle integration failures

The distribution matters more than the peak. My bug fix achieved major cost savings ($376 vs $1.07) and demonstrated capability expansion (solo work spanning multiple systems). But across client work over the past three months, the aggregate value is more modest—typically 2-3x gains from acceleration rather than transformation.

What determines where you land on this curve?

High-value scenarios (cost + capability):

• Small projects where coordination overhead dominates

• Personal work not worth hiring for at any price

• Multi-system fixes with clear success criteria

• Modern tech stacks matching AI training data

• Straightforward verification and testing

Moderate-value scenarios (primarily acceleration):

• Work within managed teams requiring oversight anyway

• Complex problems needing senior judgment but benefiting from AI assistance

• Projects where you’re coordinating engineers regardless

• Incremental features in well-understood systems

Low-value scenarios:

• Legacy systems requiring extensive human context

• Novel problem spaces with no training data

• Security or performance-critical code demanding extensive review

• Work where AI suggestions require more debugging than starting fresh

• Political or organizational constraints on implementation approach

The heightened investor interest makes sense for the high-value category—massive volume of small projects plus capability expansion for individual contributors. Market skepticism makes sense for larger managed work where you’re hiring teams regardless.

The Token Efficiency Story

Something interesting emerged from analyzing the session: token efficiency mattered more than raw capability.

Initial context loading consumed nearly 50,000 tokens—establishing project structure, reading configuration files, understanding the codebase. This overhead was identical whether I was fixing a trivial bug or implementing a complex feature.

For small tasks, that overhead dominates. A 5-line change doesn’t justify 50,000 tokens of context establishment. The productivity multiplier approaches 1x or worse.

For complex tasks spanning multiple files and subsystems, the overhead amortizes. My 8.1x multiplier came from a bug fix that required:

• Analyzing 8 different files

• Understanding data flow across 3 system layers

• Implementing changes in 4 locations

• Verifying behavior across multiple post types

• Documenting architectural decisions

The same initial context cost, but much higher value from the work performed.

Token efficiency insights:

• Single-session work: No context restarts saved ~50,000 tokens

• Targeted analysis: Research agent methodology minimized exploratory waste

• Parallel processing: Multiple files analyzed simultaneously without token duplication

• Smart caching: Repeated file access handled efficiently

The session used 52.3% of the available 200,000-token context window. Efficient enough to complete the work in one session, but not wasteful. A goldilocks utilization rate.

Why Investors Are Interested (And Where Skepticism Is Warranted)

The funding activity around AI coding tools—Augment’s $227M (enterprise-focused coding assistant), Magic’s $320M (autonomous coding agents), Codeium’s $150M (AI code acceleration platform)—reflects recognition of two distinct value propositions: cost savings on small projects and capability expansion for individual technical contributors.

Where the investment thesis makes sense:

The addressable market appears substantial across two dimensions:

1. Cost savings market: Small projects, personal sites, maintenance tasks—all the work below the “worth hiring for” threshold—suddenly become economically viable. Millions of these decisions happen daily.

2. Capability expansion market: Technical people at various levels handling multi-system work solo that traditionally required team coordination. Senior engineers, staff engineers, technical founders, technical PMs—all expanding what they can accomplish independently within certain contexts.

Both markets show real, measurable value when conditions align. Token costs decline while capabilities improve. The technology enables both cost arbitrage and skill amplification simultaneously.

Where caution is warranted:

Neither value proposition scales uniformly to all software work. Personal project economics don’t apply when you’d hire and manage teams regardless. Capability expansion has limits—complex projects still require specialized expertise and human oversight. Context windows constrain problem scope. Verification overhead grows with project complexity.

The peak performance cases—like my $376 saved, 8-minute fix spanning multiple system layers—aren’t representative of median experience. Legacy systems, ambiguous requirements, and genuinely novel problems still resist automation.

My website bug represents the sweet spot: clear problem, modern stack, straightforward solution, multi-layer complexity. It demonstrates both cost savings (work that wouldn’t happen) and capability expansion (work that would have required team support).

Companies that can deliver consistent value across both use cases without overpromising tend to build sustainable businesses. Companies that only optimize for one scenario or suggest they can replace entire engineering organizations risk underdelivering on expectations.

What This Means for Practitioners

The session analytics reveal a practical framework for when to employ agentic coding tools across two distinct value dimensions:

Cost savings scenarios (personal projects, small fixes):

• Projects too small to justify hiring (personal sites, side projects, maintenance)

• Coordination overhead would exceed implementation value

• Clear specifications and straightforward verification

• Multiple independent tasks can run in parallel

• Modern tech stacks with good AI training coverage

Capability expansion scenarios (individual technical work):

• Multi-system work traditionally requiring team coordination

• Full-stack features spanning frontend, backend, and infrastructure

• Complex integrations across distributed systems

• Prototyping architectural changes before team involvement

• Maintenance across multiple production systems

Both scenarios benefit from:

• Good orchestration frameworks (like Claude-MPM)

• Clear problem specifications

• Ability to verify results independently

• Iterative refinement workflows

Deploy tactically when:

• Accelerating work within managed teams (2-3x gains typical)

• Augmenting rather than replacing hiring decisions

• Clear subtasks within larger projects requiring human judgment

• Prototyping before committing team resources

Avoid or minimize when:

• Project complexity demands senior engineering judgment regardless

• Legacy systems requiring extensive human context

• Security or performance criticality mandates extensive review

• Verification overhead approaches or exceeds implementation savings

The key questions aren’t just “Can AI do this work?” but rather:

1. Cost dimension: Would I have hired someone, or would coordination overhead kill the project?

2. Capability dimension: Does this require coordination across specialists I don’t have access to?

If either answer is yes—small projects, personal work, or multi-system complexity requiring team coordination—the value can be compelling. If you’d hire and manage a focused team anyway, the gains are more modest but still meaningful.

The Honest Bottom Line

My $1.07 bug fix demonstrates two valuable aspects of agentic coding tools: $376 saved in engineering costs (based on $40/hour offshore rates for 9.4 hours of work) and expanded capability to handle multi-layer system work solo that would have required team support.

The first value—cost savings on small projects—applies specifically to work that falls below the “worth hiring for” threshold. The second value—capability expansion—applies in certain contexts across technical roles attempting work that would have traditionally required coordination across specialized team members.

The recent funding activity makes sense when you consider both markets: the massive volume of small projects that become viable, and the expanded capability bar for what technical people can attempt independently in favorable conditions. Market skepticism makes sense when you focus on complex work requiring team oversight regardless of tooling.

Understanding which scenario you’re in determines what value you’ll see:

Personal projects and small fixes: Cost savings ($376 vs $1.07) and time efficiency (8 minutes vs coordination overhead) make previously unviable work viable.

Capability expansion: Technical people at various levels—senior engineers, staff engineers, technical founders, technical PMs—attempting full-stack or multi-system work that would have required team coordination, when the scope and context align.

Larger managed projects: More modest 2-3x acceleration where you’re managing teams anyway.

For my website bug fix? Both values delivered—work got done that otherwise would have stayed broken, and I handled complexity that would have required multiple specialists. For larger client work? The primary value comes from acceleration rather than enablement.

Both scenarios represent real value. Both are happening across the industry. The difference is knowing which applies to your situation and what you’re actually optimizing for.

I’m Bob Matsuoka, writing about agentic coding and AI-powered development at HyperDev. The orchestration framework used in this article is Claude-MPM, my open-source multi-agent project management system. For more on orchestration strategies, read my analysis of multi-agent coordination patterns or my comparison of orchestration frameworks.

MCP Vector Search helps if you’re using Claude Code. It does semantic embeddings of text and AST embeddings of many types of code.

Which as it turns out is also an interesting way to build visualizations of your code base. Check it out!

pipx install mcp-vector-search

Claude.AI rolled out a significant but undocumented improvement to its editor system around October 23-24, 2025, delivering 3-4x faster artifact updates through inline text replacement instead of full code regeneration. Multiple users independently discovered this enhancement during the same timeframe, coinciding with the improved Claude 3.5 Sonnet release, though Anthropic has provided no official announcement or documentation about the feature.

What actually changed and when it happened

The most impactful improvement—discovered by users rather than announced—transforms how Claude updates artifacts. Previously, any modification required regenerating the entire code base, even for single-line changes. Now Claude intelligently chooses between targeted inline edits for small changes and full rewrites only when necessary. Developer Rui Quintino, who documented his discovery in a detailed Medium article, observed: “What used to need a complete rebuild now happens almost instantly. In this simple change, a 3-4x reduction in waiting time.”

The timing aligns precisely with the Claude 4.5 Sonnet refresh released October 23-24, 2025. Multiple Reddit threads appeared simultaneously in r/ClaudeAI with titles like “Claude Diff Editor! Part of upgrade to Artifacts” and “Claude is now editing my artifacts (new feature?).” Users testing the system with browser developer tools revealed new network patterns showing distinct commands for “create,” “update,” and “rewrite” operations.

The update mechanism uses precise string matching for targeted changes—each update must match exactly once in the artifact, with whitespace and formatting mattering for accuracy. The system works across all artifact types: React components, Markdown documents, SVG graphics, Mermaid diagrams, and HTML pages. Users report seeing live preview changes as each update applies, dramatically improving process visibility.

Official announcements that did happen

While the inline editing improvement went undocumented, Anthropic made several official editor-related announcements during late September through October 2025:

Claude Code VS Code Extension (September 29, 2025) introduced native IDE integration with inline diff displays, real-time change visibility through a dedicated sidebar panel, and checkpoint functionality that automatically saves code state before each change. The extension provides automatic context sharing—knowing which files are open, what code is highlighted, and seeing diagnostics from linters and language servers. Users can rewind to previous versions by tapping Escape twice or using the /rewind command.

File creation capabilities (October 21, 2025) expanded Claude’s reach beyond text-based outputs, enabling creation and editing of Excel spreadsheets, Word documents, PowerPoint presentations, and PDFs directly in Claude.ai. Files are actual downloadable documents, not just artifacts, with direct Google Drive saving. The feature operates through a private sandboxed environment where Claude writes and executes code, though users receive warnings that internet access “may put your data at risk.”

Agent Skills (October 16, 2025) introduced lightweight instruction sets for consistent task performance, with pre-built skills for PowerPoint, Excel, Word, and PDF files. The Analysis tool received enhancements supporting targeted edits within artifacts, advanced mathematical operations through math.js, and high-precision calculations.

How users discovered and tested the improvements

The discovery process reveals a fascinating pattern of collective user investigation. Rui Quintino noticed changes while building a Halloween game: “Changes were happening much faster than usual. After testing on both mobile and desktop, the improvement was clear: several artifact updates were being edited inline, instead of forcing full regeneration of the full code.”

He investigated using browser network traffic analysis, revealing intelligent routing decisions between update types. Testing showed live preview changes visible in real-time as updates applied, with dramatically reduced computational waste and token usage. He wrote: “Lower computational resources and token usage. More artifacts and Claude usage possible within the same message limits.”

Multiple power users contributed additional observations. Simon Willison, a veteran AI researcher, documented building numerous interactive applications in single sessions—YAML to JSON converters, pricing calculators, recording tools, and text editors—all benefiting from the faster iteration cycles. Developer teams at companies like Builder.io and Puzzmo reported similar experiences with improved reliability and speed.

Problems the updates addressed

The improvements directly tackle four major pain points users experienced with the previous artifact system:

Full code regeneration waste: Every edit previously required regenerating entire code bases, consuming excessive tokens and time even for single-character changes. The inline replacement mechanism now handles targeted updates for small modifications while reserving full rewrites for substantial restructuring.

Imprecise editing workflows: Users previously had to describe changes in chat or copy-paste code sections, prone to misunderstanding. The highlight-and-edit feature introduced earlier (enhanced in October) allows precise selection and modification of specific code sections, with “Improve” and “Explain” options for targeted changes.

Slow update cycles: The 3-4x speed improvement eliminates waiting time for minor tweaks, enabling “changes that feel more natural, like working with a code editor” with “less context switching between chat and preview.”

Poor process visibility: Users couldn’t see what Claude was actually changing during updates. The new system shows multiple update commands in sequence, with live preview changes visible as they apply, providing transparency previously absent from the editing process.

Community response and developer adoption

Sentiment across Reddit, Twitter, Medium, and developer forums is overwhelmingly positive, tempered by frustration about lack of official documentation. The r/ClaudeAI community actively discusses the improvements, with users sharing testing results and technical observations. Multiple sources reference discovering the feature through peer reports rather than official channels.

Developer teams report substantial workflow improvements. A Builder.io developer stated: “I’ve gone deep down the rabbit hole on every Cursor power feature... And I’ve abandoned it all for Claude Code.” The team notes Claude Code successfully handles 18,000-line React components where competing tools struggle, with exceptional codebase navigation and pattern recognition capabilities.

The Puzzmo engineering team, after six weeks with Claude Code, reported “constantly trashing usual estimation timings” and noted the tool freed developers from “anxiety of the first step in programming.” They use Claude Code with monorepos and GitHub Actions, having it respond to PR comments and fix CI errors automatically.

However, persistent issues remain. Usage limits continue as the #1 complaint even for paid users, with Pro subscribers reporting “Opus blocked” messages mid-project. Platform stability issues emerge during peak hours, and feature rollout remains inconsistent—some older chat sessions lack the fast update mechanism entirely.

What users are still requesting

The community maintains clear priorities for future improvements:

Official documentation tops the list, with repeated requests for Anthropic to explain the inline editing mechanism, provide technical implementation details, and guarantee feature stability. As Rui Quintino wrote: “Anthropic, can we please know a bit more?☺”

Project-based organization would reduce artifact clutter, with users wanting better version control and cleanup of intermediate artifacts. Enhanced usage limits remain critical, as current limits feel “set too low even for paid customers” according to multiple Trustpilot reviews from October 2025.

External integrations face limitations—no FTP access, no SSH to servers, cannot browse file systems directly. Users request persistent storage with database support for artifacts and expanded Model Context Protocol (MCP) integration. Collaborative features including real-time collaboration on artifacts and team-based artifact libraries remain on wish lists.

Technical improvements requested include better edge case handling for the inline editing system (occasional issues with multiple string matches), mobile artifact editing with full capabilities on mobile apps, and manual edit preservation in diff viewers—a long-standing issue where user modifications get discarded when accepting Claude’s proposed changes.

Technical implementation and remaining gaps

Browser network analysis reveals Claude now makes intelligent choices between update types based on change scope. The system uses three distinct operation modes: “create” for new artifacts, “update” for targeted string replacement with precise matching requirements, and “rewrite” for substantial changes requiring full regeneration.

The mechanism works best with well-structured code, benefiting from const declarations and single-source-of-truth patterns. It effectively handles button color changes, text updates, and single-line modifications across all artifact types. Complex refactoring still triggers full rewrites, and ambiguous string matching can cause errors.

Critical bugs remain unresolved. GitHub Issue #1317 (opened May 2025, still open in October) documents how the model is unaware of manual editing in diff viewers—when users manually edit Claude’s proposed changes before accepting, Claude doesn’t recognize the edits and discards user changes. Developers must choose “No, and tell Claude what to do differently” and describe manual changes verbally, a significant workflow disruption.

GitHub Issue #9668 (October 16, 2025) reveals conversation history loading problems. Multiple distinct conversations display “Warmup” as the title because the UI uses the first user message as the conversation title, and many users type “Warmup” to initialize sessions. One user reported three conversations from the same day—totaling 250KB, 128KB, and 295KB with 69, 87, and 210 messages respectively—all displayed identically as “Warmup,” making previous work effectively inaccessible.

Comparison to Claude Code and competing tools

The improvements narrow the gap between web-based Claude.ai artifacts and the more powerful Claude Code terminal/IDE integration. Claude Code offers native diff panels in VS Code, file system integration, and version control readiness, making it superior for complex multi-file projects. The web interface now provides faster iteration for prototyping and better visual feedback for non-technical users.

Developer comparisons favor Claude’s vertical integration advantage—Anthropic controlling both model and tooling enables better optimization. Builder.io’s developer noted Claude Code rarely gets stuck and excels at navigating large codebases, contrasting with Cursor’s struggles updating extremely large files. Terminal-Bench benchmarks show 60% overall accuracy, dropping to 16% on complex tasks, but real-world usage reports suggest higher practical success rates.

OpenAI’s Canvas provides similar editing tools but lacks Claude’s emphasis on creating shareable, interactive applications. Canvas allows manual editing of content while Claude Artifacts remain view-only (only Claude can edit), though Claude now provides artifact preview for HTML/SVG that Canvas doesn’t offer. The community remains split on which approach better serves different use cases.

Conclusion: A maturation moment with documentation debt

The October 2025 updates represent substantial technical maturation rather than experimental features. The inline editing improvement alone transforms artifact workflows, enabling rapid iteration that was previously impossible. Combined with file creation capabilities, enhanced analysis tools, and the Agent Skills framework, Claude.ai has evolved from a conversational interface into a collaborative development environment.

Yet the silence around the most impactful improvement—inline artifact editing—creates unnecessary confusion. Users shouldn’t need to reverse-engineer features through browser developer tools and community investigation. As one developer forum noted: “October’s releases represent maturation rather than experimentation. These tools are production-ready for specific use cases.”

The core question has shifted from “Can AI help with code?” to “Which AI tool solves which specific bottleneck?” For rapid prototyping, interactive applications, and visual content, Claude’s artifacts now offer compelling speed and ease of use. For complex multi-file projects and enterprise development, Claude Code’s IDE integration provides the necessary depth. Both have reached production readiness, but persistent issues with usage limits, conversation history management, and documentation gaps prevent them from reaching their full potential.

The improvements are real, significant, and genuinely useful. They just happened quietly, leaving users to discover them by accident—an odd approach for features that meaningfully enhance the product.

I run four AI coding tools simultaneously. Sounds excessive until you see the strategy in action. Augment Code’s Augie CLI and Claude Code aren’t rivals in my workflow – they’re complementary partners. Augment did something subtle but brilliant: they made interoperability a first-class feature.

The Integration Play

Augment Code adopted two key things that make “platooning” multiple AI agents seamless:

• Claude Code’s /commands model. Augment’s terminal tool (Auggie) implements the same slash‑command interface as Claude Code. In fact, Auggie automatically detects and supports commands defined in Claude’s ./.claude/commands/ directory for full compatibility. Every workflow I built in Claude – /mpm, /mpm-agents, /mpm-doctor – runs identically in Auggie.

• Model Context Protocol (MCP). Augment supports MCP natively, meaning external context engines, memory systems, and tools can be shared between Claude and Augment with zero changes. MCP is the open protocol unifying AI assistants with external data and tools.

Because Augment adopted Claude’s command schema and MCP, switching between the two costs you nothing—your workflows just carry over.

Why This Matters

I built months of custom workflows in Claude Code. When I switch to Auggie, those workflows just work. No translation, no re-learning. Augment’s context engine is particularly strong—it indexes codebases like a search engine, rather than pushing raw tokens. Users have observed that Augment can process and retrieve context from hundreds of thousands of files more efficiently than Claude’s prompt window.

[REMOVED MOLISHA SHAH QUOTE - couldn’t verify]

Augment supports the Model Context Protocol (MCP) standard, and third-party developers have created MCP servers like auggie-context-mcp that enable Claude and other tools to access Augment’s context engine, creating practical interoperability across the ecosystem.

When to Use What

Use Case Tool Why Complex refactoring, cross-cutting architectural changes Claude Code + Claude‑MPM Multi-agent orchestration, long-horizon reasoning, full codebase coordination. Quick bug fixes, debugging, documentation, operations Augment’s Auggie CLI Single-agent focus, near-instant responses, efficient token usage.

Power users often platoon them—do architectural planning in Claude, rapid iteration and patching in Auggie.

The Conservative Token Play

Augment’s design avoids “context dumping.” Because it indexes projects and retrieves selectively, its prompts stay lean. Augment’s pricing page emphasizes efficiency: users pay for meaningful interactions, not wasted tokens.

In production use, Augment’s retrieval-first design shows approximately 3× faster response times compared to large-context tools—averaging 4.1 seconds per response versus 12-15 seconds for competitors using million-token context windows. This architecture allows rapid, iterative work without ballooning API costs.

What They’ll Probably Do Next

Augment already offers multi-agent support via Remote Agents in its IDE extensions. Their roadmap appears centered on orchestrating teams of agents through standard protocols rather than proprietary lock-in.

This aligns with the broader industry movement toward agent interoperability standards, much like Language Server Protocol did for IDEs. Augment’s track record with MCP support suggests they’ll continue embracing open standards.

The Broader Implication

The AI coding market is consolidating around shared standards:

• Slash commands as a universal interface (Claude’s model, extended by Augment)

• Model Context Protocol for tool/data interconnectivity

• Agent orchestration protocols for multi-tool collaboration

Tools embracing these standards gain instant workflow compatibility; those resisting create friction and force users into binary ecosystems. Augment’s strategy embraces openness, enabling seamless use alongside Claude.

Bottom Line

Augment Code’s integration strategy is a model of pragmatic interoperability: acknowledge where the ecosystem is heading, align with the standards, and differentiate through execution. For users like me, that means I can use Claude‑MPM for orchestration and Augment Auggie for focused execution—no vendor lock‑in, no translation overhead.

In a market obsessed with proprietary control, Augment’s commitment to playing well with others is the smartest move of all.

By Bob Matsuoka, writing about agentic coding and AI‑powered development at HyperDev.

I spent twenty minutes yesterday watching Claude Code correct itself about what Claude Code actually is. Then correct itself again. Then get it wrong a third time.

Here’s what happened: I was setting up MCP browser tools and Claude Code kept insisting it had “added mcp-browser to Claude Code’s config at ~/Library/Application Support/Claude/claude_desktop_config.json.”

That’s not Claude Code’s config. That’s Claude.ai Desktop’s config.

When I pointed this out—”that is not the Claude Code config! That is the Claude.AI Desktop config!”—it apologized profusely and tried to find the right location. But the damage reveals something deeper than a simple naming mixup.

Claude Code doesn’t understand what Claude Code is.

The Identity Crisis

This isn’t user error or a documentation problem. I’ve got system instructions that explicitly explain the difference between:

• Claude Code: The coding assistant/IDE application

• Claude.ai Desktop: The chat application from Anthropic

Despite these instructions, Claude Code routinely confuses itself with other Anthropic products. It’ll reference the wrong config files, suggest the wrong installation paths, and generally behave like it’s having an identity crisis.

The pattern shows up constantly. Claude Code will acknowledge it’s wrong, correct itself, then make the same mistake three responses later. It’s like watching someone with short-term memory issues try to remember their own name.

Why Static Memory Fails Fast-Moving Markets

This confusion points to a fundamental limitation in current AI architectures. These systems rely on static training data and baked-in instructions that become obsolete quickly in fast-moving markets.

Anthropic has multiple products with similar names and overlapping functionality. The training data probably contains references to “Claude Desktop” from different time periods when the product lineup looked different. Add in user documentation, forum discussions, and third-party tutorials that use inconsistent naming, and you get...chaos.

The AI gets conflicting signals about what it actually is.

Static memory models can’t adapt when:

• Product names change or evolve

• New versions launch with different capabilities

• Configuration patterns shift between releases

• Multiple similar products coexist

The Broader Problem

This isn’t just annoying—it’s symptomatic of how current AI systems handle rapidly changing information. When your coding assistant doesn’t know its own configuration system, how can users trust it for complex technical decisions?

The confusion cascades. Wrong configuration advice leads to broken setups. Users waste time following incorrect instructions. Trust erodes because the tool seems unreliable on basic facts about itself.

I’ve seen this pattern across multiple AI coding tools. They’ll confidently provide outdated installation instructions, reference deprecated APIs, or suggest workflows that don’t match current product capabilities.

What This Means for Users

Right now, you need to verify everything. Even when an AI tool gives you instructions about itself, double-check against current documentation.

This is particularly problematic for:

• Configuration and setup tasks where wrong paths break everything

• Version-specific features that may not exist in your installation

• Integration workflows that depend on accurate product understanding

The workaround? Treat AI coding assistants as unreliable narrators about their own capabilities. They’re great at generating code, terrible at knowing what they can actually do.

Moving Beyond Static Memory

The solution isn’t more detailed instructions—it’s fundamentally different memory architectures. Static prompts and training data can’t keep pace with software development cycles.

What we need are dynamic memory systems that can:

• Update product knowledge in real-time

• Verify information against current documentation

• Distinguish between different versions and configurations

• Learn from user corrections without losing context

I’m working on approaches to this problem, which I’ll detail in a future post. But the core insight is clear: current memory models are incompatible with fast-moving technical domains.

The Meta-Problem

Here’s what really gets me: we’re using AI tools to build software, and those tools don’t understand basic facts about themselves. How can they make architectural decisions about systems they can’t even identify correctly?

This identity confusion reflects deeper issues with how AI systems maintain and update knowledge. If Claude Code can’t keep track of what Claude Code is, what other fundamental misconceptions are lurking in its responses?

The irony is thick. We’re debugging AI tools that can’t debug their own identity.

Bottom Line

Claude Code remains useful for actual coding tasks. But don’t trust it for meta-information about Anthropic’s product lineup, configuration systems, or its own capabilities.

Verify everything. Check official documentation. And remember that your coding assistant might be as confused about what it is as you are about what it can actually do.

The tools work best when you stop expecting them to be self-aware.

Next week: The dynamic memory architectures that could actually solve this problem

TL;DR: Key Highlights

Thanks to Alex May and Jean Barmash for suggesting we add these quick-hit summaries to help busy developers get the core insights fast.

• The judgment gap is real: Experienced engineers solve problems through targeted analysis; AI uses probabilistic shotgun approaches that often work but miss root causes

• Speed vs effectiveness paradox: METR study shows experienced developers are 19% slower with AI tools despite feeling 20% faster—we're deceiving ourselves about current AI effectiveness

• Case study reality check: When debugging WordPress performance issues, Claude applied 7 optimizations achieving 98% improvement; human engineer Oswaldo made 3 targeted changes that fixed the actual bug

• AI excels in constrained spaces: Pattern-based tasks like test generation, boilerplate code, and API clients see 70% time savings; complex debugging and architecture decisions still require human judgment

• Economic implications: Teams need fewer junior developers but more senior architects; AI amplifies junior productivity while sometimes hindering expert-level work

• Practical workflow: Human defines architecture → AI implements → Human reviews → AI generates tests → Human validates. Checkpoints beat full autonomy

• Bottom line: AI is powerful pattern matching without judgment. Use it for mechanical coding tasks, reserve human expertise for decisions that actually matter

An experienced engineer will almost always write code better than AI in its current state. This isn't my pessimism about AI's future or a rejection of the new tools. It's a practical observation from the trenches, one that becomes crystal clear when you watch how differently humans and AI approach the same problem.

Let me share a cautionary tale that perfectly illustrates where we are with agentic coding in 2025. When code that pulled content from a WordPress blog was experiencing performance issues, two approaches emerged: Claude, representing state-of-the-art AI, and Oswaldo, an experienced engineer. The way each tackled the problem reveals fundamental truths about the current state of AI coding that every developer needs to understand.

A tale of two debugging approaches

The problem seemed straightforward enough: code fetching content from a WordPress site was running slowly. Claude, the AI agent, approached it probabilistically, generating hypothesis after hypothesis based on pattern matching from its training data. It suggested optimizing API calls, implementing aggressive caching, checking for network timeouts, examining data fetching patterns—essentially throwing a comprehensive troubleshooting checklist at the content fetching problem. Each suggestion was reasonable, drawn from the vast corpus of performance optimization issues it had seen before.

Claude's AI approach: Optimize everything

Here's how Claude tackled the problem:

// Claude's probabilistic optimization approach
function Posts() {
  // Hypothesis 1: Parallel fetching will solve waterfall loading
  const [featuredCategoryId, setFeaturedCategoryId] = useState(-1); // Start optimistically
  
  // Hypothesis 2: Aggressive caching prevents redundant requests
  const SWR_CONFIG = {
    revalidateOnFocus: false,
    revalidateOnReconnect: false,
    dedupingInterval: 60000, // 60-second cache
  };
  
  // Hypothesis 3: Fetch everything in parallel
  const { data: categories } = useSWR(categoriesUrl, fetcher, SWR_CONFIG);
  const { data: posts } = useSWR(
    `${postsUrl}?categories_exclude=${featuredCategoryId}`,
    fetcher,
    SWR_CONFIG
  );
  
  // Hypothesis 4: Memoize expensive operations
  const parsedTitle = useMemo(() => parseHtml(title, {}), [title]);
  const formattedDate = useMemo(() => formatDateString(date), [date]);
  
  // Hypothesis 5: Prefetch for faster navigation
  return <Link href={`/posts/${slug}`} prefetch={true}>
}

// Result: 7.2s → 133ms (98% improvement)
// But: Didn't fix the root cause

Claude's solution was comprehensive, addressing multiple potential bottlenecks simultaneously. It applied every optimization pattern in its training data, achieving dramatic performance improvements through brute force.

Oswaldo's human approach: Find the root cause

Oswaldo took a different path entirely. Instead of following a probabilistic decision tree, he used judgment. He noticed something subtle in the symptoms that pointed to a specific bottleneck in the data fetching logic. Where Claude saw a universe of equally probable causes, Oswaldo's experience let him recognize a familiar pattern and zero in on the actual issue.

// Oswaldo's targeted fix approach
function Posts() {
  // Root cause analysis: SWR hanging on malformed requests
  
  // Replace problematic SWR with direct control
  const [categories, setCategories] = useState(null);
  const [categoriesIsLoading, setCategoriesIsLoading] = useState(true);
  
  useEffect(() => {
    const fetchCategories = async () => {
      try {
        setCategoriesIsLoading(true);
        const response = await fetch(
          `${process.env.NEXT_PUBLIC_BLOG_URL}/wp-json/wp/v2/categories`
        );
        if (!response.ok) {
          throw new Error(`HTTP ${response.status}`);
        }
        const data = await response.json();
        setCategories(data);
        
        // Set featured category ID after successful fetch
        const featuredCategory = data.find(category => category.slug === "featured");
        if (featuredCategory) {
          setFeaturedCategoryId(featuredCategory.id);
        }
      } catch (error) {
        console.error("Failed to fetch categories:", error);
        setCategories(null);
      } finally {
        setCategoriesIsLoading(false);
      }
    };
    
    fetchCategories();
  }, []); // Fresh data on mount, no caching to hide issues
  
  // Keep SWR for posts but with correct parameters
  const { data: posts } = useSWR(
    featuredCategoryId 
      ? `${url}?categories_exclude=${featuredCategoryId}`
      : null, // Only fetch when featuredCategoryId is ready
    fetcher,
    { 
      revalidateOnFocus: false,
      dedupingInterval: 0, // No aggressive caching hiding bugs
    }
  );
}

// Result: Fixed 5-minute hang, immediate new post visibility
// Method: Identified and fixed the actual bug

The result? Oswaldo solved the problem with a handful of precise changes. Claude would have eventually gotten there too, but probably after writing twice as much code and exploring multiple dead ends.

This isn't a story about AI failure—it's about understanding what judgment means in engineering and why it matters.

Judgment operates where probability struggles

Recent research from cognitive science reveals something fascinating about how expert programmers think. The RIKEN Brain Science Institute found that experienced developers literally develop specialized neural circuits in the caudate nucleus, creating what amounts to "special-purpose hardware" for rapid, unconscious pattern recognition. When Oswaldo looked at that content fetching issue, his brain wasn't calculating probabilities—it was firing specialized neurons that had been shaped by years of similar problems.

This biological reality explains why the METR study's findings shouldn't surprise us. When experienced open-source developers used frontier AI tools (Cursor Pro with Claude 3.5 Sonnet) on mature codebases, they were 19% slower than working without AI assistance. Even more telling: developers thought they were 20% faster despite the measured slowdown. We're so enamored with the promise of AI that we're literally deceiving ourselves about its current effectiveness.

The difference comes down to mental models versus pattern matching. As Sean Goedecke notes, what distinguishes excellent programmers is "the accuracy and sophistication of the programmer's mental model." Humans maintain three distinct types of mental models when coding: framework models (how Rails works), code models (how this specific function executes), and domain models (what the business actually needs). AI has none of these—just statistical correlations between text patterns.

Debugging approaches compared

// AI Debugging Pattern: Shotgun approach
function debugPerformance() {
  const optimizations = [
    () => implementParallelFetching(),
    () => addAggressiveCaching(),
    () => memoizeExpensiveOperations(),
    () => addPrefetching(),
    () => optimizeNetworkRequests(),
    () => implementLoadingStates(),
    () => addErrorBoundaries(),
  ];
  
  // Apply all optimizations simultaneously
  optimizations.forEach(opt => opt());
  
  // Result: Better metrics, but root cause still exists
}

// Human Debugging Pattern: Surgical approach  
function debugPerformance() {
  // 1. Observe symptoms
  console.log("Network tab shows 5-minute hanging requests");
  
  // 2. Form hypothesis based on experience
  // "SWR configuration issues cause this pattern"
  
  // 3. Test hypothesis directly
  const suspiciousCall = useSWR(url, fetcher, config);
  
  // 4. Isolate and fix root cause
  if (config.missing || params.malformed) {
    return fixSWRConfiguration();
  }
  
  // Result: Problem solved at the source
}

Where AI coding agents actually deliver value

Before you think I'm advocating abandoning AI tools, let me be clear: AI coding assistants have transformed specific aspects of development, and denying their value would be equally misguided. The key is understanding where probabilistic approaches excel and where judgment remains irreplaceable.

AI dominates in well-defined, constrained spaces. When Diffblue used AI to generate 4,750+ tests, they saved 132 developer days. Why? Because unit test generation from specifications is largely pattern matching—exactly what AI does best. Similarly, GitHub Copilot users report 70% time savings on boilerplate code, API client generation from OpenAPI specs, and documentation. These are tasks where "good enough" based on common patterns is actually good enough.

// Where AI excels: Pattern-based code generation
function generateTestSuite(apiSpec) {
  // AI can reliably generate this from patterns:
  
  describe('User API', () => {
    it('should create user with valid data', async () => {
      const userData = { name: 'John', email: 'john@example.com' };
      const response = await createUser(userData);
      expect(response.status).toBe(201);
      expect(response.body).toMatchObject(userData);
    });
    
    it('should return 400 for invalid email', async () => {
      const userData = { name: 'John', email: 'invalid-email' };
      const response = await createUser(userData);
      expect(response.status).toBe(400);
    });
    
    // ... 47 more similar tests generated in minutes
  });
}

// Where AI struggles: Business logic requiring judgment
function calculatePricing(user, product, context) {
  // Requires understanding of:
  // - Business rules that aren't in training data
  // - Edge cases specific to this domain  
  // - Trade-offs between accuracy and performance
  // - Integration with existing pricing logic
  
  if (context.isBlackFriday && user.hasLoyaltyCard) {
    // Should this stack with other discounts?
    // How does this affect our margins?
    // What about regional pricing differences?
    // AI can't make these judgment calls
  }
}

The real wins come from what I call the "30-minute rule"—tasks that would take a human roughly 30 minutes show the highest AI success rates. These are substantial enough to benefit from automation but simple enough that AI's lack of deep understanding doesn't matter. Generate CRUD endpoints? Perfect. Write migration scripts? Excellent. Design a distributed system's failure recovery strategy? Not so much.

Multi-agent environments show particular promise when properly constrained. JM Family's BAQA Genie system cut development cycles from weeks to days by using specialized agents for requirements, coding, documentation, and QA. But notice the pattern: each agent handles a well-defined slice of the problem. When AI agents stick to their lanes, they can be remarkably effective.

The architecture of future human-AI collaboration

The path forward isn't AI versus human—it's designing workflows that leverage each side's strengths. Anthropic's research on "workflows versus agents" provides a crucial insight: predefined workflows with human checkpoints consistently outperform fully autonomous agents on complex tasks. Their evaluator-optimizer pattern, where AI generates and humans review in iterative loops, points toward a sustainable model for AI-assisted development.

Effective Human-AI Collaboration Workflow:

1. Human defines the architecture (judgment required) - Set technical direction and constraints

2. AI generates implementation (pattern matching) - Write code following established patterns

3. Human reviews and validates (judgment required) - Ensure business logic and edge cases are handled

4. AI generates comprehensive tests (pattern matching) - Create test coverage based on code structure

5. Human reviews test coverage (judgment required) - Verify tests actually validate important behaviors

Anti-pattern: Full autonomy without checkpoints Asking AI to handle the entire feature development process without human oversight often fails because AI lacks business context, domain knowledge, and judgment about trade-offs.

Think of it as the difference between hiring a junior developer and installing a power tool. You don't expect your nail gun to design the house, but you'd be foolish to frame it with a hammer. Similarly, AI excels at the mechanical aspects of coding—syntax, patterns, boilerplate—while humans handle the judgment calls about architecture, trade-offs, and business logic.

Test-driven development with AI represents this sweet spot perfectly. Humans define the test cases (judgment about what matters), AI writes the failing tests (pattern matching), humans review and commit (quality control), then AI implements the code (mechanical execution). Each party does what they do best.

Prompting adjustments that close the gap

If we accept that AI will often write more verbose, less elegant code than experienced developers, can we prompt our way to better results? The research suggests yes, but with caveats.

The most effective prompting strategies share a common thread: they inject human judgment into the AI's process. OpenAI's Q&A strategy works because it forces the AI to surface its assumptions for human validation. Role-based prompting ("Act as a security engineer") provides the context that AI lacks naturally. Incremental refactoring with human checkpoints prevents the cascade of "almost right" solutions that plague autonomous generation.

// Ineffective: Open-ended prompting
"Fix the performance issue in this code"

// Effective: Constrained prompting with context
`You are a senior React developer. This component fetches data from WordPress.

CONTEXT: The component should load in under 500ms but currently takes 7+ seconds.
SYMPTOMS: Network tab shows hanging requests to /wp-json/wp/v2/categories
CONSTRAINT: Keep existing functionality, only fix the performance issue

Review this code and identify the root cause:
[code here]

Before proposing a solution, ask yourself:
1. What specifically is causing the hanging request?
2. Is this a caching issue, API issue, or configuration issue?
3. What's the minimal change that fixes the root cause?`

// AI now has the context and constraints needed for targeted analysis

Here's what actually works: constrain the solution space, provide rich context, avoid open-ended tasks, and always maintain human review. When developers remember that AI is a powerful pattern matcher, not a thinking engineer, they can craft prompts that play to its strengths. Ask it to implement a specific algorithm, not to decide which algorithm to use. Have it write code that passes existing tests, not design the testing strategy.

My biggest prompting adjustments these days are trying to get AI to write less code and to review solutions more thoroughly. Until AI gets "smarter" at judgment, constraining the scope and requiring explicit validation steps works better than expecting autonomous brilliance.

Economic reality check and industry implications

The economic data presents a striking paradox. McKinsey projects $6.1-7.9 trillion in economic benefits from generative AI, yet our content fetching case study and the METR research show experienced developers getting slower with AI assistance. How do we reconcile this?

The answer lies in distribution and task selection. AI dramatically accelerates junior developers and helps seniors with routine tasks, but it can actively hinder experts working on complex problems. GitHub's data shows 41% faster task completion for new developers but much smaller gains for experienced ones. The revolution isn't in replacing senior engineers—it's in amplifying junior productivity and eliminating routine work.

This has profound implications for team composition. Companies that treat AI as a senior engineer replacement will struggle. Those that use it to give junior developers senior-level productivity on appropriate tasks will thrive. The optimal team might be fewer, more senior engineers focused on architecture and judgment calls, supported by AI handling implementation details and routine code generation.

// Traditional team structure
const team = {
  seniors: 3,     // Architecture + complex features
  mids: 5,        // Feature implementation
  juniors: 4,     // Bug fixes + simple features
  productivity: 1.0
};

// AI-augmented team structure  
const aiTeam = {
  seniors: 3,     // Architecture + judgment calls (100% human)
  mids: 3,        // Review AI code + complex integration (-40% count, +50% productivity)
  juniors: 2,     // Partner with AI on implementation (-50% count, +200% productivity)
  ai: 'unlimited', // Pattern matching + boilerplate generation
  productivity: 1.8
};

What this means for agentic coding's future

Industry predictions suggest we'll achieve "superhuman coder" capabilities by 2027, with AI matching or exceeding human programmers on most tasks. I'm skeptical, not of AI's trajectory but of what "most tasks" means. If we define programming as syntax and pattern implementation, then yes, AI will dominate. If we define it as understanding business needs, making architectural trade-offs, and debugging complex systems, we're much further away.

Consider the fundamental challenge: every new business requirement, every edge case, every integration with legacy systems requires judgment that can't be pattern-matched from training data. The more successful AI becomes at routine coding tasks, the more valuable human judgment becomes for everything else.

Tasks AI will likely master by 2027:

• Generate boilerplate code and scaffolding

• Write comprehensive unit tests from specifications

• Implement standard CRUD operations

• Generate documentation from code and comments

• Refactor code using established patterns

• Translate code between programming languages

Tasks requiring human judgment indefinitely:

• Define business requirements and user needs

• Make architectural trade-offs and technology choices

• Debug novel failure modes and edge cases

• Optimize for specific performance constraints

• Integrate with legacy systems and undocumented APIs

• Handle regulatory compliance and security requirements

Neurosymbolic AI and reasoning models like OpenAI's o3 represent genuine advances, achieving Grandmaster-level performance on competitive programming. But these systems require millions of tokens per task, highlighting the massive computational inefficiency compared to human judgment. Evolution spent millions of years optimizing biological neural networks for efficiency. We're trying to replicate that with brute force computation.

Practical recommendations for developers and teams

For individual developers navigating this landscape:

Start with AI on low-stakes, well-defined tasks. Use it to learn new frameworks and APIs where its pattern matching helps you recognize common idioms. Leverage it for test generation and documentation where "good enough" truly is good enough. But maintain your judgment skills—they're your competitive advantage. The developers who thrive will be those who can orchestrate AI tools while maintaining the ability to dive deep when judgment is required.

Practice prompt engineering, but don't expect prompting to solve fundamental limitations. No prompt will give AI the judgment to know when a content fetching issue stems from a specific SWR configuration versus a network timeout. That recognition comes from experience encoded in neural pathways, not statistical patterns in training data.

For engineering teams implementing AI coding tools:

Adopt GitHub's four-stage framework: evaluate with volunteers, scale gradually, optimize workflows, then sustain improvements. But customize it for your context. Mature codebases with implicit requirements need different strategies than greenfield projects. The METR study's 19% slowdown happened on 10+ year old codebases with millions of lines of code—your mileage will vary.

Invest heavily in documentation and testing—these become the interfaces through which AI understands your system. Clear coding standards help AI generate consistent code. Comprehensive tests let you safely experiment with AI-generated changes. Think of it as creating an operating manual for your AI assistant.

Most critically, measure actual productivity, not perceived benefits. The gap between developer perception and reality in the METR study should alarm every engineering manager. Track not just speed but also bug rates, code review time, and long-term maintenance costs. AI that generates code 50% faster but requires 100% more debugging time is a net negative.

// Effective AI integration metrics
const metrics = {
  // Traditional metrics (insufficient alone)
  codeVelocity: '+40%',
  ticketsCompleted: '+25%',
  
  // Essential quality metrics
  bugEscapeRate: '-15%', // Good: AI catches simple bugs
  codeReviewTime: '+30%', // Concerning: More review needed
  technicalDebt: '+10%', // Warning: Monitor closely
  
  // Business impact metrics
  timeToMarket: '+20%',
  customerSatisfaction: 'stable',
  maintenanceCost: '+5%' // Acceptable trade-off
};

The bottom line on where we are and where we're going

We're at an inflection point where AI coding tools are simultaneously overhyped and underutilized. They're overhyped as replacements for engineering judgment and underutilized as amplifiers of human capability. The content fetching case study isn't an argument against AI—it's an argument for understanding what makes human engineers valuable and using AI to handle everything else.

The current state of agentic coding is powerful pattern matching without judgment. AI will solve your problems, but often inelegantly, verbosely, after exploring paths that didn't need exploring. For tasks where patterns work—much of programming's mechanical work—this changes everything. For tasks needing judgment, context, and elegant solutions, experienced engineers aren't going anywhere.

The engineers who will thrive in this new landscape are those who understand this distinction viscerally. They'll use AI to handle the probabilistic pattern matching while reserving their judgment for the decisions that matter. They'll write less code but make more architectural decisions. They'll debug less syntax but spend more time on system design.

This isn't simply a temporary state awaiting better AI. Even as AI capabilities advance toward the predicted "superhuman coder" of 2027, the gap between pattern matching and judgment will persist. The question isn't whether AI will replace programmers but how the profession will evolve when the mechanical aspects are automated. Based on the content fetching tale and thousands of similar stories playing out across the industry, that evolution will be messier, more gradual, and ultimately more human than the AI evangelists predict.

The future of software development isn't AI or human—it's AI and human, each doing what they do best. Understanding that distinction, and designing our tools and workflows around it, is the real challenge of agentic coding. Those who get it right will write less code but build better systems. Those who don't will generate twice as much code to solve problems that judgment could have handled in a few precise lines.

Related Reading

On AI Tool Evolution & Market Reality:

• The Other Shoe Will Drop - Why current AI pricing economics are unsustainable

• Around the Horn: AI Coding Tools Reality Check - Recent market developments and tool performance

On Debugging & Tool Reliability:

• The Ghost in the Machine: Non-Deterministic Debugging - When AI tools behave unpredictably

• What's In My Toolkit - August 2025 - Current tool setup and why specific choices matter

On AI Orchestration vs Direct Usage:

• I Hope Never To Use Claude Code Again - Moving from individual AI assistants to orchestrated teams

• Multi-agent AI Orchestration in Practice - Real-world experiences with coordinated AI development

I'm taking a break from my usual technical deep-dives to give you some light Friday reading and highlight a gem of a term coined by Josue Gandarilla, a QA developer working on Recess—the parent activity marketplace I'm leading tech for. According to Josue, a "pregnant bug" is a bug that gives birth to other bugs. Picture this: you think you've squashed one issue cleanly, only to watch as baby bugs scuttle out into the darkness, multiplying your problems exponentially.

While everyone should have a Josue keeping a watchful eye on their features (seriously, find yourself a meticulous QA person), the real point of this post isn't about human bug hunting per se. It's about reinforcing why agentic development absolutely shines when you're re-platforming.

The Re-platforming Advantage

Unlike new feature work—where you're often building into ambiguity, iterating on uncertain requirements, and navigating the fog of "what should this actually do?"—re-platforming gives you something invaluable: a rock-solid specification to work from. You have existing APIs with well-defined contracts, established type schemas, proven frontend components, and battle-tested user flows. These are precisely the elements that AI excels at modeling and implementing.

Using this natural advantage, we re-platformed Recess in August during what should have been a months-long sprint. The existing system served as our perfect blueprint—every endpoint documented through usage, every data transformation proven in production, every edge case already discovered and handled.

Optimizing for Velocity

We're not stopping there. We're currently optimizing our stack by moving to Neon for its superior developer experience and feature-aligned branching capabilities. When this migration is complete, we expect to have a much more agile platform that will significantly increase our development velocity. And watching that acceleration will require more than just Josue keeping guard—though he'll certainly be busy.

The Testing Multiplier Effect

Here's where agentic coding becomes truly powerful: testing. Unit tests, regression tests, end-to-end tests, smoke tests, canary deployments—all the tools you need to accelerate development safely while avoiding those pregnant bugs altogether.

One of the first things I look for when evaluating codebases for founders is test coverage. Perhaps not surprisingly, it's one of the things development teams NOT led by an internal engineering leader consistently ignore. And it's not just contractors—the original dev team for Recess had zero test coverage when I arrived.

Let me be clear: I'm not a TDD zealot. There are very good reasons why you might add test coverage AFTER building, especially if you're developing in an agile fashion where requirements are fluid. This is very different from writing to external requirements where the spec is locked down. But once you've nailed down functionality and data models—even while still in flight—write the tests. It's non-negotiable.

This becomes particularly crucial with agentic development, where LLMs absolutely love to write code (sometimes too much code). Test coverage isn't just nice to have—it's your safety net when AI is generating implementations at superhuman speed.

When AI can generate comprehensive test suites based on your existing codebase and API contracts, you're not just moving faster; you're moving more safely. We're targeting 90%+ test coverage as we ramp up our velocity, because with great speed comes great responsibility to not break things.

The beauty is that tests are perfect AI work: they're highly structured, follow predictable patterns, and have clear success criteria. Feed an AI your API schema and a few examples, and it can generate exhaustive test cases covering happy paths, edge cases, and error conditions you might not have even considered.

The Call to Action

If you're facing any re-platforming work, I encourage you to fire up Claude Code, Augment Code, or Cursor and experience this for yourself. Don't approach it like you're building something net-new. Instead, treat your existing system as the detailed specification it actually is, and let AI do what it does best: faithfully implementing well-defined requirements at superhuman speed.

Your future self—and your QA team—will thank you for the robust, well-tested platform you'll end up with. Plus, you'll have far fewer pregnant bugs scuttling around in the shadows.

Originally published on hyperdev.matsuoka.com