Anthropic пояснили, як готувати код до модернізації ШІ
Інженери Anthropic описали, як великі компанії готують legacy-системи до модернізації агентами. Проєкти, що раніше тривали роками, тепер займають місяці чи тижні — вузьким місцем стає не написання коду, а організація процесу. Підхід: визначити ціль (зберегти поведінку системи чи переписати бізнес-логіку), скласти «сертифікат» — автоматичні перевірки для кожної зміни, і «політику промоції» — рівні перегляду людиною залежно від ризику.
У регульованих галузях кожна зміна раніше проходила через людину, що написала і перевірила код. Агент генерує зміни швидше, ніж команда встигає рев'ювати, тож старий процес перевірки стає вузьким горлом.
Три сценарії модернізації — і чому суперечка про мету виникає завжди
Anthropic виділяє три типи проєктів модернізації, і від вибору залежить решта плану. Transform — стек змінюється, а поведінка системи лишається незмінною, варіант із найменшим ризиком. Reimagine — модернізація одночасно закриває технічний борг і додає нові вимоги бізнесу. Uplift — оновлення відбувається просто в діючій системі, без паралельної збірки нової версії, поки розробка триває.
За спостереженнями Anthropic, суперечка про вибір типу виникає майже завжди: команди, найближчі до продакшну, хочуть transform, щоб стримати ризик, тоді як інженери, які довго живуть із кодовою базою, та бізнес-стейкхолдери схиляються до reimagine, щоб заразом реалізувати нові вимоги. Якщо питання лишити невирішеним, воно повертається пізніше — уже як суперечка про те, чи «правильна» та чи інша конкретна зміна. Anthropic радить зафіксувати вибір типу модернізації на рівні керівництва ще до старту.
Головний аргумент «за» — не економія, а ризик
За досвідом Anthropic, скорочення витрат на підтримку рідко буває головною причиною, чому компанії беруться за модернізацію legacy-систем. Найчастіше вирішальним є зниження ризику: система з непропатченими вразливостями може призвести до злому чи збою, здатного поставити під загрозу сам бізнес. Ризик посилюють застаріле середовище виконання, яке більше не підтримується, і скорочення числа інженерів, які взагалі розуміють, як система працює.
Тому при оцінці бюджету Anthropic пропонує зважувати не лише вартість модернізації, а й вартість бездіяльності — саме це порівняння найлегше пояснити на рівні керівництва, коли команди сперечаються, скільки ризику можна закласти в одну зміну.
Хто відповідає, якщо агент помилиться
Коли агент генерує зміни швидше, ніж команда встигає перевіряти їх вручну, компанії будують «політику промоції» — заздалегідь узгоджену градацію глибини перегляду залежно від ризику зміни. Проєкт із жорстким дедлайном (наприклад, кінець підтримки середовища виконання) отримує швидшу політику з легшим ревʼю та явно прийнятим вищим ризиком на зміну; проєкт без такого тиску часу може дозволити собі глибше ревʼю й повільніше перемикання.
У регульованих галузях саме це найбільше турбує перевіряльників: полегшений перегляд означає, що конкретна людина, яка підписує зміну, персонально несе ризик поганого рішення, тоді як керівництво несе ширший ризик застарілої системи. За досвідом Anthropic, краще працює, коли директиву на полегшену політику ревʼю дає саме керівництво компанії, і коли це узгоджено заздалегідь — тоді відповідальність за баг, що дійшов до продакшну, не лягає на конкретного погоджувача, а розподіляється між тими, хто ухвалив політику.
Модернізація «на ходу» і вартість у токенах
- Якщо систему не можна зупинити або кодова база змінюється надто швидко для окремої модернізованої копії, компанії обирають uplift — оновлення без паралельної збірки.
- Робочий підхід: розбити кодову базу на логічні партиції від «листків» усередину, заморожувати й модернізувати по одній партиції за раз.
- CI/CD налаштовують так, щоб нові коміти не могли скасувати вже модернізовану партицію.
Щодо витрат: для механічної, високооб'ємної роботи, яку повністю перевіряє сертифікат, Anthropic радить моделі на кшталт Sonnet, що балансують вартість і якість, а потужніші моделі лишати для складних трансформацій і змагальних перевірок. Перехід на дорожчу модель варто робити лише після аналізу частоти повторних спроб — кілька дешевих спроб можуть коштувати дорожче за одну дорогу. Точних цифр вартості чи термінів модернізації матеріал не наводить.