CliffSearch: Co-Evolving Theory and Code for Scientific Algorithm Discovery

Paper: 2604.01210 Authors: Youssef Mroueh, Carlos Fonseca, Brian Belgodere, David Cox Categories: cs.LG, cs.AI

The Gap

Current LLM-guided algorithm discovery systems (like FunSearch, EoH) treat algorithms as pure code artifacts optimized solely for benchmark metrics. They lack scientific structure: no explicit theory representation, weak correctness validation, and no originality filtering. The result? High-throughput candidate generation that often produces uninterpretable or incorrect solutions that happen to score well.

The paper identifies three specific shortcomings: (1) code-only representation loses the “why” behind algorithmic choices, (2) optimization pressure alone doesn’t guarantee correctness or novelty, (3) mutation operators don’t distinguish between exploration (finding new ideas) and correction (fixing broken ones).

Problem: Code-only algorithm search
    |
    v
Assumption: Scientific discovery needs structure
    |
    +---> Theory + Code dual representation
    +---> Reviewer agents as correctness gates
    +---> Split mutation: explore vs correct
    |
    v
Method: CliffSearch (agentic co-evolution)
    |
    v
Evidence: 3 benchmarks (transformer, optimizer, ablation)
    |
    v
Conclusion: Structured artifacts + reviewer gating
               yields interpretable, correct discoveries

The Increment

One sentence: Before CliffSearch, LLM-guided algorithm search optimized code for metrics; after, it co-evolves theory and code under correctness and originality constraints.

Core Mechanism

CliffSearch implements evolutionary search where every component is an LLM agent. The population consists of “nodes” — each node is either a theory+code pair or code-only. Evolution proceeds through four agent-driven operators:

Pair selection picks two parent nodes based on fitness (benchmark score), correctness (reviewer judgment), and originality (novelty relative to population). Crossover merges ideas from both parents, creating a child that inherits concepts from each. Mutation comes in two flavors: exploration mutation imports ideas from adjacent scientific domains (e.g., bringing attention mechanisms into optimizer design), while correction mutation performs targeted repair using reviewer feedback on theory inconsistencies, code bugs, or runtime errors. Review agents evaluate each node on correctness and originality before it enters the population.

The key architectural choice: theory and code are separate but linked. Theory describes the algorithmic intuition in natural language; code implements it. Reviewers check both for consistency. When theory and code diverge, correction mutation uses the theory as a specification to fix the code, or updates the theory to match working code.

Population of Nodes
[Theory+Code] [Code-only] [Theory+Code] ...
      |            |            |
      v            v            v
  +-----------------------------------+
  |  Pair Selection (fitness+review)  |
  +-----------------------------------+
            |              |
            v              v
        Parent A      Parent B
            |              |
            +------+-------+
                   |
                   v
            +-------------+
            |  Crossover  |  <-- merge ideas
            +-------------+
                   |
                   v
              Child Node
                   |
        +----------+----------+
        |                     |
        v                     v
  Exploration Mut.      Correction Mut.
  (import ideas)        (fix errors)
        |                     |
        +----------+----------+
                   |
                   v
            +-------------+
            |   Review    |  <-- correctness + originality
            +-------------+
                   |
                   v
          Add to Population (if passes)

Think of CliffSearch as a scientific lab with rotating postdocs. Each node is a research proposal: some have detailed theory sections (the “why”), others are just working prototypes (the “what”). The lab director (pair selection) picks two promising proposals to combine. A senior researcher (crossover) merges their ideas into a new proposal. Then two things happen: an explorer (exploration mutation) goes to the library and brings back ideas from other fields, while a debugger (correction mutation) runs experiments and fixes what’s broken. Finally, a review committee (review agents) decides if the proposal is correct and novel enough to stay in the lab. The theory+code structure is like requiring proposals to have both a hypothesis section and an experimental protocol — you can’t just submit code and hope it works.

Key Concepts

• Theory+Code Dual Representation: Instead of treating algorithms as pure code, CliffSearch represents them as a pair: natural language theory (the intuition, the “why this should work”) and executable code (the implementation). This isn’t just documentation — the theory is a first-class artifact that reviewers check for consistency with the code. When they diverge, correction mutation uses theory as a specification to repair code, or updates theory to match working implementations. Think of it like a recipe (theory) and the actual dish (code): if the dish doesn’t match the recipe, you either fix the cooking or rewrite the recipe, but you keep both in sync.

• Reviewer-Gated Selection: Most evolutionary algorithms select based purely on fitness (does it score well?). CliffSearch adds two more gates: correctness (does it actually work as intended?) and originality (is it different from what we already have?). LLM agents act as reviewers, reading the theory, inspecting the code, checking benchmark results, and examining runtime errors. Only nodes that pass reviewer judgment enter the population. This is like peer review in science: a paper might have impressive results, but if the methodology is flawed or it’s just a minor tweak of existing work, it gets rejected.

• Split Mutation Pathways: Traditional mutation randomly tweaks code. CliffSearch splits mutation into two operators with different goals. Exploration mutation deliberately imports ideas from adjacent domains (e.g., “what if we applied attention mechanisms to optimizer design?”) to increase novelty. Correction mutation performs targeted repair: it takes reviewer feedback about what’s wrong (theory-code mismatch, runtime error, failed test) and fixes that specific issue. It’s like having two editors: one who suggests bold new directions, and another who fixes typos and logical errors. You need both, but for different reasons.

Framework Shift

Before (code-only search):          After (CliffSearch):

  Generate Code                       Generate Theory+Code
       |                                   /        \
       v                              Theory      Code
  Benchmark Score                        |          |
       |                                 v          v
       v                            Review (correctness
  Select Best                         + originality)
       |                                   |
       v                                   v
  Mutate Randomly                    Select Reviewed
       |                                   |
       +---> repeat                   +----+----+
                                      |         |
                                 Explore    Correct
                                 (import)   (repair)
                                      |         |
                                      +----+----+
                                           |
                                           v
                                      Review Again
                                           |
                                           +---> repeat

One sentence: From blind code optimization to structured co-evolution of theory and implementation under scientific review.

Expert Assessment

Problem choice: Real gap. Existing LLM-guided search systems (FunSearch, EoH) do produce uninterpretable or incorrect solutions that score well on benchmarks. The field has been moving fast on throughput but slow on interpretability and correctness. This paper addresses a genuine need for structure in automated discovery.

Method maturity: Clever architectural choices (theory+code duality, split mutation) but heavy on LLM agent orchestration. The framework is complex — four agent types, dual representation modes, multiple review stages. There’s a simpler baseline being overlooked: what if you just added a post-hoc verification step to existing code-only search? The paper doesn’t compare against “code-only + verification” to isolate the value of theory representation during evolution vs after.

Experimental integrity: Three studies (transformer hyper-connections, optimizer discovery, ablation) show the framework works, but the baselines are weak. They compare against random search and prior work (EoH), but not against “code-only CliffSearch” (same framework, no theory). The ablation study is small (native optimizer only). Benchmark results are promising but not definitive — the discovered optimizers improve over baselines, but we don’t see head-to-head comparisons with human-designed SOTA on large-scale tasks.

Writing quality: The paper front-loads framework description and under-explains the evolutionary dynamics. Section 3 (method) is dense with agent specifications but light on intuition. The case studies (Section 4) are better but arrive late. If they rewrote Section 3 to lead with a concrete example (e.g., “here’s how one node evolves through the loop”) before the formal specification, the whole paper would click faster.

Verdict: Weak accept — the structured artifact idea is valuable and the reviewer-gating mechanism is a genuine contribution, but the experimental validation needs stronger baselines and the complexity cost isn’t fully justified.

Takeaways

Dual representation for interpretability: If you’re building LLM-guided search for any domain (not just algorithms), consider maintaining both a natural language “theory” and an executable artifact. The theory acts as a specification that reviewers (human or LLM) can check for consistency. This is directly applicable to automated theorem proving, drug discovery (hypothesis + molecule), or infrastructure-as-code generation (intent + config).

Split mutation by objective: Don’t use one mutation operator for everything. Separate exploration (deliberately import ideas from other domains to increase novelty) from correction (targeted repair based on specific failure signals). This applies to any evolutionary or iterative refinement system.

Reviewer agents as selection gates: Instead of selecting purely on task metrics, add LLM agents that evaluate correctness and originality. This is a practical pattern for any automated discovery system where you care about solution quality beyond benchmark scores.

Concrete technique: The “correction mutation with evidence” pattern is immediately usable — when an LLM-generated artifact fails, don’t just retry; pass the error message, the theory, and the code to a specialized correction agent that performs targeted repair. This beats naive retry loops.