Рефакторинг легасі-коду з Codex: розвідка репозиторію, тести й режими схвалення

Коротко (TL;DR)

• Легасі ламає агента не «складністю», а чотирма вимірюваними обмеженнями: вікно контексту 272 000 токенів, вимкнена в пісочниці мережа, вимога git-репозиторію і ліміт інструкцій 32 KiB. Жодне з них не лікується формулюванням промпту.
• Порядок роботи зворотний до звичного: спершу розвідка в режимі читання, далі фіксація поточної поведінки тестами, і лише потім правки — цього вимагає й офіційна методика OpenAI.
• Головний страх знімається прапорцем, а не довірою: у замірі 13.08.2026 агент не зміг записати жодного байта в .git навіть у режимі правок, а от збірка легасі падає за замовчуванням — мережа в пісочниці вимкнена, curl повертає помилку резолву імені.
• У Codex є задокументована системна помилка саме на рефакторингу: він править сторону виклику раніше за те, що викликає, і лишає проєкт незбираним посеред роботи.
• Рефакторинг і міграція — два різні сценарії з різними стартовими промптами, і змішувати їх в одну задачу офіційна документація прямо забороняє.

Усе нижче перевірено на codex-cli 0.147.0 (13 серпня 2026): частина — за офіційною документацією, частина — власними запусками, вивід яких наведено дослівно.

Що ламає агента на легасі: чотири обмеження, а не якість моделі

Розмову про «рефакторинг чужого коду з ШІ» зазвичай ведуть так, ніби все вирішує якість моделі. На старому коді це не так: агент упирається в чотири механічні межі, і кожна з них вимірювана.

Звідси випливає весь порядок роботи. Не можна «попросити полагодити» — спершу треба вмістити задачу у вікно, підняти збірку, дати агентові правила і лише тоді міняти код. Саме так побудована й офіційна методика: OpenAI розбирає модернізацію легасі в окремому кукбуці «Modernizing your Codebase with Codex», де на весь пілотний потік припадає пʼять фаз і чотири документи, а генерація коду стоїть аж на четвертій.

Якщо ви ще не працювали з цим агентом, почніть із розбору OpenAI Codex — далі припускається, що базовий цикл вам знайомий.

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Розвідка чужого репозиторію: режим читання і карта коду в JSON

Офіційна сторінка сценарію рефакторингу починається з вимоги, яку майже всі пропускають: «ask Codex to map the area before editing» — спершу картуємо ділянку, потім правимо. Практично це означає запуск, у якому агент фізично не може нічого змінити.

Nutanix замінила Copilot і Claude кластером за $20 млн: окупність — рік

OpenAI розкрила масштаб злому Hugging Face: 1200 агентів і 12 днів без виявлення

Codex і GitHub у роботі команди: права, гілки, рев’ю та конфлікти

Perplexity Portable Computer: агент працює на вашій RTX, а рахунок за токени — нуль

Ковенанти біткоїна: п’ять років після Taproot і 0% сигналізації за OP_CTV

Документація стверджує це прямо: «By default, codex exec runs in a read-only sandbox». Я перевірив запуском без жодного прапорця пісочниці — шапка сесії 13.08.2026:

$ codex exec "list the files, do not change anything"
OpenAI Codex v0.147.0
model: gpt-5.6-terra
approval: never
sandbox: read-only

Тобто розвідку можна вести, нічого спеціально не налаштовуючи: права на запис треба давати свідомо, а не відбирати.

Найпростіший розвідувальний запуск офіційна документація показує так:

codex exec "summarize the repository structure and list the top 5 risky areas"

Для чужого легасі цього замало: потрібен не переказ, а список, з яким можна працювати далі. Тут допомагає пара прапорців, про які майже не пишуть, — вивід за JSON-схемою:

codex exec --sandbox read-only \
  "Склади карту репозиторію: точки входу, модулі без тестів, мертві шматки, зовнішні залежності" \
  --output-schema ./recon.schema.json -o ./recon.json

На виході — структура з фіксованими полями, яку можна порівнювати між прогонами і класти в тикети. Якщо потрібна не фінальна відповідь, а весь хід роботи, той самий прогін запускається з --json: тоді stdout перетворюється на потік подій JSONL (thread.started, item.*, turn.completed з витратою токенів).

Окремий випадок — легасі поза git. Це не рідкість: архів із вихідними кодами, тека з сервера, код, який ніколи не заводили в репозиторій. Codex такий запуск зупиняє:

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

$ codex exec --sandbox read-only "list the files"
Not inside a trusted directory and --skip-git-repo-check was not specified.

Вимога навмисна: git — це спосіб відкотити все, що агент зробить. Обійти її можна прапорцем --skip-git-repo-check, і в моєму замірі після цього прогін відпрацював штатно. Але правильний порядок інший: спершу git init і перший коміт, і лише потім агент. Інакше ви втрачаєте єдиний дешевий механізм відкату.

AGENTS.md для легасі-репозиторію: ліміт 32 KiB і вкладені override

AGENTS.md — файл інструкцій, який агент читає перед роботою. У своєму проєкті його пишуть один раз і забувають; у чужому легасі він стає головним інструментом керування, бо заміняє відсутню документацію.

Механіка збирання інструкцій така: спершу глобальний файл із домашньої теки Codex, далі файли від кореня проєкту вниз до поточної теки, не більше одного на каталог, і файли ближчі до робочої директорії перекривають ранні. У тому самому каталозі AGENTS.override.md має пріоритет над AGENTS.md. Детальний розбір самого файлу — в уроці про AGENTS.md; тут важливі три речі, які спливають саме на старому коді.

Перше — ліміт 32 KiB. Ключ project_doc_max_bytes за замовчуванням дорівнює 32 KiB, і при досягненні ліміту Codex просто перестає додавати файли. На монорепозиторії з десятком інструкцій це означає, що частина правил до агента не доїде, і ви про це не дізнаєтесь. Лікується або підняттям ліміту, або рознесенням правил по вкладених каталогах.

Друге — вкладені override під кожен модуль. У легасі-монорепозиторії зазвичай немає єдиної команди збірки: один сервіс збирається через make, інший — древнім скриптом, третій не збирається взагалі. Документація показує саме цей прийом — власний файл у каталозі модуля:

# services/payments/AGENTS.override.md

## Правила сервісу платежів
- Тести запускати лише `make test-payments`, загальний `npm test` тут не працює.
- Файли в legacy/ не чіпати без прямого прохання: вони збираються окремим пайплайном.

Третє — якщо в репозиторії вже є власний файл правил. Старі команди часто тримають TEAM_GUIDE.md або CONTRIBUTING.md з реальними домовленостями. Їх не треба переписувати — досить додати імʼя до списку:

# ~/.codex/config.toml
project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"]
project_doc_max_bytes = 65536

Перевірити, що агент справді прочитав потрібне, можна однією командою: codex --ask-for-approval never "Summarize the current instructions." — у відповіді він перелічить завантажені правила в порядку пріоритету.

ExecPlan: формат OpenAI для міграції, що триває годинами

Для великої міграції OpenAI пропонує не промпт, а документ — ExecPlan. Це живий проєктний файл, за яким агент веде зміну тижнями і до якого повертається після кожної паузи. Термін довільний: модель на ньому не навчалася, його зміст ви задаєте самі в AGENTS.md.

Вимоги до плану в кукбуці сформульовані жорстко. План мусить бути самодостатнім: реалізувати його має бути можливо, маючи лише робоче дерево і цей один файл, без памʼяті про минулі обговорення. Обовʼязкових розділів чотири, і документація окремо підкреслює, що вони не опційні:

• Progress — чекбокси з відмітками часу, які чесно відображають поточний стан;
• Surprises & Discoveries — що зʼясувалося дорогою, з короткими доказами (ідеально — вивід тестів);
• Decision Log — кожне рішення з обґрунтуванням і датою;
• Outcomes & Retrospective — що вийшло, що лишилось, чого навчилися.

За заявою OpenAI, схожий документ дозволяв агентові працювати понад сім годин з одного промпту. Це заява вендора, а не мій замір, — але сама конструкція зрозуміла: план заміняє памʼять між сесіями.

Утримати довгу роботу допомагає й режим цілі: /goal робить формулювання водночас першим промптом і критерієм завершення, а /plan беруть, коли результат ще не сформульовано. Показово, що офіційний приклад цілі в документації — це рівно наш клас задач:

Migrate this codebase from JavaScript to TypeScript. Preserve existing behavior,
compile in strict mode without explicit `any` types, and make the full test suite pass.

Тут видно правильну форму задачі для легасі: результат, обмеження («поведінку зберегти») і перевірка («увесь набір тестів проходить»). Методологію розробки від специфікації ми окремо не розбираємо — вона не привʼязана до конкретного агента і розібрана в статті про spec-driven development.

Тести-запобіжники, коли тестів немає: паритетний прогін двох версій

Класичне визначення каже, що легасі — це код без тестів. Звідси й головне питання: як міняти те, чию поведінку ніхто не може підтвердити.

Відповідь, яку дає офіційна методика, називається паритетна стратегія: стара і нова версії проганяються на тих самих вхідних даних, а їхні виходи порівнюються. У кукбуці під це відведено окремий документ пілота й окремий файл тестів, причому каркас тестів створюється ДО того, як зʼявиться нова реалізація.

Порядок такий:

1. Зафіксувати поточну поведінку. Не «правильну», а фактичну — разом із дивацтвами, округленнями і багами, на які хтось уже спирається. Офіційний кукбук цей крок не формулює, але в практиків, що розбирали рефакторинг легасі з агентом, він зводиться до одного прохання: написати тести на поточну поведінку модуля і поки не чіпати реалізацію.
2. Описати, що вважається збігом. Які виходи порівнюємо: файли, рядки в таблицях, логи. Це окремий пункт, бо «результат збігся» на легасі майже завжди означає «збігся з точністю до формату дати й порядку рядків».
3. Добудувати паритетний тест. Офіційний промпт вимагає, щоб тест викликав і старий потік, і нову реалізацію та порівнював виходи за описаною стратегією.
4. Записати команди паралельного прогону. Упорядкованим списком: підготувати дані → прогнати старе → прогнати нове → порівняти, з точними шляхами й описом того, який вигляд має успіх.

Важливе застереження: зафіксована поведінка — це не специфікація. Знімок показує, що система робить зараз, а рішення, які з цих дивацтв переносити в нову версію, а які вважати багом, лишається за людиною. Агент добре знімає зліпок і погано судить, що в ньому правильно.

Сама методологія розробки через тести від інструмента не залежить і докладно розібрана окремо — тести як критерій готовності. Тут важливо лише те, що специфічне для легасі: тести пишуться не на бажане, а на наявне, і пишуться раніше за правки.

Пісочниця Codex на легасі: чому падає збірка і що захищено

Найчастіший страх звучить так: «агент знесе робочий код». Найчастіша реальна проблема звучить інакше: «в агента не збирається проєкт». Я заміряв обидві, прогнавши команди під пісочницею Codex на macOS 13.08.2026.

Дослівний вивід, на якому побудована таблиця:

$ codex sandbox -c sandbox_mode="workspace-write" bash -lc 'echo z > .git/probe.txt || echo git_dir_BLOCKED'
git_dir_BLOCKED
bash: .git/probe.txt: Operation not permitted

$ codex sandbox -c sandbox_mode="workspace-write" bash -lc 'curl -sS -m 8 https://registry.npmjs.org/ -o /dev/null; echo curl_exit=$?'
curl: (6) Could not resolve host: registry.npmjs.org
curl_exit=6

Звідси два практичні висновки.

Історію репозиторію агент не зіпсує. .git оголошено доступним лише для читання всередині записуваного кореня, захист рекурсивний, і те саме стосується каталогів .agents та .codex. Тобто «агент перепише історію» — не той ризик, про який варто думати.

А от збірка легасі не підніметься. Мережа в пісочниці вимкнена за замовчуванням, і падає вона не на завантаженні пакета, а раніше — на резолві імені. Для старого проєкту, який тягне залежності із зовнішніх реєстрів, це гарантована відмова на першому ж кроці. Лікується явним увімкненням:

[sandbox_workspace_write]
network_access = true

Відкривати мережу варто свідомо: разом із залежностями агент отримує канал назовні. Розумний компроміс — підняти залежності заздалегідь власноруч, а агентові лишити роботу вже по зібраному дереву.

Подивитися, що саме заборонить пісочниця вашому легасі-скрипту, можна заздалегідь, прогнавши його в тих самих обмеженнях: codex sandbox bash -lc "./build.sh". Тут варто попередити про розбіжність: документація показує форму codex sandbox macos … з підкомандою платформи, але у 0.147.0 такої підкоманди немає — слово macos сприймається як виконувана команда, і запуск падає з execvp() of 'macos' failed. Робоча форма — без назви платформи.

Режими схвалення на ризикованих правках: untrusted і автоматичне ревʼю

На чужому коді ціна помилки вища, ніж на своєму, тому рівень автономії обирається свідомо. Загальний розбір механіки — в уроці про режими схвалення і пісочницю, а під легасі має сенс дивитися на три варіанти.

Середній рядок — робочий режим для чужого легасі. Правки файлів ідуть самі, але все, що може змінити стан за межами робочого дерева, зупиняється і питає.

Третій рядок цікавіший, ніж здається. Автоматичне ревʼю не розширює меж пісочниці: воно бере ті запити, які й так вимагали б вашого схвалення, і віддає їх окремому агентові-рецензенту. Перевіряє він цілком конкретні речі — спроби витягти дані назовні, промацування облікових даних, стійке послаблення захисту і руйнівні дії; критичний ризик відхиляється, а збої розбору трактуються на користь заборони. Для багатогодинної міграції це розумний розмін: ви не сидите над кожним питанням, але й не відкриваєте агентові все.

Чого не варто робити на чужому коді — запускати з повним вимкненням пісочниці та схвалень. Прапорець для цього існує, документація позначає його як украй небезпечний, і легасі — найгірше місце для таких експериментів.

Масові однотипні правки: codex exec, JSON-вивід і перевірка пачки

Окремий клас задач на легасі — однакова правка в сотні файлів: замінити застарілий виклик, переписати імпорти, проставити типи. Інтерактивний режим для цього незручний, працює codex exec.

Базова форма з явними правами:

codex exec --sandbox workspace-write \
  "Заміни виклики застарілого logger.log(...) на logger.info(...) у всьому каталозі src/. \
   Поведінку не міняти, публічні сигнатури не чіпати, тести не переписувати."

Двокроковий сценарій, коли після прогону треба щось підправити, тримається на resume:

codex exec "прожени лінтер і опиши, які правила падають після заміни"
codex exec resume --last "полагодь лише ті падіння, що спричинені заміною, решту не чіпай"

Перевіряти пачку читанням сотні дифів безглуздо. Для цього є окремий рецензент, який читає зміни і не чіпає робоче дерево:

codex review --uncommitted          # усе незбережене, включно з новими файлами
codex review --base main            # гілка проти базової
codex review --commit <SHA>         # рівно один коміт

В інтерактивній сесії те саме робить /review. За бажання ревʼю можна ганяти на іншій моделі, ніж сама робота, — за це відповідає ключ review_model у конфігурації.

Важливе попередження для тих, у кого вже є скрипти автоматизації. Прапорець --full-auto, який роками кочує чужими прикладами, у версії 0.147.0 не працює:

$ codex exec --full-auto "say ok"
error: unexpected argument '--full-auto' found

Я перевірив це з контролем методу — поруч прогнав завідомо вигаданий прапорець, якого в CLI немає, і відповідь виявилася ідентичною, тобто прапорець саме відсутній, а не «застарів із попередженням». При цьому офіційна сторінка на ту саму дату стверджує протилежне: що прапорець збережено як сумісний і він друкує попередження. Якщо ваш пайплайн міграції побудований на --full-auto, після оновлення CLI він зупиниться; заміна — явний --sandbox workspace-write.

Типові міграції легасі: версія мови, фреймворк, збірка, типізація

OpenAI розводить рефакторинг і міграцію по різних сторінках, і це не формальність: у сценаріїв різні стартові промпти й різні вимоги.

Рефакторинг міняє форму коду на місці: прибрати мертве, розібрати роздуті модулі, зібрати дублі, замінити застарілі прийоми на чинні домовленості репозиторію. Офіційний промпт вимагає зберігати поведінку, йти дрібними доступними для огляду проходами, тримати публічні API стабільними і — окремим пунктом — виносити будь-яку зміну фреймворка чи залежності в окрему задачу міграції.

Міграція міняє стек. Тут промпт вимагає іншого: інвентаризувати легасі-припущення (роутинг, моделі даних, авторизація, конфігурація, збірка, тести, деплой, зовнішні контракти), скласти карту відповідностей старого й нового, назвати те, чому прямої відповідності немає, і запропонувати інкрементальний план із прошарками сумісності замість великого переписування. Стратегія обирається з відомих: прошарок сумісності, перенесення модуль за модулем, branch-by-abstraction або strangler — заміщення по одній межі за раз.

Загальне правило одне: за один захід міняється щось одне. Змішування рефакторингу й міграції — найшвидший спосіб отримати диф, який неможливо відревʼюити і нічим перевірити.

Велика міграція шматками: хмарні задачі та worktree

Коли міграція не вміщається в один захід, її ріжуть. Тут є розвилка, яку варто розуміти буквально.

Паралелити читання — безпечно. Офіційна рекомендація щодо субагентів прямо каже: паралельні агенти добрі для розвідки, тестів, тріажу і стиснення результатів, а з паралельним записом радять обережніше. Для легасі це ідеальний поділ: три агенти одночасно розбирають три підсистеми і повертають витяжки, а правки йдуть послідовно.

Паралелити запис — через окремі checkout. Механізм для цього — worktree, друга робоча тека того самого репозиторію. Codex створює їх у своїй домашній теці в стані detached HEAD, щоб не засмічувати гілки. Тут ховається дрібниця, яка розвʼязує половину проблем зі збіркою старого проєкту: файл .worktreeinclude у корені репозиторію перелічує ігноровані git-ом локальні файли, які треба скопіювати в новий worktree. Без нього легасі, що залежить від локального конфіга чи вендорених бібліотек, у свіжому checkout просто не підніметься.

Різати на хмарні задачі має сенс, коли шматок самодостатній і завершується пулл-реквестом. Побудову хмарної задачі варто враховувати при плануванні: вона двофазна — на фазі підготовки є мережа і ставляться залежності, а фаза роботи агента за замовчуванням іде офлайн. І окремо: секрети оточення доступні лише на підготовчій фазі й видаляються до старту агента, тож схема «покладу токен у секрети, і агент ним скористається» у хмарі не працює. Докладніше механіка розібрана в уроці про хмарні задачі Codex.

Практичний розмір шматка — той, що завершується зеленою перевіркою: паритетним прогоном на спільних даних або чистим codex review --base по гілці цього шматка. Якщо віха не може завершитися ні тим, ні іншим, це не віха, а просто багато змін — і на легасі такий шматок розбирати буде нікому.

Де Codex помиляється на легасі: порядок правок і issue #21920

У агента є помилка, яка на рефакторингу відтворюється систематично, і вона зафіксована в репозиторії самого продукту — issue #21920 (відкритий 09.05.2026, мітки enhancement і model-behavior).

Суть: Codex править сторону виклику раніше за те, що викликає. Розбираючи модуль на кілька, він спершу додасть оголошення mod foo, і лише потім створить foo.rs. Автор описує наслідок прямо: проєкт «unable to be compiled, tested» протягом довгих відрізків роботи, і називає це систематичним спостереженням по багатьох рефакторингах.

Чому це важливіше, ніж здається на своєму коді: на легасі зламана збірка посеред правки позбавляє вас єдиного швидкого сигналу «стало гірше». Ви не можете відрізнити «агент ще не дописав» від «агент зламав».

Лікується це тим самим способом, який пропонує автор issue, — інструкцією:

## Порядок правок
- Спершу оголошуй, потім викликай: новий файл/функція зʼявляється РАНІШЕ за посилання на неї.
- Дерево має збиратися після кожного кроку. Якщо крок неможливо зробити
  без тимчасової поломки збірки — спершу опиши план, не починай правку.

Решту типових промахів на старому коді зручно тримати перед очима таблицею.

Для повторюваних сценаріїв напрацьовану інструкцію зручно оформити як скіл — багаторазовий набір правил, що підключається до будь-якого репозиторію. Матеріалів українською з цієї теми майже немає, а англомовні шукаються передбачувано: сам сценарій — за запитом codex code refactoring, готові заготовки правил — за codex refactor skill, формулювання задач — за codex refactor prompt. Застереження те саме, що й із будь-яким чужим шаблоном: перед застосуванням до свого легасі його треба прочитати цілком — скіл може тягнути за собою правила, які вашому проєкту не підходять.

Вікно контексту 272 000 токенів: скільки легасі влазить за раз

Цифра, з якої випливає вся стратегія нарізки: на 13 серпня 2026 вікно контексту в усіх моделей Codex однакове — 272 000 токенів. Це видно в метаданих моделей у репозиторії продукту: одне й те саме значення у gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna і в старіших.

Причому вікно не зростало, а стиснулося: PR #33972, влитий 18 липня 2026, змінив значення з 372 000 на 272 000.

Скільки це в коді? Я виміряв на 12 реальних файлах проєкту токенізатором o200k_base — тим самим, що використовують моделі OpenAI: 296 433 символи, 5 919 рядків, 86 997 токенів. Звідси 3,41 символа на токен і 14,7 токена на рядок.

• ≈18 500 рядків — теоретична стеля, якби вікно займав лише код;
• ≈13 000 рядків — реалістична оцінка, якщо вважати, що близько 30% вікна йде на системний промпт, інструкції, схеми інструментів і сам діалог.

Щільність залежить від мови: на багатослівних легасі-мовах на кшталт COBOL, Java чи PL/SQL рядків уміститься менше, на щільних на кшталт Python чи Go — більше. Але порядок величини ясний: середній легасі-модуль у вікно влазить, моноліт на сотні тисяч рядків — ні. Працювати доводиться підсистемами, а карту цілого тримати в документах, а не в контексті. Як витрачається вікно і що робити, коли воно закінчується, розібрано в уроці про ліміти та вікно контексту Codex.

Окремо про вибір моделі під різні частини міграції.

Поділ економить не лише гроші, а й вікно: розвідувальні прогони на молодшій моделі повертають витяжку, а не тягнуть увесь прочитаний код в основну сесію.

Що застаріє першим. Версії й моделі в цій темі живуть місяцями: gpt-5.4 і gpt-5.4-mini йдуть із Codex 31 серпня 2026, а gpt-5.2 і gpt-5.3-codex уже зняті — і це попри те, що офіційний кукбук щодо планів на 13.08.2026 усе ще радить gpt-5.2-codex. Тому перед перенесенням чужого конфіга міграції перевірте актуальність у себе: codex --version, codex exec --help і /status у сесії покажуть реальну картину швидше за будь-який гайд.

Часті запитання

Чи можна доручити Codex рефакторинг легасі, якщо тестів у проєкті немає?

Можна, але не починаючи з правок. Офіційна методика OpenAI ставить першим кроком фіксацію поточної поведінки: спершу пишуться тести на те, як система працює зараз, потім описується, що вважати збігом виходів, і лише тоді міняється код. Без цього зліпка ви не відрізните «стало краще» від «зламалося непомітно», бо еталона не існує.

Чому збірка старого проєкту падає під агентом, хоча руками збирається?

Бо в пісочниці вимкнена мережа. У замірі 13.08.2026 curl усередині пісочниці завершився з кодом 6 і повідомленням «Could not resolve host» — тобто відмова стається на резолві імені, ще до завантаження. Будь-яке встановлення залежностей падає з цієї причини. Лікується ключем network_access = true у секції sandbox_workspace_write або тим, що залежності ставляться заздалегідь вручну.

Що робити, якщо легасі-проєкт узагалі не під системою контролю версій?

Завести репозиторій до першого запуску агента. Codex відмовляється працювати поза git — прогін зупиняється повідомленням «Not inside a trusted directory». Формально це обходиться прапорцем --skip-git-repo-check, і він працює, але так ви позбавляєтесь єдиного дешевого способу відкотити правки. Мінімально достатньо git init і одного коміта з початковим станом.

Скільки коду Codex бачить за один раз?

Вікно контексту на 13 серпня 2026 — 272 000 токенів, однаково в усіх моделей. За моїм заміром на реальних файлах це близько 18 500 рядків коду в теорії і порядку 13 000 на практиці, коли частина вікна зайнята інструкціями й діалогом. Середній модуль уміщується цілком, великий моноліт — ні, тому робота йде підсистемами.

Чим міграція відрізняється від рефакторингу в термінах Codex?

Це два різні сценарії з різними стартовими промптами. Рефакторинг міняє форму коду на місці й мусить зберігати поведінку та публічні інтерфейси; усе, що тягне за собою зміну фреймворка чи залежності, документація вимагає виносити в окрему задачу. Міграція міняє стек і потребує інвентаризації припущень, карти відповідностей, плану з контрольними точками та видимого шляху відкату.

Чи потрібен AGENTS.md, якщо я в чужому репозиторії разово?

Так, і це саме той випадок, де він окупається найшвидше. У чужому коді файл інструкцій заміняє відсутню документацію: команди збірки і тестів, заборонені каталоги, порядок правок. Навіть десяти рядків досить, щоб агент не намагався запустити загальний npm test там, де працює лише власний скрипт модуля.