Начните со списка библиотек, которые ИИ добавил в проект, и проверьте, зачем нужна каждая из них. Затем сверьте названия с реестром пакетов, изучите предупреждения об уязвимостях и удалите лишнее через отдельную копию проекта. Так вы сможете проверить зависимости после вайбкодинга, даже если сайт уже открывается и выглядит готовым. Ниже разберём порядок проверки, команды для проекта на JavaScript и признаки, при которых запуск лучше отложить до разбора с разработчиком.
Где найти библиотеки, которые добавил ИИ?
Зависимость — это чужой программный компонент, который использует ваш сайт. Например, библиотека помогает показать календарь или проверить поля формы. У неё бывают собственные зависимости: вы добавили один пакет, а вместе с ним проект получил другие.
Для сайта малого бизнеса важен понятный результат: какие компоненты попадут на сервер, какие попадут в браузер посетителя и кто будет их обновлять. Работающая страница ещё не отвечает на эти вопросы.
Если проект использует JavaScript и менеджер пакетов npm, начните с файлов package.json и package-lock.json. Первый описывает прямые зависимости и команды проекта. Второй фиксирует дерево пакетов и конкретные версии. Для другого менеджера пакетов нужен его файл фиксации версий; смешивать инструменты при проверке не стоит.
- Сохраните текущее состояние проекта в системе контроля версий или сделайте отдельную копию.
- Откройте package.json и найдите разделы dependencies, devDependencies и scripts.
- Попросите ИИ объяснить назначение каждого прямого пакета и показать место его использования.
- Сверьте ответ с файлами проекта: найдите подключение библиотеки или ссылку на неё в настройках сборки.
Подойдёт такой запрос: «Пока ничего не устанавливай и не меняй. Перечисли прямые зависимости из package.json. Для каждой покажи назначение, файл использования и причину, по которой она нужна. Если подтверждения в проекте нет, прямо укажи это».
Ответ агента используйте как карту для проверки. Библиотека иногда работает через настройки сборки и не встречается в коде страниц, поэтому одного поиска по названию недостаточно.
Как распознать выдуманный или подменённый пакет?
Название из ответа Claude Code или другого агента ещё не подтверждает, что библиотека существует и решает нужную задачу. ИИ способен предложить ошибочное имя. При этом похожее имя в реестре может принадлежать совсем другому пакету.
Проверяйте пакет до установки. Начните с точного написания в package.json: лишняя буква, дефис или другое имя автора меняют адресата загрузки.
- Найдите пакет в реестре, который использует проект, и прочитайте его описание.
- Сопоставьте название с документацией разработчика библиотеки.
- Проверьте, куда ведут ссылки на исходный код и кто поддерживает пакет.
- Посмотрите историю выпусков и открытые сообщения о проблемах. Давний выпуск сам по себе не доказывает, что пакет заброшен.
- Изучите команды, которые пакет запускает при установке, особенно если его происхождение вызывает вопросы.
Для npm команда npm view имя-пакета показывает сведения из реестра без установки самого пакета. Вместо «имя-пакета» подставьте точное название из проекта. Успешный ответ подтверждает наличие записи, но не безопасность её содержимого.
Отдельно проверьте адреса загрузки в файле фиксации версий. Зависимость может приходить из репозитория или архива, а не из обычного реестра. Если источник непонятен, остановите установку до выяснения. Проверка подозрительного пакета не должна начинаться с его запуска на рабочем сервере.
Как проверить уязвимости и не сломать сайт обновлением?
В проекте на npm начните с команды npm audit. Она сверяет зависимости с доступными сведениями об известных уязвимостях. Чистый отчёт не гарантирует безопасность: в нём нет ошибок вашей бизнес-логики и ещё неизвестных проблем библиотек.
По каждому предупреждению выясните, какой пакет затронут, как он попал в проект и при каких условиях проявляется проблема. Прямая зависимость находится в вашем списке; косвенную подтянула другая библиотека. Команда npm explain имя-пакета помогает увидеть эту цепочку.
Не запускайте npm audit fix --force только ради исчезновения предупреждений. Принудительное исправление способно изменить основные версии библиотек и нарушить совместимость. Сначала сохраните проект, затем меняйте зависимости в отдельной ветке или копии и проверяйте результат.
- Выберите одну проблему из отчёта и прочитайте условия её возникновения.
- Определите, какую прямую зависимость нужно обновить для исправления.
- Внесите изменение в копии проекта и выполните предусмотренные проектом сборку и тесты.
- Проверьте пользовательский сценарий, который затрагивает библиотека.
Например, после обновления компонента формы проверьте отправку заявки, сообщения об ошибках и повторное нажатие кнопки. Для сайта с ценами в BYN проверьте ещё отображение суммы: формат числа не должен меняться после обновления.
Если автоматических тестов нет, составьте короткий маршрут ручной проверки. В качестве основы подойдёт проверка сайта после смены ИИ-модели без команды QA: после изменения зависимостей тоже нужно убедиться, что привычные действия посетителя работают.
Как найти лишние зависимости и проверить лицензию?
Попросите агента найти пакеты без подтверждённого назначения. В эту группу попадают библиотеки для функций, от которых вы отказались, и несколько инструментов для одной задачи. Но отсутствие очевидного подключения ещё не повод удалять пакет: его могут использовать тесты или сборка.
Удаляйте по одному кандидату штатной командой менеджера пакетов, чтобы он обновил и список зависимостей, и файл фиксации версий. Затем собирайте проект и повторяйте проверку нужного сценария. Если удалить сразу несколько библиотек, причину поломки будет сложнее найти.
Раздел devDependencies тоже требует внимания. Его пакеты обычно нужны для разработки, но они выполняются при подготовке сайта к публикации. Само расположение в этом разделе не делает библиотеку безвредной и не означает, что её можно удалить.
Проверьте и лицензию: разрешает ли она нужный способ использования, требует ли сохранить уведомления об авторстве, есть ли дополнительные условия. Поле license в описании пакета — отправная точка. Если оно пустое или условия непонятны, найдите текст лицензии в исходном проекте и передайте вопрос на разбор.
После удаления или замены визуальных компонентов проверьте сайт на телефоне. Для этого пригодится список проверок мобильной версии после вайбкодинга, особенно для меню, форм и элементов, которые реагируют на касание.
Что зафиксировать перед запуском и каких ошибок избегать?
Сохраните короткий отчёт рядом с проектом: какие зависимости проверили, что обновили или удалили, какие предупреждения остались и почему. По спорному пакету запишите конкретное ограничение, например: «Не устанавливать до подтверждения источника». Так следующий запуск агента не начнётся с прежних догадок.
Правила для будущих изменений можно добавить в AGENTS.md, а для Claude Code — в CLAUDE.md. Такие файлы описывают инструкции проекта: как его собрать, запустить тесты и соблюдать соглашения (журнал Яндекс Практикума «Код»). Запишите правило: перед добавлением пакета агент объясняет его назначение, проверяет источник и предлагает способ проверить результат. Сам файл правил не заменяет контроль изменений.
Типичные ошибки:
- Устанавливать пакет сразу из ответа ИИ. Сначала проверьте точное имя и источник.
- Считать отсутствие предупреждений доказательством безопасности. Дополните отчёт проверкой происхождения и назначения библиотек.
- Обновлять всё сразу. Разделите изменения, чтобы можно было найти причину сбоя и отменить конкретное обновление.
- Удалять файл фиксации версий ради успешной сборки. Сначала выясните причину ошибки, иначе изменится набор зависимостей.
- Передавать исполнителю задачу «проверить безопасность» без результата на выходе. Запросите перечень находок, исправления и список проверок после них.
Если проверку выполняет разработчик, итогом должны стать понятный отчёт и изменения, которые можно просмотреть и отменить. Для владельца бизнеса это отделяет завершённую проверку от сообщения «всё поправил»: видно, что изменилось и какие сценарии уже работают.
Следующий шаг на две минуты: откройте package.json и попросите агента объяснить назначение каждой прямой зависимости без установки пакетов и изменения файлов.
