В декабре 2025 года Anthropic купила Bun — JavaScript-Runtime, написанный на Zig. Через несколько месяцев команда Bun объявила об ускорении компиляции в 4 раза: добавили параллельный семантический анализ и несколько codegen-юнитов в llvm-бэкенд. Результат — впечатляющий. Но выложить патч в upstream Zig нельзя. Причина — политика проекта: никакого LLM-кода в Zig. Ни в Issues, ни в Pull Requests, ни в комментариях к bug-tracker.

Это редкий случай, когда бизнес-решение крупной компании упирается в философию open source. Anthropic владеет Bun, но не может заставить Zig принять улучшение компилятора. Это реальный tension между деньгами и governance.

Что именно запрещает Zig

Политика языка программирования Zig звучит предельно конкретно:

• Никаких LLM для создания Issues
• Никаких LLM для Pull Requests
• Никаких LLM для комментариев в bug-tracker, включая перевод

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

Для сравнения: большинство крупных open source проектов либо не имеют политики на этот счёт, либо indirectly поощряют использование ИИ через Accepted AI-assisted contributions в CONTRIBUTING.md. Linux допускает AI-ассист в документацию. Python не запрещает. Rust обсуждает, но не запрещает.

Zig — в явном меньшинстве. Среди крупных проектов аналогичную строгость демонстрирует разве что Debian (ограничения на автогенерированный код в определённых секциях) и редкие embedded-проекты с certification-требованиями.

Contributors важнее contributions

Объясняет Лорис Кро (Loris Cro), VP Community в Zig Software Foundation, в статье Contributor Poker and Zig's AI Ban.

Ключевая идея: в успешном open source проекте со временем появляется больше PR, чем мейнтейнеры способны обработать. Логичный ответ — отсекать неидеальные PR, брать только готовый код. Но Zig делает наоборот: команда помогает новым контрибьюторам довести работу до merge.

Делается это не из альтруизма. Причина — экономическая. Кро описывает это как iterated game: вы инвестируете немного энергии, чтобы онбордить нового контрибьютора, и рассчитываете, что через несколько итераций этот человек начнёт приносить ценность обратно — станет trusted contributor, который понимает архитектуру проекта, следует code style и входит в ритм релизов.

«In successful open source projects you eventually reach a point where you start getting more PRs than what you're capable of processing. Given what I mentioned so far, it would make sense to stop accepting imperfect PRs in order to maximize ROI from your work, but that's not what we do in the Zig project. Instead, we try our best to help new contributors to get their work in, even if they need some help getting there. We don't do this just because it's the "right" thing to do, but also because it's the smart thing to do»

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

Почему LLM ломает эту модель

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

Кро называет это «contributor poker» по аналогии с покером: «you play the person, not the cards». В покере вы ставите на человека, который сидит напротив. В open source вы инвестируете в человека, который прислал первый PR. LLM-ассист отделяет результат от навыка — и рушит всю систему.

Следствие: если LLM может написать PR за человека, мейнтейнеру проще запустить своё собственное LLM и решить задачу напрямую. Зачем тратить час на ревью чужого LLM-вклада, если можно за пять минут получить результат от своего ИИ-ассистента?

Это не риторический вопрос — это реальная экономика ревью-времени. Мейнтейнеры тратят limited cognitive resources на понимание контекста PR, проверку безопасности, оценку архитектурных решений. Если код писал LLM, а человек не понимает его полностью, ревью становится сложнее и ценнее.

Случай Bun: бизнес упирается в философию

Bun принадлежит Anthropic. Anthropic использует Claude для код-ассиста. Bun много экспериментирует с ИИ-ассистенцией. Команда достигла 4x ускорения компиляции через улучшения в Zig-backend — параллельный семантический анализ и несколько codegen-юнитов в llvm-бэкенд.

Техническая деталь: компиляция Zig исторически была bottleneck для Bun. Каждый раз, когда Bun запускает build своего runtime, компилятор Zig обрабатывает тысячи файлов. Ускорение в 4 раза означает экономию минут или десятков минут на каждом билде — для CI/CD это существенно.

Но Zig запрещает LLM-вклад. Патч не примут.

Ситуация показательна: Anthropic купила компанию, чтобы получить команду и технологию. Но владение Bun не даёт контроля над языком, на котором Bun написан. Fork будет развиваться отдельно — с ИИ-улучшениями, которые не пойдут в upstream. Через несколько лет форк Bun и upstream Zig могут разойтись настолько, что объединение станет невозможным.

Аргументы критиков: изоляция и конкурентный недостаток

Не все согласны с позицией Zig.

Первый аргумент — изоляция. Запрет LLM-вклада отсекает часть потенциальных контрибьюторов, которые могли бы внести ценный код просто потому, что без ИИ их порог входа слишком высок. Особенно это касается non-native English speakers: баг-репорты и документация на чужом языке требуют усилий, которые LLM снимает.

Второй аргумент — конкурентный недостаток. Rust получает LLM-ассист в компилятор, автокомплит и рефакторинг. Go экспериментирует с ИИ-тулзами. Если Zig отказывается от LLM-вклада, язык может отстать в экосистеме инструментов — особенно в IDE-поддержке и статическом анализе. Для языка, который конкурирует за разработчиков, это риск.

Третий аргумент — лицемерие. Bun использует ИИ внутри своей компании. Anthropic владеет Bun. Но улучшение компилятора не может вернуться в community. Это создаёт иерархию: Insiders (своя команда с ИИ) vs Outsiders (community без ИИ). Не все находят это справедливым.

Контраргумент: устойчивость и качество

Защитники позиции Zig отвечают иначе.

Качество vs скорость: LLM генерирует рабочий код — но не обязательно хороший код по критериям проекта: стилю, архитектуре, читаемости, долгосрочной поддерживаемости. Когда мейнтейнеры растят контрибьютора, они получают человека, который со временем начинает понимать эти критерии интуитивно. LLM остаётся на уровне «синтаксически верно».

Устойчивость сообщества: Open source проект, который зависит от контрибьюторов-людей, имеет finite supply ревью-времени. Если все используют LLM, supply PR становится infinite, но quality control исчезает. PR flood без ревью-инвестиции превращается в burden, а не в asset.

Исторические прецеденты: LLVM years не принимал LLM-вклад в ранние годы — и качество компилятора от этого не пострадало. Substrate от Parity следовал строгим правилам аппрува — и стал одним из самых поддерживаемых Rust-проектов. Принцип «выращиваем людей, не принимаем код» работает, когда у проекта есть ресурсы на это.

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

Zig — не default позиция индустрии. Это outlier. Но outlier полезен именно как контраст: он показывает, где проходит линия между «используем ИИ для продукта» и «открываем дверь ИИ в процесс развития проекта».

Для разработчиков это вопрос не технологии, а governance: кто принимает решения в open source, как распределяется ревью-бюджет, что считается легитимным вкладом. ИИ ставит все эти вопросы в непривычную плоскость — потому что ответ на них влияет на структуру затрат мейнтейнеров.

Для бизнеса случай Bun/Zig показателен: покупка компании не даёт контроля над языком. Anthropic владеет Bun, но не может заставить Zig принять улучшение компилятора. Open source governance — не всегда подчиняется рыночной логике. Иногда philosophical commitment перевешивает business interest.

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

Разве LLM не помогает новичкам contributing?

Помогает — генерирует код быстрее. Но цель Zig в том, чтобы новичок рос. Если LLM пишет код за человека, человек не учится. Через год это тот же новичок с тем же уровнем, просто с более длинной историей PR. Для долгосрочного здоровья проекта важнее вырастить контрибьютора, который будет приносить ценность годы, чем принять десяток LLM-PR сегодня.

Почему Rust и Python не запрещают LLM-вклад?

Масштаб и ресурсы. У Rust есть корпоративная поддержка (Mozilla, Amazon, Google, Huawei), которая позволяет нанимать людей на ревью. У Python — огромное community с тысячами активных контрибьюторов и strong opinion, что policy должна быть permissive. Zig меньше и полагается на voluntary labor мейнтейнеров. Для small-scale проектов с limited reviewer bandwidth политика «выращиваем людей» — вопрос выживаемости, не идеологии.

Bun мог бы просто forkнуть Zig и развивать его отдельно?

Именно это и происходит. У Bun есть форк Zig с ИИ-улучшениями, которые не пойдут в upstream. Это нормальная практика в open source — брать dependency и развивать его под свои нужды. Вопрос в том, не создаёт ли это fragmentation: через несколько лет форк Bun и upstream Zig могут разойтись настолько, что объединение станет невозможным. Это стоимость изоляции, которую платит Bun, и которую Zig осознанно выбирает.

Это касается только Zig или и других проектов?

Zig — наиболее яркий пример из-за публичности Bun и контраста Anthropic-владение vs upstream-отказ. Но similar tensions возникают во многих проектах. Linux-дистрибутивы обсуждают, где провести линию на LLM-генерированных патчах. Rust-экосистема разрабатывает guidelines для AI-assist в библиотеках. Даже небольшие проекты с 2–3 мейнтейнерами сталкиваются с вопросом: принимать ли PR, который автор написал с помощью Copilot, если патч хороший, но автор не понимает его полностью?

Итог

Zig запретил LLM-вклад не из вредности. Причина — экономика open source: мейнтейнеры инвестируют время в людей, а не в код. LLM-ассист отделяет результат от навыка и превращает ревью в бессмысленную работу. Концепция «contributor poker» объясняет это элегантно: вы ставите на человека, который станет valuable contributor через годы, а не на PR, который ИИ сгенерировал за час.

Bun ускорил компиляцию в 4 раза. Zig это не примет. Fork будет развиваться отдельно. Это не баг — это осознанный tradeoff между скоростью языка и целостностью community-модели.

Для индустрии вопрос открытый: если все проекты станут как Zig, ИИ останется внутри компаний, форки будут расти, upstream будет стагнировать. Если все станут как Bun (принимаем всё), мейнтейнеры утонут в LLM-PR flood. Ни один из крайних вариантов не выглядит устойчивым.

Zig показал одну точку на этой карте. Остальное — за индустрией.