dshbase
中文

Blog · Concept

Everything-is-a-plugin vs plugin fatigue

August 14, 2026 · dshbase

The sharpest line in DeepSeek Harness's Hacker News discussion is about its plugin architecture. Supporters call it a genuinely new thing; critics predict plugin fatigue and eventual chaos. Both have a point — so instead of arguing in the abstract, we spent time actually testing the ecosystem. On dsh 0.1.0-rc.6, we installed and ran 101 community plugins. The results cut through the rhetoric on both sides.

Why it's not VS Code's plugin system

VS Code has thousands of extensions, but they bolt onto a fixed core: the editor, the debugger, the terminal. You can't replace the core. Claude Code is the same — you customize Skills and MCP, but the product shell is fixed.

DeepSeek Harness inverts this. The core itself — the agent loop, the tools, the UI, the sandbox — is made of plugins. The only fixed piece is Cordis, a kernel that does nothing but load, unload, and resolve plugin dependencies. That's not "plugins on a product"; it's "the product is plugins." The architecture is a real difference, not a marketing relabel.

The "Android of agents" narrative

The closest analogy is Android vs iPhone. Android made the OS modular so OEMs and users could swap parts; iPhone kept a sealed whole. DSH's bet is that agents go the Android way — a common kernel with swappable capabilities — rather than the sealed-appliance way. Whether that bet pays off is the open question, and our 101-plugin audit is one data point toward an answer.

The legitimate concern: plugin fatigue

The critics aren't wrong. Too much modularity has real costs — and we can now name them with numbers instead of vibes:

  • Choice paralysis — if everything is a plugin, what do you install first? Our audit found 101 plugins spread across categories, and only 11 install cleanly from npm and work out of the box. A newcomer can't tell which ten without checking every card.
  • Compatibility drift — plugins that break when dependencies change. This isn't hypothetical; it's the top reason for install failure in our testing.
  • Quality variance — an open ecosystem means uneven quality. 4 plugins need a Web/TUI runtime you must run separately, and 3 failed to install outright.

And the biggest number: 81 of 101 plugins never shipped to npm at all — they exist only as GitHub source, installed with dsh plugin add github:owner/repo. That's simultaneously the ecosystem's strength (anyone can publish a repo) and its weakness (there's no gatekeeper, no versioning discipline, no install guarantee).

The failure modes we actually hit

"Compatibility drift" and "quality variance" sound abstract. Here's what they look like in a terminal, all reproduced on dsh 0.1.0-rc.6:

  • ERR_PNPM_FETCH_404 — your npm registry mirror lags behind the official one, so a just-published package returns 404. A distribution problem, not a plugin problem, but it blocks installs all the same.
  • ERR_REQUIRE_ESM — the plugin was compiled to CommonJS but depends on ESM-only packages like @deepseek-ai/dsh-tools. The plugin must ship as ESM ("type": "module").
  • Missing dsh.bundle manifest — the package installs silently as a plain dependency and never activates. The most common silent failure: it looks installed but the agent never loads it.
  • cannot get property "systemPrompt" without inject — plugin code reads ctx.systemPrompt without declaring inject: ["systemPrompt"]. A plugin bug you report to the author with that exact message.

Every one of these has a one-line fix, documented in the troubleshooting guide. The point for this debate is different, though: this is what "plugin fatigue" concretely means. It's not that modularity is bad — it's that modularity without curation shifts the debugging burden onto the user.

DSH's answer: presets, then plugins

DSH's answer so far is presets: the four built-in modes bundle sensible plugin sets so you don't start from zero. You only reach for raw plugins when you need to. That's the pragmatic middle — modular underneath, sensible defaults on top. Our audit supports that ordering: start with a preset, reach for the curated subset in the plugin directory (where each card shows verified test status and the exact install command), and treat the long tail of GitHub-source repos as a research area, not a starter kit.

The honest take

The plugin architecture is genuinely different from VS Code and Claude Code — but "different" doesn't automatically mean "better." The real test is whether presets plus a curated community keep the chaos at bay while the composability pays off. Our numbers say the composability is real (a live distribution channel that grew to 101 plugins fast), but the quality tail is long (81 GitHub-only, several needing a UI runtime, several failing outright). Watch the ecosystem: it'll decide this argument faster than any blog post — and so far it's a genuinely new architecture with a genuinely messy surface.

FAQ

Is "everything is a plugin" just VS Code with extra steps? No. In VS Code, the editor core is fixed and extensions orbit it. In DSH, the agent loop, tools, sandbox, and UI are themselves plugins on a minimal kernel. The difference is what can be replaced — in DSH, everything.

Should I install plugins from GitHub or stick to npm? Start with npm packages marked verified in the plugin directory. GitHub-source plugins (dsh plugin add github:owner/repo) work, but they're where we saw the most failures and the most allowBuilds build prompts.

Is plugin fatigue a real risk or just a hot take? It's real, but it's a curation problem, not an architecture problem. The fix is presets and a curated directory — both of which DSH ships.

Related: the architecture deep dive.

All articles →