From Fragments to Paths: Task-Level Context Recovery for Large Industrial Codebases Jiawei He∗ , Weisong Sun† , Mengyu Shi‡ , Jie Jia∗ , Tong Bian§ , Xikai Yang∗ , Dong Sun∗ ∗ AMAP, Alibaba Group † Nanyang Technological University ‡ Nanjing University
arXiv:2606.22906v1 [cs.SE] 22 Jun 2026
§ University of Cambridge
Abstract—Large language models have shown strong performance on software engineering (SE) tasks, yet understanding large industrial repositories remains challenging. Existing methods often retrieve only local fragments and fail to recover the broader task-relevant context needed for complex repositorylevel tasks. We present D EEP D ISCOVERY, a task-level repositoryunderstanding method for large industrial codebases. D EEP D ISCOVERY uses a two-stage Location–Inference framework to localize high-confidence task anchors and recover broader taskrelevant context over multi-relational repository structure under budget constraints. Across controlled method-level evaluation, organization-internal industrial repository-understanding scenarios, and end-to-end evaluation on SWE-bench Verified, D EEP D ISCOVERY consistently improves task-relevant file recovery and downstream SE performance. On 27 medium-scale tasks, D EEP D ISCOVERY achieves the best file recovery quality among five representative baselines without offline preprocessing. On organization-internal industrial tasks from a production-scale integrated codebase ecosystem, including 27 medium-scale tasks and 40 large-scale tasks, D EEP D ISCOVERY improves Full Recall Rate across multiple AI coding systems, with absolute gains ranging from 1.6 to 9.2 percentage points on large subprojects and from 2.5 to 7.4 percentage points on medium-scale subprojects. In a controlled end-to-end evaluation on SWE-bench Verified, a system equipped with D EEP D ISCOVERY achieves a 78.6% Solve Rate, outperforming the corresponding baseline by 8.2 percentage points. These results suggest that stronger task-level repository understanding can improve coding-agent performance on complex SE tasks. Index Terms—LLMs, Repository Understanding, Adaptive Repository Compression, Task-Level Context Recovery.
I. I NTRODUCTION Large language models (LLMs) have shown strong performance on a wide range of software engineering (SE) tasks, including code summarization [1], code generation [2], program repair [3], repository-level question answering [4], and end-to-end task solving [5]. However, strong performance on such tasks does not necessarily imply that current models can reliably understand large industrial code repositories [6], [7]. In realistic SE settings, successful task completion often requires reasoning not over a few isolated code fragments, but over a broader and more complete task-relevant context spanning interfaces [8], business logic [9], configuration [10], tests [11], and cross-module dependencies [12]. Bridging this gap remains a fundamental challenge [13]. Corresponding author: [email protected]
The challenge becomes more pronounced in large industrial repositories, which typically contain massive numbers of files, complex dependencies, mixed artifact types, and continuously evolving organization [14]. In such settings, existing methods often recover only limited local context. Semantic retrieval can return textually similar code fragments, but it may miss entities that are structurally important yet lexically less salient [15]. Static dependency expansion can recover part of the explicit structure, but it still struggles with many task-relevant links that are only implicitly expressed, such as configuration registration, dependency injection, event propagation, and crossmodule constraints [16]. As a result, LLMs often see useful fragments without recovering the broader implementation context required by the task. In practice, repository understanding also faces an important systems challenge beyond retrieval quality: repository freshness. Many repository-understanding methods rely on prebuilt vector indexes [17], static graphs [18], or other offline artifacts [19]. While effective in relatively stable settings, such artifacts can be costly to maintain in industrial environments with frequent commits, branch switching, module evolution, and configuration changes. When synchronization lags behind repository evolution, retrieval quality and practical timeliness can both degrade. This makes repository understanding not only a question of what context is recovered, but also whether it can be recovered effectively under realistic freshness, budget, and deployment constraints. To address these challenges, we propose D EEP D ISCOVERY, which treats repository understanding as task-relevant context recovery rather than fragment retrieval. Rather than searching for all relevant context in a single global step, D EEP D IS COVERY first identifies a small set of high-confidence task anchors and then expands from them to recover a broader implementation path. Compared with GraphRAG-style approaches that mainly expand over pre-built structural artifacts, D EEP D ISCOVERY combines adaptive repository compression with a staged Location–Inference process to better preserve project structure and recover more complete task-relevant implementation paths. D EEP D ISCOVERY uses metadata-first context construction and loads full text only when needed. We evaluate D EEP D ISCOVERY at the method, system, and end-to-end levels. Across controlled repository-understanding benchmarks and a production-scale integrated codebase
ecosystem, D EEP D ISCOVERY consistently improves taskrelevant file recovery quality. In a controlled end-to-end evaluation on SWE-bench Verified, a system equipped with D EEP D ISCOVERY achieves a 78.6% Solve Rate, outperforming the best baseline by 8.2 percentage points. The main contributions of this paper are as follows: • We propose D EEP D ISCOVERY , a task-level repositoryunderstanding method for large industrial codebases. Unlike fragment-retrieval approaches, it targets complete task-relevant context recovery under budget constraints through a two-stage Location–Inference framework that combines anchor localization, multi-relational expansion, and metadata-first context construction. • We conduct a controlled method-level comparison between D EEP D ISCOVERY and representative repositoryunderstanding baselines, evaluating both recovery quality and practical cost. The results show that D EEP D ISCOVERY achieves strong task-relevant file recovery quality while avoiding offline preprocessing and reducing tasktime latency relative to RAG-style alternatives. • We conduct a systematic evaluation of D EEP D ISCOVERY on a production-scale integrated repository ecosystem and in multiple real AI coding systems. The results show that D EEP D ISCOVERY substantially improves taskrelevant file recovery in realistic industrial settings. • We further show, under a controlled end-to-end comparison, that improving repository understanding is associated with stronger SE performance. A system equipped with D EEP D ISCOVERY achieves a 78.6% Solve Rate on SWE-bench Verified, improving over the corresponding baseline by 8.2 percentage points. II. R ELATED W ORK A. Code Repository Understanding Recent work on LLM-based software engineering (SE) has moved beyond standalone code completion toward toolintegrated and agentic systems that support repository exploration, iterative reasoning, and multi-step task execution [20]– [23]. These systems have achieved strong performance on public benchmarks [24]–[26], suggesting substantial promise for real-world SE tasks. At the same time, strong benchmark performance does not imply robust repository-scale understanding in realistic development settings, where tasks often involve extensive cross-file dependencies, inter-module relationships, and long implementation paths [6], [7], [27]. These limitations motivate methods that can provide higherquality repository-level context for downstream reasoning. Retrieval-augmented generation (RAG) is a widely used paradigm for repository-level code understanding [28]. Typical methods partition repositories into file-level or chunk-level units, retrieve task-relevant content through semantic similarity, and provide the selected context to an LLM for downstream reasoning [29], [30]. To improve on purely semantic retrieval, subsequent work incorporates static program structures such as call graphs, import graphs, and symbol reference
graphs, yielding structure-augmented retrieval or GraphRAGstyle pipelines [30]–[32]. These approaches generally improve cross-file coverage by exploiting explicit dependencies more effectively than pure vector retrieval [33]. However, most existing methods still frame repository understanding primarily as locating relevant fragments. This is often insufficient for tasks that require recovering a broader implementation chain across files, modules, abstraction layers, configuration artifacts, and tests. The limitation is especially pronounced in industrial repositories, where many critical taskrelevant links are only implicitly expressed. In addition, many retrieval-based pipelines depend on offline indexes or structural artifacts whose refresh cost may become significant in fast-changing repositories [28], [30]–[32]. These observations suggest the need for methods that move beyond fragment retrieval toward task-level context recovery under practical freshness and budget constraints. Beyond standalone retrieval pipelines, recent research and industrial coding systems increasingly treat repository-scale SE as a system-level reasoning problem rather than a pure context-selection problem [26], [34]. In practice, coding assistants often integrate repository search, multi-hop navigation [35], long-context reading [36], execution tools [37], and iterative planning [38] to support complex tasks over large codebases. These systems show that end-to-end performance depends not only on retrieving relevant files, but also on connecting scattered evidence into a coherent task-specific reasoning process. B. Code Feature Localization Code feature localization concerns identifying the code entities most likely to implement or constrain a target functionality or change request. In repository-scale SE tasks, localization is a critical first step because downstream reasoning depends heavily on whether the system can identify reliable entry points before broader exploration begins. Existing retrievalbased methods typically localize candidates through lexical matching, embedding similarity, or query-conditioned ranking over files and code chunks [28], [29]. Structure-augmented methods further improve localization by incorporating explicit dependency signals such as call, import, inheritance, and reference relations [30]–[32]. However, accurate localization in large industrial repositories remains difficult when treated purely as a similarityranking problem. Many important entry points are only weakly expressed in local text and instead depend on naming conventions, framework idioms, configuration bindings, registration mechanisms, artifact roles, and directory organization. As a result, methods optimized for local relevance may still miss the high-confidence anchors needed for broader task resolution [6], [7]. Our Location stage is closely related to this line of work, but differs by performing environment-aware narrowing before candidate scoring and combining semantic evidence, structural summaries, rule-template matches, and task-conditioned artifact priors. This design aims to identify
anchors that better support subsequent implementation-path recovery, rather than only ranking locally relevant files. III. OVERVIEW OF D EEP D ISCOVERY Figure 1 illustrates the overview of our D EEP D ISCOVERY. It takes as input a natural-language SE task and a large evolving repository, and produces a structured task-level context for downstream reasoning. D EEP D ISCOVERY uses a two-stage Location–Inference workflow to identify task anchors and recover broader task-relevant context. It outputs a structured context package with selected entities, metadata or text views, structural relations, and inclusion rationales. A. Problem Formulation Given a repository: R = {f1 , f2 , . . . , fN },
(1)
where each fi is a repository artifact such as a source file, test file, or configuration file, and a natural-language task q, D EEP D ISCOVERY aims to construct a task-relevant structured context: B(q) = {(ei , zi , ρi )}M i=1 ,
C⊆V
s.t.
Cost(C) ≤ Γmax ,
(3)
where Util(C | q) captures how well the constructed context supports task understanding, and Cost(C) reflects the practical cost consumed by exploration, context construction, and fulltext loading. In our implementation, Γmax is set as a task-time budget determined by the host system’s effective context window, tool-execution allowance, and latency target. Operationally, we instantiate Γmax as a normalized budget that jointly accounts for token usage and exploration steps, so that different repositories and tasks can be handled under a comparable decision rule. In the deployed system, this formulation is used to organize executable scoring, expansion, and stopping decisions during repository exploration, rather than to define an exact global optimization algorithm. B. Repository Representation and Overall Framework D EEP D ISCOVERY represents the repository as a multirelational graph G = (V, A),
Require: Task q, repository R, budget Γmax Ensure: Structured task context Cˆ 1: Infer task environment cq and build a compressed repository view under budget Γloc 2: Score candidate entities with Eq. (6) and select top-Ka anchors Ĥ 3: Initialize C0 ← Ĥ, remaining budget Γ ← Γmax − Γloc , t ← 0 4: while Γ > 0 do 5: Generate candidate expansion actions from explicit, implicit, organizational, and local-search relations 6: Compute Priority(d | Ct , q) for each action using Eq. (7) 7: Let d∗ = arg maxd Priority(d | Ct , q) 8: if Priority(d∗ | Ct , q) < τ then 9: break 10: end if 11: Expand Ct with d∗ to obtain Ct+1 , update the remaining budget Γ, and set t ← t + 1 12: end while 13: for each selected entity e ∈ Ct do 14: Choose metadata or full text using Eq. (8) 15: end for 16: Serialize selected evidence, relations, and rationales into Cˆ 17: return Cˆ
(2)
where ei is a selected repository entity, zi is its contextual representation, and ρi records the structural rationale for including it. Depending on the stage of reasoning, zi may be either a metadata view or full-text content. We formulate this process as budgeted context construction. Given a candidate entity space V induced from repository R, we seek a context set with high task utility under a bounded exploration budget: C ∗ (q) = arg max Util(C | q)
Algorithm 1 D EEP D ISCOVERY: Task-Level Repository Understanding
(4)
where V denotes repository entities and A denotes relations among them. Consistent with Figure 1, the relation space combines three sources of structure: (1) explicit dependencies, such
as imports, calls, inheritance, and references; (2) implicit taskrelevant links, such as configuration-to-code mappings, registration sites, dependency-injection wiring, event or callback bindings, and test-to-implementation bridges; and (3) organizational relations, such as folder containment, module boundaries, ownership cues, and physical proximity. In implementation, implicit links are extracted from a lightweight rule library covering recurring repository idioms such as configuration-tocode bindings, registration sites, test-to-implementation correspondences, and interface-to-implementation mappings. Each extracted link is assigned a relation type and a confidence level based on matched signals. Low-confidence implicit links are expanded only when supported by an additional semantic or organizational cue. In the Location stage, the system narrows the search space and identifies a small set of high-confidence task anchors. In the Inference stage, it expands from these anchors over the multi-relational repository graph, recovers a broader implementation path, and constructs a structured task-level context under the available budget. Formally, let H ⊆ V denote the task-anchor set. The overall process is implemented as: Ĥ = Locate(q, R, Γmax ),
Cˆ = Infer(Ĥ, q, G, Γmax ),
(5)
In implementation, the total budget Γmax is split into a localization budget Γloc and a remaining inference budget Γmax − Γloc . This decomposition reduces search cost while supporting repository-scale execution. Algorithm 1 summarizes the executable workflow used in our implementation. To improve reproducibility, we make the main budget and stopping decisions explicit rather than leaving them fully implicit in LLM reasoning. In all reported experiments, the default anchor count is Ka = 8, the expansion stopping threshold is τ = 0.15, and the
DeepDiscovery
Input Layer Query Source… Task Types Bug Fixing Test Repair
Inference Stage
Environment-Aware Analysis
Multi-Relational Repository Graph
Repository Input Industrial-Scale Code Repo
e.g., import, call, inheritance
Implicit dependencies
e.g., event, DI, config
Adaptive Repository Compression
Organizational relations
e.g., folder, physical, ownership
Interface
Service
Dependency Bridge Test
Config
Content View Structure View
Repo
Relation View
Budget-aware
Scale-aware
Rule-Guided Anchor Localization
+
+
+
+
Semantic Summary Naming Directory Domain Similarity Alignment Patterns Rules Lexicon
Massive Files Repo Evolution
Implementation Path
Explicit dependencies
Constraint Detection
Stack Inference
Configuration Update Logic Modification
Output Layer
Location Stage
Task Input
Heuristic Rule-Based Scoring
Broad Search Mixed Artifacts Deep Dependences
Anchor Output (API, Service, Config, Test)
Implementation-Path Recovery Budget Control Relevance Expansion + Value Expansion
Structured Context Selected Entities Metadata
Candidate Construction and Re-Ranking repo framework
Inclusion Rationale
...
Candidate Sources
Structure Relation
Candidate Clusters
Candidate Filtering
Re-Rank
Metadata-First Context Construction Metadata Cards
+
Text Cards
View Specification Repository View Architecture View Historical Description
Path View
Fig. 1: Overview of D EEP D ISCOVERY. Given a task description and a large industrial repository, D EEP D ISCOVERY first performs a Location stage to narrow the search space through environment-aware analysis, adaptive repository compression, and rule-guided anchor localization. It then performs an Inference stage to expand from these anchors over a multi-relational repository graph, recover a broader implementation path, and construct a metadata-first structured context. The recovered evidence is further compressed into a structured task-level context package for downstream reasoning, rather than being passed to the downstream model as a flat list of retrieved files.
metadata-promotion threshold in Eq. (8) is κ = 0.62. These values were selected on a held-out development set and then fixed for all reported evaluations. Expansion also stops early if two consecutive actions introduce no new artifact role or bridge relation.
C. Location: Task Anchor Localization The purpose of the Location stage is to identify a small set of high-confidence entry points for subsequent reasoning. As shown in Figure 1, this stage consists of three steps: environment-aware analysis, adaptive repository compression, and rule-guided anchor localization. Environment-Aware Analysis. D EEP D ISCOVERY first infers task-relevant contextual factors such as the likely technology stack, module scope, artifact-role priors, and explicit task constraints. This step helps narrow the repository region that should be searched and suppresses obviously unrelated areas before deeper exploration begins. Adaptive Repository Compression. D EEP D ISCOVERY constructs a compressed repository view under the available budget. Rather than using a fixed summary format, D EEP D ISCOVERY adjusts the granularity of the repository view according to repository scale, structural complexity, and context budget. Under larger budgets, it preserves richer module and interface cues; under tighter budgets, it prioritizes compact structural summaries and representative entities.
Rule-guided Anchor Localization. Finally, the system ranks candidate entities using four executable signals: Scoreloc (v | q) = αs̃sem (q, v) + βs̃sum (q, Sv ) + γs̃rule (v, q, cq ) + δπ(type(v) | q).
(6)
where s̃sem (q, v) combines embedding similarity and BM25style lexical matching between the task and the metadata view of entity v, s̃sum (q, Sv ) measures alignment with the compressed structural view associated with v with LLM assistance, s̃rule (v, q, cq ) aggregates matched rule templates such as naming patterns, directory patterns, framework-specific keywords, and domain-lexicon cues, and π(type(v) | q) is a task-conditioned prior over artifact roles. In implementation, matched rule templates are injected into a constrained scoring prompt with fixed output fields. The coefficients α, β, γ, δ are chosen from a small set of predefined configurations based on repository scale and localization ambiguity. Intuitively, more ambiguous settings place greater emphasis on structural and rule-based evidence, while clearer settings rely more on direct semantic matching. The prior π(type(v) | q) is specified using language-specific artifact-role characteristics. This keeps anchor scoring executable while still allowing limited tasktime adaptation. The highest-ranked entities are selected as task anchors for the Inference stage. D. Inference: Multi-Relational Implementation-Path Recovery Given the task anchors produced by Location, the Inference stage incrementally recovers a broader task-relevant
implementation path. As shown in Figure 1, this stage operates over a multi-relational repository graph and consists of implementation-path recovery, candidate construction, reranking, and structured context construction. At each step, D EEP D ISCOVERY considers candidate expansion actions from the current context. An action may follow explicit dependencies, implicit task-relevant links, organizational proximity, or local-search results. Rather than expanding all reachable neighbors uniformly, the system prioritizes expansion actions using a budget-aware score: Priority(d | Ct , q) =
Gain(d | Ct , q) . Cost(d)
The final part of the Inference stage constructs the task context in a metadata-first manner, as illustrated by the metadata-card and text-card views in Figure 1. The key idea is to preserve structural coverage while loading full text only when necessary. For each selected entity e, D EEP D ISCOVERY chooses between a metadata view m(e) and full-text content FullText(e): m(e), if u(e | q, Ct ) < κ, FullText(e), otherwise,
We evaluate D EEP D ISCOVERY from three perspectives: controlled method-level comparison, system-level repositoryunderstanding evaluation in real AI coding systems, and endto-end impact on SWE-bench Verified. We further include ablation, efficiency, and error analysis. A. Research Questions
E. Metadata-First Context Construction
ze =
IV. E XPERIMENTS
(7)
Here, Gain(d | Ct , q) estimates how much action d improves task relevance and implementation-path completeness, while Cost(d) estimates the additional exploration and contextconstruction cost introduced by that action under the same normalized budget accounting used for Γmax . In implementation, each action d is defined at relation-edge granularity. Gain(d | Bt , q) combines the relevance of newly reachable entities, the likelihood that the action bridges currently separated but jointly necessary parts of the implementation path, and the extent to which it helps recover still-missing artifact roles such as configuration, registration, tests, or interface-toimplementation links. Cost(d) reflects the additional context and execution overhead introduced by the action, including estimated token usage and exploration latency. Expansion stops when the remaining budget is exhausted, when the best available priority falls below a threshold, or when no candidate action is predicted to add sufficient task-relevant coverage. The selected actions are used to construct candidate clusters of related entities around the current anchors and partially recovered path, which are then filtered and re-ranked before being added to the task context.
(
evidence into a structured context package for the downstream model. The resulting package may include selected entities, metadata summaries, promoted text spans, structural relations, and inclusion rationales.
(8)
where u(e | q, Ct ) is a task-time promotion score indicating whether full-text inspection is likely to be necessary. In implementation, u(e | q, Bt ) is computed from lightweight symbolic features together with a constrained LLM judgment over fixed decision fields, based on whether e is likely to be directly modified, whether it lies on a high-confidence implementation path, whether it is supported by multiple anchors or relation types, and whether metadata alone appears insufficient for downstream reasoning. After this acquisition step, D EEP D ISCOVERY further compresses and serializes the selected
RQ1: How does D EEP D ISCOVERY compare with representative repository-understanding baselines in recovery quality and practical cost on medium-scale benchmarks? RQ2: Can D EEP D ISCOVERY improve repositoryunderstanding quality in real AI coding systems, especially in terms of fully recovering task-relevant files? RQ3: When integrated into an end-to-end software engineering system, can D EEP D ISCOVERY improve task Solve Rate on realistic software engineering tasks? RQ4: When used as a repository-understanding enhancement module, does D EEP D ISCOVERY provide stable gains across heterogeneous AI coding systems, project scales, and model backends? B. Experimental Setup a) Benchmarks and evaluation scenarios.: The mediumscale and large benchmarks are drawn from a production-scale integrated codebase ecosystem that contains multiple large subprojects, sub-repository-like components, and heterogeneous business modules. This ecosystem contains 2.67 million lines of code and more than 25,000 files, spanning structurally distinct subprojects with different scopes, dependency patterns, and organizational boundaries. The medium-scale benchmark contains smaller and structurally simpler subprojects for rapid validation, while the large benchmark consists of larger and more structurally complex subprojects and business scenarios drawn from the same integrated repository ecosystem. For the method-level comparison in RQ1, we use the 27 medium-scale tasks with 135 manually annotated gold relevant files in total. For the system-level repository-understanding evaluation, we use both the 27 medium-scale tasks and the 40 large-subproject tasks, following the same annotation protocol. For the end-to-end evaluation, we use SWE-bench Verified under a controlled comparison protocol. b) Gold annotations.: The gold relevant-file sets used in our repository-understanding evaluation were prepared independently by domain experts before the development of D EEP D ISCOVERY. They were not created for this study and were not tailored to favor the proposed method. For each task, annotators identify the minimal file set required for understanding and completing the task, including implementation files, bridge files, configuration or registration files, and tests when they are necessary for reasoning or modification.
Ambiguous cases are resolved through joint review. These annotations are used only for evaluation and are never exposed to the evaluated systems. Because the annotation process predates D EEP D ISCOVERY, the benchmark construction is methodindependent and reduces the risk of post hoc evaluation bias. As with many complex software-engineering annotations, slight variation across experts remains possible. Our end-to-end benchmark, SWE-bench Verified, is public. For the industrial evaluation assets, including gold relevantfile annotations, industrial task descriptions, relation-extraction specifications, and system-integration details, we plan to release a desensitized version after internal compliance review. The repository-scale statistics used in this study have already been publicly disclosed at the organizational level. We distinguish two types of evidence in this paper. The SWEbench Verified evaluation provides publicly reproducible endto-end evidence. By contrast, the repository-understanding evaluation on the integrated industrial codebase ecosystem provides organization-internal deployment evidence and is not yet independently reproducible. We therefore use the two settings for complementary purposes rather than treating them as interchangeable. c) Compared systems and baselines.: To evaluate the applicability of D EEP D ISCOVERY in realistic development settings, we consider six representative AI coding systems: Cline, Cursor, Claude Code, Codex, OpenCode, and Qoder. Cline and Cursor use Claude Sonnet 4.5, Claude Code uses Claude Opus 4.6, Codex and OpenCode use GPT-5.4, and Qoder uses Qwen3.5-Plus. These systems cover diverse workflows, including search-driven and tool-orchestration-based systems, as well as systems with stronger underlying models. At the method level, we compare D EEP D ISCOVERY with five representative repository-understanding baselines: DeepWiki, CodeWiki, RAG, GraphRAG, and AST+GraphRAG. To reduce confounding from host-system or model differences, all methods in RQ1 are run on top of Claude Code with the same foundation model, Claude Opus 4.6. Each configuration is executed three times. d) Controlled comparison and fairness.: For the RQ1 method-level comparison, the proposed method and the five baselines are evaluated under the same task set, execution environment, host system, and repetition protocol. To ensure fairness, we explicitly separate preprocessing cost from task-time execution cost. For RAG, GraphRAG, and AST+GraphRAG, index construction, graph construction, AST parsing, and repository-refresh operations are counted as preprocessing. For DeepWiki, CodeWiki, and D EEP D ISCOVERY, summary construction, compression, and other preparatory operations are counted under the same accounting rule. In large and evolving repositories, preprocessing latency, refresh overhead, and token cost are part of the practical quality of a repositoryunderstanding method rather than external nuisance factors, and are therefore included in the evaluation scope. For the endto-end evaluation on SWE-bench Verified, the baseline system and the D EEP D ISCOVERY-enhanced system use the same
model, prompting strategy, tool interface, execution policy, and evaluation environment, and the intended methodological change is limited to the repository-understanding component. e) Practical scope of comparison.: The compared systems are heterogeneous practical coding agents rather than research backbones sharing a common architecture. We therefore study D EEP D ISCOVERY both as a standalone method under a unified host system in RQ1 and as an enhancement module inside realistic coding agents in the system-level evaluation. C. Evaluation Protocol a) Repository-understanding metrics.: For repositoryunderstanding quality, we use Full Recall Rate (FRR) as the primary metric. Let Q denote the task set, and let Y(q) and Ŷ(q) denote the gold and predicted relevant-file sets for task q, respectively. A task q ∈ Q is considered fully recalled if: Ŷ(q) ⊇ Y(q).
(9)
The Full Recall Rate is defined as: FRR =
i 1 X h 1 Ŷ(q) ⊇ Y(q) . |Q| q∈Q
(10)
We choose FRR as the primary repository-understanding metric because, in large-repository software engineering tasks, missing a single bridge, configuration, registration, or test file can prevent correct implementation even when several locally relevant files are retrieved. FRR therefore most directly reflects whether a method recovers a complete task-relevant file set for downstream code implementation. We also report Micro Recall (MR) and Micro Precision (MP) as auxiliary file-level metrics. Because FRR is intentionally recall-oriented, we interpret it jointly with MR, MP, execution-token cost, and endto-end Solve Rate rather than as a standalone retrieval-quality indicator. Under our controlled comparisons, all methods are subject to the same host-system context limit and task-time execution policy, so FRR gains cannot be obtained through unbounded file accumulation. Let H denote the total number of correctly recovered files across all tasks, F the total number of gold relevant files, and P the total number of predicted files. b) End-to-end metric.: For the paired SWE-bench comparison, we additionally apply the McNemar test on perinstance solved/unsolved outcomes between the baseline and the D EEP D ISCOVERY-enhanced system. For this end-to-end software engineering performance, let Q denote the total number of tasks and Qsolved the number of successfully solved tasks. We define Solve Rate (SR) as: SR =
Qsolved . Q
(11)
c) Cost metrics.: To assess practical efficiency, we additionally report cost-related metrics for the method-level comparison: Avg. Preprocess Time, Avg. Execution Time, Avg. Preprocess Tokens, and Avg. Execution Tokens. Here, preprocessing refers to method-specific preparation steps before the task-time repository-understanding stage, such as repository summary construction, vector-index construction, graph construction, AST parsing, or related structural preprocessing.
Execution refers only to the repository-understanding step itself, including task-time localization, retrieval, expansion, reranking, and context construction for the current task, rather than the total time or total token usage for completing the full software engineering task. d) Metric derivation and reporting.: All repositoryunderstanding metrics are computed from run-level count statistics. For the large-subproject benchmark, we use T = 40 tasks and F = 240 gold relevant files; for the medium-scale benchmark, T = 27 and F = 135. Each configuration is executed three times. FRR is reported as mean (min–max) across runs, while MR and MP are reported as min–max across runs. Unless otherwise stated, repository-understanding metrics are computed against expert-annotated gold relevantfile sets, while end-to-end Solve Rate is computed under the benchmark’s official execution and verification protocol. D. RQ1: Method-Level Comparison on Medium-Scale Tasks To answer this question, we compare D EEP D ISCOVERY with five representative repository-understanding baselines: DeepWiki, CodeWiki, RAG, GraphRAG, and AST+GraphRAG, on the 27 medium-scale benchmarks under a unified controlled setting. Table I summarizes the results. Overall, D EEP D ISCOVERY achieves the highest FRR (92.6%) among all compared methods while requiring no offline preprocessing. From a quality perspective, D EEP D ISCOVERY outperforms all five baselines in FRR, exceeding AST+GraphRAG (90.4%), GraphRAG (90.2%), CodeWiki (88.2%), DeepWiki (88.0%), and RAG (84.4%). Graph-based baselines improve over pure RAG, but still remain below D EEP D ISCOVERY; RAG performs worst, especially in MR. D EEP D ISCOVERY is also competitive in MR and MP, indicating that its higher FRR does not come with a disproportionate precision penalty. The efficiency results further strengthen this conclusion. D EEP D ISCOVERY, DeepWiki, and CodeWiki require no offline preprocessing, whereas RAG, GraphRAG, and AST+GraphRAG incur substantial preparation cost. RAG requires about 7.0 hours of preprocessing and 2.26 billion preprocessing tokens on average, while GraphRAG and AST+GraphRAG each require about 9.0 hours, with 3.14 and 3.98 billion preprocessing tokens, respectively. At task time, DeepWiki and CodeWiki are the fastest methods, but they also underperform D EEP D ISCOVERY in FRR. More importantly, all three RAG-style pipelines are markedly slower than D EEP D ISCOVERY, requiring 57.2, 63.8, and 44.8 seconds, respectively, compared with 13.2 seconds for D EEP D ISCOVERY . Although D EEP D ISCOVERY consumes more execution tokens than DeepWiki and CodeWiki, its execution-token cost remains below AST+GraphRAG and is associated with the best FRR among all methods. In summary, D EEP D ISCOVERY achieves the highest FRR under the reported controlled setting while avoiding offline preprocessing. We do not interpret this result as a pure precision advantage; rather, it reflects a stronger recall–cost trade-off for task-level context recovery. Notably, D EEP D ISCOVERY also uses fewer execution tokens
than AST+GraphRAG while achieving higher FRR, which weakens the alternative explanation that the gain comes simply from exposing more repository content. E. RQ2: Repository Understanding in AI Coding Systems Across all evaluated systems, the most consistent improvement appears on FRR. Table II summarizes the aggregate results, show run stability and metric-wise gains. On large subprojects, FRR improves for all six systems, with the largest gains for Cline and OpenCode. The same pattern holds on medium-scale subprojects, with smaller margins. These gains reflect improved recovery of complete task-relevant file sets. Figure 2 shows that the improvement is stable across runs and generally larger on large subprojects. This pattern is consistent with the interpretation that systems with weaker native repository search and context construction capabilities have more headroom to benefit from stronger task-level context recovery. Table II further shows that gains are concentrated more on MR than on MP, indicating that D EEP D ISCOVERY primarily improves completeness rather than aggressive pruning. Overall, D EEP D ISCOVERY improves repository-understanding quality across real AI coding systems, with the clearest gains on FRR. F. Ablation Study: Where Do the Gains Come From? Because the Inference stage depends on anchors produced by Location, removing the entire Location stage would not yield a meaningful executable variant. We therefore adopt targeted ablations that preserve the semantics of the pipeline. Specifically, we evaluate four reduced variants in addition to the full system: Location-only, which performs environmentaware analysis, adaptive compression, and anchor localization without inference-based relation expansion; w/o Adaptive Compression, which replaces the adaptive compressed repository view with a simpler non-adaptive summary during anchor localization; w/o Implicit Relations, which removes implicitrelation signals during inference and keeps only explicit and organizational relations; and w/o Metadata-First, which disables metadata-first promotion and materializes selected entities more eagerly as full text. Table III shows that all removed components reduce recovery quality. Compared with the full system, Locationonly lowers FRR from 85.8% to 80.0%, showing that anchor localization alone is insufficient for recovering complete implementation paths. w/o Adaptive Compression reduces FRR to 81.5% and MR to 83.9%, indicating that adaptive compression helps preserve repository structure at a granularity useful for both localization and expansion. w/o Implicit Relations reduces FRR to 83.3% and MR to 87.4%, supporting the claim that many task-relevant files are connected through frameworkmediated or configuration-level links rather than only explicit dependencies. w/o Metadata-First reduces FRR to 82.2% and MR to 85.7%, suggesting that preserving structural coverage before selectively promoting full text is more effective than materializing detailed content too early.
TABLE I: Method-level comparison on the 27 medium-scale benchmarks. All methods are run on top of Claude Code with Claude Opus 4.6 and executed three times. FRR is reported as mean (min–max) across runs; MR and MP are reported as ranges across runs. Preprocessing and execution metrics refer only to repository-understanding cost rather than full-task cost. FRR
Claude Code(Native) DeepWiki CodeWiki RAG GraphRAG AST+GraphRAG D EEP D ISCOVERY
MR
MP
Avg. Preprocess Time (h)
Avg. Execution Time (s)
Avg. Preprocess Tokens (Billion)
Avg. Execution Tokens
0 0.0 0.0 ≈ 7.0 ≈ 9.0 ≈ 9.0 0.0
0 7.2 8.0 57.2 63.8 44.8 13.2
0 0 0 2.26 3.14 3.98 0
0 4,927 10,730 24,991 28,338 29,677 8,826
88.9% (85.2%–92.6%) 90.4%–95.6% 10.2%–10.9% 88.0% (83.4%–91.8%) 89.6%–94.8% 10.8%–11.3% 88.2% (84.0%–90.2%) 90.4%–95.6% 10.6%–11.1% 84.4% (81.5%–88.9%) 85.8%–91.8% 10.5%–10.9% 90.2% (86.4%–92.6%) 88.6%–96.2% 10.1%–10.6% 90.4% (87.2%–94.4%) 90.2%–94.6% 10.0%–10.5% 92.6% (88.9%–96.3%) 90.4%–96.3% 10.8%–11.1%
Large Projects — Run 1 Native
95
Large Projects — Run 2
+DeepDiscovery
85
+2.5
+5.0
+2.5
+2.5
+2.5
+10.0
75
70
+2.5
Cursor
Claude
Codex
OpenCode
+10.0
80
75
65
Qoder
Cursor
Medium-scale Projects — Run 1
+7.4
+3.7
+3.7
+7.4
80
75
Full Recall Rate (%)
Full Recall Rate (%)
+3.7
85
Claude
Codex
OpenCode
Claude
75
65
Qoder
Cline
Cursor
Claude
Codex
OpenCode
Qoder
95
+3.7
+3.7
+7.4
85
80
70
+DeepDiscovery
+7.4
+3.7
Cline
Cursor
+3.7
+3.7
+3.7
+3.7
90
85
80
75
Cline
Cursor
Claude
System
(d) Medium-scale Projects, Run 1
Qoder
Medium-scale Projects — Run 3 Native
+3.7
+3.7
90
OpenCode
(c) Large Projects, Run 3
+DeepDiscovery +3.7
Codex
System
75
Cursor
80
Medium-scale Projects — Run 2 Native 95
Cline
+0.0
(b) Large Projects, Run 2
+DeepDiscovery
+3.7
85
+5.0 +0.0
System
95
90
+2.5 +2.5
+7.5
70
Cline
(a) Large Projects, Run 1
Native
+DeepDiscovery
90
+5.0 +2.5
System
70
+2.5
+2.5
70
Cline
Native
95
Full Recall Rate (%)
65
85
Large Projects — Run 3
+DeepDiscovery
90
Full Recall Rate (%)
Full Recall Rate (%)
90
80
Native
95
Full Recall Rate (%)
Method
Codex
OpenCode
70
Qoder
Claude
System
Codex
OpenCode
Qoder
System
(e) Medium-scale Projects, Run 2
(f) Medium-scale Projects, Run 3
Fig. 2: Run-level Full Recall Rate across project scales and repeated executions. The first row shows large subprojects and the second row shows medium-scale subprojects; each column corresponds to one repeated run. In nearly all systems and runs, the DeepDiscovery-enhanced setting achieves higher FRR than the native setting, indicating that the gain in complete task-level file recovery is stable rather than run-specific.
Overall: 70.4% (352) → 78.6% (393), +8.2 pts (+41)
100
Baseline +DeepDiscovery +7.3 pts (+17) 192
80
Solve Rate (%)
Overall, the main gains remain concentrated on FRR and MR rather than MP, which is consistent with the recalloriented design of D EEP D ISCOVERY. This ablation is intentionally targeted at components that are central to the executable pipeline and most relevant to the observed gains.
+6.6 pts (+5)
+15.6 pts (+5)
+27.3 pts (+6)
15
58
175 53
+9.1 pts (+4)
+12.5 pts (+1) 6
32 22
23 28 13
60
1
17
19
27
1
+10.6 pts (+2)
23
5
1 4
40
1
4
20
G. RQ3: End-to-End Task Solving Capability
0 django (n=231)
sympy (n=75)
scikit-learn (n=32)
xarray (n=22)
pytest (n=19)
sphinx (n=44)
requests (n=8)
matplotlib (n=34)
pylint (n=10)
seaborn (n=2)
flask (n=1)
Repository
Figure 3 summarizes the repository-wise results. Overall, the D EEP D ISCOVERY-enhanced system solves 393 of 500 tasks (78.6%), compared with 352 of 500 (70.4%) for the baseline, for an absolute gain of 8.2 percentage points (+41 tasks). The gain is statistically significant under a paired McNemar test on per-instance outcomes (p < 0.01). Because D EEP D ISCOVERY changes both which repository evidence is recovered and how that evidence is structured for downstream consumption, this result should be interpreted as matchedcomponent evidence rather than complete causal isolation of file recovery alone. The repository-wise breakdown shows that gains are concentrated in projects whose tasks more often require cross-file, cross-module, or configuration-sensitive reasoning. In particular, D EEP D ISCOVERY solves 17 additional tasks on django, 6
Fig. 3: Solve Rate on SWE-bench Verified by repository. Bar heights show Solve Rate, numbers above bars show resolvedcase counts, and gain annotations report percentage-point improvement together with the increase in resolved cases. DeepDiscovery improves end-to-end performance across several major repositories, with especially visible gains on xarray, scikit-learn, requests, pytest, sphinx, sympy, and django.
on xarray, 5 on sympy, 5 on scikit-learn, 4 on sphinx, and 2 on pytest, with an additional gain on requests. By contrast, gains are limited or absent on more localized subsets, consistent with the zero-gain cases on matplotlib, pylint, seaborn, and flask. Under the controlled matched comparison, these results
TABLE II: Repository-understanding results of AI coding systems on large and medium-scale subprojects. For large subprojects, results are derived from T =40 tasks and F =240 gold relevant files; for medium-scale subprojects, from T =27 tasks and F =135 gold relevant files. Full Recall is reported as mean (min–max) across three runs, while Micro Recall and Micro Precision are reported as min–max across runs. Arrows indicate changes relative to the native setting, and +DD denotes the DeepDiscoveryenhanced setting. Large
Medium
System
Setting
Cline Cline
Native 72.5% (67.5%–77.5%) 75.0%–82.5% 8.9%–9.5% 79.0% (74.1%–85.2%) 82.2%–90.4% 9.6%–11.2% + DD 81.7% (77.5%–85.0%) ↑ 82.1%–88.3% ↑ 9.4%–10.2% ↑ 86.4% (81.5%–92.6%) ↑ 89.6%–96.3% ↑ 10.3%–11.9% ↑
Cursor Cursor
Native 82.5% (77.5%–87.5%) 83.8%–89.2% + DD 85.0% (80.0%–90.0%) ↑ 87.5%–92.1% ↑
8.9%–9.5% 85.2% (81.5%–88.9%) 87.4%–93.3% 10.0%–10.5% 9.1%–9.6% ↑ 88.9% (85.2%–92.6%) ↑ 91.9%–96.3% ↑ 10.2%–10.4% ↓
Claude Code Native 85.0% (80.0%–90.0%) 86.7%–92.1% Claude Code + DD 87.5% (82.5%–92.5%) ↑ 88.3%–93.3% ↑
9.2%–9.7% 88.2% (86.4%–92.2%) 90.4%–95.6% 10.2%–10.9% 9.1%–9.3% ↓ 91.4% (86.6%–94.0%) ↑ 90.4%–96.3% ↑ 10.8%–11.1% ↑
Codex Codex
Native 84.2% (77.5%–90.0%) 85.8%–91.2% + DD 85.8% (80.0%–90.0%) ↑ 85.4%–90.8% ↓
9.0%–9.6% 88.9% (85.2%–92.6%) 89.6%–94.8% 10.0%–10.8% 9.1%–9.6% ↑ 92.6% (88.9%–96.3%) ↑ 91.9%–96.3% ↑ 10.2%–11.0% ↑
OpenCode OpenCode
Native 82.5% (77.5%–87.5%) 85.0%–90.4% + DD 87.5% (82.5%–92.5%) ↑ 89.6%–94.6% ↑
9.0%–9.5% 87.7% (81.5%–92.6%) 88.9%–94.8% 10.0%–10.8% 9.1%–9.4% ↓ 90.2% (82.6%–91.2%) ↑ 94.1%–97.8% ↑ 10.5%–11.0% ↑
Qoder Qoder
Native 82.5% (77.5%–87.5%) 84.2%–89.6% + DD 84.2% (80.0%–87.5%) ↑ 86.7%–91.2% ↑
8.9%–9.4% 85.2% (81.5%–88.9%) 88.1%–94.1% 9.9%–10.7% 9.0%–9.5% ↑ 88.9% (85.2%–92.6%) ↑ 91.1%–95.6% ↑ 10.0%–10.7% ↑
Full Rec.
Mic. Rec.
Mic. Prec.
TABLE III: Ablation results on the large-subproject benchmark under a fixed host-system setting. The full Location– Inference pipeline outperforms all reduced variants, indicating that anchor localization, adaptive compression, implicitrelation expansion, and metadata-first context construction each contribute non-trivially to task-level context recovery. Variant
FRR
MR
MP
Location-only w/o Adaptive Compression w/o Implicit Relations w/o Metadata-First D EEP D ISCOVERY (full)
80.0% 81.5% 83.3% 82.2% 85.8%
85.8% 83.9% 87.4% 85.7% 89.6%
9.5% 9.0% 9.4% 9.2% 9.3%
TABLE IV: Cross-system robustness of DeepDiscovery in terms of Full Recall Rate gain across project scales. All evaluated systems obtain positive gains on both large and medium-scale subprojects. System Cline Cursor Claude Code Codex OpenCode Qoder
Large Gain
Medium Gain
Consistency
+9.2 +2.5 +2.5 +1.6 +5.0 +1.7
+7.4 +3.7 +3.7 +3.7 +4.9 +3.7
2/2 positive 2/2 positive 2/2 positive 2/2 positive 2/2 positive 2/2 positive
indicate that stronger repository understanding can materially improve end-to-end performance, especially for repositories whose tasks require broader implementation-path recovery. H. RQ4: Robustness Across Scales, Models, and Systems Finally, we examine whether the gains of D EEP D ISCOVERY remain consistent across heterogeneous AI coding systems, project scales, and model backends. The evaluated systems differ in both underlying models and agent workflows. As
Full Rec.
Mic. Rec.
Mic. Prec.
shown in Table IV, all six systems achieve positive FRR gains on both large and medium-scale subprojects. The gains are largest for Cline and OpenCode, while Claude Code and Codex still show smaller but consistent improvements. These results suggest that the benefit of D EEP D ISCOVERY is robust across diverse native backends rather than tied to a particular agent workflow. Given that these systems already employ strong but different repository search and contextconstruction strategies, the observed gains are more likely to come from improved task-level repository understanding than from weak baselines. We also observe that stronger foundation models tend to achieve higher absolute FRR under the same integration setting, suggesting that repository understanding and model reasoning are complementary. I. Efficiency and Practical Considerations We next assess whether the quality gains of D EEP D ISCOVERY come at an acceptable practical cost. A key advantage of D EEP D ISCOVERY is that it does not rely on persistent offline repository artifacts, which is particularly beneficial in fast-changing repositories where maintaining global indexes or graphs can be costly. Instead, D EEP D ISCOVERY recovers context online from the current repository state. This advantage is most relevant in fast-changing settings; in relatively stable environments with many repeated tasks, offline artifacts may amortize better across queries, and the trade-off may shift. Our measurements also support the staged design of D EEP D ISCOVERY. Coarse localization using only the compression component takes about 70 seconds on average, whereas local search alone takes about 225 seconds. This supports performing coarse localization first and invoking broader search only when needed, rather than starting from broad global exploration. In practice, this staged workflow narrows the search space and improves localization quality without materially increasing end-to-end latency.
More generally, D EEP D ISCOVERY improves efficiency through progressive budget allocation: it first builds a compressed structural view, identifies high-confidence anchors, and then expands into more detailed task-relevant context. This enables more selective use of context budget and avoids weakly targeted global exploration. Compared with minimal local retrieval, however, D EEP D ISCOVERY introduces additional control logic, relation parsing, and metadata management overhead. Our results suggest that this overhead remains acceptable in the evaluated settings, although the latency–quality tradeoff may vary across repositories, hardware environments, and deployment constraints. Overall, D EEP D ISCOVERY provides a useful quality–cost trade-off under realistic latency, budget, and freshness constraints. J. Discussion of Error Modes and Scope Although D EEP D ISCOVERY improves task-level file recovery in most evaluated settings, it does not benefit all tasks equally. We observe three recurrent failure modes. First, anchor localization remains sensitive to weak, underspecified, or ambiguous task descriptions, particularly in repositories with inconsistent naming conventions or weak organizational signals. When the initial anchors are suboptimal, subsequent expansion may follow an incomplete or misleading implementation path. Second, implicit-relation expansion can introduce structurally nearby but non-essential files. This is partly inherent to the recall-oriented design of D EEP D ISCOVERY: recovering missing bridge, configuration, or test artifacts may also admit limited adjacent non-gold context, reducing precision under tight context budgets. Third, metadata-first exploration can under-expose fine-grained implementation details when promotion is too conservative. In such cases, structural coverage is preserved, but the code evidence needed for downstream reasoning or modification may remain insufficient. At present, D EEP D ISCOVERY is best viewed as a recall-oriented repository-understanding enhancement rather than a uniformly dominant retrieval strategy. Broader validation across repositories, organizations, and technology stacks remains necessary. V. T HREATS TO VALIDITY We discuss threats to validity from four perspectives. a) Internal validity.: A primary threat to internal validity comes from the heterogeneity of the evaluated AI coding systems, which differ in models, tool behavior, search workflow, and context management. These differences may affect final performance independently of the repository-understanding module. To mitigate this threat, we emphasize within-system comparisons between each native system and its D EEP D IS COVERY -enhanced counterpart, use a unified host system for the method-level comparison, and keep the SWE-bench setting matched except for the repository-understanding component. A second threat is baseline implementation variance: different engineering realizations of the same baseline family may yield different absolute results. Our baseline results should therefore be interpreted as controlled evidence under the implementations used in this study rather than as universal rankings.
b) Construct validity.: Construct validity concerns whether our tasks and metrics adequately capture tasklevel repository understanding. We use FRR as the primary repository-understanding metric because missing a single bridge, configuration, registration, or test file can block task completion even when several locally relevant files are retrieved. However, FRR is recall-oriented and may favor methods that recover more complete file sets over methods optimized for sparse precision. We therefore interpret FRR jointly with MR, MP, execution cost, and end-to-end Solve Rate rather than as a standalone measure. A related threat comes from manual gold annotations: although the annotations were prepared independently of D EEP D ISCOVERY, relevance boundaries may still involve judgment in difficult cases. c) External validity.: Our industrial evaluation is conducted on a production-scale integrated repository ecosystem with 2.67M lines of code, more than 25,000 files, multiple large subprojects, and heterogeneous business modules, together with the public SWE-bench Verified benchmark. Nevertheless, the industrial evidence comes from one organization and one integrated development environment, and the repository-understanding benchmark is not yet public. Accordingly, these results should be interpreted as internal deployment evidence rather than independently reproducible benchmark evidence. They provide deployment-oriented evidence, but do not by themselves establish uniform gains across organizations, repositories, or technology stacks. Repositories in other settings may differ in structure, conventions, update frequency, and artifact composition, affecting the relative benefit of task-time context recovery. In addition, the trade-off between online recovery and offline artifacts may differ between fast-changing industrial environments and stable repositories with many repeated queries. d) Conclusion validity.: Our conclusions are supported by multi-level evaluation, repeated runs, and targeted ablations, but several limitations remain. Some benchmark subsets are moderate in size, which limits the strength of small-margin comparisons. Model nondeterminism, annotation noise, hyperparameter choices, and baseline implementation variance may also affect individual measurements. In end-to-end evaluation, changing the repository-understanding component may also change both what task-relevant evidence is exposed and how that evidence is structured for the downstream model, which limits strict causal attribution to retrieval quality alone. We therefore interpret the results as evidence that D EEP D ISCOVERY improves task-level repository understanding under the evaluated conditions, rather than as a claim of complete causal isolation or universal superiority. VI. C ONCLUSION We framed repository understanding in large industrial codebases as a task-level context recovery problem and evaluated D EEP D ISCOVERY in both repository-understanding and end-to-end settings. Across these evaluations, D EEP D ISCOVERY improves recall-oriented recovery of task-relevant context and is associated with better downstream software engineering
performance under the evaluated settings. In a controlled endto-end comparison on SWE-bench Verified, a system equipped with D EEP D ISCOVERY achieves a 78.6% Solve Rate, improving over the corresponding baseline by 8.2 percentage points. Overall, the results indicate that task-level repository understanding can be an important component of coding-agent performance, especially when relevant evidence is distributed across code, tests, and configuration artifacts. Future work includes broader cross-organization validation, richer baseline comparisons, and more fine-grained analysis of the components that contribute to task-level context recovery in different repository settings. R EFERENCES [1] W. Sun, Y. Miao, Y. Li, H. Zhang, C. Fang, Y. Liu, G. Deng, Y. Liu, and Z. Chen, “Source code summarization in the era of large language models,” in Proceedings of the 47th International Conference on Software Engineering, no. 1. Ottawa, Ontario, Canada: IEEE Computer Society, 27 April-3 May 2025, pp. 419–431. [2] M. Alharbi and M. Alshayeb, “Automatic code generation techniques: A systematic literature review,” Automated Software Engineering, vol. 33, no. 1, p. 4, 2026. [3] Q. Zhang, C. Fang, Y. Xie, Y. Ma, W. Sun, Y. Yang, and Z. Chen, “A systematic literature review on large language models for automated program repair,” ACM Transactions on Software Engineering and Methodology. [4] M. Yue, “A survey of large language model agents for question answering,” arXiv preprint arXiv:2503.19213, 2025. [5] Y. Zheng, Y. Chen, B. Qian, X. Shi, Y. Shu, and J. Chen, “A review on edge large language models: Design, execution, and applications,” ACM Computing Surveys, vol. 57, no. 8, pp. 1–35, 2025. [6] Y. B. Alebachew, H. Leary, S. Vaishampayan, and C. Brown, “Beyond code snippets: Benchmarking llms on repository-level question answering,” arXiv preprint arXiv:2603.26567, 2026. [7] R. Pan, B. Mao, T. Ma, and Z. Ling, “Archagent: Scalable legacy software architecture recovery with llms,” arXiv preprint arXiv:2601.13007, 2026. [8] J. Qiu, Z. Liu, Z. Liu, R. Murthy, J. Zhang, H. Chen, S. Wang, M. Zhu, L. Yang, J. Tan et al., “Locobench-agent: An interactive benchmark for llm agents in long-context software engineering,” arXiv preprint arXiv:2511.13998, 2025. [9] J. Gao, Z. Zhang, Y. Sun, Y. Liu, C. Liu, H. Liu, Y. Li, and Y. Liu, “Logicscan: An llm-driven framework for detecting business logic vulnerabilities in smart contracts,” arXiv preprint arXiv:2602.03271, 2026. [10] Y. Fu, T. Wang, S. Li, J. Ding, S. Zhou, Z. Jia, W. Li, Y. Jiang, and X. Liao, “Missconf: Llm-enhanced reproduction of configurationtriggered bugs,” in Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings, 2024, pp. 484–495. [11] Z. Liu, C. Chen, J. Wang, M. Chen, B. Wu, X. Che, D. Wang, and Q. Wang, “Make llm a testing expert: Bringing human-like interaction to mobile gui testing via functionality-aware decisions,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, 2024, pp. 1–13. [12] Z. He, Y. Wang, J. Li, K. Liang, and M. Zhang, “Loogle v2: Are llms ready for real world long dependency challenges?” Advances in Neural Information Processing Systems, vol. 38, 2026. [13] J. Du, Y. Liu, H. Guo, J. Wang, H. Huang, Y. Ni, and Z. Li, “Dependeval: Benchmarking llms for repository dependency understanding,” in Findings of the Association for Computational Linguistics: ACL 2025, 2025, pp. 7150–7179. [14] H. Wang, Z. Ni, S. Zhang, S. Lu, S. Hu, Z. He, C. Hu, J. Lin, Y. Guo, Y. Du et al., “Repomaster: Autonomous exploration and understanding of github repositories for complex task solving,” Advances in Neural Information Processing Systems, vol. 38, pp. 106 320–106 359, 2026. [15] X. Wen, M. Li, J. Huang, J. Zhong, Z. Xu, Z. Li, Y. Huang, M. Yuan, and Q. Xu, “Dependency matters: Enhancing llm reasoning with explicit knowledge grounding,” Advances in Neural Information Processing Systems, vol. 38, pp. 57 966–57 992, 2026.
[16] L. Luo, Z. Zhao, R. Haffari, D. Phung, C. Gong, and S. Pan, “Gfm-rag: graph foundation model for retrieval augmented generation,” Advances in Neural Information Processing Systems, vol. 38, pp. 36 371–36 405, 2026. [17] K. Bevziuk, A. Fatula, S. L. Y. Opanasenko, A. Tukhtarova, A. J. P. Sharma, and H. Shrivastava, “Vector graph-based repository understanding for issue-driven file retrieval,” arXiv preprint arXiv:2510.08876, 2025. [18] Y. Ma, Q. Yang, R. Cao, B. Li, F. Huang, and Y. Li, “Alibaba lingmaagent: Improving automated issue resolution via comprehensive repository exploration,” in Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering, 2025, pp. 238– 249. [19] J. Li, X. Shi, K. Zhang, G. Li, Z. Jin, L. Li, H. Zhang, F. Liu, Y. Zhang, Z. Tao et al., “Graphcodeagent: Dual graph-guided llm agent for retrieval-augmented repo-level code generation,” arXiv preprint arXiv:2504.10046, 2025. [20] M. K. Patel, “Multi-agent llms for autonomous workflow orchestration,” International Journal of Research and Applied Innovations, vol. 8, no. 1, pp. 11 644–11 647, 2025. [21] C. Chen, X. Hao, W. Liu, X. Huang, X. Zeng, S. Yu, D. Li, Y. Huang, X. Liu, W. Xinzhi et al., “Acebench: A comprehensive evaluation of llm tool usage,” Findings of the Association for Computational Linguistics: EMNLP, vol. 2025, pp. 12 970–12 998, 2025. [22] L. Yuan, G. Cui, H. Wang, N. Ding, X. Wang, B. Shan, Z. Liu, J. Deng, H. Chen, R. Xie et al., “Advancing llm reasoning generalists with preference trees,” in International Conference on Learning Representations, vol. 2025, 2025, pp. 24 897–24 919. [23] C. Tian, Y. Wang, X. Liu, Z. Wang, L. Ding, M. Zhang, and M. Zhang, “Agentinit: Initializing llm-based multi-agent systems via diversity and expertise orchestration for effective and efficient collaboration,” in Findings of the Association for Computational Linguistics: EMNLP 2025, 2025, pp. 11 870–11 902. [24] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “Swe-bench: Can language models resolve real-world github issues?” in International Conference on Learning Representations, vol. 2024, 2024, pp. 54 107–54 157. [25] M. A. Merrill, A. G. Shaw, N. Carlini, B. Li, H. Raj, I. Bercovich, L. Shi, J. Y. Shin, T. Walshe, E. K. Buchanan et al., “Terminalbench: Benchmarking agents on hard, realistic tasks in command line interfaces,” arXiv preprint arXiv:2601.11868, 2026. [26] J. He, J. Jia, C. Liu, C. Xue, Y. Song, X. Yang, and D. Sun, “Procbench: Evaluating process-level defects and control preservation in llm coding agents,” arXiv preprint arXiv:2605.20251, 2026. [27] K. Zhang, J. Li, G. Li, X. Shi, and Z. Jin, “CodeAgent: Enhancing code generation with tool-integrated agent systems for real-world repo-level coding challenges,” in Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), L.-W. Ku, A. Martins, and V. Srikumar, Eds. Bangkok, Thailand: Association for Computational Linguistics, Aug. 2024, pp. 13 643– 13 658. [Online]. Available: https://aclanthology.org/2024.acl-long.737/ [28] Z. Yang, S. Chen, C. Gao, Z. Li, X. Hu, K. Liu, and X. Xia, “An empirical study of retrieval-augmented code generation: Challenges and opportunities,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 7, pp. 1–28, 2025. [29] X. Du, G. Zheng, K. Wang, Y. Zou, Y. Wang, W. Deng, J. Feng, M. Liu, B. Chen, X. Peng et al., “Vul-rag: Enhancing llm-based vulnerability detection via knowledge-level rag,” ACM Transactions on Software Engineering and Methodology. [30] K. Guo, H. Shomer, S. Zeng, H. Han, Y. Wang, and J. Tang, “Empowering graphrag with knowledge filtering and integration,” in Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, 2025, pp. 25 450–25 464. [31] D. Edge, H. Trinh, N. Cheng, J. Bradley, A. Chao, A. Mody, S. Truitt, D. Metropolitansky, R. O. Ness, and J. Larson, “From local to global: A graph rag approach to query-focused summarization,” arXiv preprint arXiv:2404.16130, 2024. [32] M. R. Chinthareddy, “Reliable graph-rag for codebases: Astderived graphs vs llm-extracted knowledge graphs,” arXiv preprint arXiv:2601.08773, 2026. [33] D. Liu, M. Chen, B. Lu, H. Jiang, Z. Han, Q. Zhang, Q. Chen, C. Zhang, B. Ding, K. Zhang et al., “Retrievalattention: Accelerating long-context llm inference via vector retrieval,” Advances in Neural Information Processing Systems, vol. 38, pp. 54 358–54 385, 2026.
[34] Y. Wang, Y. Chen, Z. Li, X. Kang, Y. Fang, Y. Zhou, Y. Zheng, Z. Tang, X. He, R. Guo et al., “Burstgpt: A real-world workload dataset to optimize llm serving systems,” in Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V. 2, 2025, pp. 5831–5841. [35] Y. Liu, Q. Peng, B. Liu, H. Liu, X. Li, and W. Wang, “Ds-mhp: Improving chain-of-thought through dynamic subgraph-guided multihop path,” in Findings of the Association for Computational Linguistics: EMNLP 2025, 2025, pp. 11 216–11 230. [36] K. Liu, Z. Su, P. Dong, F. Mo, J. Gao, S. Zhang, and K. Chen, “Smooth reading: Bridging the gap of recurrent llm to self-attention llm on longcontext understanding,” in The Fourteenth International Conference on Learning Representations. [37] S. Yuan, K. Song, J. Chen, X. Tan, Y. Shen, K. Ren, D. Li, and D. Yang, “Easytool: Enhancing llm-based agents with concise tool instruction,” in Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), 2025, pp. 951– 972. [38] Y. Lyu, Z. Niu, Z. Xie, C. Zhang, T. Xu, Y. Wang, and E. Chen, “Retrieve-plan-generation: An iterative planning and answering framework for knowledge-intensive llm generation,” in Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, 2024, pp. 4683–4702.