A minimal evolutionary search loop with Gemini: propose, evaluate, select — prompted by AlphaEvolve's GA

The skeleton: individuals, fitness, generations

First, fix the axis of evaluation. Here I prepare a small labeled dataset and measure the agreement between "the priority I assigned" and "the ranking a candidate function produces" with Kendall's τ. τ ranges from −1 to 1; closer to 1 means the rankings match perfectly.

# fitness.py — fix the evaluation axis first
from itertools import combinations
 
# A small hand-labeled dataset (features, priority I assigned: higher = handle sooner)
# features = (rating, body_len, has_crash_word, days_since)
DATASET = [
    ((1, 180, 1,  0), 5.0),  # low rating, crash report, same day -> top priority
    ((2, 240, 1,  1), 4.6),
    ((1,  40, 0,  0), 4.0),  # low rating but short
    ((3, 320, 0,  2), 2.8),
    ((5,  30, 0,  0), 0.6),  # high rating, short -> defer
    ((4, 210, 0,  5), 1.4),
    ((2,  90, 1,  9), 3.2),  # crash but old
    ((5, 400, 0,  1), 1.0),
]
 
def kendall_tau(order_a, order_b):
    n = len(order_a)
    concordant = discordant = 0
    for i, j in combinations(range(n), 2):
        sa = order_a[i] - order_a[j]
        sb = order_b[i] - order_b[j]
        if sa * sb > 0:
            concordant += 1
        elif sa * sb < 0:
            discordant += 1
    total = concordant + discordant
    return 0.0 if total == 0 else (concordant - discordant) / total
 
def fitness(score_fn):
    """Fitness of a candidate (-1..1). Higher = closer to my priorities."""
    truth = [label for _, label in DATASET]
    preds = [score_fn(*feats) for feats, _ in DATASET]
    return kendall_tau(truth, preds)

Deciding fitness first is what matters. If this is vague, no matter how fast the later search spins, it will climb the wrong hill at full speed. My first attempt used a plain correlation coefficient for agreement and failed. For a ranking problem you want a rank-agreement metric; a correlation on the raw values gets dragged around by outliers.

Safely evaluating code the model wrote

This is the part that demands the most care. You cannot simply exec the Python code Gemini generates. Infinite loops, file writes, network calls — let any one of them through and autonomous operation turns straight into an incident.

What I chose was a four-layer guard: shrink builtins to a minimum, forbid import, put a time limit on execution, and swallow exceptions as a score of zero.

# sandbox.py — isolated evaluation of model-generated code
import signal
import math
 
SAFE_BUILTINS = {
    "abs": abs, "min": min, "max": max, "round": round,
    "len": len, "float": float, "int": int, "pow": pow,
}
SAFE_GLOBALS = {"__builtins__": SAFE_BUILTINS, "math": math}
 
class Timeout(Exception):
    pass
 
def _raise_timeout(signum, frame):
    raise Timeout()
 
def compile_candidate(code_str, time_limit_sec=1):
    """Build score(rating, body_len, has_crash_word, days_since) from a code string.
    Dangerous or invalid candidates return None; the caller treats that as fitness 0."""
    if "import" in code_str or "__" in code_str or "open(" in code_str:
        return None
    local_ns = {}
    try:
        exec(compile(code_str, "<candidate>", "exec"), dict(SAFE_GLOBALS), local_ns)
    except Exception:
        return None
    fn = local_ns.get("score")
    if not callable(fn):
        return None
 
    def guarded(*args):
        signal.signal(signal.SIGALRM, _raise_timeout)
        signal.setitimer(signal.ITIMER_REAL, time_limit_sec)
        try:
            return float(fn(*args))
        except (Timeout, Exception):
            return 0.0
        finally:
            signal.setitimer(signal.ITIMER_REAL, 0)
    return guarded

String inspection alone is not airtight. Swapping __builtins__ still leaves decorator-based escapes, and a signal-based timeout only works on the main thread. Still, within the range one person runs at their desk, this four-layer guard dropped essentially every harmful candidate to zero. If you put this on always-on production, the correct move is to add a separate process and resource limits (resource.setrlimit). This is exactly where the principle shows through: build the stop mechanism and the isolation before you build the convenience.

Letting Gemini do the mutation — why LLM-guided mutation works

I hand the job of producing the next generation to Gemini. The key is not to ask "write a scoring function" in the abstract, but to show the current best candidates with their fitness, then ask for improvements. Mutating toward a reasoned direction rather than at random — that is the essence of LLM-guided mutation.

With structured output, I receive an array of candidate code strings.

# propose.py — seed on the elites, generate several improved variants
from google import genai
from google.genai import types
 
client = genai.Client()  # reads the GEMINI_API_KEY environment variable
 
RESPONSE_SCHEMA = {
    "type": "object",
    "properties": {
        "candidates": {
            "type": "array",
            "items": {"type": "string"},
            "minItems": 4, "maxItems": 8,
        }
    },
    "required": ["candidates"],
}
 
PROMPT_TMPL = """You are a lab assistant for heuristic optimization.
Goal: improve a Python function that defines score(rating, body_len, has_crash_word, days_since).
Fitness is Kendall's tau (higher is better, max 1.0).
 
Current elite individuals (code and fitness):
{elites}
 
Constraints:
- no import statements and no double underscores
- only arithmetic, the math module, and min/max/abs/round
- the function must be named score
Given these, propose {n} improved variants that take different directions."""
 
def propose(elites, n=6, temperature=0.9):
    elites_txt = "\n\n".join(
        f"# fitness={fit:.3f}\n{code}" for code, fit in elites
    )
    prompt = PROMPT_TMPL.format(elites=elites_txt, n=n)
    resp = client.models.generate_content(
        model="gemini-flash-latest",
        contents=prompt,
        config=types.GenerateContentConfig(
            temperature=temperature,
            response_mime_type="application/json",
            response_schema=RESPONSE_SCHEMA,
        ),
    )
    import json
    return json.loads(resp.text)["candidates"]

Why does this beat random mutation? Because Gemini understands what the features mean. Raise priority when has_crash_word is 1; decay it as days_since grows — it weaves these sensible directions in from the very first move of the search. Targets that random search would need hundreds of generations to hit, it reaches in a handful. You do not need the heavy gemini-2.5-pro here. Candidate generation is a volume step, so I balanced cost and speed with gemini-flash-latest (the identity of 3.5 Flash now that it is GA).

Premature convergence and diversity — temperature and restarts

LLM-guided mutation has a side effect. It converges on good candidates fast, but the population starts to look alike just as quickly. That is premature convergence. Once the elites fill up with the same shape of function, you can't move forward.

As countermeasures I added three things. First, reject duplicate individuals by hashing normalized code, so synonymous code can't pad the population. Second, jitter the generation temperature across generations — when improvement stalls, raise it from 0.9 to 1.2 to widen the search. Third, every few generations, mix in one fully random restart, an island-model touch.

Here is the trajectory when I actually ran 8 individuals for 6 generations.

At generation 4 the best τ reached 0.79, and generation 5 brought no update. The mean τ keeps rising, so the population is converging on the best individual. I stopped there. Pushing further would only grow token spend. What mattered was that I could decide when to stop from a number — a sense I never got from hand-tuning.

Budget and guardrails — build the stop mechanism first

In a loop that runs on its own, the first thing to build is not the mechanism that starts it but the one that reliably stops it. The caps I set were these.

1. Generation cap: 8 by default. Most small problems plateau by then.
2. No-improvement stop: end if the best fitness hasn't updated for 2 consecutive generations.
3. Token budget: 60k tokens per run. Exceed it and return the current best.
4. Hold-out check: hide 20% of the data from the search and re-measure τ there at the end.

The fourth one works quietly. Evaluate only on the data used for search and the population overfits to those few cases. In my run, against τ 0.79 on the search data, the held-out data gave 0.68. That gap is the material for discounting the "apparent" quality. If the gap is too large, it's a sign to add data or penalize function complexity (favor shorter code).

The cost side was realistic too. Roughly 33k tokens per run, a few yen at the gemini-flash-latest rate. If that buys back half a day of manual work, the amount isn't worth hesitating over. As an indie developer running several apps solo, I find these "tools that make small optimizations cheap to repeat" compound over time.

Choosing between hand-tuning, DSPy, and the evolutionary loop

Finally, how to pick the tool. Evolutionary search is not universal; matching it to the shape of the problem is the practical stance.

The dividing line is a single question: can you write fitness as a number you trust? If you can, the evolutionary loop works with surprising honesty. If you can't, start by putting the evaluation axis into words — that is a problem prior to any tool.

The biggest thing I took from this loop was not the optimal coefficients themselves. It was that writing out "what counts as good" as a function forced my own criteria into the open. Priorities that had hidden inside intuition now sit in front of me as code.

As a next step, picture one number you're currently adjusting "by feel." If you can score its quality on about ten data points, it is already a problem you can put on this loop. I hope it gives you a place to start.