У Next.js 16.4 команда next upgrade --agent перевіряє встановлену версію, обирає цільовий реліз і готує для твого coding agent міграційні гайди, потрібні codemods та кроки верифікації. Агент застосовує оновлення, розв'язує міграційні проблеми і перевіряє, що застосунок працює. Це не «магічна кнопка», а правильна архітектура делегування: source of truth лишається у фреймворку, агент виконує, тести перевіряють. Розбираємось, що саме відбувається під капотом і де в цьому процесі все одно потрібен ти.

Ритуал, який усі знають напам'ять

Оновлення великого Next.js-проєкту десятиліттями виглядає однаково: прочитати migration guide, знайти deprecated API, прогнати codemods, виправити type errors, запустити тести, відкрити браузер – і виявити, що checkout тепер «трохи не checkout».

Кожен крок окремо нескладний. Разом вони з'їдають день-два, і головний ризик не в механіці, а в тому, що частину гайда ти прочитав по діагоналі.

Next.js 16.4 формалізує цей процес:

npx next@canary upgrade --agent=latest

Чому next@canary: так запускається найсвіжіший upgrade-tooling, навіть якщо сам проєкт сидить на старій версії. Тобто інструкції для агента завжди актуальні, незалежно від того, наскільки ти відстав.

Що саме готує команда

За офіційним описом, флоу виглядає так: команда перевіряє встановлену версію, обирає цільовий реліз і готує для агента три речі – міграційні гайди, потрібні codemods і verification steps. Далі агент застосовує оновлення, розв'язує міграційні конфлікти і перевіряє, що застосунок досі працює.

Окремо Next.js тепер має готові Skills для великих рефакторингів – зокрема для міграції на Cache Components, яку команда явно називає головною причиною інвестувати в agent-tooling саме зараз.

Чому це сильніша ідея, ніж черговий промпт

Промпт типу «upgrade my app to Next.js 16.4» має фундаментальну проблему: модель може пам'ятати документацію не тієї версії або змішати семантику різних релізів. Для фреймворка, який за рік змінив модель кешування двічі, це не теоретичний ризик.

next upgrade --agent зміщує source of truth назад до фреймворку:

tool owns truth → agent executes → tests verify.

Не навпаки. Агент більше не «згадує», як мігрувати – він отримує інструкцію від того, хто цю міграцію спроєктував.

Це той самий принцип, який я описував у статті про Claude Code: якість роботи агента визначається не розміром моделі, а якістю контексту й меж, які ти йому даєш. Тут контекст готує сам фреймворк – і це найякісніший контекст із можливих.

agentUpgrade: нагадування, які не треба пам'ятати

Друга частина новинки тихіша, але для production-команд, можливо, важливіша. Експериментальний конфіг agentUpgrade змушує next dev і next build самим нагадувати про доступні оновлення:

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  experimental: {
    agentUpgrade: 'security',
  },
};

export default nextConfig;

Політики три: 'security' (дефолт – нагадує лише про релізи, що закривають відомі вразливості твоєї версії), 'latest' (нагадує про нові major/minor) і false (вимкнено).

Дефолт обраний розумно: security-патч – це саме той випадок, коли «оновимось колись потім» коштує найдорожче. Якщо ти читав розбір про жовтневий security-реліз Node.js, логіка та сама: готовність до оновлення важливіша за швидкість реакції на Twitter.

Бонус: агент тепер може скаржитись на фреймворк

Ще одна експериментальна дрібниця – agentFeedback. Коли агент під час роботи натикається на помилки фреймворку, незрозумілу документацію чи обхідні шляхи, він готує чернетки звітів для команди Next.js. Важливі запобіжники: агент інструктований не включати код, логи й секрети, кожен звіт відкривається тобі на рев'ю в браузері, і нічого не відправляється, поки ти сам не натиснеш «Send feedback». У CI це не працює взагалі.

Механіка дрібна, а напрям показовий: фідбек-луп «агент → фреймворк» стає частиною інструмента.

Де Senior усе ще потрібен

Тепер чесна частина. Codemod не знає, чому конкретна route у тебе має бути dynamic. Агент не знає бізнес-контракту платіжного флоу. Migration guide не знає про legacy cookies твого production, які «тимчасово» живуть третій рік.

Хороший upgrade-процес має три рівні:

  1. Механічна міграція – deprecated API, синтаксис, імпорти. Це тепер майже повністю територія агента.
  2. Автоматизована верифікація – типи, тести, білд. Агент запускає, але якість цього рівня визначається тим, наскільки добре ти колись написав тести.
  3. Продуктове й архітектурне рев'ю – чи поводиться checkout як checkout. Тут «працює build» зовсім не дорівнює «можна deploy», і це досі твоя робота.

Перед тим як пустити агента в міграцію, пройдись по чеклісту перевірки AI-коду – diff після upgrade-агента заслуговує на те саме рев'ю, що й будь-який інший згенерований код.

Коли агентський upgrade іде не за планом

  • Запускати на брудному working tree. Міграція має починатися з чистого коміту – інакше ти не відрізниш зміни агента від своїх.
  • Довіряти «тести пройшли» без перегляду самого diff. Тести ловлять те, що покрито тестами. Міграційні баги люблять жити рівно там, де покриття немає.
  • Оновлюватись у день релізу на production-критичному проєкті. --agent прибирає механічну працю, але не прибирає ризик свіжого релізу.
  • Ігнорувати verification steps. Агент їх готує не для декорації – прожени їх і подивись очима на результат.

Прожени на pet-проєкті, не на проді

Візьми свій pet-проєкт на Next.js 15 чи 16.x і прожени npx next@canary upgrade --agent=latest зі своїм агентом. Перед запуском зроби коміт і запиши три речі, які, на твою думку, зламаються. Після міграції порівняй зі списком того, що зламалось насправді. Ця вправа калібрує твою інтуїцію щодо того, що можна делегувати, краще за будь-яку статтю – включно з цією.

У 2026 сильний розробник – не той, хто вміє зробити upgrade руками (це вміють усі), а той, хто вміє побудувати процес так, щоб агент працював у чітких межах і залишав evidence на кожному кроці.