[feature] Implement ideas from the Darwin-Godel Machine paper to evolve the openevolve agent itself

[nileshtrivedi]

Paper: https://arxiv.org/abs/2505.22954

The key idea is: Instead of evolving an algorithm or function, they evolve the coding agent itself.

I do not think it is a significantly different approach from OpenEvolve. It should be possible to replicate DGM within OpenEvolve's current architecture.

[jvm123]

Considering the multi-file edit need of this, features from issue #46 might become relevant. But this seems to turn OpenEvolve more and more into existing coding agents like Aider and Cursor. I wonder whether OpenEvolve could be integrated with them, sort of as an orchestrator.

[lmanhes]

I think the concept of “Meta Prompts,” as described in the AlphaEvolve paper, already represents an evolution of the agent itself.

[jvm123]

That would not cover the evolution logic, though?

[lmanhes]

Only the operators I guess. Taking inspiration from previous programs is a kind of crossing-over / mutation.

[andrewalufkin]

Integrating openevolve with something like cursor would be unreasonably expensive. Cursor uses one (or a few) prompts to solve a specific problem, but it doesn't care about efficiency. OpenEvolve uses many prompts in an evolutionary loop to iteratively improve the efficiency of a solution. If you did that every time you wanted to make a fix costs would skyrocket. As for running open evolve on itself I think that's a cool idea but by what metric would you test? You'd have to choose the types of problems you'd want it to optimize based on, and it would be extremely costly because you'd have to run the program O(n^2)- originally it would just memorize the answers to your problems and there's no telling whether it would actually grok enough to solve problems outside the training set (probably given enough time but that would hurt your wallet for something that isn't guaranteed to happen)

[nileshtrivedi]

@andrewalufkin The desired metric for a self-improving general agent is an interesting question. At a high-level, it could be something like "advancing its own capability-cost frontier". But you are right, the measurement of capabilities itself would be too costly (and it needs to be repeated often, else it would regress). Evolution, just like in nature, is not cheap.

I wonder if this metric can be reduced to, "Solve N previously unsolved tasks sampled from an external list". This makes the tasks themselves dynamic (humans could maintain a catalog of challenging tasks for AI and continuously update it) so, the agent would have to avoid memorization/specialization and become generally capable.

I wrote some thoughts about need for formalizing evals, but had not taken this challenge into account.

[lmanhes]

@nileshtrivedi An automatic curriculum based on curiosity and feasability? An LLM propose achievable goals and success criterion based on the agent past skills acquisition history.

• Voyager
• IMGEP with Automatic Curriculum Learning

[BradKML]

@nileshtrivedi could we also include the goal of not causing an increase in solve time or decrease in solve rate for well-established problem sets, SWE Bench or some math benchmark for example?

[nileshtrivedi]

@BradKML I think so, but as @andrewalufkin wrote above, evals like SWE-bench would be very expensive.

@codelion What are your thoughts on this direction (running OpenEvolve on itself to become better at coding)?

[codelion]

With a cheap most like Gemini-Flash-lite running on SWE-bench will not be expensive, we can try with the swe-bench-lite subset. Before we try applying openevolve to itself it will be interesting to see some evidence that evolutionary test time scaling can help with coding tasks like the ones in swe-bench.
so, we should setup an experiment that uses the same harness (like openhands) and same model (say gemini-flash-lite) with and without openevolve to see how much percentage of instances are we able to resolve in swe-bench.

[BradKML]

@nileshtrivedi then all we need to do is find subsets like how @codelion explained it, there are a lot of cheap open weight models out there as well with Qwen3 and the DeepSeek R1 distilled models. ML benchmarks and SWE benchmarks, plus maybe common sense or math for sanity checks?

[jvm123]

@BradKML The lm-evaluation-harness adapter in the examples folder should allow to run a bunch of benchmarks, incl. coding, common sense and math. The benchmarks have different task numbers and with the --limit parameter, you can always run a subset.
The adapter has not been properly tested at this point, though, and no systematic evaluations were run yet. Collecting results and summarizing them would provide a good basis to better gauge OpenEvolve as a whole, I feel.
Resource measurements could be added.

In a later step, the self-improvement could be built around this (with the O(n^2) issue..).

[BradKML]

How do we go from O(N ^ 2) to O(N * Log N) at least? How can it be accelerated for some of the more trivial benchmarks where there is a threshold of "good enough"?

[jvm123]

Start with the foundation first ;) That is: We need to do the systematic evaluation of the system as-is. If those evaluations can be done with a single command, we have the foundation for what we need to do the meta level of self-improving the system that solves the benchmarks.

Next, we need to give OpenEvolve the multi-file edit capability (cmp. my first comment and #46 ).

Next, we can create a new example folder openevolve-selfimprove/, that copies the root directory code base into a subfolder, runs the examples/lm-eval/ benchmark (and others) with that OpenEvolve executor, captures the result, improves the OpenEvolve codebase, reruns the benchmarks with the improved executor, ..

I guess it would be less than O(n^2) if you find a certain sweet spot (?).
For example, execute only a small subset of the benchmarks, to periodically do the full set of benchmarks, during the self-improvement of the executor. I think @andrewalufkin was suggesting that then you'd optimize for a dumb OpenEvolve that overfits on this subset of problems. So to arrive at a generally useful OpenEvolve codebase (incl. its prompts), you'd need to ensure that the benchmark subset is of sufficient variety (i.e., unpredictable problem types in each new turn), and that the adapted OpenEvolve codebase is not just memorizing solutions to individual tasks.

[BradKML]

The key play here would be to have emergent behavior for guardrails for some of the basic code operations, such that in case some of the modifications broke key features, it can be more easily spotted. It is not necessary to overfit them, cus even then LoRA-esque changes would be less destructive as "learns less but forgets less"

P.S. Two repos trying to work with DGM, good for some inspirations

• https://github.com/lemoz/darwin-godel-machine
• https://github.com/tuaregsand/Unified-DGM-Codex