Что опубликовала Mistral
9 сентября Mistral описала проект для европейского энергетического оператора: около 40 тысяч строк Fortran 77 переводили в современную систему на C++. Важно, что команда не называет работу простым синтаксическим переводом. Старый код содержал глобальное состояние через COMMON-блоки, неявную типизацию и архитектурные решения своего времени. Агентам пришлось помогать инженерам восстанавливать поведение системы, выделять компоненты и проверять эквивалентность. Это производственный кейс компании, а не независимый универсальный бенчмарк, поэтому его выводы нужно переносить осторожно.
Почему 40 тысяч строк — не главная цифра
Объём выглядит убедительно, но не показывает сложность автоматически. Тысяча строк расчётного ядра может быть важнее десятков тысяч повторяющейся обвязки. Перед оценкой своего проекта нужно измерить число входов и выходов, внешние зависимости, скрытое состояние, покрытие тестами и стоимость неверного расчёта. Если компания просто обещает «перевести столько же строк», она продаёт счётчик символов. Рабочая цель звучит иначе: сохранить подтверждённое поведение, убрать конкретные риски сопровождения и обеспечить понятный откат.
Сначала зафиксируйте старую систему
До первого изменения соберите воспроизводимую сборку, контрольные входы и эталонные результаты. Если старый код запускается только на одном сервере и никто не знает версию компилятора, миграция начинается с археологии. Запишите окружение, библиотеки, форматы файлов и рабочие расписания. Для расчётной программы сохраните не только финальную цифру, но и промежуточные значения на ключевых этапах. ИИ может объяснить фрагмент и предложить тест, но не способен угадать договорённость, которая десять лет жила только в практике оператора.
Разделите понимание и переписывание
Первый агент строит карту модулей, переменных и потоков данных. Второй предлагает современное представление отдельного узла. Инженер проверяет границы и добавляет тесты. Только затем код переписывается небольшим блоком. Такой порядок медленнее эффектной демонстрации, зато ошибка остаётся локальной. Не просите модель одновременно объяснить весь репозиторий, спроектировать новую архитектуру и переписать её: контекст станет перегруженным, а проверяющий потеряет происхождение решений.
Как проверить функциональную эквивалентность
Запускайте старую и новую версии на одном наборе входов. Для численных расчётов заранее задайте допустимое отклонение и причину: смена порядка операций может изменить последние знаки, но не должна менять физический вывод. Добавьте граничные случаи, пустые значения, максимальную нагрузку и известные исторические сбои. Различие не исправляют автоматически. Его классифицируют как ошибка миграции, исправление старого дефекта или намеренное изменение требований, после чего решение подтверждает владелец процесса.
Где агент особенно полезен
Модель хорошо ускоряет поиск зависимостей, черновую документацию, подготовку тестов и перевод повторяющихся конструкций. Она может предложить имена, выделить функцию из глобального состояния и найти похожие блоки. Самые опасные участки — численная точность, память, параллелизм и неявные правила обработки ошибок. Здесь ответ модели рассматривается как гипотеза. Любая правка проходит компилятор, статический анализ, тесты и ревью человека, который понимает предметную область.
Как считать экономику проекта
Сравните не скорость написания нового кода, а стоимость завершённого проверенного модуля. В неё входят подготовка эталонов, исправления, инфраструктура, экспертиза и параллельная поддержка двух систем. Отдельно считайте дефекты, найденные до и после приёмки. ИИ может уменьшить ручную работу, но первые недели часто увеличивают нагрузку на ревью: команда учится отличать правдоподобную реконструкцию от реального поведения. Бюджет должен включать этот период, а не строиться на лучшем демонстрационном проходе.
Что сделать руководителю сегодня
Выберите один модуль с понятным владельцем и измеримым выходом. Зафиксируйте сборку, десять контрольных сценариев, допустимые отклонения и процедуру отката. Дайте агенту сначала составить карту зависимостей, не разрешая менять код. Сверьте её с двумя инженерами. Затем перепишите один небольшой компонент в отдельной ветке и сравните результаты. Если процесс нельзя воспроизвести на узком фрагменте, масштабирование на весь legacy-контур только умножит неизвестность. Кейс Mistral полезен именно дисциплиной поэтапной проверки, а не обещанием заменить команду миграции.
Вопросы к кейсу
Можно ли повторить подход без Mistral? Да, метод не зависит от одной модели, но качество и инструменты нужно тестировать. Достаточно ли автотестов? Нет, если они проверяют только старые счастливые пути. Стоит ли сразу менять архитектуру? Только после фиксации поведения и по небольшим границам. Кто принимает результат? Инженер и владелец процесса, а для критических расчётов — профильный специалист. Успех — это не новый язык, а система, которая воспроизводит нужное поведение, лучше наблюдается и может безопасно заменить старую.