A Fresh Survey of Self‑Evolving Coding Agents

Introduction

Coding agents such as Codex, Claude Code, and Cursor can read repositories, run tests, and generate patches, but after deployment they usually remain static because their models, prompts, and tools are fixed. Software development, however, is dynamic: code evolves, dependencies change, and tests fail, leaving experiential traces after each fix. Without a mechanism to accumulate these traces, agents repeatedly fall into the same pitfalls.

Self‑Evolving Coding Agents

Self‑evolving coding agents are designed to update their own framework, memory, skills, and even model based on interaction feedback, repository context, and coding trajectories. This makes software engineering a natural testbed for evolutionary research, while also introducing new challenges in reliability, over‑fitting, safety, and cost.

Research Questions

RQ1: Which components of coding agents evolve and through what mechanisms?

RQ2: When does evolution occur, and what software‑engineering‑specific evidence drives it?

RQ3: How should self‑evolving coding agents be evaluated beyond task success rate, considering reliability and generalization?

1. Taxonomy: What Evolves?

The article classifies evolution targets into five categories, illustrated in Figure 2.

3.1 Framework Self‑Evolution

This most aggressive class treats the coding agent itself as a mutable software artifact. The pioneering work SICA (Self‑Improving Coding Agent) equips an agent with basic development tools, allowing it to edit its own codebase, discover new prompts or tools, and validate modifications on coding benchmarks. SIFT improves sample efficiency by using an LLM‑as‑a‑judge signal and lightweight tree search to prioritize promising patches.

3.2 Memory Self‑Evolution

Memory serves as the central hub for accumulating cross‑task software‑engineering experience. “Memory self‑evolution” goes beyond logging chats; it continuously builds, refines, and reuses experience: deciding what to store, how to abstract it, when to update, and how to retrieve it for future actions. Examples include:

SWE‑Exp builds an experience library from issue‑fix trajectories (including failed attempts) to guide locating strategies, patch decisions, and lessons learned.

EvoCoder creates a hierarchical experience pool distinguishing generic from repository‑specific knowledge for defect reproduction.

Subtask‑Level Memory stores experience at the granularity of analysis, localization, editing, and verification, avoiding coarse‑grained matching.

Repository Memory captures the evolving state of a codebase—historical commits, linked issues, and frequently changed regions—to support future code localization.

3.3 Skill and Tool Self‑Evolution

While memory records “what happened,” skills and tools encode “what to do next.” Representative efforts:

CODESKILL extracts, evolves, and maintains a skill library from raw agent trajectories, separating high‑level task flows (e.g., repository inspection) from event‑driven responses (e.g., command failures).

GSkill learns concise “on‑boarding documents” for a specific repository—architecture, coding standards, test procedures, common pitfalls—and uses SWE‑smith to generate verifiable tasks, iterating via an evolution loop that runs the agent, checks patches, and refines the skill set.

Socratic‑SWE distills historical solution traces into an Agent Skill Registry, registering recurring failure and successful repair patterns to guide targeted repair tasks during training.

3.4 Model Self‑Evolution

This class modifies model‑side components (base model, adapters, policies, reward models, validators). Ordinary fine‑tuning is not considered self‑evolution; only when software‑specific experience is fed back into components that decide future behavior does it qualify. The strongest form is training signals generated entirely by the agent’s own software interactions:

Self‑play SWE‑RL couples bug generation, bug fixing, and executable verification: the agent creates bugs in real repositories, fixes them, and uses the verified results to improve subsequent solvers.

Agent‑RLVR lets the agent produce trajectories, receive guidance and environmental rewards, then update its policy via guided retries.

Other works such as ReVeal , CURE , ZeroCoder , Sol‑Ver , and ACE explore co‑evolution of code generation and verification, often using adversarial unit‑test generation and preference optimization.

3.5 Workflow and Topology Self‑Evolution

The most macro‑level class evolves the organization of the agent system itself. Early systems like ChatDev , MetaGPT , and AgentCoder demonstrate the value of role division, but their role assignments and message paths are hand‑crafted. Newer systems treat these structures as mutable objects:

SEMAG coordinates planning, coding, debugging, and discussion based on task difficulty.

SEW jointly evolves prompts, tools, and workflow topology, allowing different coding tasks to use distinct pipelines.

AFlow searches the space of code‑centric workflows with Monte‑Carlo tree search.

EvoAgentX packages joint optimization of prompts, tools, and workflow topology into a generic evolution framework.

AgentConductor makes the “right amount of collaboration” explicit by generating a communication DAG whose density adapts to task difficulty.

2. Orthogonal Perspectives: When and What Evidence Drives Evolution

4.1 Evolution Timing

Three temporal patterns are identified:

Task‑time evolution : Adjustments happen during the current task based on immediate feedback (e.g., test failures). Examples include Live‑SWE‑Agent which creates tools while fixing issues, and SEMAG / AgentConductor which adapt collaboration on‑the‑fly.

Post‑task evolution : After a task finishes, trajectories are abstracted into persistent experience, knowledge, or repair skills (e.g., memory libraries, skill distillation). This is slower but enables cross‑task transfer.

Stage‑wise evolution : After accumulating a batch of validated trajectories, they are aggregated to form a new base model or strategy for the next generation. This is the slowest but yields lasting cross‑generation improvements.

4.2 Evolution Evidence

Evidence sources are categorized from coarse to fine granularity:

Result evidence : Observable performance metrics such as benchmark success rate or test pass rate. Used by SICA and Gödel Machine series to select superior variants, but it does not explain why a variant is better.

Environment feedback : Local signals from compilation diagnostics, runtime exceptions, and test logs that indicate success or failure under specific conditions. Essential for intra‑task adaptation but requires abstraction for long‑term evolution.

Trajectory‑derived evidence : Full operation logs that reveal “how” a result was achieved. Though difficult to process and not immediately actionable, they can be abstracted into reusable experience, skills, and memory, offering the highest value.

Self-Evolving Coding Agents
https://arxiv.org/abs/2608.03392v1
https://github.com/zhouhao1024/Awesome-Self-Evolving-Coding-Agents