Переписывание Bun с помощью ИИ разжигает языковую войну

Bun совершил невозможное: переписывание 500 000 строк кода с Zig на Rust, завершенное за поразительные 11 дней. В период с 3 по 14 мая этот быстрый рефакторинг сгенерировал более 6 500 коммитов, фундаментально изменив высокопроизводительную среду выполнения JavaScript. Это быстрое, масштабное предприятие знаменует новую эру в эволюции крупномасштабного программного обеспечения, расширяя границы возможного.

В основе этого беспрецедентного спринта лежали хронические проблемы со стабильностью, присущие кодовой базе Bun на Zig. Принципы ручного управления памятью Zig фундаментально конфликтовали со сборщиком мусора JavaScriptCore, создавая нестабильную среду. Это взаимодействие порождало постоянные ошибки безопасности памяти, такие как use-after-free и double-free, подрывая основное обещание Bun о скорости и надежности. Система borrow checker Rust теперь предлагает гарантию на этапе компиляции, предотвращая эти критические проблемы до того, как они достигнут продакшена.

Искусственный интеллект руководил всей этой трансформацией, демонстрируя новую парадигму инженерии. Процесс, основанный на ИИ, использующий 64 одновременных экземпляра Claude и предрелизную версию Fable 5, достигал пика в 58 коммитов в минуту. Эта беспрецедентная автоматизация обошлась примерно в $165 000 в виде API-токенов. Эти инвестиции составляют лишь малую часть расходов на команду из нескольких инженеров, работающую в течение года, что делает ручное переписывание такого масштаба экономически нецелесообразным и, вероятно, никогда не предпринимаемым. Исключительная экономическая эффективность и скорость бросают вызов традиционным моделям разработки.

Выпустив армию ИИ-агентов для кода, команда Bun построила сложный рабочий процесс вокруг предрелизной версии Fable 5. Эта система одновременно управляла до 64 экземпляров Claude, обеспечивая переписывание с беспрецедентной параллелизацией. Это мощный взгляд на будущее разработки программного обеспечения в масштабе, где ИИ выступает как архитектор и работник, действуя со скоростью, о которой человеческие команды могут только мечтать.

Ядром этого процесса, управляемого ИИ, был надежный цикл "implementer-reviewer-fixer". Один агент выполнил первоначальный перенос на Rust, сгенерировав новый код. Затем этот вывод подвергся проверке со стороны двух независимых, противоборствующих агентов, которые тщательно просматривали разницу в коде на предмет ошибок и несоответствий, выступая в качестве автоматизированных шлюзов качества. Затем финальный агент синтезировал и применил предложенные ими исправления, обеспечивая многоуровневую верификацию перед внесением любых изменений.

Первоначальное развертывание столкнулось с предсказуемым хаосом, вызванным ИИ. Агенты, работая независимо в четырех Git worktrees, выполняли конфликтующие команды Git, такие как `git stash` и `git reset HEAD --hard`, по сути, сражаясь за репозиторий. Быстрые доработки быстро разрешили эту проблему, предписав агентам избегать любых команд Git или медленных команд `cargo`, не связанных напрямую с фиксацией изменений.

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

Первоначальный вывод ИИ, хотя и объемный, не скомпилировался. Jarred Sumner сначала устранил фундаментальное архитектурное несоответствие: исходная кодовая база Bun на Zig функционировала как единый блок компиляции, но команда нацелилась на 100 Rust crates для улучшения скорости компиляции. Это потребовало сложного рефакторинга для устранения циклических зависимостей, концепции, которую Zig в значительной степени игнорирует. Рабочие процессы ИИ классифицировали, а затем выполнили этот сложный рефакторинг, заложив основу.

Этот структурный пересмотр немедленно выявил примерно 16 000 ошибок компилятора. Специализированный рой агентов ИИ, отражая первоначальную настройку генерации кода, методично справлялся с ними. Агенты итерировали crate за crate, запуская `cargo check`, выявляя ошибки и предлагая исправления. Два противоборствующих агента просматривали каждое предложение, обеспечивая качество кода, прежде чем агент-исправитель применял изменения, в конечном итоге приводя весь проект в компилируемое состояние.

Достижение чистой компиляции было лишь половиной дела; оставался массивный набор тестов Bun. Затем агенты приступили к беспощадному циклу отладки, сосредоточившись на failing stack traces, чтобы выявить и устранить проблемы времени выполнения. Этот последний рывок привел к тому, что все 972 ранее неработавших тестовых файла стали зелеными на Linux, macOS и Windows, что ознаменовало успешное завершение беспрецедентного инженерного подвига. Альтернативные точки зрения на мотивы переписывания доступны в статье Andrew Kelley My Thoughts on the Bun Rust Rewrite.

Andrew Kelley, создатель Zig, не стеснялся в выражениях. Его взрывной пост в блоге утверждал, что монументальное переписывание Bun было не технической необходимостью, а скорее «разрывом отношений». Kelley утверждал, что кодовая база Bun представляла собой «хаки поверх хаков», не соблюдая установленные лучшие практики Zig для управления памятью и очистки. Он отметил, что Zig ожидает, что очистка будет явно прописана в каждом месте вызова с помощью `defer`, практику, которую Bun предположительно упустил из виду.

Kelley утверждал, что предполагаемые проблемы стабильности Bun, такие как ошибки use-after-free или double-free, можно было решить целенаправленными инженерными усилиями, а не радикальной сменой языка на Rust. Он прямо критиковал стиль управления Jarred Sumner, добавляя острый человеческий аспект в технические дебаты и ссылаясь на «безвкусных энтузиастов ИИ» в процессе.

Ключевой вопрос от Kelley оспаривал саму предпосылку переписывания: если набор тестов Bun оказался достаточно надежным для проверки миллиона строк кода, сгенерированного ИИ, почему его было недостаточно для выявления ошибок в исходной реализации Zig? Этот острый вопрос подчеркнул глубокий идеологический раскол, превратив техническую миграцию в полномасштабную language war со значительными последствиями для developer ecosystems.

Почему Bun переключил свою кодовую базу с Zig на Rust?

Основной причиной была стабильность. Команда Bun боролась с ошибками безопасности памяти, такими как use-after-free и double-free, возникающими из-за взаимодействия ручного управления памятью Zig со сборщиком мусора JavaScriptCore. Компилятор Rust с borrow checker автоматизирует безопасность памяти, устраняя весь этот класс ошибок.

Как именно агенты ИИ переписали код Bun?

Создатель Bun, Jarred Sumner, использовал предрелизную версию Fable 5 для оркестровки 64 экземпляров Claude. Он разработал агентский рабочий процесс, где один агент ИИ писал код на Rust, два «противоборствующих» агента проверяли код на наличие ошибок, а финальный агент-«исправитель» применял предложения перед коммитом.

В чем заключалась основная критика Andrew Kelley (создателя Zig) по поводу переписывания?

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

Было ли переписывание на Rust успешным для Bun?

Да. Версия Bun на Rust на 20% меньше, на 2-5% быстрее и имеет значительно меньше утечек памяти. Хотя переписывание привело к 19 новым регрессиям, они были быстро исправлены. В процессе проект исправил 128 известных ошибок и заложил более стабильную основу для будущего развития.