Покер контрибьюторов

"Contributor poker" (покер контрибьюторов) - формулировка Zig Software Foundation для распределения времени мейнтейнеров на ревью, предложенная Loris Cro в защиту полного запрета на вклад с помощью LLM в Zig. Фраза отсылает к покерному принципу "играй против человека, а не карт" - проверяя PR, мейнтейнер делает ставку на будущие отношения с контрибьютором, а не на сиюминутную ценность патча.

Суть аргумента

Время мейнтейнеров на ревью - узкое место любого успешного open-source проекта. Когда проект начинает получать больше PR'ов, чем мейнтейнеры способны обработать, возникают две стратегии:

Принимать только почти идеальные PR'ы. Максимизировать отдачу от артефакта на минуту ревью. К этому склоняется большинство проектов по мере роста популярности.
Принимать несовершенные PR'ы и помогать авторам их доработать. Рассматривать ревью как инвестицию в расширение базы контрибьюторов. Первые PR'ы - плата за обучение ради долгосрочных отношений.

Zig осознанно выбирает (2). Аргумент не в том, что это добрее, а в том, что это разумный шаг в долгосрочной перспективе. Каждый контрибьютор, чей первый PR довели до финиша терпеливым ревью, становится тем, кто сможет делать ревью для следующего участника. Сложный процент накапливается в людях, а не в патчах.

Как это ломают PR'ы, написанные LLM

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

Идеальный PR от LLM даёт нулевой результат в плане отношений. Артефакт хорош, но новый контрибьютор не вырос. Время мейнтейнера ушло на то, что LLM могла бы сделать без присмотра.
Несовершенный PR от LLM даёт отрицательный результат. Мейнтейнер вынужден объяснять человеку перед LLM, что не так, но ошибку допустил не этот человек, а LLM. Обратная связь не доходит до реального автора. Цикл не замыкается.

В итоге мейнтейнер при проверке PR от LLM несёт те же затраты, что и при ревью человека, но не получает никакой долгосрочной отдачи.

Замечание Simon Willison'а

Simon Willison приводит более резкую версию того же аргумента: если PR по большей части написан LLM, зачем мейнтейнеру вообще проверять и обсуждать его, вместо того чтобы запустить собственную LLM и решить задачу напрямую? Мейнтейнер и сам может создать артефакт; незаменимы только человеческие отношения. Поэтому трата времени на ревью PR'ов, написанных LLM, - это обмен чего-то невосполнимого на то, что у мейнтейнера уже есть.

В who-teaches-you представлена позиция со стороны контрибьютора: учитель, знающий ученика, - то, чем LLM быть не может.

Когда этот подход применим

Речь идёт именно о проектах, чья модель развития строится вокруг людей, а не артефактов:

Волонтёрские open-source проекты, где главное узкое место - часы мейнтейнеров
Проекты, которым нужен длинный хвост контрибьюторов (никто не может вечно финансировать штатную команду)
Проекты с сильной культурой ("культура Zig" / "культура Rust" / "культура Linux"), которую усваивают годами и которая передаётся от контрибьютора к контрибьютору

Это явно не относится к:

Open-source проектам одной компании (single-vendor), где взращивание контрибьюторов не является стратегией (компания сама нанимает разработчиков)
Проектам, чья ценность полностью заключается в артефакте, а не в сообществе (одноразовые утилиты, публикации наборов данных)
Проектам, где время на ревью не является сдерживающим фактором

Почему этот аргумент устойчив

Большинство полных запретов на LLM в open source объясняли качеством (галлюцинации LLM), лицензированием (происхождение обучающих данных) или спамом (шум от ИИ). Все три проблемы реальны, но против каждой есть частичный контраргумент: люди тоже ошибаются, лицензионные споры трудно разрешать по каждому PR'у отдельно, а фильтры спама существуют.

Аргумент о покере контрибьюторов устроен иначе. Он не зависит от того, плох ли результат работы LLM. Он утверждает, что цель ревью - растить людей, а PR от LLM оптимизирует артефакт в ущерб этой цели. Такой довод останется в силе, даже если LLM станут неотличимы от senior-инженеров.

В how-ai-is-changing-open-source к аналогичному выводу приходит Jiří Eischmann со стороны Red Hat и GNOME, а не Zig. Потеря, которая его волнует, - тоже не пропускная способность: через ревью мейнтейнеры растили участников и будущих преемников, а в предложенных изменениях, которые ничего не стоили автору и в которых он сам не разбирается, попросту нечего наставлять.

Обратная сторона

Видимая цена вполне осязаема: форк компилятора Zig от Bun с 4-кратным приростом производительности не будет принят в upstream, так как был создан с помощью ИИ. Это существенное улучшение, которое не вернётся обратно. Стоит ли овчинка выделки, зависит от того, какой актив считать долговечным; позиция Zig состоит в том, что долговечна база контрибьюторов, а не текущий компилятор.

Связанные страницы

simonw-zig-anti-ai - разбор от Simon Willison'а
zig - язык, чью политику защищает этот подход
i-dont-want-your-prs - смежное переосмысление open source в эпоху LLM с другого ракурса (полный отказ от PR'ов в пользу промптов и форков)
llm-enshittification - максималистский аргумент против LLM во FLOSS
tools-matter - противоположная ставка на то же узкое место: дерево поручительств Manganin ограничивает доступ требованием поручительства от уже проверенного участника, ставящего на кон свою репутацию; подход оптимизирует экономию внимания мейнтейнеров, а не взращивание контрибьюторов