Reusing Past Repairs Through Hierarchical Trajectory Abstraction for Coding Agents

01 · Problem

Reuse a past repair, but at which level?

Experienced developers reuse what worked before: localization strategies, editing procedures, verification steps.

That knowledge exists at different granularities. A concrete procedure, such as checking a particular configuration file, is actionable but may apply only to closely related issues. A broader strategy, such as tracing data flow backward from a failure site, transfers more widely but says less about what to do next. Agents that already reuse past repairs (Lingxi, SWE-Exp, ExpeRepair) fix the unit and the granularity when they extract it: a whole repair, stage-level experience, or a demonstration plus abstract insights. None splits a past repair into its distinct procedures and keeps each one at several levels of detail.

Too specific

Reuse the concrete repair as it happened

Concrete steps are actionable but may apply only to closely related issues. A new issue may need a past repair's localization strategy but not its repository-specific edit; a raw trajectory adds tool outputs, failed attempts and repeated actions.

Concrete steps · example from the paper's Figure 1

Remove the “Add” button
User still added items
Checked why it still worked
Found a hidden shortcut

Too vague

Reuse only an abstract insight

A broad strategy transfers to more issues, but it may omit the actions that made the strategy work, including steps a closely related issue would need. It gives the agent less guidance on what to do next.

High-level principle · same example

Always enforce intent at every system layer, not just at the visible entry point.

The questionHow can an agent identify the reusable procedures within a past repair, and represent each at the level of detail a future repair needs? STAIR's answer: keep every level, and let each repair stage of the new issue draw the recipes that apply.

02 · Method

Keep every granularity; select per stage.

STAIR works in three phases. Phase 1 runs offline, once, before any target repair. Phases 2 and 3 run for each new issue, separately for each of the three repair stages: localization, planning, and execution-and-verification. A repair recipe is a reusable procedure or strategy derived from a past repair; a repair plan instantiates selected recipes for the target issue.

1Phase 1 · offline 2Phase 2 · per stage 3Phase 3 · per stage

How to readTop to bottom, following the arrows. Phase 1 turns a solved issue's trajectory into recipes at low, medium and high level and stores all of them. Phase 2 retrieves recipes for a new issue, from different past issues and granularities, and combines them into a plan; each plan step names the recipes it came from. Phase 3 hands the plan to the repair agent.

What it showsNo level replaces another: the plan's second step comes from a medium-level recipe, its third from a high-level and a medium-level recipe of two different issues. Figure 1 of the paper; construction, retrieval and plan generation are performed separately for each repair stage.

1Phase 1 · offline recipe construction

Split by stage, then abstract level by level.

STAIR runs Lingxi's repair scaffold, with its knowledge-reuse mechanism disabled, on earlier issues of the same repository and keeps the trajectories of successful repairs. Each trajectory is cut into three ordered segments, one per repair stage, τ(u) = ⟨τ_loc, τ_plan, τ_exec⟩. Within a segment, an LLM operator G_ℓ groups consecutive steps that serve a common repair purpose, and an operator A_ℓ abstracts each group into one recipe. The recipes are then grouped and abstracted again, until at most K = 2 remain. Every level is kept.

One successful trajectory

τ_locLocalizationτ_planPlanningτ_execExecution & verification

Recipes are built, and later retrieved, separately for each segment. Below: one segment, as in the paper's example.

High levelgeneral problem-solving principle

Cross-issue design principleAlways enforce intent at every system layer, not just at the visible entry point

Medium levelproject-agnostic investigation strategy

Issue-level reusable strategyWhen a feature is blocked via UI, also check the backend rejects it directly

Low levelconcrete sub-goals grounded in project artifacts

Remove the “Add” buttonUser still added itemsChecked why it still workedFound a hidden shortcut

Sourceagent trajectory, N steps

Solved issue: Hide the “Add” button, but items keep adding

Intentwhat the procedure aims to accomplish

Key actionsthe actions used to carry it out

When to applythe conditions under which it is useful

Pitfallscommon pitfalls met during the repair

Every recipe has these fields at every level; only their specificity changes. A low-level recipe may name specific APIs; a high-level one must be fully generic. Recipes are built once with GPT-5 from 479 historical trajectories (about $0.44 each, about $211 in total) and shared by all configurations.

Simplified grouping prompt. Task: partition the current level into consecutive groups sharing a coherent procedural intent at the given abstraction level. Inputs: issue report, current-level nodes, abstraction level low, medium or high. Guidance: at low level group by concrete sub-goals, at medium by investigation strategies, at high by general problem-solving principles. Rules: groups are consecutive ranges with no reordering or gaps, and every node belongs to exactly one group. Output: reasoning and a list of groups with start, end and purpose. — **How to read:** one template for all levels; only the guidance line changes with ℓ. Groups must be consecutive and cover every node, so the stage's order is kept.

Simplified abstraction prompt. Task: summarize a group into a single parent node at the given abstraction level. Inputs: issue report, group steps, abstraction level. Guidance: at low level produce a concrete sub-goal grounded in project artifacts, at medium extract a project-agnostic investigation strategy, at high distill a general problem-solving principle. Rules: interpret nodes holistically using reasoning traces, tool usage and existing abstractions; concreteness decreases with the level. Output: a structured node with level, node type, summary, intent, rationale, when to apply, key actions and pitfalls. — **What it shows:** each group becomes one recipe with the fields above; concreteness decreases with the level, from named APIs to a fully generic principle.

2Phase 2 · retrieval and plan generation, per stage

One pool across granularities, one plan per stage.

For a new issue u and each stage s, every recipe from stage s of the selected past repairs is a candidate, whatever its granularity. STAIR ranks them in one list by cosine similarity to the issue report (Qwen3-Embedding-8B), and an LLM verifier removes recipes whose procedures do not apply at this stage. The retained set R_s(u) can mix granularities and source issues. An LLM then writes the stage plan P_s(u) = Plan(u, R_s(u)): it keeps applicable guidance, drops irrelevant or conflicting parts, and combines complementary recipes into an action sequence for this issue.

New issue · report only

Make the form edit-only, no new entries allowed

Rank recipes of stage s from all granularities in one list
LLM verifier drops those that do not apply at this stage
Keep order: same-trajectory recipes in execution order, broader before narrower

Retrieved recipes R_s(u)

#1 Issue AhighAlways enforce intent at every system layer, …

#2 Issue AmediumWhen a feature is blocked via UI, also check …

#3 Issue BmediumCheck whether hidden pages still allow POST …

Generated plan P_s(u)

Find out how the form controls user actions
Add a proper “edit-only” setting from #2
Block new entries everywhere, not just on screen from #1, #3
…

Example from the paper's Figure 1. Retrieval uses only the issue report; repository-specific details in the plan are checked and adjusted by the repair agent as it explores the target codebase.

3Phase 3 · plan-guided issue resolution

The plan guides the agent; the agent still decides.

Each plan is given to the repair agent in the matching stage. The agent still explores the repository, applies edits, runs checks and responds to test feedback; when new evidence conflicts with the plan, it can revise its decisions. The underlying agent remains responsible for constructing and verifying the final patch.

Stage 1

Localization

P_loc(u)

guides the agent toward relevant failure evidence and candidate code locations.

Stage 2

Planning

P_plan(u)

describes the intended modification strategy, the repair scope and relevant constraints.

Stage 3

Execution & verification

P_exec(u)

suggests procedures for implementing the repair and checking it.

Primary scaffold · RQ1, RQ3, RQ4

Lingxi

Its decision logic, tools and three-stage repair process are kept; its original knowledge-reuse mechanism is disabled, and each stage's prompt receives the STAIR plan for that stage.

Transfer target · RQ2

mini-SWE-agent v2

A minimal bash-only agent. The plans are prepended as an <external_reference_plans> block; its source code, tool definitions and verification logic are unchanged.

03 · Evaluation

Does multi-granularity reuse pay off?

All experiments use SWE-bench Verified: 500 real GitHub issues from 12 Python repositories, each checked by developer-written tests. Pass@1 is the share of issues resolved by the final patch of a single agent run. Two backbones, both with high reasoning (HR): GPT-5 (commercial) and MiniMax M2.5 (open-weight). For each target issue, past issues come from the same repository, were created before it, and are disjoint from the evaluation instances.

Recipes: built once with GPT-510–15 min per instance$0.84 / instance · MiniMax M2.5$1.60 / instance · GPT-5

RQ1 · comparison with repair agents

Same scaffold, same model: higher Pass@1.

GPT-5 (HR)same backbone

live-SWE-agent

68.4

OpenHands

71.8

Lingxisame scaffold, original knowledge reuse

75.6

STAIRLingxi scaffold + recipes

+3.6 pp79.2

MiniMax M2.5 (HR)same backbone

Lingxisame scaffold, original knowledge reuse

74.6

mini-SWE-agent v2

75.8

STAIRLingxi scaffold + recipes

+6.6 pp81.2

Claude 4 Sonnetreported results · different backbone · no STAIR run

SWE-Exp

73.0

ExpeRepairwith o4-mini as fallback

74.6

Lingxi

74.6

Pass@1 (%) · axis starts at 65

6570758085

+6.6 ppMiniMax M2.5 · Lingxi → STAIR74.6 → 81.2, only the knowledge-reuse mechanism changes

+3.6 ppGPT-5 · Lingxi → STAIR75.6 → 79.2, only the knowledge-reuse mechanism changes

How to readRows are grouped by backbone, so within a group only the agent differs; the paper's Table 2 lists the same numbers by agent type. Lingxi in dark grey is the controlled comparison: same scaffold, backbone, tools and historical issues, with its original knowledge reuse instead of STAIR's recipes and plans. The Claude 4 Sonnet rows are reported results with a different backbone, so that comparison is less controlled.

What it showsSTAIR reaches 81.2% with MiniMax M2.5 and 79.2% with GPT-5, the highest among the compared agents under their reported settings. Changing only the knowledge-reuse mechanism adds 6.6 points on MiniMax M2.5 and 3.6 on GPT-5; GPT-5's higher Lingxi baseline may leave less room. On the same backbones, STAIR is 7.4 points above OpenHands, 10.8 above live-SWE-agent and 5.4 above mini-SWE-agent v2.

RQ2 · transfer to another agent · MiniMax M2.5

The plans also guide a different agent.

Pass@1 on 500 issues

Resolved

mini-SWE-agent v2379/500 · 75.8%

+ STAIR plans405/500 · 81.0%

+5.2 pp · 379 → 405 resolved

per instance

Average steps

mini-SWE-agent v260.45

+ STAIR plans58.18

fewer steps · 60.45 → 58.18

total per instance

Average tokens

mini-SWE-agent v21,244,923

+ STAIR plans1,179,885

−5.2% · 1,245k → 1,180k

How to readmini-SWE-agent v2 has its own architecture, tool interface and prompting strategy. The only change is the prepended block of STAIR plans, generated from recipes built on Lingxi trajectories. Table 3 of the paper, all 500 instances.

What it showsPass@1 rises from 75.8% to 81.0% (+5.2 points), close to STAIR on Lingxi's scaffold (81.2%). Average steps fall from 60.45 to 58.18 and tokens per instance by 5.2%: the plans do not just add context, the agent explores less. This is evidence for one other scaffold, not for agent scaffolds in general.

RQ3 · how plans change agent behavior

Where plans help, and where they fall short.

Gained and regressed instances · Table 4

STAIR_MiniMax vs. Lingxi_MiniMaxshared 363 · solved by both

10

43

+33net

mini-SWE-agent v2 + Plans vs. vanillashared 372 · solved by both

7

33

+26net

Why gained · what the plan corrected · Figure 4, rebuilt

Wrong Location

The baseline targets the wrong component and cannot recover; the plan points to the correct location from the start, e.g. the upstream serializer rather than the downstream loader.

12 (28%)

17 (52%)

Partial Fix

The baseline finds the root cause but edits only some of the affected code. In django-11138 it fixed a timezone bug for MySQL and Oracle but not SQLite; the plan framed it as a cross-backend audit.

21 (49%)

10 (30%)

Over-modification

The baseline changes more code than needed; the plan keeps the repair to the minimal change, e.g. extending a matching condition instead of rewriting the discovery pipeline.

10 (23%)

6 (18%)

Why regressed · all 17 regressions

8 · plan-related

The plan misses part of the scope

It captures the main direction but not every change; typically the fix needs coordinated updates across several files or entry points. 5 from STAIR_MiniMax, 3 from mini-SWE-agent v2 + Plans.

9 · not plan-related

The plan fits; execution fails

The agent deviates from the plan, makes unnecessarily complex edits, or makes local mistakes such as a wrong API or wrong arguments. 5 from STAIR_MiniMax, 4 from mini-SWE-agent v2 + Plans.

How to readGained means solved only with STAIR's plan; regressed means solved only by the baseline (Lingxi for STAIR, vanilla mini-SWE-agent v2 for the plan-augmented version). Two authors labeled every such instance from its plan, patch and full trajectory and resolved disagreements (Cohen's κ = 0.85).

What it showsGains outnumber regressions, 43 to 10 and 33 to 7. Each agent gains where it is weakest: Lingxi already has an explicit localization stage, so plans mostly widen the fix (Partial Fix, 49%); bash-only mini-SWE-agent v2 most often starts in the wrong place, so plans mostly redirect it (Wrong Location, 52%). Of the 17 regressions, 8 trace back to plans that miss part of the required scope; in the other 9 the plan fit and execution failed.

RQ4 · ablation · 125-instance subset · MiniMax M2.5

No single granularity matches the full pool.

Multi-granularity reusefull system · all levels

100/125 · 80.0

Low-level onlysingle granularity

80/125 · 64.0−16.0

Medium-level onlysingle granularity

76/125 · 60.8−19.2

High-level onlysingle granularity

73/125 · 58.4−21.6

Raw trajectoriesno abstraction

72/125 · 57.6−22.4

91.4%of stage plans in the full systemuse recipes from more than one granularity

−22.4 ppRaw trajectories instead of recipesthe largest drop among the variants

How to readEach variant changes only what is reused. The 125 instances are difficulty-stratified: 92 (73.6%) medium or hard, with an estimated fix time of at least 15 minutes, and 33 (26.4%) easy. The subset emphasizes harder issues, so differences on the full benchmark may not be the same.

What it showsThe full pool resolves 100 of 125 (80.0%). Restricting retrieval to one granularity costs 16.0 to 21.6 points; concrete low-level recipes do best of the three, possibly because they are more actionable, yet still trail by 16.0. Reusing raw trajectories is lowest at 57.6%. The results support keeping recipes at several granularities and selecting among them per issue and stage.

04 · Threats to validity

What the results do not establish.

The paper states these limits; the numbers above should be read within them.

External

One benchmark, one language

SWE-bench Verified has 500 Python instances from 12 repositories. Results may not carry over to other languages, benchmarks or proprietary codebases.

External

One source agent, one transfer target

Recipes come from Lingxi trajectories; another source agent may produce trajectories of different quality. RQ2 shows transfer to mini-SWE-agent v2, not to other scaffolds.

Internal

LLM-built recipes, manual labels

Grouping, abstraction and the relevance verifier are LLM-based; recipe quality can vary with trajectory length, and the verifier may drop useful recipes or keep inapplicable ones. RQ3's labels involve judgment (κ = 0.85).

Construct

Tests, two models, a sampled ablation

Pass@1 relies on the provided tests, which may accept behaviorally incorrect patches. Two backbones do not establish the same benefit for other models. RQ4 uses a subset weighted toward harder issues.

05 · Cite

BibTeX

Please cite the arXiv preprint.

@misc{xu2026reusingpastrepairshierarchical,
  title         = {Reusing Past Repairs Through Hierarchical Trajectory
                   Abstraction for Coding Agents},
  author        = {Yisen Xu and Jiayuan Zhou and Ruiqi Pan and Tse-Hsun Chen},
  year          = {2026},
  eprint        = {2607.29658},
  archivePrefix = {arXiv},
  primaryClass  = {cs.SE},
  url           = {https://arxiv.org/abs/2607.29658}
}