RefineEdit-Agent in Iterative Refinement

Updated 9 July 2026

RefineEdit-Agent is a refinement-oriented system that transforms near-correct draft patches into validated fixes through iterative context clarification and candidate diversification.
It employs a structured pipeline featuring context disambiguation, test-time candidate sampling, and LLM-based patch aggregation to improve repository-level program repair.
The framework's principles extend beyond code repair to iterative image editing and knowledge-base refinement, showcasing broad applicability in multi-agent systems.

RefineEdit-Agent is a refinement-oriented agent architecture in which an initial draft output is treated as an intermediate object to be clarified, revised, merged, and validated rather than accepted as final. In repository-level automatic program repair (APR), the term most directly denotes the implementation of REFINE as a downstream module over a seeding APR system $R_0$ , where an initial Draft Patch $P_0$ is transformed through context disambiguation, test-time candidate diversification, LLM-based review and aggregation, and regression-test validation (Pabba et al., 4 Oct 2025). The same label is also used in procedure customization, image editing, and knowledge-base maintenance, where it similarly denotes iterative edit refinement rather than one-shot generation (Liang et al., 24 Aug 2025, Guo et al., 3 Jun 2026).

1. Problem setting and conceptual scope

In the REFINE formulation, RefineEdit-Agent sits downstream of any APR system $R_0$ that produces an initial, often near-correct, patch $P_0$ . The original codebase is denoted by $D$ , the raw issue by $I$ , and the regression-test suite by $T$ . The initial patch is defined as

$P_0 = R_0(I,D,T).$

A Draft Patch is explicitly characterized as “near-correct” but possibly incomplete or overfitted. The motivating claim is that current LLM-based APR techniques often struggle to produce correct fixes because of limited understanding of code context and over-reliance on incomplete test suites; the result is the frequent production of Draft Patches that either incompletely address the bug or overfit to the test cases (Pabba et al., 4 Oct 2025).

REFINE frames refinement as the missing step between a plausible first fix and a correct final fix. Its stated purpose is to transform Draft Patches into correct ones by addressing three challenges: disambiguating vague issue and code context, diversifying patch candidates through test-time scaling, and aggregating partial fixes via an LLM-powered code review process. The system is described as a general refinement module that can be integrated into both open-agent-based and workflow-based APR systems (Pabba et al., 4 Oct 2025).

This code-centered usage also establishes the broader sense of RefineEdit-Agent: an agentic mechanism that assumes the first draft is informative but insufficient, and that correctness emerges from iterative refinement rather than a single decoding pass.

2. Pipeline architecture in repository-level program repair

The REFINE pipeline has three core components inside a bounded retry loop. The first is Context Disambiguation. An Issue-Context Agent takes the raw GitHub issue text $I$ and codebase $D$ , and produces a structured issue context

$P_0$ 0

capturing Target modules $P_0$ 1, intended Logic change $P_0$ 2, high-level Actions $P_0$ 3, semantic Constraints $P_0$ 4, and Generalization scope $P_0$ 5. A Code-Context Agent takes $P_0$ 6 and $P_0$ 7, and synthesizes a patch context $P_0$ 8 comprising Data-dependencies $P_0$ 9, Control-flow dependencies $R_0$ 0, Invariants $R_0$ 1, and Call-graph context $R_0$ 2 (Pabba et al., 4 Oct 2025).

The second component is Test-time Candidate Diversification. A Delta-Patch Generator conditions on $R_0$ 3, formulates a few-shot LLM prompt, and repeatedly samples $R_0$ 4 delta patches $R_0$ 5 by setting sampling parameters such as temperature $R_0$ 6 and top- $R_0$ 7. Each $R_0$ 8 is a small diff snippet. Application of a delta patch yields a candidate full patch

$R_0$ 9

and the candidate patch set is

$P_0$ 0

This design treats diversity as a deliberate inference-time operation rather than a byproduct of stochastic generation (Pabba et al., 4 Oct 2025).

The third component is LLM-based Patch Aggregation. A Code-Reviewer Agent evaluates each $P_0$ 1 together with $P_0$ 2 and filters out negatives by asking whether the patch addresses the issue. An Aggregator Agent groups the surviving $P_0$ 3 by conflict and, for each group, uses the LLM to merge or choose edits in a merge-conflict style. This produces one Aggregated Patch $P_0$ 4 per group, after which the results are consolidated into a final patch $P_0$ 5 via a git-style diff application and linted for syntax. Regression tests are then executed on $P_0$ 6; if $P_0$ 7 passes, the patch is returned, and if not, the system sets $P_0$ 8 and repeats up to $P_0$ 9 retries (Pabba et al., 4 Oct 2025).

The architecture is therefore neither a pure generate-and-test loop nor a pure review-only loop. It combines semantic disambiguation, stochastic local search over edits, and explicit aggregation of partial fixes.

3. Formalization, scoring, and operating parameters

REFINE defines the Patch Context at a location $D$ 0 as

$D$ 1

where $D$ 2 is the data-dependency subgraph at $D$ 3, $D$ 4 is the control-flow constructs guarding $D$ 5, $D$ 6 is the invariants to preserve, and $D$ 7 is the call-graph trace to or from $D$ 8. The Candidate Patch Set $D$ 9 is obtained by sampling delta patches and applying them to $I$ 0. An Aggregated Patch $I$ 1 is produced by merging a conflict-group of candidate patches via an LLM-guided merge operation and then consolidating it with $I$ 2 (Pabba et al., 4 Oct 2025).

Although the main loop uses binary yes-or-no filtering, the framework also sketches a continuous scoring function: $I$ 3 where $I$ 4 is a relevance score from an LLM query, the test term normalizes test success, and $I$ 5 penalizes radical departures from the draft. The coefficients $I$ 6 sum to $I$ 7, with the example $I$ 8. Patches are then ranked by Score, and the top- $I$ 9 are merged (Pabba et al., 4 Oct 2025).

The recommended defaults are concrete and operationally specific: $T$ 0 candidate patches, $T$ 1 during delta sampling, top- $T$ 2, and $T$ 3 refinement loops. Context extraction uses 15 LLM calls for issue context and 15 for code context, and an aggregation linting pass is enabled to catch syntactic errors early. Under varied hyperparameters with $T$ 4 and retries $T$ 5, the best performance is reported at $T$ 6 and retries $T$ 7 (Pabba et al., 4 Oct 2025).

These design choices make RefineEdit-Agent technically distinctive within APR: the refinement target is the edit itself, but the optimization signal is distributed across semantic review, test behavior, and closeness to the initial draft.

4. Benchmarks, ablations, and performance

REFINE is evaluated on SWE-Bench Lite, described here as 300 Python issues, and SWE-Bench Verified, described here as 500 issues. The seed APR system is AutoCodeRover v1.0. The backend LLMs are Claude 3.7 Sonnet for context and delta generation, and Gemini 2.5 Pro for review and aggregation. The evaluation budget is a single-pass per issue, with no web access and hidden tests (Pabba et al., 4 Oct 2025).

Benchmark	Baseline	RefineEdit-Agent result
SWE-Bench Lite	AutoCodeRover alone resolves 37.0%	51.67% $T$ 8
SWE-Bench Verified	51.6%	63.8% $T$ 9

On SWE-Bench Lite, the reported score of 51.67% surpasses all prior baselines and is described as state-of-the-art among workflow-based approaches; more broadly, REFINE is said to approach the best-known performance across all APR categories. When integrated across multiple APR systems, it yields an average improvement of 14%, which is presented as evidence of broad effectiveness and generalizability. The paper also reports an average cost per issue of approximately $P_0 = R_0(I,D,T).$ 0, approximately $P_0 = R_0(I,D,T).$ 1 million tokens, and approximately $P_0 = R_0(I,D,T).$ 2 minutes (Pabba et al., 4 Oct 2025).

The ablation analysis attributes gains to all three principal modules. Context extraction, delta diversification, and review or aggregation each contribute $P_0 = R_0(I,D,T).$ 3– $P_0 = R_0(I,D,T).$ 4 percentage points of improvement. This directly supports the claim that refinement is not a single mechanism but a composed process in which context modeling, inference-time diversity, and post-generation consolidation each matter materially (Pabba et al., 4 Oct 2025).

5. Relation to adjacent code-editing and verification frameworks

RefineEdit-Agent belongs to a larger cluster of multi-agent code-editing systems that separate planning, editing, and checking rather than relying on a single monolithic interaction. "SWE-Edit" decomposes code editing into two specialized subagents: a Viewer that extracts task-relevant code on demand and an Editor that executes modifications from high-level plans. The Viewer returns, on average, 39.7% of a file, corresponding to 60.3% context reduction, and on SWE-bench Verified the full Viewer-plus-Editor configuration improves resolved rate by 2.1%, reduces inference cost by 17.9%, and increases edit success to 96.9%. SWE-Edit also formulates editing as a one-step decision process and trains Qwen3-8B with GRPO to adaptively choose between find-replace and whole-file rewrite (Zhang et al., 28 Apr 2026).

"SAFEdit" addresses instructed code editing through a Planner Agent, an Editor Agent, and a Verifier Agent, coupled by a Failure Abstraction Layer that converts raw test logs into structured diagnostic feedback. On EditBench, SAFEdit achieves 68.6 percent TSR, outperforming the single-model baseline by 3.8 percentage points and the ReAct single-agent baseline by 8.6 percentage points; its iterative refinement loop contributes 17.4 percentage points to the overall success rate. At the same time, its error analysis shows that failures remain concentrated in Instruction Hallucination and Implementation Gap, even though Regression Error is reduced to 0.0% in the reported example. This directly counters any simple claim that decomposition alone resolves reliability challenges (Tarshish et al., 28 Apr 2026).

A still earlier edit-based agent formulation appears in "Tailoring with Targeted Precision: Edit-Based Agents for Open-Domain Procedure Customization," where a SEQUENTIAL architecture runs a ModifyAgent before a VerifyAgent. On the CustomPlans evaluation, SEQUENTIAL achieves $P_0 = R_0(I,D,T).$ 5, $P_0 = R_0(I,D,T).$ 6, and $P_0 = R_0(I,D,T).$ 7, compared with $P_0 = R_0(I,D,T).$ 8 for an end-to-end LLM, yielding a $P_0 = R_0(I,D,T).$ 9 absolute gain in fully correct outputs. Reverse-SEQUENTIAL, which places verification before modification, drops to $I$ 0, indicating that agent ordering matters (Lal et al., 2023).

Taken together, these systems indicate that RefineEdit-Agent is not merely a patch sampler. It is part of a broader design philosophy in which semantic planning, literal editing, and execution-grounded verification are deliberately decoupled. This suggests that refinement quality depends as much on interface design and feedback structuring as on the raw capability of the underlying backbone models.

The label RefineEdit-Agent is also attached to several image-editing systems, where the object being refined is an image edit rather than a source patch. The resulting architectures differ in modality but preserve the same pattern of decomposition, iterative feedback, and bounded termination.

System	Core loop	Representative result
RefineEdit-Agent (Liang et al., 24 Aug 2025)	parse–plan–execute–evaluate–feedback	AvgScore 3.67 on LongBench-T2I-Edit
EditRefiner (Xu et al., 8 May 2026)	Perception $I$ 1 Reasoning $I$ 2 Action $I$ 3 Evaluation	Qwen-Img-Edit 66.62 $I$ 4 72.58
Agentic Retoucher (Shen et al., 5 Jan 2026)	Perception $I$ 5 Reasoning $I$ 6 Action	Overall 47.15 $I$ 7 49.27; 83.2% human preference
ImageEdit-R1 (Zhao et al., 9 Mar 2026)	decomposition, sequencing, single-shot editing	FLUX.1 7.21 $I$ 8 8.23
JarvisEvo (Lin et al., 28 Nov 2025)	edit–evaluate–reflect with iMCoT and SEPO	18.95% average improvement on preservative editing metrics

The 2025 image-editing RefineEdit-Agent explicitly formalizes editing as a closed-loop system with LVLM-driven instruction parsing and scene understanding, multi-level LLM-driven planning, iterative image editing, and LVLM-driven feedback and evaluation. It introduces LongBench-T2I-Edit with 500 initial images and reports statistically significant gains over Direct Re-Prompting, InstructPix2Pix, GLIGEN-based Edit, and ControlNet-XL (Liang et al., 24 Aug 2025).

EditRefiner and Agentic Retoucher convert post-editing or post-generation correction into hierarchical perception-reasoning-action loops. EditRefiner introduces EditFHF-15K with 15,287 edited images, 60,318 artifact annotations, 80,345 editing failure annotations, and 45,861 mean opinion scores, and reports that the full system consistently outperforms state-of-the-art methods in distortion localization, diagnose accuracy, and human perception alignment (Xu et al., 8 May 2026). Agentic Retoucher similarly constructs GenBlemish-27K with 6,025 images and 27,507 pixel-level masks, using saliency localization and region-conditioned diagnosis to drive localized inpainting (Shen et al., 5 Jan 2026).

ImageEdit-R1 and JarvisEvo push the refinement idea toward reinforcement learning and self-improvement. ImageEdit-R1 formulates instruction decomposition as a Markov decision process and fine-tunes the decomposition agent with GRPO, while JarvisEvo combines interleaved multimodal chain-of-thought with synergistic editor-evaluator policy optimization to mitigate instruction hallucination and reward hacking (Zhao et al., 9 Mar 2026, Lin et al., 28 Nov 2025).

A plausible generalization is that, in image editing, RefineEdit-Agent denotes not a single algorithm but a stable architectural pattern: localized diagnosis, explicit planning, iterative correction, and a learned or rule-based evaluator that determines whether another refinement step is warranted.

Outside code and image editing, RefineEdit-Agent also denotes systems that refine structured knowledge after an initial draft or expert correction. RAID, the "Reflective Agent for Identifier Dictionary," is triggered when an expert edits a single entry in a compositional identifier dictionary. It then executes three phases—Intent Inference, Reflection-based Planning, and User Controlled Execution—to decide whether the edit reflects a systemic change and, if so, to propagate that change across the knowledge base. On the RxTerms benchmark, RAID reports approximately 99.6% intent accuracy, approximately 98.6% propagation precision, 100% recall, approximately 99.3% F1, and 76.3% revision accuracy, with a user study reporting mean UMUX-Lite of 3.75/5 and intent-inference quality of 4/5 (Guo et al., 3 Jun 2026).

DeepRefine addresses agent-compiled knowledge bases that suffer from incompleteness, incorrectness, and redundancy. It represents a knowledge base as a set of generalized triples

$I$ 9

and performs multi-turn interactions over retrieved subgraphs, an answerability judgment loop, error abduction, and graph-edit actions such as $D$ 0, $D$ 1, and $D$ 2. Its reinforcement-learning signal is the Gain-Beyond-Draft reward,

$D$ 3

which directly measures the benefit of refinement over the draft knowledge base. Across five QA benchmarks—NQ, PopQA, 2Wiki, MuSiQue, and LOCOMO—reported average F1 gains range from $D$ 4 to $D$ 5, and end-to-end refinement runs in approximately $D$ 6 per split versus approximately $D$ 7 for full-reconstruction AR1 (Huang et al., 11 May 2026).

These knowledge-centric systems broaden the meaning of RefineEdit-Agent. The “edit” may be a graph update or propagated description revision rather than a line-level patch, yet the governing assumption remains the same: draft artifacts are useful but systematically limited by incompleteness, incorrectness, redundancy, or local ambiguity. The refinement agent therefore becomes a mechanism for turning isolated corrections into structured, reusable improvements. This suggests that the concept has evolved from a program-repair technique into a general template for post-hoc quality improvement in agentic systems.