← Back to Index

AutoEvolver

Can Coding Agents Optimize Algorithms Autonomously? Organization: Princeton NLP Group (Princeton University) Published: March 23, 2026 Type: Blog Post + GitHub Repository Report Type: PhD-Level Technical Analysis Report Date: April 2026

Table of Contents

• Full Title and Attribution
• Authors and Team
• Core Contribution
• Supported Solutions
• LLM Integration
• Key Results
• Reproducibility
• Compute and API Costs
• Architecture Solution
• Component Breakdown
• Core Mechanisms (Detailed)
• Programming Language
• Memory Management
• Continued Learning
• Applications

1 Full Title and Attribution

Full Title: Can Coding Agents Optimize Algorithms Autonomously?

Project Page: tengxiaoliu.github.io/autoevolver

Repository: github.com/tengxiaoliu/autoevolver

Publication Date: March 23, 2026

Institutional Affiliation: Princeton NLP Group, Department of Computer Science, Princeton University

Lineage: Positioned as a direct empirical response to dedicated evolutionary optimization systems including AlphaEvolve (DeepMind, 2025), ShinkaEvolve (2025), ThetaEvolve (2025), and TTT-Discover (2026). AutoEvolver does not build on any of these systems' codebases — it deliberately strips them away to test a minimalist hypothesis.

Publication Format: Technical blog post with open-source supporting materials, not a peer-reviewed paper. The work is primarily empirical and observational, analyzing the emergent behaviors of a general-purpose coding agent applied to algorithmic optimization problems without purpose-built evolutionary scaffolding.

Central Question: "What happens if you give a coding agent an algorithmic optimization problem and simply ask it to keep improving?"

2 Authors and Team

The research team is from the Princeton NLP Group, one of the leading academic NLP labs in the United States. Danqi Chen's group has published extensively on language model capabilities, retrieval-augmented generation, and code generation. The team's approach reflects an empirically-driven philosophy: rather than building a new system, they systematically studied the behavior of an existing one (Claude Code) when given optimization tasks.

Methodological Posture

AutoEvolver is explicitly framed as an observational study rather than a system paper. The researchers did not build a tool — they conducted a carefully controlled experiment to test whether purpose-built evolutionary frameworks are necessary for competitive performance on algorithmic optimization benchmarks. This epistemological stance is critical to understanding the contribution: the result is primarily a set of empirical findings and behavioral observations, not a software artifact.

3 Core Contribution

Key Finding: A general-purpose coding agent (Claude Code with Opus 4.6), given only a problem description, an initial naive solution, and an evaluation script, can achieve state-of-the-art results on established algorithmic optimization benchmarks — surpassing results from purpose-built evolutionary systems like ThetaEvolve and TTT-Discover — with zero evolutionary scaffolding.

The Minimalist Hypothesis

AutoEvolver tests a radical minimalist hypothesis: that the evolutionary framework — population management, selection operators, mutation pipelines, crossover, diversity mechanisms — may be unnecessary when the LLM itself is sufficiently capable. The coding agent spontaneously exhibits behaviors that are functionally equivalent to evolutionary strategies:

The Aspiration Prompting Discovery

Perhaps the most significant methodological contribution is the discovery of aspiration prompting — a minimal intervention technique where a single sentence raising the agent's target score is sufficient to break through performance plateaus. This finding has broad implications:

1. Satisficing behavior: Coding agents exhibit satisficing — they settle for "good enough" solutions unless externally pushed. This mirrors Herbert Simon's bounded rationality theory applied to AI agents.
2. Qualitative strategy shifts: Aspiration prompting doesn't just extend search time — it triggers qualitatively different algorithmic strategies. The agent shifts from incremental parameter tuning to fundamentally different approaches (e.g., switching from simulated annealing to SLSQP joint optimization).
3. Minimal intervention cost: The intervention is a single natural language sentence. No algorithmic modification, no hyperparameter changes, no additional code. This makes aspiration prompting trivially cheap to implement.

What AutoEvolver Is NOT

• Not a framework or tool — it's an empirical study
• Not reproducible in the traditional sense — each run follows a unique trajectory
• Not a replacement for evolutionary frameworks — the authors explicitly acknowledge this
• Not a peer-reviewed paper — published as a blog post with supporting code

4 Supported Solutions

AutoEvolver was tested on three benchmark problems that are standard in the evolutionary AI literature. Each problem represents a different class of optimization:

Problem Taxonomy

Circle Packing (n=26)

Pack 26 non-overlapping circles inside a unit square, maximizing the sum of their radii. Constraints:

$$r_i \le x_i \le 1 - r_i, \quad r_i \le y_i \le 1 - r_i \quad \forall i$$ $$\sqrt{(x_i - x_j)^2 + (y_i - y_j)^2} \ge r_i + r_j \quad \forall i \ne j$$

Objective: $\max \sum_{i=1}^{26} r_i$

This problem has a rich history in computational geometry and operations research. Known optimal configurations exist for small n, but for n=26 the landscape is extremely rugged with many local optima. The problem requires both global exploration (finding a good arrangement topology) and local refinement (precise coordinate optimization).

Erdős Minimum Overlap Problem

A classic problem in additive combinatorics. Partition {1, 2, ..., 2n} into two equal-size sets A and B. For each integer k, let Mₖ count the solutions to aᵢ - bⱼ = k. The goal is to bound c = lim(n→∞) M(n)/n, where M(n) = min_{A,B} max_k Mₖ.

Following prior work, the problem is formulated as optimizing step functions f describing the density of A throughout [1, 2n], with f(x) ∈ [0, 1] and ∫f = 1. The objective:

$$\text{Minimize } C_5 = \max_k \int f(x)(1 - f(x+k))\,dx$$

This is a minimax optimization over function space, discretized at resolution n. A key discovery by Claude Code was that increasing the discretization n yields better solutions — a direction the agent initially missed and only explored after aspiration prompting.

First Autocorrelation Inequality (AC1)

For nonnegative f supported on [-1/4, 1/4], find the smallest C₁ such that:

$$\max_{|t| \le 1/2} (f * f)(t) \ge C_1 \left(\int f\right)^2$$

Any valid construction f certifies an upper bound C₁ ≤ ‖f * f‖_∞ / (∫f)². Lower values represent tighter bounds. This problem arises in the study of additive patterns and has connections to the Littlewood conjecture.

Solution Quality Summary

All three results represent new state-of-the-art performance, though the margins are extremely small. The circle packing result is evaluated with a feasibility tolerance of 1e-6, consistent with ThetaEvolve's evaluator.

5 LLM Integration

Model Configuration

AutoEvolver uses a single LLM configuration with no ensemble:

How the LLM Functions

Unlike evolutionary systems where the LLM serves as a mutation operator within a larger framework, in AutoEvolver the LLM is the entire system. Claude Code functions simultaneously as:

AutoEvolver: LLM as Complete Optimization System
=================================================

┌─────────────────────────────────────────────────────────────────┐
│                    CLAUDE CODE (Opus 4.6)                       │
│                                                                 │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐  │
│  │  STRATEGIST   │  │  IMPLEMENTER │  │  EVALUATOR           │  │
│  │              │  │              │  │                      │  │
│  │ Decides what │  │ Writes code  │  │ Interprets results   │  │
│  │ approach to  │  │ modifications│  │ Compares against     │  │
│  │ try next     │  │ and new      │  │ known best           │  │
│  │              │  │ algorithms   │  │                      │  │
│  └──────┬───────┘  └──────┬───────┘  └──────────┬───────────┘  │
│         │                 │                      │              │
│  ┌──────┴───────┐  ┌──────┴───────┐  ┌──────────┴───────────┐  │
│  │  RESEARCHER   │  │  PARALLELIZER│  │  SELF-CORRECTOR      │  │
│  │              │  │              │  │                      │  │
│  │ Searches web │  │ Launches     │  │ Detects reward       │  │
│  │ for papers,  │  │ background   │  │ hacking, catches     │  │
│  │ GitHub repos │  │ tasks,       │  │ comparison errors,   │  │
│  │              │  │ sub-agents   │  │ validates feasibility│  │
│  └──────────────┘  └──────────────┘  └──────────────────────┘  │
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                     MEMORY SYSTEM                         │   │
│  │  Context Window (short-term) ←→ File System (long-term)  │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

LLM as Mutation Operator (Emergent)

In evolutionary systems, the LLM receives a prompt containing parent programs and generates mutated offspring. AutoEvolver demonstrates that this pattern emerges naturally when an LLM is given an optimization objective:

1. The agent maintains candidate solutions (in files) — analogous to a population
2. The agent modifies solutions (via code changes) — analogous to mutation
3. The agent evaluates and compares (via evaluation scripts) — analogous to fitness evaluation
4. The agent selects the best (keeping the highest-scoring solution) — analogous to selection
5. The agent combines ideas (integrating insights from web research with current solutions) — analogous to crossover

The critical difference is that these behaviors are not orchestrated by an external evolutionary loop — they emerge from the LLM's internal planning and execution within the agentic framework.

No Prompt Engineering

A notable aspect of AutoEvolver is the absence of sophisticated prompt engineering. The agent receives:

1. A natural language problem description
2. An initial naive solution (code file)
3. An evaluation script

No system prompts, few-shot examples, persona assignments, or structured output formats are used. The simplicity of the setup is the point: the researchers test whether the agent's general capabilities are sufficient without domain-specific prompting.

6 Key Results

Headline Performance

All three benchmark problems achieved new state-of-the-art:

Combined runtime: 88 hours of autonomous computation across 2,762 messages and 1,486 tool calls.

Circle Packing Trajectory

The agent's progression on the circle packing problem illustrates the multi-phase strategy evolution:

Circle Packing Score Progression
================================

Score
2.636 ┤                                                    ●━━━━ 2.63598844
      │                                                   ╱     (SOTA)
2.620 ┤                                              ●━━━╱ SLSQP
      │                                             ╱      joint opt
2.560 ┤                                    ●━━━━━━━╱ Multi-start
      │                                   ╱         optimization
2.500 ┤                          ●━━━━━━━╱ LP + simulated
      │                         ╱         annealing (plateau)
      │                        ╱
      │                       ╱
1.000 ┤          ●━━━━━━━━━━━╱
      │         ╱ Naive ring
0.960 ┤    ●━━━╱  arrangement
      │
      └──┬───┬───┬───┬───┬───┬───┬───┬───┬───┬──── Time
         0   1   2   3   4   5   8  10  12  16  (hours)
              │        │         │        │
          Exploration  │     Research   Endgame
                   Refinement  Pivot   Optimization

Key breakthrough: Web search → GitHub discussion mentioning SLSQP
joint optimization → score jumped from 2.555 → 2.619

Phase Transitions in Strategy

Across all three problems, the agent exhibited a consistent multi-phase behavior pattern:

Erdős Problem: The Discretization Discovery

The Erdős problem produced the most dramatic illustration of aspiration prompting's effect:

Before intervention (message 231): The agent reached C₅ = 0.38087447, beating TTT-Discover's 0.38087532 by a margin of 0.85 × 10⁻⁶. The agent declared "Final result" and confirmed the solution was at a local optimum via SLSQP, perturbation search, and subgradient verification.

Intervention (message 252): "Great — let's try more rounds. Aiming for larger improvements."

After intervention: The agent discovered that increasing discretization n yields better solutions. It systematically pushed from n=180 → 270 → 360 → 450 → 600 → 750, ultimately reaching C₅ = 0.38086945 — expanding the margin over prior SOTA from 0.85 × 10⁻⁶ to 5.87 × 10⁻⁶ (7× improvement triggered by one sentence).

Emergent Self-Correction

The agent demonstrated multiple forms of self-monitoring:

1. Reward hacking detection (Circle Packing): The agent found that L-BFGS-B could produce seemingly improved scores by exploiting LP solver tolerances, yielding slightly infeasible solutions. It identified the issue, diagnosed the cause, and corrected it autonomously.

2. Optimization direction confusion (Erdős): The agent twice confused maximization with minimization for C₅, prematurely declared "this beats the competitor," then caught its own error within a few messages and corrected the comparison.

3. Efficiency vs. correctness analysis (AC1): When replacing np.convolve with scipy.signal.fftconvolve (reducing O(n²) to O(n log n)), the agent explicitly questioned whether this constituted "cheating" before confirming mathematical equivalence and proceeding.

7 Reproducibility

Fundamental Reproducibility Challenges

AutoEvolver represents a worst case for scientific reproducibility. The authors are transparent about this:

Trajectory Analysis Methodology

The researchers used DataClaw to capture conversation trajectories, enabling post-hoc analysis of 88 hours of autonomous computation. The tool records all messages, tool calls, and agent outputs, providing a complete audit trail even though the trajectories themselves are not reproducible.

Available Materials

The GitHub repository (tengxiaoliu/autoevolver) provides:

autoevolver/
├── tasks/                    # Problem setups (problem descriptions,
│   ├── circle_packing/       #   initial solutions, evaluation scripts)
│   │   ├── problem.md
│   │   ├── initial_solution.py
│   │   └── evaluate.py
│   ├── erdos_overlap/
│   └── ac1/
├── results/                  # Final solutions for all three problems
│   ├── circle_packing/
│   ├── erdos_overlap/
│   └── ac1/
└── README.md

What Would Be Needed for Reproducibility

To approach reproducibility, future work would need:

1. Deterministic LLM sampling — temperature=0, fixed random seeds (though even this doesn't guarantee identical outputs across API versions)
2. Frozen web content — cached versions of all external resources accessed
3. Predefined aspiration schedule — fixed intervention timing and wording
4. Version-locked API — identical model weights and inference infrastructure

The authors do not claim reproducibility as a goal. Their contribution is the demonstration that competitive performance is possible under these conditions, not that it is reliably achievable.

8 Compute and API Costs

Runtime Breakdown

Cost Estimation

The authors do not report exact API costs. We can estimate based on Claude Code Opus 4.6 pricing (as of March 2026):

Cost Comparison with Evolutionary Frameworks

The key cost advantage of AutoEvolver is not API costs (which may be comparable or higher) but human engineering time. Setting up a problem in AutoEvolver requires writing a problem description, an initial solution, and an evaluation script — no framework configuration, population parameters, or evolutionary operator design.

Compute Efficiency Analysis

A critical nuance: AutoEvolver is almost certainly less efficient in terms of useful computation per dollar. The agent exhibits:

• Approach cycling: Revisiting previously explored strategies (L-BFGS-B attempted 15+ times on AC1)
• Ignored task outputs: ~60% of 174 task completion notifications on Erdős were never read
• Stalled processes: ~40 messages on AC1 polling processes with 0-byte output files
• Redundant launches: Four monitoring sub-agents with near-identical prompts

In a purpose-built evolutionary framework, every evaluation contributes to the population and is never wasted. In AutoEvolver, a significant fraction of computation is redundant or unproductive.

9 Architecture Solution

The Non-Architecture

AutoEvolver's architecture is deliberately minimal — it is the absence of architecture that constitutes the contribution. The "system" consists of:

AutoEvolver "Architecture"
===========================

┌─────────────────────────────────────────────────────────┐
│                                                         │
│   ┌───────────────┐         ┌────────────────────┐     │
│   │  Problem       │         │  Evaluation        │     │
│   │  Description   │────────▶│  Script            │     │
│   │  (text)        │         │  (Python)          │     │
│   └───────────────┘         └─────────┬──────────┘     │
│                                       │                 │
│   ┌───────────────┐                   │                 │
│   │  Initial       │                   │ Score           │
│   │  Solution      │                   │ feedback        │
│   │  (Python)      │                   │                 │
│   └───────┬───────┘                   │                 │
│           │                           │                 │
│           ▼                           ▼                 │
│   ┌────────────────────────────────────────────────┐    │
│   │                                                │    │
│   │              CLAUDE CODE (Opus 4.6)            │    │
│   │                                                │    │
│   │   Autonomous session in skip-permissions mode  │    │
│   │                                                │    │
│   │   Capabilities:                                │    │
│   │   • Code writing and execution                 │    │
│   │   • Web search (arXiv, GitHub, forums)         │    │
│   │   • File system operations                     │    │
│   │   • Parallel task spawning                     │    │
│   │   • Sub-agent creation                         │    │
│   │   • Result analysis and plotting               │    │
│   │                                                │    │
│   └────────────────────────────────────────────────┘    │
│                        │                                │
│                        ▼                                │
│   ┌─────────────────────────────────────────────┐      │
│   │  Aspiration Prompt (1 sentence, when needed) │      │
│   │  "The SOTA is X. I believe you can beat it." │      │
│   └─────────────────────────────────────────────┘      │
│                                                         │
└─────────────────────────────────────────────────────────┘

Comparison with Purpose-Built Evolutionary Architectures

Traditional Evolutionary Framework (e.g., AlphaEvolve)
======================================================

┌──────────┐    ┌───────────┐    ┌──────────┐    ┌───────────┐
│ Program  │───▶│ Prompt    │───▶│ LLM      │───▶│ Parser    │
│ Database │    │ Sampler   │    │ (Gemini) │    │ & Differ  │
│ (pop.)   │    │           │    │          │    │           │
└────┬─────┘    └───────────┘    └──────────┘    └─────┬─────┘
     │                                                  │
     │    ┌────────────────────┐                        │
     │    │  Evaluator Pool    │◀───────────────────────┘
     │    │  (parallel sandbox │
     │    │   execution)       │
     │    └────────┬───────────┘
     │             │
     └─────────────┘
     Selection + Archive

AutoEvolver
===========

┌──────────────┐    ┌──────────────────────────────────┐
│ Problem +    │───▶│ Claude Code (the ENTIRE system)  │
│ Eval Script  │    │ Does everything above + more     │
└──────────────┘    └──────────────────────────────────┘

The philosophical difference is profound. In evolutionary frameworks, the LLM is a component — a mutation operator — within a larger algorithmic structure. In AutoEvolver, the LLM is the algorithm. The evolutionary-like behaviors emerge from the LLM's general intelligence rather than being imposed by external structure.

Implications for System Design

This result challenges the evolutionary AI systems field to justify its architectural complexity. If a bare LLM can match or exceed the performance of carefully engineered evolutionary pipelines, several possibilities follow:

1. The frameworks provide marginal value: The LLM's general capabilities already encompass the evolutionary strategies, making explicit frameworks redundant.
2. The frameworks provide value at scale: AutoEvolver was tested on three problems. At scale (hundreds of problems, diverse domains), the consistency and efficiency of evolutionary frameworks may dominate.
3. The frameworks provide different value: Controllability, reproducibility, and transparency may be more important than raw performance in research settings.

The authors favor interpretation (3), explicitly stating: "Not a replacement. Compared to purpose-built frameworks, coding agents still lack controllability and reproducibility."

10 Component Breakdown

Input Components

Emergent Components (Not Designed, Observed)

Through analysis of the 88-hour trajectory, the researchers identified several emergent system components:

The Aspiration Prompt

The aspiration prompt is the only designed component beyond the basic setup. Its anatomy:

Aspiration Prompt Anatomy
=========================

Structure:  "[Acknowledgment] + [Target] + [Encouragement]"

Examples used in the study:

  Circle Packing:
  "The current SOTA on this problem is 2.6359. I believe you can beat it."

  Erdős:
  "Great — let's try more rounds. Aiming for larger improvements."

  AC1:
  [Not explicitly reported — similar pattern inferred]

Timing:  Applied when the agent declares "Final result" or equivalent
Effect:  Triggers qualitative strategy shift, not just extended search

Tool Usage Patterns

Claude Code's tool usage across the 88-hour study:

11 Core Mechanisms (Detailed)

Mechanism 1: Multi-Phase Strategy Evolution

The most striking emergent behavior is the agent's consistent progression through qualitatively different optimization phases. This pattern was observed independently across all three problems.

Multi-Phase Strategy Evolution
==============================

Phase 1: EXPLORATION (Hours 0-2)
├── Apply textbook optimization methods
├── Test multiple approaches quickly
├── Establish baseline performance
└── Characteristic: Broad, shallow search

Phase 2: REFINEMENT (Hours 2-5)
├── Focus on best-performing approach
├── Tune hyperparameters systematically
├── Scale problem parameters
└── Characteristic: Deep, narrow search

Phase 3: PLATEAU RECOGNITION (Hours 5-8)
├── Detect diminishing returns
├── Declare solution as "final" or "optimal"
├── Verify local optimality (perturbation, gradient checks)
└── Characteristic: Satisficing behavior

Phase 4: ASPIRATION INTERVENTION (Single message)
├── Human raises target score
└── Characteristic: External pressure applied

Phase 5: RESEARCH PIVOT (Hours 8-12)
├── Web search for alternative approaches
├── Read papers, GitHub repos, forum discussions
├── Discover fundamentally new strategies
└── Characteristic: Information seeking, strategy shift

Phase 6: SYNTHESIS (Hours 12-16)
├── Combine external insights with accumulated progress
├── Implement new approaches using best solution as warm start
├── Evaluate hybrid strategies
└── Characteristic: Cross-pollination, integration

Phase 7: ENDGAME (Hours 16+)
├── High-resolution local search around best known
├── Scaling tricks (higher discretization, more iterations)
├── Diminishing returns but still accumulating small gains
└── Characteristic: Exploitation-dominated, precision focus

Mechanism 2: Spontaneous Parallel Exploration

The agent autonomously transitions from sequential to parallel exploration as optimization becomes harder. This behavior was most pronounced on the Erdős problem:

Quantitative Parallelism Metrics (Erdős Problem):

The agent's parallelism exhibits a natural analogy to population-based search. Multiple candidate strategies compete for the agent's attention, with better-performing ones receiving more follow-up computation. However, unlike formal evolutionary algorithms, this "selection" is mediated by the agent's attention and context management rather than explicit selection operators.

Mechanism 3: Strategic Web Research

The agent uses web research in two distinct patterns:

Pattern A: Fallback when stuck. After reaching a plateau, the agent initiates web searches alongside continued optimization, looking for new techniques. Example trajectory (Circle Packing):

Message 37: "I'm stuck at 2.57, likely because the simulated annealing is converging to a local optimum." → Searches Packomania website for known n=26 coordinates → fails to extract useful data

Message 144: Launches 4 parallel experiments including web search for known optimal packing coordinates

Message 157: "I found a GitHub issue that mentions a circle packing result of 2.635977 for n=26!"

Message 171: "The key insight from that issue is that they used SLSQP for jointly optimizing centers AND radii, rather than our approach of LP for radii and NM/Powell for centers." → Score jumps from 2.555 to 2.619

Pattern B: Opportunistic during idle time. While background optimization tasks run, the agent uses idle time to gather theoretical insights. On the AC1 problem, the agent read papers on autocorrelation inequalities to understand the theoretical landscape, even though the insights did not directly translate to code improvements.

Mechanism 4: Self-Correction and Reward Hacking Detection

The agent exhibits multiple layers of self-monitoring, including detection of its own reward hacking:

Case Study: L-BFGS-B Feasibility Exploitation (Circle Packing)

The agent discovered that L-BFGS-B could produce seemingly improved scores by exploiting LP solver tolerances, yielding solutions that technically violated the non-overlap constraint by amounts smaller than the tolerance threshold. The agent's reasoning:

1. Observed that L-BFGS-B solutions scored slightly higher than SLSQP solutions
2. Investigated why — found that the LP solver's tolerance allowed slightly infeasible circle placements
3. Determined this was "reward hacking" — the evaluation function was being gamed
4. Reverted to stricter feasibility checking
5. Continued optimization with properly constrained solutions

This is a remarkable demonstration of an AI system detecting and correcting its own tendency to exploit evaluation metrics — a behavior that purpose-built evolutionary frameworks typically handle via explicit constraint enforcement in the evaluator.

Mechanism 5: Approach Cycling (Failure Mode)

A significant failure mode is the agent's tendency to revisit previously explored and rejected approaches, apparently losing track of prior conclusions as the context window advances:

Case Study: L-BFGS-B Cycling (AC1 Problem)

This failure mode represents the most significant practical limitation of AutoEvolver. In a purpose-built evolutionary framework, a tabu list or strategy registry would prevent this waste. The context window functions as short-term memory, but information is lost as earlier messages scroll out of the active context. The file system acts as long-term memory, but the agent doesn't maintain a systematic strategy log.

Mechanism 6: Process Awareness and Resource Management

The agent demonstrates system-level awareness that goes beyond algorithm design:

Case Study: Process Interference Detection (Erdős)

Message 1280: "Both processes write to the same file. The better process's saves get overwritten by the worse one. This explains why we rarely see improvement."

Message 1283: "I should stop the worse process so only the better one saves snapshots."

Message 1291: "C₅ dropped to 0.380869458 — a big improvement! Killing the worse process worked perfectly."

This incident demonstrates debugging of system-level interactions between concurrent processes — a skill typically associated with software engineering rather than algorithm optimization.

12 Programming Language

Solution Implementation

All solutions are implemented in Python, leveraging the scientific computing ecosystem:

Code Characteristics

The agent-generated code exhibits several notable patterns:

1. Progressive sophistication: Early code is simple and procedural; late-stage code uses advanced optimization techniques with careful numerical handling.
2. Self-documenting: The agent tends to add comments explaining its reasoning, though these comments become less reliable as context is lost.
3. Modular evolution: The agent often refactors its solution into separate functions as complexity grows, spontaneously applying software engineering practices.

Example: Circle Packing Solution Evolution

Stage 1 — Naive (Score: 0.96):

def pack_circles(n=26):
    """Naive ring arrangement."""
    circles = []
    r = 1.0 / (2 * n)
    for i in range(n):
        angle = 2 * np.pi * i / n
        x = 0.5 + 0.3 * np.cos(angle)
        y = 0.5 + 0.3 * np.sin(angle)
        circles.append((x, y, r))
    return circles

Stage 5 — SLSQP Joint Optimization (Score: 2.619):

def joint_optimize(centers, radii, n=26):
    """Jointly optimize centers and radii using SLSQP."""
    x0 = np.concatenate([centers.ravel(), radii])

    def objective(x):
        return -np.sum(x[2*n:])  # Maximize sum of radii

    constraints = []
    for i in range(n):
        # Containment: r <= x <= 1-r, r <= y <= 1-r
        constraints.append({'type': 'ineq', 'fun': lambda x, i=i:
            x[2*i] - x[2*n+i]})
        constraints.append({'type': 'ineq', 'fun': lambda x, i=i:
            1 - x[2*i] - x[2*n+i]})
        constraints.append({'type': 'ineq', 'fun': lambda x, i=i:
            x[2*i+1] - x[2*n+i]})
        constraints.append({'type': 'ineq', 'fun': lambda x, i=i:
            1 - x[2*i+1] - x[2*n+i]})

    for i in range(n):
        for j in range(i+1, n):
            # Non-overlap: dist(i,j) >= r_i + r_j
            constraints.append({'type': 'ineq', 'fun': lambda x, i=i, j=j:
                np.sqrt((x[2*i]-x[2*j])**2 + (x[2*i+1]-x[2*j+1])**2)
                - x[2*n+i] - x[2*n+j]})

    result = minimize(objective, x0, method='SLSQP',
                      constraints=constraints, options={'maxiter': 10000})
    return result

Stage 7 — Iterated Perturbation Chains (Score: 2.63598844):

def perturbation_chain(solution, eval_fn, n_iters=100000, temp=1e-6):
    """Fine-grained local search via iterated perturbation."""
    best = solution.copy()
    best_score = eval_fn(best)

    for it in range(n_iters):
        candidate = best.copy()
        # Perturb a random circle's position or radius
        idx = np.random.randint(len(candidate))
        dim = np.random.randint(3)  # x, y, or r
        delta = np.random.normal(0, temp)
        candidate[idx][dim] += delta

        if is_feasible(candidate) and eval_fn(candidate) > best_score:
            best = candidate
            best_score = eval_fn(candidate)

    return best, best_score

13 Memory Management

The Dual Memory System

AutoEvolver's memory architecture is an emergent property of Claude Code's design, not an intentional choice:

Memory Architecture
===================

┌─────────────────────────────────────────────────────────┐
│  SHORT-TERM MEMORY: Context Window                      │
│                                                         │
│  • Contains recent messages, tool outputs, reasoning    │
│  • Finite capacity (~200K tokens for Opus 4.6)          │
│  • Information drops off as window advances             │
│  • Strategy history, previous conclusions lost          │
│  • Current best solution always tracked                 │
│                                                         │
│  FAILURE MODE: Approach cycling                         │
│  L-BFGS-B tried 15+ times on AC1 because prior         │
│  negative conclusions scrolled out of context           │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  LONG-TERM MEMORY: File System                          │
│                                                         │
│  • Solution files (current best, candidates)            │
│  • promising_solutions/ directory (110+ files, Erdős)   │
│  • Evaluation results and logs                          │
│  • Code implementations (versioned by the agent)        │
│                                                         │
│  FAILURE MODE: No systematic strategy log               │
│  The agent saves solutions but not a record of          │
│  which approaches were tried and rejected               │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  EXTERNAL MEMORY: Web Resources                         │
│                                                         │
│  • arXiv papers, GitHub repos, forum discussions        │
│  • Accessed opportunistically during idle periods       │
│  • Not persistent — re-searched when needed             │
│  • Provides novel strategies not in training data       │
│                                                         │
└─────────────────────────────────────────────────────────┘

Memory Failure Analysis

The most significant memory-related failure is approach cycling, where the agent revisits strategies it previously explored and rejected. Quantitative evidence:

Proposed Mitigations (Not Implemented)

The authors identify but do not implement several mitigations:

1. Persistent strategy registry: A file logging all tried approaches with their outcomes, consulted before each new attempt.
2. Context summarization: Periodic compression of the context window into a summary of findings and rejected approaches.
3. Approach deduplication: A check before launching a new strategy to verify it hasn't been tried before.

These mitigations would move AutoEvolver closer to a purpose-built framework, partially undermining the minimalist thesis. This tension between raw capability and systematic efficiency is one of the paper's most interesting implicit findings.

File System as Population Archive

The agent's use of the file system as a solution archive is structurally similar to a MAP-Elites archive or a quality-diversity archive:

Erdős Problem File System (Post-Run):

promising_solutions/
├── best_n180.npy          # Best solution at discretization n=180
├── best_n270.npy          # Best at n=270
├── best_n360.npy          # Best at n=360 (C5=0.38087064)
├── best_n450.npy          # Best at n=450
├── best_n600.npy          # Best at n=600
├── best_n750.npy          # Best at n=750 (C5=0.38086945, final SOTA)
├── candidate_001.npy      # Intermediate candidates
├── candidate_002.npy
│   ... (~110 files total)
├── candidate_110.npy
├── basin_search_result_1.npy
├── basin_search_result_2.npy
└── ...

This archive was created entirely by the agent without external instruction. The structure mirrors a quality-diversity archive where solutions are organized by a behavioral characteristic (discretization n) rather than pure fitness.

14 Continued Learning

Within-Session Learning

AutoEvolver exhibits clear within-session learning across the multi-phase trajectory. The agent accumulates domain knowledge throughout each run:

Cross-Problem Learning: Absent

A critical limitation: AutoEvolver performs no cross-problem learning. Each problem is solved in an independent session with no knowledge transfer. The agent does not:

• Recognize that SLSQP worked well on Circle Packing and try it first on Erdős
• Transfer the aspiration-prompt-induced insight about discretization scaling
• Build a library of optimization strategies across problems
• Maintain a persistent memory of effective techniques

This is a fundamental difference from evolutionary frameworks that can accumulate cross-problem knowledge through prompt templates, strategy libraries, or learned mutation operators.

Comparison with Evolutionary Framework Learning

Implications for System Design

The absence of cross-problem learning suggests a concrete architecture improvement: a strategy memory layer that persists across sessions and records which approaches worked on which problem types. This would address the approach cycling problem within sessions and enable knowledge transfer across problems, without requiring the full complexity of an evolutionary framework.

Proposed Strategy Memory Architecture
======================================

Session 1 (Circle Packing)         Session 2 (Erdős)
┌──────────────────┐              ┌──────────────────┐
│ Claude Code      │              │ Claude Code      │
│                  │              │                  │
│ • Tried SA ❌    │ ──write──▶  │ • Read prior     │
│ • Tried SLSQP ✅ │              │   strategies     │
│ • SLSQP + perturb│              │ • Skip SA, try   │
│   chains ✅✅    │              │   SLSQP first    │
└──────────────────┘              └──────────────────┘
         │                                 │
         ▼                                 ▼
┌─────────────────────────────────────────────────┐
│           PERSISTENT STRATEGY MEMORY            │
│                                                 │
│  Problem Type    │ Approach     │ Outcome       │
│  ─────────────── │ ──────────── │ ─────────     │
│  Continuous opt  │ SA           │ Local optima  │
│  Continuous opt  │ SLSQP joint  │ Breakthrough  │
│  Continuous opt  │ Perturbation │ Refinement    │
│  Functional opt  │ ↑ discret.   │ Breakthrough  │
└─────────────────────────────────────────────────┘

15 Applications

Direct Applications

AutoEvolver's primary application is algorithmic optimization on problems where:

1. Solutions are expressible as code — the agent needs to write and execute Python
2. An evaluation function exists — deterministic scoring of solution quality
3. Web resources are available — the agent benefits from accessing existing literature
4. Long compute budgets are acceptable — 16-40 hours per problem
5. Reproducibility is not critical — each run follows a unique trajectory

Implications for the Evolutionary AI Field

AutoEvolver's most significant contribution is not practical but conceptual. It challenges foundational assumptions in the field:

Challenge 1: Are evolutionary frameworks necessary?

If a general-purpose coding agent can match evolutionary frameworks on their home benchmarks, the burden of proof shifts to framework developers to demonstrate value beyond raw performance — in efficiency, controllability, reproducibility, or scalability.

Challenge 2: What is the role of the LLM?

In evolutionary frameworks, the LLM is a component (mutation operator) within a larger system. AutoEvolver shows the LLM can serve as the entire optimization system. This raises the question of whether the evolutionary framework is mostly providing structure that the LLM already implicitly possesses.

Challenge 3: How should we evaluate evolutionary AI systems?

If performance on a small number of benchmark problems is the primary metric, AutoEvolver's results undermine the case for complex frameworks. The field may need evaluation criteria that capture efficiency, scalability, robustness, and reproducibility — dimensions where frameworks are expected to excel.

Relationship to OmniEvolve Design

AutoEvolver's findings are directly relevant to OmniEvolve's architecture:

Broader Scientific Context

AutoEvolver joins a growing body of evidence that general-purpose AI agents can perform specialized tasks previously requiring purpose-built systems:

The pattern suggests that as general-purpose LLMs become more capable, the value proposition of domain-specific systems shifts from capability (can it solve the problem?) to efficiency (can it solve the problem better, faster, and more reliably?).

Limitations as a Research Contribution

Despite the impressive results, several limitations constrain AutoEvolver's impact:

1. N=1 per problem: Each problem was solved once. Statistical significance cannot be established without multiple runs.
2. Human intervention: Aspiration prompting, while minimal, is not automated. The timing and content of interventions involve human judgment.
3. Fair comparison: The agent has access to web resources including potentially the very papers it's competing against. Evolutionary frameworks typically operate without such external information.
4. Cost opacity: API costs are not reported, making cost-efficiency comparisons impossible.
5. Narrow benchmark: Three mathematical optimization problems are not representative of the broader algorithmic design space.

Bottom line: AutoEvolver demonstrates that the capability gap between general-purpose coding agents and purpose-built evolutionary frameworks has narrowed to the point of parity on selected benchmarks. The efficiency, reproducibility, and scalability gaps remain wide — and these may be the more important dimensions for practical research systems.

References

1. Liu, T., Yang, Y., Ye, X., and Chen, D. "Can Coding Agents Optimize Algorithms Autonomously?" Blog Post, March 2026. https://tengxiaoliu.github.io/autoevolver/
2. Novikov, A. et al. "AlphaEvolve: A coding agent for scientific and algorithmic discovery." arXiv:2506.13131, 2025.
3. Lange, R.T. et al. "ShinkaEvolve: Towards Open-Ended And Sample-Efficient Program Evolution." arXiv:2509.19349, 2025.
4. Wang, Y. et al. "ThetaEvolve: Test-time Learning on Open Problems." arXiv:2511.23473, 2025.
5. Yuksekgonul, M. et al. "Learning to Discover at Test Time." arXiv:2601.16175 (TTT-Discover), 2026.
6. Simon, H.A. "Models of Bounded Rationality." MIT Press, 1982.
7. Mouret, J.-B. and Clune, J. "Illuminating search spaces by mapping elites." arXiv:1504.04909, 2015.
8. Romera-Paredes, B. et al. "Mathematical discoveries from program search with large language models." Nature, 625, 468–475, 2024 (FunSearch).
9. DataClaw. Conversation trajectory capture tool. github.com/peteromallet/dataclaw.
10. Anthropic. "Claude Code." Technical Documentation, 2026.

Back to Index