Agent Plugins Are Maintained Software: 8.8x Growth and a New Kind of Coupling

Paper: 2608.28497 Authors: Ahmed Hereiz, Yingzhe Lyu, Hao Li, Bram Adams, Ahmed E. Hassan Categories: cs.SE, cs.AI

The Gap

AI coding agents are increasingly extended through plugin marketplaces, and these repositories were empirically unexplored. That is a gap with a specific shape, because the artifacts differ from ordinary packages in a way that makes the usual software-engineering intuitions unreliable.

Traditional packages deliver functionality through source code. Agent plugins deliver functionality through a combination of natural-language instruction files, scripts, and configuration files. So the thing that determines behaviour is partly prose. That raises a question the field had not answered: are these maintained artifacts that co-evolve across components, or one-off artifacts that developers write once and do not need to revisit?

The distinction is not academic. If plugins behave like maintained software, then the whole apparatus of software engineering — versioning, dependency tracking, review, testing, release hygiene — is relevant to them. If they are one-off, most of that apparatus is overhead. And if they are a third thing, then the field’s existing tooling is aimed at the wrong object.

   WHAT MAKES AGENT PLUGINS DIFFERENT

   traditional package:  functionality delivered via SOURCE CODE
        -> the thing determining behaviour is code

   agent plugin:         functionality delivered via a
                         COMBINATION of
                           natural-language INSTRUCTION FILES
                           scripts
                           configuration files
        -> the thing determining behaviour is PARTLY PROSE

        |
        v
   [THE UNANSWERED QUESTION]
     are plugins MAINTAINED artifacts that co-evolve
     across components?
     or ONE-OFF artifacts, written once and never revisited?
        |
        v
   WHY IT DECIDES THE TOOLING
     if maintained -> versioning, dependency tracking,
                      review, testing, release hygiene all apply
     if one-off    -> most of that apparatus is pure overhead
     if a THIRD thing -> existing tooling aims at the wrong object

The Increment

One sentence: Before this paper, agent plugin marketplaces had no empirical account; after it, a study of 1,926 repositories, 8,351 plugins and 77,773 commits shows rapid growth, heavy agent authorship, and a maintenance dependency between prose and code that traditional software engineering does not have.

Core Mechanism

The scale is the foundation: 1,926 repositories hosting Claude Code plugin marketplaces, 8,351 plugins, 77,773 commits across 2,018 marketplaces. That is enough to make the structural findings general rather than anecdotal.

The marketplace is expanding rapidly — plugin-touching commit activity growing 8.8× over six months after the October 2025 launch. And the composition is concentrated: plugins targeting software engineering tasks account for 61.3% of all plugins. So the ecosystem is growing fast and is mostly about the thing the researchers study for a living.

Development is predominantly feature-driven. Feature commits occur at 39.6%, more than twice the rate of conventional open source software at 17.2%. That asymmetry is informative about what these artifacts are for: a community mostly adding new capabilities rather than fixing, refactoring or paying down debt. It is consistent with a young, rapidly expanding ecosystem where coverage matters more than consolidation.

Claude co-authors 34.9% of all commits. An agent writing a third of the commits in a plugin ecosystem is a notable fact about how this software is produced, and it bears on the maintenance question: if the author is often an agent, the cost of maintaining prose-plus-code may be lower than the traditional intuition suggests.

Four commit types carry substantially different meanings in plugin repositories than in traditional software: docs, perf, style and refactor. This is a measurement-validity finding, and it matters for anyone planning to study these ecosystems with established tooling — a taxonomy calibrated on ordinary repositories misreads what the categories mean here.

And then the result the paper is built around. Most component types evolve independently — which supports the one-off reading for those components — but within skills directories, natural-language instruction files and implementation scripts co-evolve at above-chance rates, with 78% of co-changes being functionally coupled. This is reported as a new class of maintenance dependency not observed in traditional software engineering.

The finding is precise enough to act on. It is not that plugins are maintained in general; it is that a specific pairing — the prose that instructs and the code that implements — moves together, and moves together for functional reasons. That is the coupling that does not exist when behaviour is determined by code alone, because in that case there is no prose to fall out of sync with.

   SCALE AND COMPOSITION

   1,926 repos | 2,018 marketplaces | 8,351 plugins | 77,773 commits
     plugin-touching commit activity: 8.8x growth in SIX MONTHS
       (after the October 2025 launch)
     SWE-targeting plugins: 61.3% of all plugins

   HOW DEVELOPMENT LOOKS
     feature commits 39.6%  vs  17.2% in conventional OSS
        -> more than 2x, predominantly FEATURE-DRIVEN
     Claude co-authors 34.9% of ALL commits
     docs / perf / style / refactor carry SUBSTANTIALLY
       DIFFERENT MEANINGS here than in traditional software
        -> a measurement-validity problem for existing tooling

   THE COUPLING
     MOST component types evolve INDEPENDENTLY
        -> supports the "one-off artifact" reading for those
     BUT inside skills directories:
        natural-language INSTRUCTION FILES
          and IMPLEMENTATION SCRIPTS
        co-evolve at ABOVE-CHANCE rates
        78% of those co-changes are FUNCTIONALLY COUPLED
        -> a NEW class of maintenance dependency, not observed
           in traditional software engineering

Think of it as a recipe card stapled to the kitchen equipment. In most kitchens the equipment and the recipes are separate concerns: you can buy a new oven without editing your recipes, and you can rewrite a recipe without touching the oven. That is the “most component types evolve independently” result — and it is why the one-off reading is not simply wrong. But if a recipe says “fold the batter using the stand mixer’s dough hook” and the mixer is replaced with one that has no dough hook, the card and the machine must change together, because the instruction refers to the equipment. That is the skills-directory coupling: the prose and the code are functionally bound, and 78% of their joint changes are for that reason rather than coincidental. The practical consequence is that version-control tooling treating a documentation edit and a code edit as independent events will mis-summarise what happened.

Key Concepts

• Prose plus code as the delivery mechanism: plugin behaviour is determined by instruction files, scripts and configuration together. It is the structural difference from ordinary packages and the reason existing maintenance intuitions cannot be assumed to transfer.
• The one-off versus maintained question as a tooling decision: whether plugins are revisited determines whether versioning, dependency tracking and review are relevant or overhead. The paper’s answer is mixed, and the mix is the finding — most components independent, one component pair coupled.
• Prose-code functional coupling: 78% of joint changes between instruction files and implementation scripts are functionally coupled. It is a maintenance dependency with no analogue in code-only software, because there is no prose to synchronise.
• Commit-taxonomy validity failure: docs, perf, style and refactor mean substantially different things here. Measuring this ecosystem with a taxonomy calibrated on traditional repositories will systematically misclassify activity.

Framework Shift

Before (unexplored, intuitions borrowed from packages):
  "agent plugins are like packages, but partly prose"
  -> assume either maintained-software hygiene or one-off
  -> measure with conventional commit taxonomies
  -> no empirical basis for either practice

After (measured, with a mixed answer):
  1,926 repos / 8,351 plugins / 77,773 commits analysed
  -> rapid growth (8.8x), feature-driven (39.6%), agent-authored (34.9%)
  -> MOST components evolve independently
  -> prose and implementation script co-evolve, 78% functionally coupled
  -> a new maintenance dependency class
  -> and conventional commit categories mean something else here

From treating agent plugins as a variant of ordinary packages, to finding a mixed maintenance profile with one genuinely new dependency class, the core shift is that these artifacts are neither fully maintained software nor one-off scripts, and their tooling needs to reflect the specific coupling.

Expert Assessment

Problem choice: Very good, and it takes the empirical route where the field has been speculating. Agent plugin ecosystems are growing fast enough that their maintenance properties will matter, and asking the question before establishing the ecosystem’s conventions is the right order — the answer shapes what conventions should be.

Method maturity: This is a measurement study, and its quality is in the scale and the specificity of its conclusions. Nearly two thousand repositories and over seventy thousand commits is enough for structural claims, and the design does something careful: it does not force a single answer to “maintained or one-off”, but reports that most components evolve independently while one specific pair is structurally coupled. The 78% functional-coupling figure is the contribution, because it quantifies a dependency rather than asserting one exists.

Experimental integrity: The finding that four commit types carry different meanings is a validity check on the study’s own instruments, and reporting it is to the authors’ credit — it warns anyone replicating the work with standard taxonomies that the labels will not mean what they expect. The 34.9% co-authorship figure is reported as a fact about production without being over-interpreted. The honest limitation is that co-evolution measured through commit co-occurrence is evidence of coupling, not proof that the components could not be maintained separately; the 78% functional-coupling rate is what addresses that, and it depends on the classification of “functional”.

Writing quality: The question is posed in a form that admits a non-dogmatic answer — maintained artifacts, or one-off — and the paper’s willingness to answer “mostly the first, one exception” is what makes it useful. The abstract is dense with numbers but each supports a distinct claim. A worked example of one instruction file and its script changing together would make the new dependency class concrete for readers who will not read the statistics.

Verdict: strong accept — a large-scale empirical grounding for a fast-growing ecosystem, with a mixed answer that is more useful than either extreme and one finding that identifies a genuinely new class of maintenance dependency.

Takeaways

• Establish an ecosystem’s maintenance profile before importing conventions. Whether these are maintained artifacts decides whether release hygiene is necessary or overhead.
• Watch for prose-code coupling in your own agent tooling. If instruction files and scripts refer to each other, they must be versioned together, and treating them as independent changes will misrepresent history.
• Do not measure a new artifact type with an old taxonomy. Docs, perf, style and refactor mean something different in plugin repositories, so automated classification will be systematically wrong.
• Read the co-authorship figure as a production fact. With roughly a third of commits agent-authored, the cost of maintaining prose plus code is lower than the traditional intuition would suggest.