# Обновление зависимостей с ИИ без сломанной сборки

URL: https://agentvera.dev/ru/blog/upgrade-dependencies-with-ai/ · Опубликовано: 2026-10-27

Как безопасно обновлять зависимости с ИИ-агентами: разбор npm outdated, одна мажорная версия на ветку, гайд по миграции, codemod, тесты и починка PR от Dependabot.

**Коротко:**

- Начните с инвентаризации: npm outdated, pnpm outdated или pip list --outdated плюс npm audit, а затем попросите агента разложить все обновления на patch, minor и major с оценкой риска.
- Patch- и minor-обновления соберите в одну ветку, а каждой мажорной версии дайте свою ветку или worktree: сначала гайд по миграции и официальный codemod, потом правки агента.
- Доказательство — это тесты, проверка типов и сборка. Запретите менять тесты ради зелёного результата, коммитьте lock-файл и смотрите его diff.
- Dependabot и Renovate открывают PR, а агент читает упавший лог CI в этой ветке, чинит код и пушит. Именно здесь экономится больше всего времени.

**Чтобы обновлять зависимости с помощью ИИ, отдайте агенту чтение и однообразные правки, а правила безопасности оставьте себе: одно мажорное обновление на ветку, гайд по миграции до любых изменений в коде и тесты как единственное доказательство, что всё получилось.** Агенты для программирования вроде Claude Code, Codex и Gemini CLI хорошо справляются с рутинной частью обновлений: переименовать API в восьмидесяти файлах, переделать настройку тестов под новый раннер, объяснить непонятную ошибку peer-зависимостей. Плохи они в одном, и здесь это очень важно: они помнят старую версию библиотеки.

В этом руководстве — процесс, который подходит и для небольшого приложения, и для большого монорепозитория: инвентаризация, разбор, пакетные лёгкие обновления, изоляция сложных, codemod, lock-файлы, проверка, PR от ботов и уведомления об уязвимостях. Примеры даны для npm и pnpm, а там, где Python отличается, — и для него.

## Почему обновления зависимостей с агентами идут не так

Обновления выглядят простыми, поэтому и ломаются. Типичные сценарии провала:

- **Устаревшие знания.** Обучающие данные модели заканчиваются в какой-то момент. Попросите перейти на версию, вышедшую позже, и модель уверенно напишет код для той версии, которую знает.
- **Расползание задачи.** «Обнови React» превращается в React, роутер, тестовую библиотеку, ESLint и три плагина — всё в одном diff.
- **Сдвиг ворот.** После обновления падает тест, и агент обновляет snapshot, ослабляет проверку или пропускает тест.
- **Заглушенный установщик.** Конфликт peer-зависимостей «чинится» через `--force` или `--legacy-peer-deps`, вместо того чтобы найти версии, которые действительно совместимы.
- **Хаос в lock-файле.** Агент удаляет lock-файл, чтобы исчезла ошибка установки, и сотни транзитивных пакетов меняются разом.

Каждый шаг ниже закрывает один из этих сценариев.

## Шаг 1: проведите инвентаризацию

Начинайте с фактов, а не с промпта вроде «обнови всё». В каждой экосистеме есть встроенная команда, которая показывает, что отстало:

```bash
npm outdated            # Current, Wanted (highest in your range) and Latest
pnpm outdated           # add -r in a workspace
pip list --outdated     # for the active Python environment
```

Добавьте взгляд с точки зрения безопасности:

```bash
npm audit
pip-audit               # PyPA tool: pip install pip-audit
```

Затем отдайте вывод агенту и попросите разбор, а не изменения:

```text
Вот вывод npm outdated и npm audit. Пока ничего не меняй.
Составь таблицу: пакет, текущая версия, wanted, latest, тип обновления
(patch/minor/major), обычная это зависимость или dev, и ссылка на
changelog или страницу релизов. Отметь всё, у чего есть уведомление о
уязвимости. Затем предложи порядок: что можно обновить пакетом, а чему
нужна своя ветка.
```

Это задача только на чтение, поэтому её безопасно запускать в режиме планирования или с правами только на чтение. Таблица становится вашим планом и заранее показывает, какие обновления на самом деле большие.

## Шаг 2: обновите лёгкое одним пакетом

Patch- и minor-версии должны быть обратно совместимыми. На практике обычно так и есть, а остальное ловят тесты. Делайте их вместе, в одной ветке:

```bash
git switch -c deps/minor-patch
npm update              # stays inside the ranges in package.json
```

В pnpm то же делает `pnpm update`, `pnpm update --interactive` позволяет выбрать пакеты, а `pnpm update --latest` переходит через мажорные версии, так что его оставьте для шага 3. Затем:

```text
Запусти все тесты, проверку типов и сборку. Если что-то падает, найди,
какой пакет виноват, и исправь код, а не тесты. Если исправление требует
больше нескольких строк, верни этот пакет к прежней версии и внеси его
в список для отдельного обновления.
```

Последнее предложение важно. Оно держит пакет обновлений маленьким и скучным, а всё неожиданное уводит в отдельную ветку.

## Шаг 3: одно мажорное обновление на ветку

Мажорная версия по определению означает несовместимые изменения. Дайте каждой свою ветку, а если хотите вести несколько одновременно — свою папку через [git worktree](/ru/glossary/git-worktree/ "Что такое git worktree"):

```bash
git worktree add ../app-vite -b deps/vite-major
git worktree add ../app-eslint -b deps/eslint-major
```

Теперь один агент обновляет сборщик, другой — линтер, а ваша основная папка остаётся нетронутой. Если одно из обновлений превращается в болото, вы удаляете этот worktree и ветку и больше ничего не теряете. Подробнее о настройке — в статье [Git worktree для параллельных агентов](/ru/blog/git-worktree-parallel-agents/ "Git worktree для параллельных агентов").

Два правила для мажорных версий:

- **Одна мажорная ступень за раз.** Прыжок с версии 3 на 6 складывает три набора несовместимых изменений в один diff. Идите 3 → 4, добейтесь зелёного результата, закоммитьте, потом 4 → 5.
- **Связанные пакеты обновляйте вместе, и больше ничего.** Фреймворк и его официальные плагины часто должны двигаться синхронно. Это нормально. Несвязанные пакеты подождут.

## Шаг 4: прочитайте гайд по миграции до правок кода

Этот шаг решает проблему устаревших знаний. Прежде чем агент что-то изменит, он должен прочитать настоящую документацию для точной версии, на которую вы переходите:

```text
Мы обновляем eslint с 8 на 9. Прежде чем править какой-либо файл:
1. Прочитай официальный гайд по миграции и changelog для 9.0.0.
2. Перечисли все несовместимые изменения, которые касаются этого
   репозитория, с затронутыми файлами (подтверди поиском по коду).
3. Скажи, что ты сделаешь для каждого.
Источник истины — документация и определения типов установленного пакета,
а не то, что ты помнишь о старых версиях. Дождись моего OK.
```

Если агент умеет ходить в интернет, он сам скачает гайд; если нет, вставьте нужные части или укажите ему на release notes в `node_modules/<package>/CHANGELOG.md`, если пакет их поставляет. Здесь же помогает MCP-сервер с документацией; см. [лучшие MCP-серверы для программирования](/ru/blog/best-mcp-servers-for-coding/ "Лучшие MCP-серверы для программирования").

Список, который он составит, потом станет и вашим чек-листом для ревью: каждому пункту должно соответствовать изменение в diff.

## Шаг 5: пусть первым работает codemod

Многие фреймворки поставляют codemod — скрипты, которые механически переписывают код под новую версию. Codemod детерминирован, а агент нет, поэтому пусть codemod сделает всё, что может, а агенту достанется остаток.

Два известных примера:

```bash
# Next.js: upgrades Next.js, React and React DOM and runs the codemods
npx @next/codemod upgrade major

# Angular: updates packages and runs their migrations
ng update @angular/core @angular/cli
```

По состоянию на октябрь 2026 года в документации Next.js указано, что `@next/codemod upgrade` работает неинтерактивно и принимает все значения по умолчанию, когда stdin не терминал, — а так и бывает, когда его запускает агент. Если хотите сами выбрать, какие codemod применить, сначала запустите его вручную и передайте результат агенту.

После codemod сделайте коммит, а затем попросите агента разобраться с оставшимися пунктами из шага 4: случаями, которые codemod пометил или пропустил, собственными обёртками вокруг старого API, настройкой тестов и конфигурационными файлами. Если вывод codemod и правки агента лежат в разных коммитах, ревью сильно упрощается. Та же идея работает и для более крупных миграций; о пошаговых миграциях подробнее — в статьях [рефакторинг legacy-кода с ИИ](/ru/blog/refactor-legacy-code-with-ai/ "Рефакторинг legacy-кода с ИИ") и [миграция с JavaScript на TypeScript с ИИ](/ru/blog/migrate-javascript-to-typescript-with-ai/ "Миграция с JavaScript на TypeScript с ИИ").

## Шаг 6: считайте lock-файл частью изменения

Именно lock-файл придаёт смысл фразе «у меня работает». Несколько правил, которые стоит записать в `AGENTS.md` или `CLAUDE.md`:

```markdown
## Зависимости
- Никогда не удаляй package-lock.json / pnpm-lock.yaml, чтобы исправить ошибку установки.
- Не используй --force или --legacy-peer-deps, не спросив.
- В CI устанавливай через npm ci; коммить lock-файл вместе с изменением package.json.
- Не добавляй новые зависимости во время задачи по обновлению.
```

Когда установка падает из-за peer-зависимостей, попросите агента объяснить конфликт, а не продавливать его. `npm explain <package>` (псевдоним `npm why`) показывает, почему пакет попал в дерево и кто какую версию требует; `npm ls <package>` показывает все его копии. Часто настоящее исправление — обновить плагин, который закрепил старую peer-версию, и это относится к той же ветке.

На ревью смотрите и на diff lock-файла. Minor-обновление одной прямой зависимости, которое меняет триста транзитивных записей, заслуживает вопроса.

## Шаг 7: проверяйте своими проверками

«Устанавливается» — это ещё не готово. Опишите в промпте, что значит «готово», в терминах, которые агент может проверить:

```text
Готово означает: npm ci проходит, npm test проходит, tsc --noEmit проходит,
npm run build проходит, и ни один существующий тестовый файл не изменён,
кроме случаев, которых требует гайд по миграции (объясни каждый).
```

Если вокруг обновляемой библиотеки тестов мало, сначала добавьте несколько на старой версии и держите их зелёными на протяжении всего обновления. Для UI-библиотек быстрая проверка в настоящем браузере ловит то, что пропускают unit-тесты: агент с браузером может открыть основные страницы и сообщить об ошибках в консоли. Для сборщиков сравните размер результата сборки до и после; бандл, выросший вдвое, — это баг, даже если все тесты проходят.

Смотрите diff с тремя вопросами: менялся ли какой-нибудь тест, менялось ли публичное поведение и соответствует ли каждая правка пункту из списка несовместимых изменений?

## PR от ботов: Dependabot и Renovate плюс агент

Dependabot и Renovate хорошо умеют открывать PR с обновлениями по расписанию. Чего они не умеют — так это чинить код, когда обновление что-то ломает. Эту часть может взять на себя агент.

Минимальная конфигурация Dependabot, которая собирает лёгкие обновления в один PR:

```yaml
# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      minor-and-patch:
        update-types:
          - "minor"
          - "patch"
```

Аналог для Renovate начинается с рекомендованного пресета:

```json
{
  "extends": ["config:recommended"],
  "packageRules": [
    { "matchUpdateTypes": ["minor", "patch"], "groupName": "minor and patch" }
  ]
}
```

Когда PR от бота краснеет, цикл выглядит так:

```bash
gh pr checkout 123
gh pr checks 123              # find the failing run
gh run view <run-id> --log-failed   # the log of its failed jobs
```

```text
Это PR от Dependabot, который поднимает zod до следующей мажорной версии.
CI падает с логом ниже. Найди причину, прочитай release notes новой версии
и исправь наш код, чтобы он работал с новой версией. Не закрепляй старую
версию и не меняй тесты, чтобы скрыть падение. Прогони тесты локально,
потом кратко опиши изменение, прежде чем пушить.
```

Одна деталь: как только вы запушите собственные коммиты в ветку Dependabot, он перестаёт автоматически делать rebase этого PR, а `@dependabot recreate` выбросит ваше исправление. Слейте PR поскорее или сделайте rebase сами. Общую версию этого цикла описывает статья [автоисправление упавшего CI с ИИ](/ru/blog/auto-fix-ci-failures-with-ai/ "Автоисправление упавшего CI с ИИ").

## Уведомления об уязвимостях

`npm audit` перечисляет известные уязвимости в вашем дереве зависимостей. Несколько приёмов, которые сохраняют от него пользу:

- **Сосредоточьтесь на том, что уходит в продакшен.** `npm audit --omit=dev` не учитывает dev-зависимости, а `--audit-level=high` заставляет команду падать только при высокой или критической серьёзности — разумный порог для CI.
- **`npm audit fix` и `--force`.** Обычный `audit fix` остаётся в объявленных диапазонах. С `--force` он может поставить semver-major версии; считайте это обновлением из шага 3, а не быстрым исправлением.
- **Транзитивные пакеты.** Когда уязвимый пакет лежит глубоко в дереве, а его родитель ещё не выпустил исправление, поле `overrides` в `package.json` для npm (или `pnpm.overrides` для pnpm) может принудительно поставить исправленную версию. Попросите агента добавить комментарий или issue с объяснением причины, чтобы override потом убрали.
- **Спросите, достижима ли уязвимость.** Пусть агент проверит, использует ли ваш код уязвимую функцию на самом деле. Это не значит, что исправление можно пропустить, но так вы поймёте, срочно ли оно сегодня или может подождать еженедельного пакета.

Для Python `pip-audit` сообщает о таких же находках для окружения или `requirements.txt`, а `pip-audit --fix` пытается обновить затронутые пакеты. Более широкая тема — что разрешено устанавливать самим агентам — разобрана в статье [безопасность ИИ-агентов для программирования](/ru/blog/ai-coding-agent-security/ "Безопасность ИИ-агентов для программирования").

## Частые ошибки

- **«Обнови все зависимости до latest» одним промптом.** Вы получаете один гигантский diff и никакой возможности найти виновника бисекцией.
- **Пропуск гайда по миграции.** Агент пишет код для той версии, которую помнит.
- **Тихие изменения тестов.** Обновлённый snapshot допустим, когда гайд объясняет изменение; иначе он прячет регрессию.
- **Продавливание установщика.** Сегодняшний `--force` — это сломанная установка для следующего человека.
- **Слияние параллельных веток обновлений без совместной проверки.** Две зелёные ветки после объединения могут стать красными; [очередь слияния](/ru/blog/merge-queue-for-ai-agents/ "Очередь слияния для ИИ-агентов") проверяет каждую поверх свежего main.

## Как это делать в AgentVera

AgentVera — десктопное приложение, которое запускает CLI агентов для программирования, такие как Claude Code, Codex и Gemini CLI, рядом друг с другом и со встроенным git. Несколько его функций напрямую ложатся на этот процесс:

- **Worktree на каждое мажорное обновление.** Создайте worktree в [панели Git](/ru/features/git-and-github/ "Git и GitHub") и запустите в нём агента одним кликом; обновление Vite идёт в одной панели, обновление ESLint — в другой.
- **Еженедельное правило для зависимостей.** [Автоматизации](/ru/features/automations/ "Автоматизации") (Pro) запускают агента по cron-расписанию в собственном worktree. Один из встроенных сценариев — «обновить зависимости (только minor и patch)», а результат может прийти в виде PR или попасть в очередь слияния.
- **Красный CI — агенту.** [Центр CI/CD](/ru/features/ci-cd-center/ "Центр CI/CD") показывает запуски GitHub Actions, GitLab CI и Jenkins; на упавшем запуске кнопка «Исправить с агентом» открывает агента Claude с деталями запуска и хвостом лога до трёх упавших задач. Автоматизация также может запускать агента, когда CI краснеет на выбранных вами ветках.
- **Проверка по вашему определению «готово».** Напишите в сообщении «тесты, проверка типов и сборка проходят; ни один тестовый файл не изменён». [Verify](/ru/features/verify/ "Verify") превращает это в критерии, а когда ход заканчивается, отдельный проверяющий, который не может править файлы, проверяет каждый пункт с доказательствами.
- **Ревью и очередь слияния.** [Ревью кода](/ru/features/code-review/ "Ревью кода") просматривает изменения агента второй моделью, а [очередь слияния](/ru/features/merge-queue/ "Очередь слияния") вливает ветки обновлений по одной поверх свежей целевой ветки и запускает вашу команду проверки на объединённом результате.

## Итоги

Обновление зависимостей с ИИ работает, когда вы держите работу маленькими частями: сначала инвентаризация, лёгкие обновления одним пакетом, каждая мажорная версия в своей ветке, гайд по миграции до первой правки, codemod раньше агента и тесты в роли судьи. Агент экономит вам чтение и сотню мелких правок, а процесс следит, чтобы эти правки были честными. Когда обновление закончено и вы хотите ещё и ускорить приложение, прочитайте, [как оптимизировать производительность кода с ИИ](/ru/blog/optimize-code-performance-with-ai/ "Оптимизация производительности кода с ИИ").

Чтобы попробовать это на своём репозитории, [скачайте AgentVera](/ru/download/ "Скачать AgentVera").

## Частые вопросы

**Может ли ИИ-агент сам обновить мои зависимости?** Для patch- и minor-обновлений при хорошем наборе тестов — в основном да: он запускает обновление, тесты и сборку и чинит мелкие поломки. С мажорными версиями он должен работать по официальному гайду по миграции, по одному пакету на ветку, а diff перед слиянием стоит просмотреть вам.

**Почему агент при обновлении библиотеки использует старые API?** Его обучающие данные старше релиза, на который вы переходите, поэтому он помнит прежний API. Сначала попросите его прочитать changelog и гайд по миграции для точной целевой версии и скажите доверять установленным определениям типов и документации, а не своей памяти.

**Стоит ли обновлять всё сразу?** Нет. Patch- и minor-обновления можно сгруппировать, но каждой мажорной версии нужна своя ветка. Когда пять мажорных обновлений попадают в один diff и тесты падают, никто не скажет, какой пакет виноват.

**Безопасно ли запускать npm audit fix --force?** Не вслепую. В документации npm сказано, что --force позволяет audit fix ставить версии за пределами объявленных диапазонов, включая semver-major изменения. Относитесь к этому как к любому мажорному обновлению: отдельная ветка, прогон тестов и просмотр diff.

**Как дать агенту починить упавший pull request от Dependabot?** Переключитесь на ветку PR, дайте агенту лог упавшего CI (например, из gh run view --log-failed), попросите найти причину и исправление, сохраняющее новую версию, прогоните тесты локально и запушьте. После ваших собственных коммитов Dependabot перестаёт автоматически делать rebase этого PR.

---

**Об AgentVera.** AgentVera — настольное приложение для macOS, Windows и Linux от Solviera Teknoloji. Оно запускает 18 ИИ-агентов для программирования (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) рядом, по проектам, в настоящих терминалах с собственными установками CLI и входами пользователя. В бесплатном тарифе количество агентов не ограничено. Скачать: https://agentvera.dev/ru/download/ · Цены: https://agentvera.dev/ru/pricing/