Claude Code Rewrites Claude App: Where Are the Limits of AI Coding Agents?

Introduction: When an AI Programming Tool Challenges Itself

Boris Cherny, a core developer of Claude Code at Anthropic, shared a thought-provoking experiment—attempting to use Claude Code to rewrite the Claude App itself. Behind this seemingly simple idea lies the most fundamental question about current AI programming tools: to what extent can an AI coding agent handle real, complex, large-scale production-grade codebases?

This is not merely a technical demonstration but a stress test of AI programming capabilities. Using a tool to refactor the very product that created it carries an undertone of "self-iteration" and offers the entire industry a glimpse into the real gap between AI-assisted programming going from "toy-level" to "engineering-level."

What Is Claude Code: The Leap from Completion to Agency

Claude Code is Anthropic's command-line AI programming agent (agentic coding tool). Unlike traditional code completion plugins, it operates in an "agentic" mode, autonomously executing multi-step programming tasks.

Traditional AI programming assistants (like early code completion tools) are essentially "passive"—you write a line, and they guess the next one. Agent-based tools like Claude Code are "active": you provide a goal (such as "add unit tests to this module" or "refactor this logic"), and it autonomously reads the codebase, understands context, edits multiple files, runs commands, and adjusts based on feedback.

The Technical Foundation of Agentic AI Programming Tools

Claude Code's ability to operate in "agent" mode relies on several key capability breakthroughs in large language models (LLMs). First is tool use (Function Calling)—the model can autonomously decide when to invoke external tools such as file read/write, terminal command execution, and code search. Second is planning and reasoning—the model can decompose complex tasks into executable sub-steps and dynamically adjust plans during execution. Finally, there's long context window support—Claude's model supports a 200K token context, enabling it to "read" large volumes of code files at once. This architecture is commonly referred to as the ReAct (Reasoning + Acting) paradigm—the model alternates between thinking and acting in cycles, with each step making decisions based on observations from the previous step, forming a continuous loop of "think → act → observe → think again."

This leap in capability makes ambitious tasks like "having AI rewrite an entire App" theoretically possible. But as Cherny's experiment reveals, there remains a significant gap between theoretical possibility and engineering feasibility.

What Makes Rewriting Claude App So Difficult

Having Claude Code rewrite the Claude App is a classic "bootstrapping" challenge.

The Computer Science Origins of Bootstrapping

Bootstrapping has deep historical roots in computer science. The most classic example is compiler bootstrapping: the first C language compiler was initially written in assembly language. Once it could compile C code, the compiler could be rewritten in C itself, and then the old compiler could compile the new compiler's source code, achieving "self-compilation." Similarly, GCC, the Rust compiler, and the Go compiler have all gone through bootstrapping processes. The core value of this pattern is: if a tool is powerful enough to create or improve itself, it demonstrates its generality and maturity. While Claude Code rewriting the Claude App isn't bootstrapping in the strict sense (it's not rewriting its own source code), it carries similar philosophical implications—using an AI programming tool to work on an AI product's codebase is the ultimate trust test of the tool's capabilities.

The difficulty of this task manifests on several levels.

The Challenge of Understanding Large-Scale Codebases

A mature application typically contains hundreds of thousands of lines of code, complex dependency relationships, and legacy technical debt. An AI agent needs to understand the entire system's architecture within a limited context window, which is an enormous test of the model's long-context processing and code comprehension abilities. When the codebase scale exceeds the model's "cognitive bandwidth," the agent tends to be locally correct but globally out of control.

Technical Bottlenecks of Context Windows and Code Understanding

Even with Claude's 200K token context window (roughly equivalent to 150,000 words or several hundred pages of documents), it still falls short when facing real large-scale codebases. A medium-sized production application might contain hundreds of thousands to millions of lines of code, far exceeding any model's single-pass processing capacity. To address this limitation, agentic tools typically employ RAG (Retrieval-Augmented Generation) strategies—first retrieving relevant code snippets through code search, AST (Abstract Syntax Tree) parsing, and dependency graph analysis, then injecting them into the context. There's also "codebase map" technology, where the model first builds a summary understanding of the overall architecture, forming file-level and module-level functional indexes, then dives into specific modules for details on demand. However, all these methods face issues of information loss and attention dispersion—the model may miss critical cross-module dependencies or lack awareness of distant code coupling relationships. This is why AI tends to exhibit the "locally correct, globally out of control" phenomenon in large codebases.

The Threshold of Production-Grade Quality

Rewriting a real product is fundamentally different from generating a demo. It requires that the generated code not only runs but also maintains existing functionality without regression, preserves performance, and properly handles edge cases. This demands engineer-level rigor from the AI, not merely the ability to "write code that looks correct." In software engineering, this requirement is called "functional equivalence"—the new code must behave identically to the old code across all input-output combinations, including implicit behaviors not explicitly documented but already relied upon by users.

The Write-Test-Fix Closed Loop

A truly valuable AI programming agent must be able to form a complete "write—test—fix" closed loop. Cherny's experiment is essentially testing whether Claude Code can autonomously discover problems when code fails, locate root causes, and fix them, rather than leaving the mess for human developers. This capability requires the model not only to generate code but also to understand test failure messages, analyze stack traces, infer root causes of errors, and generate targeted fixes—a process that may require multiple iterations to converge on the correct solution.

What This Experiment Reveals About the AI Programming Industry

Although public details are limited, this experiment reflects several noteworthy trends in the current AI programming landscape.

The Flywheel Effect of AI Tool Self-Improvement

Using AI tools to improve AI tools themselves is a crucial path to stronger capabilities. If Claude Code can effectively participate in Claude App development, it implies compound growth in development efficiency—the tool gets stronger, the product improves, and the product in turn feeds back into the tool's training data, forming a positive flywheel.

The Flywheel Effect concept comes from Jim Collins' Good to Great, describing a self-reinforcing positive feedback loop. In the AI domain, this concept takes on deeper meaning: if AI tools can participate in improving themselves or their underlying products, it may produce "recursive self-improvement." Specifically in Anthropic's scenario, this flywheel can be described as: Claude Code assists in developing Claude App → improved product experience brings more users and usage data → richer interaction data feeds back into model training and alignment → improved model capabilities make Claude Code stronger → a stronger Claude Code can better assist development. While each step in this cycle offers limited incremental gains with some decay, continuous operation can produce significant compound effects. OpenAI, Google DeepMind, and other companies also extensively use their own AI internally for code writing and research work, all essentially pursuing a similar flywheel.

Human-AI Collaborative Programming Is Currently the Optimal Approach

The current reality is that even the most advanced programming agents are better suited as "highly capable assistants" rather than "independent engineers." They excel at handling well-defined tasks with clear boundaries but cannot replace human engineers in scenarios requiring architectural decisions, trade-off analysis, and domain intuition. The significance of experiments like this lies in continuously probing exactly where the human-machine division of labor boundary lies.

From an engineering practice perspective, the most effective human-AI collaboration model currently shows a clear layered structure: humans handle system design, requirement decomposition, and key decisions, while AI agents handle concrete implementation, test writing, and repetitive refactoring. The role of human engineers is shifting from "code writers" to "orchestrators and reviewers of AI workflows"—they set direction, decompose tasks, review AI output quality, and provide judgment when AI encounters ambiguity. This model can already multiply development efficiency several times in some scenarios, but the prerequisite is that human engineers have sufficiently deep understanding of the codebase to quickly identify subtle errors in AI output.

Internal Dogfooding: The Most Rigorous Product Validation

Using Claude Code to rewrite the Claude App is essentially an extremely rigorous form of "internal dogfooding" (eating your own dog food). When a development team personally uses their own product to tackle their own product's development challenges, it most directly exposes the tool's shortcomings—a product refinement approach championed by many top engineering teams.

The term "dogfooding" originated at Microsoft in the 1980s, when manager Paul Maritz sent an email titled "Eating our own dog food," encouraging teams to use more of their own products under development. This practice has since become core culture at tech companies: Google employees long used early versions of Gmail and Chrome, Meta employees are required to use their own internal collaboration tools, and Apple engineers begin daily use of prototype iPhones months before release. For AI programming tools, dogfooding is especially valuable—because AI products have fuzzy capability boundaries and unpredictable failure modes, standardized benchmark tests often cannot cover the complex scenarios encountered in real use. Only through continuous use in real high-pressure engineering tasks can deep issues be discovered that synthetic tests cannot reveal, such as losing context during multi-file refactoring, introducing race conditions in concurrent code, or making incompatible assumptions when handling legacy code.

Conclusion: AI Programming Is Moving from Assistance to Participation

Boris Cherny's experiment provides us with a precious window for observing the real level of AI programming capabilities. It reminds us that AI programming is advancing from "assisting with writing code" to a new stage of "participating in engineering," but remains a considerable distance from fully autonomous software engineering.

This "considerable distance" can be understood from multiple dimensions: the most advanced AI programming agents currently achieve over 50% resolution rates on standardized benchmarks like SWE-bench, but these test problems are typically bug fixes or feature additions with clear boundaries. When facing ambiguous requirements, cross-team coordination, and incremental architectural evolution in real engineering, AI performance still falls far short of experienced engineers. However, the pace of progress is equally remarkable—a year ago, AI programming tools were mainly limited to single-file code generation, but now they can handle complex refactoring tasks spanning multiple files.

For developers, rather than agonizing over whether AI will replace them, it's better to think about how to harness these tools more effectively—freeing themselves from repetitive labor to focus on higher-dimensional architectural design and creative work. And for companies like Anthropic, daring to use their own tools to challenge their own products is itself the best proof of technical confidence and product integrity.