GitHub и ИИ-агенты начинают конфликтовать уже не в теории, а на уровне базового workflow. По данным свежего академического датасета AIDev, исследователи уже насчитали 932 791 pull request, созданный пятью AI-агентами, а другая работа оценивает проникновение таких инструментов в 15,85–22,60% проектов. На этом фоне спор о том, как должен выглядеть GitHub и ИИ-агенты в одной цепочке разработки, перестал быть разговором про «фичи будущего» и стал вполне прикладной инженерной проблемой.
Именно об этом пишет The New Stack в материале о позициях Cursor, GitLab и Zed. У трех компаний общий диагноз: привычная модель GitHub, построенная вокруг коммитов, pull request и асинхронного ревью людьми, начинает буксовать, когда код массово производят и переписывают не только разработчики, но и агенты. Дальше консенсус заканчивается. Все трое согласны, что старая схема ломается, но предлагают лечить ее с разных концов стека.
Суть конфликта понятна любому тимлиду, который уже пробовал пускать в репозиторий не один Copilot, а несколько автономных помощников. Классический PR-процесс предполагает, что изменения приходят порциями, человек их читает, обсуждает, прогоняет CI и принимает решение. Агентная разработка работает иначе: изменений больше, они идут быстрее, их чаще нужно верифицировать автоматически, а не вычитывать построчно глазами. В такой модели GitHub и ИИ-агенты плохо уживаются в старом режиме не потому, что GitHub «плохой», а потому что он проектировался под людей, которые коммитят десятки изменений в день, а не под систему, где несколько агентов могут параллельно генерировать десятки веток, фиксов и попыток решения одной задачи.
Для Cursor это особенно чувствительная тема. Компания выросла на идее, что среда разработки должна быть не просто редактором с автодополнением, а рабочим местом для ИИ, который способен брать задачу целиком. Отсюда и логика: если агент пишет, правит, проверяет и повторяет цикл быстрее человека, то узким местом становится внешний контур согласования, в первую очередь GitHub как центральная точка обмена изменениями. В такой картине мира pull request превращается скорее в артефакт для фиксации результата, чем в основное место, где идет работа. Для разработчиков это означает неприятную, но честную мысль: привычный GitHub-ритуал может оказаться уже не «сердцем разработки», а формой упаковки того, что произошло раньше и в другом месте.
У GitLab взгляд более платформенный и, что неудивительно, более корпоративный. Для него проблема не только в скорости, но и в управляемости. Если в кодовую базу входят машины, нужно не просто ускорить создание патчей, а встроить в процесс политики, трассировку, безопасность, права доступа, аудит и понятный контроль над тем, кто именно сделал изменение: человек, агент или их гибрид. Иначе компания получает не productivity boost, а новый класс операционного риска. Для enterprise-заказчиков это, возможно, самый приземленный тезис во всей дискуссии. Бизнесу мало знать, что агент написал код быстрее. Ему нужно понимать, кто отвечает за дефект, как это прошло через комплаенс и можно ли повторить цепочку принятия решения в случае инцидента.
Zed смотрит на тот же кризис с позиции инструмента, который исторически делал ставку на скорость, локальность и совместную работу прямо в редакторе. Логика тут тоже читается без особого труда: если разработка становится более интерактивной и многопользовательской, то выносить каждое существенное взаимодействие в удаленный хостинг-контур уже не всегда рационально. Часть того, что раньше откладывали до PR, можно сдвинуть ближе к моменту написания кода: обсуждение, проверку, локальную синхронизацию, быстрый просмотр изменений. Для команд это важный сигнал. Следующая конкуренция в devtools может идти не вокруг того, у кого лучше чат сбоку, а вокруг того, где вообще теперь находится «истинное» место работы над кодом: в редакторе, в платформе DevSecOps или в репозитории.
Контекст у этой истории шире, чем спор трех вендоров. За последний год рынок быстро ушел от модели «ИИ подсказывает строку» к модели «ИИ берет задачу». Как только агент начинает создавать полноценные ветки и PR, немедленно всплывают старые боли GitHub в новом масштабе: шум в ревью, длинные очереди CI, конфликты веток, слабая различимость авторства и трудноуправляемая автоматизация. Исследования это подтверждают. В работах 2026 года про agentic pull requests отдельно фиксируются более крупные изменения, высокий объем неслитых PR и заметная доля конфликтов при интеграции. Иными словами, рынок спорит не о красивой метафоре, а о конкретной производственной поломке.
Для русскоязычной IT-аудитории тут есть три практических вывода. Первый: GitHub и ИИ-агенты уже нельзя рассматривать как простой апгрейд привычного девелоперского стека, это перестройка процесса. Второй: ценность будет смещаться от генерации кода к его верификации, приоритизации и управлению потоком изменений. Третий: компаниям придется решать, где они хотят держать центр тяжести разработки. Если в GitHub, то нужно усиливать автоматическое ревью, правила мержа и контроль над агентами. Если в IDE или платформе уровня GitLab, то придется переосмысливать роль PR и саму границу между написанием и принятием кода.
Самый интересный вопрос теперь не в том, сломается ли GitHub под напором агентной разработки, а в том, кто первым убедительно предложит замену его главной роли. Cursor, GitLab и Zed спорят не о косметике интерфейса, а о том, где будет находиться диспетчерская будущей разработки: в редакторе, в DevSecOps-платформе или все-таки в репозитории, которому придется срочно учиться жить рядом с машинами. Подробнее об этой дискуссии можно прочитать в .