Сможет ли AI заменить менеджеры пакетов? От npm к реестру промптов

Российский технологический автор на Habr разобрал идею, предложенную разработчиком Марсело Эммерихом (Marcelo Emmerich) в посте на платформе Medium: заменить традиционные менеджеры пакетов вроде npm «реестром промптов» — системой, где авторы библиотек публикуют не готовый код, а промпты для ИИ, генерирующие самодостаточную реализацию прямо на стороне разработчика.

В чём суть идеи «реестра промптов»

По замыслу Эммериха, вместо установки готовой библиотеки через npm install разработчик вставляет промпт от автора библиотеки в свой ИИ-инструмент, и тот на месте генерирует реализацию функциональности — подогнанную под конкретный язык программирования и особенности проекта. У такого подхода, как отмечает автор Habr, есть привлекательная логика: если код каждый раз генерируется заново под задачу, то исчезают транзитивные зависимости (библиотеки, которые тянет за собой другая библиотека), атаки на цепочку поставок (supply chain attacks) через скомпрометированные пакеты и конфликты версий разных зависимостей одного проекта — классические болевые точки современной разработки.

Почему это наивное, но небезосновательное предложение

Автор Habr называет идею наивной, но признаёт, что она указывает на реальные проблемы. Атаки на цепочку поставок — то есть внедрение вредоносного кода через скомпрометированную зависимость в глубине дерева пакетов — действительно серьёзная и трудноконтролируемая угроза: разобраться, что именно содержится во всех транзитивных зависимостях крупного проекта, практически невозможно вручную. Идея «сгенерировать именно то, что нужно, и ничего лишнего» тоже по-своему привлекательна — она обещает избавление от раздутости современных приложений, тянущих через цепочки зависимостей десятки мегабайт неиспользуемого кода.

Ключевые тезисы разбора:

• Автор оригинальной идеи — Марсело Эммерих, пост опубликован на платформе Medium.
• Предлагаемая замена менеджерам пакетов — «реестр промптов» для генерации кода на месте.
• Заявленные преимущества идеи — отсутствие транзитивных зависимостей, защита от supply chain атак, отсутствие конфликтов версий.
• Контраргумент автора Habr — сложность (парсинг TLS, JSON, Unicode) никуда не исчезает, а лишь перестаёт называться «зависимостью».

Что не учитывает эта идея

Главный контраргумент, который приводит автор Habr, касается природы сложности программного обеспечения: даже если каждый разработчик будет генерировать реализацию базовой функциональности заново — TLS-шифрование, разбор формата JSON, корректную обработку Unicode, — эта сложность никуда не денется. Она просто переместится из общедоступной, единожды написанной и многократно проверенной сообществом библиотеки в тысячи параллельных, независимо сгенерированных реализаций, каждая из которых потенциально содержит собственные баги и уязвимости. Иными словами, отказ от концепции «зависимости» как таковой не устраняет саму задачу — реализовать сложную и легко ошибающуюся логику, — а лишь меняет то, кто и когда её решает.

Это возвращает к фундаментальному компромиссу экосистем открытого кода: централизованные, широко используемые библиотеки при всех рисках цепочки поставок выигрывают за счёт эффекта масштаба — тысячи глаз проверяют один и тот же код, баги находят и чинят один раз для всех. Модель «генерируй заново для каждого проекта», напротив, теряет это коллективное тестирование в обмен на кастомизацию и отсутствие внешних зависимостей — и неизвестно, окупается ли этот обмен, особенно для критичной инфраструктурной логики вроде криптографии или парсинга сетевых протоколов, где цена ошибки высока, а редкие граничные случаи трудно предугадать при однократной генерации кода.

Экосистема npm, которую в своём разборе упоминает Марсело Эммерих, объединяет миллионы пакетов и остаётся крупнейшим в мире реестром для JavaScript-разработки — и одновременно одним из самых частых объектов атак на цепочку поставок, когда злоумышленники публикуют вредоносные версии популярных или похожих по названию пакетов в расчёте на то, что их случайно установят разработчики или автоматизированные сборочные системы. Именно этот многолетний опыт борьбы с подобными инцидентами и объясняет, почему идея вовсе отказаться от разделяемого кода в пользу генерации «с нуля» звучит для части сообщества привлекательно, даже если, как показывает разбор на Habr, она переносит проблему сложности в новое, менее проверенное место, а не решает её.