Anthropic co-founder Jack Clark’s latest argument is not that AI systems have already crossed into self-improving autonomy. It is narrower, and more consequential: public benchmark data now supports a credible path to AI systems doing enough of the work of AI research that they could start improving successor models with limited human intervention.
Clark’s odds are the headline. In his newsletter, he puts the chance of that kind of recursive self-improvement at roughly 30% by 2027 and about 60% by the end of 2028. Those are not certainties, but they are no longer throwaway forecasts either. They are anchored in a visible set of capability curves that matter to technical teams because they map onto tasks that sit close to the center of model development: coding, debugging, reproducing research results, and extending task horizons beyond a few minutes of human oversight.
What changed is not one breakthrough, but a stack of them
The reason the claim feels different now is that multiple benchmarks are moving in the same direction.
SWE-Bench is the clearest example. The benchmark tests whether a model can solve real GitHub issues in codebases with actual software engineering constraints, not toy examples. Clark points to progress from about 2% success with Claude 2 in late 2023 to 93.9% today, effectively near saturation for the benchmark as it is currently constructed. That does not mean models can replace entire engineering teams. It does mean they can now handle a large share of the patching, debugging, and repository navigation work that used to require a human in the loop for almost every step.
METR’s time-horizon measurements tell a different but complementary story. The measure tracks how long a task a system can complete at 50% reliability, expressed in human-equivalent hours. Clark cites a jump from roughly 30 seconds with GPT-3.5 to around twelve hours with current frontier systems, and METR researcher Ajeya Cotra has suggested 100 hours by the end of 2026 is plausible. That matters because research work rarely arrives as a single neat prompt. It is a chain of subproblems: read, hypothesize, implement, run experiments, inspect failures, revise, and repeat. The longer the task horizon, the more of that chain a system can carry without immediate supervision.
CORE-Bench strengthens the same case from a research angle. The benchmark asks models to reproduce the results of a paper, which gets closer to the mechanics of AI research than generic coding tasks do. Clark cites one of the benchmark’s authors describing it as effectively solved at 95.5%. Again, “solved” here should be read carefully: benchmarks can saturate, real research can’t. But high scores on tasks like this suggest that pieces of the research loop that once looked brittle are becoming routine.
Put together, these trajectories sketch a world in which AI systems can do more than assist researchers. They can increasingly execute the kind of work that produces better models, which is the technical basis of recursive self-improvement. That is why Clark’s probability estimates matter. They translate an abstract idea into a plausible timeline grounded in public measurements rather than vibes.
Why the benchmarks matter operationally
For product and infrastructure teams, the practical question is not whether a model can one day “improve itself” in some broad philosophical sense. It is whether the model can safely take over enough of the development cycle to compress iteration time.
If AI systems can reliably handle code changes, test generation, experiment design, and paper reproduction, the cycle between hypothesis and deployment can shrink sharply. A feature that once required a team’s daily attention could become a sequence of machine-generated proposals, evaluations, and merges with humans reviewing only the most risky steps. That would change how teams budget compute, how they staff research and engineering, and how they define quality control.
The implication for tooling is immediate. Model providers and internal platform teams will need stronger evaluation pipelines that go beyond static benchmark scores. If an automated research agent can produce code, run experiments, and suggest successor models, then the critical failure modes become less about isolated accuracy and more about drift, reward hacking, hidden regressions, and over-optimization against narrow metrics. Teams will need monitoring that can detect when a system is becoming more capable at the task while less trustworthy in the process.
Containment also becomes a product feature, not just a policy issue. Sandboxed execution, limited permissions, staged rollouts, secure experiment environments, audit trails, and rollback mechanisms stop being nice-to-haves. They become the basic architecture for any serious attempt to let models participate in research workflows. The more the loop closes, the more important it becomes to preserve human veto power over training runs, architecture changes, and deployment gates.
Competitive advantage will likely accrue to the teams that can evaluate better, not just model better
If Clark’s framing is directionally right, the next strategic divide may not be between the labs with the largest frontier models and everyone else. It may be between the organizations that can reliably operate automated research systems and those that cannot.
That favors teams with mature eval infrastructure, strong internal tooling, and a discipline around deployment that treats benchmark gains as inputs, not verdicts. A lab that can measure model behavior across long-horizon tasks, catch regressions early, and confine risky actions to controlled environments will be better positioned to use AI to accelerate AI development itself.
The market implication is that tooling vendors and platform builders may find new demand in the unglamorous layer beneath model releases: experiment orchestration, eval harnesses, provenance tracking, policy enforcement, and automated red-teaming. In a world where “progress” includes a model’s ability to help train the next model, the product stack shifts toward systems that can observe and constrain the loop.
That could also reshape how vendors communicate capability. A simple leaderboard score will matter less than evidence that a system can sustain performance across multi-step workflows under realistic operational constraints. For enterprise buyers, that means asking not only whether a model can solve a benchmark, but whether the surrounding stack can prove when the model should not be allowed to act.
The governance problem gets harder as capability gets cleaner
The temptation with these benchmark curves is to treat them as a countdown. That would be a mistake.
Recursive self-improvement is not guaranteed, and Clark’s own probability estimates leave substantial uncertainty. A 30% chance by 2027 is meaningful precisely because it is not 100%. Model capability can plateau. Benchmarks can saturate. Real-world research can expose gaps that synthetic tests miss. And even if systems become capable enough to automate more of AI research, the transition from capability to safe deployment is not automatic.
That gap is where governance becomes technical.
As models move closer to taking part in their own improvement, oversight has to become more than a policy document. Organizations will need clear criteria for when a model may propose changes, when it may execute them, what evidence is required before those changes are accepted, and which actions remain permanently human-controlled. Without that structure, capability gains can outpace the ability to contain bad outcomes, whether those are ordinary regressions, security failures, or deeper alignment issues.
The broader regulatory question is just as complex. Systems that can materially accelerate model development may force policymakers to think less about individual applications and more about the control of the development process itself. That is a harder problem. It involves auditability, access controls, compute governance, and how to verify that powerful systems are not operating beyond the oversight that their operators claim.
Clark’s argument matters because it makes the timeline concrete enough to plan against. The benchmark evidence does not prove that AI will automate AI research by 2028. It does suggest that the capability stack required for that outcome is no longer science fiction, and that technical teams should prepare for a world where the bottleneck is increasingly not raw model intelligence, but the systems around it that decide what the model may do next.
