AI-миграция кода между языками программирования
Нам часто приносят legacy-проекты, где Python-бэкенд нужно перевести на TypeScript, а Java — на Kotlin. Переписывать вручную — дорого и долго: проект на 15 000 строк занимает 3–4 месяца, а бюджет уходит в десятки тысяч долларов. Транспиляторы вроде Babel или j2objc дают нечитаемый код без учёта идиом: snake_case остаётся snake_case, а Pydantic-модели превращаются в громоздкие классы. Мы построили систему на основе LLM, которая не просто переводит синтаксис, а адаптирует архитектуру: заменяет библиотеки на идиоматические аналоги, переводит типы и валидирует результат. В этой статье делимся архитектурой и реальным кейсом миграции notification-сервиса из Python FastAPI в TypeScript.
Почему AI-миграция эффективнее ручного рефакторинга?
Ручная миграция кода — задача на недели и месяцы. AI-миграция сокращает время в 5–7 раз для проектов до 15 000 строк. При этом код получается идиоматическим: snake_case превращается в camelCase, Pydantic-модели — в Zod-схемы, а асинхронные вызовы — в нативные Promise. Наш опыт показывает, что 70–85% строк мигрируется без правок, оставшиеся 15% — сложная бизнес-логика, которую мы дорабатываем вручную. Экономия бюджета достигает 50–70% по сравнению с ручным рефакторингом.
| Критерий | Ручная миграция | AI-миграция |
|---|---|---|
| Время (15K строк) | 3–4 месяца | 3–6 недель |
| Идиоматичность кода | Зависит от разработчика | Гарантируется glossary |
| Ошибки компиляции | Много, исправляются вручную | Автофикс через LLM |
| Стоимость | Высокая (часы дорогих сеньоров) | Снижение затрат на 50–70% |
Как устроена архитектура AI-миграции?
Наивный подход — скормить LLM весь файл и попросить перевести — работает только для файлов до 200–300 строк. Для реальных кодовых баз мы используем четырёхкомпонентную архитектуру:
- Dependency Analyzer — строит граф зависимостей между модулями и определяет порядок миграции. Использует AST для анализа импортов.
- Chunk Splitter — разбивает файлы на независимые чанки (классы, функции, модули), которые можно мигрировать и тестировать изолированно.
- Context Manager — передаёт в LLM уже мигрированные зависимости, чтобы новые файлы использовали правильные импорты.
- Validator — компилирует и тестирует мигрированный код, при ошибках запускает автофикс.
Ключевой элемент — Glossary: словарь соответствий библиотек исходного языка и целевого. Например, Pydantic → Zod, SQLAlchemy → Prisma, FastAPI → Express+Hono.
Пример конфигурации Glossary для пары Python→TypeScript
# source: Python, target: TypeScript pydantic.BaseModel: zod.ZodObject sqlalchemy.orm.Session: prisma.PrismaClient fastapi.FastAPI: express.Application Как мы мигрируем ваш проект: этапы
- Анализ и подготовка glossary — изучаем исходную кодовую базу, строим граф зависимостей, настраиваем соответствия библиотек. Занимает 1–2 дня.
- Миграция изолированных модулей — сначала переносим модели, утилиты, затем сервисы и роуты. Каждый файл компилируется и тестируется отдельно.
- Интеграция и автофикс — объединяем мигрированные модули, запускаем полную сборку. При ошибках компиляции система автоматически исправляет их через LLM.
- Тестирование — прогоняем unit-тесты (jest/vitest) и интеграционные тесты. Если покрытие падает более чем на 10%, дорабатываем тесты вручную.
- Сдача результатов — передаём код, документацию glossary, отчёт о покрытии и инструкцию по повторной миграции.
Практический кейс: Python microservice → TypeScript
Контекст: стартап мигрировал notification-сервис (Python FastAPI, 3200 строк) в TypeScript для унификации стека (фронтенд команда знала только JS/TS).
Объём: 28 файлов, 12 Pydantic моделей, 34 API endpoints, 180 юнит-тестов. Процесс (2 недели):
- Неделя 1: настройка glossary, миграция моделей и утилит (автоматически), ручная доработка 3 сложных файлов с бизнес-логикой.
- Неделя 2: миграция роутов, адаптация тестов (Jest), интеграционное тестирование.
Результаты:
- 85% кода мигрировано автоматически без ручных правок.
- 15% потребовало доработки (сложная логика с Python-специфичными идиомами).
- TypeScript compilation errors: 47 → 0 (после 2 итераций LLM fix).
- Test coverage мигрированного сервиса: 71% (было 74% в Python — минимальная потеря).
- Неожиданный плюс: в процессе миграции AI выявил 3 места с потенциальными race conditions в Python коде, которые были исправлены в TypeScript версии.
Мы ожидали автоматизацию только простых файлов, но система справилась с 85% кода — это сэкономило нам 3 недели ручной работы. — отметил стартап-инженер.
Что входит в результат миграции?
Мы передаём полный пакет:
- Мигрированный код на целевом языке (вся кодовая база).
- Документация glossary (соответствия библиотек).
- Настроенный пайплайн компиляции и тестирования.
- Отчёт о покрытии тестами.
- Инструкция по повторной миграции при обновлениях.
Каждый мигрированный файл компилируется с флагом strict. При ошибках запускается автофикс через LLM. После миграции всех файлов прогоняются unit-тесты (jest) и интеграционные тесты. Если покрытие падает более чем на 10%, мы дорабатываем тесты вручную. Весь процесс повторяем до полного успеха.
Сколько времени занимает миграция?
| Этап | Сроки | Доля работ |
|---|---|---|
| Прототип одного файла | 1–2 дня | 10% |
| Dependency Graph + batch | ~1 неделя | 30% |
| Валидация + автофикс | ~1 неделя | 30% |
| Полная миграция проекта | 3–6 недель (с QA) | 30% |
Свяжитесь с нами для консультации по миграции кодовой базы. Получите анализ вашего проекта за 1–2 дня и узнайте точную экономию времени и бюджета. Закажите консультацию — мы проанализируем ваш проект и предложим оптимальный подход.