Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 21
В большинстве случаев LLM не сильно помогает в рефакторинге уникального кода, только шаблонного, повторяющегося и boilerplate.
Даже лень повторять уже:
Не восстановит скрытые смыслы
Не поймёт что лучше локальный рефакторинг или надо расширить область переделок
Логика кусочная
Не поймёт: тут надо падать или пропустить с логированием или молчаливый fallback - всё присыпет чтобы никогда не упало, а что внутри теперь мусор не волнует
Ошибки, не видные из статического анализа, нужны сначала тесты на реальных данных на реальном окружении и потом мелкими итерациями втыкать туда швы по Физерсу, добавлять всё более мелкие, простые и быстрые тесты, а для этого думать надо
Тысячи причин
Ссылки очень интересные. Но выводы неправильные, особенно для банков, госов и прочего долгоживущего продукта
markdown-редактор - пример где много общеизвестной логики, понятные мотивы и решения. Тут сработает (если не придираться к результату), но не за выходные.
"Не восстановит скрытые смыслы"
при всем уважении, но это звучит по "вайбодерски", у них там да, скрыто считай все и логика кусочная, и думать нужно как впарить себя любимого куда-то...
вы явно умный, но мало практики с взрослой агентской разработкой, по факту теперь можно "перегонять" не только самогон, но и "скрытые смыслы" в новый стек без маркетинга.
пять лет назад руками пилил на рельсе ecommerce, фронт на ember... одно легаси и скрытых смыслов там оочень норм, но несколько недель и куча токенов, и это современно, тестируемо, быстро и одно удовольствие от работы "над ошибками". (это не рельса и эмбер теперь...)
а так да, golden тесты пишет ии распрекрасно на любой черный ящик, а дальше заливаешь токенами и терпением и вуаля, новая жизнь старого ПО.
Видимо, разный класс систем.
У вас little black dress (маленький изолированный понятный домен), а у меня средневековый многослойный камзол (наслоения забытых решений и каскады ошибок / неоптимальных решений)
Не вайбодерски, конкретно: бизнес-правила, зашитые в порядок вызовов, в именах полей типа flag3, в комментариях на языке оригинальных разработчиков 30 лет назад. Чат-интерфейс их действительно не вытащит. Агентный пайплайн с knowledge-graph уже может, но требует разметки человеком.
Список ограничений по делу. Но «не восстановит скрытые смыслы» - это про чат-интерфейс, не про агентский пайплайн.
Швы по Физерсу - отличная аналогия. Golden-тесты (characterization tests) на реальных данных + мелкие итерации - именно то, что агентские системы умеют хорошо: зафиксировать поведение чёрного ящика, затем менять реализацию под контролем тестов. schekinfs ниже подтверждает это собственным опытом.
Markdown-редактор - да, простой кейс. Банковский COBOL - сложный. Статья не утверждает что всё одинаково, она утверждает что порог «дешевле переписать» сместился.
Статья полезна как маркер тренда, но её кейсы принадлежат ограниченному классу систем. 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 перенесет код, тест пройдет, но почему так — останется в черном ящике.
Точное наблюдение. Batch-отчёты в банковском COBOL - фиксация результата, а не семантики. AI перенесёт код, тест пройдёт, а «почему округление именно такое» останется в чёрном ящике.
Именно поэтому knowledge-graph подходы пытаются вытащить эту семантику в отдельный слой до начала миграции. Это не бесплатно - нужен доменный эксперт, который валидирует. Но альтернатива - тот же чёрный ящик, только на новом стеке.
тогда вопрос что такое knowledge-graph
Knowledge-graph в контексте миграции - это структурированная карта системы, которая описывает не что делает код (это видно из AST), а почему он так устроен: зависимости между модулями, контракты на границах, бизнес-правила, и связи, которые не выводятся из кода напрямую.
Без такой карты агент работает "через замочную скважину" - видит локальный контекст, но не понимает как изменение здесь аукнется там. С картой он может планировать изменения с учётом всех зависимостей, и проверять контракты после каждого шага.
Практическая реализация: GRACE (Graph-RAG Anchored Code Engineering) - https://github.com/osovv/grace-marketplace. Это набор agent skills, который ставится как плагин к агенту, которым вы уже пользуетесь - Claude Code, Codex CLI, Kilo Code. Можно буквально попросить агента "установи grace", и он подтянет skills из маркетплейса.
Что делает агент после установки:
- grace-init - строит XML-карту модулей и их границ по вашему коду
- grace-plan - планирует изменения в рамках этих границ
- grace-verification - создаёт тесты-контракты до начала рефакторинга
- grace-execute - вносит изменения порциями, проверяя контракты после каждого шага
Подход не уникальный - есть и другие решения с похожим принципом (формализовать структуру, зафиксировать контракты, менять под контролем). GRACE - один из доступных инструментов.
для kimi не подошел напрямую, но он как-то его сконвертнул
похоже, что-то полезное
спасибо, посмотрим...
Попробовал.
Не, не поможет.
В моём (распространенном) случае домен основан на легаси структуре со шрамами и патчами. Денормализованные данные, где надо ещё вспомнить где там данные первичные, где вторичные.
А если этого не знать (для LLM это естественно), то много кода строится вокруг кривых и хрупких структур.
Low coupling high cohesion нельзя спроектировать только из кода, не зная какие части будут меняться по одной причине, то есть связаны логически, по бизнес процессу.
Закономерно - и ровно поэтому в статье lift-and-shift идёт первым этапом, а не редизайн. Смысл: не трогать архитектуру, пока не перенёс 1:1 на новый стек.
Денормализация, шрамы, патчи всё переезжает as-is. А вот дальше - да, «какие части меняются по одной причине» из кода не вытащишь автоматически. Поэтому ты руками подсказываешь агенту: размечаешь бизнес-контексты, уточняешь, корректируешь. И уже на этой разметке модель сможет намного лучше строить новые модули, перестраивать и переписывать узкие места.
Без этого шага согласен - получится перекладывание кривых структур на новый язык.
Как в старом мультике "день потерять - потом за 5 минут долететь" :)
Спасибо за развёрнутый разбор.
Вы правы в главном: кейсы Cloudflare и Яндекса - lift-and-shift, где семантика очевидна. Каскадное легаси с n² сцепленностью - принципиально другой класс.
Но именно для этого класса и появляются knowledge-graph подходы (CLPS - один из них). Идея не в том чтобы «сгенерировать адаптеры быстрее», а в том чтобы формализовать семантику слоёв до начала миграции. Human-in-the-loop - не костыль, а осознанный выбор: археология бизнес-логики требует доменного эксперта, но AI радикально сокращает его время.
Согласен, что без пересмотра архитектуры получится «новый legacy на современном стеке» - в статье это оговорено специально. Ключевая ставка не на автоматизацию переноса, а на то что формализация через граф знаний делает n² видимым и декомпозируемым.
в тему
Попробовал Kimi code. Можно в командной строке, можно внутри IDE
Код пишет нормально, но медленно.
Архитектурно тупой.
Переделал контракт (формат данных) между шагами визарда. Он нашёл все зависимости, определил объём работ, какие файлы менять, написал тесты (которые все ошибки не нашли, конечно). Написал. 6 часов писал с моим участием. Потратил почти всю недельную квоту.Результат, конечно, дурной, в мусорку.Уже ближе к концу начал видеть много дублирования. Действительно, легаси данные денормализованные. Потребовал от него типизацию. Дал мне типы, указал где источник правды...
Ну и в топку всё равно: несколько раз патчил контракт без полного проектирования, по фактической боли. Получилась какая-то дичь, но работающая. Надо заново.
Что выглядело как "немного прибрать", оказалось архитектурным расслоением. Без этого шага проблема осталась бы незамеченной и превратилась в технический долг на месяцы.
Вывод: многократное неявное (в данном случае, нетипизированное) изменение контракта по фактически видной сейчас боли - большая ошибка, я одобрял каждую итерацию но когда увидел дублирование (а в исходной версии оно не было видно) то потребовал типизацию, а в типе увидел что мне все не нравится и спайк неудачен (а в реальном случае был бы технически долг)
Классический паттерн. Агент видит локальный кусок, патчит контракт, натыкается на следующую боль, патчит снова. Каждая итерация выглядит разумно, но в сумме - "дичь". Потому что нет общей картины зависимостей.
Ваш вывод про типизацию - ключевой. По сути, вы вручную сделали то, что knowledge-graph подход автоматизирует: вытащили неявные контракты в явную структуру и увидели реальный масштаб. Только у вас это случилось после 6 часов работы, а должно было - до первой строчки кода.
Подробнее про knowledge-graph и конкретный инструмент (GRACE) - в ответе на ваш вопрос выше в этом же треде. Если коротко: в вашем сценарии с визардом агент бы сначала построил карту всех зависимостей на контракт между шагами, типизировал его, и только потом начал менять - одним проходом вместо шести часов патчинга по боли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Где новые фичи?» — Как AI-миграция легаси вернет IT-бюджет бизнесу