From a Problem Definition to an Executable Candidate
This chapter follows AlphaEvolve at the point where an abstract research goal becomes a runnable candidate program. The specific question is how a human-supplied initial program and evaluator constrain a language model’s freedom without reducing the search to hand-written edits. Understanding that contract lets the reader distinguish a generated suggestion from a candidate that has actually entered AlphaEvolve’s evidence-producing loop.
The task contract: a runnable candidate and a measurable objective
AlphaEvolve does not begin with a request such as “find a better algorithm” and leave the meaning of better to the model. The user supplies a program and a way to evaluate it. In the paper’s formulation, the evaluator is a function that maps a solution to a set of scalar metrics, conventionally treated as quantities to maximize. The metrics might represent the size of a valid mathematical object, the quality of a search result, the time taken by a kernel, or the outcome of training and testing a machine-learning model. The important property is not that every objective becomes simple; it is that the candidate can be passed through executable tests.
The initial program is the starting point for mutation. It need not contain the best known method, and it can be rudimentary, but it must be complete enough to run and return the expected kinds of values. That requirement is easy to underestimate. A blank page gives a language model no stable object to modify and gives an evaluator nothing reliable to execute. A rough but functioning program, by contrast, supplies interfaces, data flow, and a measurable baseline. AlphaEvolve can then search around that baseline rather than repeatedly guessing what a complete solution might look like.
The system also separates the parts of a codebase that may change from the parts that hold the experiment together. The user marks one or more regions for evolution inside an otherwise fixed skeleton. The evolving regions contain the program components AlphaEvolve is allowed to replace or extend. The surrounding code calls those components and exposes the complete result to the evaluator. This arrangement can support more than a single function: several interacting parts of an algorithm can change together while the input and evaluation boundary remains stable.
That boundary has a practical consequence. A proposed child must still fit the surrounding program well enough to execute. A change that refers to incompatible data, breaks an interface, or prevents the evaluator from running is not an intriguing partial success; it is a failed candidate at this stage. The fixed skeleton therefore does not merely make integration convenient. It defines part of the search space by preserving the context in which a proposed change has meaning.
The evaluator has a second boundary beyond whether a program runs: what it chooses to measure. A construction may be valid but smaller than an existing one. A kernel may remain correct but be slower. A scheduling rule may be executable but fail to use resources efficiently. AlphaEvolve can rank such candidates only through the metrics the user exposes. That makes the evaluator an operational contract between human intent and machine selection. It provides a repeatable standard, but it cannot silently supply omitted goals such as maintainability, performance on untested workloads, or a proof that no better candidate exists.
This is why task setup is part of the method’s reasoning, not administrative preparation. The human chooses which behavior is variable, which behavior is held fixed, and which observations count as improvement. AlphaEvolve supplies the search over code within those choices. If the initial program is incomplete or the evaluator is misaligned with the desired outcome, a larger search budget can produce more candidates without producing better knowledge.
One generation: from a sampled parent to a child program
Once the task contract exists, AlphaEvolve’s controller can run a generation. The starting state is a program database containing earlier candidates together with their evaluation results and, where useful, their outputs. The controller samples a parent program and additional programs that can serve as inspirations. The choice is not simply “take the current winner.” Strong programs are useful for exploitation, while different high-performing programs can expose alternative structures and support exploration.
A prompt sampler turns that selection into a context for the language model. It can include the current parent, prior programs, instructions about the task, and rendered evaluation results. The latter matters because a model is not asked to imagine improvement in a vacuum. It can see how a program behaved, which metrics it achieved, and what code it is being asked to change. The prompt may also contain human-written equations, literature, or other problem-specific knowledge. In this role, context is an interface between accumulated experimental evidence and the model’s ability to propose a new program.
The language model then returns a proposed modification. For larger code changes, AlphaEvolve uses a targeted diff format: an original segment to locate and a replacement segment to insert. The controller applies the modification to the sampled parent, producing a child program. The model is responsible for suggesting the change; the controller is responsible for applying it to an actual program state. That distinction prevents a textual proposal from being mistaken for a completed experiment.
The child now crosses the execution boundary. The evaluator loads or invokes it, runs the relevant workload or test, and returns scores and possibly additional feedback. Several outcomes are possible. The child may fail to run. It may run but violate a task property. It may be valid but underperform the parent. It may improve one metric while weakening another. Or it may produce a promising combination that deserves to remain available for later mutations. The loop records these outcomes rather than treating “the model produced code” as the end of the process.
The sequence has an important asymmetry: generation is permissive, while retention is conditional. The language model can propose a surprising change, but only an executable child can receive the feedback that makes the change useful to the search. A failed child may still be informative to a human or to a debugging process, but it does not become evidence of improvement merely because its code is novel.
Evaluation is a pipeline of filters and signals
A single final score is not always an efficient way to run the loop. AlphaEvolve supports an evaluation cascade in which candidates face tests of increasing difficulty. A cheap or small-scale test can filter out broken programs before the system spends the main evaluation budget on them. Candidates that pass early thresholds move to more demanding cases. This is a form of hypothesis testing applied to program search: the candidate must earn access to expensive evidence.
The cascade can protect both speed and validity, but its thresholds also shape what the search sees. If an early test is too strict, it may discard a program whose unusual strategy would have become valuable at a later stage. If it is too permissive, expensive evaluators may fill with obvious failures. The paper describes the mechanism as a way to prune unpromising solutions quickly; it does not claim that one cascade is universally correct. Its usefulness depends on whether early cases are meaningful proxies for the later objective.
AlphaEvolve can also return more than one metric. A user may genuinely care about several objectives, or may use multiple scores to keep structurally different candidates in play. A program that is not the single best on the primary metric can still expose a useful idea if it performs well under another criterion. The authors suggest that these diverse examples can stimulate more varied subsequent proposals. Multiobjective evaluation therefore affects generation indirectly: it changes which programs survive into the prompts that guide the next mutation.
Some desirable properties are difficult to encode precisely. The system can use additional language-model calls to grade qualities such as simplicity, but this feedback has a different status from executing the task and checking a formal property. It is another signal used to steer or filter the search, not an automatic proof. Keeping that distinction clear matters whenever a candidate’s appeal includes qualities that the main evaluator cannot measure directly.
Evaluation can also be expensive. In some applications, each candidate may be tested from many randomized initializations or on accelerator hardware. Those runs can often be parallelized, allowing the system to spend a substantial total compute budget without making every generation wait for one serial experiment. The pipeline is optimized for aggregate throughput: many proposals can be in flight, and the controller can continue assembling work while evaluation nodes complete independent runs.
The result is not a simple hierarchy in which faster evaluation is always better. Cheap filters increase the number of candidate generations that fit within a budget. Expensive, realistic tests increase confidence that a promising change matters under the conditions of interest. Multiple metrics preserve variation but make selection more complicated. Additional feedback can encode human-relevant qualities but introduces another model-mediated judgment. AlphaEvolve’s design combines these signals because no single one captures the entire search problem.
Retention turns execution into cumulative search
After evaluation, the database becomes the system’s memory. It stores candidate programs with their scores and outputs so that later prompts can draw on what has already been tried. The database’s responsibility is not merely archival. It must decide how to resurface evidence: continue exploiting a strong line of code, preserve alternatives that occupy different regions of the search space, or combine both pressures in a population model. AlphaEvolve’s design is inspired by MAP-elites and island-based evolutionary methods for this exploration–exploitation balance.
This memory changes the meaning of a compute budget. Repeatedly asking a model to improve the same initial program would spend computation on new text without necessarily accumulating a structured history of what worked. In AlphaEvolve, retained programs become parents, examples, or contrasts. A later proposal can inherit a high score, borrow a structural idea from another candidate, or move away from a locally successful pattern because the population contains a different route. The paper’s ablations later test what is lost when evolution or context is removed; the mechanism already explains why those changes should matter.
The loop has no guarantee that every retained program is globally superior. Selection is based on the available metrics and the database’s diversity strategy. A candidate may look strong on the tested distribution and fail elsewhere; a candidate may be preserved because it is diverse rather than because it currently leads the main score. The database can make search cumulative without making the result omniscient. Its success depends on the evaluator, the representation, and the amount and variety of computation supplied.
That is the operational standard for reading an AlphaEvolve result: ask when the candidate became executable, which tests it passed, which metrics caused it to be retained, and what evidence was carried into the next generation. The system’s distinctive contribution is not simply that an LLM can emit a code diff. It is that the diff enters a controlled state transition from parent to child, from child to measured result, and from result to future search context. Once that lifecycle is clear, the next question is what the evolving program should represent—an answer, a constructor, or a search strategy—because that choice determines what a “better” child actually means.