Large language models are increasingly embedded in software engineering workflows as coding agents that can inspect repositories, invoke tools, execute tests, debug failures, and generate patches. Yet most existing agents remain largely static after deployment, even though software development is a dynamic, feedback-rich process in which repositories evolve, dependencies change, tests fail, and repair attempts leave reusable experience. This tension has motivated a growing body of work on self-evolving coding agents, where the agent improves its future behavior by updating its framework, memory, skills, tools, models, or collaboration structures from prior coding interactions. In this survey, we provide a systematic synthesis of this emerging area. We first define self-evolving coding agents and distinguish them from conventional coding agents and general self-evolving agents. We then develop an object-centered taxonomy that characterizes what evolves in these systems, and complement it with two orthogonal perspectives: when evolution occurs and what software-specific evidence drives it. Across the literature, we find that executable feedback, repository-level context, and coding trajectories give software engineering a distinctive role as a natural domain for agent self-evolution, but also introduce new challenges in feedback reliability, benchmark overfitting, safety, maintainability, cost, and generalization. By organizing existing work around these dimensions, this survey aims to clarify the conceptual boundaries of self-evolving coding agents and provide a foundation for designing more adaptive, reliable, and software-aware agentic systems. The papers we collect can be found at https://github.com/zhouhao1024/Awesome-Self-Evolving-Coding-Agents.
Alex: Welcome to another episode of ResearchPod. Today, we're looking at how AI agents learn to write and fix software.
Sam: We're discussing what researchers call "self-evolving coding agents." The central puzzle is this: AI systems have gotten genuinely capable at writing code, but they almost always stay frozen after they're built. They don't learn from their mistakes or get better over time.
Alex: So this paper is asking how we move from static assistants to agents that actually grow as they work on real projects?
Sam: Exactly. And the researchers argue that software development is actually the ideal place to test this kind of learning—because of something they call "executable feedback."
Alex: What do you mean by that?
Sam: Think about the difference between a teacher's opinion and a math test. A teacher might say your essay is "pretty good," and you could argue about it. But a math test has a definite right or wrong answer. Software works the same way. You run the code, and the computer tells you immediately: it either works or it crashes. That clear, objective signal—pass or fail—is what they mean by executable feedback. An agent can't argue with it, and it can't fake it.
Alex: That's a useful distinction. It's like learning to play a video game where the game itself tells you the instant you hit a wall. So how do these agents actually use that signal to evolve?
Sam: The researchers lay out what they call an "object-centered taxonomy"—which is really just a structured way of asking: what part of the system are you actually improving? Think of a mechanic's garage. You could make the garage better by buying new tools, rewriting the repair manual, retraining the mechanics, or reorganizing the workflow. Each of those is a different kind of improvement, even if the goal—fixing cars—stays the same.
Alex: Oh—so they've mapped out exactly which component of the AI is being updated. The tools, the memory, the procedures...
Sam: Right. They identify four main targets: the agent's core framework, its memory, its library of reusable skills, and its workflow. By being precise about which one is changing, researchers can finally compare different techniques on equal footing. Before this kind of taxonomy, it was hard to know if two approaches were even solving the same problem.
Alex: And I assume that clarity also helps researchers spot where things can go wrong?
Sam: It does—and the risks are real. The paper highlights something called "benchmark overfitting." Imagine a student who memorizes every past exam paper but can't solve a problem they've never seen before. An agent can fall into the same trap: it gets very good at passing the specific tests it was trained on, but that skill doesn't carry over to real-world problems. And the stakes are higher when the agent starts rewriting its own code, because a mistake there isn't just a wrong answer—it could introduce a security flaw or break something that was working fine.
Alex: So it's not just about making these agents smarter. It's about making sure they don't quietly break the systems they're supposed to be improving.
Sam: Precisely. Which brings us to how learning actually happens in practice.
Alex: Right—if an agent fixes a bug, how does it turn that experience into a skill it can use again later?
Sam: That's the core of what the paper calls "experience memory." When an agent successfully solves a task, it saves the entire trajectory—the sequence of steps, tool calls, failed attempts, error messages, and the specific commands that finally worked. It's like keeping a detailed lab notebook rather than just noting the final answer.
Alex: And then it can refer back to that notebook the next time it hits a similar problem?
Sam: Exactly. The agent distills those logs into reusable procedures. Instead of just remembering one specific fix, it builds a general rule for handling that type of problem in the future. The key word there is "general"—a skill that only works on one specific file isn't really a skill, it's just a shortcut.
Alex: So how do we know whether the evolution is actually making the agent better, rather than just more confident?
Sam: That's the central challenge. The paper calls it the "feedback reliability" trap. If the logs the agent learns from are flawed—say, a fix that passes a test today but introduces a subtle bug tomorrow—then the agent will train itself on bad information. It can drift into a state where it's consistently making poor decisions while appearing to perform well on standard tests.
Alex: So the agent could get very good at gaming the tests while actually making the code worse underneath.
Sam: That's exactly the concern. Which is why the researchers argue that measuring success requires more than just "did it pass?" You have to track whether the agent's new skills actually transfer to unfamiliar problems, and whether the cost of those updates—in time, compute, and risk—is justified by the improvement.
Alex: It sounds like the field is moving toward a more demanding standard. Not just "can the AI code?" but "can the AI maintain code reliably over months, without accumulating hidden errors?"
Sam: That's a good way to put it. The goal is to move away from agents that treat every task as a blank slate, toward systems that build a stable, audited library of experience. The evolution itself needs to be treated with the same care and scrutiny as the code it produces.
Alex: So the future isn't just more powerful models—it's better ways to audit and constrain how they change over time.
Sam: That's the direction the paper points toward. The shift from static tools to adaptive agents only works if we can trust the process of adaptation. Otherwise, we're just building systems that get harder to understand as they get more capable.
Alex: That's a useful frame. It's not just about what the agent can do today—it's about whether the way it learns is itself trustworthy. Thanks for walking me through this.
Sam: It's a good question to sit with. Thanks for listening to ResearchPod.