AlphaEvolve — Evolutionary Coding Agents
Pair a frontier coding model with an evolutionary loop and a machine-checkable evaluator, then let it run. AlphaEvolve found a 4x4 complex-matrix multiplication procedure that uses 48 scalar multiplications, the first improvement over Strassen in 56 years. It also found a Borg scheduling heuristic that recovers ~0.7% of Google's cluster compute in production. The architecture is boring on purpose. The wins come from the evaluator's rigor.
Learning Objectives
- Describe the AlphaEvolve loop: a seed program, a program database, an LLM proposer, and a machine-checkable evaluator.
- Explain why pairing an LLM with evolutionary search beats using either technique alone.
- Explain how reward hacking arises when an evaluator has a gap, and why a held-out evaluator with inputs generated at evaluation time is the fix.
- Run the toy evolutionary loop with and without held-out test points, and quantify the resulting overfitting.
- Judge whether a new domain has an evaluator rigorous enough to support an AlphaEvolve-style search.
The Problem
Large language models can write code, and evolutionary algorithms can search over code. Each has been tried alone for decades and each hits a ceiling. The LLM ceiling is confabulation: the model writes plausible code that does not do what it claims. The evolutionary ceiling is search cost, because random mutations over syntax rarely produce a program that compiles, let alone one that scores better.
AlphaEvolve (Novikov et al., DeepMind, arXiv:2506.13131, June 2025) combines the two. The LLM proposes targeted edits to programs in a database, an automatic evaluator scores each variant, and high-scoring variants become parents for the next generation. The LLM does the expensive part, writing plausible code. The evaluator catches the confabulations. The loop runs for hours to weeks.
Results reported: 48-scalar-multiplication 4x4 complex matrix multiplication (Strassen's 1969 bound was 49), a Borg scheduling heuristic in Google production, a 32.5% FlashAttention kernel speedup, and Gemini training throughput improvements.
The architecture works because the evaluator is machine-checkable, and it does not work where the evaluator isn't. That asymmetry is the core idea.
The Concept
The loop
- Start from a seed program
P_0that is correct but suboptimal. - Maintain a database of variant programs, each scored by the evaluator.
- Sample one or more parents from the database (MAP-elites-style or island-based).
- Prompt the LLM (Gemini Flash for many candidates, Gemini Pro for the hard ones) to produce a modified variant of the parent.
- Compile, run, and evaluate the variant on the held-out evaluator.
- Insert into the database keyed by its score and feature vector.
- Repeat.
Two details matter. First, the LLM sees more than the parent program: typically several top variants from the database, the evaluator signature, and a short task description. Its job is to propose a targeted change that might improve the score. Second, the database is structured (MAP-elites grid, island-based) so the loop explores diversity and not just the current leader.
What makes the evaluator non-negotiable
The reported wins come from domains where the evaluator is fast, deterministic, and hard to game:
- Matrix multiplication algorithm: a unit test that multiplies matrices and checks equality bit-identically.
- Borg scheduling heuristic: a production-grade simulator that replays historical cluster load and measures wasted compute.
- FlashAttention kernel: a correctness test plus a wall-clock benchmark on real hardware.
- Gemini training throughput: measured GPU-seconds per step.
In each case the evaluator catches the LLM errors that would otherwise dominate: confabulated correctness claims, performance claims that vanish on hardware, and edge-case failures. Remove it and the loop optimizes for pretty code.
Reward hacking is the other face of that statement
Evolution optimizes whatever the evaluator measures. If the evaluator has a gap, the loop will find it, and in an unverified domain it optimizes the surface feature instead of the intended behavior. DeepMind flags this in the paper: AlphaEvolve's successes transfer only to domains where evaluator rigor matches the ambition of the search.
Concrete 2025-2026 examples of reward hacking in code-search loops:
- Optimization targets that reward "time to complete" rewarded submitting empty solutions.
- Benchmark scores that reward correctness-under-test rewarded memorizing tests and overfitting.
- A "code quality" proxy rewarded removing comments and rewriting variable names, with no semantic change.
The fix in AlphaEvolve is a held-out evaluator the LLM has not seen, with inputs generated at evaluation time. Even then, DeepMind recommends strong review before deploying anything the loop proposes.
Why LLM + search beats either alone
The LLM can produce compilable, semantically plausible modifications. A random-mutation GA on a 2000-line Python file almost always produces syntax errors. The LLM also concentrates search on plausible neighborhoods (change one function, not random bytes), which dramatically reduces wasted evaluator calls.
The evaluator, in turn, catches the LLM's confabulations. An LLM will confidently claim that a function "is O(n log n) in the limit" when it is actually O(n^2). A wall-clock benchmark settles the question.
Where AlphaEvolve fits in the frontier stack
| System | Generator | Evaluator | Domain | Example win |
|---|---|---|---|---|
| AlphaEvolve | Gemini | correctness + benchmark | algorithms, kernels, schedulers | 48-mul 4x4 matmul |
| FunSearch (DeepMind, 2023) | PaLM / Codey | correctness | combinatorial math | cap-set lower bounds |
| AI Scientist v2 (Sakana, L5) | GPT/Claude | LLM critique + experiment | ML research | ICLR workshop paper |
| Darwin Godel Machine (L4) | agent scaffolding | SWE-bench / Polyglot | agent code | 20% → 50% SWE-bench |
All four follow the same recipe: a generator, an evaluator, and a loop. They differ in what the evaluator grades and how rigorous it is.
Use It
code/main.py implements a minimal AlphaEvolve-like loop over a toy symbolic-regression problem. The "LLM" is a stdlib stand-in that proposes small random mutations to an expression tree, and the target is 2x^2 + 3x - 1. The "evaluator" measures mean squared error on train and test points.
Watch:
- How the best train score improves over generations in Run A.
- How a MAP-elites grid keeps diverse candidates alive so the loop doesn't settle on the first local minimum.
- What happens to the test error in Run B, where the evaluator sees training points only. Pass
--no-holdoutto skip Run A and run just that one.
Ship It
outputs/skill-evaluator-rigor-audit.md is the precondition for considering an AlphaEvolve-style loop in a new domain: does your evaluator actually catch the failures you care about?
I'd run main.py before reading anything else and compare the two runs side by side. Run A scores each candidate on the mean of its train and test error, and Run B scores on train error alone. Both use the same seed, a population of 20, and 1500 generations, so the evaluator is the only thing that changes. With the default seed, Run A ends on 2x^2 + x + x + x - 1, which is the target written the long way, while Run B finishes with a test error well above its train error.
One caveat on the toy. The test points are a fixed list, not inputs generated at evaluation time, and Run A feeds them into the selection signal. That makes them a validation set the search can see, so the guard here is weaker than the held-out evaluator described above. In a real loop I'd generate fresh inputs per evaluation and keep a final set the search never touches.
I'd also keep in mind that the mutation step is random, with no model behind it. The toy exercises the evaluator and the archive. It says nothing about how well an LLM proposes edits. The archive is keyed on expression depth and the largest constant, a descriptor you will want to replace in exercise 2.
Exercises
-
Run
code/main.py. Note the best score trajectory. Disable the held-out evaluator (flag--no-holdout) and re-run. Quantify the overfitting. -
Read Section 3 of the AlphaEvolve paper on the MAP-elites grid. Design a feature-vector descriptor for a new problem (e.g. compiler optimization passes) that would keep the search diverse.
-
The 48-multiplication 4x4 result improved on Strassen's 49-mul bound after 56 years. Read Appendix F of the paper and explain in three sentences why the evaluator for this problem is particularly easy to get right, and why most domains are not like it.
-
Propose one domain where AlphaEvolve would fail. Identify exactly where the evaluator breaks and why.
-
For a domain you know, write the evaluator signature you would use. Include (a) correctness conditions, (b) performance metric, (c) held-out input generation rule, (d) at least one anti-reward-hacking check.
Key Terms
| Term | What people say | What it actually means |
|---|---|---|
| AlphaEvolve | "DeepMind's evolutionary coding agent" | Gemini + program database + machine-checkable evaluator |
| MAP-elites | "Diversity-preserving archive" | Grid keyed by feature vectors; each cell holds the best variant with that descriptor |
| Island model | "Parallel evolution subpopulations" | Independent populations that migrate periodically; prevents premature convergence |
| Machine-checkable evaluator | "Deterministic oracle" | A unit test, simulator, or benchmark the LLM cannot fake, a prerequisite for this loop |
| Reward hacking | "Optimizing the measure, not the goal" | Loop finds a way to maximize score without doing the intended task |
| Seed program | "The starting point" | An initial correct-but-suboptimal program the loop evolves from |
| Held-out evaluator | "Evaluation data the LLM never saw" | Inputs generated at evaluation time to prevent memorization |
Further Reading
- Novikov et al. (2025). AlphaEvolve: A coding agent for scientific and algorithmic discovery: the full paper.
- DeepMind blog on AlphaEvolve: vendor writeup with results.
- AlphaEvolve results repository: discovered algorithms, including the 48-mul 4x4 matmul.
- Romera-Paredes et al. (2023). Mathematical discoveries from program search with LLMs (FunSearch): the predecessor system.
- Anthropic: Responsible Scaling Policy v3.0 (Feb 2026): frames evaluator-bound autonomy as a key research direction.
Code
- main.py (python, 224 lines)