Комментарии 7
В большинстве случаев LLM не сильно помогает в рефакторинге уникального кода, только шаблонного, повторяющегося и boilerplate.
Даже лень повторять уже:
Не восстановит скрытые смыслы
Не поймёт что лучше локальный рефакторинг или надо расширить область переделок
Логика кусочная
Не поймёт: тут надо падать или пропустить с логированием или молчаливый fallback - всё присыпет чтобы никогда не упало, а что внутри теперь мусор не волнует
Ошибки, не видные из статического анализа, нужны сначала тесты на реальных данных на реальном окружении и потом мелкими итерациями втыкать туда швы по Физерсу, добавлять всё более мелкие, простые и быстрые тесты, а для этого думать надо
Тысячи причин
Ссылки очень интересные. Но выводы неправильные, особенно для банков, госов и прочего долгоживущего продукта
markdown-редактор - пример где много общеизвестной логики, понятные мотивы и решения. Тут сработает (если не придираться к результату), но не за выходные.
"Не восстановит скрытые смыслы"
при всем уважении, но это звучит по "вайбодерски", у них там да, скрыто считай все и логика кусочная, и думать нужно как впарить себя любимого куда-то...
вы явно умный, но мало практики с взрослой агентской разработкой, по факту теперь можно "перегонять" не только самогон, но и "скрытые смыслы" в новый стек без маркетинга.
пять лет назад руками пилил на рельсе ecommerce, фронт на ember... одно легаси и скрытых смыслов там оочень норм, но несколько недель и куча токенов, и это современно, тестируемо, быстро и одно удовольствие от работы "над ошибками". (это не рельса и эмбер теперь...)
а так да, golden тесты пишет ии распрекрасно на любой черный ящик, а дальше заливаешь токенами и терпением и вуаля, новая жизнь старого ПО.
Видимо, разный класс систем.
У вас little black dress (маленький изолированный понятный домен), а у меня средневековый многослойный камзол (наслоения забытых решений и каскады ошибок / неоптимальных решений)
Статья полезна как маркер тренда, но её кейсы принадлежат ограниченному классу систем. Cloudflare переписывал well-known фреймворк (Next.js) на известные паттерны. Яндекс мигрировал мобильное приложение с одного императивного языка на другой в рамках той же платформенной парадигмы. Это lift-and-shift (переход на новый похожий стек 1:1) или boilerplate-rich задачи, где семантика очевидна. CLPS это пока Proof of concept, и там явно используется knowledge graph как human-in-the-loop прослойка для восстановления бизнес-логики, то есть без археологии не обошлось.
Для каскадного легаси, где каждый слой решений кристаллизовался в контракты и стал ограничением для следующего так называемый AI не решает проблему масштаба. Пробой одного слоя легаси требует адаптации всех слоев выше, давая n² объем работы. AI-агент может сгенерировать адаптеры быстрее человека, но если архитектура не пересмотрена, получится новый legacy на современном стеке, как и предупреждает сам автор статьи.
дело в том, что если в броузере открыть "чатыджипити" и кинуть туда много кобола, то ваши выводы подтвердятся - ИИ это глупая и малополезная игрушка.
но если это в пайплан, то и контракты и архитектура, и все спрятанные хитрюшки, не проблема вовсе, и не нужны модели сильно умные и большие, просто правильно их готовить и запускать, проверять (не глазами и руками, и тем более не человеком рядом, если только дедушку вызвать с пенсии для антуража)
Допустим, старый Кобол хорошо обложен старыми тестами, которые сделали умные люди. Тогда у вас в результате есть короткая надёжная петля проверки.
Тогда это не подходит под определение легаси
Второе: в реальном банковском COBOL тесты обычно не unit, а интеграционные через batch-отчеты. Они проверяют, что на выходе цифра совпадает, но не объясняют, почему округление именно такое, или почему проводка разбивается на две строки при определенном условии. Это фиксация результата, а не семантики. AI перенесет код, тест пройдет, но почему так — останется в черном ящике.



«Где новые фичи?» — Как AI-миграция легаси вернет IT-бюджет бизнесу