Functionality-Oriented Code Self-Evolution

• Functionality-Oriented Code Self-Evolution is a paradigm where code autonomously evolves based on execution feedback, proof obligations, and environmental signals.
• It employs iterative evolution loops, repository-level reuse, multi-agent architectures, and source-level self-rewriting to ensure functional correctness.
• Empirical studies demonstrate measurable performance gains by extending system capabilities beyond traditional parameter tuning and adapting to new requirements.

Functionality-Oriented Code Self-Evolution denotes a family of methods in which code, code-related artifacts, or software architectures are iteratively modified in response to signals tied to behavior: execution results, proof obligations, hidden tests, requirement changes, environment validity, or structured downstream task outcomes. In the recent literature, the evolved object ranges from an intermediate program revised under interpreter feedback, to a persistent repository of reusable modules, to a source-level agent harness, to synthesized datasets designed to stress functional semantics rather than surface similarity (Jiang et al., 2023, Li et al., 27 Aug 2025, Cai et al., 21 May 2026). A recurring distinction is that between ordinary adaptation within a pre-engineered envelope and evolution that extends the system’s reachable capabilities, goals, or executable mechanisms (Weyns et al., 2023, Robol et al., 29 Apr 2026).

1. Conceptual scope and relation to adaptation

A precise conceptual boundary is given by the Operational Design Domain (ODD). In this formulation, a system’s design envelope is the set of working points that satisfy its requirements, constraints, and context:

$$ODD_{S} = \{(u,c)~|~(u,c).sat(R,B,C)_{S}\,\land\,c \in C\,, u \in U\}.$$

Within $ODD_S$, self-adaptation can move among already engineered alternatives; outside $ODD_S$, the system requires evolution because new goals, contexts, or utility levels demand capabilities not present in the original design. The evolved envelope is expressed as

$ODD_{Se} = ODD_{Si} \cup ODD_{e},$

where $ODD_e$ is the evolution target (Weyns et al., 2023). This makes “functionality-oriented” evolution fundamentally capability-centered rather than parameter-centered.

The same distinction appears in agent architectures. “Self-Evolving Software Agents” describes conventional autonomous agents as adaptive but still bound to goals, requirements, and executable capabilities fixed at design time; its proposed BDI–LLM architecture adds an automated evolution module that can revise knowledge representation, goal generation and decision making, and execution itself by synthesizing new executable actions and code (Robol et al., 29 Apr 2026). A plausible implication is that functionality-oriented self-evolution is best viewed as a layered process in which requirement change, reasoning change, and code change may be coupled rather than isolated.

Earlier precursors approached the problem from language and self-modification perspectives. “Self-composable Programming” describes a language-driven, composition-based variability implementation with a hierarchical relationship of behavior through “abstract function” and “specific function,” and compares this object-oriented treatment of function to Aspect-oriented Programming (Kim, 2016). In parallel, the allagmatic line of work formalizes runtime self-modification as controlled transformation of functionality-bearing code blocks within a fixed metamodel, preserving a distinction between stable structural categories and mutable concrete rules (Christen, 2022, Christen, 2022).

2. Evolution loops and architectural patterns

Across systems, the literature suggests several recurrent architectural forms. One form is inference-time code evolution. “SelfEvolve” decomposes code generation into explicit knowledge generation followed by execution-guided revision. Given task description $d$ and context $c$, it first externalizes task-relevant knowledge $K$ and generates code conditioned on that knowledge,

$$P(Y|K)=\prod_{i=1..n} p_{\theta}(Y_i|Y_{<i}, X, K),$$

then revises the intermediate solution using execution feedback $e$,

$ODD_S$0

The loop repeats until the code can be interpreted without exceptions or a fixed iteration threshold is reached (Jiang et al., 2023).

A second form is repository- or system-level accumulation of reusable functionality. “AI-Driven Self-Evolving Software” proposes a four-part multi-agent architecture—Leader, Data Manager, Code Generator, and Code Validator—in which a user request is first checked against existing repository contents, then either satisfied by reuse or by generating, validating, and integrating a new module. Validation is based on multiple candidate programs $ODD_S$1 and generated test inputs $ODD_S$2, scored with disagreement and error counts:

$ODD_S$3

$ODD_S$4

$ODD_S$5

with lexicographic selection of the final candidate (Cai et al., 1 Oct 2025).

A third form is specialized multi-agent evolution over functional domains. “MobileSteward” replaces stage-only decomposition with a centralized StewardAgent plus app-oriented StaffAgents. It decomposes a user instruction $ODD_S$6 into app-specific subtasks, builds a scheduling graph, and executes tasks in topological order. Evaluation is not terminal: on success it extracts result information $ODD_S$7 and rewrites successor tasks; on failure it returns reflection tips for local retry (Liu et al., 24 Feb 2025).

A fourth form is source-level self-rewriting of the agent substrate itself. “MOSS” argues that prompt, skill, memory, and workflow mutation leave the harness untouched, whereas routing, hook ordering, state invariants, and dispatch reside in code. Its system therefore evolves by automatically curating a production-failure batch, running a deterministic seven-stage pipeline—Locate, Plan, Plan-Review, Implement, Code-Review, Task-Evaluate, Verdict—and verifying candidate images through replay on isolated trial workers before user-consent-gated promotion and rollback-guarded container swap (Cai et al., 21 May 2026).

System	Evolved artifact	Functional validation
SelfEvolve (Jiang et al., 2023)	Intermediate code under iterative revision	Interpreter errors, assertions, sandbox execution
AI-Driven Self-Evolving Software (Cai et al., 1 Oct 2025)	Persistent scripts/modules plus metadata	Candidate agreement and execution behavior
MobileSteward (Liu et al., 24 Feb 2025)	App-task execution and task routing state	Adjusted evaluation with retries and downstream adjustment
MOSS (Cai et al., 21 May 2026)	Source-level harness code	Replay on candidate images, health-probed deployment

3. Functional feedback and verification regimes

The defining feature of the field is that improvement is driven by behavioral evidence rather than textual resemblance. In “SelfEvolve,” the most important signals are interpreter error information, standard output from sandbox execution, API errors, and incorrect assertion statements. The method explicitly distinguishes executability from hidden-test correctness: fixing syntax and runtime failures does not by itself prove semantic correctness, but improvements on those fronts translated into higher benchmark pass rates (Jiang et al., 2023).

Other systems use stronger or different behavioral oracles. “SAFE” turns formal verification into the evolutionary signal for proof generation over Verus-annotated Rust. Instead of evolving end-user application logic, it evolves the model’s ability to produce verification artifacts. Correct proofs are filtered by the Verus verifier, while incorrect proofs become self-debugging supervision through triplets of the form

$ODD_S$8

The overall proof loop alternates generation, verifier filtering, debugging, and fine-tuning, using proof correctness as a functionality signal stronger than sampled test execution (Chen et al., 2024).

A third regime is trace-based behavioral equivalence across versions. “Erlang Code Evolution Control” defines preservation not by whole-program output equality but by equality of traces at a developer-chosen point of interest. For an input test case, the observed output is “the sequence of those values the POI is evaluated to during the execution.” Two versions preserve the selected functionality when they produce the same trace at the corresponding POI for every generated input (Insa et al., 2017). This makes internal observable behavior itself the specification target.

A fourth regime appears in environment construction. SetupX studies “functionality-correct repository setup,” formalizing validity of an environment $ODD_S$9 for repository $ODD_S$0 by requiring a reproducible container image and absence of setup-induced failure on all declared functionality-oriented execution targets:

$ODD_S$1

Its Prosecutor-Judge protocol separates evidence collection from final judgment, specifically to distinguish setup-induced failures from repository-intrinsic bugs (Zhou et al., 25 May 2026).

A plausible synthesis is that functionality-oriented self-evolution spans at least four oracle types: sampled execution, symbolic verification, trace equivalence, and deployment-environment validity. The common denominator is that the signal comes from what the artifact does, not from how similar it looks to a reference.

4. Memory, reuse, and transfer

Many recent systems treat self-evolution not as weight updates but as structured experience accumulation. SetupX is the clearest example. Its eXPerience Unit is defined as

$ODD_S$2

combining diagnostic signals, natural-language advice, executable atomic operations, and deployment statistics. Retrieved XPUs are ranked partly by past effectiveness, and telemetry is updated by delayed audit:

$ODD_S$3

This makes memory a live policy component rather than a passive log (Zhou et al., 25 May 2026).

“MobileSteward” separates routing memory from execution memory. The StewardAgent maintains Staff Expertise Memory $ODD_S$4, while StaffAgents retrieve from Task Guideline Memory $ODD_S$5. Successful execution updates both:

$ODD_S$6

$ODD_S$7

This dual-memory design is notable because it distinguishes “who should handle this” from “how a similar task was previously executed” (Liu et al., 24 Feb 2025).

“Controlled Self-Evolution for Algorithmic Code Optimization” introduces a hierarchical evolution memory with both intra-task local memory and inter-task global memory. Parent selection is reward-proportional,

$ODD_S$8

and each evolutionary step stores its gain

$ODD_S$9

for later reflection and distillation. The paper reports that memory is most useful when combined with controlled mutation and crossover rather than used in isolation (Hu et al., 12 Jan 2026).

Repository-level persistence appears in “AI-Driven Self-Evolving Software,” where the Data Manager stores source files and metadata in a hierarchical JSON representation of the file system, enabling later inspection, execution, and reuse of previously generated modules (Cai et al., 1 Oct 2025).

The notion of self-evolution also extends to dataset construction. “Functional Consistency of LLM Code Embeddings” defines “Functionality-Oriented Code Self-Evolution” as an overview framework that starts from one code instance $ODD_{Se} = ODD_{Si} \cup ODD_{e},$0, chooses an evolution direction $ODD_{Se} = ODD_{Si} \cup ODD_{e},$1, and generates

$ODD_{Se} = ODD_{Si} \cup ODD_{e},$2

It systematically spans four pair types—Type I through Type IV—so that datasets include semantically equivalent but syntactically different positives and, crucially, syntactically similar but semantically inconsistent negatives (Li et al., 27 Aug 2025). This broadens the term beyond deployed software evolution to the evolution of training and evaluation corpora around functional semantics.

5. Evaluation regimes and empirical landscape

Empirical results are heterogeneous because the field evaluates different evolved artifacts under different oracle types, but several systems report substantial gains under functionality-grounded metrics.

System	Setting	Reported outcome
SelfEvolve (Jiang et al., 2023)	DS-1000, HumanEval, TransCoder	DS-1000 pass@1: 49.30 → 57.10; HumanEval pass@1/pass@10: 66.46/86.58 → 78.05/93.29; TransCoder computational accuracy/pass@1: 92.7/90.0 → 94.8/92.4
SAFE (Chen et al., 2024)	VerusBench and CodeNet-Test	DeepSeekCoder SAFE+: 49.64% @1 and 70.50% @10 on VerusBench; LLaMA3.1 SAFE+ reaches 52.52% @1
SetupX (Zhou et al., 25 May 2026)	100 Python repositories	92% pass rate; +19 percentage points over Claude Code; +33 points over ExecutionAgent
MaintainCoder (Wang et al., 31 Mar 2025)	Dynamic requirements	Maintains higher correctness while improving maintainability metrics by 14–30%; reports 46.5% reduction on average in adaptation costs
CSE (Hu et al., 12 Jan 2026)	EffiBench-X	On GPT-5 average MI: 59.13 → 67.47; on DeepSeek-v3 average MI: 48.62 → 55.09
MOSS (Cai et al., 21 May 2026)	OpenClaw four-task batch	Mean claweval score: 0.2526 → 0.6100 in one cycle

Benchmark work has also shifted toward trajectory-level evaluation. EvoCodeBench defines self-evolving coding systems as agents that improve “during inference” by iteratively refining candidate programs, repairing failures with execution feedback, and reusing intermediate artifacts while keeping task specification, prompt schema, evaluation interface, and model parameters fixed. It evaluates pass rate, failure categories, runtime, memory, average passed cases, and human-relative efficiency across Python3, C++, Java, Go, and Kotlin (Zhang et al., 10 Feb 2026). Its standard evolving-agent comparison for gemini-3-flash-preview shows pass-rate increases in all five languages—Python3 79 → 87, C++ 84 → 99, Java 84 → 98, Go 82 → 95, Kotlin 75 → 95—together with faster accepted solutions in every language, though memory improves only in some of them (Zhang et al., 10 Feb 2026).

For embedding evaluation, the dataset-synthesis strand reports equally large effects. On the functional consistency task, bge-en-icl improves from mean F1 0.5426 to 0.8131 after alignment with the evolved POJ-Evl dataset, while the hardest Type IV category rises from 0.0291 to 0.5595 (Li et al., 27 Aug 2025). This is important because it shows that self-evolution can target functional semantics even when the output artifact is a benchmark rather than a deployed program.

The evaluation literature therefore supports a broad empirical claim: when the feedback channel is genuinely functionality-grounded—tests, proof verifiers, hidden judges, deployment replay, or requirement-driven edit effort—iterative evolution can produce measurable gains not captured by one-shot code generation alone.

6. Control, limitations, and open problems

A recurring misconception is that self-evolution implies unrestricted self-modifying code. The literature instead emphasizes control. The allagmatic work restricts self-modification to specific regions and specific code–data transitions, such as update rules $ODD_{Se} = ODD_{Si} \cup ODD_{e},$3 interpreted by an update function $ODD_{Se} = ODD_{Si} \cup ODD_{e},$4, rather than allowing arbitrary rewriting of the whole program (Christen, 2022). “Self-Modifying Code in Open-Ended Evolutionary Systems” similarly distinguishes a fixed metamodel layer from a more concrete modifiable layer, so that executable change remains interpretable as variation in entities, milieus, update rules, and adaptation rules rather than unconstrained mutation (Christen, 2022). MOSS adds build gates, isolated trial workers, user-consent-gated promotion, and health-probe-based rollback (Cai et al., 21 May 2026).

A second limitation is shallowness of many current loops. SelfEvolve reports that one debugging turn is often enough on HumanEval and TransCoder and that DS-1000 benefits only up to around three iterations; the evolved object is therefore practical but shallow rather than long-horizon autonomous improvement (Jiang et al., 2023). EvoCodeBench’s own standardized self-evolving agent uses at most three reflection/revision rounds (Zhang et al., 10 Feb 2026). MaintainCoder studies maintainability under requirement change, but its experiments use GPT-4o-mini as the common downstream modifier for all systems; the paper therefore shows that MaintainCoder-generated code is easier to evolve, not that MaintainCoder itself performs long-horizon autonomous maintenance (Wang et al., 31 Mar 2025).

A third limitation is the narrowness of many verification signals. SelfEvolve explicitly focuses on API errors and incorrect assertion statements (Jiang et al., 2023). SAFE depends on Verus, Rust, and mostly function-level proof obligations (Chen et al., 2024). SetupX’s main benchmark is Python-only and single-run containerized setup (Zhou et al., 25 May 2026). MOSS verifies against a curated replay batch and reports no held-out regression suite (Cai et al., 21 May 2026). These constraints do not invalidate the systems, but they limit how far current evidence can be generalized.

A fourth issue is stability and inheritance. “Self-Evolving Software Agents” reports feasibility but also current limits in behavioral inheritance and stability, especially as environmental complexity increases (Robol et al., 29 Apr 2026). The ODD literature likewise leaves open how to realize warehouse search, anomaly detection, synchronized enactment, and human guidance in a full self-evolving architecture (Weyns et al., 2023). A plausible implication is that the field has stronger evidence for local repair, optimization, and adaptation loops than for durable cumulative software evolution over long operational horizons.

Open problems follow directly from these limitations. The literature points toward richer dynamic analysis and multilingual validation for functional consistency datasets (Li et al., 27 Aug 2025), stronger assurance and benchmark design for autonomous software growth (Cai et al., 1 Oct 2025), cost-aware and convergence-aware evaluation of adaptive coding agents (Zhang et al., 10 Feb 2026), retrieval-augmented reasoning and cooperative evolution for self-evolving agents (Robol et al., 29 Apr 2026), and ODD-based evolution targets for systems that must decide when adaptation is insufficient and true capability extension is required (Weyns et al., 2023). Taken together, these works indicate that functionality-oriented code self-evolution is no longer a single technique but an emerging research area organized around one central question: how to make code change itself, or change its supporting artifacts, in ways that are judged by realized behavior rather than by textual plausibility alone.