GitHub Octoverse 2026: агенты начали свыше 40% пул-реквестов
Отчет GitHub Octoverse 2026, представленный 28 октября 2026 года на GitHub Universe, говорит, что ИИ-агенты начали больше 40% пул-реквестов на платформе в сентябре 2026 года против 17% в марте. Число объединенных пул-реквестов утроилось меньше чем за год и достигло 220 млн в месяц. Для софтверных компаний эти цифры показывают, куда движется работа: агенты пишут больше черновиков кода, а на проверку, безопасность и правила слияния ложится больше нагрузки.
Что GitHub измерил в этом году
Отчет измеряет, насколько больше работы теперь идет через GitHub. Исполнительный вице-президент GitHub Джей Парих представил отчет на GitHub Universe, и его главные цифры показывают, как быстро выросла активность. Число объединенных пул-реквестов утроилось меньше чем за год и достигло 220 млн в месяц. Число коммитов выросло больше чем втрое, до 7,38 млрд в месяц, причем основной рост пришелся на вторую половину года. Темп создания новых репозиториев удвоился до 30,3 млн в месяц.
Отчетный период шел с 1 октября 2025 года по 30 сентября 2026 года. Цифры по агентам опираются на собственное определение GitHub активности агентов на платформе. Для некоторых разбивок GitHub сам использовал ИИ: языковая модель классифицировала профили пользователей по странам, а дообученная многоязычная модель эмбеддингов распределила публичные репозитории по отраслям.
Какую долю работы теперь начинают ИИ-агенты
Более 40% пул-реквестов на GitHub в сентябре 2026 года начинались с черновика, созданного ИИ-агентом, против 17% в марте. Только в сентябре агенты начали 110 млн пул-реквестов, примерно в шесть раз больше, чем в марте.
Работа агентов тоже обычно шире. GitHub обнаружил, что 87% пул-реквестов, начатых агентами, меняли несколько файлов, против 79% пул-реквестов без выявленного участия агента. Доля пул-реквестов с участием агентов, объединенных в течение двух недель, выросла с 83% в феврале до 90% в сентябре, а у остальных осталась около 86%. GitHub отмечает, что эти цифры описывают время до слияния, а не качество кода.
Как разработчики используют возможности агентов в Copilot
Среди ежемесячно активных пользователей GitHub Copilot 55% использовали агентные функции против 35% годом ранее. Использование облачного агента Copilot, который позволяет разработчику поручить агенту задачу, чтобы тот довел ее сам, выросло на 230% за год, а использование чата с агентом на 85%.
GitHub также выпустил Copilot Projects в публичный предпросмотр. Он позволяет разработчикам координировать агентов в нескольких репозиториях, подавать контекст из файлов дизайна, разговоров в Slack и заметок встреч и проверять результат.
Как GitHub справляется с проверкой кода, написанного агентами
Больше кода значит больше проверки, и цифры GitHub показывают быстрый рост инструментов проверки и безопасности. Использование проверки кода с поддержкой ИИ и GitHub Advanced Security выросло более чем на 90% за год в каждом случае. Разработчики объединили более 30 млн пул-реквестов Dependabot, примерно вдвое больше, чем в 2025 году.
К сентябрю более 264 000 разработчиков использовали многослойные пул-реквесты. Эта функция разбивает крупное изменение на меньшие пул-реквесты, которые можно проверять по одному, и она стала общедоступной 6 октября. GitHub говорит, что в репозиториях, где ее применяли, объем объединенного кода за время предпросмотра вырос на 9%, но не утверждает, что причиной стала только эта функция.
"Для команды, проверяющей работу друг друга, это было заметное улучшение в том, как мы сотрудничаем." Дэвид Мостоллер, инженер-программист Comcast, о многослойных пул-реквестах
28 октября GitHub добавил в публичный предпросмотр Copilot code review Max, который запускает независимых агентов проверки на моделях разных провайдеров и объединяет их выводы. Агентное автоисправление стало общедоступным 15 октября: Copilot предлагает исправления до 25 предупреждений сканирования кода в одном пул-реквесте и повторно запускает CodeQL, чтобы их проверить.
Что этот сдвиг значит для руководителей разработки
Для бизнеса, который выпускает программы, узкое место смещается с написания кода на его проверку. Когда агенты начинают свыше 40% пул-реквестов, пределом выработки становится число изменений, которые люди способны уверенно проверить.
Собственные средства контроля GitHub показывают, как компания ждет от других управления этим. Одобрения Copilot, теперь общедоступные, могут засчитываться в обязательные одобрения, но по умолчанию отключены, администраторы могут ограничить пути к файлам, которые Copilot вправе одобрять, а одобрение снимается, если позже приходят новые коммиты. Командам, внедряющим агентов, нужны правила проверки такого же рода до того, как придет объем.
Вопросы и ответы
Какую долю пул-реквестов GitHub начинают ИИ-агенты?
Более 40% в сентябре 2026 года против 17% в марте, согласно отчету GitHub Octoverse 2026. Только в сентябре агенты начали 110 млн пул-реквестов.
Сколько пул-реквестов объединяется на GitHub каждый месяц?
Около 220 млн в месяц в 2026 году, втрое больше, чем меньше года назад, говорит GitHub.
Что такое Copilot code review Max?
Вариант проверки в публичном предпросмотре с 28 октября, который запускает независимых агентов проверки на моделях разных провайдеров и объединяет их выводы в одну проверку. GitHub говорит, что он занимает больше времени и тратит больше кредитов ИИ, чем варианты Lite и Balanced.
Взгляд MOZGII
Как бы мы это построили
Когда агенты начинают большую долю изменений, дефицитным ресурсом в команде разработки становится не набор текста, а внимательное чтение. Если бы мы настраивали команду под это, то начали бы с пути проверки, а не с агента. Каждый начатый агентом пул-реквест нес бы короткую заметку о том, что изменено и зачем, какие тесты запущены и какие файлы затронуты, чтобы проверяющий начинал с контекста, а не с сырого различия.
Мы бы держали изменения небольшими, потому что маленькое изменение проще проверить, чем большое, и по правилу направляли бы любое изменение, касающееся входа в систему или общих библиотек, старшему проверяющему. Одобрения ИИ для этих путей оставались бы выключенными. Вторая модель, проверяющая первую, может поймать ошибки, но решение о слиянии все равно принадлежало бы человеку.
Сбой случился бы там, где объем обгоняет внимание. Если проверяющие каждый день сталкиваются с гораздо большим числом пул-реквестов, они начинают одобрять по привычке, и цифры скорости выглядят хорошо, пока качество падает. Поэтому мы бы не следили за временем до слияния. Единственная метрика, за которой мы бы следили, это доля объединенных изменений агентов, которые откатывают или исправляют в течение нескольких недель. Далее мы создали бы еженедельный отчет, который показывает проверяющим, какие виды изменений агентов потребовали больше всего доработок, чтобы команда знала, куда смотреть внимательнее.
Источники
Откуда взяты факты этой новости.