Мне больше не нужны ваши PR'ы

Апрельский пост 2026 года Dawid Ciężarkiewicz переосмысляет то, как мейнтейнерам опенсорса стоит относиться к внешним контрибьюциям теперь, когда с приходом LLM написание кода перестало быть узким местом. Это не выпад против сотрудничества - изменилась сама форма полезного участия.

Баланс до эпохи LLM

Случайный PR от незнакомого человека всегда нёс издержки: риск для безопасности (вредоносный код, спрятанный в патче), несовпадение стилей (предпочтения контрибьютора расходятся с соглашениями проекта), накладные расходы на координацию (раунды review, CI, конфликты слияния, разница в часовых поясах). Платить эту цену имело смысл, потому что написание кода отнимало уйму времени, и "добротный, рабочий, легко проверяемый PR" окупал себя за счёт сэкономленного на реализации времени.

Почему LLM всё переворачивают

Для мейнтейнера, использующего инструменты на базе LLM, написание кода больше не является узким местом. Настоящие препятствия теперь другие:

Понимание - чтение существующего кода достаточно глубоко, чтобы осмысливать его.
Проектирование - принятие решений о том, какие изменения и какая архитектура нужны.
Review - проверка того, что получившийся код делает именно то, что задумывалось.

PR не помогает ни с одним из этих пунктов. Мейнтейнеру всё равно нужно понять изменение, решить, подходит ли архитектура, и провести review кода - причём по чужому графику, с чужим стилем и с неизбежными опасениями насчёт безопасности. Ответный ход - просто поручить реализацию собственной LLM: никаких стилевых конфликтов (LLM соблюдает зафиксированные правила проекта), никаких рисков безопасности (мейнтейнер сам проверил написанное LLM) и никаких накладных расходов на координацию.

Исходный код уже не так фундаментален, как раньше

Мета-аргумент Ciężarkiewicz в том, что сам код становится скорее промежуточным формализованным слоем между мыслями мейнтейнера и машиной, а не главным итоговым артефактом. Такая мысль не нова - возможно, так было всегда, - но это становится очевидным на практике, когда самым дорогим шагом оказывается перевод идей в код, а не набор текста руками.

Это согласуется с идеями, уже описанными в вики:

cult-of-vibe-coding рассматривает отказ читать сгенерированный ИИ код как доведённый до абсурда dogfooding.
no-silver-bullet-llms доказывает, что математика всё равно ограничивает рост продуктивности от LLM.
peril-of-laziness-lost отмечает, что LLM лишены полезной человеческой лени, возникающей в условиях нехватки времени.
building-syntaqlite-ai - взгляд со стороны разработчика-одиночки: vibe-coding проваливается, дисциплинированное переписывание даёт результат, а проектирование невозможно делегировать.

Ciężarkiewicz здесь ближе к лагерю "ИИ помогает, но понимание и проектирование остаются за человеком".

Что делать вместо этого

В посте перечислены более полезные способы помочь мейнтейнеру с такой позицией:

Давать обратную связь. Мейнтейнеры выпускают код быстро, но у них нет времени самим им пользоваться. Отчёты о пользовательском опыте имеют значение.
Обсуждать идеи. Разные точки зрения определяют то, что и как создаётся.
Сообщать об ошибках и исследовать их. Хороший баг-репорт - это три четверти исправления. Воспроизведите проблему, локализуйте её, предложите решения.
Создавать прототипы в виде референсных PR - но обязательно прикладывать промпт. Быстрый PR может служить иллюстрацией, но реальным артефактом для обмена становится сгенерировавший его промпт. Промпты можно комбинировать и уточнять, тогда как PR приходится либо вливать, либо отклонять.
Проводить review кода и указывать на проблемы. Review - это узкое место мейнтейнера, поэтому ещё одна пара глаз всегда идёт на пользу.
Форкать и делиться выводами. Не стоит ждать консенсуса по архитектуре для редких сценариев. Внесите изменения под себя, делайте rebase (или нет) в удобном темпе и рассказывайте об извлечённых уроках.

Пункт "форкать и делиться выводами" наиболее интересен структурно. Он рассматривает форк как полноценное сотрудничество, а не как раскол: мейнтейнер получает выводы из чужого эксперимента, не беря на себя груз архитектурных компромиссов.

Почему это применимо не везде

Пост написан с позиции проекта одного автора или небольшой команды мейнтейнеров. Для проектов, где есть:

Цель онбординга контрибьюторов (менторство, постепенное выстраивание доверия) - отказ от PR убирает главный инструмент для роста доверия.
Code review как журнал аудита - в регулируемых или критичных для безопасности проектах проверка изменений несколькими людьми обязательна по регламенту, а не по желанию мейнтейнера.
Большие команды - накладные расходы на координацию, на которые сетует автор, являются неизбежной платой за наличие команды.

Поэтому рекомендации из статьи лучше всего подходят для инди-проектов и небольших групп в опенсорсе, и куда меньше - для масштабов Apache, Eclipse, CNCF или проектов с жёсткими нормативными требованиями.

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

dpc-pw - блог автора, добавленный в базу вместе с этим материалом
bubblewrap-dev-env - статья того же автора о песочницах для LLM-агентов
cult-of-vibe-coding, no-silver-bullet-llms, peril-of-laziness-lost, building-syntaqlite-ai - другие умеренно-скептические взгляды на LLM в вики
ai-assisted-workflow - дополняющий подход: "планирование предшествует коду, ИИ тестирует мышление на прочность"
how-ai-is-changing-open-source - то же переосмысление со стороны мейнтейнера, который уже тонет в этом потоке: сгенерированный ИИ патч для gvfs на 4 000 строк, который кому-то придётся поддерживать годами, и PR на 9 000 строк, автор которого так и не ответил на review
port-not-patch-contribution - зеркальный взгляд со стороны пользователя: когда форкать и портировать становится дёшево, цикл правок в upstream слабеет с обоих концов
stop-using-pull-requests - параллельная критика PR от Лафорджиа с позиции классических исследований в SWE (Bacchelli & Bird, DORA, Muller & Tichy) внутри доверенных команд, в то время как Ciężarkiewicz критикует их со стороны мейнтейнеров опенсорса через призму LLM