GitHub опубликовал подробный разбор того, как поддерживать контроль над проектом с ростом числа вкладов от ИИ-агентов. Материал основан на опыте Николаса Тиндла, ведущего инженера по ИИ и мейнтейнера AutoGPT, одного из самых популярных репозиториев на GitHub с более чем 180 000 звёзд и около 150 открытых pull request в момент интервью.
По словам Тиндла, значительная часть входящих pull request в AutoGPT создаётся агентами и инструментами вроде Copilot, OpenClaw и внутреннего инструментария AutoGPT. Многие мейнтейнеры в такой ситуации предпочитают закрывать внешний вклад, чтобы не перегружать команду разбором некачественных изменений. Тиндл предлагает другой подход: если кто-то тратит свои токены на улучшение вашего проекта, имеет смысл принять этот вклад, но выстроить чёткие правила, по которым он попадает в репозиторий.
Команда AutoGPT сначала усилила стандартную документацию: добавила расширенные рекомендации для контрибьюторов, улучшила README и оформила подробную wiki. Однако это практически не повлияло на качество вкладов агентов, потому что ИИ-инструменты сами по себе не ищут документацию. Они читают только те файлы, которые получают в контексте, обычно на уровне текущего каталога.
Следующий шаг — разместить инструкции там, куда реально смотрят агенты. AutoGPT начала с файлов CLAUDE.md для запросов, которые формировались моделью Claude, так как её коммиты легко было отследить по трейлерам. Затем выяснилось, что Copilot и Codex такие файлы игнорируют. Команда ввела единый формат AGENTS.md и стала ссылаться на него из файлов для отдельных моделей, чтобы все инструменты работали с одной точкой входа.
Ключевой момент — привязка инструкций к каталогу, а не только к репозиторию в целом. AGENTS.md размещается рядом с кодом, который он регулирует, а специальные файлы-навыки (skills) позволяют агентам динамически подгружать нужные правила. Навык — это файл с описанием, которое подсказывает агенту, когда его следует применить. Агент просматривает описания заранее и загружает полные инструкции, если задача подходит под условия.
Так, фронтенд‑разработчик AutoGPT устал от однотипно сломанных pull request по интерфейсу и оформил подробное руководство как навык. В его описании указали фразу‑триггер: «пиши тесты Storybook для компонентов из этих каталогов». Теперь любой инструмент, который работает с репозиторием, автоматически находит это правило и использует его. Аналогичный механизм используют в бекенде: навык требует достичь 80% тестового покрытия, прежде чем открывать pull request.
AutoGPT использует несколько «заслонов», которые можно применить и в других проектах. Первый — жёсткое соблюдение шаблона pull request. Агентам прямо сообщают, что заявки, не соответствующие шаблону, закрываются автоматически. Команда даже создала tooling для такой автоматизации, но почти не запускает его: правило само по себе изменило поведение агентов. При этом люди иногда выходят за рамки шаблона, и Тиндл считает это полезным сигналом: если шаблон нарушен, вероятно, перед тобой человек, и с ним стоит общаться мягче.
В шаблон включили обязательный план тестирования. Формулировка пунктов подобрана так, чтобы активировать навык test PR: он может установить браузерный агент (с разрешения), развернуть приложение и выполнить изменения. Агент начинал просто заполнять чекбокс в шаблоне, но в итоге реально запускал и проверял код. После этого команда практически перестала получать нерабочие pull request, оставались заявки, которые формально корректны, но не соответствуют дорожной карте, что заметно легче для мейнтейнера.
Контроль CI тоже перевели в разряд жёстких требований. Пороги покрытия Codecov настроены как обязательные проверки. Агент открывает pull request, через несколько минут видит, что слияние невозможно, подгружает навык тестирования и дописывает тесты. Это снижает нагрузку на людей, так как им не нужно каждый раз просить о дополнительном покрытии.
Отдельный фильтр — соглашение с автором (CLA). AutoGPT использует двойное лицензирование, но Тиндл уверен, что подобная практика полезна для любого проекта, даже с лицензией MIT. Подписание требует браузера и OAuth‑авторизации GitHub на другом домене, с чем агенты пока справляются плохо. В AutoGPT действует простое правило: если CLA не подписано в течение недели, pull request закрывается с комментарием, предлагающим подписать документ и переоткрыть заявку. Этот барьер снова возвращает человека в процесс. Аналогичную функцию может выполнять флажок принятия кодекса поведения.
Ещё одна проблема — ИИ‑агенты, которые автоматически помечают все комментарии в ревью как «решённые», не меняя код. Для этого в репозитории AutoGPT добавлен навык pr-address, который задаёт допустимую последовательность действий: исправление, коммит, push, ответ на комментарий, затем закрытие ветки обсуждения. В ответе нужно приложить commit SHA, полученный через git rev-parse HEAD после коммита, чтобы агент не мог сослаться на старое изменение. Навык также явно описывает анти‑паттерны: ответы вроде «Принято к сведению» без исправлений или ссылка на коммит, который не затрагивает отмеченную строку, считаются нарушением.
AutoGPT пробовала и более продвинутые сценарии с агентами в CI. На одном из этапов Claude Code был интегрирован в GitHub Actions с аутентификацией внутри workflow, чтобы автоматически анализировать упавшие проверки и комментировать причины. Впоследствии команда перешла на Copilot с аналогичным результатом и без дополнительного секрета с широкими правами в CI. Однако постоянный поток комментариев от бота по каждому сбою оказался чрезмерным, и автоматическую «озвучку» падений отключили. Вывод: полезно оставлять те автоматизации, которые реально снижают нагрузку на мейнтейнера, и убирать те, что добавляют шум.
Опыт показал и обратную сторону конфигурационных файлов для агентов. Первая версия AGENTS.md была размножена по репозиторию, что ухудшило поведение инструментов: контекст засорился и внимание агентов сместилось к несущественным файлам. Если поведение ИИ‑помощников ухудшается, Тиндл советует вернуться к содержимому этих файлов и пересмотреть объём и структуру инструкций, вместо того чтобы полностью отказываться от подхода.
Отдельно обсуждаются технические ограничения при активном использовании GitHub API. Массовые интеграции, запускаемые от имени персональных аккаунтов через CLI, быстро упираются в лимиты GraphQL. Команда решила это, создав GitHub App и аутентифицируя CLI через него, что даёт более устойчивые квоты для автоматизированных инструментов.
Серьёзная инфраструктура для ревью обходится недёшево. AutoGPT использует стенд, который клонирует ветку, запускает восемь агентов с различными задачами, поднимает полный стек приложения и выгружает скриншоты. Нагрузка по ресурсам настолько велика, что сейчас такой комплексный прогон запускают только для очень маленьких или очень крупных pull request, где он приносит наибольшую пользу.
Тиндл также рекомендует регулярно проверять список авторизованных приложений GitHub. AutoGPT участвует в программе Secure Open Source Fund, и одним из итогов работы стала ревизия доступов: каждая протестированная и забытая интеграция зачастую оставляет после себя разрешённый доступ. Если вы перестали пользоваться каким‑то приложением, его стоит убрать из списка разрешённых. Автор материала подчёркивает, что вход через GitHub стал настолько привычным, что мало кто возвращается в настройки, чтобы увидеть полный перечень таких приложений.
Часть выводов Николаса относится не к инструментам, а к границам ответственности. Во‑первых, мейнтейнер не обязан принимать каждый pull request. Слияние кода, сгенерированного большой языковой моделью, всегда асимметрично: поддержку и исправления берёт на себя проект. Закрыть заявку и реализовать исправление самостоятельно — нормальный вариант.
Во‑вторых, репозиторий может сознательно ограничить тип внешнего вклада. Можно полностью отключить pull request, разрешить создание задач только коллабораторам или требовать предварительного обсуждения. Тиндл приводит в пример SQLite: проект не принимает внешние патчи, а работает с отчётами об ошибках. Такой формат тоже считается корректным для открытого кода, и у вашего проекта может быть собственная договорённость.
Наконец, если вы закрываете pull request и реализуете решение сами, Тиндл советует по возможности указывать исходного автора как соавтора коммита. У AutoGPT около 800 контрибьюторов, и добавление ещё одного ничего не меняет для проекта, но для участника важно, что его запрос был замечен и привёл к изменению.
Автор материала связывает происходящее с общим развитием практик открытого кода. Раньше формализация шла через лицензии, задачи и pull request, которые делали права, работу и ревью более прозрачными. Теперь на этом пути появляются инструкции в самом репозитории — от общих файлов AGENTS.md до точечных навыков рядом с кодом. AutoGPT уже дошёл до третьей версии такой структуры, и каждый шаг опирался на наблюдения за тем, как агенты реально используют эти файлы.
В завершение GitHub приглашает мейнтейнеров присоединиться к платформе maintainers.github.com. Николас Тиндл подчёркивает, что именно там он узнал о многих практиках, описанных в статье, и делится своими наработками. Это пространство, где команда GitHub собирает обратную связь, в том числе в формате инициативы Tiny Wins — небольших доработок по запросу мейнтейнеров, часть которых уже стала частью настроек и контролей, показанных в Maintainer Month. Учитывая, что всё больше контрибьюторов работают в режиме «AI‑first», имеет смысл зафиксировать правила рядом с кодом ещё до того, как в очередь попадёт следующий pull request.
В конце материала приводится краткая справка об авторе. Андреа — Senior Developer Advocate в GitHub с более чем десятилетним опытом в разработке инструментов для программистов. Она помогает сделать сложные технологии более доступными и пришла в разработку после службы в армии и работы в строительном менеджменте. Сейчас живёт во Флориде, поддерживает глобальные инициативы GitHub для open source и делится знаниями в том числе через соцсети под ником @acolombiadev.
Источник: GitHub
