AlphaEvolve evolves whole files, not one function, scored by a cascade of cheap-to-expensive tests, generalizing FunSearch's single-function loop to frontier-model, multi-objective evolution.
lane: program loop · Novikov et al., "AlphaEvolve: A coding agent for scientific and algorithmic discovery," arXiv:2506.13131 (submitted 2025-06-16; announced by DeepMind 2025-05-14), Google DeepMind
Gives. Cheap tests first, hours-long tests last, over whole files from a fast-plus-frontier model pair with full problem context.
Needs. An automated evaluator; without one the method does not exist.
Breaks. Excludes most natural science that cannot be simulated; discovered programs ran out of memory past 5x5x5.
FunSearch's own paper frames the comparison (Table 1, Sec. 1). FunSearch evolves a single function of 10-20 lines. It needs an evaluator that returns in 20 minutes or less on one CPU. It samples millions of times from a small code-specialized LLM with minimal context, and optimizes one metric. AlphaEvolve evolves whole files of hundreds of lines in any language. It tolerates evaluations that run for hours in parallel, sometimes about 100 compute-hours per candidate (Sec. 2.4). It draws thousands of samples from an ensemble of two models: Gemini Flash for throughput and Gemini Pro for occasional higher-quality jumps. It accepts rich natural-language context in the prompt and optimizes multiple objectives at once. Section 5 names three ways AlphaEvolve goes beyond FunSearch. It uses whole codebases instead of one function, multi-objective scoring instead of single-objective, and frontier LLMs with richer context instead of a narrow code model with minimal context.
1. Propose: a prompt sampler (Sec. 2.2) builds prompts from the program database. It includes explicit problem context, stochastically formatted, plus rendered evaluation results from prior attempts. "Meta-prompt evolution" lets the LLM co-evolve its own instruction templates. The Flash/Pro ensemble (Sec. 2.3) generates code diffs against the current best program, not full rewrites. 2. Judge: an evaluation cascade (Sec. 2.4) runs candidates through test-case ensembles of increasing difficulty and cost. A candidate must clear cheap, small-scale checks before promotion to expensive, exact evaluation. The cascade can add optional LLM-graded properties, such as code simplicity, as auxiliary scores or use them to discard candidates outright. 3. Keep: an evolutionary database (Sec. 2.5) combines MAP-elites with an island-based population model, the FunSearch lineage component, to balance exploration against exploitation. Promising programs register back into the database and become future prompt material. 4. Infrastructure: an asynchronous pipeline, Sec. 2.6, with a controller, LLM samplers, and evaluation nodes, targets throughput explicitly over per-call latency.
As with FunSearch, nothing in the core loop is continuous. Code generation, diff application, and evaluation are all discrete operations. The evaluation cascade's scalar and vector scores are the only signal crossing into the next round of prompt construction. The paper reports one partially-continuous element, in the matrix-multiplication results: a rounding step snaps discovered tensor decompositions to exact integers or half-integers after the fact (Sec. 3.1). That is a post-hoc continuous-to-discrete cleanup step, not a gradient inside the search.
The authors state the binding constraint directly (Sec. 6): "The main limitation of AlphaEvolve is that it handles problems for which it is possible to devise an automated evaluator." They flag the natural sciences as a domain where "only some experiments can be simulated or automated." The framework supports LLM-provided evaluation, but it is "not a setting we have optimized for." Per-candidate evaluation cost can reach roughly 100 compute-hours (Sec. 2.4). AlphaEvolve therefore trades raw iteration count, FunSearch's millions of cheap calls, for far fewer, far more expensive, higher-information evaluations per candidate. That is the opposite scaling bet from FunSearch. The authors describe current absolute gains as "moderate." They note the feedback loop for improving AlphaEvolve itself between versions takes "on the order of months" (Sec. 6).
1. Memory limits break scaling of discovered programs: Appendix A reports that running discovered matrix-multiplication programs beyond the ⟨5,5,5⟩ tensor size, on 1000 random seeds using a single GPU, frequently ran out of memory. The discovered algorithms themselves did not scale cleanly without further engineering. 2. Evaluator dependency is the paper's own stated ceiling (Sec. 6): any domain without a cheap or constructible automated evaluator is out of scope. The authors admit this excludes most natural-science experiments that cannot be simulated. 3. Slow outer-loop improvement: the authors state the feedback cycle for improving AlphaEvolve's own method takes "on the order of months" (Sec. 6). This is a meta-level bottleneck independent of any single task. 4. No official code release: this research found no primary DeepMind repository. All open implementations, OpenEvolve and ShinkaEvolve, are unofficial reconstructions from the paper. Readers cannot check any result above against the authors' original code, only against the paper's stated numbers. 5. Reproduction gap, even where closest: OpenEvolve's own best reported circle-packing reproduction, 2.634, does not exactly match the paper's figure of 2.635. The blog post does not report final numbers for its second worked example, function minimization, leaving that reproduction incomplete by the author's own account. 6. AlphaResearch's comparison claims are UNVERIFIED in this research: WebSearch synthesis reports arXiv:2511.08522 claims to beat OpenEvolve on four open-ended problems, and ShinkaEvolve on three of four, within 1,000 iterations. WebFetch could not extract the PDF's body text — only scaffolding and metadata were readable. These specific numbers are unconfirmed leads, not independently verified citations.
Sec. 1 and Sec. 5 explicitly position AlphaEvolve as DeepMind's direct generalization of FunSearch. It keeps the islands/MAP-elites population model and the propose-evaluate-keep loop structure. But it replaces FunSearch's single-function skeleton with whole-file and whole-codebase diffs, its single small code LLM with a Flash/Pro ensemble, and its single-metric scoring with a multi-stage, multi-objective evaluation cascade. Two 2025-2026 open-source projects reconstruct AlphaEvolve's method independently downstream: OpenEvolve, a community, informal reimplementation blog, and ShinkaEvolve, Sakana AI, arXiv:2509.19349. ShinkaEvolve claims better sample efficiency and reports outperforming AlphaEvolve's own circle-packing solution — UNVERIFIED beyond the WebSearch snippet, full text not opened this session. AlphaResearch, arXiv:2511.08522, in turn benchmarks itself against both of those reconstructions.
Verified: WebFetch on full arXiv HTML (https://arxiv.org/html/2506.13131), three passes covering offset 0-100000 (Sec. 1-3, Table 1, Table 2), offset 60000-160000 (Sec. 4 ablations, Sec. 6 discussion/limitations), and offset 95000+ (Appendix B math results table); WebFetch on OpenEvolve HuggingFace blog post; WebSearch extended for reproductions/critiques (OpenEvolve, ShinkaEvolve, AlphaResearch arXiv:2511.08522 — AlphaResearch's own body text could not be extracted from its PDF, so its comparison numbers are UNVERIFIED, taken only from WebSearch's synthesis). · code: no official release found; community reimplementations OpenEvolve (github.com/codelion/openevolve) and Sakana AI's ShinkaEvolve (github.com/SakanaAI/shinkaevolve, arXiv:2509.19349)