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

Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase Daegyu Sung1* , Yukyeong Lee1* , Geon Park1 , Yumin Choi1 , Sung Ju Hwang1,2† 1

KAIST, 2 DeepAuto.ai

{sbigstar0310, yukyeong, geon.park, yumin.choi, sungju.hwang}@kaist.ac.kr Extract once, Reuse consistently

Abstract

From Scratch

arXiv:2608.29310v1 [cs.SE] 29 Aug 2026

(isolated codebases)

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.

1

Introduction

LLM coding agents can now generate non-trivial applications end-to-end (Qian et al., 2024; Hong et al., 2024; Dong et al., 2024), but real-world software development rarely produces a single application in isolation. Organizations often maintain portfolios of related applications (Clements and *

Equal contribution. † Corresponding author.

𝒙𝟏

Super Library Agent

(shared reusable components) Super Library 𝑳𝒕

codebase 𝒄𝟏 UI

𝒙𝟐

State

Chart

UI

State

Chart

Form

codebase 𝒄𝟐 UI

𝒙𝟑

State

Form

𝒄𝟏

𝒄𝟐

𝒄𝟑

𝒙𝟐

𝒙𝟑

codebase 𝒄𝟑 UI

State

Chart

𝒙𝟏

Low maintainability

High Maintainability

Figure 1: Super Library Agent (SLA) problem. Independent generation duplicates shared logic; SLA maintains a shared library across a sequence of codebases.

Northrop, 2001; Pohl et al., 2005): independently deployable codebases that share domain logic, interface patterns, data-processing routines, or operational conventions. Generating each portfolio member independently duplicates these shared concerns, violating DRY principles (Thomas and Hunt, 2019) and creating an inconsistency surface where every bug fix, design change, or policy update must be manually propagated across near-duplicates. Such duplication is already a well-known maintenance burden in software portfolios (van der Zwaag et al., 2025; Roy and Cordy, 2007; Juergens et al., 2009); LLM-generated portfolios make the problem easier to create at scale. Furthermore, the issue is compounded by the maintenance behavior of LLM coding agents. LLM code generators are known to emit measurable code smells (Siddiq et al., 2022; Liu et al., 2026). SlopCodeBench (Orlanski et al., 2026) shows that prolonged agentic coding can produce slop: code that remains functionally correct while becoming increasingly verbose and structurally convoluted. Generating and maintaining a portfolio of N applications with N isolated coding agents compounds the effect: each agent re-derives shared logic in subtly different forms, accumulates its own dead code, and drifts further from its siblings with ev-

ery maintenance cycle. A method that explicitly factors and re-factors shared concerns across the portfolio is therefore an essential structural defense against agent-induced slop accumulation. Library learning with LLMs originated as a way to amortize reasoning and tool-creation costs across related tasks (Ellis et al., 2021; Bowers et al., 2023; Berlot-Attwell et al., 2026; Stengel-Eskin et al., 2024; Wang et al., 2023; Cai et al., 2024). Recent work, such as Librarian (Kovacic et al., 2025), assumes the input files live inside one logical project, and the authors explicitly leave “large-scale multirepo library creation” as an open problem. We introduce the Super Library Agent problem. Given a sequence of related application requests, an agent must generate each application while maintaining a shared Super Library of components reused across applications. A naive baseline generates each application independently, duplicating shared concerns. A stronger sequential scaffold generates applications one by one, extracts shared components into the Super Library, and migrates affected applications to use the updated library. Although this scaffold captures the intended functionality–maintainability trade-off, it fails in practice for two main reasons. Challenge 1: Extraction Recall. The agent must discover reusable components across an expanding portfolio of codebases. This is difficult because functionally equivalent implementations may differ substantially in syntax and structure (Svajlenko et al., 2014; Saini et al., 2018). Retrieval mechanisms that rely primarily on surface similarity may therefore overlook valid reuse candidates. As the portfolio grows, these missed candidates increasingly limit the coverage and reuse of the Super Library. Challenge 2: Migration Correctness. Extraction is not a local edit. Once a local implementation is moved into the Super Library, applications must update imports, call sites, dependent helper functions, and sometimes surrounding APIs. A naive migration agent may replace the visible local implementation but miss non-local dependency updates, leaving broken references, duplicated implementations, or dead code behind. Thus, reliable Super Library construction requires both discovering reusable abstractions and safely propagating their use through application codebases. We propose an augmented Super Library Agent scaffold that targets these two failures. For ex-

traction recall, we build summarized code indexes and use an LLM-based selector to propose explicit cross-application reuse candidates, rather than relying only on implicit discovery. For migration correctness, we provide the dependency-migration agent with extraction traces and call-graph context, making explicit which local blocks were consolidated, which library components should replace them, and which surrounding call sites or dependencies must be updated. We evaluate our method on WebGen-Bench (Lu et al., 2025) and PaperBench (Starace et al., 2025), reporting accuracy and various code maintainability metrics. Our contributions are: • We formulate the Super Library Agent problem, in which an agent generates a sequence of related applications while maintaining a shared library of reusable cross-application components. • We identify two key obstacles to naive library construction: low extraction recall and fragile dependency migration. We address them with candidate-guided extraction and context-aware migration, respectively. • We evaluate on WebGen-Bench and PaperBench, showing that our method preserves functionality while improving maintainability metrics, library utilization, and abstraction quality over other baselines.

2

Related Work

Maintainable code generation. Recent code generation work increasingly treats maintainability as an explicit objective. MaintainCoder (Wang et al., 2025b) studies changing requirements, while SlopCodeBench (Orlanski et al., 2026), CodeTaste (Thillen et al., 2026), and Agentic Refactoring (Horikawa et al., 2025) show that agents can preserve behavior while accumulating verbosity, duplication, and architectural debt, and often perform only local cleanups. These works mainly study a single evolving codebase. In contrast, SLA targets a portfolio of independently deployable applications whose maintainability depends on the joint codebase: the shared library and all applications that import it. Library learning and post-hoc refactoring. Library learning typically mines abstractions from fixed code corpora, from DreamCoder (Ellis et al., 2021) and Stitch (Bowers et al., 2023) in program synthesis to LILO (Grand et al., 2024)’s LLMassisted interpretable libraries. However, Berlot-

Attwell et al. (2026) shows that LLM librarylearning gains can be confounded by extra inference budget and that learned artifacts are often rarely reused. Kovacic et al. (2025) brings this line closer to software engineering by framing library construction as MDL-minimizing refactoring over existing code snippets. These methods treat library construction as a post-hoc compression or refactoring step over programs that already exist. SLA instead studies an online setting: applications arrive sequentially, the shared library is used when generating each new application, and updated abstractions are migrated back to prior applications. Common-logic extraction and migration. Existing systems extract common logic from completed codebases through corpus-level grouping or explicit refactoring workflows (Meng et al., 2015; Yue et al., 2018; Pomian et al., 2024). RefAgent (Oueslati et al., 2025) decomposes project refactoring into planning, execution, and repair. These systems show that discovery and migration need more structure than direct rewriting, but they do not address online cross-application abstraction: SLA extracts code blocks from natural-language summaries, synthesizes parameterized APIs by turning codebase-specific values into arguments, and records source blocks in an extract map for migration back to affected applications.

3

Methods

3.1

Problem Definition

We introduce the Super Library Agent problem, a novel challenge for coding-specific agentic workflows that jointly generate and maintain N related applications with a shared Super Library. Unlike single-codebase generation, the agent must implement each new application while identifying reusable components across existing codebases and maintaining them through a common library. Let X = (x1 , . . . , xN ) be a sequence of application implementation requests. The agent starts with an empty Super Library L0 = ∅. At each step t, given a new request xt , previous codebases C<t = {c1 , . . . , ct−1 }, and the current library Lt−1 , the agent A produces (ct , C′<t , Lt ) = A(xt , C<t , Lt−1 ), where ct is the new codebase, Lt is the updated Super Library, and C′<t denotes previous codebases patched to use the updated library.

The ideal Super Library contains every component used by at least two implemented applications:  X  t ⋆ Lt = u 1[use(u, ci )] ≥ 2 . i=1

Thus, application-specific components remain local, while shared components are extracted and consistently reused. We consider a sequential portfolio construction setting, where applications arrive one at a time with a single initial request and no subsequent patches. The goal is to seek a favorable Pareto trade-off between the functionality and joint-codebase maintainability of the final applications CN and Super Library LN : max (Sfunc (CN , X), Smaint (CN , LN )) . A

Here, functionality measures whether applications satisfy their requests, while maintainability measures whether shared components are properly extracted, deduplicated, reused, and updated. 3.2

A Minimal Agentic Scaffold

We instantiate Super Library Agent with a minimal sequential scaffold that maps (xt , C<t , Lt−1 ) to (ct , C′<t , Lt ) at each step t using two specialized phases: coding and library maintenance. First, the coding agent generates the new codebase c0t from xt , reusing components from Lt−1 when applicable. Second, a single library agent jointly extracts components shared across the implemented applications into the Super Library, yielding Lt , and migrates previous codebases that contain duplicated local implementations or deprecated library dependencies, yielding ct and C′<t . This minimal scaffold assigns both Super Library construction and cross-codebase dependency migration to a single general-purpose library agent, without dedicated candidate selection or a structured hand-off between the two tasks. We provide the full procedure in Appendix G; our experiments in Section 4 use this scaffold as the SLA-NAIVE comparison baseline. 3.3

Library Extraction and Dependency Migration Strategies

The minimal scaffold in Section 3.2 has two practical limitations: (i) low recall in identifying reusable components across growing codebases, and (ii) the risk of breaking existing applications when migrating them to newly extracted library components.

(b) Ours

(a) Minimal Scaffold Super Lib. 𝑳𝟐 UI State Code 𝒄𝟏

Request 𝒙𝟑

1. CODE

Code 𝒄𝟐

Imports

UI Code 𝒄𝟏

Super Lib. 𝑳𝟑 State Chart Code 𝒄𝟐

Code 𝒄𝒊

Summarize

Chunk 1

Code 𝒄𝟑 Shared

2. EXTRACT & MIGRATE

Index-based Candidate Extraction

Code 𝒄𝟑

𝒔𝟐

Pattern: Renders a search input … Why Extractable: The underlying `useSearchFilter` hook is already shared … Members:

《Search + Category Bar》

NL Sum. 𝒔𝒊 𝒔𝟏

Chunk 1

Chunk 2

Chunk 2

Chunk 3

Chunk 3

Call Graph Condition Apply Candidate Also Refactors Callers & Callees

𝒔𝟑

Code 1-2

Context-Aware Dependency Migration

★

Select Candidates

Explicit Candidate

Migrate Dependency

★ Extract Library

Code 2-1

Code 3-3

Extraction Trace Library Symbol 《useSearchFilter》

Module: src/hooks/useSearchFilter.js Why Generalized: Both tasks implement the same UX pattern: a text search input … Sources: Code 1-2

Code 2-1

Code 3-3

Figure 2: Overview of the proposed workflow. Minimal scaffold SLA-NAIVE (left) vs. SLA-F ULL (right).

To address these limitations, we decompose the single library agent into two specialized agents: a library-extraction agent responsible for updating the shared library and a dependency-migration agent responsible for patching previous codebases. We then equip them with two complementary strategies: (i) index-based candidate extraction and (ii) context-aware dependency migration. See Algorithm 2 for our augmented scaffold. 3.3.1

Index-based Candidate Extraction

Functionally equivalent code blocks often share little surface form, so grouping them by code text or embedding similarity overlooks valid candidates. We therefore summarize each block in natural language and select over these compact code-summary indexes, matching blocks by what they do rather than by how they are written, for both library extraction and dependency migration. Code Block Indexing. We maintain an up-todate code-summary index for every application codebase and the Super Library. Each entry records the location of a semantically meaningful code block and its concise natural-language summary. We identify code blocks using abstract syntax tree (AST) boundaries, such as functions, classes, and modules,1 and generate their summaries with an LLM.2 LLM-Based Candidate Selection. A dedicated candidate selector uses these indexes for two matching tasks.3 The library-extraction agent receives extraction candidates, code blocks from multiple applications that implement shared functionality. We use cocoindex-code. https://github.com/ cocoindex-io/cocoindex-code 2 gpt-5.4-nano with medium reasoning effort is used. 3 The candidate selector uses deepseek-v4-flash with high reasoning effort. 1

The dependency-migration agent receives migration candidates, library components paired with the application-local blocks they can replace. Detailed prompts and example outputs are provided in Appendix H.3. Pre-Extraction Codebase Consolidation. Before cross-application candidate selection, we perform a one-time consolidation of each newly generated codebase. Using the same index-based selection procedure, the agent identifies duplicated or overlapping local implementations and refactors them into shared modules within the application. The consolidated codebase is then indexed for Super Library extraction. 3.3.2

Context-Aware Dependency Migration

Dependency migration is challenging because extraction and migration are performed by separate agents, and because replacing a local implementation requires coordinated updates to its import declarations and call sites. To address these challenges, we use extraction traces to bridge the two agents and call-graph context to guide dependent edits. Extraction-Trace-Based Bridging. After each library extraction, the library-extraction agent creates a structured extraction trace for every new or updated Super Library symbol. Each trace records where the symbol came from, why the pattern generalizes across applications, and how to replace the original code with the library API. Passing this trace to the dependency-migration agent bridges the two phases without requiring it to rediscover the correspondence from scratch. Appendix H.4 provides an example. Call Graph Conditioning. For each migration candidate, we attach an also-refactor list to the mi-

gration prompt containing the relevant import declarations and local caller/callee relationships (Ryder, 1979). This context directs the agent to update dependent call sites and imports while removing obsolete local implementations, reducing broken references, duplication, and dead code (Eder et al., 2012).

4

Experiments

4.1

Experimental Setup

4.1.1

Non-SLA baselines. Z ERO -S HOT generates each codebase independently, without a shared library or cross-codebase memory. L IBRARIAN (Kovacic et al., 2025) applies post-hoc library construction to the completed Zero-Shot codebases. It runs library construction K=8 times and selects the lowest-MDL candidate among those passing the functionality gate.

Benchmarks

We evaluate our method on two coding domains: WebGen-Bench and PaperBench. To adapt existing single-task coding benchmarks to the Super Library Agent setting, we sample disjoint task sequences of length N and treat each sequence as an evaluation suite. Given a suite X = (x1 , . . . , xN ), the agent sequentially implements each task while maintaining a shared Super Library across the generated applications. WebGen-Bench. WebGen-Bench (Lu et al., 2025) evaluates website generation from naturallanguage instructions using executable functionality tests and visual-quality judgments. We construct three disjoint 8-task suites. Because web applications share UI components, layout primitives, styling patterns, and interaction logic, this domain provides natural reuse opportunities. To reduce variance from underspecified visual design, we augment all methods’ inputs with the same layout descriptions generated from rendered reference pages; all the details are in Appendix A.2. PaperBench. PaperBench (Starace et al., 2025) evaluates whether coding agents can reproduce AI research contributions from ICML 2024 Spotlight and Oral papers. We use the Code-Dev variant and construct five disjoint 4-task suites. Research implementations share abstractions such as training loops, data pipelines, model wrappers, and evaluation utilities, providing a distinct domain for evaluating library reuse. Suite details are provided in Appendix A.3.2. 4.1.2

library construction or perform it only after all applications are complete.

Compared Methods

All methods use the same backbone LLM, deepseek-v4-flash (DeepSeek-AI, 2026), and the mini-SWE-agent harness (Yang et al., 2024). We distinguish SLA methods, which update the Super Library and migrate dependent applications as requests arrive, from baselines that either omit

SLA methods. SLA-NAIVE uses the minimal scaffold introduced in Section 3.2. We evaluate two variants using implicit candidate discovery and Ward-clustering-based candidate selection. SLA-F ULL augments SLA-Naive with indexbased candidate extraction, pre-extraction codebase consolidation, extraction traces, and call graphconditioned migration. 4.2 4.2.1

Evaluation Metrics Application Functionality

WebGen-Bench. We use the two applicationlevel metrics from WebGen-Bench (Lu et al., 2025). Accuracy (↑) is the weighted pass rate over executable tests, assigning full credit to fully completed cases and half credit to partially completed ones; test operations are executed by a webnavigation UI agent (He et al., 2024).4 Appearance Score (↑) is a 0–5 LLM judge score (Zheng et al., 2023) on the rendered entry page, measuring visual quality.5 PaperBench. We report the Code-Dev Score (↑) (Starace et al., 2025), a normalized 0–1 LLMjudge score that checks the generated implementation against paper-specific rubric items.6 4.2.2

Code Maintainability

We evaluate maintainability over the final generated codebase, including all applications and the shared library, using five metrics. Lines of Code (LOC, ↓). LOC is the total number of non-empty source lines across all generated applications and the shared library. 4 The navigation agent is driven by gpt-5-mini with high reasoning effort. 5 gpt-5-mini with default reasoning effort is used. 6 deepseek-v4-flash with high reasoning effort is used as main evaluator, and gpt-5-mini with default reasoning effort is used as evaluation report parser.

Token Length (Tok, ↓). Token Length measures the total number of tokens in all generated applications and the shared library.7 Minimum Description Length (MDL, ↓). MDL (Kovacic et al., 2025) measures the negative log probability of the generated code under a reference model pθ . We use Qwen-2.5-7B (Team, 2024) and adapt the original file-independent formulation to our setting with a dependency-aware variant: MDL(C) = − log pθ (L) −

N X X

log pθ f | deps(f ) .

i=1 f ∈ci

where C consists of codebases c1 , . . . , cN and the shared library L, and deps(f ) denotes the direct imports of file f . Structural Erosion (↓). Structural Erosion (Orlanski et al., 2026) measures the share of complexity mass in functions with cyclomatic complexity above 10, weighting each function by its complexity (McCabe, 1976) and the square root of its source lines of code. Verbosity (↓). Verbosity (Orlanski et al., 2026) is the fraction of logical lines of code covered by duplicated code or rule-flagged redundant patterns. 4.3

Initial Portfolio Construction

Further Evaluation. Paired t-tests show significant improvements in several maintainability metrics, while functionality differences are not statistically significant (Appendix A.1). We further report inference cost and evaluate two cost-reduction strategies (Appendix C) and compare against recent agentic SE scaffolds (Appendix F). 4.4

Post-Construction Maintenance

Our primary evaluation measures the functionality and structural maintainability of portfolios after initial construction. Existing benchmarks provide no shared follow-up changes for related applications. We therefore take each final portfolio from Section 4.3, consisting of the completed application codebases with or without a Super Library, and apply a shared policy update as an issue patch. Shared policy updates. For each WebGenBench suite, we construct one cross-application policy update targeting behavior shared by multiple task specifications. A separate agent authors the update using only the original instructions and layout descriptions, without access to any generated portfolio or library.8 We instantiate the suite-level policy as application-specific issue-patch instructions and corresponding WebVoyager test cases for the target applications. Appendix B provides the policy construction and evaluation details.

WebGen-Bench. Table 1 (top) shows that all methods achieve comparable functionality, indicating that library use does not harm task performance. SLA-F ULL obtains the best scores on LOC, token length, Erosion, and Verbosity, with statistically significant reductions in LOC, token length, and verbosity relative to zero-shot. L IBRARIAN attains the lowest MDL by selecting the lowest-MDL candidate among K sampled refactorings, but its Erosion rises above zero-shot rather than falling. In contrast, both SLA-NAIVE variants reduce some size metrics but increase Erosion, suggesting that unguided library extraction can concentrate complexity into shared components.

Evaluation protocol. We apply the same issue patch to every method using the same edit agent.9 For methods with a shared library, a single agent jointly updates the library and all target applications. To preserve the independent-codebase setting, Zero-Shot assigns a separate agent to each application and disallows shared-library construction and cross-application imports. We measure Patch Size (Added LOC, ↓) from the resulting Git diff and report it separately for application and library code. We also evaluate whether the patched applications preserve their original behavior, satisfy the requested behavior, and maintain their visual quality.

PaperBench. Table 1 (bottom) shows that SLAF ULL achieves the lowest values on all five maintainability metrics while retaining a comparable Code-Dev Score. In contrast, L IBRARIAN’s posthoc MDL selection improves neither MDL nor functionality over Zero-Shot.

Results. Table 2 shows that SLA-F ULL achieves the smallest Patch Size overall and across all three suites. By centralizing shared changes in the Super Library, it substantially reduces application-level edits. This realizes the maintainability benefit that motivated our formulation of the Super Library

Tokens are counted with the Qwen-2.5-7B (Team, 2024) tokenizer. 7

8 9

We use claude-opus-4.8 with high reasoning effort. We use deepseek-v4-flash with high reasoning effort.

Functionality

Maintainability

Library Size

Method

Acc. ↑

Appr. ↑

LOC ↓

Tok ↓

MDL ↓

Eros. ↓

Verb. ↓

LOC

MDL

WebGen-Bench Zero-Shot L IBRARIAN (K=1) L IBRARIAN (K=8)

76.04 75.09 75.78

3.84 3.90 3.89

9393 9202 8973

70364 69492 68159

34875 34566 33919

0.1032 0.1266 0.1352

0.1603 0.1558 0.1472

– 184 222

– 576 639

NAIVE -I MPLICIT NAIVE -WARD SLA-F ULL ∆ vs. Zero-Shot (%)

76.95 76.07 77.21 +1.5

3.89 3.90 3.86 +0.5

9133 8786 8552 −9.0

69777 67774 65633 −6.7

35103 34675 34195 −1.9

0.1567 0.1250 0.0987 −4.4

0.1408 0.1370 0.0994 −38.0

447 433 574 –

1212 1175 1630 –

PaperBench Zero-Shot L IBRARIAN (K=1) L IBRARIAN (K=8)

0.4687 0.4741 0.4591

– – –

6578 6608 6551

68603 68859 68297

30342 30643 30400

0.2558 0.2534 0.2527

0.8665 0.8628 0.8628

– 124 98

– 482 397

NAIVE -I MPLICIT NAIVE -WARD SLA-F ULL ∆ vs. Zero-Shot (%)

0.4802 0.4720 0.4809 +2.6

– – – –

6445 6440 6252 −5.0

66539 66028 63514 −7.4

29850 29568 29489 −2.8

0.2882 0.2761 0.2291 −10.4

0.8582 0.8645 0.8490 −2.0

212 295 336 –

765 1027 1203 –

Table 1: Initial portfolio construction results. Results are averaged over three 8-task WebGen-Bench suites and five 4-task PaperBench suites, each with three trials. PaperBench Acc. denotes the rubric-based Code-Dev Score, and appearance is not applicable. Maintainability metrics cover the complete portfolio, while Library Size covers only the Super Library. L IBRARIAN K=1 omits best-of-K selection.

Patch Size

Functionality

Method

Total ↓ App ↓ Lib Orig. ↑ Req. ↑ Appr. ↑

Zero-Shot L IBRARIAN

936 522

936 500

0 22

77.9 74.0

81.9 76.9

3.93 3.83

NAIVE -I MPLICIT NAIVE -WARD SLA-F ULL

632 380 256

618 363 232

14 18 24

76.9 77.7 77.4

82.9 81.1 80.0

3.82 3.95 3.86

Table 2: Maintenance under shared policy updates. Results are averaged over three WebGen-Bench suites and three trials. Patch Size counts source lines added by the patch. Orig. and Req. report post-patch pass rates on the original and requested behaviors. Appr. denotes appearance quality.

Agent problem. The patched applications retain functionality and visual quality comparable to the baselines.

5

Candidate selection for library update. In Table 3a, we compare three ways of providing reuse candidates to the library-extraction agent in the SLA-NAIVE setting: no explicit candidates, Ward cluster-based candidates, and our index-based candidate selection. We observe that our natural language (NL) summary-based approach gives the best scores in four out of five maintainability metrics. This is due to the NL-based approach extracting the largest number of shared components, as seen by the library size. The accuracy degrades in NL due to the additional shared component extraction introducing opportunities for the agent to introduce new bugs. We address this inaccuracy by using call graph conditioning in our SLA-F ULL approach.

Analysis

Beyond the aggregate results in Section 4, we analyze how SLA-F ULL improves reuse and maintainability over sequential application generation. 5.1

tion of each design choice.

Ablation Study

In Table 3, we compare different candidate selection methods on SLA-NAIVE, and ablate the major components of SLA-F ULL to isolate the contribu-

Pre-extraction codebase consolidation. We remove the pre-extraction codebase consolidation (Section 3.3.1) to test whether reducing intracodebase redundancy before library extraction improves the quality of Super Library candidates. This isolates the effect of filtering duplicated or overly local implementations before they are considered for cross-application extraction. We observe that without local consolidation, the library

Functionality

Maintainability

Metric w/o LC w/o CG SLA-Full

Library Size

Acc. ↑ 75.25 74.48 Verb. ↓ 0.1264 0.1215 Eros. ↓ 0.1263 0.1409 LOC ↓ 8733 9068 MDL ↓ 33880 34166

Selec. Acc. ↑ Appr. ↑ LOC ↓ Tok ↓ MDL ↓ Eros. ↓ Verb. ↓ LOC Tok MDL 76.95 76.07 72.95

None Ward NL

3.89 3.90 3.89

9133 69777 35103 0.1567 0.1408 447 3173 1212 8786 67774 34675 0.1250 0.1370 433 3090 1175 8583 66727 32893 0.1122 0.1376 815 5944 2057

77.21 0.0994 0.0987 8552 34195

(a) Candidate selection for SLA-NAIVE: None, embedding-based Ward clustering, and (b) LC: Local consolidation, CG: natural-language code-block summary matching (NL). Call graph conditioning.

(a) SLA-naive 0

0

0

−200

−200

−200

Avg. # highly reused symbols

Relative LOC

Relative LOC

Table 3: Ablations on WebGen-Bench. We report the mean values over three suites × three trials. Maintainability metrics are computed over the final portfolio including the shared library.

0

0

−200

−200

−200

LOC

0

2 3 Round

4

3.3

1 0

Page/domain patterns

3.4

3.0 2.0

1.4

1.0 0.4 0.3

Librarian

0.4

0.9 0.2

Naive (Implicit) Naive (Ward)

Full

(a) Average number of symbols by category. 500

1

3.2

2

(c) Super-Library 500

Behavioral hooks/utils

3

(b) SLA-full 0

Primitive UI

0

500 1

2 3 Round

SLA-naive

4

0

Method

1

2 3 Round

4

SLA-full

Figure 3: LOC dynamics across sequential rounds. Columns are WebGen suites 1–3. In (a) and (b), each colored line is one application. Values are relative to each app’s first round; shaded area shows ±1 std over three trials.

agent fails to abstract shared components within a single codebase, since it is designed to extract shared components across multiple codebases. In Table 3b, this is reflected in the higher Verbosity, Erosion, and LOC metrics compared to SLAF ULL. The MDL metric fails to capture this, which is possibly caused by the quality of the training data of the LLM used for evaluating MDL. Call Graph Conditioning. We ablate the migration context by removing call-graph (CG) conditioning, in order to test whether structural caller/callee context is necessary for reliably replacing local implementations with Super Library calls. In Table 3b, the accuracy of the no-CG variant is lower, which is due to the dependency-migration agent failing to properly handle the structural dependency updates. Also, without CG, the migration agent often leaves dead code after replacing the local implementation with a Super Library call, which is reflected in higher Verbosity, Erosion, and LOC.

Primitive UI

Behavioral hooks/utils Page/domain patterns

L IBRARIAN

Footer Header

useLocalStorage saveToStorage

ContactForm LoginForm

N AIVE -I MPLICIT

Header Footer

useLocalStorage useFormValidation

ContactForm KpiCard

N AIVE -WARD

Header Card

useLocalStorage createAuthContext

ContactForm

SLA-F ULL

NavigationBar Section

useRouter useFilteredList

FeatureCardGrid MessageBanner

(b) Representative symbols (up to two examples per category; full per-run export inventories in Appendix I).

Figure 4: Categories of highly reused Super Library symbols (imported by ≥ 4 of 8 apps). SLA-F ULL captures more behavioral and page/domain abstractions beyond primitives.

5.2 Maintainability Dynamics Across Rounds We track each application’s LOC after the last phase of each round. This shows when reuse is accumulated, rather than only comparing final scores. In Figure 3, SLA-F ULL tends to reduce app-local code as more applications are added to the stream. In contrast, the naive scaffold shows flatter trajectories, suggesting that a shared library alone is insufficient without reliable candidate discovery and migration.

5.3

Library Utilization and Abstraction

We analyze whether the final Super Library is both reused and meaningfully abstracted.

No. of Apps Total 1–2 3–5 6–8 Exports

Metric

Method L IBRARIAN N AIVE -I MPLICIT N AIVE -WARD SLA-F ULL

1.2 1.3 1.4 2.2

UI acc. (%) ↑ Appear. (0–5) ↑

80.95 3.83

LOC ↓ MDL ↓

8,256 29,291

1.6 3.6 3.3 6.0

1.0 2.7 2.0 4.8

5.3.1

Library Utilization

In Table 4, we measure library utilization by counting how many exported Super Library components are reused by different numbers of applications. The Exports column reports all exported library components, while the remaining columns group those exports by the number of generated applications that import them: 1–2, 3–5, and 6–8 apps. The result shows that our SLA-F ULL builds a larger reusable library rather than merely increasing reuse density over a small set of components. SLA-F ULL exposes 13.3 components, 5–6 more than the naive variants on average. SLA-F ULL also increases the number of broadly reused exports, with 6.0 exports used by 3–5 apps and 4.8 exports used by 6–8 apps, compared to 3.3–3.6 and 2.0–2.7 for the naive variants. 5.3.2

Abstraction Quality

We analyze what types of abstractions are captured by highly reused Super Library symbols, defined as symbols imported by at least four of eight applications in a run. We categorize them into primitive UI components, behavioral hooks/utilities, and pageor domain-level patterns. Figure 4a shows that, apart from L IBRARIAN, all methods extract comparable numbers of primitive UI components, but SLA-F ULL captures substantially more reusable symbols beyond primitives, including behavioral hooks/utilities and page/domain patterns. Figure 4b provides representative examples, showing that the naive variants mostly reuse shallow widgets or thin utilities, whereas SLA-F ULL additionally extracts interaction/statemanagement hooks and composed page/domain components. This suggests summary-guided extraction broadens the library’s semantic coverage rather than merely raising primitive counts. Per-suite and pertrial export inventories are in Appendix I.

w/ library App

4.2 8.2 7.2 13.3

Table 4: Super Library utilization, averaged over three suites × three trials.

w/o library

Lib

84.35 3.92 6,567 27,442

∆

750 1,985

+3.40 +0.09 −940 +135

Table 5: Library-as-prior ablation. 8 tasks × 3 trials. ∆ on total (App + Lib).

5.4

Mature Libraries Enable Richer Application Generation

We test whether a Super Library can also serve as a prior for application generation. In this taskinformed ablation, a vanilla coding agent generates eight Content-Presentation applications with or without access to SLA-F ULL’s final library, while extraction, migration, candidate selection, and detailed layout inputs are disabled. Table 5 shows that library access improves average accuracy from 80.95 to 84.35 and appearance while reducing application-local code. Even after including the library itself, total LOC decreases by approximately 11%, with only a marginal change in MDL. Figure 7 shows the per-task comparisons.

6

Conclusion

As LLM coding agents build portfolios of related applications at scale, independent generation duplicates shared logic and prolonged agentic maintenance accumulates slop. We formulate this as the Super Library Agent problem, in which an agent develops related applications while maintaining a shared library of reusable components. SLA addresses missed abstractions and incomplete migration through candidate-guided extraction and context-aware dependency migration. Across WebGen-Bench and PaperBench, SLA preserves functionality while improving maintainability, library utilization, and abstraction quality. Postpatch results further show fewer cross-application edits, pointing toward more sustainable LLM coding for larger, evolving codebases.

Limitations Lack of SLA-native benchmarks. A major limitation of this work is the absence of benchmarks specifically designed for the Super Library Agent setting. We adapt existing single-task coding benchmarks into sequential suites, but they were not originally built to evaluate long-horizon library growth, cross-application reuse, or codebase maintenance. Section 4.4 measures one round of postdeployment maintenance, but two gaps remain: the applications being maintained are themselves benchmark artifacts, generated from task specifications with no users, commit history, or production constraints, so it is untested whether the reduction in patch size survives on real applications; and we measure a single round rather than a sequence, so we do not observe how the shared library holds up as requirements keep drifting or how errors compound across rounds. Future benchmarks should include related application streams with enough shared structure for meaningful reuse, while also testing how the shared library supports evolving maintenance requests. Limitations of maintainability metrics. Our maintainability evaluation relies on proxy metrics such as code size, duplication, verbosity, and library utilization. These metrics capture useful signals about abstraction and reuse, but they do not fully measure whether a codebase is easier to understand, modify, or extend. Moreover, maintainability is ultimately revealed through repeated future changes, whereas our evaluation combines static properties of the final codebases with a single maintenance round. Future work should extend this to multi-round maintenance on real applications, cross-application update consistency, regression frequency, and human judgments of abstraction quality.

Ethical Considerations Automated code modification. Our system edits code without a human in the loop: it rewrites existing applications to import from a shared library, and it applies a maintenance patch across a whole portfolio in a single pass. A migration that passes our functional checks can still alter behavior those checks do not cover, and because one library symbol is imported by many applications, a single faulty edit propagates to all of them at once. This concentration is the same property that makes the

shared library useful for maintenance, so it cannot be separated from the method. Applying this to software that people depend on would require human review of the generated diffs and stronger regression testing than a benchmark setting provides. Released artifacts. The application codebases and Super Libraries we release are generated from benchmark task specifications and are intended as evidence for the claims in this paper, not as deployable software; they have not been reviewed for security, accessibility, or data-handling practices. The backbone models we use are trained on public code, so generated components may resemble existing implementations, and downstream users should verify licensing before reuse. Our experiments use only public coding benchmarks and involve no human subjects or personal data (Appendix J).

Acknowledgements This work was supported by Institute for Information & communications Technology Planning & Evaluation (IITP) grant funded by the Korea government (MSIT) (RS-2019-II190075, Artificial Intelligence Graduate School Program (KAIST)), National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIT) (No. RS2023-00256259), the Institute of Information & Communications Technology Planning & Evaluation (IITP) with a grant funded by the Ministry of Science and ICT (MSIT) of the Republic of Korea in connection with the Global AI Frontier Lab International Collaborative Research (No. RS-202400469482 & RS-2024-00509279), Institute of Information & communications Technology Planning & Evaluation (IITP) grant funded by the Korea government (MSIT) (No. RS-2022-II220713, Metalearning Applicable to Real-world Problems), and the “Advanced GPU Utilization Support Program” funded by the Government of the Republic of Korea (Ministry of Science and ICT).

References Ian Berlot-Attwell, Tobias Sesterhenn, Frank Rudzicz, and Xujie Si. 2026. Is this LLM library learning? evaluation must account for compute and behaviour. In Proceedings of EACL 2026. Matthew Bowers, Theo X. Olausson, Catherine Wong, Gabriel Grand, Joshua B. Tenenbaum, Kevin Ellis, and Armando Solar-Lezama. 2023. Top-down syn-

thesis for library learning. Proceedings of the ACM on Programming Languages, 7(POPL). Tianle Cai, Xuezhi Wang, Tengyu Ma, Xinyun Chen, and Denny Zhou. 2024. Large language models as tool makers. In The Twelfth International Conference on Learning Representations. Paul Clements and Linda Northrop. 2001. Software Product Lines: Practices and Patterns. AddisonWesley Professional. DeepSeek-AI. 2026. Deepseek-v4: Towards highly efficient million-token context intelligence. Yihong Dong, Xue Jiang, Zhi Jin, and Ge Li. 2024. Self-collaboration code generation via chatgpt. ACM Trans. Softw. Eng. Methodol., 33(7). Sebastian Eder, Maximilian Junker, Elmar Jürgens, Benedikt Hauptmann, Rudolf Vaas, and Karl-Heinz Prommer. 2012. How much does unused code matter for maintenance? In 2012 34th International Conference on Software Engineering (ICSE), pages 1102–1111. Kevin Ellis, Catherine Wong, Maxwell Nye, Mathias Sablé-Meyer, Lucas Morales, Luke Hewitt, Luc Cary, Armando Solar-Lezama, and Joshua B. Tenenbaum. 2021. DreamCoder: Bootstrapping inductive program synthesis with wake-sleep library learning. In Proceedings of the 42nd ACM SIGPLAN International Conference on Programming Language Design and Implementation. Gabriel Grand, Lionel Wong, Maddy Bowers, Theo X. Olausson, Muxin Liu, Joshua B. Tenenbaum, and Jacob Andreas. 2024. LILO: Learning interpretable libraries by compressing and documenting code. In The Twelfth International Conference on Learning Representations. Hongliang He, Wenlin Yao, Kaixin Ma, Wenhao Yu, Yong Dai, Hongming Zhang, Zhenzhong Lan, and Dong Yu. 2024. WebVoyager: Building an end-toend web agent with large multimodal models. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 6864–6890. Association for Computational Linguistics. Sirui Hong, Mingchen Zhuge, Jiaqi Chen, Xiawu Zheng, Yuheng Cheng, Ceyao Zhang, Jinlin Wang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. 2024. Metagpt: Meta programming for a multi-agent collaborative framework. Preprint, arXiv:2308.00352. Kosei Horikawa, Hao Li, Yutaro Kashiwa, Bram Adams, Hajimu Iida, and Ahmed E. Hassan. 2025. Agentic refactoring: An empirical study of AI coding agents. Preprint, arXiv:2511.04824.

Elmar Juergens, Florian Deissenboeck, Benjamin Hummel, and Stefan Wagner. 2009. Do code clones matter? In 2009 IEEE 31st International Conference on Software Engineering, pages 485–495. Ziga Kovacic, Justin T. Chiu, Celine Lee, Wenting Zhao, and Kevin Ellis. 2025. Refactoring Codebases through Library Design. arXiv preprint arXiv:2506.11058v1. Version 1. Xunhao Lai, Weiqi Xu, Yufeng Yang, Yuxuan Zhang, Zehan Zhu, Chengyue Chen, Ziyi Wang, Yuchen Zhou, Hao Li, Zhenhua Xie, Yifan Wu, Jian Chen, Yu Zhao, Peng Sun, Xin Liu, Jie Zheng, and Bo Wang. 2026. MiniMax sparse attention. arXiv preprint arXiv:2606.13392. Yue Liu, Ratnadira Widyasari, Yanjie Zhao, Ivana Clairine Irsan, Junkai Chen, and David Lo. 2026. Debt behind the ai boom: A large-scale empirical study of ai-generated code in the wild. Preprint, arXiv:2603.28592. Zimu Lu, Yunqiao Yang, Houxing Ren, Haotian Hou, Han Xiao, Ke Wang, Weikang Shi, Aojun Zhou, Mingjie Zhan, and Hongsheng Li. 2025. Webgenbench: Evaluating LLMs on generating interactive and functional websites from scratch. In The Thirtyninth Annual Conference on Neural Information Processing Systems Datasets and Benchmarks Track. Thomas J McCabe. 1976. A complexity measure. IEEE Transactions on software Engineering, (4):308–320. Na Meng, Lisa Hua, Miryung Kim, and Kathryn S. McKinley. 2015. Does automated refactoring obviate systematic editing? In 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, volume 1, pages 392–402. Gabriel Orlanski, Devjeet Roy, Alexander Yun, Changho Shin, Alex Gu, Albert Ge, Dyah Adila, Nicholas Roberts, Frederic Sala, and Aws Albarghouthi. 2026. Slopcodebench: Benchmarking how coding agents degrade over long-horizon iterative tasks. Khouloud Oueslati, Maxime Lamothe, and Foutse Khomh. 2025. RefAgent: A multi-agent LLMbased framework for automatic software refactoring. Preprint, arXiv:2511.03153. Klaus Pohl, Günter Böckle, and Frank Van Der Linden. 2005. Software product line engineering: foundations, principles, and techniques, volume 1. Springer. Dorin Pomian, Abhiram Bellur, Malinda Dilhara, Zarina Kurbatova, Egor Bogomolov, Andrey Sokolov, Timofey Bryksin, and Danny Dig. 2024. Em-assist: Safe automated extractmethod refactoring with llms. In Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering, FSE 2024, pages 582–586, New York, NY, USA. Association for Computing Machinery.

Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, Juyuan Xu, Dahai Li, Zhiyuan Liu, and Maosong Sun. 2024. Chatdev: Communicative agents for software development. Preprint, arXiv:2307.07924. Chanchal Kumar Roy and James R. Cordy. 2007. A survey on software clone detection research. Technical Report 2007-541, School of Computing, Queen’s University at Kingston, Kingston, Ontario, Canada. B.G. Ryder. 1979. Constructing the call graph of a program. IEEE Transactions on Software Engineering, SE-5(3):216–226. Vaibhav Saini, Farima Farmahinifarahani, Yadong Lu, Pierre Baldi, and Cristina V. Lopes. 2018. Oreo: detection of clones in the twilight zone. In Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE ’18, pages 354–365. ACM. Mohammed Latif Siddiq, Shafayat H Majumder, Maisha R Mim, Sourov Jajodia, and Joanna CS Santos. 2022. An empirical study of code smells in transformer-based code generation techniques. In 2022 IEEE 22nd International Working Conference on Source Code Analysis and Manipulation (SCAM), pages 71–82. IEEE. Giulio Starace, Oliver Jaffe, Dane Sherburn, James Aung, Jun Shern Chan, Leon Maksin, Rachel Dias, Evan Mays, Benjamin Kinsella, Wyatt Thompson, Johannes Heidecke, Amelia Glaese, and Tejal Patwardhan. 2025. Paperbench: Evaluating ai’s ability to replicate ai research. Preprint, arXiv:2504.01848. Elias Stengel-Eskin, Archiki Prasad, and Mohit Bansal. 2024. Regal: refactoring programs to discover generalizable abstractions. In Proceedings of the 41st International Conference on Machine Learning, ICML’24. JMLR.org. Jeffrey Svajlenko, Judith F. Islam, Iman Keivanloo, Chanchal K. Roy, and Mohammad Mamun Mia. 2014. Towards a big data curated benchmark of interproject code clones. In 2014 IEEE International Conference on Software Maintenance and Evolution, pages 476–480. Qwen Team. 2024. Qwen2.5 technical report. arXiv preprint arXiv:2412.15115. Alex Thillen, Niels Mündler, Veselin Raychev, and Martin Vechev. 2026. CodeTaste: Can LLMs generate human-level code refactorings? Preprint, arXiv:2603.04177. David Thomas and Andrew Hunt. 2019. The pragmatic programmer, 20th anniversary edition: journey to mastery, second edition edition. Addison-Wesley, Boston.

Jesper van der Zwaag, Frank Driesens, Bouwe Postma, and Andrea Capiluppi. 2025. Refactoring crossproject code duplication in an industrial software product line: A case study from RDW. J. Syst. Softw., 230(C). Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. 2023. Voyager: An openended embodied agent with large language models. Preprint, arXiv:2305.16291. Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, and 5 others. 2025a. OpenHands: An open platform for AI software developers as generalist agents. In International Conference on Learning Representations (ICLR). Zhengren Wang, Rui Ling, Chufan Wang, Yongan Yu, Sizhe Wang, Zhiyu Li, Feiyu Xiong, and Wentao Zhang. 2025b. MaintainCoder: Maintainable code generation under dynamic requirements. In Advances in Neural Information Processing Systems. John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik R Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-computer interfaces enable automated software engineering. In The Thirty-eighth Annual Conference on Neural Information Processing Systems. Ruru Yue, Zhe Gao, Na Meng, Yingfei Xiong, Xiaoyin Wang, and J. David Morgenthaler. 2018. Automatic clone recommendation for refactoring based on the present and the past. Preprint, arXiv:1807.11184. Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Hao Zhang, Joseph E. Gonzalez, and Ion Stoica. 2023. Judging llm-as-a-judge with mt-bench and chatbot arena. In Proceedings of the 37th International Conference on Neural Information Processing Systems, NIPS ’23, Red Hook, NY, USA. Curran Associates Inc.

Appendix Table of Contents A Initial-Construction Results A.1 Paired Statistical Tests . . . . . . A.2 WebGen-Bench Setup & Results . A.3 PaperBench Setup & Results . . . A.4 Qualitative Example . . . . . . .

14 14 14 14 14

B Post-Construction Maintenance B.1 Policy Updates . . . . . . . . . . B.2 Expanded Results . . . . . . . . . B.3 Qualitative Example . . . . . . . B.4 Change-Specific Test Cases . . . .

14 14 15 15 16

C Inference Cost and Cost Reduction C.1 Inference Cost . . . . . . . . . . . C.2 Migration-Session Reuse . . . . . C.3 Fewer Migration Rounds . . . . .

24 24 24 24

D Backbone Robustness

24

E Low-Reuse Suite Stress Test

24

F Agentic SE Scaffold Comparison

24

G Algorithms

25

H Prompts and Auxiliary Inputs H.1 Agent Prompts . . . . . . . . . . H.2 Code-Index Summarization . . . . H.3 Candidate-Selection Prompts . . . H.4 Extraction Trace . . . . . . . . . . H.5 Call-Graph Context . . . . . . . .

28 28 28 28 30 31

I

Library Export Listings

31

J

Responsible NLP Checklist Details J.1 Scientific Artifacts . . . . . . . . J.2 AI Assistants . . . . . . . . . . .

31 31 32

A

Initial-Construction Results

A.3

A.1

Paired Statistical Tests

A.3.1 Agent Environment We pre-install 27 packages in the agent container: PyTorch, NumPy, SciPy, scikit-learn, and pandas, along with common plotting, I/O, and configuration utilities. Domain frameworks such as stable-baselines3, transformers, and timm are left out on purpose. Such a framework already implements a paper’s method, so it would hand the agent the very code that a shared library is meant to capture. We would then be measuring whether a method calls the framework, not how it organizes its own code. The container also runs with –network=none, so no agent can install anything mid-run. The list of available packages is given to the agent in its prompt. Every method runs in this same container, Zero-Shot included.

To assess whether the maintainability differences between SLA-F ULL and each baseline are statistically reliable rather than artifacts of a few suites, we run paired significance tests at the level of individual tasks. For each metric we form one paired observation per task, taking the unit of pairing to be a (suite, task) pair and averaging over the three trials to reduce run-to-run noise. This yields n = 20 paired units for PaperBench (five suites of four papers) and n = 24 for WebGen-Bench (three suites of eight tasks). For every method pair we compute the mean paired difference ∆ (oriented so that a positive value favors SLA-F ULL on lower-is-better metrics), a bootstrap 95% confidence interval over ∆ (10,000 resamples), and a two-sided paired t-test p-value. Table 6 reports the results. The reductions in token length and Verbosity over zero-shot are significant on both benchmarks, and SLA-F ULL significantly reduces Erosion relative to the naive baselines. No functionality metric differs significantly between methods, so the maintainability gains do not come at the cost of task performance. Against L IBRARIAN, SLA-F ULL obtains significant reductions in Erosion and Verbosity on WebGen-Bench and in token length and Verbosity on PaperBench, while no metric significantly favors L IBRARIAN. A.2

WebGen-Bench Setup & Results

A.2.1 About Layout Descriptions For fair comparison, we augment the original instructions with detailed layout descriptions. Because WebGen-Bench instructions are often brief, agents can produce substantially different initial designs, making maintainability metrics sensitive to arbitrary design complexity rather than library reuse. We therefore use Claude Opus 4.7 to generate an initial webpage from each raw instruction and describe the rendered layout, then provide this description to all methods together with the original instruction. This controls design variance and allows us to more directly evaluate code abstraction, migration, and reuse. A.2.2 Evaluation Suites Table 7 lists the tasks in each suite and how the suites were constructed. A.2.3 Per-Suite Results See Table 9 for WebGen-Bench per-suite results.

PaperBench Setup & Results

A.3.2 Evaluation Suites Table 8 lists the papers in each suite and how the suites were constructed. A.3.3 Per-Suite Results See Table 10 for PaperBench per-suite results. A.4

Qualitative Example

Figure 5 shows a detailed example from WebGenBench Suite 1. Four of the eight applications persist state to localStorage in both portfolios. ZeroShot writes the same load-and-persist cycle into each of them, each with its own try/catch and JSON round-trip. SLA-F ULL extracts the cycle into one library hook, which the four applications reach through one import and one call each.

B

Post-Construction Maintenance

B.1

Policy Updates

We construct each maintenance request in two isolated stages. First, an agent observes only the task metadata for a suite and writes one policy update grounded in behavior shared across its applications. Second, isolated sessions use each application’s original instruction and layout description to instantiate the policy for that application. Neither stage observes generated code, Super Libraries, or evaluation results. We retain the first policy produced for each suite without selecting among alternatives. This appendix reproduces the suite-level instructions and the resulting change-specific WebVoyager tests. The tests also identify every target application.

vs. Zero-Shot ∆ [95% CI]

vs. Librarian

vs. Naive-Implicit

vs. Naive-Ward

p

∆ [95% CI]

p

∆ [95% CI]

p

∆ [95% CI]

p

WebGen-Bench (n = 24) Acc. ↑ -0.85 [-3.24, +1.38] Appear. ↑ -0.028 [-0.125, +0.042] LOC ↓ +105 [+54, +154] Tok ↓ +591 [+275, +891] MDL ↓ +85 [-43, +206] Eros. ↓ +0.0213 [-0.0072, +0.0535] Verb. ↓ +0.0582 [+0.0315, +0.0867]

0.484 0.539 0.001 0.001 0.207 0.189 0.001

-1.14 [-3.07, +0.78] +0.028 [-0.069, +0.125] +53 [+0, +102] +316 [-1, +633] -34 [-170, +92] +0.1338 [+0.0836, +0.1860] +0.0334 [+0.0101, +0.0594]

0.274 0.575 0.059 0.068 0.623 4.5e-05 0.017

+0.23 [-2.38, +2.60] +0.028 [-0.056, +0.125] +73 [+28, +126] +518 [+232, +884] +113 [-57, +308] +0.1322 [+0.0595, +0.2113] +0.0240 [-0.0021, +0.0609]

0.864 0.575 0.009 0.006 0.256 0.002 0.174

-1.04 [-3.23, +1.06] +0.042 [-0.028, +0.125] +29 [+3, +56] +268 [+60, +492] +60 [-77, +207] +0.1249 [+0.0502, +0.2037] +0.0455 [+0.0251, +0.0719]

0.358 0.328 0.044 0.028 0.434 0.004 0.001

PaperBench (n = 20) Score ↑ -0.0122 [-0.0437, +0.0182] LOC ↓ +81 [-15, +165] Tok ↓ +1272 [+357, +2071] MDL ↓ +213 [-171, +560] Eros. ↓ +0.0362 [-0.0104, +0.0804] Verb. ↓ +0.0342 [+0.0226, +0.0460]

0.458 0.097 0.010 0.273 0.148 2.5e-05

-0.0218 [-0.0545, +0.0107] +75 [-19, +158] +1196 [+325, +1979] +221 [-157, +568] +0.0291 [-0.0157, +0.0705] +0.0267 [+0.0149, +0.0387]

0.216 0.120 0.012 0.250 0.219 4.0e-04

-0.0007 [-0.0242, +0.0274] +48 [-37, +128] +756 [+134, +1369] +90 [-203, +345] +0.0496 [+0.0091, +0.0935] +0.0189 [+0.0041, +0.0333]

0.959 0.271 0.029 0.531 0.038 0.022

-0.0089 [-0.0416, +0.0240] +47 [-56, +146] +628 [-543, +1735] +20 [-542, +551] +0.0347 [-0.0032, +0.0736] +0.0210 [+0.0064, +0.0339]

0.607 0.388 0.304 0.945 0.101 0.008

Metric

Table 6: Paired significance tests comparing SLA-F ULL against each baseline (protocol in the text). ∆ is the compared method minus SLA-F ULL, so SLA-F ULL is favored by a positive ∆ on lower-is-better (↓) metrics and by a negative ∆ on higher-is-better (↑) ones; bold marks p < 0.05. WebGen LOC/Tok/MDL are per-task.

Suite 1: Engagement-form standardization.

Suite 3: Trust, safety, and search quality.

Our organization has standardized how all customer-facing engagement forms behave across its web properties. For every contact, lead, newsletter, reservation, or similar primary engagement form:

Our platform group has adopted a trust-and-safety policy for user-generated content, plus a searchquality baseline. Part A: Moderation status. For each publicly visible user-generated content submission flow— submissions that appear in lists, feeds, or search results seen by other users (e.g., shared promotions, job postings, job/internship applications appearing in a reviewable list, tool comments/ratings, uploaded pictures, newly registered public profile cards):

1. Required text inputs must reject empty or whitespace-only values. 2. If an email field exists, it must require a value containing both “@” and “.”. 3. An invalid submit must show a clear inline error message and must not show a success state. 4. An invalid submit must preserve the user’s current input values. 5. A valid submit must show an in-page confirmation without navigating away. 6. The confirmation must include either “Received” or “Submitted”, and must include the submitted name or email when such a field exists.

1. After successful submission, show a confirmation message. 2. The submitted item must display a visible “Pending review” badge or status text. 3. Pending items must remain visible in the relevant list/detail/search views—do not hide them. Explicitly excluded from moderation (keep original immediate behavior): edits to one’s own profile fields, one-to-one chat messages, friend invitations.

Original navigation and content behavior must not be removed or weakened.

Suite 2: Record-audit policy.

Part B: Search normalization. Search must trim leading/trailing whitespace, match caseinsensitively, and show a clear empty-state message when there are no matches (instead of a blank area or silently showing all items).

Our organization has adopted a record-audit policy for its data-management applications. For each app’s primary create/update workflows: 1. When a new domain record is created, display a human-readable record ID with a domain prefix and a 3+ digit/character suffix where possible (e.g., CALL-001, LEAD-001, PAT001, TASK-001). Where the app already exposes a domain-prefixed ID scheme, keep that scheme. 2. Created or updated records must display a “Last updated” timestamp or date, refreshed on update. 3. Create and update actions must show a confirmation message. 4. The created/updated record must be findable from the app’s relevant list, search, filter, tracking, or status view. Original CRUD, report, and navigation behavior must not be removed or weakened.

Original registration, login, navigation, and search behavior must not be removed or weakened.

B.2

Expanded Results

Table 11 supplements the aggregate results in Table 2 with the number of files touched, changes in portfolio-level structural metrics, and Patch Size for each suite. B.3

Qualitative Example

Figure 6 shows a detailed example from WebGenBench Suite 1. Zero-Shot and SLA-F ULL receive

Zero-Shot • application code

SLA-Full • library, 51 lines

// tasks/000019 .. src/App.jsx const [submissions, setSubmissions] = useState(() => { try { const saved = localStorage.getItem( 'brickworks_contact_submissions'); return saved ? JSON.parse(saved) : []; } catch { return []; } }); [...] localStorage.setItem( 'brickworks_contact_submissions', JSON.stringify(updated));

// lib/src/hooks/useLocalStorage.js export function useLocalStorage( key, initialValue) { const [storedValue, setStoredValue] = useState(() => { try { const item = localStorage.getItem(key); return item !== null ? JSON.parse(item) : initialValue; } catch { return initialValue; } }); const setValue = useCallback((value) => { [...] }, [key]); const clearValue = useCallback(() => { [...] }, [key, initialValue]); return [storedValue, setValue, clearValue]; }

// tasks/000040 .. src/App.jsx function loadCart() { try { const data = localStorage.getItem( CART_STORAGE_KEY); return data ? JSON.parse(data) : []; } catch { return []; } } useEffect(() => { localStorage.setItem(CART_STORAGE_KEY, JSON.stringify(cartItems)); }, [cartItems]); // tasks/000064 .. 8 more calls in 4 files // tasks/000075 .. 3 more calls // Zero-Shot has no library.

SLA-Full • application code, 2 lines each // tasks/000019 .. src/App.jsx import { useLocalStorage, ... } from '../../lib/src/index.js'; const [submissions, setSubmissions] = useLocalStorage( 'brickworks_contact_submissions', []); // tasks/000040 .. src/context/CartContext.jsx const [cart, setCart] = useLocalStorage('apex_cart', []); // tasks/000016, 000064 .. the same two lines // No application calls localStorage directly.

Figure 5: Initial-construction example. Zero-Shot repeats the same persistence cycle in every application that needs it, while SLA-F ULL defines it once in the library.

the same policy (Section B.1), whose first two items require that an email field contain both @ and a dot. Zero-Shot implements the rule independently in four of the six applications, each with its own message. SLA-F ULL adds it once to a library component, the shared validator that the shared contact form already calls, so five of the six applications need no edit at all. B.4

Change-Specific Test Cases

Tables 12–14 report the WebVoyager action and expected result used to evaluate each target application.

Zero-Shot • application code, +186

SLA-Full • library, +76

// tasks/000019 .. src/pages/Contact.jsx + } else if (!email.includes('@') + || !email.includes('.')) { + newErrors.email = <app-specific text>; + }

// lib/src/utils/validate.js +export function validateEmailField( + value, label = 'Email') { + if (!value || !value.trim()) return null; + const trimmed = value.trim(); + if (!trimmed.includes('@') + || !trimmed.includes('.')) { + return `${label} must contain both + "@" and ".".`; + } + return null; +}

// tasks/000071 .. src/pages/Contact.jsx + } else if (!email.includes('@') + || !email.includes('.')) { + newErrors.email = <app-specific text>; + } // tasks/000075 .. src/App.jsx + if (!email.includes('@') + || !email.includes('.')) { + setError(<app-specific text>); + return; + } // tasks/000016 .. a fourth copy of the check // Zero-Shot has no library.

// lib/src/components/ContactForm.jsx + const emailError = + validateEmailField(values[f.name], + f.label); [...] // +53 -10 in this file // lib/src/index.js +export { validateEmailField } + from './utils/validate.js';

SLA-Full • application code, +1 // tasks/000019 .. src/pages/Contact.jsx - { name: 'company', label: 'Company' }, + { name: 'company', label: 'Company', + optional: true }, // the other five applications: unchanged

Figure 6: Post-construction maintenance example. Zero-Shot repeats the requested rule in every application it applies to, while SLA-F ULL adds it once to the library.

Suite

WebGen-Bench tasks

S1

1. [000019] SW solutions brochure. 2. [000075] Team projects & skills. 3. [000015] Clinical office info. 4. [000016] Solar company products. 5. [000040] Consulting & training. 6. [000072] Personal CV/resume. 7. [000071] Designer portfolio. 8. [000064] Shipping news blog.

Content Presentation Brochures & Portfolios

S2 Data Management CRUD / ERP / CRM

S3 User Interaction Social & Job Platforms

1. [000085] Construction project mgmt. 2. [000022] Customer-service call log. 3. [000046] Hospital admin & inventory. 4. [000083] Detective agency case mgmt. 5. [000047] E-government office system. 6. [000044] Supply-chain traceability. 7. [000023] CRM sales lead tracking. 8. [000080] Advanced to-do list app. 1. [000052] Blue-collar job board. 2. [000090] Social networking site. 3. [000051] Driver recruitment listings. 4. [000077] Engineer tool info site. 5. [000092] Skill-sharing platform. 6. [000053] Student internship portal. 7. [000091] Matrimonial matching site. 8. [000027] Promotions & discounts forum.

Table 7: WebGen-Bench evaluation suites. We cluster the 101 WebGen-Bench tasks with Ward agglomerative clustering (k=14, Euclidean) over text-embedding-3-small embeddings of each task’s instruction, category metadata, and UI-test interactions, and select three of the resulting clusters as evaluation suites. From each selected cluster we take the eight tasks closest to the centroid; each suite is then used as a sequential application stream.

Suite

PaperBench tasks

S1

1. fre: Functional Reward Encodings. 2. rice: RICE. 3. sapg: Split and Aggregate Policy Gradients. 4. ftrl: RL Fine-tuning as Forgetting Mitigation.

S2

1. robust-clip: Robust CLIP. 2. sample-specific-masks: Sample-specific Masks. 3. lca-on-the-line: OOD Generalization. 4. test-time-model-adaptation: Test-Time Adaptation.

S3

1. mechanistic-understanding: DPO and Toxicity. 2. what-will-my-model-forget: Forgotten Examples. 3. stay-on-topic-with-classifier-free-guidance: CFG. 4. adaptive-pruning: Adaptive Pruning and Tuning.

S4

1. bridging-data-gaps: Diffusion Transfer Learning. 2. sequential-neural-score-estimation: Neural Score Estimation. 3. stochastic-interpolants: Data-Dependent Couplings. 4. all-in-one: Simulation-Based Inference.

S5

1. bam: Batch-and-Match Variational Inference. 2. pinn: Training PINNs Loss Landscapes. 3. lbcs: Refined Coreset Selection. 4. bbox: BBox-Adapter for Black-Box LLMs.

Table 8: PaperBench evaluation suites. We construct five disjoint suites of four tasks each. Suites S1–S3 are topically coherent (RL, VLM, NLP), S4 is a diffusion/score-based inference suite, and S5 is a heterogeneous low-reuse suite included as a robustness probe. Each suite is used as a sequential task stream for evaluating Super Library Agent methods.

Metric

Suite

Zero

Librarian

Naive

Full

Implicit

Ward

Functionality S1 S2 Acc. ↑ S3 Avg. S1 S2 Appear. ↑ S3 Avg.

82.99 ±2.12 70.28 ±2.55 74.85 ±0.52 76.04 ±5.82 3.84 ±0.08 3.92 ±0.07 3.75 ±0.00 3.84 ±0.09

81.97 ±1.56 70.83 ±2.21 74.55 ±1.82 75.78 ±5.17 3.96 ±0.07 3.84 ±0.08 3.88 ±0.13 3.89 ±0.10

83.67 ±0.00 70.83 ±3.00 76.36 ±1.57 76.96 ±5.83 4.00 ±0.00 3.84 ±0.08 3.84 ±0.08 3.89 ±0.10

83.67 ±3.68 70.00 ±4.64 74.54 ±3.96 76.07 ±7.00 3.96 ±0.07 3.96 ±0.07 3.79 ±0.08 3.90 ±0.10

83.33 ±2.12 72.22 ±3.37 76.06 ±2.62 77.21 ±5.44 3.92 ±0.07 3.96 ±0.07 3.71 ±0.08 3.86 ±0.13

Maintainability S1 S2 LOC ↓ S3 Avg. S1 S2 MDL ↓ S3 Avg. S1 S2 Eros. ↓ S3 Avg. S1 S2 Verb. ↓ S3 Avg.

7129 ±235 9834 ±463 11215 ±51 9392 ±1819 31474 ±1691 36138 ±3020 37013 ±553 34875 ±3118 0.0113 ±0.0196 0.0817 ±0.0101 0.2167 ±0.0463 0.1032 ±0.0939 0.0670 ±0.0189 0.2261 ±0.0336 0.1878 ±0.0234 0.1603 ±0.0754

6623 ±302 9437 ±705 10858 ±207 8973 ±1909 30378 ±1886 35371 ±3372 36008 ±1281 33919 ±3357 0.0948 ±0.1179 0.0842 ±0.0189 0.2264 ±0.0578 0.1352 ±0.0954 0.0514 ±0.0244 0.2187 ±0.0318 0.1715 ±0.0120 0.1472 ±0.0776

6809 ±83 9890 ±741 10700 ±734 9133 ±1853 30556 ±136 37607 ±2778 37144 ±125 35102 ±3689 0.1476 ±0.0819 0.1151 ±0.0717 0.2075 ±0.0312 0.1567 ±0.0697 0.0148 ±0.0056 0.1986 ±0.0610 0.2090 ±0.0335 0.1408 ±0.1008

6459 ±42 9668 ±768 10232 ±665 8787 ±1834 29927 ±614 38014 ±2299 36082 ±2663 34674 ±4070 0.1406 ±0.0670 0.0613 ±0.0253 0.1730 ±0.0358 0.1250 ±0.0639 0.0277 ±0.0192 0.1995 ±0.0166 0.1838 ±0.0142 0.1370 ±0.0836

6299 ±245 9689 ±576 9669 ±445 8552 ±1733 30072 ±1193 36924 ±3397 35589 ±1884 34195 ±3745 0.0102 ±0.0177 0.0673 ±0.0319 0.2185 ±0.0335 0.0986 ±0.0964 0.0361 ±0.0251 0.1382 ±0.0212 0.1238 ±0.0127 0.0994 ±0.0510

Library Size S1 S2 LOC S3 Avg. S1 S2 Tok. S3 Avg. S1 S2 MDL S3 Avg.

– – – – – – – – – – – –

247 ±41 225 ±252 194 ±80 222 ±136 1849 ±357 1579 ±1663 1334 ±554 1587 ±922 640 ±130 752 ±753 526 ±203 639 ±407

493 ±59 431 ±116 418 ±182 447 ±117 3529 ±399 3123 ±753 2867 ±1161 3173 ±776 1297 ±289 1193 ±299 1147 ±318 1212 ±270

510 ±62 499 ±169 290 ±67 433 ±144 3666 ±336 3592 ±750 2012 ±607 3090 ±957 1445 ±155 1332 ±286 749 ±141 1175 ±369

750 ±151 418 ±179 553 ±123 573 ±196 5281 ±1103 3070 ±1207 4077 ±989 4143 ±1353 1985 ±308 1214 ±383 1693 ±305 1631 ±444

Table 9: Per-suite results on WebGen-Bench. We report functionality and maintainability metrics across three disjoint suites of eight tasks each, as mean ± std over three independent trials per suite. Avg. is pooled across all 9 trials (3 suites × 3 trials).

Metric

Suite

Zero

Librarian

Naive

Full

Implicit

Ward

Functionality S1 S2 S3 Score ↑ S4 S5 Avg.

0.3409 ±0.0918 0.4394 ±0.0127 0.4461 ±0.0193 0.5909 ±0.0564 0.5261 ±0.0674 0.4687 ±0.1004

0.3539 ±0.0476 0.3924 ±0.0137 0.4420 ±0.0406 0.5801 ±0.0772 0.5271 ±0.0206 0.4591 ±0.0949

0.3393 ±0.0822 0.4885 ±0.0382 0.4006 ±0.0154 0.6071 ±0.0701 0.5655 ±0.0440 0.4802 ±0.1132

0.3918 ±0.0594 0.4557 ±0.0269 0.3958 ±0.0799 0.5392 ±0.0650 0.5773 ±0.0654 0.4720 ±0.0936

0.3690 ±0.0456 0.4584 ±0.0104 0.4160 ±0.0597 0.5751 ±0.0683 0.5860 ±0.0174 0.4809 ±0.0975

Maintainability S1 S2 S3 LOC ↓ S4 S5 Avg. S1 S2 S3 Tok. ↓ S4 S5 Avg. S1 S2 S3 MDL ↓ S4 S5 Avg. S1 S2 S3 Eros. ↓ S4 S5 Avg. S1 S2 S3 Verb. ↓ S4 S5 Avg.

7128 ±891 6239 ±1006 6922 ±86 6057 ±421 6544 ±488 6578 ±701 69723 ±6679 64270 ±10973 73351 ±2528 64699 ±4074 70974 ±7082 68603 ±6900 28483 ±2831 29510 ±4585 36079 ±3979 27663 ±1995 29977 ±3606 30342 ±4283 0.2070 ±0.0202 0.2342 ±0.0777 0.2560 ±0.0660 0.2012 ±0.1213 0.3804 ±0.0646 0.2558 ±0.0939 0.8889 ±0.0042 0.8482 ±0.0231 0.8455 ±0.0102 0.8645 ±0.0097 0.8853 ±0.0153 0.8665 ±0.0221

7125 ±874 6209 ±961 6928 ±120 5998 ±407 6496 ±437 6551 ±697 69730 ±6560 64100 ±10502 73147 ±1806 64160 ±3727 70350 ±6461 68297 ±6644 28724 ±2727 29656 ±4605 36140 ±3409 27541 ±1892 29941 ±3555 30400 ±4201 0.2133 ±0.0290 0.2350 ±0.0784 0.2383 ±0.0519 0.1974 ±0.1132 0.3795 ±0.0657 0.2527 ±0.0915 0.8865 ±0.0040 0.8435 ±0.0258 0.8404 ±0.0120 0.8618 ±0.0117 0.8818 ±0.0173 0.8628 ±0.0238

7155 ±582 6288 ±754 6309 ±518 6041 ±455 6430 ±140 6445 ±594 70292 ±4967 65198 ±6768 64868 ±6821 63268 ±6188 69066 ±1807 66539 ±5506 29080 ±2283 29216 ±1649 32919 ±2949 27665 ±4704 30369 ±1720 29850 ±3045 0.2536 ±0.0835 0.2394 ±0.0460 0.2656 ±0.0509 0.2978 ±0.0476 0.3849 ±0.1232 0.2882 ±0.0840 0.8707 ±0.0216 0.8413 ±0.0197 0.8394 ±0.0217 0.8719 ±0.0090 0.8675 ±0.0112 0.8582 ±0.0212

7156 ±602 6381 ±820 5992 ±337 6134 ±1059 6536 ±286 6440 ±715 70942 ±5114 64823 ±9037 59797 ±4782 64403 ±10701 70176 ±2483 66028 ±7346 28671 ±2073 30483 ±4302 29731 ±2625 28750 ±4919 30207 ±3485 29568 ±3166 0.2585 ±0.0159 0.2281 ±0.0769 0.2709 ±0.0995 0.2916 ±0.0856 0.3314 ±0.0611 0.2761 ±0.0717 0.8860 ±0.0135 0.8582 ±0.0102 0.8404 ±0.0278 0.8646 ±0.0048 0.8734 ±0.0251 0.8645 ±0.0222

7080 ±526 6387 ±1109 6198 ±381 5604 ±528 5993 ±441 6252 ±748 67897 ±5531 63029 ±12116 62997 ±5168 59037 ±4488 64613 ±4752 63514 ±6636 29006 ±3820 30444 ±7164 32518 ±624 27281 ±1832 28198 ±1530 29489 ±3728 0.1552 ±0.0244 0.2678 ±0.0348 0.2616 ±0.0347 0.1641 ±0.0555 0.2967 ±0.1291 0.2291 ±0.0828 0.8552 ±0.0064 0.8356 ±0.0154 0.8393 ±0.0221 0.8518 ±0.0222 0.8630 ±0.0132 0.8490 ±0.0177

Library Size S1 S2 S3 LOC S4 S5 Avg. S1 S2 S3 Tok. S4 S5 Avg. S1 S2 S3 MDL S4 S5 Avg.

– – – – – – – – – – – – – – – – – –

152 ±53 48 ±37 105 ±48 163 ±43 20 ±5 98 ±68 1445 ±501 472 ±364 950 ±397 2017 ±346 171 ±48 1011 ±752 516 ±208 201 ±126 368 ±130 779 ±240 121 ±26 397 ±280

216 ±91 156 ±87 220 ±49 320 ±25 146 ±80 212 ±88 1960 ±821 1414 ±629 2104 ±587 3385 ±401 1347 ±653 2042 ±929 650 ±190 511 ±218 854 ±131 1137 ±148 673 ±327 765 ±287

308 ±83 355 ±109 231 ±167 364 ±79 215 ±70 295 ±111 2914 ±712 3132 ±963 2089 ±1418 4048 ±899 1757 ±415 2788 ±1155 901 ±125 1212 ±381 825 ±561 1300 ±149 896 ±41 1027 ±332

541 ±73 277 ±150 217 ±128 524 ±15 118 ±34 336 ±192 4872 ±754 2733 ±1786 1879 ±1135 5309 ±184 1050 ±416 3168 ±1927 1583 ±263 1043 ±441 786 ±379 2084 ±125 520 ±197 1203 ±637

Table 10: Per-suite results on PaperBench. We report functionality and maintainability metrics across five disjoint suites of four tasks each, as mean ± std over three independent trials per suite. Avg. is pooled across all 15 trials (5 suites × 3 trials). Library Size reports the size of the final Super Library only.

Patch

Change in maintainability

Patch Size by suite

Added LOC ↓

App ↓

Lib

Files ↓

∆LOC ↓

∆Tok ↓

∆MDL ↓

∆Eros. ↓

∆Verb. ↓

S1

S2

S3

Zero-Shot L IBRARIAN

936 522

936 500

0 22

29.8 27.0

+605 –

+5101 –

+2565 –

−0.004 –

+0.007 –

182 151

1804 717

822 699

NAIVE -I MPLICIT NAIVE -WARD SLA-F ULL

632 380 256

618 363 232

14 18 24

27.4 22.2 19.9

+278 +251 +171

+2874 +2779 +2073

+2078 +1909 +1377

+0.019 +0.030 +0.001

+0.005 +0.011 +0.003

97 103 79

1328 574 422

471 463 268

Method

Table 11: Post-construction maintenance, full results. The table extends Table 2 with the number of files touched, changes in portfolio-level structural metrics, and Patch Size for each suite. ∆ columns report post-patch minus pre-patch values. They are unavailable for L IBRARIAN, whose pre-patch portfolio is a post-hoc refactoring of the Zero-Shot codebases rather than a round-structured run.

Table 12: Change-specific tests for Suite 1. Each row reproduces one WebVoyager action and its expected result. App ID

Action

000015

Go to the Contact Us page. In the contact form, fill the Name and An inline error message appears, no success/confirmation state is shown, Message fields but leave Email empty (or whitespace only), then and the values already typed in Name and Message remain in the fields. submit. On the same contact form, fill Name, a valid Email containing “@” An in-page confirmation appears on the Contact Us page without navand “.”, and Message, then submit. igating away, containing the word “Received” or “Submitted” and including the submitted name or email. Go to the Contact page. In the contact form, enter a Name and Mes- A clear inline error appears for the email field, no confirmation banner sage but type an invalid email without “@” or “.” (e.g., “testmail”), is shown, and the typed Name, Email, and Message values remain in then submit. the inputs. Correct the email to a valid address containing “@” and “.”, then An in-page confirmation banner appears on the Contact page without submit the form. navigating away, containing “Received” or “Submitted” together with the submitted name or email. Go to the Contact page. Submit the contact form with the “How can An inline error message appears, no confirmation is shown, and all we help?” field empty while Name and Email are filled. values typed so far, including Company if entered, are preserved in the form. Fill Name, a valid Email containing “@” and “.”, and the “How can An in-page confirmation appears on the Contact page without naviwe help?” field, then submit. gating away, including “Received” or “Submitted” plus the submitted name or email. Go to the Newsletter page. Enter an invalid email without “@” or “.” A clear inline error message appears, no success state is shown, and the (e.g., “newsfan”) into the subscription input and click Subscribe. typed value remains in the input. Replace it with a valid email containing “@” and “.”, then click An in-page confirmation appears on the same page without navigating Subscribe. away, containing “Received” or “Submitted” along with the submitted email address. Go to the Contact page’s “Get in Touch” form. Submit it with the A clear inline error message appears, no saved/confirmation line is Message field empty (or spaces only) while Name and Email are shown, and the typed Name and Email values are preserved in the form. filled. Fill all three fields with valid values (email containing “@” and “.”) An in-page confirmation appears beneath the form without navigating and submit. away, including “Received” or “Submitted” together with the submitted name or email. Scroll to the Contact Us section. Submit the contact form with all A clear inline error message appears within the Contact Us section, and fields empty. no success state is shown. Fill name, a valid email containing “@” and “.”, and a message, then An in-page confirmation appears within the Contact Us section without submit. navigating away, and includes “Received” or “Submitted” plus the submitted name or email.

000015 000016 000016 000019 000019 000064 000064 000071 000071 000075 000075

Expected result

Table 13: Change-specific tests for Suite 2. Each row reproduces one WebVoyager action and its expected result. App ID

Action

000022

Create a new call log via the New Call form with required fields filled. A confirmation message appears, and the new call log displays a humanreadable ID with the CALL- prefix (e.g., CALL-001) and a “Last updated” timestamp. The call appears in the Open Calls or To-Do Calls view. Modify an existing client’s information (or close/mark done an exist- A confirmation message appears and the record’s “Last updated” timesing call). tamp refreshes to reflect the change. Create a new lead via the New Lead form/modal with valid details. A confirmation message appears, and the new lead is shown with a LEAD- prefixed ID (e.g., LEAD-001) and a “Last updated” timestamp or date, visible in the leads table. Change that lead’s status (or edit it), then locate it using the leads A confirmation appears, the “Last updated” value refreshes, and the search or filters. lead is findable via search/filter with its LEAD- ID still displayed. A confirmation message appears and the product’s SCT- prefixed ID is Register a new product via the registration form. displayed immediately upon registration. Add a checkpoint to that product on the Track screen, then look it up A confirmation appears for the checkpoint, the product’s “Last updated” on the Inquiry screen. line refreshes, and the product is findable via the Inquiry search with its updated status. Create a new patient electronic file in the patient management section. A confirmation message appears and the new patient record displays a PAT- prefixed ID (e.g., PAT-001) and a “Last updated” timestamp or date, visible in the patient files list. Add a new medicine in the pharmacy section (or collect a patient fee A confirmation appears and the new record shows its prefixed ID (MEDin finances). or FEE-) with a “Last updated” value, findable in the corresponding section list. A confirmation message appears and the new task row displays a TASKAdd a new task via the Add Task input. prefixed ID (e.g., TASK-001) and a “Last updated” timestamp or date. Edit that task’s description (or toggle it complete), then find it via A confirmation appears, the “Last updated” value refreshes, the ID search and the matching filter. persists, and the task is findable via search and under the correct All/Active/Completed filter. Submit a real-time report on a case. A confirmation message appears and the new report entry displays an RPT- prefixed ID with a timestamp, visible in the selected case’s report history. Log work hours for the same case. A confirmation appears, the new hours entry shows an HRS- prefixed ID with a “Last updated” timestamp, and the case’s total hours update. Create a new project via the New Project action. A confirmation message appears and the new project row displays a PRJ- prefixed ID (e.g., PRJ-001) and a “Last updated” date, visible in the Projects table and reflected on the dashboard. Add a schedule task (or a document), then mark the task complete. A confirmation appears on create, and the record shows its prefixed ID (TASK- or DOC-) with a “Last updated” value that refreshes on the completion toggle.

000022 000023 000023 000044 000044 000046 000046 000080 000080 000083 000083 000085 000085

Expected result

Table 14: Change-specific tests for Suite 3. Each row reproduces one WebVoyager action and its expected result. App ID

Action

000027

Share a new promotion using the share form with all necessary details. A confirmation message appears, and the new promotion is visible in the browse list carrying a visible “Pending review” badge or status text. It is not hidden. Search for that promotion using its title typed in mixed case with The mixed-case padded query still returns the promotion. The nonsense leading and trailing spaces, then search for a nonsense string such as query shows a clear empty-state message instead of a blank area or all “zzqqxx”. deals. A confirmation appears, and the new listing shows a visible “Pending Post a new job as a client with all required details. review” badge while still appearing on the jobs board and in the client’s active-postings list. Search the jobs page for that job’s title typed in mixed case with The padded mixed-case query returns the job. The nonsense query surrounding spaces, then search for a nonsense string. shows a clear empty-state message instead of a blank list or all jobs. On the jobs page, search for “ELECTRICIAN ” (upper case with The padded upper-case query returns the electrician listings. The nontrailing spaces), then search for a nonsense string such as “zzqqxx”. sense query shows a clear empty-state message such as “No jobs match your search” instead of a blank grid or all listings. As a company, post a new internship position. A confirmation appears, and the new listing shows a visible “Pending review” badge while remaining visible on the student browse list and in the company’s listings. On the student panel, search for that internship’s role typed in mixed The padded mixed-case query returns the internship. The nonsense case with surrounding spaces, then search for a nonsense string. query shows a clear empty-state message instead of a blank list or all internships. As a logged-in user, add a comment and rating to a tool. A confirmation message appears, and the review is visible under the tool’s reviews section with a visible “Pending review” badge or status text. Search for a tool by its name typed in mixed case with leading and The padded mixed-case query returns the tool. The nonsense query trailing spaces, then search for a nonsense string. shows a clear empty-state message instead of a blank grid or all tools. As a logged-in user, upload a picture post. A confirmation message appears, and the new post is visible in the updates feed carrying a visible “Pending review” badge or status text. It is not hidden from the feed or the profile’s own updates. Register a new member profile with valid details. A confirmation appears, and the newly registered profile appears in partner search results carrying a visible “Pending review” badge or status text. It is not hidden from matches. Search for that member using a keyword typed in mixed case with The padded mixed-case query still returns the member. The no-match surrounding spaces, then search with criteria that match no one. search shows a clear empty-state message instead of a blank panel or all profiles. Join as a new member with skills filled in. A confirmation appears, and the new member’s card shows a visible “Pending review” badge or status text in the browse-members grid. It is not hidden. Search members for one of that member’s skills typed in mixed case The padded mixed-case query returns the member. The nonsense query with surrounding spaces, then search for a nonsense skill. shows a clear empty-state message instead of a blank result area or all members.

000027 000051 000051 000052 000053 000053 000077 000077 000090 000091 000091 000092 000092

Expected result

C

Inference Cost and Cost Reduction

C.1

Inference Cost

Maintaining a shared library is not free. Table 15 reports the total LLM spend to produce one portfolio, relative to Zero-Shot. The difference comes from how dependencies are migrated (Section 3.3). SLA-F ULL runs a separate migration agent per application, whereas the naive variants extract and migrate in a single call. We consider two ways to reduce this cost, migration-session reuse and fewer migration rounds. The rest of this section evaluates each. C.2

Migration-Session Reuse

SLA-F ULL gives each application its own dependency-migration agent and starts it with a fresh context every round, so an application’s code is read again in every round it survives, whether the previous round changed it or not. We therefore compare fresh sessions against reused sessions on cost, functionality, and maintainability, with everything else held fixed. Both arms start from the same round-1 portfolio and run over three suites × three trials. Table 16 shows a significant drop in both total cost and migration turns, with all six quality metrics statistically indistinguishable. The saving depends on prompt caching. Session reuse sends about 6% more input, but that prefix is stable across rounds and 97% of input tokens are cache hits. Repriced without a cache discount the saving falls to 1.9% and is no longer significant, whereas the drop in migration turns does not depend on pricing. C.3

Fewer Migration Rounds

The number of migration cycles is itself a knob. Holding the portfolio fixed at eight applications, we vary m, the number of applications generated per round. The paper’s configuration is m=2 over four rounds, and we additionally run m=4 over two rounds and m=8 in a single round. Table 17 shows cost falling steeply as rounds are removed, from 8.3× to 4.9× Zero-Shot, since fewer rounds mean fewer migration passes over the portfolio. The saving comes with a loss in quality. At m=8, accuracy drops by 3.6%, LOC rises by 4.4%, and Verbosity rises by 11.1%.

D

Backbone Robustness

To test whether the main result is specific to the coding backbone, we rerun the WebGen-Bench pro-

Method

WebGen

PaperBench

Zero-Shot L IBRARIAN (K=8)

1.0 5.9

1.0 3.2

NAIVE -I MPLICIT NAIVE -WARD SLA-F ULL

3.1 2.9 8.3

1.7 1.7 3.1

Table 15: Cost of producing one portfolio, as total LLM spend relative to Zero-Shot (×ZS, lower is better); same runs as Table 1. L IBRARIAN (K=1) is omitted: it reuses a sample already drawn for K=8 and has no independent cost.

tocol with minimax-m3 (Lai et al., 2026), keeping the three N =8 suites, m=2, four-round schedule, and evaluation harness unchanged. Table 18 shows that the core result transfers. SLAF ULL again produces the most compact portfolio, with the lowest LOC, token length, and Verbosity, and its appearance score is indistinguishable from the best.

E

Low-Reuse Suite Stress Test

Each suite in the main results is taken from a single topical group of the benchmark tasks, so its applications have much in common, which is a favorable setting for a shared library. To build the opposite, we cluster all 101 WebGen-Bench tasks by embedding similarity into 14 topical groups, set aside the 24 tasks already used by the three reported suites, and take one or two of the remaining tasks from each group until we reach N =16. The result spans 13 groups, one having been fully consumed by the reported suites. With m=2, its 16 applications run over eight rounds. Even in this unfavorable setting, SLA-F ULL still produces the smallest portfolio in Table 19, with the lowest LOC, token length, and Verbosity. Its MDL is level with NAIVE -WARD, and it has the lowest Erosion of the library-building methods. Functionality degrades in this setting, with SLAF ULL falling below Zero-Shot on both accuracy and appearance. This is what the stress test was built to create, since the applications share as little as the benchmark allows and a shared library therefore has little to reuse.

F

Agentic SE Scaffold Comparison

All experiments in the paper use the minimal mini-SWE-agent scaffold. As a reference point we also run two recent agentic SE systems,

Cost Migration configuration Fresh sessions Reused sessions ∆ (%) p

Functionality

Maintainability

Total ($) ↓

Migr. turns ↓

Acc. ↑

Appr. ↑

LOC ↓

MDL ↓

Eros. ↓

Verb. ↓

0.453 0.400 −11.7 0.017

485 354 −27.0 0.002

75.4 76.0 +0.8 0.749

3.78 3.88 +2.6 0.064

8598 8760 +1.9 0.348

34473 35122 +1.9 0.553

0.094 0.104 +11.1 0.410

0.104 0.114 +10.0 0.536

Table 16: Reusing the dependency-migration session across rounds (WebGen-Bench). Mean over three suites × three trials (n=9), both arms seeded from the same round-1 portfolio. p is from a two-sided paired t-test, with p < 0.05 in bold. Cost is the total spend to produce one portfolio, as in Table 1. Reusing the session cuts cost and migration turns significantly while every functionality and maintainability metric is statistically indistinguishable.

m

Rounds

Cost ↓

Acc. ↑

LOC ↓

Verb. ↓

2 4 8

4 2 1

8.30 6.55 4.93

77.21 73.97 74.44

8552 8643 8932

0.099 0.095 0.110

Table 17: Applications per round (WebGen-Bench). The portfolio is fixed at eight applications; m sets how many arrive per round, so larger m means fewer extractand-migrate cycles. m=2 is the configuration used everywhere else in the paper. Cost is relative to Zero-Shot, as in Table 15; mean over three suites × three trials. Zero-Shot NAIVE -I NAIVE -W SLA-F ULL Functionality Acc. ↑ Appr. ↑

79.17 3.92

74.51 3.86

81.68 3.90

77.45 3.91

Zero-Shot NAIVE -I NAIVE -W SLA-F ULL Functionality Acc. ↑ 69.02

62.58

63.37

65.88

Appr. ↑

3.48

3.52

3.29

3.66

Maintainability LOC ↓ Tok ↓

23,263 177,022

20,744 163,063

19,900 157,096

18,557 147,844

MDL ↓ Eros. ↓

76,131 0.189

72,606 0.303

67,277 0.282

67,943 0.248

Verb. ↓

0.179

0.157

0.165

0.121

Table 19: Stress test: the hardest suite of N =16 tasks (WebGen-Bench). Mean over three trials; bold marks the best method per row. Metrics are computed with the same evaluation harness as the main results. Standard deviations are omitted for space.

Maintainability LOC ↓

10,957

11,305

11,152

10,581

Tok ↓ MDL ↓

80,796 46,124

85,795 51,578

85,930 49,975

80,185 48,910

Eros. ↓ Verb. ↓

0.112 0.125

0.152 0.099

0.159 0.134

0.127 0.095

Table 18: Results with the Minimax-M3 backbone (WebGen-Bench). Mean over three suites × three trials; bold marks the best method per row. Standard deviations are omitted for space and follow the same pattern as Table 1.

O PEN H ANDS (Wang et al., 2025a) and C LAUDE C ODE,10 in the Zero-Shot slot, where each generates the eight applications of a suite independently with no shared library and no cross-codebase memory. Only the scaffold differs, with the backbone, reasoning-effort setting, task specifications, and evaluation harness as in the main results. As Table 20 shows, the recent scaffolds are strong on some metrics. C LAUDE C ODE attains the best accuracy and MDL, and O PEN H ANDS the 10

https://www.anthropic.com/claude-code

best appearance and Erosion. But SLA-F ULL still leads on LOC, token length, and Verbosity, because an agent working on one codebase at a time cannot see redundancy across applications. Removing that redundancy needs a shared library, not a stronger scaffold. SLA is a layer over a scaffold, so it could be instantiated over these systems as well.

G

Algorithms

Algorithm 1 gives the full procedure for the minimal scaffold (Section 3.2), used as our SLANAIVE comparison baseline, and Algorithm 2 gives the full procedure for SLA-F ULL (Section 3.3).

Functionality

Maintainability

Method

Scaffold

Acc. ↑

Appr. ↑

LOC ↓

Tok ↓

MDL ↓

Eros. ↓

Verb. ↓

Zero-Shot Zero-Shot Zero-Shot

mini-SWE-agent O PEN H ANDS C LAUDE C ODE

76.04 77.34 78.20

3.84 3.92 3.86

9393 8948 8712

70364 68528 67857

34875 34926 34009

0.1032 0.0732 0.1125

0.1603 0.1489 0.1349

SLA-F ULL

mini-SWE-agent

77.21

3.86

8552

65633

34195

0.0987

0.0994

Table 20: Scaffold comparison (WebGen-Bench). All rows use the same backbone (deepseek-v4-flash), task specifications, and reasoning-effort setting, and only the scaffold differs. Mean over three suites × three trials.

Algorithm 1 M INIMAL AGENTIC S CAFFOLD: per round, m codebases are generated in parallel by the Coding agent, and a single Library agent then both extracts shared symbols into Lr and migrates the existing codebases to use Lr in one call. Require: Test instances {xi }N i=1 , batch size m (with N divisible by m) 1: L0 ← ∅ 2: for r = 1 to N/m do 3: Br ← {x(r−1)m+1 , . . . , xrm } 4: Stage 1. Coding agent — Generate codebases 5: in parallel for all i with xi ∈ Br : 6: ci ← C ODING(xi | Lr−1 ) 7: end parallel

▷ batch of m instances

Stage 2. Library
agent — Joint extraction and
migration rm rm 9: {cj }j=1 , Lr ← L IBRARY {ct }t=1 , Lr−1 10: ▷ single agent jointly extracts shared symbols into Lr and rewrites local implementations as imports from Lr 11: end for 12: return {cj }N j=1 , LN/m 8:

Algorithm 2 SLA-F ULL (ours): two-level library extraction with code-block index Nr and accumulated extraction trace Tr , followed by trace-guided dependency migration. Require: Test instances {xi }N i=1 , batch size m (with N divisible by m) 1: L0 ← ∅, N0 ← ∅, T0 ← ∅ 2: for r = 1 to N/m do 3: Br ← {x(r−1)m+1 , . . . , xrm } 4: Stage 1. Coding agent — Generate codebases 5: in parallel for all i with xi ∈ Br : 6: ci ← C ODING(xi | Lr−1 , Nr−1 ) 7: end parallel
8: Nr ← I NDEX B LOCKS Nr−1 , {ci }xi ∈Br 9: 10: 11: 12: 13:

Stage 2a. Two-level library extraction (consolidation then update) in parallel for all i with xi ∈ Br : ci ← C ONSOLIDATE(ci , Nr ) ▷ intra-codebase pre-extraction consolidation end parallel
(Lr , Tr ) ← L IBRARY U PDATE {ct }rm t=1 , Lr−1 , Tr−1 , Nr

Stage 2b. Dependency migration with extraction trace in parallel for all j ∈ {1, . . . , rm}: 16: cj ← M IGRATE(cj , Lr , Tr ) ▷ Tr pre-localizes migration sites in cj 17: end parallel 18: end for 19: return {cj }N j=1 , LN/m 14: 15:

H

Prompts and Auxiliary Inputs

H.1

Agent Prompts

This appendix summarizes what each agent is instructed to do. The verbatim text of the four agent prompts, for both benchmarks, is in our released code. Here we record the division of labor and the constraints that matter for interpreting the results. Stage structure. SLA-F ULL runs four subagents per round. The coding agent implements the round’s tasks against the benchmark specification. The local extract agent then consolidates duplication within each new codebase into a codebase-local module (the pre-extraction consolidation of Section 3.3.1). The global extract agent (the library-extraction agent of Section 3.3) grows the shared Super Library from patterns recurring across codebases, and the migration agent (the dependency-migration agent) rewrites each application to consume the resulting library. SLA- NAIVE omits local extraction and collapses global extraction and migration into a single-shot library agent. This difference in decomposition, not in prompt wording, is what the two conditions compare. Cross-benchmark scope. The three librarymanipulating prompts—local extract, global extract, and migration—are byte-identical across WebGen-Bench and PaperBench: they refer to code structure rather than to any domain concept. Only the coding agent and the SLA- NAIVE library agent are benchmark-specific, since they must state the target stack and the run/build contract. Shared rule blocks. Every agent that can touch application or library code receives the same two rule blocks, which encode the constraints assumed throughout the paper: application code may import from the library but the library may never import from an application; the library must remain free of application-specific state; and each benchmark’s build and entry-point conventions must be preserved so that a refactored portfolio still runs under the evaluation harness unchanged. H.2

Code-Index Summarization

The candidate-selection prompts in Appendix H.3 are built from natural-language summaries of code rather than from source files. Every application codebase and the Super Library carry an index that pairs each AST-delimited

chunk11 with a one-line natural-language summary. One LLM call summarizes one chunk, using the following instruction. System Prompt (chunk summarization) You summarize a code chunk in ONE concise English sentence (<=160 chars). Describe what the chunk does -- its purpose and notable mechanism if non-obvious. No quotes, no preamble like 'This chunk'. Output only the summary.

The user message carries only the chunk itself, prefixed by its file path, line span, and language. An index entry stores the language, file path, line span, a content hash, and the summary. The hash makes the index incremental. A chunk whose hash is unchanged keeps its stored summary, so each round pays only for code that actually changed. Chunks shorter than five lines are skipped. An index is rendered into a prompt as one line per chunk, the format shown under ## LIBRARY and ## APP in Appendix H.3. Two example entries follow. Rendered index lines - chunk_id=6 [40L] src/components/Button.jsx:1 -- Defines a reusable themed Button component that composes CSS classes from variant/size/block props (with defaulting) and renders a native button. - chunk_id=23 [23L] src/hooks/useSearchFilter. js:1 -- Defines a React hook scaffold that will track searchQuery and activeCategory state and use filterBySearch to compute filtered items.

H.3

Candidate-Selection Prompts

H.3.1 Extraction Candidates System Prompt You are a senior library architect deciding which code patterns to extract from multiple Python codebases into a shared library. You will be given one-line summaries of every chunk across all apps, plus summaries of the EXISTING library (treat lib symbols as ' already extracted' -- do NOT propose duplicates). Identify the TOP-K distinct, high-value crossapp patterns that appear in TWO OR MORE apps and would be genuinely worth extracting (not trivial helpers, not app-specific glue, not 11 We use cocoindex-code. cocoindex-io/cocoindex-code

https://github.com/

duplicates of existing lib). For each candidate, output exactly: ### C<n>. <short pattern name> **Pattern**: <1 sentence describing the shared behavior> **Why extractable**: <1 sentence on why this generalizes> **Members**: - <app>::<file_path>:<start>-<end>::< chunk_id=<id>> -- <summary> - ... (>=2 distinct apps required) Be conservative -- false positives matter more than coverage.

User Prompt (with sample indices) ### EXISTING LIBRARY (already extracted -- do NOT duplicate) ## LIBRARY - chunk_id=1 [8L] src/index.js:1 -- Reexports custom hooks and React components from internal files so consumers can import them via this package entry point. - chunk_id=2 [42L] src/components/Header.css:1 -- Defines a sticky dark header bar layout using flexbox, styling the brand for focus accessibility, and setting up a horizontally spaced navigation button area. (skip) ### APPS (8 apps, 794 chunks total) ## App: 000027 - chunk_id=1 [21L] src/App.jsx:14 -- Defines the App component with persisted currentPage and isSignedIn state via useLocalStorage, plus navigate/signOut/signIn handlers updating both. - chunk_id=2 [28L] src/App.jsx:36 -- Maps the currentPage string to the corresponding React component, passing navigate (and signIn for auth-login), defaulting to Home. ## App: 000051

**Why extractable**: The underlying ` useSearchFilter` hook is already shared, but the *UI shell* around it (input + category control + count/empty messaging) is still duplicated across apps with only small behavioral differences. **Members**: - 000027::src/components/BrowseScreen.jsx :17-43::chunk_id=75 -- Renders a "Find a Deal " search UI with controlled input and category dropdown, populating options from categories. - 000051::src/components/JobsScreen/ JobsScreen.jsx:13-39::chunk_id=167 -- Renders a Jobs screen header with controlled search input and clickable category filter pills updating selected category. - 000053::src/Home.jsx:21-36::chunk_id=158 -- Renders a controlled search input and category dropdown, updating state on typing/ selection changes. - 000092::src/components/Search.jsx:1-7:: chunk_id=149 -- Initializes search filters ( search term + category selection defaulting to "All"). ### C2. App Shell / Page Layout (Header + main content + Footer) **Pattern**: Standardizes each app's toplevel layout by composing a shared Header, a main content region (page switch/routing), and a shared Footer. **Why extractable**: Even with shared `Header `/`Footer` components already extracted, the * shell composition* (main container, renderPage wiring, screen switching placement) is still duplicated across apps. **Members**: - 000027::src/App.jsx:110-142::chunk_id=59 -- Renders the app layout with a shared header /footer and conditionally shows Browse/Share/ Admin screens. - 000051::src/App.jsx:65-74::chunk_id=58 -Renders the app layout with Header ( navigation/auth props), main content from ` renderPage()`, and a Footer. - 000092::src/App.jsx:116-149::chunk_id=62 -- Wraps profile-related screen content with Header and a main layout region. (skip)

(skip) Identify the top-10 cross-app extraction candidates.

Assistant Response (with sample candidates) ### C1. Search+Category Bar (query + category + results count) **Pattern**: Renders a controlled search input plus a category selector, derives/filter results, and displays a count-based summary (often with an empty state).

H.3.2 Migration Candidates System Prompt You are a senior engineer migrating an app to use a shared utility library. Given (a) oneline summaries of every symbol in the library and (b) summaries of every chunk in ONE specific app, pick the TOP-K library symbols this app should adopt -- i.e., places where the app currently has its own implementation that the library symbol could replace. For each candidate, output exactly:

### A<n>. <lib symbol> **Library**: <lib_file>:<start>-<end>::< chunk_id=<id>> -- <lib summary> **Replaces in this app**: - <app_file>:<start>-<end>::<chunk_id=<id>> -- <reason> - ... (one or more places) Be conservative. If fewer than the requested number of strong matches exist, output only the strong ones. If NONE, output exactly ' NONE'.

User Prompt (with sample indices) ### Library (37 symbols) ## LIBRARY - chunk_id=11 [20L] src/hooks/useLocalStorage. js:15 -- Implements a React hook that syncs state with localStorage by reading/parsing an initial value and persisting updates as JSON with error-suppressed failures. - chunk_id=23 [28L] src/hooks/useSearchFilter. js:70 -- Memoizes and returns a filtered data array by lowercasing/trimming the search query, matching it against configured fields, and applying an optional category filter. (skip) ### Target App: 000027 (94 chunks) ## APP - chunk_id=160 [28L] src/App.jsx:1 -- Imports localStorage helpers and page components, then declares the app-level persistence approach. - chunk_id=162 [27L] src/App.jsx:64 -Manages and persists promotions and app state via localStorage with custom update logic. (skip) Pick the top-10 migration candidates.

imports localStorage helpers and owns the persistence approach (can be replaced by adopting the shared useLocalStorage hook). ### A2. useSearchFilter **Library**: src/hooks/useSearchFilter.js :70-97::chunk_id=23 -- Memoizes and returns a filtered data array by lowercasing/trimming the search query, matching it against configured fields, and applying an optional category filter. **Replaces in this app**: - src/components/BrowseScreen.jsx:1-18:: chunk_id=167 -- BrowseScreen initializes its own search/category state and performs filtering logic over promotions (directly matches the hook's responsibility). - src/components/BrowseScreen.jsx:17-43:: chunk_id=75 -- BrowseScreen builds the controlled "Find a Deal" search + category UI and derives counts from filtered results ( should instead consume the hook's derived categories + filtered list). (skip)

H.4

Extraction Trace

After each library extraction, the library-extraction agent writes a markdown document for every new or updated library symbol, recording where the symbol came from, why the pattern generalizes, and how to replace the original code with the library API. The file is cumulative with later rounds appending newly extracted symbols and revising existing entries whose lib-side implementation changed. The example below generalizes two independent localStorage usage patterns into a single useLocalStorage hook. Sample Extract Trace Entry ## library symbol: `useLocalStorage` **Module**: `src/hooks/useLocalStorage.js`

Assistant Response (with sample candidates) ### A1. useLocalStorage **Library**: src/hooks/useLocalStorage.js :15-34::chunk_id=11 -- Implements a React hook that syncs state with localStorage by reading/parsing an initial value and persisting updates as JSON with errorsuppressed failures. **Replaces in this app**: - src/App.jsx:64-90::chunk_id=162 -- App manages and persists promotions/app state via localStorage with custom update logic (can be replaced by the shared useLocalStorage contract). - src/App.jsx:1-28::chunk_id=160 -- App

**Sources** (tasks the pattern was generalized from) | Task | File | Original Symbol | |-----|-----|-----| | 000019 | App.jsx (L18-25, 102-119) | inline useState init + handler | | 000075 | ContactUs/ContactUs.jsx (L23-25) | inline localStorage get/set | **Why generalized** Both tasks read and write contact-submission data to localStorage with the same load-modify-save cycle. 000019 wraps the pattern in a React lazyinitializer state and a callback that appends

The same candidate after call-graph injection

to the stored array; 000075 directly calls localStorage.getItem and setItem from the submit handler. The common skeleton -- load JSON from a key, fall back to a default, persist updates -- is captured by this hook so that any component can declare `const [data, setData, clearData] = useLocalStorage(key, [])`.

### A1. NotificationBanner **Library**: src/components/NotificationBanner .jsx:24-52::chunk_id=44 -- Renders a typed notification alert with message text and an optional dismiss button [...] **Replaces in this app**: - src/NotificationBanner.jsx:1-18::chunk_id =63 -- The app defines its own simple notification banner component (green / red) [...] **Also refactor** (neighbors of src/ NotificationBanner.jsx): ^ Callers (import this file) : src/ AdminPage.jsx, src/SharePage.jsx v Imports (used by this file) : src/ NotificationBanner.css

**Apply guidance** Replace inline `useState(() => { try {...} }) ` + manual `localStorage.setItem` calls with `useLocalStorage(key, initialValue) `. The hook returns a state tuple where `setValue` automatically persists the serialised value. Apps no longer need `JSON.parse` / `JSON.stringify` / `try-catch` boilerplate.

Every entry has the same four parts, namely the library symbol with its module path, a Sources table keyed by task ID and file location, the justification under Why generalized, and the migration instructions under Apply guidance. H.5

Call-Graph Context

A file cannot be migrated in isolation. Other files import it, and they break if they are not updated too. We therefore append the related files to each migration candidate of Appendix H.3.2 (Section 3.3.2). No LLM is involved. We build a file-level dependency graph from the import statements of the application and the library. For each file the candidate cites, we then list the files that import it and the files it imports. Modules that only re-export are skipped, and each side is capped at eight files. In the candidate below, the library’s NotificationBanner replaces the application’s duplicated copy. Call-graph injection then appends the callers of that file (AdminPage.jsx and SharePage.jsx) and the file it imports (NotificationBanner.css), so the agent is asked to update those too. Long summaries are elided here, and arrows appear as ˆ and v. Migration candidate, as returned by the selector ### A1. NotificationBanner **Library**: src/components/NotificationBanner .jsx:24-52::chunk_id=44 -- Renders a typed notification alert with message text and an optional dismiss button [...] **Replaces in this app**: - src/NotificationBanner.jsx:1-18::chunk_id =63 -- The app defines its own simple notification banner component (green / red) [...]

I

Library Export Listings

We report the complete Super Library export inventory underlying the abstraction-quality analysis in Figure 4. Each table corresponds to one WebGenBench suite, which contains N = 8 related applications, and each row corresponds to one trial of a method variant. For every trial, we list all exported symbols together with their reuse rate, defined as the percentage of applications in the suite that import the symbol. Exports are sorted by reuse rate in descending order. We include low- and zero-reuse exports as well, since they reveal whether a method produces unused or overly specific library code in addition to broadly reused abstractions.

J

Responsible NLP Checklist Details

This appendix expands on the items listed in the Responsible NLP Checklist that did not fit in the main text. J.1

Scientific Artifacts

Artifacts we use. Our experiments rely on the following external artifacts: the WebGen-Bench benchmark (Lu et al., 2025), the PaperBench Code-Dev benchmark (Starace et al., 2025), the WebVoyager UI agent used as WebGen-Bench’s executable test runner (He et al., 2024), the mini-SWE-agent harness (Yang et al., 2024), the cocoindex-code code-indexing tool used by our Global Extract / Apply candidate selectors, and the Qwen-2.5-7B reference model used to compute MDL. We additionally call hosted LLM APIs (deepseek-v4-flash, gpt-5-mini, gpt-5.4-nano, Claude Opus 4.7) for code generation and judging. License information is summarized in Table 24.

Method

Trial

#

Exported symbols with reuse rate

NAIVE -I MPLICIT NAIVE -I MPLICIT NAIVE -I MPLICIT

T1 T2 T3

6 5 6

Footer (100%), Header (88%), ContactForm (62%), PillNav (50%), useLocalStorage (50%), SkillBar (25%). Footer (100%), Header (88%), ContactForm (62%), useLocalStorage (62%), SkillBar (25%). Footer (100%), ContactForm (50%), NavBar (50%), FilterGroup (38%), useLocalStorage (38%), SkillBar (25%).

NAIVE -WARD NAIVE -WARD NAIVE -WARD

T1 T2 T3

4 5 7

Footer (100%), Header (62%), ContactSection (38%), SkillsSection (25%). Footer (100%), Header (88%), ContactForm (62%), SkillsChart (25%), useLocalStorage (25%). Footer (88%), Header (62%), ContactForm (50%), Section (38%), loadStorage (38%), saveStorage (38%), SkillBar (25%).

SLA-F ULL

T1

13

SLA-F ULL

T2

SLA-F ULL

T3

Footer (100%), NavigationBar (100%), Section (100%), TagPill (62%), Hero (50%), useLocalStorage (50%), validateContactFields (50%), FilterBar (38%), saveSubmission (38%), ProgressBar (25%), createSubmission (25%), validateRequiredFields (25%), loadSubmissions (0%). 14 NavHeader (100%), FeatureCardGrid (62%), FormField (62%), HeroSection (62%), Tag (62%), useContactForm (62%), ProjectCards (50%), FilterGroup (38%), StatsGrid (38%), saveToStorage (38%), SkillBars (25%), loadFromStorage (25%), defaultContactValidator (12%), removeFromStorage (0%). 11 Footer (100%), ContactForm (75%), Header (62%), Section (62%), PillNav (50%), Timeline (50%), useLocalStorage (50%), NewsCard (38%), SkillBar (25%), FormField (12%), validateRequiredFields (12%).

Table 21: Complete Super Library export inventory for WebGen-Bench Suite 1. Reuse rate denotes the percentage of the eight applications in the suite that import each symbol. Method

Trial

#

NAIVE -I MPLICIT

T1

10

NAIVE -I MPLICIT

T2

NAIVE -I MPLICIT

T3

NAIVE -WARD NAIVE -WARD

T1 T2

NAIVE -WARD

T3

SLA-F ULL

T1

SLA-F ULL

T2

SLA-F ULL

T3

Exported symbols with reuse rate

Button (100%), FormField (88%), Card (75%), useLocalStorage (75%), ErrorMsg (62%), NavBar (50%), StatusPill (50%), SearchInput (38%), loadStorage (0%), saveStorage (0%). 10 useLocalStorage (100%), Button (88%), Card (88%), FormField (75%), KpiCard (75%), Footer (50%), NavBar (50%), SearchBar (38%), PageHeader (12%), DataTable (0%). 9 Footer (100%), Header (100%), NavBar (88%), Badge (62%), useLocalStorage (62%), Card (50%), loadStorage (38%), saveStorage (12%), StatCard (0%). Button (88%), Card (88%), useLocalStorage (62%), Footer (50%), Header (50%), NavBar (50%), Sidebar (25%). Button (100%), Card (88%), useLocalStorage (75%), FormField (62%), StatusPill (62%), StatCard (50%), Table (50%), NavTabs (38%), Alert (12%). 14 Button (88%), useLocalStorage (75%), Card (62%), StatCard (62%), Badge (50%), FormGroup (50%), NavBar (50%), DataTable (38%), PageHeader (25%), SearchBar (25%), Sidebar (25%), EmptyState (12%), loadData (0%), saveData (0%). 7 9

NavBar (88%), generateId (88%), useLocalStorage (88%), Badge (75%), EmptyState (75%), KpiCard (75%), Selector (75%), ErrorMessage (62%), formatCurrency (50%), updateItemById (50%), useFilteredList (50%), ProgressBar (38%), deleteItemById (38%), filterByKey (38%), formatDate (38%), FilterBar (25%), StepProgress (25%), formatDateTime (25%), seedLocalStorage (25%), todayISO (12%). 11 addItem (100%), useLocalStorage (100%), EmptyState (88%), NavBar (75%), sumBy (62%), formatCurrency (50%), updateItem (50%), useFilter (50%), formatDate (38%), toggleField (38%), removeByIndex (25%). 10 ControlledSelect (88%), NavigationBar (88%), StatCard (75%), useLocalStorage (75%), Badge (62%), EmptyState (50%), SearchFilterBar (50%), StatusMessage (38%), loadFromLocalStorage (12%), saveToLocalStorage (0%). 20

Table 22: Complete Super Library export inventory for WebGen-Bench Suite 2. Reuse rate denotes the percentage of the eight applications in the suite that import each symbol.

Consistency with intended use. All listed artifacts are released for open use in research on automated code generation, web agent evaluation, or language modeling. Our use — evaluating an LLM-based multi-agent coding system on the public task splits, without redistributing benchmark data, grader rubrics, or ground-truth code — is consistent with each artifact’s stated intended use. We do not modify any benchmark task descriptions or graders; we only adapt them into our suite format by sampling disjoint task subsequences (§4.1.1). Artifacts we create. The artifacts produced by this work — the source code of the system, the metric and evaluation result files behind every reported number, and the final-round application codebases together with the Super Libraries extracted from them — are released under the MIT license. The generated codebases are produced from benchmark

task specifications and are intended as evidence for the claims in this paper rather than as deployable applications. J.2

AI Assistants

We disclose the use of AI assistants in two distinct roles. As research subjects. LLMs and LLM-based coding agents are the object of study in this paper. Specifically, deepseek-v4-flash is used as the backbone for all compared agents, gpt-5.4-nano produces per-block code summaries inside our pipeline, gpt-5-mini serves as the appearance judge and the report parser, and Claude Opus 4.7 is used to render the reference layout descriptions provided to all methods. These usages are described in §4.1.2 and §4.2 and are integral to the experimental setup, not authoring aids.

Method

Trial

#

NAIVE -I MPLICIT

T1

NAIVE -I MPLICIT

T2

NAIVE -I MPLICIT

T3

Alert (100%), loadStorage (100%), saveStorage (100%), Footer (62%), FileInput (38%), SearchBar (38%), useFileUpload (25%), useLocalStorage (0%). 12 Alert (100%), FormField (100%), useLocalStorage (100%), validateRequired (50%), FilePicker (38%), Button (25%), SearchBar (25%), validateEmail (25%), validateMinLength (25%), Modal (12%), Pill (12%), Footer (0%). 8 useFormValidation (75%), Footer (62%), createKeyedStorage (50%), loadStorage (50%), saveStorage (50%), Chip (38%), FileUpload (38%), SearchFilter (38%).

Exported symbols with reuse rate

NAIVE -WARD NAIVE -WARD

T1 T2

8

NAIVE -WARD

T3

Header (100%), loadStorage (100%), saveStorage (100%), Footer (75%), FormField (75%). Button (62%), Footer (62%), FormField (62%), createAuthContext (62%), Modal (25%), useLocalStorage (12%), getStorage (0%), setStorage (0%). 6 loadJSON (100%), saveJSON (100%), Footer (62%), ImageUpload (38%), LoginForm (38%), RegisterForm (25%).

SLA-F ULL

T1

13

SLA-F ULL

T2

SLA-F ULL

T3

5 8

loadStorage (100%), saveStorage (100%), validateRequired (100%), Header (88%), MessageBanner (88%), useFilteredList (75%), Footer (62%), Pill (62%), EmptyState (50%), TabBar (38%), fileToDataURL (38%), validateMinLength (38%), renderPills (12%). 17 useLocalStorage (100%), useRouter (100%), validateRequired (100%), useFormError (88%), FormField (75%), NotificationBanner (75%), Pill (75%), validateAll (75%), EmptyState (62%), Footer (50%), TabBar (50%), useSearchFilter (50%), usePhotoUpload (38%), validateEmail (38%), getTodayDate (25%), useFieldErrors (25%), filterBySearch (12%). 11 FormField (100%), Card (88%), ErrorMessage (88%), loadFromStorage (88%), saveToStorage (88%), usePersistentList (88%), EmptyState (75%), useFilteredList (75%), Pill (62%), Grid (62%), useImageUpload (38%).

Table 23: Complete Super Library export inventory for WebGen-Bench Suite 3. Reuse rate denotes the percentage of the eight applications in the suite that import each symbol.

Artifact

License

Use

WebGen-Bench PaperBench WebVoyager mini-SWE-agent cocoindex-code Qwen2.5-7B

MIT MIT Apache 2.0 MIT Apache 2.0 Apache 2.0

eval suite eval suite UI runner harness indexing MDL ref.

Table 24: External artifacts and their licenses. All are permissive open-source licenses, and our use is consistent with each artifact’s intended purpose.

As research and engineering aids. During this project we used ChatGPT (GPT-5 family) and Claude (Opus 4.7) as auxiliary tools in three bounded roles. They sanity-checked the logical flow and consistency of arguments in draft sections, stress-tested research ideas and surfaced counterexamples or related work we might have missed, and assisted with implementation-level code generation such as boilerplate analysis scripts and plotting code. All scientific claims, experimental designs, analyses, and final interpretations are authored and verified by the human authors; AI assistants did not autonomously produce any of the experimental results, ablations, or conclusions reported in this paper.

Figure 7: All eight Content-Presentation tasks under trial 1. Each task is shown as a (without library, with library) pair; the eight tasks are tiled as four rows of two tasks. UI-test accuracy and appearance grade are reported below each pair.

Related documents

• Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase#794113
• Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase#790094
• Can Agents Design Libraries for Agents?#1131931
• Can Agents Design Libraries for Agents?#1122372
• To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study#168373