Как Claude Code переписал Bun на Rust: руководство по шестиэтапной миграции крупномасштабного кода

Введение

Раньше миграция между крупными языками программирования была тем типом проектов, которые инженерные команды откладывали на годы. Такие миграции дороги, разрушительны и сопряжены с огромными рисками. Компания могла потратить несколько кварталов на поддержку двух версий реализации одновременно, а в итоге получить замену, поведение которой не совпадает с оригиналом.

Claude Code меняет эту ситуацию.

Anthropic недавно опубликовала свой процесс массовой миграции кода с использованием ИИ-агентов. Самый яркий пример — создатель Bun Джаред Самнер, который перенес ядро Bun с Zig на Rust. Менее чем за две недели рабочий процесс Claude Code сгенерировал более миллиона строк кода, а существующий набор тестов Bun прошел непрерывную интеграцию еще до слияния.

Этот проект не был выполнен путем передачи модели команды "перепиши Bun на Rust" и ожидания идеального ответа. Он опирался на тщательно продуманную систему, включающую руководства по правилам, карты зависимостей, механические очереди, adversarial-проверяющих, компиляторы, дымовые тесты и проверки согласованности поведения.

Ключевой урок очевиден: при миграции такого масштаба разработчики не должны тратить большую часть времени на исправление отдельных файлов. Они должны улучшать процесс генерации, проверки и валидации этих файлов.

Создатель Bun переписал более миллиона строк кода с помощью ИИ

Изначально Джаред Самнер создал Bun на Zig. Этот язык позволил независимому разработчику получить как низкоуровневый контроль и производительность, сравнимую с C, так и не сталкиваться со всей сложностью экосистемы крупных системных языков.

Этот выбор помог Bun быстро развиваться на ранних этапах. Самнер рассказывал, что написал первую версию в небольшой квартире в Окленде примерно за год, еще до появления современных кодовых моделей.

К 2026 году Bun стал широко используемой средой выполнения JavaScript и TypeScript, менеджером пакетов, тестовым бегунком и инструментом сборки. Его утилита командной строки загружается десятки миллионов раз в месяц, и такие продукты, как Claude Code, сильно зависят от Bun.

Рост также сделал старые инженерные компромиссы трудно игнорируемыми.

Bun объединяет сборщик мусора JavaScript с вручную управляемой нативной памятью. В Zig разработчики должны явно продумывать выделение, очистку, пути ошибок и жизненный цикл объектов. Команда Bun вложила значительные усилия в санитайзеры, фаззинг, безопасную сборку и тесты на утечку памяти, но ошибки use-after-free, двойного освобождения, утечки и ошибки жизненного цикла продолжали возникать.

Rust предлагает другую основу. Его система владения, borrow checker и автоматическая очистка могут превратить многие проблемы с памятью во время выполнения в ошибки компиляции.

Исторически это преимущество не оправдывало полную перезапись. Bun содержит сотни тысяч строк кода на Zig, плюс множество нативных интеграций. Традиционная перезапись могла занять у небольшой инженерной команды год или больше, одновременно замедляя разработку функционала и исправления безопасности.

Claude Code сделал полностью механическую миграцию возможной.

11 дней с Zig на Rust

Самнер использовал предрелизную версию Claude Fable 5 и динамические рабочие процессы Claude Code для выполнения миграции.

Основное написание и проверка

Процесс непрерывно работал 11 дней. Около 50 динамических рабочих процессов обрабатывали различные этапы, в том числе:

• Создание руководства по переносу с Zig на Rust
• Картографирование жизненного цикла памяти
• Преобразование файлов .zig в файлы .rs
• Проверка каждого сгенерированного файла
• Исправление ошибок компилятора
• Восстановление отдельных команд Bun
• Запуск полного набора тестов
• Рефакторинг и очистка сгенерированного кода

При пиковой пропускной способности рабочий процесс выдавал около 1300 строк кода в минуту. Каждая сгенерированная единица кода проходила проверку двумя независимыми adversarial-проверяющими, после чего фиксатор применял подтвержденные изменения.

Итоговый pull request добавил более миллиона строк кода в более чем 2000 измененных файлов.

До слияния существующий набор тестов Bun проходил CI. После слияния возникло 19 регрессий, которые, по сообщению Anthropic, все были исправлены. Портированная версия на Rust была выпущена с Claude Code в июне 2026 года.

Этот результат не доказывает, что первоначально сгенерированный миллион строк кода был правильным. Самнер четко указал, что самые ранние результаты перевода не работали. Ключ к успеху заключался в системе обратной связи, которая постепенно превращала неработающий вывод в скомпилированный, протестированный, поведенчески совместимый код.

Стоимость миграции составила около 165 000 долларов (по ценам API)

Миграция Bun потребовала примерно:

• 5,9 миллиардов некешированных входных токенов
• 690 миллионов выходных токенов
• Около 165 000 долларов по ценам API

Это немалая сумма, но она все еще значительно ниже стоимости миграции, традиционно требующей нескольких штатных инженеров на годы.

Anthropic оценивает, что ранее миграции уровня миллионов строк могли занять четыре года и стоить от 3 до 4 миллионов долларов инженерных ресурсов. ИИ изменил бизнес-логику, потому что миграция больше не требует решения проблемы выживания для оправдания затрат.

Постоянные ошибки памяти, стареющие языковые экосистемы, дорогие процессы сборки или повторяющиеся узкие места обслуживания теперь могут быть достаточным основанием для оценки миграции.

Однако сравнения следует делать с осторожностью. Стоимость токенов — не общая стоимость проекта. Команде также требуется ручное планирование, инфраструктура, тестирование, проверка кода, безопасность и обслуживание после слияния.

Почему Bun мигрировал с Zig на Rust

Эта миграция была вызвана в первую очередь соображениями надежности, а не сырой скорости.

Bun уже отлично работал на Zig. Проблема заключалась в безопасной координации вручную управляемой нативной памяти со сборщиком мусора JavaScript.

Типичные категории сбоев включали:

• Ошибки использования после освобождения
• Ошибки двойного освобождения
• Утечки памяти на путях исключений
• Недействительные указатели из-за повторных вызовов
• Пропущенный код очистки
• Предположения о жизненном цикле, которые трудно последовательно реализовать

В безопасном Rust многие из этих ошибок не проходят компиляцию. Значения имеют четкое владение, очистка ресурсов привязана к жизненному циклу объекта, а компилятор проверяет ссылки до запуска программы.

Целью миграции было сохранение существующей архитектуры, структур данных, поведения и производительности Bun. Она была намеренно ближе к механическому переносу, чем к полному редизайну.

Это решение было критически важным. Если бы вы перепроектировали систему и одновременно меняли язык, сравнение поведения стало бы чрезвычайно сложным.

Второй пример: 165 000 строк кода Python переведены на TypeScript

Джаред Самнер — не единственный инженер Anthropic, использующий Claude Code для крупных миграций.

Соруководитель Anthropic Labs, сооснователь Instagram Майк Кригер за выходные мигрировал внутреннюю кодовую базу Python в около 165 000 строк кода TypeScript.

Основная миграция потребовала около 27 миллионов токенов, включая:

• Сотни интеллектуальных агентов
• Восемь этапов
• Три раунда adversarial-проверки
• Финальную проверку согласованности
• Последовательное сравнение вывода с Python-версией
• Сгенерированные ИИ end-to-end тесты

Исходный инструмент должен был поставляться как единый бинарный файл. При использовании инструментария Python компиляция на каждой платформе занимала около восьми минут, а полная матрица сборки задерживала каждый релиз примерно на 30 минут.

После миграции на TypeScript:

• Время компиляции сократилось до примерно двух секунд
• Запуск бинарного файла ускорился примерно в шесть раз
• Можно было отказаться от отдельных конвейеров развертывания

Кригер не полагался на существующий всеобъемлющий кроссязычный набор тестов. Вместо этого Claude

Создан фреймворк консистентного тестирования, охватывающий семь реальных сценариев, после чего сравнивались результаты работы старой и новой реализаций.

Клод также разработал дополнительные сквозные тесты и запускал их четыре ночи подряд, исправляя неудачные случаи и повторяя процесс. Это выявило тонкие различия в поведении, не предусмотренные исходными сценариями.

Почему крупные переносы кода подходят для ИИ-агентов

Крупные миграции пугают из-за огромного количества однотипных изменений. Именно эти характеристики делают их подходящими для рабочих процессов с ИИ-агентами.

Работа параллелизуема

Большие кодовые базы обычно можно разбить на файлы, пакеты, крейты, модули или группы зависимостей. Независимые агенты могут одновременно обрабатывать независимые единицы.

Граф зависимостей определяет, какие единицы можно продвигать параллельно, а какие должны ждать.

Существующий код как спецификация

Исходная реализация уже содержит необходимое поведение, граничные случаи, структуры данных и детали интеграции.

Модели не нужно создавать функциональность продукта — их задача сохранить существующую систему на новом языке или в новом фреймворке.

Тесты как объективная оценка

Агенты работают лучше, когда могут механически оценивать собственный вывод.

Компилятор, набор тестов, сравнение различий в выводе, бенчмарки или фреймворк консистентного тестирования дают системе конкретные сигналы. Агент может постоянно улучшаться без ручной оценки каждой промежуточной попытки.

Очередь задач создаётся автоматически

Ошибка компиляции становится следующей задачей, проваленный тест — следующей задачей, сбой программы — следующей задачей.

Это превращает

крупную миграцию в очередь, которая постоянно уменьшается.

Повторяющиеся ошибки ведут к улучшению правил

Когда рецензент обнаруживает одну и ту же проблему в нескольких файлах, лучшее решение — не исправлять каждый файл вручную.

Следует обновить руководство по правилам и повторно сгенерировать затронутые пакеты. Это предотвращает повторение той же ошибки в дальнейшей работе.

Основной принцип: исправляйте процесс, а не отдельные файлы

Важнейшая идея процесса Anthropic: рассматривать сгенерированный код как результат работы системы.

Предположим, 200 переведённых файлов содержат одну и ту же ошибку владения. Ручное исправление этих файлов может устранить видимые ошибки, но рабочий процесс может снова породить ту же ошибку.

Более эффективный метод:

1. Выявить шаблон повторяющихся ошибок.
2. Определить, какое правило миграции их вызвало.
3. Обновить руководство по правилам.
4. Повторно сгенерировать только затронутые файлы.
5. Повторно запустить цикл проверки и валидации.

Код улучшается потому, что оптимизируется производственный процесс.

Это похоже на обычную программную инженерию. Повторяющийся дефект производства должен привести к улучшению тестов, правил типов, статических проверок или процесса — а не просто к очередному изолированному патчу.

Предварительные условия: создание надёжного механизма оценки

Перед началом масштабной миграции необходимо определить, как команда будет доказывать корректность новой реализации.

Без механизма оценки невозможно определить надёжные критерии завершения.

Механизм оценки должен оценивать исходную и целевую реализации в равных условиях. Существующие тесты могут полагаться на приватные функции или внутренние механизмы, специфичные для языка, которые исчезнут при переносе.

Anthropic рекомендует три подготовительных шага:

1. Классифицировать существующие тесты. Отделить тесты, проверяющие публичное поведение, от тестов, зависящих от внутренней реализации.
2. Переписать тесты для переносимости. Преобразовать внешне наблюдаемое поведение в утверждения, которые могут работать в обеих системах.
3. Валидировать механизм оценки. Убедиться, что исходная реализация проходит тесты, затем намеренно сломать программу и проверить, что механизм оценки фиксирует сбой.

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

У Bun есть значительное преимущество: большая часть его тестов написана на TypeScript, а не на Zig, поэтому один и тот же набор тестов может проверять реализацию на Rust.

Для проектов без такого преимущества можно использовать инструменты для сравнения фактического ввода-вывода между двумя версиями.

Шестишаговый фреймворк миграции кода от Anthropic

Anthropic обобщил опыт этих проектов в следующий шестишаговый процесс.

Изображение показывает предложенный Anthropic шестишаговый фреймворк миграции кода. Первый шаг — создание карты и правил, включая автора руководства, маппер зависимостей, инвентаризацию пробелов и т.д.; второй шаг — стресс-тестирование правил, с двойным переводчиком, инспектором различий и т.д.; третий шаг — перевод всего, с исполнителем, рецензентом и т.д.; четвёртый шаг — компиляция, с исследованием сборки, параллельным исправителем и т.д.; пятый шаг — запуск, с дымовым тестированием, исправителем и т.д.; шестой шаг — сопоставление поведения, с демоном сборки, исправителем и т.д. Внизу также перечислены общие документы, инфраструктура выполнения и т.д. Это визуализация описанного выше шестишагового фреймворка Anthropic.

Шаг 1: Создание руководства по правилам, графа зависимостей и списка пробелов

Первый этап создаёт общие документы, которым будут следовать все последующие агенты.

Составление руководства по правилам

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

Для миграций, сохраняющих структуру, руководство может включать:

• Отображение типов
• Обработку ошибок

Соглашения по правилам

• Соглашения об именовании
• Правила памяти и владения
• Спецификации замены стандартной библиотеки
• Шаблоны конкурентности
• Расположение файлов и модулей
• Правила для внешних интерфейсов функций
• Шаблоны, требующие ручной проверки

В рефакторинге проектирования руководство по правилам больше напоминает архитектурный документ.

Джарред Самнер, взаимодействуя с Claude и проводя ручную проверку, создал руководство по переносу Bun. Финальная версия насчитывает сотни строк.

Создание карты зависимостей

Репозиторий должен быть разделён в порядке зависимостей.

Детерминированный скрипт может сгенерировать карту зависимостей, проверяя импорты, манифесты, файлы сборки и символьные связи. Результат помогает оркестратору определить, какие файлы можно преобразовывать независимо, а какие следует обрабатывать совместно.

Составление списка пробелов

Исходный и целевой языки следуют разным правилам.

Для миграции с Zig на Rust основным пробелом является владение памятью. Для миграции с Python на TypeScript неявные формы объектов и интерфейсы должны быть преобразованы в явные контракты.

Список пробелов должен фиксировать аспекты, которые нельзя решить простым переводом, в частности:

• Скрытые предположения исходного языка
• Отсутствующие абстракции целевого языка
• Поведение времени выполнения, требующее явного указания
• Неподдерживаемые библиотеки
• Платформенно-зависимый код
• Небезопасные границы
• Области, требующие перепроектирования или ручного решения

Руководство по правилам следует создавать до списка пробелов, поскольку список пробелов частично зависит от того, что не могут обработать обычные правила.

Шаг 2: Стресс-тестирование правил

Не переводите тысячи файлов сразу.

Выберите несколько сложных и репрезентативных файлов для небольшого однократного пробного запуска. Цель — выявить дефекты правил до того, как они распространятся по всему репозиторию.

В пробном запуске для Bun:

1. Первый агент перевёл три файла в соответствии с руководством по правилам.
2. Другой агент перевёл те же файлы с точки зрения старшего инженера Rust.
3. Средство сравнения проверило различия.
4. Рецензент отметил отсутствующие или ошибочные правила миграции.
5. Переведённые файлы были отброшены.

Результатом этого этапа является оптимизированное руководство по правилам — а не рабочий код.

Для миграций с рефакторингом эквивалентный тест — позволить оппоненту-рецензенту атаковать дизайн-документ, а затем выполнить однократный сквозной запуск.

Шаг 3: Полный перевод

Как только правила прошли валидацию в пробном запуске, репозиторий можно обрабатывать через параллельную очередь.

Типичная конфигурация юнита включает:

• Один исполнитель
• Два независимых рецензента-оппонента
• Один исправитель
• Механическая очередь
• Общее руководство по правилам
• Общий список пробелов

Очередь должна поддерживать возобновление с прерванного места. Работу следует считать завершённой путём проверки файлов или записи артефактов, а не полагаясь на память отдельного агента.

Агенты должны последовательно помечать незавершённую работу, например:

TODO(перенос): объяснить, почему эту часть нельзя безопасно перевести

Нет необходимости использовать самую дорогую модель для каждого юнита. Модели с более низкой конфигурацией могут обрабатывать большие объёмы перевода, а более мощные модели можно оставить для рецензентов, архитектурных решений и модификации правил.

Шаг 4: Компиляция

Первая полная сборка преобразует ошибки компилятора в структурированную очередь задач.

В зависимости от стоимости сборки

компилятор может выполняться внутри цикла каждого агента или через отдельный оркестратор.

Для проекта Bun стоимость полной сборки рабочего пространства высока, поэтому в процессе перевода файлов агент Claude не выполняет произвольные команды cargo. Вместо этого применяется следующий процесс:

1. Оркестратор запускает компилятор.
2. Сообщения об ошибках записываются в общий список.
3. Список классифицируется по модулям или корневым причинам.
4. Агенты-исправители обрабатывают группы ошибок параллельно.
5. Рецензенты проверяют исправления.
6. Оркестратор пересобирает проект.

Это предотвращает одновременный запуск десятков агентов с одними и теми же дорогостоящими сборками.

Систематические ошибки компилятора должны приводить к обновлению правил. Например, целевой язык может отклонять циклические зависимости, которые исходный компилятор терпит при ленивой загрузке. Это проблема уровня процесса, а не просто набор изолированных файловых ошибок.

Шаг 5: Запустите программу

Успешная компиляция лишь доказывает, что целевой язык может принять код.

Следующий этап использует базовое выполнение и smoke-тесты для выявления сбоев, ошибок инициализации, отсутствия ресурсов, неверных предположений и сбоев интеграции.

Неудачные случаи по-прежнему следует классифицировать по причинам.

Если 40 smoke-тестов падают из-за одного и того же неверного шаблона инициализации, следует исправить правило миграции и перегенерировать затронутый код, а не назначать 40 отдельных исправлений.

Шаг 6: Соответствие исходному поведению

Финальный этап — это поведенческая согласованность.

Одновременно запускайте портативные тестовые наборы, инструменты проверки согласованности, сравнение выходных данных и соответствующие бенчмарки обеих кодовых баз.

Для каждого неудачного случая:

1. Предоставьте агенту по исправлению доказательства сбоя и два варианта реализации.
2. Потребуйте от агента по исправлению определить поведенческое различие.
3. Пусть оппонент-проверяющий изучит предлагаемые изменения.
4. Пакетно обрабатывайте дорогостоящие сборки через единый конвейер.
5. Повторно запустите затронутые тесты.
6. Повторяющиеся сбои повышайте до изменений правил.

Исходная кодовая база всегда является эталоном истины, если только проект явно не намерен изменить поведение.

Отсутствие тестового набора не является основанием для пропуска этого шага. Команда может с помощью Claude создавать внешние инструменты проверки согласованности на основе реальных сценариев и подтверждать их эффективность через намеренно сломанное поведение.

Краткое руководство по набору инструментов миграции Anthropic

Anthropic опубликовал открытый начальный набор, содержащий общие промпты, шаблоны и скрипты на основе процесса миграции.

Этот репозиторий является справочным материалом, а не полностью управляемым продуктом миграции. Его промпты — это шаблоны для рефакторинга, а не точное описание процесса для проекта Bun.

1. Установка Claude Code

В macOS или Linux:

curl -fsSL https://claude.ai/install.sh | bash

В Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

Перед выполнением удаленного скрипта установки, пожалуйста, проверьте содержимое скрипта и политику безопасности вашей организации.

2. Клонирование набора инструментов миграции

В репозитории, ожидающем миграции, выполните:

git clone https://github.com/anthropics/code-migration-kit-with-claude-code.git ./migration-kit

3. Добавление навыка миграции

Этот необязательный шаг копирует навык миграции в локальный каталог навыков Claude Code:

cp -r migration-kit/skill ~/.claude/skills/code-migration

Обновите путь к набору инструментов в установленном файле SKILL.md согласно инструкциям.

Репозиторий.

4. Запуск оценки осуществимости

Сначала используйте промпт оценки осуществимости только для чтения из набора:

prompts/00-feasibility.md

Результат должен ответить на три вопроса:

• Следует ли мигрировать этот проект?
• Сохраняет ли миграция структуру или подразумевает редизайн?
• Можно ли справедливо оценить исходную и целевую реализации?

"Не мигрировать" — это допустимый результат.

5. Подготовка инструментов оценки и правил безопасности

Перед началом трансляции:

• Создайте или проверьте межъязыковые инструменты оценки.
• Скопируйте рекомендуемые настройки Claude в целевой репозиторий.
• Запретите деструктивные или дорогостоящие команды, где это уместно.
• Убедитесь, что у исходного репозитория есть восстанавливаемая резервная копия.
• Используйте изолированные ветки, контролируемые рабочие деревья и учетные данные с минимальными привилегиями.

Затем запускайте промпты миграции последовательно, а не переходите сразу к масштабной трансляции.

Проблемы, возникшие на ранних этапах миграции Bun

Миграция Bun с самого начала шла негладко.

Когда множество агентов начали работать в одном репозитории, их Git-операции мешали друг другу. Один агент запускал git stash, другой использовал git stash pop, а третий сбрасывал рабочее дерево.

Sumner изменил рабочий процесс, лишив агентов возможности свободно запускать деструктивные Git-команды. Позже он разделил работу на четыре фрагмента рабочего процесса, каждый из которых использовал независимое рабочее дерево и координировал нескольких агентов.

Этот пример подчеркивает ключевой момент: права агентов должны соответствовать дизайну рабочего процесса.

Кодирующий агент с широким доступом к оболочке может:

• Удалять или перезаписывать работу
• Сбрасывать незакоммиченные изменения
• Повторно запускать дорогостоящие сборки
• Изменять несвязанные файлы
• Раскрывать секреты через команды или логи
• Мешать другим агентам

Уровень оркестрации должен ограничивать команды, определять владение файлами, сериализовать дорогостоящие операции и упрощать восстановление.

Лучшие практики AI-ассистированной миграции кода

Опыт Anthropic можно свести к нескольким практическим правилам.

Не следуйте слепо общим руководствам

У каждой кодовой базы своя система сборки, тестовое покрытие, поведение во время выполнения, ограничения развертывания и толерантность к риску.

Используйте шестишаговую структуру как отправную точку, а затем позвольте Claude адаптировать ее под реальный репозиторий.

Фокусируйтесь на шаблонах, а не на отдельных сбоях

Агенты по исправлению могут обрабатывать отдельные сбои. Человеческое внимание наиболее ценно, когда оно направлено на выявление повторяющихся шаблонов, отсутствующих правил, небезопасных предположений и архитектурных проблем.

Сделайте проверку оппонентской

Агент-исполнитель не должен быть единственным проверяющим.

Предоставьте проверяющему независимый контекст и скажите ему исходить из того, что сгенерированный код ошибочен. Его задача — выяснить, почему код падает, отклоняется от требований или нарушает правила.

Механизируйте проверку

Используйте компиляторы, тесты, линтеры, различия в выводе, бенчмарки и детерминированные скрипты в качестве инструментов оценки.

Субъективная проверка "выглядит правильно" не может безопасно валидировать изменения в миллион строк.

Используйте разные модели для разных ролей

Высокообъемные задачи трансляции можно поручить меньшим или более дешевым моделям. Самые сильные модели должны использоваться для создания правил, архитектуры, нечетких сбоев и проверки.

Привлекайте людей как можно раньше

Самая ценная человеческая работа должна быть выполнена до массовой генерации:

• Определите бизнес-кейс
• Постройте механизм проверки
• Разработайте свод правил
• Составьте карту зависимостей
• Проверьте пилотный проект
• Установите права и границы

Как только эти основы станут надежными, большая часть оставшейся работы превратится в механизированные задачи из очереди.

Обеспечьте восстанавливаемость очереди

Миграции, выполняющиеся несколько дней, должны выдерживать сбои, перезагрузки, неисправности моделей и перебои в инфраструктуре.

Состояние завершения должно определяться на основе устойчивых артефактов на диске, записей коммитов, результатов тестов и состояния очереди, а не полагаться на один длинный диалог.

Результаты после миграции Bun

Anthropic сообщает, что код Bun, написанный на Rust, используется в производственной среде.

Эта миграция не устранила все компромиссы. Около 4% кода на Rust все еще находится в блоках unsafe, в основном это небольшие операции с указателями на границах с C и C++.

Однако новая реализация принесла значительные улучшения:

• Исправлены обнаруживаемые утечки памяти
• Использование памяти в тестовом сценарии повторной сборки снизилось с 6 745 МБ до 609 МБ
• Размер двоичных файлов уменьшился на 19% на платформах Linux и Windows
• Межъязыковая оптимизация повысила производительность на определенных рабочих нагрузках примерно на 2–5%

Эти результаты ясно показывают, в чем смысл миграции. Цель не в генерации большого количества кода, написанного AI, а в создании более безопасной, компактной и удобной для поддержки системы при сохранении исходного поведения.

Сценарии применения AI-миграции

Крупномасштабная миграция подходит для агентных рабочих процессов, когда:

• Исходная кодовая база используется как полная спецификация
• Поведение можно проверить внешними средствами
• Можно создать тесты или сценарии для сравнения
• Работа может быть разбита на повторяемые единицы
• Целевой язык имеет явные преимущества
• Организация может позволить себе крупные экспериментальные ветки
• Человек-эксперт может проверить архитектуру и граничные случаи
• Инструментальная среда может быть ограничена и аудируема

Миграция менее подходит, когда:

• Исходное поведение недостаточно понято
• Невозможно проверить корректность
• Проект смешивает миграцию с полным редизайном продукта
• Регуляторное одобрение требует ручной проверки каждого изменения
• Код содержит секреты или системы, которые нельзя безопасно раскрыть
• У команды нет чувства ответственности за код после слияния AI-генерации

Возможность быстро сгенерировать миллион строк кода не делает миграцию автоматически разумной.

Часто задаваемые вопросы

Действительно ли Claude Code перенес Bun с Zig

Переписали на Rust?

Да. Джарред Самнер, используя динамические рабочие процессы Claude Code и предрелизную модель Claude, перенёс ядро Bun с Zig на Rust. Этот процесс занял менее двух недель и привёл к генерации более миллиона строк кода, после чего были выполнены компиляция, тестирование, рецензирование и исправления после слияния.

Сколько стоила миграция Bun?

Согласно отчёту Anthropic, было израсходовано около 5,9 миллиарда некэшированных входных токенов и 690 миллионов выходных токенов. По ценам API стоимость модели оценивается примерно в 165 000 долларов США, не включая затраты на персонал и инфраструктуру.

Прошла ли миграция все тесты перед слиянием?

Anthropic сообщает, что перед слиянием существующий набор тестов Bun успешно проходил в CI. После слияния было обнаружено 19 регрессий, которые впоследствии были исправлены.

Почему Bun перешёл с Zig на Rust?

Основная цель — повысить безопасность памяти, сократить количество повторяющихся проблем с временем жизни, а также ошибок, связанных с освобождением, использованием после освобождения и двойным освобождением, и утечек памяти. Система владения и типов Rust позволяет выявлять многие из этих проблем на этапе компиляции.

Может ли Claude Code автоматически перенести произвольную кодовую базу?

Нет. Для успешной миграции необходимы строгие рецензенты, чёткие правила, анализ зависимостей, контролируемые разрешения, повторяемая очередь контроля качества, а также рецензирование с учётом противодействия и человеческий надзор. Некоторые проекты вообще не следует мигрировать.

Что такое рецензирование кода с учётом противодействия?

Рецензенты с учётом противодействия получают сгенерированные изменения в изолированной среде. Их задача — находить дефекты, а не одобрять изменения. Роли исполнителя и рецензента различаются, что снижает риск того, что автор будет защищать свои собственные результаты.

Нужен ли мне существующий набор тестов?

В идеале — да, особенно если он позволяет проверять публичное поведение независимо от языка реализации. Если такого набора нет, команда может создать среду проверки, сравнивая поведение старой и новой систем в реальных сценариях и сопоставляя выходные данные.

Набор инструментов для миграции от Anthropic — это тот же полный рабочий процесс, который использовался для Bun?

Нет. Anthropic описывает этот репозиторий как обобщённый и реструктурированный стартовый набор. Фактическая миграция Bun использовала более специфические компоненты, включая подробное руководство по правилам проекта и настраиваемый динамический рабочий процесс.

Связанные инструменты

• Claude Code: Интеллектуальный инструмент для кодирования от Anthropic, используемый для управления репозиториями, терминалом, тестированием и рабочими процессами разработки.
• Bun: Среда выполнения JavaScript и TypeScript, менеджер пакетов, сборщик и тестовый раннер.
• Rust: Системный язык программирования, ориентированный на производительность, безопасность типов и безопасность памяти.
• Zig: Низкоуровневый язык программирования, подчёркивающий явный контроль и простую семантику языка.
• GitHub: Платформа для управления исходным кодом и совместной работы, используемая для управления запросами на слияние при миграции Bun и для набора инструментов миграции от Anthropic.
• Плагин модернизации Claude Code: Официальный плагин Anthropic для оценки и модернизации устаревших систем.

Связанные ссылки

• Руководство Anthropic по крупномасштабной миграции кода: Официальный шестишаговый процесс и два тематических исследования миграции.
• Переписывание Bun на Rust: Подробный отчёт Джарреда Самнера об архитектуре, рабочем процессе, рецензировании, неудачах и результатах.
• Запрос на слияние переписанного на Rust Bun: Принятый запрос на слияние, содержащий крупномасштабную миграцию с Zig на Rust.
• Набор инструментов для миграции с Claude Code: Официальные подсказки, шаблоны, скрипты и эталонные рабочие процессы для миграции языков.
• Документация Claude Code: Официальная документация по установке, настройке, безопасности и рабочим процессам.
• Плагин модернизации кода: Официальный плагин Claude Code для оценки и трансформации устаревших систем.
• Тестирование эквивалентности поведения.
• Официальное руководство по Rust: Официальная документация, охватывающая владение, заимствование, типы, конкурентность и разработку приложений на Rust.

Заключение

Claude Code позволил успешно мигрировать Bun не потому, что он сгенерировал идеальный миллион строк кода за один раз. Ключ к успеху проекта заключался в том, что команда построила вокруг модели строгую производственную систему: руководство по правилам, карту зависимостей, список пробелов, пилотный проект, параллельную очередь трансляции, рецензирование с учётом противодействия, цикл компиляции, дымовые тесты и проверки поведенческой эквивалентности.

Тот же подход помог Anthropic за выходные перенести большую кодовую базу на Python в TypeScript. В обоих случаях объективная проверка оказалась намного важнее скорости первоначальной генерации.

ИИ может значительно снизить стоимость и цикл крупномасштабных миграций, но только при условии, что процесс можно прервать и возобновить, разрешения контролируются, а повторяющиеся дефекты постоянно улучша