A plugin architecture is a way of building a program so that much of its functionality can be added from the outside, by separate units of code that the program loads and runs without being recompiled. The host application defines extension points: well-defined places where additional behavior can be attached. Third parties write plugins that contribute to those points, and the host discovers and activates them at runtime. This lets an editor or IDE grow new languages, tools, and views without anyone touching its core source.
The Eclipse platform is a canonical example, and its architecture documentation states the model directly: plug-ins are structured bundles of code or data that contribute functionality to the system, and plug-ins can define extension points, well-defined places where other plug-ins can add functionality. Eclipse takes this to its logical conclusion: even its Java development tools and plug-in development environment are themselves plug-ins built on the same base platform that third parties use, so there is no privileged core feature set that extensions cannot match. The underlying runtime is built on the OSGi module system, which manages each plug-in as a bundle with its own lifecycle and dependencies.
Visual Studio Code follows the same philosophy with a different mechanism. Its extension API documentation explains that almost every part of VS Code, from the user interface to the editing experience, can be customized and enhanced through the Extension API, and that many of VS Code’s own core features are built as extensions using the same public API available to third-party developers. Extensions contribute through declared contribution points and run in a separate extension host process, which isolates them from the editor’s main thread so that a slow or crashing extension does not freeze the editor.
Isolation and sandboxing are recurring themes in robust plugin systems. Running extensions in a separate host, restricting what APIs they can call, and declaring their capabilities up front all limit the damage a faulty or malicious plugin can do, and they let the host evolve its internals while keeping the published extension interface stable. The contrast is the older Emacs model, where packages are loaded into the same process and can redefine almost anything, which is maximally flexible but offers little isolation.
The payoff of a plugin architecture is an ecosystem. By turning the editor into a host with stable extension points, the maintainers let a much larger community supply language support, themes, debuggers, and tooling than any single team could build. This is why a relatively small editor core can support thousands of languages and workflows: the architecture, not the core, carries most of the breadth.