Simple but Effective Search: Entering the Era Where It Climbs with the Models.

A model's capability was never the bottleneck — the instruction was. Finding the right one is a search, and automating that search is program evolution.

The Potter mid-stance, channeling the search–evaluate–select loop: a graph of failing candidates on the left resolving into verified ones on the right.

A language model is powerful and nearly useless at the same time. Hand it a precise instruction and it will do things that looked like science fiction a few years ago. Leave the instruction vague — the way we usually do — and you get the confident, plausible, wrong answers everyone has learned to dread. The same model, the same weights. Only the words changed.

That is the uncomfortable part of working with these systems. We carry a task in our heads, recognise the right answer when we see it, and hold only a fuzzy idea of the words that would reliably produce it. The capability is not the missing piece. The specification is. Tell a model the right way and it turns reliable almost suddenly — the intelligence was there the whole time, waiting to be pointed at the problem.

So the real question is rarely can the model do this. It is what, exactly, do I say. And that is not something you answer by thinking harder. It is a search: you try a way of asking, measure what comes back, adjust, and go again, until the words are right. Done by hand it is a slow afternoon with a spreadsheet. Done as a loop, automatically, it has a name — program evolution.

None of which is a 2025 invention. The loop is older than deep learning; it runs in population genetics and in the genetic algorithms people were writing in the 1970s. What is new is narrow, and worth naming exactly — because it is not the part the headlines point at.

First, it's a search problem

The prompt optimizers worth caring about are evolutionary, and that word earns its place. It means the task is a search: you are not asking a model for the answer, you are searching a space of possible answers for one that scores well.

A search like that needs a few specific parts, and not many more:

That is the whole apparatus.

generator an input → any point in the space
scorer / policy says what “better” means
compute every visit spends it — the real budget
The mechanism: a generator and a scorer wired together, run against the compute budget that every guess spends.

Two more things are not required, but you want them. You can usually tell a loser before you have scored it in full — so you stop early, and spend what is left on the candidates still in the running. And every round you are choosing between exploring new ground and exploiting what already works. Lean too far either way and the search stalls.

The search space as a landscape the optimizer crosses A framed 2-D space scattered with regularly spaced grid dots and altitude contour lines that rise toward a summit in the top-right corner, labelled valid and high accuracy. The bottom-left corner is hatched and labelled invalid or degrades; a handful of candidate points there are crossed out as culled. Candidate dots are spread widely in early rounds, drift up the slope in middle rounds, and cluster tightly on the summit in late rounds, traced by a single curved arrow from the bad corner to the peak. valid · high accuracy invalid / degrades early — explore widely mid — drift centerward late — cluster
The same space, crossed over many rounds. Early guesses fan out; the ones that are invalid or degrade get culled; the survivors drift up the slope and cluster where the score is highest. Explore early, exploit late — that is the whole game.

AlphaEvolve isn't special

This is why AlphaEvolve, for all it has done, is not a new kind of thing. Change the space, the generator and the scorer, and the same skeleton becomes a genetic algorithm, an evolution strategy, a reinforcement learner, an AutoML sweep — or evolution itself, the original. The wiring does not change. Only what flows through it does.

What changed, and only recently, is the generator. A language model's weights are a function approximator; on their own they optimise nothing. Put one inside this loop as the thing that proposes the next candidate, and the ceiling that kept evolutionary search niche falls away — you no longer hand-build a mutation operator for each domain. The model proposes a sensible variant of code, a prompt, a config, a schema, whatever you can describe. That is the new thing. Not the weights. The pairing.

Biological evolution organismssurvival
Genetic algorithms bit-stringsfitness fn
Reinforcement learning policiesreward
identical everywhere the loop assess a population · keep the best · vary · repeat
AutoML — irace, SMAC configsval. score
AlphaEvolve programscode execution
PromptPotter prompts + paramslabelled data
Swap the individual and the evaluator and the same skeleton becomes any of these. A language model is just the most general way yet to propose the next individual.

The strongest proof it works

Point that pairing at source code, with a compiler to score it, and you get AlphaEvolve. In 2025 it found the first improvement to 4×4 complex matrix multiplication in fifty-six years — Strassen's 49 multiplications down to 48 — and shaved roughly 0.7% off the compute in Google's data centres. Small numbers. They are also the clearest evidence so far that the loop, handed a good enough generator, does real work and not just demos.

4×4 complex matrix multiplication
Strassen 1969 49 scalar mults · stood for 56 years
AlphaEvolve 2025 48 first improvement in over half a century

And a data-centre scheduling heuristic now in production — +0.7% compute recovered across Google.

The headline result: the very same evolutionary loop, pointed at code.

Who actually matters here

Among the recent crop, a short genealogy carries most of the signal. The idea that a model can write and refine its own prompts goes back to APE and OPRO in 2023; TextGrad turned critique into something gradient-shaped. The program-synthesis line runs from FunSearch (Nature, 2024) to AlphaEvolve. On the prompt side the direct ancestor is PromptWizard (Microsoft, 2024). Everything else is a cousin; the full map is in the optimizer's related-work doc.

Foundations · 2023 — APE, OPRO and TextGrad seed the idea.
Program synthesis
FunSearch2024 · Nature
AlphaEvolve2025 · DeepMind
Prompt optimization
PromptWizard2024 · Microsoft
PromptPotter2025 · this work
structurally closest peer
PromptPotter descends from PromptWizard's loop and lands next to AlphaEvolve — same paradigm, different artifact.

Where PromptPotter sits

PromptPotter is the same loop again, pointed at prompts and pipeline parameters. Its loop is PromptWizard's; structurally it stands beside AlphaEvolve and shares the same primitives. The one place AlphaEvolve reaches further is into source code itself. PromptPotter gives up that depth for breadth — the messy, multi-step LLM pipelines most teams actually run.

Capability PromptPotter AlphaEvolve
Generate → evaluate → select loop yes yes
Evaluator-driven scoring yes yes
Statistical early-stopping yes yes
Cross-run memory yes yes
Self-healing on failed measurements yes yes
Optimizes source-code algorithms no yes
Optimizes prompts + pipeline params yes no
Runs in your terminal / IDE yes no
Functionally equivalent across the shared rows. Code optimization is the one axis where AlphaEvolve is unambiguously stronger.
Broader in domain, where AlphaEvolve is deeper in code. AlphaEvolve is stronger where it specializes; PromptPotter reaches the systems most teams actually ship.

The rest of the field

The other names are the same idea in different cells — another space, another generator, another scoring rule. OpenEvolve is AlphaEvolve, rebuilt in the open; MIPROv2 and GEPA search prompts inside DSPy programs; AlgoTuner and AutoResearch tune code against a fixed scorer; promptolution and promptfoo cover the prompt-tooling edges. Worth knowing they exist; not worth re-explaining here. The related-work doc lays them out side by side.

It only compounds

None of this is special, and none of it is deep science. What makes it worth betting on is duller and stronger than cleverness: it compounds. The proposer is a language model, and language models are the part of the stack improving fastest and on the most money — so every gain the trainers ship lands in this loop for free. Same wiring, a better proposer, better results, no rewrite. It climbs with the models, and the models are not slowing down. That makes it close to unstoppable.

So that is all it is: simple, but effective — and nowhere near finished. I am not going to sell you the language model as the answer; it sits in the one seat nothing cheaper can fill yet, not a law of nature. The day something sharper and cheaper can guess the next candidate, it takes that seat and the loop never notices. The bet was never the model. It is the spare little loop around it — and that is the part I trust.

Start the tutorial Read the source

Next — Nothing here is clever, on purpose: the optional, borrowed parts that make the loop cheaper to run.

Trending Agents & Posts
GroqOpenAIAnthropicOpenRouterLangfusePython 3.13
Find host…