AlphaEvolve and LLM-Guided Evolution

Genetic programming has always had a problem with mutation. A random change to a program, whether a swapped subtree or an edited character, usually breaks it, and a change that improves it is rare. Much of the field's work on representations has been an effort to make random variation of programs less destructive. Large language models (LLMs) trained on code offer a different answer: a mutation operator that has read a great deal of code, proposes changes that usually run, and can be told in plain language what to try.

Three systems built on that idea between 2022 and 2025. Evolution through large models (ELM) showed that a code model could serve as the mutation operator in a quality-diversity search. FunSearch paired a code model with an automated evaluator and an island-model database and found new results in combinatorics. AlphaEvolve scaled the approach to whole files, frontier models and problems at Google. This article describes each, states AlphaEvolve's reported results as the paper gives them, and asks what is evolutionary about these systems and what is not.

The loop

All three systems run the same cycle, shown here in AlphaEvolve's form (Novikov et al., 2025, Fig. 2):

1. Sample a parent program, and some other programs as inspiration, from a database of evaluated programs.
2. Prompt a language model with them, their scores, and instructions to propose an improvement.
3. Apply the model's output to the parent to get a child program.
4. Evaluate the child with an automated evaluator that returns one or more scores.
5. Store the child and its scores in the database.

Steps 1, 4 and 5 are an evolutionary algorithm: a population, selection biased toward good scores, and heritable variation. Steps 2 and 3 are the variation operator. A tree-based GP system would replace them with subtree crossover and point mutation. Here they are replaced by a model that reads the parent and writes a modified version.

The paper gives the controller loop as six lines of pseudocode (Novikov et al., 2025, Fig. 2), which make the correspondence exact:

parent_program, inspirations = database.sample()
prompt = prompt_sampler.build(parent_program, inspirations)
diff = llm.generate(prompt)
child_program = apply_diff(parent_program, diff)
results = evaluator.execute(child_program)
database.add(child_program, results)

Read as a genetic algorithm, database.sample is parent selection, the next three lines are mutation, evaluator.execute is the fitness function, and database.add is where survivor selection takes place (the paper does not say whether, or how, programs are ever removed). The inspirations are the one part with no standard counterpart: they are other programs placed in the prompt so that the model can borrow from them, which makes the operator closer to a many-parent recombination than to mutation of one parent.

Evolution through large models

Lehman, Gordon, Jain, Ndousse, Yeh and Stanley (2022) argued that a language model trained on code changes approximates the changes a human programmer would make, and so makes a far better mutation operator than random edits. They used a diff model, a 300-million-parameter model trained on code changes from GitHub, prompted with a program and a commit message, drawn at random from a short list, saying for example that the function that builds the program's robot was changed.

A small test made the point. A correct 4-bit parity function was broken by one to five bugs, and each operator was asked to repair it in a single mutation. A standard GP mutation operator's success rate fell exponentially with the number of bugs, and none of its 100,000 attempts fixed all five. The diff model fixed all five, and its success depended more on how many kinds of bug there were than on how many bugs.

The main experiment used MAP-Elites with the diff model as its mutation operator. The candidates were Python programs that build Sodaracers, two-dimensional walking robots made of masses and oscillating springs. The archive was a 12 by 12 by 12 grid over the robots' height, width and mass, 1,728 cells in all, and fitness rewarded effective locomotion across the ground. Each run started from a single hand-written program and made 1,024,000 evaluations (2,000 iterations of 512 diffs). The runs filled a large share of the cells, at different speeds for different seed programs, and generated hundreds of thousands of working programs in a domain the model had not seen in training. The authors then fine-tuned a model on those programs and trained a terrain-conditioned version with reinforcement learning (Lehman et al., 2022, §§3, 5–7). The point of interest here is the first step: evolution with a language model as its mutation operator could generate training data in a new domain from one example.

FunSearch

FunSearch (Romera-Paredes et al., 2024) applied the loop to open mathematical problems and to heuristics. Its design choices recur in AlphaEvolve.

• Evolve a function, not a solution. The user writes a program skeleton and an evaluate function, and only one function is evolved: for the cap set problem, a priority function that a fixed greedy loop uses to decide which vector to add next. A short program can generate a large, structured object, and a person can read it.
• Best-shot prompting. Each prompt contains $k = 2$ programs from the database, sorted by score, and asks the model for the next version. The authors found two better than one, with diminishing returns beyond.
• An islands database. The population is split into $m$ islands, each started from the user's program and evolved separately; a prompt draws both its programs from one island, and the child goes back to that island. Every 4 hours, the islands in the worse half by best score are wiped and each is reseeded with the best program of a randomly chosen surviving island. Within an island, programs are clustered by their scores on the test inputs, and sampling favors higher-scoring clusters and, within a cluster, shorter programs. This is the island model of parallel genetic algorithms, with migration replaced by periodic resets.
• Cheap models, many samples. FunSearch used Codey, a code model from the PaLM 2 family, chosen for fast inference, and typically ran 15 samplers and 150 CPU evaluators in parallel.

Its results:

• Cap sets. A cap set is a set of vectors in $\mathbb{Z}_3^n$ with no three on a line, equivalently no three distinct vectors summing to zero. In dimension $n = 8$, FunSearch found a cap set of size 512, larger than the best previously known, 496 (Romera-Paredes et al., 2024, Fig. 4). Through admissible sets, which combine small cap sets into large ones, it also raised the lower bound on the cap set capacity from 2.2180 to 2.2202, which the authors call the largest improvement in 20 years.
• Online bin packing. Starting from best fit, FunSearch evolved heuristics that choose a bin for each arriving item. They used fewer bins than first fit and best fit on the four OR-Library datasets and on instances drawn from a Weibull distribution, generalizing to larger instances than those they were evolved on; on 100,000-item Weibull instances the result was 0.03% above the lower bound on the optimum. The evolved heuristics avoid leaving small gaps that later items are unlikely to fill. (First fit is also the decoder in this site's genetic algorithm for bin packing, an offline problem.)

The discovered programs were short and readable, and simplifying by hand the program that produced the 512-cap gave an explicit construction of it.

Cap sets and the priority function, worked

The cap set problem is small enough to try by hand in two dimensions. $\mathbb{Z}_3^2$ has 9 points and 12 lines of three points each (rows, columns, and diagonals that wrap around modulo 3). The points $(0,0), (0,1), (1,0), (1,1)$ form a cap: any third point on a line through two of them lies outside the set. For instance, $(0,0)$ and $(1,1)$ lie on the line completed by $(2,2)$, and $(0,0) + (1,1) + (2,2) = (3,3) \equiv (0,0)$, which is the sum-to-zero test. No set of five points avoids all 12 lines, so 4 is the maximum; Romera-Paredes et al. (2024, Fig. 3) draw this cap with its lines. The script tools/experiments/evolution/cap_sets.py checks, over every triple of distinct points in $\mathbb{Z}_3^2$ and $\mathbb{Z}_3^3$, that the triple is collinear exactly when it sums to zero, and finds by exhaustive search that the largest caps have sizes 4 and 9. Beyond that, exhaustive search becomes hopeless, and the exact maximum is known only for $n \le 6$ (Romera-Paredes et al., 2024).

FunSearch did not search over sets. Its user-written skeleton is a greedy loop that never changes. It is shown here abridged from Romera-Paredes et al. (2024, Fig. 2a): the main and evaluate functions, the docstrings and the utils_capset. module prefix are left out, and the comments are ours.

def solve(n):
    elements = get_all_elements(n)                  # every vector of Z_3^n
    scores = [priority(el, n) for el in elements]
    elements = elements[np.argsort(scores, kind='stable')[::-1]]
    capset = []
    for element in elements:                        # highest priority first
        if can_be_added(element, capset):           # completes no line
            capset.append(element)
    return capset

def priority(element, n):                           # the only function evolved
    return 0.0

All the search happens inside priority. How much that one function matters can be seen in four dimensions, where 20 is the best known size (Romera-Paredes et al., 2024, Fig. 4a) and the greedy loop is all there is. With vectors visited in lexicographic order, the loop builds a cap of 16. Over 1,000 random priority functions (seeded), it built caps of 16 in 94 cases, 17 in 585 and 18 in 321. None reached 20. The loop guarantees a valid cap; whether it is a large one depends on the order in which the priority function offers vectors.

In eight dimensions the same skeleton with the constant priority above produces a cap of 256 (ties are broken by the stable sort, so the loop takes vectors in reverse lexicographic order). The priority function that FunSearch evolved, a few dozen lines printed in the paper (Fig. 4b), gives a large bonus to vectors with no zero coordinates, and its score also depends on whether the same entry appears in mirrored positions $i$ and $-i$ (the $i$-th position counted from the end), which raises the priority of a vector with no zeros. Transcribed and run in the skeleton by our script, it produces a valid cap of exactly 512, the published result. Nothing about the problem changed between the two runs except the priority function, and every candidate was scored by the same evaluate: the size of the cap if it is a cap set.

AlphaEvolve

AlphaEvolve (Novikov et al., 2025) keeps FunSearch's loop and changes almost everything around it. The authors summarize the differences in a table (Novikov et al., 2025, Table 1):

Components

• Task specification. The user marks the blocks of an existing program to be evolved with # EVOLVE-BLOCK-START and # EVOLVE-BLOCK-END, provides an initial version that runs (it may be trivial), and writes an evaluate function that returns a dictionary of scores to be maximized. The evolved code can be the solution itself, a function that constructs it, or a search algorithm that finds it within a compute budget.
• Prompt sampling. Prompts combine previous programs from the database with system instructions and optional extras: human-written context such as equations or papers, randomized template alternatives, rendered evaluation results, and meta prompts, instructions written by an LLM and evolved in a separate database of their own.
• Diff-based edits. The model answers with one or more blocks of the form <<<<<<< SEARCH (exact code to find) ======= (replacement) >>>>>>> REPLACE, so it edits targeted parts of a large file instead of rewriting it. For short code, it can be asked for a full rewrite instead.
• An ensemble of models. Gemini 2.0 Flash supplies many fast proposals, and Gemini 2.0 Pro occasional stronger ones.
• Evaluation. Beyond running evaluate, the user can set up an evaluation cascade of tests of increasing difficulty, so that weak programs are discarded cheaply; ask separate LLM calls to grade properties such as simplicity; and spread evaluation over a cluster. The authors note that the system's sample efficiency makes it feasible to spend on the order of 100 compute-hours evaluating a single candidate.
• The evolutionary database. It stores every program with its scores and outputs and decides which to resurface in prompts, balancing improvement of the best programs against diversity. The paper says only that it implements "an algorithm that is inspired by a combination of the MAP elites algorithm and island-based population models" and gives no further detail (Novikov et al., 2025, §2.5).
• Asynchronous pipeline. A controller, LLM samplers and evaluation nodes run concurrently, optimized for throughput, in the spirit of master-slave parallel evaluation.

The evaluator is the requirement on which everything else depends. It is what the authors name as the main limitation: AlphaEvolve handles only problems "for which it is possible to devise an automated evaluator" (Novikov et al., 2025, §6).

Reported results

The following are the paper's claims, stated as the paper gives them.

Matrix multiplication. Multiplying an $m \times n$ matrix by an $n \times p$ matrix with $r$ scalar multiplications corresponds to a rank-$r$ decomposition of a fixed three-dimensional tensor. AlphaEvolve evolved the code of a gradient-based decomposition search, starting from a standard initializer, loss and Adam optimizer, with candidates scored by the lowest rank reached on a set of targets and the fraction of random seeds that reached it. Entries were rounded to integers or half-integers so that decompositions were exact. It improved the best known rank for 14 targets and matched or improved the best known for every $\langle m, n, p \rangle$ with all three at most 5. For two $4 \times 4$ matrices, applying Strassen's algorithm recursively gives 49 multiplications and works over any field; AlphaTensor had found 47, but only for arithmetic modulo 2 (Fawzi et al., 2022). AlphaEvolve found a decomposition of rank 48 that uses complex numbers and so applies to complex and real matrices, the first improvement over 49 in fields of characteristic 0 in 56 years (Novikov et al., 2025, §3.1 and Table 2). Dumas, Pernet and Sedoglavic (2025) later transformed it into a 48-multiplication algorithm with rational coefficients, valid over any ring whose characteristic is not 2. The section below works through what these ranks mean.

Mathematics. On more than 50 open problems in analysis, geometry, combinatorics and number theory, AlphaEvolve matched the best known construction in about 75% of cases and found a better one in about 20%, starting each time from a simple or random construction (§3.2). Examples:

• Kissing number in 11 dimensions. 593 non-overlapping unit spheres that touch a central unit sphere, against the previous record of 592.
• Erdős's minimum overlap problem. The upper bound improved from 0.380926 to 0.380924 (Fig. 5).
• Packing. Eleven and twelve unit regular hexagons fit in regular hexagons of side 3.931 and 3.942, against 3.943 and 4.0 (Appendix B.7).

Google's computing infrastructure (§3.3):

• Data center scheduling. An early version of AlphaEvolve evolved the heuristic that Google's cluster manager, Borg, uses to rank machines for a pending job, treated as a two-dimensional (CPU and memory) bin-packing problem and scored in a simulator built from historical workload snapshots. The new heuristic, which is short, was deployed across the fleet, and post-deployment measurement found that it "continuously recovers on average 0.7% of Google's fleet-wide compute resources" that would otherwise be stranded. Because the heuristic only reorders machines already judged able to run the job, its decisions are correct by construction.
• Gemini kernel tiling. For a matrix-multiplication kernel used in training Gemini, an evolved tiling heuristic gave "an average 23% kernel speedup across all kernels" over the expert-written heuristic, "and a corresponding 1% reduction in Gemini's overall training time," with half of the collected input shapes held out for evaluation. Kernel tuning that had taken months of engineering took days.
• TPU circuit. A rewrite of a Verilog arithmetic circuit removed unnecessary bits; the paper notes that downstream synthesis tools also found this simplification independently. It is to be included in an upcoming TPU.
• Compiler-generated code. Editing the XLA intermediate representation of a FlashAttention kernel for a GPU inference configuration sped up the kernel by 32% and its pre- and post-processing by 15%, with correctness checked on random inputs and confirmed by human experts.

Ablations (§4). Removing any one component made results worse: no evolution (the same initial program fed repeatedly to the model), no problem context in the prompt, or using only a single small model, each tested on the tensor and kissing-number tasks; and no meta-prompt evolution, or evolving only a loss function instead of the whole file, tested on the tensor task alone. Each configuration was run three times.

The matrix multiplication result, worked through

Strassen's seven products. Multiplying two $2 \times 2$ matrices in the ordinary way computes each of the four entries $c_{ik} = a_{i1} b_{1k} + a_{i2} b_{2k}$ with two multiplications, eight in all. Strassen's 1969 algorithm, as presented by Fawzi et al. (2022, Fig. 1), uses seven, at the price of more additions:

$$c_{11} = M_1 + M_4 - M_5 + M_7, \quad c_{12} = M_3 + M_5, \quad c_{21} = M_2 + M_4, \quad c_{22} = M_1 - M_2 + M_3 + M_6.$$

With $A = \begin{pmatrix} 1 & 2 \\ 3 & 4 \end{pmatrix}$ and $B = \begin{pmatrix} 5 & 6 \\ 7 & 8 \end{pmatrix}$, the products are $M_1 = 5 \cdot 13 = 65$, $M_2 = 7 \cdot 5 = 35$, $M_3 = 1 \cdot (-2) = -2$, $M_4 = 4 \cdot 2 = 8$, $M_5 = 3 \cdot 8 = 24$, $M_6 = 2 \cdot 11 = 22$ and $M_7 = (-2) \cdot 15 = -30$. Then $c_{11} = 65 + 8 - 24 - 30 = 19$, $c_{12} = -2 + 24 = 22$, $c_{21} = 35 + 8 = 43$ and $c_{22} = 65 - 35 - 2 + 22 = 50$, which is $AB$. To check that the cross terms cancel in general, expand $c_{12} = M_3 + M_5 = a_{11} b_{12} - a_{11} b_{22} + a_{11} b_{22} + a_{12} b_{22} = a_{11} b_{12} + a_{12} b_{22}$; the other three entries cancel the same way.

Saving one multiplication in eight matters because nothing in the formulas uses commutativity: the entries can themselves be matrices. A $4 \times 4$ matrix is a $2 \times 2$ matrix of $2 \times 2$ blocks, so Strassen's formulas multiply it with seven block products, each of which is again a $2 \times 2$ product done with seven scalar multiplications: $7 \times 7 = 49$, against $4^3 = 64$ for the ordinary method. Applied recursively to $n \times n$ matrices, the count is $7^{\log_2 n} = n^{\log_2 7} \approx n^{2.807}$. This is the "rank 49" that stood for 4 × 4 matrices. Our script tools/experiments/evolution/matmul_tensor.py runs the recursion on integer matrices, counts 49 scalar products and checks the result against the ordinary product.

The tensor. Every bilinear algorithm of this kind can be written down as numbers. Index the four entries of $A$, of $B$ and of $C$, and form a $4 \times 4 \times 4$ array $\mathcal{T}$ with a 1 at position $(a_{ij}, b_{jk}, c_{ik})$ for every term $a_{ij} b_{jk}$ that contributes to $c_{ik}$, and 0 elsewhere. The $2 \times 2$ tensor has eight ones, one per multiplication of the ordinary method.

A rank-one tensor $u \otimes v \otimes w$ has entries $u_x v_y w_z$, and it describes one multiplication: form the combination $\sum_x u_x a_x$ of entries of $A$, the combination $\sum_y v_y b_y$ of entries of $B$, multiply the two numbers, and add $w_z$ times the product to each entry $c_z$ of $C$. A sum of $R$ rank-one tensors that equals $\mathcal{T}$ exactly is therefore an algorithm with $R$ multiplications, and the least such $R$ is the rank of the tensor (Fawzi et al., 2022). The ordinary method is the decomposition into eight rank-one tensors, one per 1. Strassen's algorithm is a decomposition into seven, whose factor vectors are the columns of three $4 \times 7$ matrices:

For two $4 \times 4$ matrices the tensor is $16 \times 16 \times 16$ with 64 ones, and recursive Strassen gives a decomposition of rank 49. The search that AlphaEvolve's evolved program carries out is for three $16 \times R$ factor matrices whose rank-one terms sum exactly to that tensor, with $R$ as small as possible. The decomposition it found has $R = 48$. The paper notes that algorithms with fewer than 49 multiplications were known, but that they do not correspond to decompositions of this tensor and cannot be applied recursively to larger matrices (Novikov et al., 2025, §3.1, footnote 3); the tensor rank is the count that recursion multiplies.

The rank-48 factors are published by Google DeepMind in the notebook mathematical_results.ipynb that accompanies the paper (repository google-deepmind/alphaevolve_results on GitHub, materials licensed CC-BY 4.0); our script reads a copy of them, stored with that attribution. The notebook indexes the entries of $C$ in transposed order, $c_{ki}$ in place of $c_{ik}$, which relabels the third factor and changes nothing else. Every entry has real and imaginary parts in $\{-\tfrac12, 0, \tfrac12\}$, so the nine possible values run from $-\tfrac12 - \tfrac12 i$ to $\tfrac12 + \tfrac12 i$. Our script reads them and checks them in two independent ways. The sum of the 48 rank-one terms equals the $16 \times 16 \times 16$ tensor exactly, entry for entry. Run as an algorithm, it multiplies 1,000 pairs of random complex $4 \times 4$ matrices with 48 multiplications each and agrees with the ordinary product to within $1.1 \times 10^{-14}$, which is floating-point rounding. Every one of the 48 left-hand combinations has complex coefficients, so even when $A$ and $B$ are real, the 48 multiplications are of complex numbers, and a complex multiplication carried out in real arithmetic takes more than one real multiplication. The later version with rational coefficients by Dumas, Pernet and Sedoglavic (2025), whose title stresses "non-complex multiplications," removed that qualification.

What is evolutionary about it

The loop is evolutionary in the plain technical sense. There is a population of candidates held in a database, variation produces children from parents, an evaluator assigns fitness, and selection decides what is kept and what is shown to the model next. Its diversity mechanisms are borrowed directly from the field: islands with resets in FunSearch, and a database inspired by MAP-Elites and island models in AlphaEvolve. The ablation without evolution, which samples repeatedly from the initial program, did worse, so the accumulation of improvements across generations matters and the model alone is not the whole story. The authors place AlphaEvolve in the genetic programming tradition, describing the use of an LLM as automating the construction of the mutation operators that GP had to design by hand (Novikov et al., 2025, §5).

What is missing is most of what the biological metaphor suggests (see limits of the evolutionary metaphor). There is no genome separate from the program and no recombination by a fixed operator, and AlphaEvolve's prompts can contain several programs, so a single child may draw on many parents. "Mutation" here is closer to a programmer's edit, informed by scores, context and the code of other programs, than to a random change.

What the language model contributes

The model supplies variation with strong prior knowledge. Its edits are usually syntactically valid and often meaningful, which addresses GP's old problem of locality: a small change to the text of a program is rarely a small change to what it does, but a change proposed by a model trained on code is far more likely to be a sensible one. The ELM parity test measured this directly. The model also reads natural-language context, so a human can steer the search with descriptions, papers and hints, as the AlphaEvolve authors did when they asked for near-integral tensor entries in the prompt.

What the model does not supply is correctness. In the authors' words, evaluation "allows AlphaEvolve to avoid any incorrect suggestions from the base LLM." Every reported result is a program or construction that was executed and scored, and many can be checked independently: a kissing configuration, a cap set, a tensor decomposition.

Limits

• An evaluator is required. The approach applies to problems whose answers a program can score. That covers much of mathematics and computer systems, but in the natural sciences only some experiments can be simulated (Novikov et al., 2025, §6). The evaluator also defines success: any flaw in it is a target for search, a problem with a long history in digital evolution. The safeguards described in the paper (rounding to exact values, testing on held-out inputs, correctness by construction, expert review) are specific to each application.
• Cost. Each candidate costs a model call plus an evaluation that may run for hours. The paper does not report the total compute for its results, which makes comparisons with other methods at equal budget impossible from the paper alone.
• Reproducibility. The system depends on proprietary models, and the white paper describes AlphaEvolve without releasing its code; the discovered algorithms and constructions are published in an accompanying notebook. FunSearch released a single-threaded implementation of its pipeline with the paper. Results that are checkable objects can be verified even when the search that produced them cannot be rerun, as with the rational version of the 48-multiplication algorithm.
• Size of the gains. Several of the improvements are small: one more sphere in 11 dimensions, the sixth decimal place of the minimum overlap bound. They are improvements on problems that specialists had worked on for decades, and the infrastructure gains are large in absolute terms because they apply across a fleet. Our own observation is that the headline results are compared with the best published results, not with other search methods given the same budget. The ablations show on two tasks that evolution, prompt context and the stronger models each help, but the paper does not show how much of each result would also be reached by other search methods given the same compute.

LLM-guided evolution does not replace the classical methods on problems where a fixed representation and cheap evaluations are available; there, a genetic algorithm or CMA-ES costs a small fraction as much per evaluation. Its niche is problems where the solution is naturally a program, an evaluator can be written, and human knowledge about the domain can be expressed in the prompt. The history of evolutionary computation begins with Friedberg's attempt to evolve programs in the 1950s, which learned only very simple tasks; these systems bring a far more capable mutation operator to that old problem.

References

• Dumas, J.-G., Pernet, C., and Sedoglavic, A. (2025). A non-commutative algorithm for multiplying 4x4 matrices using 48 non-complex multiplications. arXiv:2506.13242.
• Fawzi, A., Balog, M., Huang, A., Hubert, T., Romera-Paredes, B., Barekatain, M., Novikov, A., Ruiz, F. J. R., Schrittwieser, J., Swirszcz, G., Silver, D., Hassabis, D., and Kohli, P. (2022). Discovering faster matrix multiplication algorithms with reinforcement learning. Nature, 610(7930), 47–53.
• Google DeepMind (2025). alphaevolve_results: mathematical_results.ipynb (section "Rank-48 decomposition of <4,4,4> over 0.5*C"). https://github.com/google-deepmind/alphaevolve_results. Software Apache 2.0; other materials CC-BY 4.0.
• Lehman, J., Gordon, J., Jain, S., Ndousse, K., Yeh, C., and Stanley, K. O. (2022). Evolution through large models. arXiv:2206.08896. Published in Banzhaf, W., Machado, P., and Zhang, M. (eds.), Handbook of Evolutionary Machine Learning, 331–366, Springer, 2023.
• Novikov, A., Vũ, N., Eisenberger, M., Dupont, E., Huang, P.-S., Wagner, A. Z., Shirobokov, S., Kozlovskii, B., Ruiz, F. J. R., Mehrabian, A., Kumar, M. P., See, A., Chaudhuri, S., Holland, G., Davies, A., Nowozin, S., Kohli, P., and Balog, M. (2025). AlphaEvolve: a coding agent for scientific and algorithmic discovery. arXiv:2506.13131.
• Romera-Paredes, B., Barekatain, M., Novikov, A., Balog, M., Kumar, M. P., Dupont, E., Ruiz, F. J. R., Ellenberg, J. S., Wang, P., Fawzi, O., Kohli, P., and Fawzi, A. (2024). Mathematical discoveries from program search with large language models. Nature, 625(7995), 468–475.