В Bun объединили крупный pull request, который переносит значительную часть кодовой базы с Zig на Rust и связан с веткой claude/phase-a-port. Это важный пример не демонстрационного, а боевого применения AI-агентов в разработке: Claude Code помог выполнить работу масштаба, который обычно требует долгой команды миграции, но качество такого порта уже вызывает споры.
Rust-порт Bun уже попал в основную ветку проекта
14 мая 2026 года в репозитории Bun был объединён pull request Rewrite Bun in Rust. Его автор, Jarred Sumner, влил в main ветку claude/phase-a-port; GitHub показывает 6755 коммитов в составе PR.
Bun — это JavaScript-рантайм и набор инструментов, который пытается заменить сразу несколько привычных частей JS-инфраструктуры: Node.js, npm, bundler и test runner. Изначально проект был тесно связан с Zig, но теперь в нём появился большой Rust-порт.
По словам Sumner в обсуждении PR, новая версия проходит существующий тестовый набор Bun на всех платформах, исправляет часть утечек памяти и flaky-тестов, а размер бинарного файла уменьшается примерно на 3–8 МБ. При этом он отдельно подчёркивает: архитектура и структуры данных в целом остались прежними, а async Rust в проекте не используется.
Claude Code стал инструментом переноса
Главная особенность истории не только в смене языка. Важнее то, что перенос связывают с использованием Claude Code — AI-инструмента Anthropic для работы с кодовой базой.
Профильное издание Heise пишет, что в конце апреля появилась ветка, где Claude по инструкции перенёс кодовую базу Bun с Zig на Rust, а 14 мая изменения были объединены в основную ветку. The Register также указывает, что переход произошёл с необычной для такого масштаба скоростью и сопровождался заявлением Sumner о том, что команда уже долгое время не пишет весь код вручную в привычном смысле.
Это делает кейс Bun показательным. Обычно AI в разработке обсуждают на уровне автодополнения, генерации маленьких функций или помощи с тестами. Здесь же речь идёт о переносе крупной системной части проекта, где важны память, производительность, совместимость и большое количество низкоуровневых деталей.
Переход на Rust связан с борьбой за надёжность памяти
Заявленная практическая причина миграции — больше инструментов для борьбы с ошибками памяти. Rust не делает программу автоматически безопасной, но его модель владения, заимствований и автоматического освобождения ресурсов помогает компилятору заранее ловить классы ошибок, которые в системном коде часто приводят к падениям, утечкам или уязвимостям.
Для Bun это особенно чувствительная тема. Рантайм должен быстро запускать JavaScript, работать с файловой системой, сетью, пакетами, сборкой и тестами. В таких проектах ошибка управления памятью может проявляться не сразу: сегодня это редкий crash, завтра — нестабильность в production, а позже — трудноуловимый баг в чужом CI/CD.
Sumner прямо пишет в PR, что команда потратила много времени на ошибки памяти, а Rust даёт «compiler-assisted tools» для их предотвращения. В обычном переводе это означает: часть проблем теперь должен замечать компилятор, а не пользователь после релиза.
AI-порт не превращает код в идиоматичный Rust автоматически
Самая спорная часть истории — качество результата. Переписать код с одного языка на другой ещё не значит получить хороший код на новом языке.
Rust ценят не только за синтаксис, а за модель безопасности. Если при переносе активно используются unsafe-блоки, часть гарантий языка ослабляется. unsafe в Rust нужен для низкоуровневых операций, но он требует строгих инвариантов: разработчик обязан сам доказать, что код не нарушает правила памяти.
После объединения Rust-порта в GitHub уже появились обсуждения проблем. Например, issue Unsound unsafe APIs in Rust port указывает на ситуацию, где безопасная на вид функция внутри использует unsafe и может приводить к undefined behavior. Иными словами, внешний интерфейс выглядит безопасным, но внутри скрывается риск, который Rust сам уже не обязан предотвращать.
Это важный сигнал для всей индустрии. AI может быстро перенести огромный объём кода, но он не всегда понимает границы абстракций так, как их ожидает опытный Rust-разработчик. Особенно когда задача не просто «сделать, чтобы компилировалось», а сохранить долгосрочную поддерживаемость.
Тесты подтверждают совместимость, но не закрывают вопрос сопровождения
Прохождение тестов — сильный аргумент в пользу переноса. Если большая существующая тестовая база проходит, значит поведение многих частей Bun сохранилось. Но тесты не доказывают, что код стал проще, безопаснее и дешевле в поддержке.
У такого рефакторинга есть несколько уровней проверки:
| Уровень проверки | Что он показывает | Что остаётся вне зоны видимости |
| Тесты | Сохранилось ли ожидаемое поведение в известных сценариях | Неизвестные edge cases и скрытые ошибки памяти |
| Бенчмарки | Не просела ли производительность | Долгосрочная стабильность под разной нагрузкой |
| Компиляция Rust | Нет ли части ошибок типов и владения | Риски внутри unsafe и неверные инварианты |
| Ревью кода | Понимают ли люди изменения | Огромный AI-generated diff трудно проверить вручную |
| Production-эксплуатация | Как код ведёт себя у реальных пользователей | Баги проявляются постепенно и неравномерно |
В обычном проекте перенос такого масштаба разбивают на много небольших этапов: модуль за модулем, с понятной историей изменений и ревью. В случае Bun часть сообщества как раз обеспокоена тем, что объём изменений слишком велик для классической человеческой проверки.
Разработчикам стоит воспринимать кейс Bun как эксперимент с высокой ставкой
Для обычного разработчика главный вывод не в том, что теперь любой проект можно быстро переписать на другой язык через AI. Более практичный вывод другой: AI становится реальным участником больших миграций, но вокруг него нужно строить контроль качества.
В подобных задачах особенно важны:
- сильная тестовая база до начала миграции;
- автоматические проверки производительности;
- статический анализ;
- ручное ревью критических участков;
- отдельный аудит
unsafe-кода; - поэтапное включение изменений в стабильные релизы;
- возможность быстро откатиться на предыдущую версию.
Bun пока предлагает попробовать Rust-порт через bun upgrade --canary, то есть через canary-канал. Это разумный промежуточный шаг: пользователи могут тестировать новую ветку, а команда собирает реальные баг-репорты до попадания изменений в обычный стабильный релиз.
Bun показывает новую границу AI-разработки
История с Bun важна не потому, что Claude Code «заменил разработчиков». Скорее она показывает, как меняется роль разработчика в больших рефакторингах. Человек всё ещё отвечает за архитектурное решение, критерии качества, релизную стратегию и последствия для пользователей. AI берёт на себя огромный объём механической и полуинтеллектуальной работы, но не освобождает проект от проверки.
Если Rust-порт Bun окажется стабильным, это станет сильным аргументом в пользу AI-assisted migration: переносов между языками, больших рефакторингов и ускоренной модернизации старого кода. Если же проект столкнётся с трудными багами и проблемами поддержки, кейс станет не менее ценным предупреждением: скорость AI не должна подменять инженерную дисциплину.
Для разработчиков сейчас лучший подход — наблюдать за Bun осторожно. Использовать canary-ветку можно для тестов и экспериментов, но для production разумнее дождаться стабильного релиза, отчётов о найденных проблемах и более понятной картины по качеству Rust-кода.
