Technical Summary: In Context: Repository-Level Code Generation via Context Inlining

Problem Statement

Repository-level code generation requires Large Language Models (LLMs) to understand entire codebases and reason across complex dependencies between functions, classes, and modules. In contrast to function-level generation, this task demands consistency with the repository's design, coding conventions, and complex inter-functional relationships.

Current approaches face significant limitations:

• Retrieval-Augmented Generation (RAG): Relies on superficial text similarity, often retrieving lexically similar but functionally irrelevant snippets that fail to capture the semantic dependencies governing repository-level semantics.
• Context-Based Selection: Methods that simply prepend retrieved code or use static analyses (e.g., control flow graphs) frequently neglect the specific role of the target function within its actual calling environment. They fail to systematically represent how a function is utilized by its callers (upstream) or how it depends on the functions it calls (downstream), leading to errors in variable binding, return types, and API usage.

Methodology: InlineCoder

The authors propose InlineCoder, a framework that reformulates repository-level generation into a manageable function-level task by inlining the unfinished function into its call graph. The central insight is that a function's behavior is constrained by its upstream callers (usage scenarios) and its implementation depends on its downstream called functions (dependencies).

The framework operates via a three-stage pipeline:

1. Draft Generation (Anchor Creation)

Given a function signature, InlineCoder first generates a preliminary implementation (the "anchor" or "draft").

• Input: A base prompt containing the target signature, a natural language description, and all import statements and directly referenced dependencies from the repository.
• Output: A draft implementation and a list of API calls used within it.
• Purpose: This draft serves two functions: (1) it acts as a seed to identify downstream dependencies (called functions) and (2) it provides a basis for a perplexity-based confidence estimation.

2. Context Inlining (Bidirectional Enrichment)

The draft drives a bidirectional inlining process to construct comprehensive context:

• Upstream Inlining: The system identifies all callers of the target function in the repository. Subsequently, the draft implementation is embedded directly into these caller functions. This involves a four-step transformation:
  1. Parameter Substitution: Mapping caller arguments to the parameters of the called function.
  2. Return Value Normalization: Converting return statements into variable assignments (result = ...) to fit the flow of the caller.
  3. Assignment Redirection: Binding the caller's result to the caller's variables.
  4. Inline Expansion: Replacing the function call in the caller with the transformed draft body.
     Result: This converts distributed call relationships into a linearized, execution-oriented view, revealing input/output constraints and usage patterns.
• Downstream Retrieval: The system extracts function calls from the draft's AST and the functions predicted by the LLM. It performs a substring-based search to find matching function implementations in the repository. These retrieved called functions are integrated into the prompt to provide precise dependency context.

3. Context-Aware Code Generation

The final stage integrates the draft, the upstream-inlined context, and the downstream-retrieved context into a unified prompt.

• Confidence Mechanism: The system calculates the perplexity (PPL) of the initial draft. Based on PPL thresholds, it assigns a confidence level (High, Medium, Low) and generates specific natural language instructions for the LLM:
  • High Confidence: Trust the draft closely.
  • Medium Confidence: Partially modify or improve the draft.
  • Low Confidence: Critically re-evaluate and potentially regenerate from scratch.
• Final Output: The LLM generates the final function body, guided by the enriched prompt containing the target signature, the inlined upstream usage context, downstream dependencies, and confidence-based instructions.

Key Contributions

1. Novel Framework: The proposal of InlineCoder, which locates target functions in both upstream (callers) and downstream (called functions) contexts via a call-graph inlining mechanism.
2. First-Time Inlining: The authors claim to be the first to inline a function directly into the context of its callers, enabling the LLM to delve deeper into the intended purpose and usage patterns than simple retrieval allows.
3. Comprehensive Evaluation: Extensive experiments demonstrating consistent improvements over state-of-the-art baselines across diverse domains and multiple backbone LLMs.

Experimental Results

The framework was evaluated on the DevEval and RepoExec benchmarks using three backbone LLMs: DeepSeek-V3, Qwen3-Coder, and GPT5-mini.

• Performance Gains: InlineCoder performed significantly better than baselines (including In-File, Vanilla, RepoCoder, GraphCoder, and DRACO).
  • On RepoExec, it achieved average relative improvements of 29.73% in Exact Match (EM), 20.82% in Edit Similarity (ES), and 49.34% in BLEU compared to the strongest baseline.
  • On DevEval, it showed consistent improvements with average relative gains of 5.13% in EM, 10.86% in ES, and 10.67% in BLEU.
• Ablation Studies: Removing any single component (upstream inlining, downstream retrieval, draft generation, or confidence guidance) led to performance degradation. The draft implementation was identified as the most critical component.
• Qualitative Analysis:
  • Return Statements: InlineCoder improved the accuracy of return statement generation by 2.07% (EM) over baselines, attributable to better understanding of the upstream context.
  • Function Calls: It improved the accuracy of function call instructions by 4.27% (EM) and demonstrated better resolution of downstream dependencies.
• Domain Generalization: The method proved robust across 10 different software domains (e.g., databases, security, text processing), achieving the best results in EM in 9/10 domains and in ID.F1 in all 10. Performance was slightly lower in the Scientific-Engineering domain, where cross-functional calls are naturally rare.

Significance and Claims

The work claims that InlineCoder addresses the fundamental limitation of existing retrieval strategies by moving beyond superficial similarity to capture the structural and semantic dependencies of a repository. By reformulating the problem via context inlining, the method transforms complex repository-level reasoning tasks into a more manageable function-level task where the model can explicitly see how the code fits into the larger system.

The authors emphasize that their approach does not require extensive fine-tuning; instead, it leverages the reasoning capabilities of existing LLMs through a carefully designed prompting strategy that integrates upstream usage constraints and downstream dependencies. The results underscore the framework's effectiveness in generating code that is not only syntactically correct but also semantically consistent with the repository's design and dependencies.