arxiv:2608.29310

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

Published on Aug 29

· Submitted by

Daegyu Sung on Sep 1

KAIST AI

Upvote

Authors:

Daegyu Sung ,

Abstract

A shared-library agent framework reduces redundancy and structural erosion when sequentially generating related applications by guiding cross-application code extraction and migration.

Generated by thinkingmachines/Inkling-Small

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.

View arXiv page View PDF Project page GitHub 0 Add to collection

Community

Sung10230

Paper author Paper submitter about 5 hours ago

An agent writes several related apps in sequence. Rather than letting each app reimplement the same components, SLA extracts what they share into a library and migrates the earlier apps onto it as the library grows.

On WebGen-Bench, against the same eight apps generated independently: 38% less redundant code, 9% fewer lines, and patches 3.7x smaller when one new requirement lands on every app, at unchanged accuracy. PaperBench goes the same way with smaller margins.

Project Page: https://sbigstar0310.github.io/super-library-agent/
Code: https://github.com/sbigstar0310/super-library-agent

O96a

about 1 hour ago

Versioning is where multi-app agents usually fall apart. The setup looks clean when all apps move together, but the real world has one app pinned to an old API while another needs the breaking change. Does the agent refactor all N apps in one pass, or does it quietly fork the library and start the copy-paste pile? That's the difference between a shared library and technical debt with a nice name. I'd want to see the eval include a version-skew scenario — one app on v1, one on v2, and a change that touches both. If the agent can't keep them in sync without forking, the maintenance story doesn't hold up in prod.

Sung10230

Paper author 22 minutes ago

Thanks, good point. Strictly speaking it sits outside our problem setting: we don't consider pinning one app to an old version of the library. The agent has write access to every codebase and migrates all of them to the current library each round, so the skew never comes up.

Thinking about what our agent actually does when func_v1() gets a breaking change, I'd split it three ways depending on how big the v1 to v2 diff is.

If the diff is large, every app touching the changed component gets migrated. Not all N though. We condition on the call graph, so only the apps that actually import the changed part get rewritten. And I'd argue the large migration is the correct outcome rather than a failure mode. These are a related suite of apps, so a big diff in a shared component is itself evidence that they all need the change. Think of a cash handling flow updated across N banking apps, propagating it is the whole point.

If the diff is small and confined to a couple of functions, that's where your fork case is most likely, func_v1() and func_v2() sitting next to each other.

And if the diff is something one component can absorb, adding a hover state to a button, that kind of thing, the agent tends to merge them into a single func covering both behaviors.

What your scenario (app pinned to an old API while another needs the breaking change) changes is that pinning takes the first option away. If App1 genuinely can't move, the diff size stops deciding anything and you're left with either the fork or the merged function.

On the merged one, I don't actually think it's a bad outcome. Real UI libraries look like this anyway, a button accumulates radius, hover, color, align, and that's a mature API rather than a broken one. To me that's the library growing up as it absorbs requirements from N apps, which is closer to what we want than the fork case.

The open part is whether that growth stays maintainable, and there I think you've found something we're missing. We have no notion of selectively revising or deprecating a library API after library construction and migration. Real libraries have a deprecation cycle so a compat option can eventually be removed. So the merged component keeps widening and nothing ever prunes it.