Context-as-AI-Service: Surfacing Cross-File Dependency Chains for LLM-Generated Developer Documentation Ameya Gawde, Vyzantinos Repantis, Harshvardhan Singh, Lucy Moys Meta Platforms, Inc. {ameyagawde, vrepantis, harshvardhan, ljm}@meta.com
Abstract
arXiv:2606.04397v2 [cs.SE] 4 Jun 2026
LLM agents increasingly write and maintain developer documentation, but usefulness and accuracy often rely on dependency chains that are not obvious to follow. Even with more files in context, the agent must still decide which cross-file dependencies to trace. We present Context-as-AI-Service (CAIS), a retrieval layer that LLM agents query to find evidence across the codebase as they review or generate documentation. CAIS indexes source code, API references, and upstream documentation, then enables agents to query the index through tool calls that combine keyword and semantic search. We evaluate CAIS in two case studies using Claude Sonnet 4.6 on a production SDK: improving API reference comments in a core source file and validating an LLM-generated tutorial. In both studies, the baseline already had ordinary repository tools such as file reads, keyword search, and symbol navigation. CAIS adds a retrieval layer on top, so the comparison isolates added retrieval rather than basic repository access. In the APIreference review, the CAIS-augmented agent produced the same 5 missing-documentation fixes as the baseline and surfaced 4 findings the baseline missed: 2 cross-file factual errors and 2 underspecified API comments. In the tutorial validation, it surfaced 1 executable bug, 1 API-usage improvement, and 2 missing prerequisites that the baseline pipeline did not catch. These findings required tracing non-obvious dependency chains across utility files, framework internals, usage examples, tests, and component-creation logic. Over five runs per condition, adding CAIS reduced wallclock time by 22% to 34% across the two tasks and lowered input-token usage.
1
Introduction
Developer documentation is easy to generate but hard to keep correct. API references become stale as code evolves, tutorials accumulate subtle mistakes, and documentation can drift away from the
internal codebase that serves as the source of truth for system behavior. LLMs are increasingly used to automate documentation tasks, including generating doc comments, writing tutorials, and maintaining reference pages (Chen et al., 2021; Nijkamp et al., 2023). LLM-based coding agents can read source files, understand API signatures, and produce fluent prose at scale. Documentation claims often depend on behavior distributed across files: a method delegating to an internal scheduler, an equality check depending on a separate backing object, a tutorial step relying on framework lifecycle rules, or a component assuming another already exists. Even when many files are available to an agent, the relevant chain may not be obvious. The generated documentation can be locally plausible, yet globally wrong. Many practical LLM workflows give agents ordinary repository tools such as file reads, keyword search, and nearby-file inspection. This helps when the relevant evidence is local or lexically obvious, but it is less reliable when a documentation claim requires following a non-obvious dependency chain: from an API comment to a registry component, from a method name to a state-management layer, from a tutorial example to a utility constructor, or from an interaction component to framework-level componentcreation logic. In these cases, the challenge is not merely having enough tokens. The agent must identify which symbols, examples, tests, or framework rules are worth chasing. Consider a disposal method documented as removing an object and freeing its resources. From the declaring file, this looks plausible. But the implementation hands the actual removal to a separate state-management layer, where cleanup is deferred until the next processing cycle. The documentation can, therefore, mislead developers about cleanup and synchronization. The defect surfaces only after tracing the dependency from
the local API to the layer that defines what removal really does. We call this the cross-file documentation problem: documentation can look correct in its own file while depending on symbols, implementations, examples, tests, or framework rules elsewhere in the codebase. These errors survive because confirming a claim requires finding the specific files it depends on, and the agent rarely knows in advance which files those are. To address this problem, we introduce Contextas-AI-Service (CAIS), a composable retrieval layer for LLM documentation workflows. CAIS does not replace the agent’s decision about which files to inspect. It gives the agent a scoped way to retrieve evidence from the codebase before deciding which dependency chains to follow. During documentation generation or review, the agent queries CAIS – a pre-indexed corpus of source code, API references, tests, examples, and upstream documentation, and receives structured results that point to relevant codebase evidence. The goal is to make non-obvious dependency chains easier to surface without replacing the agent’s file inspection or reasoning steps. This paper makes three contributions: 1. We describe a retrieval architecture suitable for documentation workflows, callable by an agent as a tool, that combines keyword and dense search over code, examples, tests, API references, and upstream documentation. 2. We present two case studies on a production SDK in which this architecture surfaced review findings that baseline workflows with ordinary repository tools missed. 3. We characterize the cross-file documentation problem and provide an evidence trail showing which dependency chain each retained finding required.
2
Related Work
Retrieval-Augmented Generation. Retrievalaugmented generation (RAG) grounds LLM outputs in retrieved documents, reducing reliance on parametric memory (Lewis et al., 2020). Prior work has applied retrieval to code tasks such as code generation and summarization (Parvez et al., 2021; Zhang et al., 2023). CAIS applies retrieval to a different documentation failure mode: claims
Figure 1: CAIS system architecture. The LLM agent queries a retrieval service during its documentation workflow and receives evidence from across the codebase for documentation review.
that are fluent and locally plausible, but contradicted or incomplete once their codebase dependencies are traced. Code Documentation Generation. Automated documentation generation has progressed from template and heuristic systems (Sridhara et al., 2010; McBurney and McMillan, 2014) to neural and LLM-based approaches (Hu et al., 2018; Ahmad et al., 2020; Khan and Uddin, 2022; Geng et al., 2024). Much of this work focuses on generating useful or fluent summaries. We focus instead on validation: whether documentation that reads correctly in one file holds up once the relevant cross-file evidence is checked. LLM Agents for Software Engineering. LLMbased software engineering agents can navigate repositories, execute commands, and complete multi-step tasks (Yang et al., 2024; Jimenez et al., 2024). They typically choose files through repository tools such as file reads, keyword search, and symbol navigation. This works when the relevant evidence is obvious from names, imports, or local call sites, but is less reliable when the dependency chain is semantic or indirect. CAIS complements this agent-driven model with a reusable retrieval layer for surfacing candidate cross-file evidence.
3
System Architecture
CAIS is organized as a four-stage pipeline: ingestion, storage, retrieval, and review. Figure 1 illustrates the architecture. 3.1
Source Ingestion
The ingestion layer collects three source types: • Source code: SDK implementation files, public APIs, internal utilities, and tests.
• API references: Structured documentation extracted from code comments and published API reference pages. • Upstream documentation: Third-party platform or engine documentation relevant to the target SDK. A configurable fetcher normalizes each source into a document record tagged with source type, file path, and last-modified timestamp. This lets one retrieval interface serve code, reference prose, examples, tests, and upstream documentation while preserving enough metadata for freshness checks and re-indexing. The mixed corpus matters because evidence chains often cross source types, such as from an API comment to implementation code, from implementation code to tests, or from tutorial prose to external framework documentation. The corpus itself is configurable, so an operator chooses what to index for a given project. 3.2
Storage and Indexing
Ingested documents are stored in raw and enriched forms. The raw form preserves original formatting for inspection, while the enriched form is tokenized, indexed with BM25, and embedded with DRAMA (Ma et al., 2025). Because the storage layer supports enumeration and bulk retrieval, the corpus can be re-indexed as the codebase evolves. CAIS makes project information searchable along both lexical and semantic dimensions, so agents can query for behavior, symbols, examples, temporal dependencies, or failure modes that may not be obvious from the immediate file. 3.3
Figure 2: Case-study design. The baseline agent performs the documentation task with ordinary repository tools such as file reads, keyword search, and symbol navigation. The CAIS condition uses the same agent and tools, with retrieval from CAIS added over the indexed SDK corpus. We compare the outputs for extra findings backed by cross-file evidence.
cycle..."}, ...]
CAIS is agent-agnostic: any LLM agent able to call tools can query it. In our workflows, agents issued partial or behavior-based queries (describing what the code should do, not just its name), retrieved ranked snippets from CAIS, then opened the underlying files when a finding needed broader context. Retrieval guided the agent’s exploration. It did not replace reading files, and it did not force the agent to follow a fixed list of queries. 3.4
Review Layer
CAIS retrieval results can be used directly by the agent or passed through a lightweight review prompt that labels documentation claims as consistent, contradicted, or incomplete. Retrieved snippets are treated as candidate evidence, not ground truth. In our case studies, a finding was retained only when the evidence supported a concrete correction to the documentation or tutorial.
Retrieval Interface
The retrieval component exposes a tool-callable query interface for LLM agents. BM25 handles exact lexical matches such as method names and enum values, while dense retrieval handles semantically related descriptions, examples, and behavioral explanations. At query time, CAIS combines BM25 and DRAMA results using reciprocal rank fusion (Cormack et al., 2009), then returns ranked snippets with document identifiers and source metadata. Agent -> CAIS: query( "deferred removal semantics", corpus="codebase", top_k=5) CAIS -> Agent: [{doc_id: "...", score: 0.94, snippet: "object will be removed in the next processing
4
Case-Study Protocol
We evaluate CAIS in a retrospective study of two documentation workflows on a production SDK of roughly 200 source files across core, toolkit, and feature packages. Because the SDK and detailed logs are proprietary, we do not try to measure how accurate documentation is across repositories in general. Instead, we ask whether codebase retrieval exposed concrete documentation problems that the recorded baseline workflows missed. Both studies use the design in Figure 2: • Baseline: an LLM coding agent performs the task using its standard repository tools over the working codebase, including file reads,
keyword search, and symbol navigation, but without CAIS. • +CAIS: the same agent, prompts, and repository tools, with CAIS retrieval as an extra tool-callable layer over the indexed corpus. The comparison is between using ordinary repository tools alone and using those same tools together with a retrieval layer that helps find crossfile evidence. The question is whether CAIS exposed non-obvious cross-file dependency chains that the baseline workflow did not follow. We retained a CAIS finding only when three conditions held: (1) the baseline workflow left a meaningful gap – it missed relations that matter for correctness or comprehension; (2) the CAIS run drew on context beyond what an LLM would normally see while working on the immediate task; and (3) the finding would concretely affect how an LLM understands the API, whether the tutorial actually runs, or which implementation steps are needed. Retained findings were manually inspected before inclusion in the evidence trail. This protocol supports a qualitative, evidence-centered case study rather than a controlled benchmark. Section 6.2 lists each finding, its supporting evidence type, and its developer impact.
5
Case Studies
5.1
Case Study 1: API Reference Improvement
Task. We gave an LLM coding agent a core SDK source file of roughly 900 lines, containing a central domain abstraction, and asked it to review and improve the documentation comments on public members. Baseline. Without CAIS, the agent loaded the source file and its immediate dependencies, identified 5 undocumented public methods, and wrote clean, consistent comments for them. It did not flag any existing comment as wrong. With CAIS. With CAIS access, the agent produced the same missing-documentation fixes and surfaced four additional findings: two cross-file factual errors and two incomplete or underspecified API comments. First, the documentation for a lookup method referenced a method name renamed in an earlier API revision and called the argument a type identifier. The evidence that CAIS retrieved from a reg-
istry component and a query layer showed that the argument is actually an attribute identifier. Second, the documentation for a disposal method implied immediate removal, whereas CAIS retrieved state-management-layer documentation showing that removal is deferred to the next processing cycle. Third, the documentation for an equality method defined equality by object ID alone, but CAIS retrieved implementation and test evidence showing that a separate backing object also matters. Fourth, the documentation for an ownership method largely restated the method name. CAIS retrieved evidence from a filter implementation describing what ownership actually means across multiple clients, the detail needed for a useful comment. Finding. CAIS surfaced non-local evidence needed to evaluate existing comments. The baseline corrected missing comments visible in the file, but missed comments whose correctness depended on registry behavior, state-management semantics, tests, or ownership-filter logic elsewhere in the repository. 5.2
Case Study 2: Tutorial Generation and Validation
Task. A multi-stage LLM pipeline generated a step-by-step tutorial for an SDK interaction feature. The pipeline researched source code and samples, drafted the tutorial, reviewed the result, validated technical claims against source, and performed a quality critique. Baseline. Without CAIS, the pipeline produced a tutorial covering interaction-subsystem dependencies, creation of an interactive object, the feature’s input events, and advanced interaction customization. Its validator confirmed 17 API claims, including enum values, method signatures, component fields, and lifecycle behavior. The tutorial passed all five stages and was marked complete. With CAIS. CAIS-augmented post-generation review surfaced four additional findings. The agent queried CAIS to decide which examples, framework rules, utility APIs, and componentcreation behavior to inspect more closely. One finding was an executable bug: the tutorial used an incorrect resource URI scheme for loading external resources. CAIS retrieved canonical examples showing that the scheme prefix already resolves to the resource root, so the tutorial path would
double-nest the directory. Because the URI looked syntactically valid, the pipeline’s validator (baseline) did not flag it. Another finding was an APIidiom improvement: the tutorial used a verbose scaling constructor even though a shorter equivalent was available in a utility module outside the component’s primary definition. The remaining two findings were critical omissions. First, the tutorial demonstrated two lifecycle callbacks without specifying the required base class, leaving developers without enough information to compile the example. CAIS found this requirement in framework documentation. Second, the tutorial created an interactive object from mesh geometry, but the interaction subsystem autogenerates the needed collision-support component only for primitive shapes. Direct contact interaction could, therefore, fail silently while pointerbased interaction worked, a dependency the baseline’s file-by-file validation did not connect to the tutorial scenario. Finding. The baseline validation checked many local API claims correctly, but the retained CAIS findings depended on evidence elsewhere: conventions in example code, a constructor in a utility file, a framework inheritance rule, and a multihop component-creation dependency. The failure mode was not a lack of validation, but validation that did not follow the dependency chains needed to tell whether the tutorial would actually work.
6
Results and Discussion
6.1
Summary of Findings
Table 1 summarizes the retained findings across both case studies. We separate findings that affect correctness from those that improve documentation quality or use a cleaner API idiom, rather than treating every additional finding as the same kind of error. The baseline findings were missing information available in the local source file. The 8 additional CAIS findings required evidence from registry behavior, scheduling semantics, tests, ownership logic, examples, utility APIs, base-class requirements, and component-creation behavior. Because the baseline already had file reads, lexical search, and symbol navigation, the difference comes from surfacing semantic, cross-file evidence rather than from basic repository access.
Finding category
Base +CAIS
Missing public-member docs Cross-file factual errors Incomplete/underspecified API comments Executable tutorial bug API-idiom improvement Critical omitted prerequisites
5 0 0 0 0 0
5 2 2 1 1 2
Total retained findings
5
13
Table 1: Findings retained from the two case studies. CAIS surfaced 8 additional findings not detected in the baseline workflows.
6.2
Evidence Trail
Table 2 provides a compact audit trail for the 8 additional CAIS findings. The table is intentionally phrased in terms of evidence type rather than internal file names, preserving anonymity while showing why each finding required repository-scoped retrieval. 6.3
Dependency-Chain Taxonomy
The case studies suggest a taxonomy by the scope of dependency chain needed to validate a documentation claim: 1. Single-file: missing documentation, style issues, or comments the same file contradicts. 2. Cross-file: stale references, wrong semantics, missing prerequisites, and implicit dependencies that need evidence from other files. 3. Cross-system: mismatches with upstream platform behavior or version-specific external documentation. CAIS can retrieve evidence for all three categories, but its added value concentrates in cross-file issues, where the evidence is often not lexically adjacent to the claim, and in cross-system issues when upstream documentation is in the indexed corpus. Single-file issues are already handled well by ordinary LLM workflows, so retrieval adds little there. 6.4
Efficiency
To measure efficiency, we ran each condition five times: the agent with its native repository tools, and the same agent with CAIS added. We report mean and standard deviation in Tables 3 and 4. The CAIS condition used fewer input tokens and
ID
Finding
Supporting evidence
Why baseline missed it
Impact
F1
Stale method name and wrong parameter meaning in a lookup method Disposal method described as immediate removal Equality method described as ID-only equality Ownership method restated the method name Incorrect resource URI scheme in tutorial Verbose scaling constructor
Registry and query-layer usage showed the argument is an attribute identifier, not a type identifier State-management layer documented deferred removal in the next processing cycle Implementation and tests showed equality also depends on a separate backing object Ownership-filter logic described clientownership semantics Canonical examples showed the scheme prefix already resolves to the resource root Utility module provided a shorter equivalent
Local declaration made the comment look plausible
Wrong API understanding
Method name suggested immediate cleanup ID-only description looked locally plausible Comment was vague rather than contradicted URI looked syntactically valid
Cleanup semantics
Missing required base class for lifecycle callbacks Mesh-based object lacked required collision support
Framework documentation specified the class developers must extend Component-creation logic auto-generates support for primitive shapes but not mesh geometry
F2 F3 F4 F5 F6 F7 F8
Constructor lived outside the primary component definition Callback names validated, but inheritance requirement was omitted File-by-file validation missed the component dependency
Multi-client correctness Useful API reference Tutorial code will fail More idiomatic code Example may not compile Direct contact may fail silently
Table 2: Evidence trail for the 8 additional CAIS findings. Each finding required evidence outside the immediate source file or tutorial validation context.
Metric
Baseline
+CAIS
Wall-clock time (min) Input tokens (K) Output tokens (K) LLM calls Prompt cache hit Query latency CAIS queries
4.1 ± 0.7 17.4 ± 1.8 3.8 ± 0.6 2.4 ± 0.5 84 ± 3% — —
3.2 ± 0.4 14.6 ± 1.3 5.1 ± 0.5 17.6 ± 0.5 91 ± 2% 1.6 ± 0.3 s 15.0 ± 0.0
Table 3: Efficiency for Case Study 1, averaged over five runs per condition (µ ± σ). CAIS reduced wall-clock time by 22% and used fewer input tokens. Metric
Baseline
+CAIS
Wall-clock time (min) Input tokens (K) Output tokens (K) LLM calls Prompt cache hit Query latency CAIS queries
17.2 ± 2.1 112.3 ± 8.6 9.8 ± 1.4 17.4 ± 1.9 71 ± 4% — —
11.4 ± 1.3 76.8 ± 6.2 10.4 ± 1.2 30.2 ± 2.4 84 ± 3% 1.7 ± 0.3 s 13.4 ± 1.1
Table 4: Efficiency for Case Study 2, averaged over five runs per condition (µ ± σ). CAIS reduced wall-clock time by 34% and used fewer input tokens.
finished faster on both tasks, because retrieval returned compact, pre-ranked snippets for the agent to inspect. LLM calls went up because the agent issued retrieval queries as tool calls. These were queries the agent chose as it went, not a fixed script.
7
Conclusion and Future Work
These case studies suggest that cross-file documentation inconsistency is a practical failure mode for LLM-assisted documentation workflows. The problem is not only that agents lack enough context; it is that documentation correctness can de-
pend on non-obvious dependency chains that are easy not to trace. CAIS did not merely help generate more text. It exposed contradictions and missing prerequisites whose supporting evidence lived in utility files, examples, tests, framework documentation, and component-creation logic outside the immediate task context. While our evidence comes from two workflows in one SDK, the observed findings share a common structure: the documentation claim was plausible from the local context, but wrong or incomplete once connected to evidence elsewhere in the codebase. This makes retrieval across the codebase a practical complement to LLM documentation workflows: retrieval can help agents discover which cross-file evidence is relevant before the documentation is trusted. Several directions remain open. Symbol-level indexing could reduce wasted context-window budget by retrieving specific classes, methods, or tests rather than file-level snippets. Difflevel provenance could help agents reason about when documentation and implementation last changed. Future work should also compare retrieval-augmented review against large-context prompting strategies that explicitly instruct agents to trace dependencies. More broadly, a service like CAIS could serve as a general-purpose context layer for code review, bug detection, and other agent-driven software engineering tasks.
Limitations This work is a case study, not a broad benchmark. We evaluate two documentation workflows on one production SDK, and the findings may not gener-
alize to other languages, repositories, documentation genres, or agent designs. The SDK and full logs are proprietary, so we anonymize identifiers and cannot release the underlying corpus. The evidence trail is therefore self-contained at the level of finding type and retrieved evidence, but not independently reproducible from public data. Our baseline was a single coding agent (Claude Code v2.1.154 and model Sonnet 4.6) with its native repository tools on one SDK, not an exhaustive set of baselines. A stronger future evaluation would broaden beyond this to alternative retrieval models, different exploration budgets, and large-context models explicitly prompted to trace cross-file dependencies. We also evaluate documentation quality through retained review findings rather than a controlled human-subject study of developer impact. Finally, the current retrieval layer operates mostly at document or file granularity; symbol-level retrieval improves precision and reduces the number of queries needed to reach actionable evidence.
Ethics Statement Our work focuses on improving the accuracy of developer-facing documentation through retrievalaugmented LLM workflows. The case studies used internal, non-public SDK source code with authorization from the codebase owners. No human participants were recruited, no crowdsourced annotations were collected, and no personally identifiable information was accessed or generated as part of the study. The LLM agent used in the case studies was accessed through a licensed API under the provider’s standard terms of service. We anonymize internal system names, file paths, and identifiable product details, and we present CAIS as a review aid rather than a replacement for human approval. Automated documentation tools can affect technical writing and developer education workflows. In the deployment context studied here, the bottleneck was documentation freshness and correctness rather than writing capacity; CAIS was used to surface evidence for review, not to remove human oversight.
Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics, pages 4998– 5007, Online. Association for Computational Linguistics. Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, and 39 others. 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374. Gordon V. Cormack, Charles L. A. Clarke, and Stefan Büttcher. 2009. Reciprocal rank fusion outperforms condorcet and individual rank learning methods. In Proceedings of the 32nd International ACM SIGIR Conference on Research and Development in Information Retrieval, pages 758–759. ACM. Mingyang Geng, Shangwen Wang, Dezun Dong, Haotian Wang, Ge Li, Zhi Jin, Xiaoguang Mao, and Xiangke Liao. 2024. Large language models are fewshot summarizers: Multi-intent comment generation via in-context learning. In Proceedings of the 46th International Conference on Software Engineering, pages 39:1–39:13, Lisbon, Portugal. ACM. Xing Hu, Ge Li, Xin Xia, David Lo, and Zhi Jin. 2018. Deep code comment generation. In Proceedings of the 26th International Conference on Program Comprehension, pages 200–210. ACM. Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. SWE-bench: Can language models resolve real-world GitHub issues? In Proceedings of the Twelfth International Conference on Learning Representations. Junaed Younus Khan and Gias Uddin. 2022. Automatic code documentation generation using GPT3. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, Rochester, MI, USA. ACM. Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2020. Retrieval-augmented generation for knowledge-intensive NLP tasks. In Advances in Neural Information Processing Systems 33 (NeurIPS 2020), volume 33, pages 9459–9474. Curran Associates, Inc.
References
Xueguang Ma, Xi Victoria Lin, Barlas Oguz, Jimmy Lin, Wen-tau Yih, and Xilun Chen. 2025. DRAMA: Diverse augmentation from large language models to smaller dense retrievers. arXiv preprint arXiv:2502.18460.
Wasi Uddin Ahmad, Saikat Chakraborty, Baishakhi Ray, and Kai-Wei Chang. 2020. A transformerbased approach for source code summarization. In
Paul W. McBurney and Collin McMillan. 2014. Automatic documentation generation via source code summarization of method context. In Proceedings
of the 22nd International Conference on Program Comprehension, pages 279–290, Hyderabad, India. ACM. Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, and Caiming Xiong. 2023. CodeGen: An open large language model for code with multi-turn program synthesis. In Proceedings of the Eleventh International Conference on Learning Representations. Md Rizwan Parvez, Wasi Ahmad, Saikat Chakraborty, Baishakhi Ray, and Kai-Wei Chang. 2021. Retrieval augmented code generation and summarization. In Findings of the Association for Computational Linguistics: EMNLP 2021, pages 2719–2734, Punta Cana, Dominican Republic. Association for Computational Linguistics. Giriprasad Sridhara, Emily Hill, Divya Muppaneni, Lori Pollock, and K. Vijay-Shanker. 2010. Towards automatically generating summary comments for Java methods. In Proceedings of the 25th IEEE/ACM International Conference on Automated Software Engineering, pages 43–52. ACM. John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-computer interfaces enable automated software engineering. In Advances in Neural Information Processing Systems 37 (NeurIPS 2024), volume 37, pages 50528–50543. Curran Associates, Inc. Xiangyu Zhang, Yu Zhou, Guang Yang, and Taolue Chen. 2023. Syntax-aware retrieval augmented code generation. In Findings of the Association for Computational Linguistics: EMNLP 2023, pages 1291– 1302. Association for Computational Linguistics.