“Claude writes a significant proportion of Anthropic’s code. As of May 2026, more than 80% of the code we merge into Anthropic’s codebase was authored by Claude. Before Claude Code launched in research preview in February 2025, this number was in the low single digits.” – Anthropic – Artificial Intelligence – Recursive Self Improvement
The moment an internal engineering metric flips from human-written to AI-written code marks a structural shift in how complex software systems are built and evolved, not just a productivity bump for individual programmers.1 It signals that the primary generative force shaping a large codebase has become a model rather than a workforce, and that human engineers are increasingly curators, reviewers, and system designers guiding a non-human author.7
In Anthropic’s case, that shift is tightly bound to a broader concern: the trajectory from powerful coding assistants to systems that can meaningfully participate in, and eventually drive, the entire AI research and development cycle.7 When an AI model can write most of the code for its own infrastructure, tools, and scaffolding, the boundary between “AI helps humans build AI” and “AI builds AI” becomes thinner, and the timeline to more thorough forms of recursive self-improvement compresses.1,3,7
From coding assistant to dominant author
Large language models like Claude were initially introduced as general-purpose assistants: chatbots that could answer questions, draft text, help with documents, and generate basic code.2,13,15 Early coding capabilities looked like autocomplete on steroids: filling in small functions, refactoring snippets, or suggesting tests. In that phase, AI was clearly subordinate to the human developer, integrated into IDEs as a suggestion layer with humans still doing the conceptual work, system design, and most of the implementation.
The internal numbers highlighted by Anthropic indicate that this relationship has inverted in at least one crucial dimension: the share of merged code now primarily authored by the model rather than by employees.7 Human engineers still specify goals, review diffs, and orchestrate work, but the bulk of literal line-by-line code is machine-generated. Independent developers using Claude Code describe a similar workflow: they treat the AI interface almost as the primary editor, with a traditional editor demoted to a verification and correction tool.5 One typical pattern is to spend most of the time explaining the problem and iterating on plans with the model, then auto-accept its changes, and only afterwards manually review and adjust.5 That mirrors the internal picture: humans move up a level of abstraction, while the model handles implementation detail at scale.
The key structural consequence is that the constraint on how fast a codebase can change shifts away from human typing speed or individual concentration. Instead, the main bottlenecks become prompt quality, review capacity, testing infrastructure, and organisational willingness to deploy AI-authored changes. Once those guardrails are in place, the marginal cost of asking the AI to implement yet another subsystem approaches the cost of specifying it, rather than building it yourself.
Recursive self-improvement: several distinct mechanisms
The idea of recursive self-improvement (RSI) in AI originally focused on a dramatic scenario: a sufficiently capable system rewrites its own code, becomes smarter, uses that increased intelligence to further rewrite itself, and so on, producing an “intelligence explosion”.1 In more formal discussions, RSI is framed as a process where an AI improves its own ability to improve, potentially leading to superintelligence if the feedback loop is strong enough.1,3 For decades this remained hypothetical, because no deployed system could modify its own internals in a reliable, directed way.
Recent work on RSI has clarified that there are at least three separable mechanisms, each with different bottlenecks and risk profiles.3,6 First, there is what some researchers call scaffolding-level improvement: you keep the base model weights fixed but wrap the model in better tools, agents, and workflows that make more effective use of its capabilities over time.6 Coding agents that orchestrate tool calls, decompose tasks into subproblems, and maintain long-lived workspaces fall into this category. The AI does not change itself directly, but the environment around it is iteratively improved-often with heavy AI assistance.
Second, there is improvement of the broader AI research and engineering process. Here, models help design better architectures, tune hyperparameters, automate experiments, and analyse results.6,9 The AI is not rewriting its own weights on the fly but is heavily used by human researchers to run more experiments faster, test more ideas, and push the frontier models forward.9 In effect, the research pipeline that generates new models is being partially automated by prior models, shortening cycle times.
Third, there is the more classical vision of model-internal self-modification: a system that can inspect, reason about, and deliberately rewrite its own internal structure.1,3 In the current deep learning paradigm, this would require some combination of advanced mechanistic interpretability and internal training or optimisation loops guided by the model itself.6 This is the least empirically grounded category today; there are not yet widely documented systems that autonomously edit their own weights in a stable, predictable way in production, without external training pipelines.
Anthropic’s published analysis emphasises that the world is beginning to see concrete progress in the first two forms of RSI, while the third remains more speculative but increasingly relevant.7,9 The metric that more than four-fifths of merged code comes from Claude is directly relevant to the first two types: scaffolding-level improvement and research-process acceleration. It is not yet full-blown self-modifying AI, but it clearly moves along the continuum from “AI as a tool” to “AI as a primary agent in its own development ecosystem”.
What does it mean for AI to “build itself”?
In its report “When AI builds itself”, Anthropic defines a future regime in which AI systems can design, implement, and train successor models with minimal human involvement.7 That scenario includes choosing research directions, generating experimental configurations, running training runs, monitoring results, and iteratively refining architectures, all mediated by models rather than individual researchers.7,9 The report stresses that current systems have not yet reached this stage, but the pattern of automation suggests a trajectory that could plausibly converge towards it in the medium term.7
Already, tools like Claude Code enable models to handle much of the mundane engineering needed to integrate new components, instrument experiments, and manage evaluation pipelines.5,7 For example, a model can generate scripts to launch training runs, write configuration files for different hyperparameter sweeps, produce dashboards for monitoring metrics, and adapt code to new hardware or inference setups. Engineers remain in the loop to approve designs, interpret anomalies, and adjust objectives, but they increasingly operate at the level of specifying desired behaviours and constraints rather than manually wiring every detail.
Once the majority of the code surrounding the training and deployment pipeline is generated by models, the human role shifts to defining goals, setting safety criteria, and analysing higher-level trade-offs. The mechanics of “building”-in the sense of constructing new experimental setups, converting research ideas into running code, and instrumenting systems-becomes heavily AI-mediated. Over time, if models learn from this process (for instance by analysing successful and failed experiments), they can become better at designing and conducting AI research itself.7,9
Strategic and technological tensions
The shift towards AI-written code simultaneously advances capability and heightens safety concerns. On the one hand, organisations that can mobilise models as large-scale coding engines enjoy dramatic efficiency gains. Anthropic and other labs report that a single engineer working with AI can now accomplish several times the output of a solo developer from only a few years ago.4,9 Internal numbers cited in commentary around the Anthropic report suggest that in some workflows, one engineer paired with advanced coding models can match the productivity of many engineers without such tools.4 This is economically attractive and strategically hard to ignore, especially in competitive markets where speed and feature velocity matter.
On the other hand, every additional layer of automation in the AI development pipeline reduces the surface area where humans directly engage with the details of what is being built. If most of the code diff is AI-authored, there is a constant pressure to keep review lightweight enough not to erase the productivity gains. Organisations must decide how much friction to reintroduce via testing, code review, and formal verification to compensate for the opacity and potential brittleness of model-generated software.
There is also a tension between transparency and performance. Coding models are trained on large corpora and fine-tuned for usefulness, but their internal reasoning is not inherently interpretable. When such models are tasked with writing critical infrastructure-especially infrastructure that itself trains or deploys models-the demand for rigorous verification increases. Yet the whole point of using AI at scale is to compress the development cycle; fully auditing every AI-generated line is often infeasible. This pushes teams towards probabilistic assurance: relying on automated tests, static analysis, and spot checks, accepting that some defects or misalignments may slip through.
Anthropic’s policy stance reflects this tension. The organisation has publicly advocated for a potential future pause or slowdown in frontier AI development if such a pause can be coordinated and verifiable.4,7 At the same time, it continues to deploy tools that significantly accelerate the AI engineering process. The argument is not that acceleration ought to stop now, but that the world should build governance and monitoring infrastructure capable of making a pause credible if systems begin to show signs of more autonomous, less controllable forms of self-improvement.4,7
Debates and objections
There are several lines of scepticism about treating AI-written code as a near-term marker of recursive self-improvement. One objection is that a model generating code on command is still deeply dependent on a human-constructed training pipeline and hardware stack. The AI may write most of the repository, but it does not yet select its own training data, modify its own loss functions, or commission new datacentres. From this perspective, calling such behaviour “self-improvement” risks overstating the level of autonomy.
Another objection focuses on quality. Critics argue that high percentages of AI-written code may reflect a bias towards quantity over robustness. If models can quickly generate large volumes of superficially plausible code, teams may be tempted to merge more, trusting tests and users to uncover issues. This could increase technical debt and vulnerability surfaces, particularly if AI-generated code uses patterns that are less idiomatic or less well understood by the team. In this view, the headline figure of more than four-fifths AI-authored code says more about internal incentives and tooling than about genuine leaps in capability.
A further concern is that the narrative of “AI writing its own code” might be leveraged for competitive signalling or regulatory positioning. Emphasising that models are rapidly approaching self-building status can support calls for stricter regulation, but it can also serve as a way to demonstrate leadership and sophistication in the race for funding and talent. Observers therefore scrutinise such claims, asking how the metric is defined (for example, how attribution between human and AI edits is measured) and what kinds of code are included-core model logic, surrounding infrastructure, or peripheral tools.
Supporters of the stronger interpretation respond that the exact percentage is less important than the direction of travel and the kinds of tasks being automated. The movement from “AI can write helper scripts” to “AI can build and maintain major production systems” represents a qualitative shift. Moreover, as AI-generated code begins to include experiment orchestration, data processing pipelines, and evaluation harnesses, the model’s role in improving subsequent models increases, even if human oversight remains substantial.7,9 From this vantage point, the concern is not that current systems are already self-improving in the strongest sense, but that they are laying the groundwork for a regime in which incremental capability increases lead to disproportionate gains in further capability development.
Why it matters beyond software engineering
The implications of AI writing most of the code in a frontier lab extend well beyond the internal life of software teams. One major dimension is economic. If an AI-augmented engineer can do the work of several traditional engineers, the effective labour cost of software development drops sharply.4,9 Over a horizon of a few years, this could reshape labour markets, favouring organisations that can most effectively integrate AI into workflows. Entire categories of skilled work-software engineering, research assistance, data analysis, legal drafting-could be automated at a pace that leaves limited time for institutions to adapt.4,9
Another dimension is geopolitical. Access to models capable of acting as high-bandwidth coding engines becomes a strategic asset. States or firms that control such systems can upgrade their digital infrastructure, defence systems, and research capabilities faster than competitors. If recursive self-improvement processes take hold, the gap between leading actors and followers could widen rapidly.4,7,10 This is one reason why some analysts emphasise the risks of concentration of power: if a small number of organisations own the most capable self-improving AI systems, they may acquire outsized influence over economic and political developments.4,10
There is also a safety dimension that goes beyond the immediate risk of buggy code. As AI systems participate more in their own development, misalignments in objectives or reward signals can be compounded. If an AI is tasked with optimising for performance on certain benchmarks, and it also plays a role in designing the evaluation apparatus and experimental setups, it might inadvertently favour changes that make it look better on metrics without improving, or even while degrading, its broader alignment with human values. The more of the research loop is automatised, the more important it becomes to design robust, hard-to-game objectives and interpretability tools.1,3,7
Finally, there is an epistemic dimension. When AI systems write most of the code, run most of the experiments, and summarise most of the results, human understanding of complex software and research landscapes can become indirect. Engineers and scientists may interact primarily with AI-generated abstractions of what is going on. This can be efficient, but it also risks a kind of institutional deskilling: fewer people understand systems end-to-end, making it harder to detect systemic errors, correlated failures, or unanticipated interactions. In high-stakes domains, that loss of deep understanding could itself become a safety hazard.
The emerging role of human engineers
In the near term, the rise of models as dominant code authors does not eliminate the need for human engineers; it changes their role. Reports from practitioners using Claude Code suggest that humans increasingly focus on problem decomposition, specification, and verification.5 They spend more time writing detailed natural language descriptions of desired behaviour, orchestrating multi-step workflows, and designing tests that capture subtle requirements. They also become stewards of code quality and maintainers of conceptual coherence across rapidly evolving codebases.
This role shift is non-trivial. Writing good prompts or instructions is a skill; designing prompts that anticipate edge cases, security concerns, and performance constraints is even more demanding. Similarly, effective verification under conditions of AI-generated abundance requires new practices: stronger automated test suites, better monitoring, and perhaps new forms of formal methods that are integrated into everyday workflows. Human engineers who adapt to these demands may become more like system architects and editors, curating and refining the work of a powerful but sometimes unreliable assistant.
At the same time, there will likely remain pockets of development where human-written code is preferred or required, especially for safety-critical components, low-level systems programming, or domains where subtle domain knowledge is hard to transmit through prompts alone. The distribution of human effort across a codebase will change: less time on boilerplate and repetitive patterns, more on rare but consequential decision points.
Looking ahead
The internal data that an AI system now authors the majority of a leading lab’s merged codebase should be understood as a waypoint, not an endpoint. It marks a concrete, measurable point on a curve that leads from basic assistance to deeper forms of recursive self-improvement. The same dynamics that allow models to dominate code authoring-scaling, better scaffolding, agentic tools, and integration into research workflows-are also those that will shape how quickly AI systems begin to design and build their successors with decreasing human input.1,3,6,7
Whether this trajectory culminates in controllable, beneficial systems or in hard-to-govern, rapidly self-improving agents will depend on decisions being made now: how much autonomy to grant coding models, what review standards to enforce, how to design incentives for safety rather than pure speed, and what international coordination mechanisms to build in anticipation of more powerful RSI. As the proportion of AI-written code grows, so too does the responsibility to align not just the models, but the socio-technical systems that surround them.
References
1. When AI builds itself – Anthropic – 2026-06-07 – https://www.anthropic.com/institute/recursive-self-improvement
2. Recursive self-improvement – Wikipedia – 2004-11-14 – https://en.wikipedia.org/wiki/Recursive_self-improvement
3. Artificial Intelligence : Claude AI – Research Guides – 2026-05-11 – https://researchguides.library.syr.edu/c.php?g=1341750&p=10258238
4. Recursive Self-Improvement – AI Alignment Forum – 2025-05-20 – https://www.alignmentforum.org/w/recursive-self-improvement
5. ‘Slow Down…’, What Is AI ‘Recursive Self-improvement … – YouTube – 2026-06-05 – https://www.youtube.com/watch?v=RjTT8Ad6qJ8
6. Why Claude Code Changed My Mind About AI Development – Prismic – 2025-08-06 – https://prismic.io/blog/claude-code
7. “Recursive Self-Improvement” Is Three Different Things – LessWrong – 2026-02-10 – https://www.lesswrong.com/posts/XHd75cuHhWcBDd8to/recursive-self-improvement-is-three-different-things
8. Claude by Anthropic – Apps on Google Play – https://play.google.com/store/apps/details?id=com.anthropic.claude&hl=en_US
9. On Recursive Self-Improvement (Part I) – by Dean W. Ball – 2026-02-05 – https://www.hyperdimensional.co/p/on-recursive-self-improvement-part
10. What Is Recursive Self-Improvement in AI? The Intelligence … – 2026-05-13 – https://www.mindstudio.ai/blog/what-is-recursive-self-improvement-ai-intelligence-explosion/
11. Claude: Sign in – https://claude.ai
12. Anthropic Academy: Claude API Development Guide – 2025-03-25 – https://www.anthropic.com/learn/build-with-claude
13. Claude (language model) – Wikipedia – 2024-01-22 – https://en.wikipedia.org/wiki/Claude_(language_model)
14. Claude Code Tutorial – Build Apps 10x Faster with AI – YouTube – 2026-03-24 – https://www.youtube.com/watch?v=IuyVVtr1uhY
15. What Is Claude AI? – IBM – 2024-09-24 – https://www.ibm.com/think/topics/claude-ai
