Most coding agents go stale the moment you deploy them. The repo keeps moving — dependencies bump, tests break, past repair attempts leave reusable experience on the floor — and a static agent relearns nothing from any of it. That gap is what “self-evolving coding agents” try to close, and this new survey is worth reading less for the promise than for the map it draws of how that evolution goes wrong.
The arXiv survey organizes the field by what actually changes in these systems: the agent’s framework, its memory, its skills, its tools, its underlying models, or the way multiple agents collaborate. It then layers on when evolution happens and what software-specific evidence drives it. The useful claim is that executable feedback, repository-level context, and coding trajectories give software engineering a genuinely distinctive signal — an agent can run the tests and know, concretely, whether it improved. The HF paper page collects the underlying papers.
The failure list is where I’d spend my attention. The survey names feedback reliability, benchmark overfitting, safety, maintainability, cost, and generalization — and in production those aren’t footnotes, they’re the whole risk surface. An agent that rewrites its own tools and memory is an observability problem before it’s a capability win: you now have to version, diff, and roll back a moving target. Benchmark overfitting is the quiet one — a green eval dashboard may just mean the agent learned the test harness, not the task. And “improves from prior interactions” only holds if the feedback grading those interactions is trustworthy, which, going by the reward-model literature, is not a safe assumption.
Would you let an agent silently mutate its own toolset in a repo you’re on call for — and if not, what’s the smallest slice of self-evolution you’d actually ship?