Skip to content

Software Supply Chains are Dead: Use-Case-Oriented Regeneration

🕒 Published (v1): 2026-07-14 17:58 UTC · Source: Arxiv · link

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

This paper proposes use-case-oriented regeneration, a software sourcing paradigm in which an agentic workflow synthesizes only the dependency functionality a repository actually exercises, replacing full third-party packages with narrow, locally owned implementations. Evaluated across 180 JavaScript/TypeScript repository–dependency pairs, the approach achieves 99.8% behavioral preservation while reducing exported API surface by 93%.

Problem

Modern dependency reuse suffers a granularity mismatch: downstream repositories adopt, validate, and maintain entire upstream packages to obtain a small behavioral slice, inheriting transitive vulnerabilities, maintenance obligations, and supply-chain attack exposure. Existing mitigations (debloating, tree shaking, vendoring, full regeneration à la HARP/Lexo) either still rely on the upstream artifact as their starting point or target a general 1-to-1 package equivalent rather than the repository-specific behavioral slice.

Method

The unit of analysis is the repository–dependency pair \((R, P)\). Rather than seeking a replacement \(P'\) that is fully semantically equivalent to \(P\), the method seeks a local implementation \(L_{R,P}\) satisfying:

\[\pi_{O_R}(L_{R,P}) \equiv \pi_{O_R}(P)\]

where \(O_R\) is the observation context—the set of calls, inputs, and execution paths through which \(R\) exercises \(P\)—and \(\pi_{O_R}\) projects package behavior onto that observable slice.

The agentic workflow (Claude-based) follows three steps per pair: 1. Baseline establishment — clone repo at fixed revision, install deps, run validation artifacts (tests, build, linter); pairs that fail baseline are excluded. 2. Agentic regeneration — agent inspects repository context, identifies first-party call sites for the target dep, generates local replacement code, updates call sites, removes the dependency declaration, and iterates on validation failures. 3. Re-validation — rerun baseline checks; measure feasibility, behavioral preservation, and API-surface footprint delta.

Nine npm packages spanning small utilities (nanoid, change-case, chalk), medium libraries (express, semver, postcss), and large packages (lodash, axios, zod) were evaluated at 20 repositories each.

Key Contributions

  • Formal definition of use-case-oriented regeneration as a projection problem targeting repository-observed equivalence rather than full package equivalence.
  • Empirical feasibility study across 180 repository–dependency pairs demonstrating the paradigm is actionable today.
  • Characterization of three primary failure modes: semantic/edge-case mismatches, class identity mismatches (instanceof failures), and deep framework integrations.
  • A research agenda covering behavioral confidence, provenance metadata, refresh practices, and decision frameworks for when regeneration is appropriate.

Results

  • 99.8% aggregate validation pass rate post-regeneration (64,477 / 64,634 checks passing).
  • 166/180 pairs achieved perfect behavioral preservation (all baseline checks pass).
  • 93.1% average reduction in exported API surface (original avg. 82.1 exports → 5.6 regenerated exports).
  • Per-dependency perfect-preservation rates: nanoid 20/20, zod 20/20; lodash worst at 16/20 (104 failed checks).
  • Highest API-surface reductions: zod −98.3%, change-case −97.1%, postcss −96.0%; lowest: express −70.9%, nanoid −73.0%.
  • 14 failed pairs; failures concentrated in lodash (104 of 157 total failed checks).

Limitations

  • Behavioral preservation is measured only against existing repository test suites; passing weak or flaky tests may hide semantic deviations or falsely flag broken replacements.
  • Evaluation is limited to JavaScript/TypeScript (npm) — generalizability to other ecosystems (PyPI, Maven, Cargo) is unconfirmed.
  • The agentic workflow is illustrative, not prescriptive; fully automated dependency removal is not recommended without human review.
  • Regenerated replacements capture a point-in-time slice and do not automatically inherit upstream security fixes, API clarifications, or edge-case corrections — requiring an explicit refresh practice.
  • The study does not address maintainability or auditability of generated code beyond surface-area reduction.
  • Complex framework behaviors (middleware arity, mock interceptors, prototype identity) remain out of reach for the current agent.

Relevance to Harnesses / Meta-Harnesses

This paper is directly relevant because the regeneration workflow is itself an agentic meta-harness: a multi-step orchestration loop that inspects a repository, drives code synthesis, rewrites call sites, and iterates against a validation harness (test suite + build + linter) as its feedback signal. The three-phase pipeline (baseline → agentic regeneration → re-validation) is a canonical harness pattern where the agent's loop is gated on structured pass/fail signals from an external validation executor. For researchers tracking harness design, the paper surfaces an important principle: the validation artifact quality is the binding constraint on what a harness can guarantee — a finding with direct implications for harness design in any agentic code-generation pipeline.