Source-linked AI summary

A Self-Improving Coding Agent

Maxime Robeyns, Martin Szummer, Laurence Aitchison

arXiv:2504.15228v2cs.AI

TL;DR

The paper asks whether an LLM coding agent can autonomously improve its own code instead of relying on separately designed agent orchestrators. SICA lets the agent edit its codebase, and the authors report benchmark gains, including an increase from 17% to 53% on a random subset of SWE-Bench Verified.

  • Problem

    The paper asks whether coding agents can autonomously modify and improve their own code, rather than relying on hand-crafted orchestrators or separate meta-agents.

    Source: §1 · p. 1
  • Method

    SICA uses an agent to edit its full codebase, repeatedly selecting an archived high-performing agent to propose and implement improvements.

    Source: §1 · p. 2, §3 · p. 3
  • Results

    Improvements appeared across agentic tasks; performance on a random subset of SWE-Bench Verified rose from 17% to 53%, while LiveCodeBench saw a subtle improvement.

    Source: §5 · p. 7, §4 · p. 7
  • Takeaways & Limitations

    SICA offers a practical approach to automated agent-system design and a foundation for future work jointly training foundation models with their agent systems.

    Source: §5 · p. 7

    Generating novel, feasible improvement ideas is difficult, and early poor-quality suggestions can steer later suggestions toward the same theme and lower their quality.

    Source: §5.1 · pp. 7–8

Abstract

from arXiv · show

Recent advancements in Large Language Models (LLMs) have spurred interest in deploying LLM agents to undertake tasks in the world. LLMs are often deployed in agent systems: code that orchestrates LLM calls and provides them with tools. We demonstrate that an agent system, equipped with basic coding tools, can autonomously edit itself, and thereby improve its performance on benchmark tasks. We find performance gains from 17% to 53% on a random subset of SWE Bench Verified, with additional performance gains on LiveCodeBench, as well as synthetically generated agent benchmarks. Our work represents an advancement in the automated and open-ended design of agentic systems, and demonstrates a data-efficient, non gradient-based learning mechanism driven by LLM reflection and code updates.

1 Introduction

LLM agents combine models with code that orchestrates calls and exposes tools, but their architectures and prompting strategies have largely been hand-crafted. This paper proposes an agent that edits its own code and reports improved benchmark performance.

1 Introduction

  • Agent systems orchestrate LLM calls and expose tools for taking actions, and often outperform plain LLMs through prompting and output-combination strategies.The cited strategies range from best-of-N and chain of thought to more sophisticated multi-step methods.Source: §1 · p. 1
  • The paper asks whether coding agents can discover prompting schemes or tools and improve their own code, rather than relying on hand-crafted orchestrators.Unlike ADAS [16], which uses separate target and meta agents, SICA makes the system self-referential, with the hope that coding improvements can compound across later steps.Source: §1 · p. 1
  • 17% to 53% performance on a random subset of SWE-Bench Verified is the reported gain from self-referential agent improvements.The authors also describe the agent as capable of editing its codebase to improve cost, speed, and benchmark performance.Source: §1 · p. 2
  • SICA removes the distinction between meta-agent and target agent, allowing the agent to edit its own codebase.The implementation is in standard Python and is shared as a reference framework.Source: §1 · p. 2

2 Related Work

Prior work improves agents through manually designed strategies, language-based optimization, and automated search over agent designs. This paper distinguishes its approach by having an agent edit its full codebase rather than using a separate meta-agent or a restricted design space.

2 Related Work

  • Hand-crafted approaches include prompting and reflection methods [23], tool-use frameworks [33], and compositional agent systems [38] [1], but require human effort and may miss patterns automated search could find.The section also notes manually created strategies such as Chain-of-Thought prompting, self-refinement [23], and self-reflection.Source: §2 · p. 2
  • MaestroMotif [19] learns skill rewards from LLM feedback and combines skills through code generation, alongside earlier work on internally motivated skills and open-ended exploration [48] [12].Source: §2 · p. 2
  • OPRO [41] and Promptbreeder optimize prompts through language, while other work uses LLMs for critique, curriculum generation, or reinforcement-learning feedback [18].Editing the full codebase also lets SICA tune its own prompts.Source: §2 · p. 2
  • AgentSquare [35] searches combinations of planning, reasoning, tool-use, and memory modules, while AlphaEvolve uses coding for scientific discovery and infrastructure optimization; both lean more on structured evolutionary search.Source: §2 · p. 3
  • ADAS [16] uses separate target and meta agents, with the meta-agent editing one forward function in a domain-specific language; SICA edits its full Python codebase.SICA has no distinction between target and meta agent.Source: §2 · p. 3
  • Earlier self-improvement claims include Gödel Agent and Zelikman et al. [47], but their evaluations use language-understanding, math, or algorithmic tasks rather than general-purpose coding-agent tasks.The authors distinguish those systems from coding agents that can work on arbitrary software-engineering tasks.Source: §2 · p. 3

3 Methods

SICA iteratively evaluates agents, selects a strong archived agent to propose and implement an improvement, and stores the resulting benchmark performance. Its initial coding agent combines coding tools, sub-agents, and oversight mechanisms to support autonomous runs.

3 Methods

  • The loop evaluates each agent on benchmarks and archives its results, then uses the highest-utility archived agent as meta-agent to propose and implement an improvement.The selected agent is the best performer so far; the resulting agent is evaluated and its results are stored.Source: §3 · p. 3, §3.1 · p. 5
  • Utility combines normalized benchmark performance, dollar cost, and wall-clock time, weighted 0.5, 0.25, and 0.25, respectively.Cost is capped at $10 per problem, runtime at 300 seconds, and timeout handling uses a penalty of τ = 0.5.Source: §3 · p. 3
  • The utility score selects the next meta-agent and the base agent for the next iteration; the method does not update model weights.Source: §3 · p. 3

3.1 Initial agent

  • The initial system is a sophisticated coding agent with tools, sub-agents, and oversight mechanisms, all of which are open to self-improvement.Source: §3.1 · p. 4
  • Its context includes the agent definition and tool and sub-agent documentation, followed by the problem, open-file and working-directory views, and the running assistant interaction.The running interaction includes reasoning, tool and sub-agent calls and responses, and overseer notifications.Source: §3.1 · pp. 4–5
  • Tools support file operations, shell commands, calculation, benchmark submission, sub-agent returns, and archive analysis.Source: §3.1 · p. 4
  • Three initial sub-agents—a coding agent, problem-solver, and reasoning agent—support autonomous task decomposition and help manage context length on long improvement runs.Sub-task context can be discarded when a sub-agent returns a summary to the main agent.Source: §3.1 · p. 4
  • Appending new context preserves the KV cache; file edits are appended as diffs and periodically consolidated into the file view.The authors note that agents could write more sophisticated cache-preservation schemes to reduce cost.Source: §3.1 · p. 5

4 Experiments and Results

The experiments assess SICA on long-horizon coding, synthetic editing and navigation, LiveCodeBench, and reasoning tasks. Improvements were uneven: coding benchmarks progressed, while benefits were marginal when the base models already performed well.

4 Experiments and Results

  • The evaluation included a fixed random subset of 50 SWE Bench Verified questions, 50 LiveCodeBench questions, and two agent-curated synthetic coding tasks.The synthetic tasks assess file editing against a target commit and locating symbol definitions in Python repositories.Source: §4 · pp. 5–6
  • The 15-iteration run used Sonnet 3.5 (v2) for most agents and o3 mini for the reasoning agent, at an API cost of approximately $7,000.Source: §4 · p. 6
  • SWE-Bench Verified increased appreciably as agent-framework improvements accrued; LiveCodeBench improved more subtly.Table 1 reports per-iteration benchmark accuracy and average per-problem costs.Source: §4 · pp. 6–7, Table 1 · p. 6
  • The symbol-locator benchmark’s low score was attributed to poor data quality, including target symbols in uninstalled external libraries.Source: §4 · p. 6

4.1 Performance on Reasoning Tasks

  • o3-mini alone scored 87% on AIME and 79% on GPQA Diamond at high reasoning effort, while the agent system averaged 76% across both benchmarks.The authors suspect crude reasoning components may interrupt reasoning chains in models trained outside the agent system.Source: §4.1 · p. 7, Figure 4 · p. 7

5 Conclusion

SICA shows that an agent system can improve itself by editing its own code, particularly on longer-horizon agentic tasks. The conclusion also identifies constraints in proposing improvements and benchmark settings, and points to joint model-and-agent updates and benchmark curation as future directions.

5 Conclusion

  • 17% to 53% on a random subset of SWE-Bench Verified, with a slight decrease in average time per problem, demonstrates SICA’s reported self-improvement.The authors describe the gains as especially relevant to longer-horizon agentic tasks.Source: §5 · p. 7

5.1 Limitations

  • Poor initial feature ideas can influence later suggestions, potentially increasing run-to-run variance and lowering the quality of subsequent ideas.A lengthy editing step followed by an expensive benchmark run can make settling on a bad idea costly.Source: §5.1 · pp. 7–8
  • Five-minute timeouts, and to a lesser degree per-problem cost limits, may depress initial scores, especially on longer-horizon tasks such as SWE-Bench.The authors note that much of the initial improvement comes from faster file editing and lower agent cost, which SWE-Bench does not reflect to the same degree.Source: §5.1 · p. 8

5.2 Future Work

  • The system updates behavior through prompt optimization and code edits rather than model-weight updates; future work could jointly update the foundation model and agent system.The authors describe this approach as sample-efficient because archive inspection informs substantial modifications at each step.Source: §5.2 · p. 8
  • Future systems may exhaust what they can learn from a static benchmark set, motivating automated benchmark design and curation.SICA’s agent-curated file-editing and symbol-navigation benchmarks demonstrate its flexibility to support new evaluations.Source: §5.2 · p. 8

6 Safety Considerations

The paper discusses safety measures for a self-improving agent that edits scaffolding but not model weights. It highlights human oversight and safety evaluations, while noting that observability alone would be inadequate if model weights were also updated.

6 Safety Considerations

  • Because SICA does not modify model weights, the authors expect recursively self-improving systems that update weights as well as scaffolding to pose higher risks.They also note limits to what scaffolding-only systems can achieve.Source: §6 · p. 8
  • SICA’s observability mechanisms expose reasoning traces, actions, and sub-agent calls, while an asynchronous LLM overseer can notify or cancel an agent.The authors consider observability a strong mitigation in this setting, but say it would be inadequate on its own for systems that also update model weights.Source: §6 · p. 8
  • Safety evaluations can be added to the iterative benchmark set to validate each agent before it advances to the next improvement iteration.Source: §6 · p. 8
  • The authors do not expect significant direct adverse societal consequences, describing the objectives as improving code editing or longer-horizon coding-task reasoning.Source: §6 · p. 9

A Agent Prompts

The appendix presents prompts that assign the main agent a routing and synthesis role, direct it to delegate tasks, and guide sub-agents and an overseer. The prompts specify coding workflows and intervention procedures for agent execution.

A Agent Prompts

  • The main agent routes requests to other agents and synthesizes their results into the final answer.Source: A Agent Prompts · p. 12
  • The main prompt instructs the agent to orchestrate sub-agents to solve the supplied problem and pass the problem statement along for delegation.It tells the agent to relay the statement accurately and avoid repeating a long prompt unnecessarily.Source: A Agent Prompts · p. 12

A.1 Base Sub-Agent Prompts

  • The coding workflow emphasizes understanding documentation and code conventions, making minimal edits, testing end to end, and cleaning up.It allows prototyping and benchmarking before implementation, and says exploratory requests may bypass the rigorous procedure.Source: §A.1 · p. 12
  • The base sub-agent prompt frames the incoming task as the problem to solve and asks the agent to follow a deliberate coding workflow.Source: §A.1 · pp. 12–13
  • Additional base-prompt guidance favors simple viable solutions, early validation, and adaptation, and recommends consulting a reasoning agent for difficult technical problems.Source: §A.1 · pp. 12–13

A.2 Overseer Prompt

  • The overseer prompt asks an LLM to monitor execution traces, assess progress, and send constructive guidance or cancel an agent in extreme cases.It also directs the overseer to consider timestamps, event counts, and both local and overall progress.Source: §A.2 · p. 14
  • Overseer instructions require an attempted notification before cancellation, notification of the parent after cancellation, and structured judgments about intervention.The example judgment includes loop status, notification content, cancellation fields, and the next check.Source: §A.2 · p. 14

B Example Traces

The appendix gives two execution traces: one illustrates a problem-solving run, and the other shows a meta-improvement run that inspects prior iterations, implements a change, and verifies it. The traces also report duration, token, and cost information.

B Example Traces

  • One problem-solving trace shows a main agent coordinating reasoning and software-development agents, with the latter debugging a script before the main agent submits an answer.A final reasoning agent synthesizes the results after the coding agent returns.Source: B Example Traces · p. 15
  • The example problem-solving run reports a total duration of 249.9 seconds, 407,766 tokens, and a total cost of $0.712.Source: B Example Traces · p. 15
  • In the meta-improvement trace, an archive explorer compares iterations and studies strong and weak benchmark cases before recommending a change.The explorer reviews implementation and documentation and consults reasoning agents.Source: B Example Traces · pp. 16–17
  • A software developer implements and tests the recommended feature, documents it, and a second developer independently verifies it before the main agent exits.Source: B Example Traces · pp. 16–17

C Function Calling Interface

The interface lets an LLM call tools and sub-agents at runtime, and uses unconstrained XML-formatted generation to identify and execute those calls. XML is chosen over JSON because it avoids escaping string literals in arguments such as verbatim file content.

C Function Calling Interface

  • The interface supports runtime tool and sub-agent invocation without predefined control flow.The text notes that implementations may use constrained generation, stream parsing, or native function-calling support.Source: C Function Calling Interface · p. 17
  • Unconstrained XML generation uses a registered closing tag and stop reason to detect tool or agent calls, parse their content, and run the tool implementation.The closing tag is the stop token used to identify when generation should stop for call handling.Source: C Function Calling Interface · p. 17
  • The tool-call syntax names a tool and encloses its arguments, which are parsed into a dictionary before the tool class is instantiated.The parsed tool name indexes the tools available to the calling agent.Source: C Function Calling Interface · p. 17
  • XML is selected over JSON because it avoids escaping string literals, which can be burdensome when file content is passed verbatim as an argument.Source: C Function Calling Interface · p. 17

D Additional Result Details

The agent’s updates add and refine file-editing tools, improve codebase exploration and edit verification, and optimize symbol location, routing, and handling of large files.

D Additional Result Details

  • The agent added a SmartEditor, a quick overwrite tool, diff-based editing strategies, and simplified DiffVerifier tests to improve editing and maintainability.Source: D Additional Result Details · p. 17
  • The updates added code-context summarization with ripgrep, input normalization, file-state tracking, and minimal-diff output to improve exploration, edit reliability, and token use.Source: D Additional Result Details · p. 18
  • The agent added AST and hybrid symbol locators, optimized file-edit routing, and a 100KB file-size threshold for handling large files.Source: D Additional Result Details · p. 18
  • Context-sensitive diff minimization uses AST parsing for Python and pattern-based analysis for other file types, while targeted AST parsing limits processing to relevant regions.Source: D Additional Result Details · p. 18
Loading 2504.15228v2…