Крупнейшие AI-нативные open-source проекты пересматривают фундаментальный принцип GitHub — открытость пул-реквестов. Vercel AI SDK (более 20 млн загрузок npm в неделю), фреймворк Astro (62 тыс. звёзд), Flue и редактор tldraw (50 тыс. звёзд) либо полностью закрыли приём внешних PR, либо заменили их автоматизированными конвейерами — так называемыми «программными фабриками» (software factories). Причина — лавина AI-сгенерированных «мусорных» патчей, которые требуют больше времени на ревью, чем написание кода с нуля.
Почему пул-реквесты перестали работать
В основе коллапса лежит разрушение негласного сигнала, который удерживал систему open-source на плаву: раньше отправка PR означала, что автор потратил время на изучение кодовой базы и написание осмысленного патча. Это делало ревью оправданным. С появлением доступных LLM любой желающий может сгенерировать правдоподобный патч за секунды. Объём входящих заявок резко вырос, а качество сигнала упал до нуля.
В статье Latent Space от 1 сентября 2026 года Ричард Макманус приводит данные: только Vercel AI SDK к концу июня накопил более 1000 открытых issues и почти 800 пул-реквестов. Мейнтейнеры оказались в ситуации, когда они тратят всё время на сортировку и ревью, а не на развитие проекта. Аналогичная картина сложилась в Astro, где, по словам создателя Фреда Шотта, «issues поступали быстрее, чем мы могли их обрабатывать».
Как работают «программные фабрики»
Vercel опубликовал развёрнутое описание своего подхода в посте «Building a software factory for AI SDK». Вместо того чтобы доверять сообществу, команда развернула собственную систему агентов, каждый из которых отвечает за строго определённую задачу:
- Агент воспроизведения бага
- Агент применения исправления
- Агент ревью кода
- Агент закрытия issues
Инженер Vercel Ларс Граммел пояснил в видео: «Если у нас есть очень специфичный агент с конкретным промптом, который мы оптимизировали, и мы знаем, что исторически он был успешен в исправлении определённой категории багов, — мы доверяем этой конфигурации». Архитектура развёртывания включает UI, веб-приложение, API, среду выполнения и песочницы, синхронизированные с GitHub.
Результат за четыре недели: фабрика создаёт от 25 до 35% всех мержимых PR и закрывает 70–80% issues. Человек остаётся только на этапе финального мержа.
Astro и Flue: от триажа к полному закрытию
Проект Astro внедрил похожую систему «автотриажа». Как рассказывает Шотт, «за последние шесть месяцев всё полностью изменилось. Мы теперь можем решать проблемы с помощью автоматизации: триаж, воспроизведение, получение от пользователя подтверждения исправления, которое предлагает бот, — и только потом мы смотрим на это».
На основе этого опыта Шотт создал собственный агентный фреймворк Flue, который пошёл ещё дальше. В руководстве для контрибьюторов Flue прямо указано: «мы собираемся переосмыслить то, как это работает» — в частности, чтобы предотвратить «Drive-by AI slop PRs». Каждый внешний пул-реквест автоматически закрывается и конвертируется в issue или обсуждение. Баг-репорты и предложения исправлений становятся issues, фича-реквесты — дискуссиями. Команда использует «лучшие доступные SOTA LLM» для принятия решений о том, что делать дальше.
tldraw и позиция сообщества
Редактор tldraw также автоматически закрывает внешние PR. Создатель Стив Руис объяснил это решение в январе, а в июне подтвердил его, сославшись на «изменения в том, как мы пишем код (больше обсуждений, больше агентов), социальные практики публичного вклада и меняющийся ландшафт безопасности кода».
Митчелл Хашимото, сооснователь HashiCorp и создатель Ghostty, пошёл ещё дальше: он считает, что «будущее в том, что крупные open-source проекты полностью закроют внешние вклады». Руис с ним согласен: «Всё меньше смысла в том, чтобы люди присылали код, если задача достаточно хорошо специфицирована и код может быть написан агентами».
Что теряет сообщество и что приобретает
Традиционно пул-реквесты служили не только для улучшения кода, но и для обучения новых мейнтейнеров. Ревью было актом менторства. В новой модели этот канал исчезает. Шотт признаёт риск: «Это всё ещё оставляет место для…» — и указывает на необходимость поиска новых способов вовлечения сообщества.
С другой стороны, «программные фабрики» решают проблему, которую не могли решить люди: бесконечный backlog. Как отмечает Шотт, «я никогда не видел такого за весь свой десятилетний опыт работы с open-source. Возможность каждую неделю приоритизировать issues — независимо от всего — вместо бесконечного тримминга бэклога».
Практический вывод для разработчиков
Для мейнтейнеров и команд, управляющих open-source проектами, происходящее — не просто тренд, а сигнал к действию. Если проект уже испытывает проблемы с качеством входящих PR, стоит рассмотреть следующие шаги:
Оценить объём входящих PR и issues за последние 3–6 месяцев.
Внедрить автоматизированный триаж: бот, который проверяет наличие воспроизводимого примера, соответствие гайдлайнам и базовую корректность.
3. Создать специализированных агентов для воспроизведения и исправления типовых багов, как это сделали в Vercel.
4. Рассмотреть возможность закрытия прямых PR в пользу issue/дискуссий с последующей реализацией агентами — по примеру Flue и tldraw.
Важно понимать: речь не об отказе от сообщества, а о смене модели взаимодействия. Вместо «пришли код — получи ревью» появляется «опиши проблему — получи решение от агента под контролем мейнтейнера».
Ограничение: пока что описанные практики — это опыт нескольких громких проектов. Нет крупномасштабных исследований, подтверждающих, что «фабрики» работают для всех типов проектов (например, для инфраструктурных библиотек с низкой частотой коммитов или для проектов, где критична безопасность и аудит каждой строки). Кроме того, полностью закрытые проекты рискуют потерять поток новых идей и контрибьюторов, которые со временем становятся мейнтейнерами.