Найкращий ROI від штучного інтелекту зараз полягає в тому, щоб виправляти старий код, а не писати новий

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

Більш значуща робота відбувається в місці, яке значно менш гламурне: всередині кодової бази十五річної давності, яку ніхто не хоче торкатися, написаної інженерами, які покинули компанію десять років тому, і яка містить бізнес-логіку, яку ніхто не повністю зрозумів за роки. Більшість матеріалів про штучний інтелект сприймає це у зворотному порядку. Старий код не є технічним боргом. Це накопичений бізнес-інтелект: десятиліття рішень, закодованих у вигляді програмного забезпечення, з людьми, які приймали ці рішення, давно пішли.

Greenfield-розробка займає ключові слоти. Старий код отримує гроші, неохоче, і зазвичай без розуміння, необхідного для їх витрат.

Наступна нестача не розробників, а пам’яті

Це не ізольована проблема. За даними дослідження Pegasystems 2025 року, проведеного дослідницькою фірмою Savanta серед понад 500 керівників ІТ-відділів у світі, середній глобальний корпоративний клієнт марнує понад $370 мільйонів доларів на рік через свою нездатність ефективно модернізувати старі системи, з яких майже $134 мільйонів пов’язані з повільними, ресурсоємними проектами трансформації.

Ми нещодавно працювали з компанією з розподілу батарей, яка використовувала понад十五 старих програм, такого роду розосередженості, яке накопичується за двадцять років злиття, одиничних інтеграцій та інженерів, які розв’язують сьогодні проблему, не думając про завтрашню. У цьому коді були правила ціноутворення, пороги запасів та обмеження розподілу, які представляли роки інституційних рішень, записаних ніде, окрім логіки, яку ніхто не повністю відобразив.

Це спокусительно назвати це проблемою талантів: найняти більше розробників, міґрувати швидше. Але ви не можете найняти достатньо розробників, щоб компенсувати той факт, що людина, яка розуміла, чому модуль працював певним чином, покинула компанію у 2014 році. Більшість підприємств страждають від нестачі пам’яті, а не нестачі талантів. І до останнього часу не було реального способу вирішити цю проблему у великому масштабі. Ви або платили декільком старшим інженерам, щоб вони тримали інституційний знання у своїх головах назавжди, або втрачали його в день їхнього відходу.

Що штучний інтелект насправді змінює

Ми не вказали інструмент генерації коду на стару кодову базу і не сказали йому переписати все; це приблизно те, як ви тихо видаляєте бізнес-логіку, про яку ви не знали, що вона існує. Замість цього ми використали агенти штучного інтелекту, щоб зробити не гламурну роботу спочатку: відстежити, як понад十五 програм насправді пов’язані між собою, поверхнути рішення, закладені в логіку, які ніколи не були записані ніде інше, і тримати цей контекст як щось, що організація могла б запитати, а не щось, що живе тільки в голові одного інженера. Це збігається з тим, що інші постачальники штучного інтелекту зараз публікують: порада Anthropic щодо модернізації систем COBOL за допомогою Claude Code описує той же самий порядок, автоматизуючи фази дослідження та аналізу спочатку, а не переходячи безпосередньо до переписування.

Агентів не оцінювали за кількістю згенерованого коду. Їх оцінювали за кількістю інституційного знання, яке вони могли поверхнути та зберегти. Інженери працювали поряд з ними над фактичною міграцією та генерацією тестів, перевіряючи інтерпретацію агентів бізнес-логіки проти того, як система поводилася у виробництві, не довіряючи їй на віру. Корисний сигнал, за яким ми спостерігали: чи відповідає пояснення агента правила збігалося з закономірністю, яку ми могли незалежно перевірити у виробничих журналах, чи це була правдоподібна гіпотеза? Пропуск між цими двома саме там, де проекти модернізації старих систем зазвичай йдуть не так.

Первоначальна оцінка проекту становила вісім з половиною місяців. Він був завершений за чотири, що означало скорочення на 53%. Але більш тривалим результатом не був графік. Інституційний знання, яке раніше випаровувалося кожного разу, коли інженер покидав компанію, стало чимось, що організація могла фактично зберегти.

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

Приблизний каркас для виконання цього без порушення речей

Проекти, які проходять добре, здаються такими, що слідують приблизно одній і тій же послідовності, незалежно від того, чи це система ціноутворення, чи система обробки вимог;

Відкрити: відобразити, як системи фактично пов’язані, а не як архітектурна схема з 2016 року говорить, що вони пов’язані.

Розуміти: щоб агент поверхнув бізнес-логіку та припущення, що стоять за нею, у звичайній мові, яку експерт з області може перевірити.

Перевірити: перевірити цю інтерпретацію проти реальної поведінки у виробництві, а не тільки проти коментарів коду.

Трансформувати: міґрувати або перебудувати тільки після того, як перші три стадії витримали, з людьми, які володіють підписом.

Пропустити безпосередньо до Трансформації, і ви не модернізуєте. Ви граєте в азартні ігри з логікою, яку ви ще не розумієте.

Чому це має значення за межами інженерних команд

Інституційний знання не просто тихо розпадається, коли старший інженер йде на пенсію. Воно стає гострою відповідальністю в тих моментах, коли бізнес може найменше цього дозволити: під час придбання, коли новий власник потребує розуміння того, що він фактично придбав; під час міграції ERP, коли стара логіка повинна бути перекладена в нову систему правильно вперше; під час auditу відповідності або реагування на інцидент, коли хтось повинен пояснити, чому система поводилася певним чином, під терміном, для регулятора, який не прийме “людина, яка побудувала це, пішла у 2014 році” як відповідь.

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

Важлива застереження

Жодна з цих речей не працює без нагляду. Найбільш ризикована версія цього підходу – це та, де інтерпретація агентом старої бізнес-логіки довіряється без перевірки, оскільки старі системи – це саме те місце, де впевнена помилкова припущення штучного інтелекту коштує найбільшого. Повна автономія над вашим новим мікросервісом – це розумна ставка. Повна автономія над системою ціноутворення, яку ніхто не торкався з 2011 року, – це не так. Користь полягає в тому, що штучний інтелект робить можливим знову стати інженерами, які розуміють бізнес, у системі, яку зараз ніхто не розуміє. Він не замінює їх.

Куди, на мою думку, це йде далі

Підприємства протягом двадцяти років розглядали старе програмне забезпечення як щось, від чого потрібно втекти: центр витрат, який потрібно фінансувати неохоче і модернізувати якомога швидше, щоб дозволити бюджет. Я думаю, що штучний інтелект ось-ось показує, що багато з цього коду насправді було одним з найбільш цінних сховищ знань, які бізнес коли-небудь побудував. Йому просто потрібно було щось, що могло б його прочитати. Дослідники вже документують іншу сторону цього циклу: огляд літератури 2026 року про розвиток з допомогою великих мовних моделей виявляє, що сучасне прагнення до прискорення за допомогою штучного інтелекту створює “борг швидкої інтеграції”, код, який відправляється швидше, ніж його можна зрозуміти. Модернізація старих систем – це просто той рахунок, який нарешті надходить, за покоління раніше.

Я був би цікавий, чи інші керівники інженерних та технологічних напрямків бачать ту саму зміну: чи з’являється повернення інвестицій у штучний інтелект більше в тому, що ви будуєте, чи в тому, що ви нарешті можете зрозуміти та зберегти? І для тих, хто намагався запускати агенти штучного інтелекту проти真正ої старої, недокументованої системи, де розуміння агента витримувало перевірку, а де воно тихо розпадалося?