Self-Evolving Coding Agents
Hao Zhou, Haichuan Hu, Ye Shang, Quanjun Zhang
cs.SE
2026-08-04
Coding agents stay fixed after deployment; software engineering is feedback-rich and ideal for self-evolution. This survey splits 26 systems into five classes by what evolves. Thesis: evolving is easy, trust is hard.
Mainstream coding agents (SWE-agent, OpenHands and the like) can read repos, edit files, run tests and submit patches, but after deployment they are largely static: the base model, prompts, tool interfaces, memory and control flow are all fixed. That clashes with real software engineering. Codebases keep changing, dependencies get upgraded, tests fail, and bug-fix attempts themselves accumulate experience. If an agent cannot learn from this feedback, it repeats the same mistakes across tasks. Software engineering is a natural testbed for self-evolving agents precisely because its feedback is far more concrete than in general tasks: unit tests, compiler errors, runtime traces, CI logs and code reviews are all executable and reproducible signals. This survey sets out to clarify the still-forming concept of the self-evolving coding agent.
The survey organizes the literature in three layers, centered on an object-oriented taxonomy that classifies systems by which part of the agent actually evolves, into five categories.
Agent-framework self-evolution: the agent treats its own scaffold source code as a modifiable artifact, editing it and validating with tests. Representatives are SICA, SIFT, STOP, and the Darwin Godel Machine lineage (maintaining many agent variants for open-ended evolution). The most aggressive category, and the riskiest for reliability.
Memory self-evolution: abstracting issue-resolution trajectories into retrievable experience, repository knowledge, or repair experience. SWE-Exp, EvoCoder, Subtask Memory, EvoRepair (vulnerability repair), Repository Memory.
Skill and tool self-evolution: distilling trajectories into reusable procedural skills, or even having the agent build its own tools. CODESKILL, GSkill, Socratic-SWE, EffiSkill, Live-SWE-Agent (building tools mid-task).
Model self-evolution: changing weights, policy, or verifiers, with feedback closing the loop on the model side. Self-play SWE-RL, Agent-RLVR, and coder-verifier co-evolution (ReVeal, CURE, ZeroCoder, Sol-Ver), plus adversarial testing (ACE).
Workflow and topology self-evolution: evolving multi-agent collaboration structures and workflow graphs. SEMAG, EvoMAC, AgentConductor, SEW, AFlow.
Two orthogonal dimensions round this out. "When evolution happens" splits into task-time (adapting mid-task), post-task (turning a finished run into reusable experience or skills), and stage-wise (accumulating a batch before a model update, closest to cross-generation self-improvement). "What evidence drives it" splits into outcome evidence (benchmark solve rate, test pass rate; provides selection pressure but is coarse), environmental feedback (compiler, test, runtime logs; local and in-task), and trajectory evidence (the full attempt record; needs abstraction to reuse).
The authors repeatedly draw a line: not every SWE-oriented post-training run counts as self-evolution, only when the learning signal closes the loop on the agent's own attempts, self-generated tasks, or interaction outcomes. SWE-RL, SWE-Gym and SWE-RM are therefore classified as infrastructure or model optimization, not complete self-evolving agents.
The survey runs no experiments; its findings are judgments distilled from 26 representative systems. Software engineering offers concrete feedback unavailable elsewhere (executable artifacts plus repository-level context plus trajectories), which is its fundamental edge over general self-evolving agents. Among the five objects, the closer a method gets to "modifying the agent itself" (framework, model), the larger the potential gain but also the higher the reliability, safety and overfitting risk; the closer to "store and retrieve" (memory, skill), the safer but the lower the ceiling. A counterintuitive point is stressed repeatedly: generating more data is not evolution. Recent self-play analysis shows sustainable improvement requires learnable information gain across iterations, or the loop merely reinforces existing biases or produces redundant tasks. Evaluation today is strong on functional correctness (pass rate, resolve rate, Pass@k) but weak on maintainability, safety, long-term reliability, and generalization beyond the evolved setting; repository-level benchmarks (the SWE-bench family) are the main arena, with function-level and competitive programming as supplements. The central thesis in one line: the real challenge is making evolution trustworthy, not making it possible.
It provides a usable map: if you build coding agents and want to add "learning", the three dimensions (object, timing, evidence) help you locate your own system and find comparable work. It draws a clear boundary between self-evolution and ordinary SWE post-training, a line useful for anyone writing papers or making claims, since it keeps infrastructure work like SWE-RL from being misread as a complete self-evolving agent. It also frames trustworthiness as the top concern and points out that unreliable feedback compounds along memory, skill, workflow and model: a wrong test does not affect only one patch, it gets stored in memory, distilled into a skill, and used to update policy. That is a sobering note for teams heading to production. A continuously updated awesome list accompanies it.
This is a guiding synthesis rather than a final verdict on a mature paradigm; the authors themselves say the field's boundaries are still fluid, the taxonomy has subjective elements, and the five classes are not mutually exclusive (one system often evolves several objects). The selection criteria for the 26 representative systems are not fully spelled out, so there may be omissions or bias. There is no unified horizontal comparison, such as a side-by-side resolve-rate table on SWE-bench; the classification is qualitative, which offers limited help to readers who want to know "which path is strongest right now". The open problems the survey raises (benchmark overfitting, feedback reliability, long-term memory maintenance, cross-domain generalization) are mostly posed, not solved, and remain far from engineering maturity. Safety and alignment risks of self-evolution (an agent editing its own scaffold could break the agent loop or exploit weaknesses in the evaluation harness) are mentioned but not developed.