PaperlayerView exact revision on arXiv

Source-linked AI summary

Code2LoRA: Hypernetwork-Generated Adapters for Code Language Models under Software Evolution

Liliana Hotsko, Yinxi Li, Yuntian Deng, Pengyu Nie

arXiv:2606.06492v1cs.SEcs.AIcs.CL

TL;DR

Repository-level code context is costly to provide through long inputs or repository-specific adaptation, especially as codebases evolve. Code2LoRA generates repository-specific LoRA adapters, achieving 63.8% cross-repo exact match on the static track and 60.3% on the evolution track, 5.2 percentage points above a shared LoRA.

  • Problem

    Existing repository-context methods incur long-input or costly per-repository training overhead and can become brittle as codebases evolve.

  • Method

    Code2LoRA uses a hypernetwork to generate repository-specific LoRA adapters from repository context, with static snapshot and GRU-updated evolution variants.

  • Results

    Code2LoRA outperforms baselines across static and evolution tracks; it achieves 63.8% cross-repo exact match statically and 60.3% evolution exact match, +5.2 pp over shared LoRA.

  • Takeaways & Limitations

    Code2LoRA provides repository-conditioned parameter-efficient adaptation without inference-time token overhead for stable and evolving Python codebases.

  • Takeaways & Limitations

    Evaluation is limited to Python repositories, one frozen Qwen2.5-Coder-1.5B backbone, and assertion-completion tasks.

Abstract

from arXiv · show

Code language models need repository-level context to resolve imports, APIs, and project conventions. Existing methods inject this knowledge as long inputs (retrieved through RAG or dependency analysis) or through per-repository fine-tuning and LoRA -- costly at repository scale and brittle to evolving codebases. We introduce Code2LoRA, a hypernetwork framework that generates repository-specific LoRA adapters, effectively injecting repository knowledge with zero inference-time token overhead. Code2LoRA supports two usage scenarios: Code2LoRA-Static converts a single repository snapshot into an adapter, suitable for comprehension of stable codebases; while Code2LoRA-Evo maintains an adapter backed by a GRU hidden state updated per code diff, suitable for active development of evolving codebases. To evaluate Code2LoRA against parameter-efficient fine-tuning baselines, we build RepoPeftBench, a benchmark of 604 Python repositories with two tracks: a static track with 40K training and 12K test assertion-completion tasks, and an evolution track with 215K commit-derived training and 87K commit-derived test tasks. On the static track, Code2LoRA-Static achieves 63.8% cross-repo and 66.2% in-repo exact match, matching the per-repository LoRA upper bound; on the evolution track, Code2LoRA-Evo achieves 60.3% cross-repo exact match (+5.2 pp over a single shared LoRA). Code2LoRA's code can be found at https://anonymous.4open.science/r/code2lora-6857; the model checkpoints and RepoPeftBench datasets can be found at https://huggingface.co/code2lora.

1 Introduction

Code2LoRA generates repository-specific LoRA adapters from repository code, injecting repository knowledge without inference-time token overhead and supporting both static snapshots and evolving codebases. On RepoPeftBench, it matches per-repository LoRA on static tasks and improves over shared LoRA on evolution tasks.

  • 1 Introduction: Code2LoRA generates repository-specific LoRA adapters with zero inference-time token overhead.Its hypernetwork maps repository code into adapter parameters for a frozen code language model.
  • 1 Introduction: Code2LoRA-Static converts one repository snapshot into an adapter, while Code2LoRA-Evo updates an adapter’s GRU hidden state per code diff.The static scenario targets stable codebases; the evolution scenario augments a snapshot prior for active development.
  • 1 Introduction: RepoPeftBench covers 604 Python repositories and includes static and evolution tracks with 39,612 and 215,129 training tasks, respectively.The corresponding test sets contain 11,636 static tasks and 86,793 commit-derived evolution tasks.
  • 1 Introduction: 63.8% cross-repo exact match is achieved by Code2LoRA-Static on the static track, while 66.2% in-repo exact match matches the per-repository LoRA upper bound.The cross-repo result exceeds context-injection methods such as RAG and dependency-resolved context, and the in-repo result requires no per-repository training.
  • 1 Introduction: 60.3% cross-repo exact match is achieved by Code2LoRA-Evo on the evolution track, a +5.2 pp improvement over a shared LoRA.Snapshot-based adaptation becomes stale when evaluation uses commit-derived tasks.

2 Related Work

Prior work adapts models with static parameter-efficient modules, generates LoRA through hypernetworks, studies software evolution, or injects repository context through inputs. Code2LoRA extends hypernetwork-based adaptation to sequential code changes, generating an adapter trajectory over a repository’s lifetime.

  • Parameter-efficient fine-tuning: LoRA and its extensions provide efficient adaptation through low-rank weight updates, but treat adapters as static artifacts trained per task or language.The cited extensions include QLoRA, DoRA, weight merging, multi-LoRA routing, LoRACode, and MoLE.
  • Hypernetworks for LoRA generation: Hypernetworks generate target-network parameters from conditioning signals, with prior language-model applications including HyperTuning, HyperLoRA, and Generative Adapter.Code2LoRA-Static uses this general paradigm for repository-conditioned adapter generation.
  • Hypernetworks for LoRA generation: Code2LoRA-Evo uses a GRU to aggregate sequential code diffs into a hidden state that conditions adapter generation at each commit.This produces an adapter trajectory over a repository’s lifetime, unlike Text2LoRA and Doc2LoRA, which model only a single static input.
  • Software evolution and continual code adaptation: Software-evolution research tracks repository changes commit by commit and file by file, supporting analyses of change impact, bug introduction, and refactoring detection.This line of work provides the broader software-engineering context for modeling repository histories.
  • Repository-level code understanding and generation: Repository-level code understanding commonly injects cross-file information through the input using context training, iterative retrieval, selective retrieval, or joint in-file and cross-file modeling.Examples include RepoFusion, RepoCoder, Repo-Former, and CoCoMIC.

3 Method

Code2LoRA encodes repository context into embeddings, uses a hypernetwork to generate repository-specific LoRA adapters for a frozen code LM, and supports both static snapshots and recurrent updates from code diffs. The method trains these hypernetworks end-to-end on assertion-completion pairs while avoiding inference-time repository tokens.

  • 3.1–3.2: Code2LoRA combines a shared repository encoder, a hypernetwork that generates LoRA weights, and a frozen base LLM receiving the adapter.The generated adapter injects repository knowledge with zero inference-time token overhead.
  • 3.1 Repository Encoder: Repository context is embedded by chunking files into 4096-token segments with 512-token overlap, mean-pooling into 1024-dimensional file vectors, then concatenating weighted-mean and max pools.File importance weights combine content distinctiveness, file size, and path importance, and embeddings are pre-computed during training.
  • 3.2 Static Hypernetwork: Code2LoRA-Static maps one repository embedding to shared LoRA matrices for seven module types through a 2-layer GELU MLP, using rank r=16 and approximately 720M trainable parameters.The matrices are shared across all base-LLM layers and injected through W′ = W + αr BmAm.
  • 3.3 Recurrent Hypernetwork: Code2LoRA-Evo maintains an adapter trajectory by updating a GRU state with chronological diff embeddings, requiring one GRU step per stored diff instead of re-encoding the full repository.The initial state is projected from the initial repository embedding, and the shared head generates each step’s LoRA adapter from the recurrent state.
  • 3.4 Training: The hypernetworks minimize cross-entropy on assertion-completion pairs from the frozen base LM, using u=e for Static and u=zt for Evo with truncated backpropagation through time at K=16.Training samples a repository first and then an input-output pair to expose the hypernetwork to diverse repositories.

4 RepoPeftBench: A Repository-Level PEFT Benchmark

RepoPeftBench is a repository-level PEFT benchmark comprising 604 quality-filtered Python repositories, with static and evolution tracks that evaluate assertion completion using full repository information. Its shared CR/IR partitions distinguish generalization to unseen codebases from adaptation within training repositories.

  • Corpus: 604 Python repositories form the benchmark corpus, split at the 2025-04-01 cutoff into 512 in-distribution and 92 out-of-distribution repositories.Repositories use pytest or unittest, have permissive licenses, and show recent activity.
  • Task: Assertion completion requires predicting an assertion’s expected value from a structured test-file prefix.Inputs include repository-relevant test context up to the assertion cut point, while outputs are comparison right-hand sides or assertion-call final arguments.
  • Task: Full repository information is released so methods can ingest entire codebases rather than retrieval-selected repository slices.This design addresses leakage concerns that make conventional repository-level completion unsuitable without excluding target files from context.
  • Repository splits: 103 repositories are held out entirely in the cross-repo split, while 409 repositories comprise the in-repo split for within-repository training.The CR split contains 51 validation and 52 test repositories; per-repository LoRA is defined only in IR.
  • Evaluation tracks: 62,294 tasks populate the Static track, whereas the Evolution track replays repository commit histories to support streaming adaptation.Both tracks share the task, metrics, and CR/IR partitions; bursty commit histories motivate Code2LoRA-Evo over a frozen snapshot.

5 Experimental Setup

The experiments use Qwen2.5-Coder-1.5B as a shared backbone, with repository encoding from Qwen3-Embedding-0.6B and controlled Code2LoRA training configurations. Evaluation compares against pretrained, retrieval- and dependency-based context methods, parameter-efficient baselines, and three code-completion metrics.

  • Models: Qwen2.5-Coder-1.5B is the bfloat16 backbone shared by all baselines and both Code2LoRA scenarios, while Qwen3-Embedding-0.6B encodes repositories.Both models are released under Apache 2.0.
  • Hyperparameters: Rank-16 adapters use α=32 across seven attention and MLP projection types, with each adapter-factor pair shared across 28 transformer layers.Code2LoRA-Static and Code2LoRA-Evo have ∼720M and ∼745M trainable parameters, respectively, and are trained for 3 epochs with AdamW on one H100 80 GB GPU.
  • Baselines: Baselines include the pretrained model, RAG with k=3, dependency-resolved context, full fine-tuning, a single rank-16 LoRA, and per-repository rank-16 LoRA.Per-repository LoRA is evaluated only on IR splits and serves as an upper bound on repository-level adaptation.
  • Baselines: The strengthened Text2LoRA baseline matches Code2LoRA’s repository encoder, training data, loss, budget, and seven-target-module coverage, differing only in its LoRA-generation head.Its repository representation uses mean+max-pooled Qwen3-Embedding-0.6B, replacing the original natural-language task description.
  • Evaluation metrics: Evaluation reports Exact Match, Edit Similarity, and CodeBLEU, capturing normalized exact completion, SequenceMatcher similarity, and syntax- and data-flow-aware overlap.Exact Match collapses whitespace, removes trailing punctuation, and tolerates model overgeneration.

6 Results

Code2LoRA outperforms context-injection and fine-tuned baselines on both RepoPeftBench tracks, with Code2LoRA-Static leading static evaluation and Code2LoRA-Evo leading commit-derived evaluation. Code2LoRA-Evo also achieves the highest exact-match score on the temporal out-of-distribution holdout.

  • 6.1 Static track: 63.8% EM: Code2LoRA-Static exceeds the strongest static-track baseline, FFT + RAG at 53.9%, by 9.9 pp on CR evaluation.It also surpasses RAG, dependency-resolved context, FFT, Single LoRA, and strengthened Text2LoRA baselines.
  • 6.2 Evolution track: 31.5% Pretrained CR EM on commit-derived tasks, down from 45.7% on the static track, shows that evolution-track evaluation is substantially harder.RAG falls below the pretrained backbone on CR and IR, while dependency-resolved context recovers only to pretrained CR levels.
  • 6.2 Evolution track: 60.3% CR EM and 64.5% IR EM: Code2LoRA-Evo is strongest on both evolution-track splits, gaining 5.2 pp over Single LoRA on CR.It exceeds the 64.2% IR EM Per-repo LoRA upper bound without per-repository training.
  • Overall findings: Parametric adaptation outperforms context injection on both tracks, while recurrent aggregation over commit diffs outperforms static snapshots under repository evolution.Code2LoRA-Evo’s OOD lead over the next-best fine-tuned adapter is approximately 1.8 pp EM and remains positive across EditSim and CodeBLEU.
  • OOD evaluation: 74.1% EM: Code2LoRA-Evo leads the temporal OOD holdout, ahead of Code2LoRA-Static at 72.2%.The OOD repositories were created after the in-distribution training cutoff and used only for held-out evaluation.

7 Conclusion

The paper introduces Code2LoRA, a hypernetwork framework that generates repository-specific LoRA adapters with zero inference-time token overhead, alongside RepoPeftBench for evaluating repository-level PEFT methods. It positions these contributions as building blocks for stronger, customizable, and less costly AI code assistants.

  • Contributions: Code2LoRA generates repository-specific LoRA adapters, injecting repository knowledge without inference-time token overhead.The framework instantiates two usage scenarios based on how knowledge enters parameters and when it is refreshed.
  • Contributions: RepoPeftBench contains 604 Python repositories for evaluating repository-level PEFT methods.
  • Implications: Code2LoRA is envisioned as a building block for stronger, customizable to repository-level context, and less costly AI code assistants.

Limitations … B.3 Construction Pipeline

The paper reports scope, evaluation, model-size, and metric limitations, while documenting RepoPeftBench’s repository-level data sources and structured assertion-task construction. It also states the dataset’s licensing and intended research-use constraints, and discloses limited LLM assistance in writing.

  • Limitations: Evaluation is limited to Python repositories, one Qwen2.5-Coder-1.5B backbone, and assertion completion, with broader languages, backbones, and tasks left for future work.The architecture is described as language- and task-agnostic in principle, but empirical validation remains narrow.
  • Limitations: 74.1% OOD EM may be inflated by shorter assertion targets, so the paper emphasizes the within-OOD comparison, where Code2LoRA-Evo leads the next-best fine-tuned adapter by ∼1.8 pp EM.OOD targets have a 7-character median versus 12–13 characters in CR/IR tests; the confound affects every OOD row.
  • Limitations: Exact match misses functional equivalence; the evaluation partly mitigates this with EditSim, CodeBLEU, and a pytest execution probe, while full semantic execution remains future work.Executing every generated assertion against each project’s test runtime was outside the submission’s compute budget.
  • Limitations: ∼720M and ∼745M trainable parameters make the hypernetwork dominant in Code2LoRA-Static and Code2LoRA-Evo, respectively, with evolution findings most directly supported at the 1.5B scale.Whether recurrent aggregation over commit diffs remains necessary or sufficient for much larger backbones is open.
  • B.2 Repository Selection and Licensing: RepoPeftBench uses public permissively licensed Python repositories and preserves attribution, while released artifacts are intended exclusively for non-commercial research.Commercial or product deployment requires independent relicensing review, and derivatives inherit the same research-use scope.
  • B Dataset Details: RepoPeftBench releases whole repositories, including non-test source files, test files, and first-parent production commits, enabling repository-parameter and streaming-state methods.Existing benchmarks discard most codebase content and Git history at release time.
  • B.3 Construction Pipeline: Each QnA prefix includes imports, an enclosing class when applicable, helper methods, and the test body through the assertion cut point to preserve informative context within the token budget.Test files are identified by standard filename or directory patterns and moved under TEST_HYPERNET/ while preserving relative paths.
  • B.3 Construction Pipeline: The evolution track is motivated by irregular bursts of test-touching commits, which static snapshots cannot capture across active assertion-edit histories.The construction pipeline filters malformed, module-level, empty, duplicate, punctuation-only, and single-character targets.

B.4 Splits Used in Experiments … D.2 Detailed Architecture Diagrams

The supplementary sections specify capped evaluation splits, aligned assertion and token distributions, repository-level reporting, privacy constraints, RAG sensitivity, and implementation details for DRC and architecture diagrams. Together, they document how RepoPeftBench is constructed, analyzed, and used to evaluate repository-aware adaptation.

  • B.4 Splits Used in Experiments: ≤8 QnAs per (repo, commit) are evaluated, yielding an average density of ∼6.8 QnAs per commit after capping.Training additionally applies a ≤4-QnA-per-test-file smart cap for Code2LoRA-Evo.
  • B.5 Composition by Assertion Family and Target Type: Bare assert comprises ∼82–86% of static-track pairs, while target-type fractions differ by at most ∼2 pp across train, CR test, and IR test.The aligned distributions cover numeric/string literals, variables, function calls, and complex expressions.
  • B.6 Token-Length Statistics: 165K tokens is the median repository size, compared with 517 median DRC-context tokens, 224 median prefix tokens, and 3 median target tokens.DRC+prefix inputs have a heavy right tail, motivating the 8K-context setting.
  • B.7 Per-Repository Performance Breakdown: 409 IR-test repositories receive per-repository EM, EditSim, CodeBLEU, and example-count reporting for all evaluated methods.The supplementary materials also summarize aggregate distributions and per-repository-LoRA data sparsity.
  • B.8 Privacy and Content Review: The dataset contains verbatim non-test source and test files from permissively licensed public repositories, excluding private repositories, accounts, commits, issues, and PR discussions.No automated PII scrubbing was performed because identifiers required by the benchmark could be altered.
  • C.1 RAG with Different k: 3 retrieved chunks of 512 tokens is the strongest tested RAG configuration; increasing k to 10 reduces CR EM by 3.4 pp and IR EM by 2.7 pp.At the same retrieval budget, 256-token chunks are uniformly worse than 512-token chunks.
  • D Implementation Details: DRC extracts import-reachable function and class definitions using AST parsing with regex fallback, multi-root module resolution, relative-import handling, and relevance-aware compression.The implementation and experiments use a single H100 80 GB GPU.
  • D.1 Dependency-Resolved Context Construction: 70.3% of CR-test pairs and 64.7% of IR-test pairs have DRC context, which adds 517 median tokens, with mean 1,900 and p95 7,850 tokens.Pairs without resolvable imports use the plain prefix; Figures 4 and 5 provide step-by-step architecture details for both usage scenarios.

D.3 Training Details · D.4 Compute Resources · D.5 Hypernetwork Training Hyperparameters

The training setup freezes the language model and embedder while training repository-conditioned hypernetworks that generate shared LoRA adapters. Static and evolutionary variants use distinct repository representations, sequence handling, and compute requirements.

  • D.3 Training Details: All methods use a Qwen2.5-Coder-1.5B bf16 backbone, AdamW, cosine scheduling, weight decay 0.01, and roughly matched effective compute, differing in training and adapter settings.Code2LoRA-Static uses 8K sequences, while Code2LoRA-Evo uses 4K sequences and truncates backpropagation through time every 16 commits.
  • D.3 Training Details: Code2LoRA-Static stores frozen Qwen3-Embedding-0.6B repository embeddings, aggregated into a 2048-dimensional vector and consumed verbatim during training.Gradients never flow through the embedder.
  • D.3 Training Details: The shared MLP trunk maps repository embeddings to normalized hidden representations, while seven heads generate LoRA factors shared across all 28 transformer layers.The trunk uses two GELU layers with hidden size H=512.
  • D.4 Compute Resources: All experiments ran on one NVIDIA H100 80 GB GPU per job.Reported total GPU hours include approximately 17 hours for Code2LoRA-Static without DRC, 18 hours with DRC, and 24 additional hours for Code2LoRA-Evo.
  • D.5 Hypernetwork Training Hyperparameters: Code2LoRA-Static uses input dimension 2,048, trunk hidden size H=512, LoRA rank r=16, α=32, and seven projection types shared across 28 layers.Its input combines mean and max repository embeddings.
  • D.5 Hypernetwork Training Hyperparameters: Code2LoRA-Evo initializes a 1-layer GRU hidden state from the initial 2,048-dimensional repository embedding and updates it chronologically from encoded production-code diffs.A Linear + LayerNorm projects each diff embedding, and truncated BPTT detaches the hidden state every K=16 steps.
  • D.5 Hypernetwork Training Hyperparameters: The final normalized Evo state feeds a projection head with trunk hidden size 1,024, whose generated LoRAs are shared across all 28 transformer layers.Training gradients flow through the projection head, GRU, and repository-state initializer, while the LLM and embedder remain frozen.
  • D.5 Hypernetwork Training Hyperparameters: Both variants train for 3 epochs with AdamW, cosine scheduling, and weight decay 0.01; Code2LoRA-Static uses LR 1×10−4 and maximum sequence length 8,192.The supplied passage truncates the remaining Evo hyperparameter specification.

E OOD Evaluation Caveats … F.4 Structure of the Generated LoRAs

The paper qualifies its OOD comparison and broadens the analysis across robustness, scaling, temporal trends, and generated-adapter structure. These analyses show repository-data sensitivity, diversity benefits, reduced temporal drift, and noncollapsed repository-specific LoRAs.

  • E OOD Evaluation Caveats: OOD assertion targets have a 7-character median versus 12–13 characters for CR/IR-test, uniformly inflating exact-match credit across OOD rows.Table 4 uses commit-derived prefixes with a median size of ∼7.9 KB, matching Table 3 rather than static Table 2 prefixes of ∼0.9 KB.
  • E OOD Evaluation Caveats: +5.2/+3.2 pp margins over Table 3 remain positive, leaving Code2LoRA-Evo best on every split under matched inputs.The narrower OOD margin is attributed to within-distribution edit patterns observed during training; OOD repositories were created after the scrape cutoff.
  • F Broader Analysis: F Broader Analysis examines per-repository variance, data sparsity, repository-count scaling, commit position, adapter structure, errors, DRC coverage, and efficiency.The supporting analyses are organized across §§F.1–F.8.
  • F.1 Per-Repository Performance and Data Sparsity: 62.5% median and 20.9 standard deviation describe per-repo LoRA EM across 389 repositories, spanning [0, 100]% and falling below the pretrained baseline on 10.5%.Per-repo LoRA scores below the pretrained baseline on 41/389 repositories, with a per-repository median of 30.7% on those cases.
  • F.1 Per-Repository Performance and Data Sparsity: σ=16.8 for Code2LoRA-Static and 15.8 for Code2LoRA-Evo versus 20.9 for per-repo LoRA shows tighter per-repository EM distributions.Code2LoRA-Static transfers knowledge from 409 repositories and 39,612 examples, regularizing generated adapters against sparse-data failures.
  • F.3 Per-Commit Position Trend: Code2LoRA-Evo stays flattest across normalized commit positions, while other methods show steeper downward drift consistent with staleness.Repository timelines are rescaled to 0–100%, with QnAs aggregated into 5%-wide bins using QnA-weighted mean EM.
  • F.4 Structure of the Generated LoRAs: Pairwise cosine similarities among 52 mean-centered CR-test LoRAs span [−1, +1], with mean 0.01 and standard deviation 0.94, ruling out a collapsed mean adapter.The adapters are 659K-dimensional after flattening; t-SNE further shows semantically coherent clustering, while FFT+DRC applies a uniform delta across modules.

F.5 Error Analysis … F.8 Deployment Efficiency

The analysis finds that Code2LoRA-Static errors are concentrated in wrong literals and syntax, while qualitative cases show repository context can be retrieved yet still fail to support value-level reasoning. DRC helps only for resolvable imports, whereas deployment comparisons emphasize token and repository-scaling costs.

  • F.5 Error Analysis: 31.0% of 2,321 incorrect CR-test predictions are wrong literals, while 28.0% are syntax errors, with no single failure mode dominating.Type mismatch, near-miss, and wrong identifier account for 19.0%, 10.8%, and 10.2%, respectively; hallucinations and empty outputs are each under 1%.
  • F.5 Error Analysis: Wrong-literal errors mainly involve runtime-dependent numeric assertions, while near-misses differ from references in trailing punctuation or single tokens.
  • F.6 Qualitative Examples: Code2LoRA-Static recovers repository-specific identifiers and conventions in representative inline-snapshot and ALNS successes that pretrained Qwen2.5-Coder and full fine-tuning miss.
  • F.6 Qualitative Examples: Retrieval can surface the relevant class definition while parametric methods alone complete the value-level reasoning step, exposing a context-quality bottleneck.A commit-derived case likewise reports pretrained, RAG, DRC, and sLoRA failing despite RAG@3 / DRC retrieving the exact determining class definition.
  • F.7 Effect of Dependency-Resolved Context Coverage: 70.3% of CR-test pairs have nonempty DRC, while 29.7% import only standard-library or third-party packages and receive no DRC augmentation.
  • F.7 Effect of Dependency-Resolved Context Coverage: +1.8 pp is DRC’s reported gain over pretrained on CR-test, and the partition tests whether this modest aggregate effect depends on resolvable imports.
  • F.8 Deployment Efficiency: 500–2,000 extra inference tokens are incurred by RAG and DRC, while FFT requires ∼4 h of training and a full 3.1 GB model copy per repository.Code2LoRA-Static and Code2LoRA-Evo are described as requiring zero extra inference tokens; the comparison also flags per-repository training and 32 MB storage as non-scalable costs.

G Discussions

The discussion explains why repository knowledge is best routed through per-repository LoRA parameters, why Static and Evo address stable and evolving codebases, and why Evo benefits from recurrent edit-history aggregation. Qualitative cases further show parametric methods can avoid retrieval-induced generation failures, while both variants add zero inference tokens.

  • Q1. Why parameters over context?: Code2LoRA routes repository-specific symbols into per-repository LoRA parameters, conditioning every layer without inference-time tokens or shared capacity across repositories.The discussion contrasts this with RAG and DRC’s locally noisy token injection and FFT’s average specialization.
  • Q2. Why two usage scenarios rather than one?: Code2LoRA-Static targets one-shot snapshot adaptation, whereas Code2LoRA-Evo incrementally refreshes a shared adapter for active development on evolving codebases.Static uses one forward pass without recurrence or deployment-time commit history; Evo updates a recurrent context vector at each step with amortized constant work.
  • Q3. Where does Code2LoRA-Evo’s edge come from?: +5.2 pp commit-CR EM over single LoRA is Code2LoRA-Evo’s empirical lead, attributed to GRU-based aggregation of sequential diff embeddings before the shared MLP trunk.Evo reuses Static’s LoRA-generation head, adding only GRU recurrence over diff history.
  • Qualitative examples: Only the parametric methods—Code2LoRA variants and Text2LoRA—complete the apscheduler assertion correctly when retrieval context causes Fill-In-the-Middle decoding failure.In this retrieval-degeneracy case, DRC surfaces the literal answer while RAG retrieves the enum pattern without the literal member, yet both fail at generation.
  • Efficiency: Both Code2LoRA variants add zero inference tokens and generate repository-specific adapters in a single forward pass.The efficiency comparison measures extra storage beyond the shared frozen Qwen2.5-Coder-1.5B base model.
Loading 2606.06492v1…