Наверное, каждый, кто занимался эксплуатацией и развитием корпоративных систем, знает эту бесконечную претензию от бизнеса: «Мы столько тратим на IT – а результата ноль. Новых продуктов нет. Или они появляются мучительно медленно». И бизнес по-своему прав. Если из каждого рубля, потраченного на IT, менее 20 копеек уходит на то, что видит клиент – скорость появления новых продуктов будет именно такой, какая она есть - неудовлетворительной.

TL;DR

• ~75% IT-бюджета банков – налог на legacy. Менее 20 центов из каждого IT-доллара доходят до клиента в виде новых продуктов. При стагнирующем бюджете – стремится к 5%.

• В 2026-м экономика переписывания впервые стала ниже экономики поддержки. Cloudflare: 194K строк за неделю, $1 100. Яндекс: 97K строк за 2 месяца вместо года. CLPS: первый AI-перенос core banking.

• AI-агенты сокращают рутину разработки на 46% (McKinsey, 4 500 разработчиков). Банки на современном ядре: +60% выручки, +40% прибыли (Accenture).

• Код стал расходником. Знания внутри него – актив. AI-миграция – это экстракция семантики, а не уничтожение легаси.

• «Работает – не трогай» было рациональной стратегией. До тех пор, пока стоимость «не трогать» не стала выше стоимости «переписать».

Масштаб проблемы: откуда 20 и куда уходят остальные 80 центов

Формально остаётся ~25%. Но это при условии, что IT-бюджет постоянно растёт – а именно так обстоят дела у крупных банков: McKinsey фиксирует рост IT-расходов в банкинге на 5–10% ежегодно. Каждый год бюджет увеличивается – и этот прирост позволяет хоть что-то направить на развитие, сохраняя legacy-часть на плаву.

Если же бюджет не растёт (или растёт медленнее инфляции технических затрат) – арифметика становится жёстче. Каждый новый продукт, выведенный в production, сам начинает генерировать техдолг: его нужно поддерживать, обновлять, патчить. Legacy-часть бюджета не сокращается – она только растёт. В такой ситуации доля «свободных денег на развитие» стремится не к 20%, а скорее к 5%. Это математика, а не пессимизм.

Чтобы почувствовать масштаб: JPMorgan Chase тратит на технологии $19.8 млрд в 2026 году. При пропорции 75/25 это ~$15 млрд на то, чтобы существующее не развалилось. CFO JPMorgan говорил об этом на Investor Day в марте 2026.

Так было раньше.

Что изменилось в 2026-м

Проблему legacy не то чтобы игнорировали. Её решали – как умели. Заливали людьми. Нанимали команды на поддержку, команды на модернизацию, команды на «параллельный бег» старого и нового. Бюджеты росли на 5–10% ежегодно – и этот прирост съехался как мы обсудили выше на легаси. Это уровень индексации затрат на персонал. Больше людей – больше кода – больше техдолга – больше людей. Замкнутый круг.

В 2026-м сошлись три обстоятельства, которые этот круг разрывают.

Экономика переписывания стала ниже экономики поддержки. Это ключевой сдвиг. Раньше «переписать с нуля» было синонимом катастрофы и удвоения бюджетов на время трансформации и миграции со сроками от года. Год и более удвоенный бюджет ИТ? ТАкое могли себе позволить единицы и только в отчаянных ситуациях, когда под вопросом весь бизнес. Теперь IDC фиксирует: 45% бюджетов модернизации в 2026 году направлены на AI-driven solutions. Не эксперименты – бюджетные строки. Stanford AI Index 2025 оценивает точность AI-конвертации legacy-кода в ~85%. Год назад было 60–70%.

AI-агенты научились работать с контекстом проекта, а не с отдельным файлом. Разница – как между калькулятором и бухгалтером. 67% разработчиков уже используют AI-инструменты, но агент нового поколения умеет прочитать кодовую базу целиком, построить граф зависимостей, спланировать миграцию и выполнить её итеративно – с само-проверкой на тестах после каждого шага. Разработчик или инженер проверяет контрольные точки, по сути принимает работу, корректирует приоритеты и формулировки, уточняет задачи.

Появились задокументированные публичные кейсы, где «переписать с нуля» заняло дни, а не годы. До 2026-го AI-миграция была теоретической возможностью. Теперь есть конкретные результаты – и именно они меняют разговор с бордом и стейкхолдерами с «давайте попробуем» на «давайте посчитаем».

📝 По данным SoftServe 2025, Bandarupalli et al. 2025, agentic-AI достигает 85–93% точности при конвертации COBOL→Java – против 75% при ручной миграции. Есть аналогичные данные и замеры от FreshBrew, точность ИИ-агентов в 5 раз превышает результаты rule-based инструментов.

Кейс 1: Cloudflare vinext – $1 100 за фреймворк

24 февраля 2026 года Cloudflare опубликовал блог-пост, который вызвал дискуссию по всему IT-сообществу.

Суть: один инженер – Стив Фолкнер, Engineering Director в Cloudflare – за одну неделю с помощью AI (Claude Opus, OpenCode) переписал с нуля Next.js – самый популярный React-фреймворк в мире. Next.js создавался большой командой Vercel на протяжении 10 лет. Результат получил название vinext. Это не прототип. У Cloudflare уже есть клиенты, использующие vinext в проде.

Кейс 2: Яндекс Браузер – 97 000 строк за 2 месяца вместо года

В мае 2026 года Яндекс опубликовал на Хабре кейс, который ближе к «нашим широтам» и потому особенно показателен.

Проблема: iOS-приложение Яндекс Браузера содержало 10 038 файлов и 541 856 строк Objective-C. Команда наложила «мораторий на новый ObjC-код» и начала ручную миграцию на Swift. За пять лет – с 2020 по 2025 – переписали лишь чуть более 50%.

Причины: огромный объём legacy, запутанные зависимости между модулями, постоянная необходимость развивать продукт. Ручное переписывание – монотонная работа, чреватая ошибками.

В 2025 году команда начала автоматизировать миграцию с помощью LLM. В результате 97 000 строк кода с Objective-C на Swift за 2 месяца – вместо года+ при ручном подходе. Яндекс сделал публикацию в open source. «Бесконечный техдолг» превратился в «воспроизводимый процесс».

Кейс 3: CLPS – core banking в Гонконге

В марте 2026 года CLPS Technology – Nasdaq-листированная IT-компания из Гонконга, специализирующаяся на банковском ПО – объявила о прохождении PoC по AI-миграции core banking system крупного банка.

Ядро банка мигрировали с устаревшего COBOL-стека (возможно значительная доля читателей даже не слышала про такой древний язык) на Java. Ключевая сложность таких кексов – нет документации и в мире физически почти не осталось разработчиков COBOL. Бизнес-логику (а это десятилетия накопленных правил, edge cases и workarounds) восстановили из «чёрного ящика» через граф знаний (knowledge graph) – AI-агент анализировал код и строил граф зависимостей и бизнес-процессов.

⭐ Knowledge graph как инструмент разработки для восстановления и передачи агенту бизнес-логики – это не экзотика, а формирующийся стандарт. Я пропагандист методологии GRACE (Graph-RAG Anchored Code Engineering), которую развивает Владимир Иванов (@turboproject), и активно применяю в своих проектах стандарты, выстроенные на её основе – включая AI Standards и открытую спецификацию GRACE. Суть подхода: семантическая разметка кодовой базы, графы знаний, контракты модулей и верификационные планы – всё то, что превращает код (в том числе «чёрный ящик» legacy) в структуру и AI-агент и человек(проще всего- задавая вопросы агенту). Если вам интересна тема – рекомендую изучить, это меняет подход к разработке и тем более миграции принципиально.

Почему это важно: это первый публично задокументированный AI-перенос core banking system. Не фронтенд. Не мобильное приложение. Жесткий банковский кор. Хардкор хардкорный на коболе. С бизнес-логикой, которую «никто не помнит, но всё на ней держится».

Экономика перехода: что это даёт бизнесу

Три кейса – доказательство возможности. Но когда ты идёшь к борду с предложением «давайте перепишем core с помощью AI», первый вопрос будет не про технологию. Он будет про деньги.

Здесь есть два уровня ответа.

Первый – операционный. McKinsey провёл крупнейшее исследование (4 500 разработчиков, 150 компаний, февраль 2026) и зафиксировал: AI-инструменты сокращают рутинные задачи разработки на 46%. Не абстрактный «productivity boost» – а конкретные часы, освобождённые от написания тестов, документации и рефакторинга. Часы, которые можно перенаправить на то, что видит клиент.

Второй – стратегический. Accenture Banking Trends 2026 даёт бизнес-результат: банки, перешедшие на современное ядро, показывают +60% к росту выручки и +40% к прибыли по сравнению с банками на legacy. Потенциал GenAI для топ-200 банков мира: $289 млрд в год. Это та цифра, которую понимает борд.

Переведём в нашу метафору: если AI-миграция позволяет сократить долю maintenance с 75% хотя бы до 30–40% бюджета (а это то, к чему пришёл JPMorgan за несколько лет и миллиарды долларов), то пропорция переворачивается. Вместо менее 20 центов из доллара – 60–70 центов идут на создание продукта. Бизнес наконец-то получает ответ на вечный вопрос «куда уходят наши деньги на IT». А IT наконец-то может перестать выгорать и оправдываться и начать строить.

Честный раздел: где это пока не работает

Хабр – не место для маркетинговых слайдов. Я сам практик, и мне важно сказать прямо, где я вижу границу между реальностью и консалтинг-хайпом.

Архитектуру AI не трогает. Исследование «Agentic Refactoring» показало: 52% AI-рефакторингов направлены на maintainability, 28% – на readability. Архитектурные изменения – менее 10%. AI отлично справляется с 80% работы – рутинной, монотонной, объёмной. Но решение «разбить монолит на микросервисы» или «перейти с event sourcing на CQRS» – это по-прежнему задача человека. AI – усилитель, не замена архитектора. Это не значит что ИИ не умеет в архитектуру, это значит что там его пока меньше используют люди.

Без дисциплины – катастрофа. На Хабре есть показательный кейс от Т2: команда попробовала AI-миграцию без изменения процесса. Снаружи всё выглядело впечатляюще – продуктивность резко выросла. А на ревью обнаружились «большие куски готового кода», в которые никто не вникал. Знакомая картина для любого, кто видел, как аутсорс-команда «быстро» делает проект. Скорость без понимания – это не скорость, а отложенные проблемы. Тут важно еще раз напомнить про методологию и процессы подход (включая AI Standards и спецификацию GRACE)

1:1 миграция ≠ модернизация. Есть соблазн думать, что переписать = улучшить. Нет. AI-агент отлично делает 1:1 перенос – ту же логику на новом стеке. Но если архитектура была плохой на COBOL, она будет плохой и на Java. Получится «новый legacy на современных технологиях». Правильный подход: сначала lift-and-shift (переехать 1:1, быстро, дёшево), потом рефакторить уже на современном стеке с современными инструментами. Переписать спагетти за неделю и рефакторить на Java – реалистичнее, чем рефакторить на COBOL, где каждый специалист на вес золота. И да – без тестов миграция = лотерея. Если покрытие ниже 40%, начинать нужно с генерации тестов, а не с переписывания кода. Регулятор не ускоряется. AI ускоряет код, но не ускоряет согласование с ЦБ. В банках полная миграция core – это reverse-engineering бизнес-правил под аудит, согласование с регулятором, параллельный бег систем под контролем compliance. Это месяцы бумажной работы, которую нельзя автоматизировать. AI сжимает ехническую часть с лет до недель – но регуляторный трек остаётся. Его нужно закладывать в план с первого дня.

Проприетарный код и облако. Вопрос скорее в отношении чем в реальной ценности и рисках. Если в коде нет секретов (а за этим тоже очень хорошо помогают следить локально развернутые агенты и работающие процессы), то ценность самого кода как интеллектуальной собственности отдельный дискуссионный вопрос. Точнее сформулирую: ценность кода как текста стремится к нулю – его можно сгенерировать за копейки. Но бизнес-логика внутри этого кода – десятилетия edge-cases, компромиссов, регуляторных workarounds – остаётся активом. Код стал расходным материалом, а знания внутри него – интеллектуальной собственностью. AI-миграция – это не уничтожение легаси, а экстракция семантики. И здесь правильно обвязанный и инструктированный агент (knowledge graph) как раз ловит этот момент: вытаскивает актив из + расходника до того, как расходник выбросят.

PoC ≠ production. Cloudflare vinext – production. Яндекс Браузер – production с миллионами пользователей. CLPS core banking – пока PoC. Промышленная AI-миграция core banking в полном объёме – ещё впереди. Но если судить по скорости развития инструментов, «PoC пройден в 2026» означает «production через 12–18 месяцев». Год назад мы не имели ни одного из этих кейсов. И да, нужно быть честным про масштаб: 194K строк (vinext) и 97K (Яндекс) – это не enterprise-монолит на 5–10 миллионов строк с двадцатилетней историей и интеграциями с mainframe. Там «дни» превратятся в месяцы, а human-in-the-loop станет bottleneck-ом. Но год назад мы не умели и сотни тысяч – а тренд экспоненциальный.

Резюме

Сегодня банк тратит доллар на IT – и менее 20 центов из него доходят до клиента в виде новых продуктов. Остальное – налог на прошлое. При стагнирующем бюджете – и того меньше.

AI-миграция legacy – это не серебряная пуля. Это не «уволить разработчиков и заменить их нейросетью». Это инструмент, который позволяет сделать то, что раньше было экономически невозможно: переписать системы, на которые не хватало(и никогда бы не хватило) ни людей, ни бюджета, ни – будем честны – мотивации. Потому что «работает – не трогай» было рациональной стратегией. До тех пор, пока стоимость «не трогать» не стала выше стоимости «переписать».

AI-миграция legacy в 2026 году уже стала инженерной практикой: с задокументированными кейсами, измеримыми результатами и open-source инструментами. Да, практика молодая, развитие идет по часам. Поэтому, для тех у кого FOMO мой список каналов практиков, которые я читаю в порядке моего личного приоритета.

1. AI Projects - Владимир Иванов. Искусственный интеллект. Управление проектами. Промптинг. Vibe coding

2. DEKSDEN notes - Денис Киселев. Канал с заметками на темы “для продолжающих” - Vibe Coding -> AI SWE, AI Coding Tools, Agents: Claude Code, Codex, news

3. Refat Talks - Рефат Аметов. Заметки про технологии, GenAI и глобал стартапы

4. The AI Architect - Тимур Хахалев пишет про AI Coding, помогает разработчикам освоить AI

В общем, вопрос не «мигрировать ли с легаси?». Вопрос – успеете ли вы перевернуть пропорцию до того, как это сделают другие за вас.

P.S. Ну и какая статья про миграцию без личного пет-проекта по миграции? 🚀

Про этот эндорфиновый опыт я хочу рассказать отдельно, а пока – тизер: 

Mark – markdown-редактор, переписанный моим агентом за выходные в одно лицо с Electron на Rust/Tauri. Мотивация прозаическая: любые редакторы на Electron (включая вс-код) жрали ресурсы на рабочей машине так, что параллельно с IDE и AI-агентами работать было невозможно. Нужен был даже не редактор, а ридер с красивым рендером и возможностью что-то поправить. Новая Tauri-версия потребляет в разы меньше памяти и стартует мгновенно. Проект в альфе. Звёзды, контрибьюшны и ишью и пр-ы – приветствуются. :)

Никто еще не голосовал. Воздержавшихся нет.