Я никогда не пользовался Bun как технологией, с языком Zig знаком поверхностно, а в Rust я не эксперт. Но за свою карьеру я создал с нуля десятки крупных систем, поддерживал и развивал сотни, выводил из эксплуатации единицы и никогда не переписывал. Это, пожалуй, один из ключевых архитектурных принципов, в котором я уверен почти безоговорочно.
Недавняя нашумевшая история с переписыванием Bun с Zig на Rust хороший повод поговорить о том, почему «переписать всё с нуля» обычно худшее решение из всех доступных. И о том, какие альтернативы реально работают, когда вам требуется сменить язык, архитектуру или технологический стек.
Что случилось с Bun
Если коротко, то для меня последовательность событий выглядит так.
23 ноября 2025 года команда языка Zig ввела строгую анти-LLM политику: никаких LLM в тикетах, в pull request’ах и в комментариях в баг-трекере. Даже для перевода. Зафиксировано коммитом в репозитории сайта.
3 декабря 2025 года Anthropic объявил о покупке Bun JavaScript-рантайма, который изначально был написан на Zig. Bun будет использоваться для развития Claude Code, Claude Agent SDK и других AI-инструментов для разработчиков. Объявление от самой команды Bun появилось на день раньше.
Через несколько месяцев в репозитории Bun появился pull request с переписыванием всей кодовой базы с Zig на Rust. 6 755 коммитов, ветка claude/phase-a-port, PR открыт 8 мая, влит 14 мая. Шесть дней. Полный перевод миллиона строк кода production кода рантайма целого языка.
Автор проекта Джаред Самнер описал результат так:
It passes Bun’s pre-existing test suite on all platforms (and fixes several memory leaks and flaky tests), the binary size shrinks by 3 MB - 8 MB, the benchmarks are between neutral and faster - and most importantly, we now have compiler-assisted tools for catching & preventing memory bugs, which have costed the team an enormous amount of development & debugging time over the years.
The codebase is otherwise largely the same. The same architecture, the same data structures. Bun still uses few 3rd party libraries. No async rust.
Перевод с Zig на Rust выполнял ИИ-агент Claude. Ревьюерами в PR значатся coderabbitai[bot] и claude[bot]. Единственный человек в списке ревьюеров alii на момент мержа имел статус «Awaiting requested review». То есть PR на миллион строк кода человеком прочитан не был до влития.
Что в итоге получили
Если структурировать заявленные результаты:
- Существующий тестовый набор проходит на всех платформах.
- Починили несколько утечек памяти и нестабильных тестов.
- Бинарник стал меньше на 3-8 МБ (для контекста, это около 5-10% от размера исходного бинарного файла).
- Бенчмарки между «такие же» и «чуть быстрее».
- Архитектура и структуры данных остались прежними.
То есть: ничего принципиально не изменилось, кроме инструмента, на котором написан код. Архитектура та же, данные те же, скорость та же, размер бинаря почти такой же. Поменялся язык программирования и тип компилятора, который теперь помогает ловить ошибки работы с памятью.
И это, заметьте, заявлено как успех. Возможно, для команды Bun это и правда успех, но если задать вопрос «какую бизнес-проблему мы решили», ответа я в этих метриках не вижу.
Сколько это стоило в токенах и долларах
Точных цифр в публичном поле нет, но порядок прикинуть можно.
Из своего опыта работы с ИИ-кодинг-агентами: на одну итоговую строку кода уходит от 50 до 200 раз больше токенов, если учитывать промпты, поиск по репозиторию, многоэтапные правки и отладку. С учётом пустых и коротких строк можно заложить около 10 токенов на строку самого кода. На миллион строк это даёт от 500 миллионов до 2 миллиардов токенов.
В деньгах разброс ещё шире — зависит от модели и того, насколько активно использовался prompt caching. Для оценки возьму распределение примерно 80% входных и 20% выходных токенов, типичное для агентного кодинга, когда агент много читает и меньше пишет.
- На самой дешёвой современной модели (Haiku 4.5, $1 за миллион входных и $5 за миллион выходных токенов) счёт получается порядка 900–3 600 долларов. Но использовать слабую модель для проекта такого масштаба маловероятно.
- На самой мощной модели (Opus 4.7, $5 за миллион входных и $25 за миллион выходных), которую скорее всего и использовали, выходит 4 500–18 000 долларов. С активным кешированием контекста (cache hits стоят в десять раз дешевле обычного входа по $0,50 за миллион токенов) реальная цифра, скорее всего, ближе к нижней границе диапазона.
То, что современные ИИ-агенты вообще способны довести до конца проект такого масштаба является само по себе интересной технической вехой развития. Меня здесь смущает не возможность, а то, как этой возможностью распорядились.
Что побудило переписывать
Официальной формулировки цели я не нашёл. По косвенным признакам видно сочетание двух факторов: анти-LLM политика Zig и сделка с Anthropic. Компания, которая зарабатывает на LLM, владеет рантаймом, написанным на языке, где LLM нельзя использовать на любом из этапов разработки. Это очевидное противоречие, которое нужно было как-то закрыть.
Это нормальный мотив для бизнес-решения, к нему нет претензий. Странно другое, а именно выбор инструмента для перехода. Переписывание миллиона строк production-кода это непростая задача «закрыть противоречие», это многомесячная работа инженеров с серьёзными рисками. Альтернативы существуют, и мы к ним вернёмся.
Параллельно автор Bun называет техническую причину: на Zig команда регулярно сталкивалась с use-after-free, double-free и утечками на error-path. Это правда, и это известное свойство ручного управления памятью. Но вывод из этой правды можно сделать по-разному. Эта проблема, как мне кажется, была не в Zig как в языке, а в несоответствии философии Zig (системное программирование с осознанным контролем за каждым байтом) и культуре команды Bun (быстро итерироваться и выпускать фичи). Например, базу данных TigerBeetle пишут базу данных на Zig почти без багов памяти, потому что их культура совпадает с философией языка. У Bun другая культура и подход к работе. Это не дефект Zig, это структурное несовпадение ценностей. Если вам не подошёл молоток, то молоток в этом не виноват.
Когнитивный долг и кто его несёт
Здесь начинается интересное. В программной инженерии есть принцип: код, который вы не понимаете, не должен идти в прод. Не потому, что в нём обязательно есть баги, а потому, что когда баг проявится, вы не будете знать, где его искать.
После этого мерджа в кодовой базе Bun появились 6 755 коммитов, которые никто из людей не прочитал и не написал целиком. ИИ написал, ИИ отревьюил, единственный человек-ревьюер не успел открыть PR до мержа.
Так же надо понимать, что формулировка «все тесты проходят» это не то же самое, что «всё работает идентично». Тесты проверяют корректность известного поведения на известных путях. Они не проверяют:
- Корректность обработки нетипичных error-path.
- Поведение на границах под нагрузкой.
- Согласованность состояния в конкурентных сценариях.
- Соответствие реализации авторскому замыслу в местах, где замысел жил только в голове автора оригинала.
Это первый известный мне крупный production-проект, где «когнитивный долг» монетизирован в чистом виде. И это очень хороший повод понаблюдать в динамике, как такой долг проявится. Я обязательно буду следить. Это редкий шанс увидеть, как LLM-агенты справляются с долгосрочной поддержкой того, что сами написали.
И тут важный момент: после покупки Anthropic’ами риск-несущая сторона поменялась. Раньше Bun был ставкой Джареда на самого себя потому что техдолг был его собственным. Сейчас Bun — это часть продукта крупной компании, которая поставляет рантайм в production других людей. Цена ошибки больше не падает только на автора, а несёт реальные коммерческие и юридические риски.
Почему я никогда не переписывал
Меня опыт переписывания не вдохновляет и отталкивает.
В моей практике я ни разу не видел переписывания, которое окупилось бы по сравнению с альтернативой «продолжать развивать и постепенно вытеснять». Каждый раз, когда команда становилась перед выбором «переписать или итеративно развивать», переписывание оборачивалось одной из трёх ситуаций:
- Проект не завершился в разумные сроки. Старая система продолжала работать в проде, новая хронически отставала. В какой-то момент бизнес терял терпение, и от переписывания тихо отказывались. Все потраченные часы инженеров, соответственно, умножались на ноль.
- Проект завершился, но новая система имеет тот же набор проблем. Потому что проблемы были не в технологии, а в архитектурных и продуктовых решениях, которые честно перенесли в новый стек.
- Проект завершился, но в процессе остановилось развитие продукта. Полгода-год, а то и больше, команда не выкатывала ничего нового, потому что все ресурсы шли в переписывание. За это время конкуренты могли уйти далеко вперёд.
Главный вопрос, который я задаю команде, когда слышу про идею переписать: какую конкретную проблему мы решаем?
Если ответ звучит как «новая технология лучше», «старый код тяжело читать», «хочется чистый дизайн», то это не проблема. Это эстетические потребности. Эстетика стоит дорого, и оплачивать её бизнес не обязан.
Если ответ звучит как «у нас перестал работать набор фич X, и в существующей архитектуре он невозможен принципиально», то это уже настоящая проблема. Но и она не решается переписыванием.
Этот же принцип я разбирал применительно к архитектурным решениям потому что там часто работает та же логика resume-driven development: меняем не потому, что нужно, а потому, что хочется.
Что делать вместо переписывания
Альтернатив несколько, и все они работают лучше тотального переписывания.
Поддерживайте существующую систему в живом и стабильном состоянии. Минимальные правки, баг-фиксы, усиление безопасности. Никакого активного развития. Это нормально, если система уже выполняет свою функцию.
Развивайте функциональность сбоку. Новый функционал реализуется в отдельных модулях или сервисах на той технологии, которую вы хотите использовать. Между старой и новой частями используйте gRPC, REST или любой другой контракт и кросс-сервисное взаимодействие. На уровне отдельных функций между Zig и Rust, например, работает обычный C-ABI: и тот, и другой умеют экспортировать и импортировать C-функции, так что миграция отдельных горячих участков по одному в данном случае вполне была реальна.
Применяйте Strangler Fig. Паттерн Мартина Фаулера: новая система постепенно «душит» старую, перехватывая на себя всё больше функциональности. Старая система живёт, пока не станет полностью не нужна. Без больших переписываний, без остановки развития продукта, с понятной точкой выхода.
Рефакторинг внутри существующей кодовой базы. Если конкретный модуль непонятен или неудобен, то переписывайте этот модуль, но не всю систему. Тесты в данном случае вам подстрахуют, пока они зелёные рефакторинг будет безопасен.
Ни в одной из этих стратегий нет шага «обнулите команду на полгода и сделайте всё заново». Потому что бизнес почти никогда не может себе такого позволить.
Что показал эксперимент Bun (и чего он не показал)
То, что ИИ-агент может перевести миллион строк кода с одного языка на другой и пройти тестовый набор — это реальное достижение. Это говорит о зрелости инструментов и о том, что класс задач «механический перевод между языками со схожей семантикой» теперь решается за дни и тысячи долларов, а не за годы и миллионы.
Но эксперимент Bun не показал главного: что после такого перевода вы получаете поддерживаемую систему. Думаю, что на горизонте 6-12 месяцев мы узнаем, когда появятся первые баги, которые будет невозможно объяснить с первого захода в код. Тогда станет понятно, какова реальная цена когнитивного долга, когда платить по нему приходится в три часа ночи во время инцидента.
Вангую, что цена этого когнитивного долга окажется выше ожидаемой. Но 100% уверенности у меня в этом нет. Поэтому буду следить за развитием проекта.
Заключение
Если вы стоите перед выбором «переписать или продолжать поддерживать», то почти всегда правильный ответ «продолжать поддерживать, развивая новое сбоку». Переписывание выглядит как красивое решение, но почти всегда оказывается дорогим способом получить ту же самую систему, только в другом синтаксисе.
История с Bun это отдельный, очень интересный случай: переписывание оказалось технически возможным благодаря ИИ, но цель этого переписывания плохо отделима от внешних обстоятельств (политика Zig, покупка Anthropic). Технически впечатляет. Экономически и инженерно пока непонятно. Посмотрим, что покажет первый серьёзный production-инцидент.
Мой совет, после 10+ лет работы в индустрии: если вам очень хочется всё переписать, потратьте неделю на то, чтобы вместо этого описать конкретные проблемы, которые вы хотите решить. На практике окажется, что рефакторинг отдельных модулей или построение нового функционала рядом со старым закроет ваши потребности даже лучше переписывания всей системы. В невероятно редких случаях переписывание будет целесообразно, но тогда у вас хотя бы будет понятный список целей, по которому вы поймёте, удалось ли вам то, ради чего всё затевалось.
Теги: