Сопровождающие Godot перегружены потоком сомнительных AI‑патчей
Один из ведущих сопровождающих открытого игрового движка Godot и сооснователь компании W4 Games Реми Вершельде открыто рассказал о новой проблеме проекта: лавинообразном росте низкокачественных pull‑запросов, сгенерированных при помощи больших языковых моделей. По его словам, этот поток "нейрослопа" выматывает и деморализует разработчиков, которые занимаются ревью кода, и уже сейчас подрывает устойчивость привычной модели открытой разработки.
Godot упирается в потолок открытости
Godot традиционно позиционируется как один из самых дружелюбных к новичкам крупных open source‑проектов. Любой желающий может отправить изменения, получить обратную связь и в итоге повлиять на развитие движка. Команда сопровождающих сознательно вкладывала время в то, чтобы помогать авторам правок доводить их до приемлемого состояния - объяснять, переписывать, подсказывать архитектурные решения.
Однако, как отмечает Реми, с появлением доступных AI‑инструментов баланс нарушился. Количество сомнительных изменений стало таким, что сопровождающие уже не уверены, сколько ещё смогут выдерживать текущую нагрузку. В официальном репозитории Godot на GitHub сейчас скопилось более 4600 открытых pull‑запросов, и значимая их часть либо явно сгенерирована AI, либо содержит следы неосознанного использования нейросетей.
"Мусорные" pull‑запросы: много слов, мало смысла
Ситуацию со стороны игрового индустриального сообщества прокомментировал директор студии Hidden Folks Адриан де Йонг. Он описывает происходящее как "полный бардак" и "огромную потерю времени" для тех, кто занимается проверкой кода. По его наблюдениям, всё чаще встречаются патчи, которые:
- содержат бессмысленные или противоречивые изменения;
- сопровождаются переусердствованно подробными, но бессодержательными описаниями;
- отправляются людьми, которые сами не до конца понимают, что именно сделали.
Для сопровождающих это превращается в дополнительный фронт работы: им приходится не просто оценивать качество кода, но и разбираться, насколько автор вообще осознаёт последствия своих правок.
Новая реальность: проверять не только код, но и его происхождение
С появлением AI‑ассистентов классический процесс ревью усложнился. Теперь сопровождающим фактически нужно решать ещё три дополнительных задачи:
1. Пытаться понять, написан ли код человеком или сгенерирован нейросетью.
2. Оценивать, разбирается ли автор в том коде, который прислал.
3. Проверять, были ли реально проведены тесты, или результаты придуманы и поданы как факт.
Отдельный пласт проблем создают ситуации, когда на прямой вопрос об использовании AI авторы отвечают: "Я использовал его только для описания, потому что плохо пишу по‑английски". Формально такой вклад вроде бы остаётся "человеческим", но определить границу между редактурой текста и полноценной генерацией решения становится сложно. Реми признаётся, что в подобных случаях разработчики Godot просто не знают, как корректно классифицировать такие патчи - и, главное, как к ним относиться с точки зрения доверия и ответственности.
Постоянные сомнения и выгорание сопровождающих
Реми отмечает, что сопровождающим теперь приходится по нескольку раз в день перепроверять pull‑запросы от новых участников, каждый раз задаваясь вопросом: не является ли это очередным фрагментом нейросетевого "шума". Вместо обычной инженерной экспертизы - анализ архитектуры, стиля, производительности - значительная часть времени уходит на фильтрацию заведомо слабых или подозрительных правок.
Такой режим приводит не только к росту очереди из патчей, но и к сильному эмоциональному выгоранию. Люди, которые годами строили проект как открытую, дружелюбную среду для новых контрибьюторов, внезапно оказываются в роли "фильтров для мусора", вынужденных отбрасывать десятки сомнительных запросов и объяснять очевидные вещи.
Деньги как единственный реалистичный выход
По мнению Реми, если проект хочет сохранить прежнюю открытость - возможность для любого новичка влиться в сообщество и внести вклад, - без дополнительных ресурсов уже не обойтись. Он видит фактически один рабочий вариант: увеличение финансирования Godot, чтобы можно было оплачивать труд дополнительных сопровождающих, которые займутся разбором и фильтрацией "AI‑слопа".
Фактически речь идёт о переходе от романтической модели "люди за идею" к более прагматичной: инфраструктура, ревью и поддержка качества кода становятся отдельной, сложной и трудоёмкой работой, за которую нужно платить. Иначе проект будет либо захлёбываться в низкокачественных изменениях, либо вынужден резко закручивать гайки и ограничивать входной порог для новых участников.
Godot - не единственный: похожие проблемы у Blender и других
Схожие трудности уже испытывают и другие крупные открытые проекты. Команда Blender в начале февраля начала разрабатывать официальную политику в отношении патчей, созданных с помощью AI‑инструментов. Речь идёт о необходимости чётко определить:
- должны ли авторы явно указывать факт использования AI;
- какие ограничения накладываются на такие патчи;
- несёт ли автор ответственность за сгенерированный код на тех же условиях, что и за написанный вручную.
Ранее аналогичные правила начали формировать или уже приняли целый ряд других проектов и организаций: Linux Foundation, Fedora, GNOME, Firefox, Ghostty, Servo, LLVM. Во всех случаях мотив один и тот же - защитить качество кода, юридическую чистоту вкладов и сохранить возможность нормальной работы сопровождающих.
Реакция GitHub: попытка ограничить лавину низкокачественных PR
Платформа, на которой разворачивается значительная часть открытой разработки, тоже не остаётся в стороне. В январе GitHub начал обсуждение мер по ограничению потока низкокачественных pull‑запросов, сгенерированных AI‑ассистентами и отправляемых без минимальной ручной проверки.
Проблема здесь двусторонняя:
- с одной стороны, AI‑подсказки действительно помогают ускорить разработку опытным программистам;
- с другой - те же инструменты в руках новичков порождают огромный объём "полуавтоматического" кода, который не проходит ни базового тестирования, ни осмысленного ревью со стороны автора.
Сопровождающие проектов оказываются в ситуации, когда многие PR формально выглядят "прилично", но по сути не соответствуют стандартам качества и создают для них дополнительную нагрузку.
---
Почему "нейрослоп" так разрушителен именно для open source
Ситуация вокруг Godot и других проектов показывает, что проблема не сводится просто к "плохому коду". В открытых проектах ключевую роль играют не только строки кода, но и:
- доверие между участниками;
- прозрачность происхождения изменений;
- способность новичков учиться на обратной связи;
- накопление человеческой экспертизы внутри сообщества.
AI‑генерация эти процессы подрывает. Вместо того чтобы разбираться в архитектуре движка, пользователь часто просит нейросеть "написать патч", а затем механически отправляет результат. Обратная связь сопровождающего в такой модели мало чему учит: автор не понимает, что именно нужно исправить, и нередко повторяет те же ошибки, снова полагаясь на AI.
В итоге сопровождающие выполняют не привычную роль наставников и архитекторов, а роль цензоров и фильтров, отбирающих микроскопический процент осмысленных правок из массы автоматически сгенерированных.
Качество против количества: как AI ломает метрики вклада
Открытые проекты долгое время ориентировались на довольно простые метрики активности: количество pull‑запросов, частота коммитов, число участников. В эпоху нейросетей эти показатели теряют смысл. Один человек с доступом к AI‑ассистенту способен генерировать десятки правок в день, не вкладывая реального понимания в происходящее.
Это создаёт ложное ощущение бурной активности, за которой часто не стоит никакого устойчивого вклада: патчи отклоняются, переписываются другими участниками или порождают новые баги. Реальная ценность проекта по-прежнему создаётся меньшинством опытных разработчиков, но их труд "тонет" в море малосодержательных PR.
Для Godot и подобных проектов это означает необходимость пересмотра критериев вклада: количество начинает вредить качеству, а открытая дверь для всех превращается в угрозу для стабильности разработки.
Возможные стратегии защиты от AI‑шумов
Несмотря на сложность ситуации, у проектов вроде Godot есть несколько потенциальных направлений, в которых можно искать решения:
1. Явное декларирование использования AI.
Требование к авторам честно отмечать, какие части патча были сгенерированы, а какие - написаны вручную. Это не решит всех проблем, но снизит уровень неопределённости.
2. Повышение планки входа для кода.
Например, требование к новичкам сопровождать каждое изменение развёрнутым техническим обоснованием и реальными результатами тестов, а не только описанием на естественном языке.
3. Фокус на малообъёмных, но осмысленных правках.
Поощрение небольшой, целенаправленной работы (исправление одного конкретного бага, улучшение документации в узком месте) вместо "массовых улучшений", которые нейросети так любят предлагать.
4. Разделение ролей: ревью кода и модерация AI‑контента.
То, о чём уже говорил Реми: выделение части сопровождающих или оплачиваемых сотрудников, которые будут заниматься именно фильтрацией AI‑патчей, освобождая ключевых разработчиков для архитектурных задач.
5. Образовательные материалы по ответственному использованию AI.
Многие разработчики просто не понимают, как правильно использовать нейросети в open source. Чёткие гайды - когда AI уместен, а когда лучше отказаться от его помощи - могут уменьшить объём мусорных PR.
Этика и ответственность: кто отвечает за код нейросети
Особый вопрос - ответственность за сгенерированный код. Если автор патча не полностью понимает предложенное AI решение, он фактически выступает не как разработчик, а как человек, делегировавший написание кода внешнему "чёрному ящику". Для open source‑проекта это риск:
- юридический (неясное происхождение фрагментов кода, возможные нарушения лицензий);
- технический (скрытые баги, уязвимости, неочевидные побочные эффекты);
- репутационный (снижение доверия к проекту и качеству его кода).
Логика большинства новых политик сводится к тому, что ответственность в любом случае остаётся на человеке, отправившем PR. Но на практике проверять реальное понимание автором кода крайне трудно.
Как сохранить открытость и не утонуть в потоке AI‑патчей
Для Godot и других проектов сейчас стоит ключевая задача: не превратиться в закрытый клуб "только для своих", но при этом не позволить лавине низкокачественных изменений парализовать разработку. Реалистичным компромиссом может стать многоуровневая модель участия:
- новички начинают с задач по документации, тестам, несложным исправлениям;
- среднеопытные участники получают доступ к более сложным зонам кода, но только после серии проверенных и осмысленных вкладов;
- основные разработчики и сопровождающие концентрируются на архитектуре и ключевых подсистемах, а не на разборе хаотичных предложений нейросети.
При этом AI может оставаться инструментом - но именно инструментом в руках человека, а не автономным "генератором патчей".
Что дальше ждёт Godot и open source
Ситуация вокруг Godot показывает, что эпоха "наивного энтузиазма" в отношении генеративного AI в open source стремительно заканчивается. Проекты переходят от экспериментов к выработке строгих правил: где нейросети уместны, как фиксировать их использование и как защитить людей, которые добровольно тратят своё время на поддержание качества кода.
Если Godot удастся вовремя усилить команду сопровождающих, в том числе за счёт финансирования, и выстроить понятную политику работы с AI‑патчами, у проекта есть шанс сохранить свою открытость, не превратившись в свалку сгенерированных изменений. В противном случае всё больше разработчиков будет выгорать и уходить, а очередь из тысяч PR станет не признаком живости сообщества, а символом системного кризиса модели "код от всех для всех" в эпоху больших языковых моделей.
