Can AI replace package managers? From npm to a prompt registry

A Russian technology author on Habr analyzed an idea proposed by developer Marcelo Emmerich in a post on the Medium platform: replace traditional package managers like npm with a "prompt registry" — a system where library authors publish not ready-made code, but prompts for AI to generate self-contained implementation directly on the developer's side.

What Is the "Prompt Registry" Idea?

According to Emmerich's concept, instead of installing a ready-made library via npm install, a developer inserts the prompt from the library author into their AI tool, and it generates an implementation tailored to the specific programming language and project features. As the Habr author notes, such an approach has an attractive logic: if code is generated fresh each time for a specific task, then transitive dependencies disappear (libraries that another library brings with it), supply chain attacks through compromised packages, and version conflicts of different dependencies in one project — classic pain points of modern development.

Why This Is Naive Yet Not Without Merit

The Habr author calls the idea naive but acknowledges it points to real problems. Supply chain attacks — injecting malicious code through a compromised dependency deep in the package tree — is indeed a serious and hard-to-control threat: understanding what exactly is contained in all transitive dependencies of a large project is practically impossible manually. The idea of "generate exactly what you need and nothing extra" is also attractive in its own way — it promises liberation from the bloat of modern applications, pulling dozens of megabytes of unused code through dependency chains.

Key points of the analysis:

• Author of the original idea — Marcelo Emmerich, post published on Medium platform.
• Proposed replacement for package managers — "prompt registry" for generating code on the fly.
• Claimed advantages of the idea — absence of transitive dependencies, protection from supply chain attacks, absence of version conflicts.
• Habr author's counterargument — complexity (parsing TLS, JSON, Unicode) does not disappear, it just stops being called a "dependency".

What This Idea Does Not Account For

The main counterargument that the Habr author brings up concerns the nature of software complexity: even if every developer generates a fresh implementation of basic functionality — TLS encryption, JSON format parsing, correct Unicode handling — this complexity does not disappear. It simply shifts from a publicly available, once-written and repeatedly verified by the community library into thousands of parallel, independently generated implementations, each potentially containing its own bugs and vulnerabilities. In other words, rejecting the concept of "dependency" as such does not eliminate the task itself — implementing complex and error-prone logic — it merely changes who solves it and when.

This returns to a fundamental compromise of open source ecosystems: centralized, widely-used libraries, despite all supply chain risks, benefit from the scale effect — thousands of eyes review the same code, bugs are found and fixed once for everyone. The model of "generate fresh for each project," conversely, loses this collective testing in exchange for customization and absence of external dependencies — and it is unclear whether this trade-off pays for itself, especially for critical infrastructure logic like cryptography or network protocol parsing, where the price of error is high and rare edge cases are hard to anticipate from a single code generation.

The npm ecosystem, which Marcelo Emmerich mentions in his analysis, unites millions of packages and remains the world's largest registry for JavaScript development — and simultaneously one of the most frequent targets of supply chain attacks, when attackers publish malicious versions of popular or similarly-named packages hoping they will be accidentally installed by developers or automated build systems. It is precisely this years-long experience of fighting such incidents that explains why the idea of completely rejecting shared code in favor of generation "from scratch" sounds attractive to part of the community, even though, as the Habr analysis shows, it transfers the problem of complexity to a new, less-tested place rather than solving it.