В декабре 2025 года Anthropic купила Bun — JavaScript runtime, написанный на языке программирования Zig. В марте 2026 года команда Bun показала четырёхкратное ускорение компиляции на своём форке Zig. Затем объяснила в твиттере: «Мы не планируем отправлять это в upstream, потому что в Zig действует строгий запрет на LLM-авторированные правки».

Звучит как техно-анекдот. Но это реальная история, которая вскрывает настоящий конфликт между тем, как работает open-source сообщество, и тем, как работают AI-инструменты. Это история о том, что этические позиции имеют цену — и иногда эта цена измеряется в невозможности смержить патч.

Что такое «contributor poker»

В сентябре 2025 года вице-президент Zig Software Foundation по комьюнити Лорис Кро опубликовал разбор своей позиции. Название концепции — «contributor poker»: ты играешь не в карты, а в человека. Когда кто-то присылает пулреквест, задача мейнтейнера — не просто проверить код на ошибки. Это инвестиция в нового участника, который со временем станет доверенным и продуктивным членом проекта.

Кро объясняет: успешные open-source проекты рано или поздно достигают момента, когда входящих PR больше, чем мейнтейнеры способны обработать. Логичный ответ — отфильтровать неидеальные PRы и оставить только безупречные. Но Zig делает наоборот: команда помогает новым контрибьюторам довести их работу до приемлемого качества, даже если на это нужно потратить время.

Почему? Потому что каждый контрибьютор — это актив. Вырастить из новичка опытного участника ценнее, чем принять готовый код от анонима. Мейнтейнеры инвестируют в людей, а не в строчки. Кро называет это «contributor poker»: вы делаете ставку на человека, а не на содержание его первого пулреквеста.

LLM-авторированные пулреквесты ломают эту модель полностью. Неважно, насколько идеальным получился код — время, которое команда тратит на ревью LLM-PR, не помогает вырастить нового участника. Мейнтейнер мог бы точно так же запустить свой LLM и решить ту же задачу сам. В результате — ноль новых людей в сообществе.

Bun и парадокс Anthropic

Теперь история становится интереснее. Bun — это JavaScript runtime, изначально созданный как альтернатива Node.js и Deno. В декабре 2025 года Anthropic купила Bun. Причина очевидна: Bun написан на Zig, а Zig — это язык системного программирования, где критически важна скорость и контроль над памятью. Для компании, которая строит AI-инфраструктуру, такой актив стратегически ценен.

Но у Bun есть проблема: компания использует AI-инструменты для разработки. А Zig запрещает LLM-правки в своём upstream.

Команда Bun форкнула Zig и добавила в компилятор параллельный семантический анализ и множественные codegen-юниты для LLVM-бэкенда. Результат — четырёхкратное ускорение компиляции Bun. Цифра подтверждена бенчмарком: сравнение upgrade-0.15.2 с upgrade-0.15.2-fast показывает стабильный 4x прирост на реальных задачах. Для JavaScript runtime, где компиляция — постоянный bottleneck, это критически важно.

Но в upstream этот патч не примут. Даже если бы он был безупречен с технической точки зрения. Потому что он был написан при участии AI-инструментов.

Почему это не лицемерие

Можно было бы сказать: «Anthropic купила компанию, которая использует LLM, а теперь страдает от того, что не может пропихнуть LLM-патч в upstream?» Это звучит как лицемерие. Но реальность сложнее.

Запрет Zig — это не PR-ход и не техническое решение. Это этическая позиция, основанная на конкретной теории того, как должны расти open-source проекты. Антропик с этой теорией не согласен (иначе они бы не купили Bun с его LLM-процессами), но при этом уважает правила чужого дома. Они не пытаются обмануть upstream. Они просто форкнули проект и работают на своей стороне. Это, в общем-то, и есть главный принцип open source: fork if you disagree.

Более того, Zig core contributor на форуме Ziggit объяснил, что параллельный семантический анализ — это давно запланированная фича языка, и конкретный патч Bun имел проблемы с дизайном, которые касаются «самой сути языка Zig». То есть технические претензии существуют и без запрета на LLM.

Но запрет на LLM — это дополнительный барьер, который делает upstreaming невозможным даже если бы патч был идеальным. Команда Bun могла бы переписать всё вручную, сохранив логику. Но тогда это был бы уже другой патч, с другой историей git, а значит — другая суть. Это не тот же самый код, который показал 4x.

Что это значит для индустрии

Ситуация с Zig/Bun — это предельный случай, но тренд очевиден. Open-source проекты начинают формулировать политики в отношении AI-инструментов. Rust обсуждает собственные правила. Linux Kernel требует раскрытия использования AI. GitHub Copilot стал нормой, но сообщества с высокими стандартами кода (ядерный, медицинский, финансовый софт) ужесточают требования.

Причина понятна: LLM генерирует правдоподобный, но непроверенный код. Для low-stakes проекта это приемлемый trade-off — скорость против идеальности. Для систем, где баг может стоить жизней или миллиардов, это неприемлемо. Zig позиционирует себя как язык для написания парсеров, компиляторов, операционных систем — software, где ошибка катастрофична. LLVM, GCC, binutils — всё это требует безупречного кода, потому что на нём строятся другие системы.

Но есть и оборотная сторона. Строгая LLM-политика сужает пул контрибьюторов. Не каждый хороший инженер готов переписывать LLM-подсказки вручную. Особенно если другие проекты (те же Electron-проекты, которые теперь могут использовать Bun) не предъявляют таких требований. Zig рискует стать «языком для гиков, которые верят в чистоту кода», а не инструментом, который побеждает на рынке.

Кто прав — Zig или индустрия

Обе позиции рациональны. Индустрия права в том, что AI-инструменты дают огромный прирост продуктивности. Отбрасывать их полностью — значит сознательно замедляться. Контрибьюторы Bun показали, что LLM-помощь позволила бы форкнуть Zig и получить 4x прирост. Это не гипотетические цифры из маркетинговых слайдов — это реальный бенчмарк на реальном проекте.

Zig прав в том, что модель «выращиваем контрибьюторов, а не принимаем код» работает для долгосрочного здоровья проекта. LLM-генерированный код не создаёт новых людей, которые понимают проект на глубинном уровне. Можно принять тысячу LLM-PRов и не получить ни одного нового мейнтейнера. А мейнтейнеры — это то, что отличает живой проект от мёртвого.

Но Zig делает одну ошибку в формулировке: позиция «мы не принимаем LLM-PRы» превращается в «мы не можем принять патч от компании, которая использует LLM». Это уже не про качество кода, а про его происхождение. А происхождение — это не то же самое, что качество. Патч Bun с 4x ускорением может быть безупречным по качеству — но он всё равно не нужен upstream, потому что команда Zig не хочет иметь дела с людьми, которые пишут код с помощью AI.

Уроки для команд

Ситуация с Bun и Zig показывает, что AI-политики в инженерных командах — это не только про этику и продуктивность. Это ещё про стратегию: могут ли ваши инструменты работать с экосистемой, в которой вы живёте?

Если вы строите на open-source фундаменте, чья LLM-политика строже вашей, вы рискуете оказаться в ситуации Bun. Продуктивный форк, который нельзя смержить обратно. Прибыльные улучшения, которые остаются приватными. Внешне всё работает, но вы изолированы от upstream. Со временем форк устаревает, и поддерживать его становится дороже, чем перейти на другой стек.

С другой стороны, если вы мейнтейнер и хотите сохранить контроль над качеством, запрет LLM — это легитимный инструмент. Но его нужно формулировать точно: не «LLM-код плохой», а «LLM-контрибьюторы не растут в нашем сообществе». Это разные утверждения с разными следствиями. Первое — про код, второе — про людей.

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

Разве LLM-код не хуже написанного вручную?

Не обязательно. Современные LLM (GPT-4.5, Claude 3.5, Gemini 1.5) генерируют код, который проходит тесты, следует best practices и не содержит очевидных багов. На бенчмарках типа HumanEval или MBPP модели показывают 80-90% accuracy. Проблема не в качестве кода, а в том, что LLM-генерированный код не создаёт нового человека, который понимает систему. Если ваш проект держится на мейнтейнерах, а не на коде — это проблема. Если код — это всё, что вам нужно, LLM прекрасно подходит.

Почему бы Zig просто не принять патч Bun, если он ускоряет компиляцию?

Потому что принятие патча означает принятие прецедента. Если Zig принимает патч от Bun, которые явно используют LLM в своих процессах, они не могут отказать следующему контрибьютору на том же основании. Запрет становится непоследовательным. Лучше держать линию и получить изоляцию, чем один раз прогнуться и потерять принципиальность. Это классический credibility trap: одна уступка — и вся позиция рушится.

Это касается только Zig?

Нет. Аналогичные дискуссии идут в Rust, Linux, LLVM и других крупных проектах. Просто Zig — наиболее радикальная позиция. Большинство проектов приходят к какому-то компромиссу: например, «LLM можно использовать для ревью, но не для написания кода» или «LLM-правки нужно явно декларировать». Linux kernel maintainer Грег Кроман-Хартман в 2024 году сказал, что не будет принимать патчи, которые «выглядят как типичный AI-мусор» — но признал, что граница размыта.

Что делать, если мой проект зависит от Zig?

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

Итог

Zig запретил LLM в пулреквестах. Bun, принадлежащий Anthropic, получил четырёхкратное ускорение компиляции на форке Zig. Этот патч нельзя пропихнуть в upstream.

Никакого лицемерия в этом нет. Есть конфликт двух моделей: индустриальной (AI как ускоритель) и ремесленной (сообщество как актив). Они обе имеют право на существование. Но чем дальше, тем чаще они будут сталкиваться — не в теоретических спорах, а в конкретных бенчмарках, конкретных форках и конкретных цифрах.

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