- Миграция legacy с ИИ получила новый инструмент: Cognition и MongoDB объявили о запуске Devin for MongoDB Modernizations 29 сентября 2026 года.
- По описанию вендоров, Devin меняет код, MongoDB AMP переносит и сверяет данные, инженеры определяют целевую модель и порядок переключения.
- Я бы начинал обновление с фиксации поведения системы, которое нужно сохранить.
- Для небольшого сервиса с проверенным сценарием переноса ИИ может оказаться лишним.
Что случилось
Cognition и MongoDB представили Devin for MongoDB Modernizations. Связка ИИ-инженера Devin и AMP – платформы модернизации приложений MongoDB – согласует изменения кода с переносом данных в MongoDB Atlas.
Devin готовит план, переписывает бизнес-логику и слой доступа к данным. Инструменты AMP переносят и проверяют записи по заданным правилам. Инженеры отвечают за устройство данных и переключение приложения. Пока это заявленная схема: обещания ускорения я бы в оценку проекта не закладывал.
Ранее Cognition объявила о сотрудничестве с AWS, включающем перенос устаревших систем в облако, и сообщила о подключении Devin к Atlas. Агент получил доступ к актуальным схемам и записям базы; теперь эту работу встроили в процесс миграции.
Что это значит для бизнеса
Я против задачи «перепишите старую систему на новый стек» без списка правил, которые нельзя потерять. Как рассчитывается заказ, резервируется товар, обрабатывается повторный запрос после сбоя? Это примеры критериев приёмки. Изменение бизнес-правил нужно согласовывать отдельно от технического переноса.
В разборе работы с COBOL в Itaú Cognition описывает тупик. Банку требовалось изменить обработку идентификатора компании. Другие агенты нарушали формат COBOL и неверно обрабатывали переменные COMP – специальное представление числовых данных. Код ломался на мейнфрейме, инженеры следили за сессиями и вручную исправляли результат.
Для Devin специалисты записали ограничения в инструкции: формат строк, обработку переменных, правила именования. Это рассказ поставщика, не независимое сравнение агентов. Мой вывод: автоматизации предшествовала работа инженеров, которые превратили знания о системе в проверяемые правила.
MongoDB в методологии AMP тоже предлагает сначала зафиксировать поведение тестами, затем преобразовывать код. Перед переключением я проверял бы согласованные результаты, сверку данных и возможность возврата. Успешной сборки кода для приёмки мало.
Как это выглядит на практике
В CRT мы развиваем подход AI Software Engineer: инженер с ИИ-инструментами ведёт задачу от бизнес-постановки до работающего решения. При миграции я жду от него чётких границ задачи.
Наш кейс Femco – система управления внутренними процессами судовладельца и оператора оффшорного флота. Это пример класса бизнес-систем, при обновлении которых я бы отталкивался от работы пользователей. Применение Devin к кейсу отношения не имеет.
Мой порядок работы:
- Описать зависимости, обмены данными и фоновые задания.
- Выбрать ограниченный участок с известными входными данными и проверяемыми результатами, поручить ИИ изменения.
- Сравнить поведение реализаций, сверить записи, разобрать расхождения с владельцем процесса.
- Определить ответственного за переключение, условия остановки и возврата, судьбу записей, появившихся после запуска.
Для российской компании я начинал бы выбор инструментов с допустимого места обработки кода и данных. А небольшой сервис с проверенным сценарием переноса спокойно обновлял бы без агента.
Вопросы и ответы
Можно ли поручить ИИ всю миграцию legacy-системы?
Я бы не передавал агенту весь процесс без ответственного инженера. ИИ можно поручить анализ и изменение кода, но критерии сохранения бизнес-логики, приёмку данных и решение о переключении должны определять люди, отвечающие за систему.
Когда обновление системы лучше отложить?
Массовое переписывание стоит отложить, если команда пока не может описать критичные сценарии и проверить результат переноса. Это повод заняться обследованием и подготовкой проверок. Если же система решает задачи бизнеса, поддерживается и не мешает развитию, сначала нужно обосновать пользу обновления.
Что делать
Я бы начал с обследования системы и согласования поведения, которое нужно сохранить. На Discovery можно определить границы переноса и критерии приёмки, затем решить, где ИИ снимет часть работы с инженера.
Обсудить задачу
