Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase

AI summary

Overview

Research area: Software engineering for LLM coding agents — specifically multi-application (portfolio) code generation, automated library extraction, and agentic code maintenance. Category: cs.SE.

Technical level: Advanced.

Scope: The paper defines the "Super Library Agent" problem — sequentially generating N related applications while jointly maintaining a shared library of reusable cross-application components — and proposes an agent scaffold (SLA-Full) that improves extraction recall and dependency-migration correctness, evaluated on WebGen-Bench and PaperBench.

What This Paper Is About

Organizations typically maintain portfolios of related applications that share domain logic, interface patterns, and operational conventions, and when LLM coding agents generate each application independently, shared logic gets duplicated across codebases while prolonged agentic maintenance accumulates verbosity, dead code, and structural erosion. The paper formalizes this as the Super Library Agent (SLA) problem: an agent generates applications one at a time, reusing components from a shared "Super Library" and migrating already-built applications to that library as it evolves. The goal is to find a favorable Pareto trade-off between application functionality and the maintainability of the joint codebase (all applications plus the library), which a naive sequential scaffold fails to achieve because of low extraction recall and fragile dependency migration.

Key Contributions

1. Problem formulation. The authors introduce the Super Library Agent problem, in which an agent sequentially generates a portfolio of N related applications while maintaining a shared Super Library whose ideal contents are every component used by at least two implemented applications.

2. Identification of two failure modes. They diagnose low extraction recall (functionally equivalent blocks with little surface similarity are missed) and fragile dependency migration (moves into the library break imports, call sites, and dependencies) as the obstacles that defeat naive library construction.

3. An augmented scaffold. They propose candidate-guided extraction over natural-language code-summary indexes, pre-extraction codebase consolidation, extraction-trace-based bridging between the extraction and migration agents, and call-graph-conditioned migration.

4. Empirical evaluation. Across WebGen-Bench (three disjoint 8-task suites) and PaperBench Code-Dev (five disjoint 4-task suites), SLA-Full preserves functionality while reducing LOC, token length, verbosity, and structural erosion relative to zero-shot, with additional gains in library utilization, abstraction quality, and post-patch maintenance size. Code is released at https://github.com/sbigstar0310/super-library-agent.

Main Findings

• Functionality is preserved, not sacrificed. On WebGen-Bench, SLA-Full reaches 77.21 Accuracy and 3.86 Appearance versus 76.04 and 3.84 for Zero-Shot (+1.5% Accuracy, +0.5% Appearance); on PaperBench it reaches a 0.4809 Code-Dev Score versus 0.4687 for Zero-Shot (+2.6%). Paired t-tests (n=24 for WebGen-Bench, n=20 for PaperBench, 10,000 bootstrap resamples) show no statistically significant difference in any functionality metric between methods.

• Maintainability improves over zero-shot. Relative to Zero-Shot, SLA-Full reduces LOC by 9.0%, token length by 6.7%, MDL by 1.9%, Structural Erosion by 4.4%, and Verbosity by 38.0% on WebGen-Bench; on PaperBench it reduces LOC by 5.0%, token length by 7.4%, MDL by 2.8%, Structural Erosion by 10.4%, and Verbosity by 2.0%.

• Naive SLA and Librarian trade off differently. Both SLA-Naive variants reduce some size metrics but increase Structural Erosion (for example Naive-Implicit reaches 0.1567 on WebGen-Bench versus 0.1032 for Zero-Shot), while Librarian attains the lowest MDL on WebGen-Bench by selecting lowest-MDL candidates among K=8 refactorings but its Erosion rises above zero-shot.

• Ablations isolate each design choice. Natural-language summary-based candidate selection (NL) produces the best scores in four of five maintainability metrics compared with no candidates or Ward clustering, but drops Accuracy to 72.95; removing local consolidation worsens Verbosity, Erosion, and LOC (Accuracy 75.25); removing call-graph conditioning lowers Accuracy to 74.48 and increases Verbosity, Erosion, and LOC.

• Library utilization is broader, not just denser. SLA-Full exposes 13.3 components on average, 5–6 more than the naive variants, with 6.0 exports used by 3–5 applications and 4.8 used by 6–8 applications, compared with 3.3–3.6 and 2.0–2.7 for the naive variants; Librarian averages 4.2 total exports.

• Abstraction quality differs. Highly reused symbols (imported by at least 4 of 8 applications) show SLA-Full capturing more behavioral hooks/utilities and page/domain patterns beyond primitive UI components — for example NavigationBar, Section, useRouter, useFilteredList, FeatureCardGrid, and MessageBanner — whereas naive variants mostly reuse shallow widgets and thin utilities such as Header, Footer, and useLocalStorage.

• Shared policy updates become much cheaper. Under a shared cross-application policy update on WebGen-Bench, SLA-Full requires the smallest patch size at 256 added lines (232 application, 24 library), versus 936 for Zero-Shot, 522 for Librarian, 632 for Naive-Implicit, and 380 for Naive-Ward, while post-patch original-behavior pass rates (77.4), requested-behavior pass rates (80.0), and appearance (3.86) remain comparable to baselines.

• A mature library helps future generation. With extraction, migration, candidate selection, and layout inputs disabled, a vanilla coding agent given SLA-Full's final library improves average accuracy from 80.95 to 84.35 and appearance from 3.83 to 3.92 while reducing application-local LOC from 8,256 to 6,567; the paper reports total LOC decreasing by approximately 11%, with only a marginal MDL change.

Methodology in Plain English

The researchers set up a sequential pipeline. Requests arrive one at a time; a coding agent builds each new application, reusing existing Super Library components where applicable. A library-extraction agent then decides what shared components to add to the library, and a dependency-migration agent patches earlier applications so they use the updated library instead of their local duplicates.

To fix recall, they stop matching code by surface text or embeddings. Instead, they index semantically meaningful code blocks (functions, classes, modules, identified by AST boundaries using cocoindex-code) and write concise natural-language summaries of each block with an LLM (gpt-5.4-nano with medium reasoning effort). A candidate selector (deepseek-v4-flash with high reasoning effort) then proposes explicit extraction candidates — blocks from multiple applications that do the same thing — and migration candidates — library components paired with the local blocks they can replace. Before cross-application selection, each new codebase is consolidated once: duplicated or overlapping local implementations are merged into shared modules inside the application.

To fix migration, the extraction agent writes a structured extraction trace for every new or updated library symbol, recording where it came from, why it generalizes, and how to replace the original code with the library API. That trace is handed to the migration agent so it does not have to rediscover the mapping. Each migration prompt is also conditioned on a call graph "also-refactor" list of relevant imports and caller/callee relationships.

All methods share the same backbone LLM (deepseek-v4-flash) and harness (mini-SWE-agent). Baselines are Zero-Shot (independent codebases), Librarian (post-hoc library construction run K=8 times with lowest-MDL candidate selection among those passing a functionality gate, plus a K=1 variant), and two SLA-Naive variants using implicit discovery and Ward-clustering-based candidate selection. Maintainability is measured with LOC, token length (Qwen-2.5-7B tokenizer), a dependency-aware MDL over Qwen-2.5-7B, Structural Erosion (share of complexity mass in functions with cyclomatic complexity above 10, weighted by complexity and the square root of source lines), and Verbosity (fraction of logical lines covered by duplicated code or rule-flagged redundant patterns).

Why This Matters

The paper reframes code generation as portfolio management rather than single-artifact production, and it supplies concrete evidence that a shared library built online — while applications are still arriving — can both cut duplication and reduce the cost of later cross-application changes. It also provides a rare measurement of post-construction maintenance, where a patch touches many applications at once.

Real-world applications:

• Platform teams with many related services or sites. Teams maintaining sibling codebases with shared domain logic could use the approach to centralize components and propagate a policy change once instead of manually per codebase.
• Agentic development pipelines. Engineering organizations already running coding agents could add library extraction and migration as a maintenance stage rather than accepting agent-induced duplication and slop accumulation.
• Long-lived internal tools. Applications that must be updated repeatedly as requirements drift could benefit from library-as-prior generation, where a mature library improves new applications' accuracy and appearance while shrinking application-local code.
• Retrofit of existing portfolios. The post-hoc baseline (Librarian) shows that library construction can be applied after the fact, but the paper's results indicate recall and migration support matter for whether that refactoring reduces or increases structural erosion.

Industry relevance: the results point to fewer cross-application edits under shared policy updates, which is directly relevant to governance-heavy settings such as policy, compliance, or design-system changes across a fleet of applications. The paper's ethical section also flags the corresponding risk: because one library symbol is imported by many applications, a single faulty automated edit propagates to all of them at once, so applying this to software people depend on would require human review of generated diffs and stronger regression testing than benchmark settings provide.

Future Directions

• SLA-native benchmarks. The authors state that a major limitation is the absence of benchmarks built for this setting; existing single-task benchmarks were adapted, not designed for long-horizon library growth, cross-application reuse, or maintenance. Future benchmarks should include related application streams with enough shared structure for meaningful reuse.
• Multi-round maintenance on real applications. The current maintenance evaluation covers one round on benchmark artifacts with no users, commit history, or production constraints; the authors call for measuring sequences of maintenance rounds, requirement drift, and error compounding.
• Better maintainability measurement. The paper relies on proxy metrics (size, duplication, verbosity, library utilization) that do not fully capture whether a codebase is easier to understand, modify, or extend; suggested additions include cross-application update consistency, regression frequency, and human judgments of abstraction quality.
• Closing the accuracy gap from aggressive extraction. The NL-based candidate selection variant extracts the largest number of shared components but loses accuracy (72.95 vs 76.95 without candidates), and the paper attributes the recovery in SLA-Full to call-graph conditioning — leaving room for selection strategies that maximize reuse without introducing new bugs.
• Cost and scaffold comparison. The paper reports that it evaluates inference cost and two cost-reduction strategies (Appendix C) and compares against recent agentic SE scaffolds (Appendix F), which are natural axes for further study.

Target Audience

Researchers and practitioners working on LLM coding agents, automated refactoring, library learning, and multi-repository software maintenance, plus engineering teams that operate portfolios of related applications and want to know whether agent-generated code can be kept maintainable over time.

Authors’ abstract

Organizations often develop and maintain portfolios of related applications: independently deployable codebases that share substantial domain logic, interface patterns, or operational conventions. As LLM coding agents are increasingly used to generate and maintain such software, a naive application-by-application workflow duplicates shared logic across codebases and allows prolonged agentic maintenance to accumulate verbosity, dead code, and structural erosion. We introduce the Super Library Agent problem, where an agent sequentially generates a portfolio of N related applications while maintaining a shared Super Library of reusable cross-application components. A minimal sequential scaffold can in principle extract shared code and migrate applications to the evolving library, but in practice suffers from low extraction recall and fragile dependency migration. We address these failures with candidate-guided extraction over code chunk summaries, pre-extraction codebase consolidation, and context-aware migration using extraction traces and call-graph information. Across WebGen-Bench and PaperBench, our method preserves application functionality while significantly reducing redundancy and token footprint (verbosity, token length) over zero-shot, and avoiding the structural erosion introduced by naive library construction, with additional reductions in LOC and MDL. Our code is available at https://github.com/sbigstar0310/super-library-agent.