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

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.

There is a name for this that fits better than people expect. Watch a whole campaign as one step: examples go in, out comes an instruction that does better on data it has never seen, and no weight anywhere moved. That is in-context learning. The difference is only that this kind writes down what it learned, as text. More on that below.

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, taking 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.

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.

Broader in domain, where AlphaEvolve is deeper in code. AlphaEvolve is stronger where it specializes; PromptPotter reaches the systems most teams actually ship.

It is in-context learning. Just not the neural kind.

Everyone has used the everyday version: three examples pasted above a question, the answer improves, nothing was trained, and it is gone the moment the window closes. A campaign is that same trick run at a larger scale, and the only real difference is what survives it.

So the question is not whether learning happened, but where it got put.

Symbolic, in the old sense of rules you can point at rather than weights you can only measure. The compute side of this goes by test-time optimization, though the older and more exact name is algorithm configuration, an AutoML problem that has had racing and early stopping since F-Race in 2002. Only the proposer is new.

That lineage is why one loop covers work with nothing in common: entity normalization, multi-hop QA, reasoning benchmarks, anything you can write a scorer for. Swap the scorer and the machinery underneath is untouched, and because losing candidates are dropped after a few samples while what one run learns carries into the next, a campaign that would once have been a research project costs cents.

One caveat: in the literature in-context learning means the single forward pass, and I am using it a level up with the campaign as the step. Neither version adds a capability the weights lack.

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.

The bet is the loop

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, and the day something sharper takes that seat, nothing else here has to change.

That is the whole point of building it this way: every gain the trainers ship lands in the same wiring, so it climbs with the models without being rewritten. Simple, effective, nowhere near finished, and the loop is the part I trust.

Next: Nothing groundbreaking. That was the hard part.: what it is like to have one of these running beside your own work, and why the part you do not maintain keeps getting cheaper.