Contributor Poker: почему Zig запретил LLMs в open source
В декабре 2025 года Anthropic купила Bun — JavaScript-runtime, написанный на языке программирования Zig. Через несколько месяцев команда Bun опубликовала впечатляющий результат: ускорение компиляции в 4 раза после добавления параллельного семантического анализа и нескольких codegen-юнитов в llvm-бэкенд. Код выложен на GitHub, ссылка на diff доступна публично. Но патч не пойдёт в основную ветку Zig — потому что в проекте действует строгий запрет на LLM-authored Pull Requests.
Звучит как идеологический абсурд. Техническое улучшение лежит на столе, а его не принимают из-за того, кто его написал. Но у Zig есть серьёзное обоснование — и оно касается не только этого конкретного проекта, а всей индустрии open source.
Zig: язык, который думает иначе
Zig — это язык системного программирования, созданный как замена C. Авторы — Эндрю Келли и сообщество — делают акцент на явности, контроле над памятью и отсутствии скрытых побочных эффектов. Zig компилируется быстро, не имеет runtime в классическом смысле, интегрируется с C напрямую. Звучит как нишевой инструмент, но Bun — не единственный известный проект на Zig. Вокруг языка сформировалось живое сообщество, а Zig Software Foundation поддерживает экосистему через гранты и ревью кода.
Политика в отношении LLMs у Zig одна из самых строгих в индустрии. Прямо в code of conduct проекта написано:
«No LLMs for issues. No LLMs for pull requests. No LLMs for comments on the bug tracker, including translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words.»
Обратите внимание: запрет касается не только кода, но и комментариев в трекер. Даже перевод через LLM — нарушение. При этом проект не требует английского как обязательного языка — наоборот, поощряет родные языки. Логика в том, что перевод через машинное обучение лишает сообщество возможности увидеть, кто на самом деле стоит за вкладом.
Что такое Contributor Poker
Термин придумал Лорис Кро (Loris Cro), VP of Community в Zig Software Foundation, в статье «Contributor Poker and Zig's AI Ban». В успешных open source проектах со временем появляется больше Pull Requests, чем команда способна обработать. Классический ответ — начать отклонять неидеальные PRы, повышать планку качества, чтобы тратить время только на проверенный код.
Но в Zig пошли другим путём: команда помогает новым контрибьюторам довести работу до merge, даже если изначально она требует значительной доработки. Не идеально — довести. Это означает активное ревью, объяснения, иногда нескольких раундов итераций. Цель — не принять конкретный PR, а помочь человеку вырасти.
Причина не только этическая. Каждый контрибьютор — это инвестиция команды. Мейнтейнер тратит время не на код, а на человека. Если через год этот человек станет regular-контрибьютором, каждый час, потраченный на первое ревью, окупится десятикратно. Один идеальный PR от анонима ничего не даёт проекту, если этот человек больше не вернётся.
Отсюда название: contributor poker — играют в человека, а не в карты. В покере вы оцениваете оппонента, его историю, паттерны поведения. В open source вы «ставка» на контрибьютора как на долгосрочный актив проекта. Мейнтейнер смотрит на человека, а не на первую раздачу.
Почему LLMs ломают эту модель
LLM assistance разрушает contributor poker полностью. Неважно, насколько идеальный PR получился с помощью LLM — время, которое команда тратит на ревью и обсуждение, никак не помогает вырастить нового надёжного участника проекта. Через месяц этот человек может не появиться. Более того — он может не понимать свой собственный код, потому что писала машина.
Кро формулирует это жёстко:
«Если PR был в основном написан LLM, почему мейнтейнер должен тратить время на его ревью, а не запустить свою собственную LLM для решения той же задачи?»
Это не риторический вопрос. Это экономический аргумент. Мейнтейнер с доступом к тем же LLM-инструментам может решить задачу сам, не тратя время на чтение кода, объяснения и обсуждение деталей от другого человека. Получается, что LLM-assisted PR не создаёт новой ценности для проекта — он просто перераспределяет время мейнтейнера.
Дополнительная проблема: LLM генерирует «компетентный» код без компетенции. Человек, который показывает блестящий PR, может не уметь отвечать на вопросы о нём. На ревью мейнтейнер обычно обсуждает не только сам код, но и контекст решений, альтернативы, компромиссы. Если автор не может это обсуждать — ревью превращается в односторонний процесс, где мейнтейнер делает работу за обоих.
Bun: бизнес vs идеология
Bun — JavaScript-runtime, купленный Anthropic за несколько миллиардов долларов. Команда наняла лучших инженеров, купила вычислительные ресурсы, получила доступ к технологиям Anthropic. Результат — 4x ускорение компиляции, которое изменит опыт разработчиков Bun по всему миру. Технически — это чистая победа. Но Zig отказывается принимать патч.
Почему? Потому что принятие этого патча создаст прецедент. Формулировка «LLM-authored код можно мержить, если он достаточно хорош» — это открытие двери. Как только появился первый исключение, начинается второй. Через год становится непонятно, где проходит граница. Можно ли мержить PR, где LLM написала 30%? 50%? 90%, но человек проверил каждую строку?
Для Zig это вопрос устойчивости экосистемы, а не скорости. Принять один патч — легко. Сохранить модель, в которой команда инвестирует в людей, а не в код, — сложно, и один exception может сломать всю систему.
Bun просто поддерживает свой форк. Компания заявляет: «We do not currently plan to upstream this, as Zig has a strict ban on LLM-authored contributions». Форк работает, улучшения применяются, пользователи Bun получают преимущество. Для бизнеса — это рациональное решение. Для open source как движения — это демонстрация того, что происходит, когда корпорация покупает open source инструмент.
Примечательно, что ядро Zig дало отдельное объяснение, почему конкретно этот патч не приняли бы независимо от LLM-вопроса. Параллельный семантический анализ — давно запланированная фича, но она имеет последствия для дизайна языка. Это не отказ от улучшения — это отказ от конкретного подхода. LLM-банк стал удобным обоснованием, но даже без него патч потребовал бы серьёзного обсуждения дизайна.
Для Bun это не проблема: команда продолжает развивать форк, пользователи получают 4x ускорение, бизнес-модель работает. Но вопрос устойчивости open source остаётся открытым. Когда каждый крупный проект может позволить себе форк с корпоративной поддержкой — что происходит с идеей общего кода?
Что это значит для индустрии
Большинство open source проектов рано или поздно сталкиваются с проблемой: PRов больше, чем можете обработать. Есть три классических ответа:
Повышать планку. Принимать только идеальный код, остальное отклонять. Проблема: отпугивает новых контрибьюторов, которые не начинают с идеального кода.
Нанимать больше мейнтейнеров. Коммерческие проекты могут себе это позволить. Open source — нет.
Contributor poker. Сознательно инвестировать в помощь новым контрибьюторам, даже если первый PR слабый. Zig выбрал этот путь — и это работает для них.
LLM усложняет все три подхода. Инструменты позволяют генерировать «идеальные» PRы без инвестиций в рост. Человек с LLM может сделать больше, чем без неё, но при этом не становится лучшим инженером. Для проекта это означает: больше PRов, но каждый из них меньше говорит о человеке, который стоит за ним.
Большинство экосистем пойдут по пути постепенного принятия: сначала Guidelines, потом фильтры, потом формальные политики. Но у Zig есть время на эксперимент — у проекта нет инвесторов, которые требуют быстрого роста и экосистемного доминирования.
Форки и будущее open source
Показательно, что Bun просто поддерживает свой форк. Это не драма — это рациональное решение для бизнеса. Компания стоит миллиарды, у неё есть ресурсы. Но здесь возникает системный вопрос: что происходит с open source, когда крупные компании могут позволить себе содержать форки?
Раньше форк был дорогим — нужно было нанять команду для поддержания полной ветки. Теперь LLM может генерировать значительную часть работы по синхронизации с upstream. Форк становится дешевле, а значит, идеологии вроде «contributor poker» становятся сложнее защищать экономически. Если любая компания может взять Zig, пропатчить его для своих нужд и поддерживать отдельную ветку — зачем вкладываться в upstream?
Возможно, Zig — один из последних проектов с такой позицией. Open source без инвесторов, с чёткой идеологией и готовностью жертвовать скоростью ради устойчивости. Контрибьютор-банк привлекает внимание, но вряд ли станет индустриальным стандартом. Индустрия скорее пойдёт по пути Graduated Contributor License — модель, при которой LLM-assisted вклад разрешён, но автор должен подтвердить, что понимает каждую строку.
Вывод
Contributor poker — это не просто метафора. Это рабочая модель, в которой мейнтейнеры сознательно инвестируют в людей, а не в код. LLM подрывает эту модель, потому что позволяет генерировать «идеальный» код без инвестиций в человека.
Zig выбрал радикальную позицию — полный запрет. Это непрактично для большинства проектов, но даёт ясный сигнал: в мире, где LLMs генерируют код быстрее людей, способность проекта растить человеческий капитал становится конкурентным преимуществом. Сообщество Zig ценит это — и готовы платить скоростью за идеологию.
Bun продолжит работать на своём форке. Техническое ускорение останется эксклюзивом для пользователей Bun. Для индустрии это история о том, что open source-модель «ставка на человека» имеет свою цену — и не всегда она совместима с темпами развития, которые ожидают бизнес.
FAQ
Разве запрет не замедлит развитие Zig?
Потенциально — да. Но Zig Software Foundation делает ставку на качество экосистемы, а не на скорость. Принятие быстрых LLM-патчей может ускорить один релиз, но создаст культуру зависимости от внешних инструментов. Zig предпочитает медленный рост с глубокими корнями.
Почему Bun просто не наймёт команду Zig?
Bun фактически так и сделала — купила компанию. Anthropic купила Oven (создателей Bun) в декабре 2025. Это не решает проблему — новые инженеры Bun генерируют LLM-патчи так же, как и любые другие. Принадлежность к корпорации не меняет того факта, что код написан с помощью LLMs.
Graduated Contributor License
Graduated Contributor License — модель, при которой LLM-assisted вклад разрешён после нескольких успешно принятых человеческих PRов. Сначала человек доказывает, что умеет писать код без LLMs, потом получает «сертификат доверия». Это не идеальное решение, но оно сохраняет модель роста contributor poker для новых участников.
Есть ли альтернативы полному запрету?
Да. Некоторые проекты экспериментируют с «Graduated Contributor License», где LLM-вклад разрешён, но автор обязан пройти собеседование на понимание кода. Другие требуют подписать declaration о роли LLM в написании PR. Третьи ведут эксперименты с метриками: сколько времени мейнтейнер тратит на LLM-assisted vs human-only PRы. Универсального ответа пока нет.