GitHub добавил массовый agentic autofix для GitHub Code Quality. Теперь разработчик может выбрать на одной странице до 25 стандартных находок и передать их Copilot одним действием. Агент создаёт отдельную ветку, готовит исправления, проверяет собственные изменения и открывает Pull Request для последующего ревью.
Обновление опубликовано в GitHub Changelog 9 сентября 2026 года: https://github.blog/changelog/2026-09-09-remediate-code-quality-findings-with-agentic-autofix
Новая схема рассчитана прежде всего на команды, которые накопили бэклог проблем качества и хотят обрабатывать его группами, а не запускать автофикс для каждой находки отдельно.
Одно действие вместо последовательной генерации исправлений
В прежнем интерфейсе для отдельной находки использовалась команда Generate fix. GitHub заменяет этот сценарий действием Assign to Copilot. Оно применяется и к одной проблеме, и к группе выбранных находок — максимум к 25 стандартным находкам на странице.
После назначения задачи Copilot работает не только как генератор фрагмента кода. Он выполняет агентный процесс:
- получает выбранные находки Code Quality;
- вносит изменения в отдельной ветке;
- проверяет подготовленный результат;
- создаёт Pull Request с исправлениями.
Такой формат оставляет решение за разработчиком. Изменения не отправляются напрямую в основную ветку: команда может изучить diff, запустить собственные проверки и решить, какие изменения принять, доработать или отклонить.
GitHub описывает функцию как способ быстрее сокращать накопившийся бэклог Code Quality. При этом в анонсе нет статистики о среднем времени обработки, доле принятых исправлений или количестве Pull Request, которые потребуют ручной доработки. Поэтому массовый режим пока следует воспринимать как инструмент автоматизации рутинной работы, а не как замену техническому ревью.
Лимит в 25 находок не означает, что нужно выбирать все
Ограничение установлено на уровне 25 стандартных находок на одной странице. Для небольшого набора предупреждений этого может быть достаточно, однако крупный бэклог придётся разбивать на несколько запусков.
Практический вопрос здесь не только в лимите интерфейса. Один Pull Request с большим числом разнородных исправлений сложнее проверять: ревьюеру нужно сопоставить каждое изменение с исходной находкой и убедиться, что агент не затронул соседнюю логику. Особенно это касается кода, связанного с обработкой ошибок, авторизацией, внешними сервисами и изменением состояния приложения.
Поэтому максимальная выборка не всегда будет оптимальной. Для первого запуска разумнее выбрать небольшую группу однотипных находок с низким риском, а затем проверить:
- соответствует ли каждое изменение исходному предупреждению;
- не появились ли посторонние изменения;
- проходят ли тесты, линтеры и обязательные проверки CI;
- не изменилось ли поведение программы в пограничных сценариях.
GitHub сообщает, что Copilot валидирует собственные изменения до открытия Pull Request, но не раскрывает в этом объявлении полный набор проверок и глубину анализа взаимосвязей между выбранными находками. Такая валидация не гарантирует, что исправление корректно для конкретной архитектуры или бизнес-логики проекта.
Доступ зависит от Code Quality и действующей политики
Массовый agentic autofix доступен репозиториям, где включён GitHub Code Quality, на следующих тарифах:
- GitHub Team;
- GitHub Enterprise Cloud;
- GitHub Enterprise Cloud с резиденцией данных.
Для этой функции не предусмотрена отдельная корпоративная политика. Согласно объявлению GitHub, массовое назначение использует уже действующие правила доступа к Code Quality: если предприятие разрешило GitHub Code Quality, пользователи могут передавать выбранные находки Copilot.
Это не означает, что функция автоматически появится у любого участника проекта. Должны быть выполнены как минимум условия, связанные с включением Code Quality для репозитория, правами пользователя и разрешённым использованием соответствующих возможностей Copilot. В документации GitHub по исправлению находок на Pull Request доступ к таким действиям описан для пользователей с правом записи: https://docs.github.com/en/code-security/how-tos/maintain-quality-code/fix-findings-on-a-pr
В анонсе также не сказано, распространяется ли описанный массовый сценарий на все типы находок и правила, доступные в конкретной конфигурации Code Quality. Подтверждено только ограничение на стандартные находки. Поддержку нестандартных правил, сторонних анализаторов или автоматическое слияние Pull Request не следует считать частью этого обновления без отдельного подтверждения GitHub.
Запуски расходуют AI-кредиты
Назначение находок Copilot расходует AI-кредиты. GitHub не указывает стоимость одной находки или одного Pull Request, поэтому расходы нельзя точно рассчитать простым умножением числа выбранных проблем на фиксированную ставку.
Для команды это означает, что перед массовой обработкой стоит проверить правила использования Copilot и доступный бюджет AI-кредитов. На практике стоимость и объём работы могут зависеть не только от числа находок, но и от сложности изменений, которые потребуется исследовать агенту.
Похожая модель применяется GitHub и в agentic autofix для оповещений CodeQL и сторонних инструментов сканирования. В июльском объявлении о предварительном доступе GitHub отдельно указывал, что такие операции используют AI-кредиты и минуты GitHub Actions: https://github.blog/changelog/2026-07-10-agentic-autofix-for-code-scanning-alerts-in-public-preview/
Для Code Quality в свежем анонсе упомянут расход AI-кредитов, но дополнительных параметров тарификации и отдельной детализации стоимости GitHub не приводит. Администраторам следует учитывать это при запуске обработки крупных групп находок.
Что изменится для разработчиков
Главное изменение — переход от исправления проблем по одной к управляемой пакетной работе через Copilot. Команда может выбрать часть накопившегося бэклога, получить результат в виде обычного Pull Request и применить к нему уже знакомый процесс: ревью, тестирование и слияние.
Этот подход снижает количество ручных действий, но не устраняет технические риски. Объединение нескольких исправлений в одном запросе может усложнить диагностику неудачных тестов и откат отдельных изменений. Для критичных компонентов безопаснее использовать небольшие группы и разделять несвязанные типы находок.
GitHub Roadmap описывает эту возможность как средство для работы с уже существующим бэклогом Code Quality, а не только с новыми проблемами, возникающими при изменении кода: https://github.com/github/roadmap/issues/1256
Перед первым массовым запуском команде стоит проверить, какие находки считаются стандартными в её конфигурации, какие права нужны пользователю, какие проверки запускаются в Pull Request и как расход AI-кредитов учитывается в организации. Это позволит оценить не только скорость автоматизации, но и стоимость последующего ревью.