A Working Mental Model of AlphaEvolve

AlphaEvolve becomes easier to judge once its parts are treated as one control loop rather than as a collection of impressive features. This checkpoint connects the human task contract, candidate representation, language-model mutation, executable evaluation, and program-population memory. The goal is practical: to predict where a reported gain could come from and to tell the difference between a generated proposal, a measured improvement, and a result that still needs independent or human verification.

Five roles, one control loop

The first useful model has five roles. The human defines the problem, supplies an initial runnable program, and chooses the evaluation criteria. The representation determines what the program is trying to be: a final object, a constructor, a search procedure, or a coordinated combination. The prompt and language-model stage proposes changes to that representation. The evaluator executes the resulting candidate and returns measurements. The program database retains scored candidates and supplies material for later mutations.

These roles are dependent, not interchangeable. The evaluator cannot judge an undefined target. A language model cannot make a meaningful mutation without a program state and enough context to understand the task. The database cannot create evidence by itself; it preserves and resurfaces evidence produced by execution. And a human-defined metric cannot become a discovery merely because the model proposes a high-scoring change—the candidate must still run under the relevant conditions.

flowchart LR H["Human task contract"] --> R["Candidate representation"] H --> V["Evaluation criteria"] R --> M["Prompt and LLM mutation"] M --> X["Executable candidate"] V --> E["Evaluator"] X --> E E --> S["Scores and feedback"] S --> D["Population memory and selection"] D --> M D --> O["Retained candidate or discovered solution"]

The diagram also clarifies the ownership of state. The human owns the problem definition and the boundary of acceptable change. The candidate program carries the current implementation state. The evaluator owns the measurement of that state under the supplied tests. The database owns persistence of candidates and outcomes for the search. AlphaEvolve’s controller connects these states, but it does not turn one role into another: applying a diff is not evaluating it, and retaining a program is not proving it optimal.

This separation explains why the method can be both flexible and constrained. The model can suggest a structural change that a human did not write by hand. Yet the suggestion must enter through the representation and fixed program boundary, and it must cross the evaluator before it can influence the population. The constraints are not an afterthought added to a creative system. They are the conditions that make the creative output comparable over time.

Where progress is actually created

It is tempting to credit a successful result to the language model because the model emits the visible code change. The loop gives a more precise account. The model creates candidate variation. The evaluator creates a selection signal. The database creates continuity between generations. The representation determines which kinds of variation are expressible and which kinds of success are meaningful. Progress appears when these functions reinforce one another.