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.
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:
- A search space — every configuration the answer could turn out to be, most of it invalid or worse than where you started.
- A generator — handed an input, it can land on any point in that space, not just the ones near where it began.
- A scorer, or more generally a policy — the thing that decides what better means, and so which way is up.
- Wiring between them — so a score feeds back and steers the next guess, instead of being read once and thrown away.
- Compute — because every step costs something, and the budget is what you are really spending.
That is the whole apparatus.
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.
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.
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.
And a data-centre scheduling heuristic now in production — +0.7% compute recovered across Google.
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.
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 |
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.
Next — Nothing here is clever, on purpose: the optional, borrowed parts that make the loop cheaper to run.