Next.js закрыл 1 462 GitHub issue с помощью ИИ-агента: как это устроено

4 сентября 2026 года команда Next.js опубликовала подробный разбор необычной задачи: как разобрать огромный backlog GitHub issues не простым правилом «закрыть всё старое», а с помощью исследовательского AI-агента и проверки результатов мейнтейнерами.

История интересна не только разработчикам Next.js. Это хороший пример того, как ИИ можно встроить в реальный технический процесс: дать агенту ограниченные права, изолированное окружение, инструменты для проверки фактов и понятный формат результата, а важное решение оставить человеку.

Что произошло в репозитории Next.js

По официальному материалу Next.js, backlog достигал 3 109 открытых обращений в январе 2025 года. К 10 августа 2026 года открытыми оставались 2 244 issue. Среди них смешались актуальные регрессии, уже исправленные ошибки, дубли, проблемы старых неподдерживаемых версий и обращения, которые давно потеряли контекст.

Команда уже пробовала автоматически закрывать неактивные issue по возрасту, но пришла к важному выводу: давность не равна нерелевантности. Старый issue может описывать реальный баг, а относительно новый — уже быть исправленным или дублировать другой.

Вместо stale-таймера — исследовательский агент

Для массового разбора команда построила агент closability. Его задача — не нажать кнопку Close, а провести исследование и собрать доказательства, по которым можно решить, стоит ли закрывать конкретное обращение.

Агент запускается в отдельной sandbox-среде с репозиторием Next.js, Node.js, Playwright и Chromium. В процессе он читает обсуждение issue, проверяет поддерживаемые версии, ищет связанные pull request, commits, releases и документацию. Если нужно, он пытается воспроизвести проблему на заявленной версии, текущем stable и canary.

Ключевой приём: искать не только подтверждение, но и опровержение

Особенно полезная деталь архитектуры — агент должен искать evidence, которое противоречит его первоначальному выводу. Это снижает риск сценария, когда модель быстро нашла один удобный факт и остановилась.

Итог исследования возвращается как structured data: оценка уверенности, основная причина, краткое резюме, список доказательств и ссылки на связанные изменения. Такой формат удобнее свободного текста, потому что его можно сортировать, показывать в очереди проверки и использовать в следующих шагах автоматизации.

Почему агенту не дали право самостоятельно всё закрывать

На первом этапе агент был read-only за пределами sandbox. Он не мог писать комментарии, закрывать issue, пушить код или делать deployment. Результаты попадали в очередь, а мейнтейнеры читали собранные доказательства и принимали решение.

Это важный шаблон для любой AI-автоматизации: чем выше цена ошибки, тем осторожнее должен быть action layer. ИИ может отлично подготовить решение, но это не означает, что ему сразу нужно дать максимальные права.

Какой результат получила команда

По состоянию на 4 сентября Next.js сообщил о 1 462 закрытых issue по репозиторию примерно за три недели активной работы, включая часть обращений, закрытых мейнтейнерами вне этой конкретной проверки. Backlog сократился ниже 1 000, хотя за это время поступали новые обращения.

Для контроля ошибок команда также добавила механизм повторного открытия. На дату публикации официального материала из закрытых обращений были повторно открыты 3.

Что можно взять из этого подхода для бизнеса

Самая полезная идея — не «поставить ИИ вместо сотрудника», а разделить процесс на исследование, доказательства, решение и действие. Такой принцип хорошо переносится на обработку заявок, техническую поддержку, классификацию обращений, проверку документов и внутренние операционные задачи.

• Ограничить права. Агенту не обязательно разрешать менять данные, если сначала достаточно собрать факты.
• Использовать structured output. Поля статуса, уверенности, причины и источников проще проверять и передавать дальше.
• Изолировать выполнение. Код, браузер и внешние данные лучше проверять в контролируемой среде.
• Требовать evidence. Решение должно быть связано с проверяемыми источниками, а не только с уверенным текстом модели.
• Оставлять human review там, где ошибка дорогая. Автоматизировать можно подготовку решения, а не обязательно финальное действие.

AI-агент — это процесс, а не один prompt

История Next.js хорошо показывает разницу между «спросить модель» и построить агентный workflow. Рабочая система включает окружение, инструменты, ограничения, историю действий, формат результата, очереди, проверки и понятный fallback.

Именно поэтому при AI-автоматизации бизнеса сначала стоит описать сам процесс: какие данные приходят, что можно делать автоматически, где нужен человек, как фиксировать ошибки и как повторять неуспешные шаги без дублей.

Когда подобный подход особенно полезен

Он подходит для задач, где много однотипных объектов, но по каждому требуется небольшое исследование: обращения клиентов, тикеты поддержки, карточки данных, проверки интеграций, технические инциденты или внутренние запросы команды.

Если процесс уже состоит из ручного поиска данных в нескольких системах и последующего решения по понятным правилам, его можно разобрать на этапы и оценить для автоматизации бизнес-процессов.

Вывод

Практическая ценность кейса Next.js не в том, что «ИИ закрыл тысячу задач». Сильнее другое: команда встроила агента в контролируемый workflow, ограничила его полномочия, заставила собирать доказательства и сохранила возможность проверки человеком.

Если у бизнеса есть похожая ручная цепочка из поиска, проверки и передачи данных, можно начать с небольшого безопасного этапа. Для оценки сценария можно посмотреть пример автоматизации заявок или описать процесс через контакты A.S Groups.

Официальный источник

• Next.js: How we closed 1,500 GitHub issues in one month