GitHub опубликовал материал о том, как меняется менторство в open source на фоне роста ИИ-генерации кода и как поддерживать устойчивые проекты при растущем потоке вкладов.
Компания отмечает, что сегодня стало гораздо проще с помощью ИИ сгенерировать правдоподобный pull request, но нагрузка на мейнтейнеров при проверке изменений не снизилась. Стоимость создания кода упала, стоимость ревью осталась прежней. Это приводит к выгоранию тех, кто отвечает за поддержку проектов и наставничество.
В тексте говорится, что у открытого ПО появился свой «вечный сентябрь»: постоянный приток новых вкладчиков и заявок, который перегружает социальные механизмы доверия и обучения. Некоторые проекты уже ограничивают входящий поток: tldraw закрыли pull request’ы, Fastify прекратил работу с HackerOne из‑за слишком большого числа отчётов о проблемах.
По данным отчёта Octoverse 2025, разработчики в 2025 году объединяли почти 45 млн pull request’ов в месяц, что на 23 % больше, чем годом ранее, однако количество часов у мейнтейнеров не растёт. Старые сигналы качества — аккуратный код, быстрые правки, работа со сложными задачами — больше не гарантируют, что автор реально понял проект: ИИ способен за секунды выдать такой результат.
GitHub и другие платформы уже разрабатывают долгосрочные решения для снижения шума и восстановления доверия к вкладам. Команда продукта GitHub опубликовала RFC и собирает отзывы о том, какие механизмы могут помочь сообществам лучше работать с ИИ‑ассистированными изменениями.
При этом автор материала подчёркивает, что даже после появления платформенных инструментов проектам всё равно нужны рабочие стратегии наставничества. Мейнтейнеры выгорают, пытаясь обучать каждого автора случайного pull request’а. Если сообщество потеряет практику менторства, исчезнет и мультипликативный эффект, когда вчерашние новички сами начинают обучать других.
Предлагается подход из трёх «С» — Понимание (Comprehension), Контекст (Context), Непрерывность (Continuity), который помогает выбирать, в кого имеет смысл вкладывать силы наставника.
Понимание
Первый фильтр — понять, насколько хорошо автор изменения понимает проблему. Некоторые проекты теперь требуют сначала завести issue и получить согласование, а уже потом отправлять pull request. Так делают, например, Codex и Gemini CLI: проверка понимания проходит в обсуждении задачи до написания кода.
Отмечается, что офлайн‑мероприятия — спринты и хакатоны — тоже помогают: мейнтейнеры могут вживую оценить интерес и уровень понимания участников. Цель — убедиться, что человек не пытается вносить изменения выше своего уровня подготовки. По мере роста опыта он сможет брать более сложные задачи.
Контекст
Вторая часть — контекст для ревьюера: ссылка на issue, описание компромиссов и раскрытие использования ИИ. По мнению автора, раскрытие факта помощи ИИ даёт мейнтейнеру ориентиры: на что обратить внимание, какие вопросы задать и насколько глубоко проверять понимание предложенных изменений.
Некоторые проекты уже формализовали такие практики. У ROOST действует простая политика из трёх принципов. The Processing Foundation добавила чекбокс для раскрытия ИИ. Сообщество Fedora после долгих обсуждений приняло лёгкую политику раскрытия использования ИИ‑инструментов.
Параллельно развивается формат AGENTS.md — инструкции для ИИ‑агентов, по аналогии с robots.txt, но для Copilot и похожих средств. Такие файлы используют, например, scikit-learn, Goose и Processing. В них описывают правила для агентов: следовать руководствам по вкладу, проверять, назначена ли задача, уважать нормы сообщества. Это переносит значительную часть работы по сбору контекста на вкладчика и его инструменты.
Непрерывность
Третий фильтр — оценка того, возвращается ли человек к проекту и как он реагирует на обратную связь. Разовые «проездом» вклады бывают полезны, но глубокое наставничество, по мнению автора, стоит сохранять для тех, кто приходит снова и ведёт себя осмысленно: участвует в обсуждениях, отправляет повторные pull request’ы и внимательно учитывает комментарии.
Рекомендуется не тратить много сил на менторство до тех пор, пока не проявятся все три сигнала: понимание, контекст и непрерывность. Если приходит отточенный с виду pull request, но без соблюдения базовых правил, его стоит закрывать без чувства вины, чтобы сохранить время на действительно значимые вклады. Если же автор возвращается и улучшает взаимодействие, это повод вкладываться в него глубже.
Автор отмечает ещё один плюс чётких критериев: снижение предвзятости. Опора на личные впечатления часто ведёт к тому, что наставники выбирают людей, которые похожи на них по опыту или культурному фону. Набор прозрачных фильтров даёт более равные условия и делает менторство справедливее.
Подход с тремя «С» предлагается как способ не ограничивать ИИ‑вклады, а выстроить «ограждения», которые сохраняют ценность человеческого менторства и поддерживают здоровье сообществ. ИИ‑инструменты останутся частью разработки, а задача проектов — скорректировать практики так, чтобы сохранить основы open source: человеческие связи, передачу знаний и эффект мультипликации.
Материал основан на докладе Abigail Cabunoc Mayes на FOSDEM 2026. Автор работает в GitHub и занимается инициативами, направленными на то, чтобы экосистема открытого кода оставалась устойчивой и в дальнейшем.
В конце публикации GitHub также напоминает о своих инициативах в сфере безопасности open source: финансировании мейнтейнеров, партнёрстве с программой Alpha-Omega и расширении доступа к инструментам, снижающим нагрузку на разработчиков и укрепляющим цепочки поставок ПО. Отдельно упоминается GitHub Security Lab Taskflow Agent, который показывает высокую эффективность в поиске уязвимостей наподобие обхода аутентификации, IDOR, утечек токенов и других проблем с серьёзным влиянием.
Источник: публикация GitHub.
