Your Code Agent Can Grow Alongside You with Structured Memory

Problem

• Existing repository-level agents operate statically, overlooking historical defect-repair patterns, implicit project conventions, and human-verified solutions.This leaves agents unable to retrieve precedents, align abstract instructions with concrete execution, or retain corrections across tasks.Source: §1 · pp. 1–2

Motivation

• Repository-level collaboration requires reconstructing developer cognition from historical trajectories and crystallizing interactions into enduring capabilities.The proposed cycle progressively attunes agents to a developer's coding philosophy and constraints.Source: §1 · p. 2

Method

• MemCoder structures historical commits into memory so agents can recall how humans previously resolved similar repository complexities.This Knowledge Dimension captures both explicit solutions and implicit intent from historical contributions.Source: §1 · p. 2
• MemCoder retrieves historical context to concretize sparse instructions, then stores human-verified solutions as persistent intent-to-code mappings.Its Execution Dimension combines intent concretization, dynamic self-refinement, and experience internalization.Source: §1 · p. 2

Evaluation

• 77.8% resolved rate, up from 68.4%, is reported for DeepSeek-V3.2 with MemCoder on SWE-bench Verified.The framework also achieves SOTA performance, with GPT-5.2 used as the backbone in the evaluation.Source: §1 · p. 2

Contribution

• MemCoder couples general models with human-derived evolutionary context to support continuous human-AI co-evolution on complex software engineering tasks.The framework is designed to let agents grow alongside projects rather than remain static executors.Source: §1 · p. 2

2.1. LLM-Based Code Generation Agents

• LLM-based code agents use iterative feedback, multi-agent collaboration, and reasoning-action coupling to improve autonomous software problem solving.MemCoder extends these approaches by incorporating historical development wisdom into agent decisions.Source: §2.1 · p. 2

2.2. Long-Term Memory Mechanisms for LLMs

• Long-term memory methods organize agent experience through external databases, hierarchical structures, or forgetting-based pruning, whereas MemCoder uses flat autonomous memory management.Its memory dynamically integrates new insights instead of relying on rigid organization or decay-based removal.Source: §2.2 · pp. 2–3

2.3. Dynamic Evolution

• Dynamic evolution methods improve agents through memory consolidation or prompt optimization driven by environmental and execution feedback.MemCoder distinguishes itself by integrating these evolutionary mechanisms with historical human experience for continuous human-AI co-evolution.Source: §2.3 · p. 3

3. Method

• MemCoder iteratively refines the agent system using long-term memory, execution trajectories, and multi-source feedback.The framework represents code generation as continuous learning rather than static inference.Source: §3 · p. 3

3.1. Experience Representation and Utilization

• Historical commits are transformed into structured memory capturing keywords, problem descriptions, root causes, and actionable solutions.The process ingests commit messages and code changes, then reconstructs developer cognition and intent-to-code mappings.Source: §3.1 · p. 3
• MemCoder retrieves relevant experiences through a two-stage pipeline combining approximate nearest-neighbor search with cross-encoder reranking.Embedding-based retrieval forms a broad candidate pool, while reranking performs fine-grained semantic matching and filters false positives.Source: §3.1 · pp. 4–5
• The retrieval system autonomously synthesizes queries from the agent’s reasoning state and task context to adapt historical-memory search to each issue.Final relevance is determined by reranking rather than the initial retrieval score.Source: §3.1 · p. 5

3.2. Self-Refinement and Internalization

• During execution, a Refining Sub-agent uses retrieved precedents, execution traces, environmental feedback, generated tests, and verification checklists to guide repository-aligned decisions.Iterative feedback updates verification logic without modifying long-term memory during execution.Source: §3.2 · p. 5
• Human-verified model solutions are internalized into long-term memory, closing the evolution loop and shifting knowledge from human-only priors toward human–agent co-evolved experience.This mechanism preserves alignment between high-level intent and concrete implementations.Source: §3.2 · p. 5

4.1. Experimental Settings

• The benchmark measures functional patch correctness by executing generated patches against tests for repository-level GitHub issues across 12 Python repositories.SWE-bench Verified is a manually curated 500-instance subset of the full 2,294-instance SWE-bench benchmark.Source: §4.1 · p. 6
• MemCoder is evaluated on 500 manually curated SWE-bench Verified tasks using resolution rate and resolved-issue count, with retrieval restricted to pre-test experiences.Experiments primarily use DeepSeek-V3.2, with GPT-5.2 used to assess absolute performance.Source: §4.1 · p. 6

4.2. Performance on Repository-Level Code Generation

• 83.8% solved rate is achieved with GPT-5.2 under pass@2, despite official OpenHands results using pass@3.MemCoder is compared with OpenHands-based LLM configurations on SWE-bench Verified.Source: §4.2 · p. 7, Table 1 · p. 7

4.3. Ablation Study

• All three modules improve performance, with commit retrieval producing the largest gain in the ablation study.The tested modules are commit retrieval, experience representation, and dynamic self-refinement.Source: §4.3 · p. 7, Table 2 · p. 7
• 76.4% resolved rate with structured memory exceeds the 73% raw-commit and 68.4% no-experience settings.Structured memory reduces noise and semantic ambiguity while presenting historical information in a unified style.Source: §4.3 · p. 7
• Moderate initial top-k balances broader information access against declining retrieval frequency, plateauing resolution gains, and excessive context noise.With smaller top-k, agents retrieve more frequently; larger top-k eventually reduces signal-to-noise ratio and yields diminishing returns.Source: §4.3 · pp. 7–8
• With one retrieval opportunity, increasing top-k improves performance at first, but gains diminish beyond 8 and excessive values degrade performance through context overload.Figure 5 evaluates resolve rate on a randomly sampled 200-instance subset using DeepSeek-V3.2.Source: §4.3 · p. 8, Figure 5 · p. 8

• MemCoder targets static agents’ inability to capture critical information embedded in projects’ temporal evolution.Source: §5 · p. 8
• The framework reconstructs developer cognition by structuring historical commits and using retrospective wisdom to guide execution verification and refinement.Source: §5 · p. 8
• Continuous internalization of reasoning trajectories lets the agent move beyond a mere executor toward an adaptive partner that grows with the developer.Source: §5 · p. 8

• Historical retrieval guides the agent to the relevant on_conflict_suffix_sql invocation and enables successful bug repair, whereas no retrieval leads to an incorrect fix location.Source: A. Case Study · p. 13
• Mixed-case db_column values cause PostgreSQL ON CONFLICT clauses to use field names instead of column names, producing a missing-column error.Source: A. Case Study · p. 13
• The case study contrasts patches generated without retrieval and with retrieval as separate conditions.Source: A. Case Study · p. 13
• The patch also updates conflict SQL generation to use converted unique columns and update columns across affected database operations.Source: A. Case Study · p. 13
• The retrieved patch converts update and unique fields into database column names before constructing conflict SQL.Source: A. Case Study · p. 13

• The pipeline takes a target repository, issue, and existing memory, and returns a resolved solution.Source: B. Algorithmic Pipeline · p. 14

Stage 1: Memory Synchronization

• Memory synchronization summarizes new commits with an LLM, embeds the summaries, and adds them to memory.Source: B. Algorithmic Pipeline · p. 14

Stage 2: Execution Loop

• During execution, the primary agent can retrieve memory, invoke a refining agent on a candidate patch, or execute a standard tool.Source: B. Algorithmic Pipeline · p. 14
• The refining agent tests the candidate and marks it solved when tests pass; otherwise, test results and checklists are added to context for further iteration.Source: B. Algorithmic Pipeline · p. 14

Stage 3: Submission (Closed-Loop)

• A solved solution undergoes human review before Git commit, and the new commit is learned during the next memory-synchronization run.Source: B. Algorithmic Pipeline · p. 14

• The Refining Agent synthesizes tests, environment feedback, and retrieved experience into an actionable checklist for the primary agent.Source: C. Prompt of Refining Agent · p. 15

0. TEST REPRODUCTION, PATCH VERIFICATION & HYPOTHESIS GENERATION

• The workflow begins by analyzing the patch mechanism, retrieving related tests and commits, and using historical patterns to inform debugging.Source: C. Prompt of Refining Agent · p. 15
• Retrieval uses problem statements with keywords and descriptions, progressive top_k values beginning at 8, and synthesis after each query.Source: C. Prompt of Refining Agent · p. 15
• The agent must create a minimal runnable reproduction, compare base and patched behavior, record commands and outcomes, and generate competing hypotheses when errors are unclear.Source: C. Prompt of Refining Agent · p. 16

1–6. Structured Analysis

• The subsequent review covers code structure, reproduction and path tracing, logic and invariants, history, fix strategies, and testing validation.Source: C. Prompt of Refining Agent · pp. 16–18

Output Format

• The final report must summarize the change, structure, reproduction, invariants, historical context, recommendations, and focused regression tests.Source: C. Prompt of Refining Agent · p. 18