Лучший ROI ИИ прямо сейчас – исправление старого кода, а не написание нового кода

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

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

Greenfield-разработка получает ключевые слоты. Старый код получает деньги, неохотно, и обычно без понимания, необходимого для их эффективного использования.

Настоящий дефицит не в разработчиках, а в памяти

Это не изолированная проблема. Исследование Pegasystems 2025 года, проведенное исследовательской фирмой Savanta более чем 500 руководителей ИТ во всем мире, оценивает, что среднее глобальное предприятие тратит более $370 миллионов в год из-за своей неспособности эффективно модернизировать устаревшие системы, с почти $134 миллионами из них, связанных с медленными, ресурсоемкими проектами трансформации.

Мы недавно работали с компанией по распределению батарей, которая запускала более пятнадцати устаревших приложений, такого рода разрастания, которое накапливается за двадцать лет слияний, единовременных интеграций и инженеров, решающих сегодняшнюю проблему без большого учета завтрашней. В этом коде были правила ценообразования, пороги запасов и ограничения распределения, которые представляли собой годы институциональных решений, записанных нигде, кроме логики, которую никто не полностью картографировал.

Соблазнительно назвать это проблемой талантов: нанять больше разработчиков, мигрировать быстрее. Но вы не можете нанять достаточно разработчиков, чтобы компенсировать тот факт, что человек, который понимал, почему модуль работает так, как он работает, покинул компанию в 2014 году. Большинство предприятий страдают от нехватки памяти, а не от нехватки талантов. И до недавнего времени не было реального способа решить эту проблему в масштабе. Вы либо платили небольшой группе старших инженеров, чтобы они держали институциональные знания в своих головах бесконечно, либо теряли их в день их ухода.

Что ИИ действительно меняет

Мы не указали инструмент генерации кода на старую кодовую базу и не сказали ему переписать все; это примерно то, как вы тихо удаляете бизнес-логику, которую не знали, что она существует. Вместо этого мы использовали ИИ-агенты для выполнения незаметной работы сначала: отслеживания того, как более пятнадцати приложений фактически связаны друг с другом, выявления решений, встроенных в логику, которые никогда не были записаны нигде, и сохранения этого контекста как чего-то, что организация могла запросить, а не что-то, что жило только в голове одного инженера. Это соответствует тому, что другие ИИ-vendors теперь документируют публично: руководство Anthropic по модернизации систем COBOL с помощью Claude Code описывает ту же последовательность, автоматизируя фазы исследования и анализа сначала, а не переходя сразу к переписыванию.

Агенты не оценивались по количеству сгенерированного кода. Они оценивались по количеству институциональных знаний, которые они могли выявить и сохранить. Инженеры затем работали вместе с ними над фактической миграцией и генерацией тестов, проверяя интерпретацию агентов бизнес-логики против того, как система работала в производстве, не доверяя ей на веру. Полезный сигнал, за которым мы следили: совпадала ли объяснение агента правила с закономерностью, которую мы могли независимо подтвердить в производственных журналах, или это было правдоподобно звучащим предположением? Промежуток между этими двумя является именно там, где проекты модернизации наследия обычно идут не так.

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

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

Грубый каркас для выполнения этого без поломки

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

Открытие: картографирование того, как системы фактически связаны, а не того, как архитектурная диаграмма 2016 года говорит, что они связаны.

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

Проверка: проверка этой интерпретации против реального поведения в производстве, а не только против комментариев кода.

Трансформация: миграция или перестройка только после того, как первые три этапа подтвердились, с людьми, владеющими подписью.

Пропустите сразу к трансформации, и вы не модернизируете. Вы будете играть в азартные игры с логикой, которую вы еще не понимаете.

Почему это имеет значение за пределами инженерных команд

Институциональная память не просто тихо разлагается, когда старший инженер выходит на пенсию. Она становится острой ответственностью в тот самый момент, когда бизнес может себе этого меньше всего позволить: во время поглощения, когда новый владелец должен понять, что он фактически купил; во время миграции ERP, когда старая логика должна быть переведена в новую систему правильно с первого раза; во время аудита соблюдения или реагирования на инцидент, когда кто-то должен объяснить, почему система работала определенным образом, под сроком, регулирующему органу, который не принимает “человек, который построил это, ушел в 2014 году” как ответ.

Если рассматривать это таким образом, модернизация наследия перестает быть статьей инженерной линии и начинает выглядеть как вопрос организационной устойчивости, что означает, что это не только CTO, кто должен заботиться об этом. Это CIO, взвешивающие, что происходит, когда ключевой технический персонал переворачивается, команды M&A, пытающиеся оценить, что они фактически приобретают, и советы, думающие о том, сколько операционных знаний компании существует нигде, кроме кода, который никто сейчас не читает.

Замечание, которое имеет значение

Ничто из этого не работает без присмотра. Самый рискованный вариант этого подхода – это тот, где интерпретация агента старой бизнес-логики доверяется без проверки, потому что устаревшие системы являются именно тем местом, где уверенно неправильное предположение ИИ стоит дорого. Полная автономность в вашем новейшем микросервисе – это разумная ставка. Полная автономность в системе ценообразования, которую никто не трогал с 2011 года, не является таковой. Ценность заключается в том, что ИИ делает возможным стать снова инженерами, которые понимают бизнес, в системе, которую никто сейчас не понимает. Он не заменяет их.

Где, по моему мнению, это идет дальше

В течение двадцати лет предприятия рассматривали программное обеспечение наследия как нечто, от чего нужно избавиться: центр затрат, который нужно финансировать неохотно и модернизировать как можно быстрее. Я думаю, что ИИ вот-вот покажет, что многое из этого кода было на самом деле одним из самых ценных репозиториев знаний, которые бизнес когда-либо построил. Ему просто нужно было что-то, что могло его прочитать. Исследователи уже документируют другую сторону этого цикла: обзор литературы 2026 года на LLM-усиленное развитие находит, что сегодняшнее преследование ИИ-ускорения создает “долг быстрой интеграции”, код, отправленный быстрее, чем его можно понять. Модернизация наследия – это просто счет, который наконец-то пришел, на поколение раньше.

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