Could AI Replace Package Managers? From npm to a Prompt Registry

A Russian tech writer on Habr has broken down an idea proposed by developer Marcelo Emmerich in a post on Medium: replace traditional package managers like npm with a "prompt registry," a system where library authors publish not finished code but prompts for an AI that generates a self-contained implementation directly on the developer's side.

What the "prompt registry" idea is about

As Emmerich envisions it, instead of installing a ready-made library via npm install, a developer pastes the library author's prompt into their AI tool, which generates the functionality on the spot, tailored to the specific programming language and project. As the Habr author notes, this approach has an appealing logic: if code is generated anew for each task, transitive dependencies (libraries pulled in by another library), supply chain attacks through compromised packages, and version conflicts between a project's dependencies all disappear. These are classic pain points of modern development.

Why it is naive, yet not baseless

The Habr author calls the idea naive but acknowledges that it points to real problems. Supply chain attacks, meaning the injection of malicious code through a compromised dependency deep in the package tree, are a serious threat that is hard to control: working out what exactly is inside all the transitive dependencies of a large project is practically impossible by hand. The idea of "generate exactly what you need and nothing extra" is also attractive in its own way, since it promises relief from the bloat of modern applications, which pull in tens of megabytes of unused code through dependency chains.

Key points of the analysis:

• The original idea comes from Marcelo Emmerich, in a post published on Medium.
• The proposed replacement for package managers is a "prompt registry" for generating code on the spot.
• The claimed benefits are no transitive dependencies, protection from supply chain attacks, and no version conflicts.
• The Habr author's counterargument: complexity (TLS, JSON parsing, Unicode) does not go away, it just stops being called a "dependency".

What the idea overlooks

The Habr author's main counterargument concerns the nature of software complexity. Even if every developer regenerates basic functionality from scratch (TLS encryption, JSON parsing, correct Unicode handling), that complexity does not vanish. It moves from a public library, written once and vetted many times by the community, into thousands of parallel, independently generated implementations, each potentially carrying its own bugs and vulnerabilities. In other words, abandoning the concept of a "dependency" does not eliminate the underlying task of implementing complex, error-prone logic. It only changes who solves it, and when.

This brings back a fundamental trade-off of open-source ecosystems: centralized, widely used libraries, for all their supply chain risks, benefit from scale. Thousands of eyes review the same code, and bugs are found and fixed once for everyone. The "generate anew for every project" model, by contrast, gives up that collective testing in exchange for customization and no external dependencies. It is unclear whether the trade pays off, especially for critical infrastructure logic such as cryptography or network protocol parsing, where the cost of a mistake is high and rare edge cases are hard to anticipate in a single code generation.

The npm ecosystem, which Marcelo Emmerich mentions in his post, brings together millions of packages and remains the world's largest registry for JavaScript development. It is also one of the most frequent targets of supply chain attacks, in which attackers publish malicious versions of popular or similarly named packages, hoping developers or automated build systems will install them by accident. It is precisely this years-long experience fighting such incidents that explains why abandoning shared code altogether in favor of generating it "from scratch" sounds appealing to part of the community, even if, as the Habr analysis shows, it moves the complexity problem to a new, less battle-tested place rather than solving it.