17 августа на GitHub произошел массовый сбой сервиса, в тот же день Cursor открыл раннюю бета-версию Origin для платных пользователей. Репозитории сейчас подключаются к постоянно работающим агентам, существующая инфраструктура сотрудничества адаптирована под ритм работы человека. Исследования показывают, что 40,2% репозиториев имеют перекрывающиеся PR агентов, а процент конфликтов слияния достигает 41,7%. Cursor Origin разработан для частых записей агентов, поддерживает 22,6 коммитов в секунду на один репозиторий, интегрируя репозитории, PR, проверки и обзоры. Origin позиционируется как уровень управления над Git, перерабатывающий процессы частого сотрудничества агентов. Компании Илона Маска — xAI, X, SpaceX и Cursor — уже сформировали полную цепочку AI-производства: Colossus обеспечивает вычислительные мощности, Grok предоставляет модели, Cursor выполняет код, а Origin управляет состоянием инженерных процессов. GitHub расширяется от человеческого сотрудничества к агентам, Cursor перерабатывает forge под нагрузку агентов — эти два подхода всё более активно конкурируют.

Автор статьи, источник: LeFeng.com

Владелец репозитория постепенно превращается из человека в агента.

17 августа на GitHub произошел массовый сбой сервиса. Основные компоненты — веб-интерфейс, API, Actions, запросы на слияние, операции с Git и вебхуки — поочередно испытали проблемы; в некоторые периоды уровень ошибок веб-запросов и API приближался к 20%.

В тот же день Cursor постепенно открыл Origin early beta для всех платных тарифов. Репозитории, PR, проверки, обзоры, слияния и автоматизации были объединены в единую систему, и позиционирование Cursor было четким: хостинг кода начинает проектироваться под «agent scale».

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

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

Многие новые проблемы, с которыми сталкивается GitHub, и многие проблемы, которые Origin хочет решить, возможно, начнутся здесь.

01 GitHub не стал внезапно старше

В момент появления GitHub основной единицей сотрудничества в разработке программного обеспечения был человек.

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

Ориентируясь на этот ритм, GitHub создал системы Pull Request, Issue, Review, Actions, Webhook и прав доступа. Даже в таких проектах, как Linux Kernel, которые долгое время поддерживают высокий объем коммитов, этот ритм сохраняет явные черты человеческого временного масштаба.

LWN сообщает, что за весь цикл разработки Linux 7.0 было сделано 14251 несливаемый коммит от 2362 разработчиков. Эти коммиты были выполнены в течение нескольких недель, включая обсуждения по электронной почте, проверку сопровождающими, интеграцию подсистем и цикл релизов.

Cursor продемонстрировал другой тип нагрузки в демонстрации Origin, опубликованной в июне: 22,6 коммита/с в одном репозитории.

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

У человеческих разработчиков естественно ограничена пропускная способность. Размышление, написание кода, собрания и отдых создают значительные промежутки времени между коммитами, поэтому forge, спроектированный вокруг человека, может передать часть нагрузки на систему времени.

Агент не имеет этого ограничения.

Десятки агентов могут одновременно форкнуться от одного базового SHA, в близкое время изменить связанные файлы, затем совместно запушить, создать PR, запустить проверки, прочитать отзывы, изменить код и снова запушить. Один коммит может продолжать вызывать обновление индекса, проверку прав, вебхуки, CI, сканирование кода, обновление статуса отзыва и расчет возможности слияния.

Следовательно, не сама модель объектов Git должна выдерживать изменения, а скорее платформа управления на основе Git: API, аутентификация, фоновые задачи, планирование CI, вебхуки, защита веток, состояние обзора, очередь слияния и каскадная нагрузка между этими компонентами.

Исследование Agent PR на GitHub, опубликованное в июле, уже зафиксировало такую параллельную форму. В исследовании проанализировано 33 596 Agent PR из 2 807 репозиториев, и в 40,2% репозиториев наблюдались перекрывающиеся по времени Agent PR.

При параллельных изменениях с повторным воспроизведением выборки процент текстовых конфликтов слияния между PR агентов составил 41,7%, а между параллельными PR, созданными одним и тем же агентом, — 19,8%.

Совместная работа нескольких агентов приводит к новым проблемам управления параллелизмом. Сбой на GitHub не доказывает, что трафик агентов превысил существующую инфраструктуру, но он предоставил наблюдательное окно: когда производство программного обеспечения переходит от редких человеческих событий к частым машинным событиям, планирование емкости, проектирование очередей, распространение состояний и модели согласованности сталкиваются с другим типом рабочей нагрузки.

Дизайн Origin также начинается здесь.

02 Origin переопределение стоимости сотрудничества

Если Origin просто добавит вход для хостинга репозитория Git, ему будет сложно изменить уже сформированные GitHub отношения с разработчиками, экосистему с открытым исходным кодом, системы прав предприятий и инструментальные цепочки.

Его возможность возникает из-за того, что агент изменил стоимость сотрудничества. Stacked PR — это типичный пример.

Человеки-разработчики обычно предпочитают объединять функциональность в относительно полные PR. Каждое разделение на отдельный PR добавляет дополнительный контекст, цикл проверки и набор зависимостей веток. Если одно изменение разбивается на десятки PR, люди легко тратят огромное количество усилий на поддержание этих связей.

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

Небольшой PR может таким образом стать контрольной точкой агента, обеспечивая локальную проверку, локальную повторную попытку и отслеживание зависимостей.

Приобретение Graphite Cursor также можно понять в этом контексте. Текущая ранняя бета-версия Origin еще не полностью реализует стековую рабочую процедуру Graphite, но долгосрочные инвестиции Graphite в стековые PR и стеково-ориентированные очереди слияния идеально соответствуют последующим узким местам, возникающим после увеличения скорости генерации кода агентом.

После увеличения количества PR обязанности очереди слияния также возрастут. Агент A и агент B могут одновременно работать из одного и того же базового SHA, и оба проходят тестирование.

После перехода A в main тестовые результаты B могут подтвердить работоспособность кода только в старом состоянии, но не гарантируют безопасность после перехода в новый main. Следовательно, очередь должна перестраивать кандидатские состояния на основе постоянно изменяющегося main, повторно выполнять проверки и обрабатывать зависимости между PR.

Конфликты также могут постепенно превращаться из ручного прерывания в восстанавливаемое состояние сбоя в конвейере. Cursor уже предоставляет возможность /babysit, которая постоянно обрабатывает обратную связь по PR, неудачные проверки и конфликты. После возникновения проблем с кандидатом на слияние соответствующий контекст может быть снова передан агенту для исправления и повторной проверки в изолированной среде.

обзор также структурируется. Человеческое взаимодействие в значительной степени зависит от естественного языка и опыта команды, тогда как длительная работа агента требует четкого определения, какой проверки не прошли, какие потоки еще не решены, какая политика не выполнена и какой текущий head SHA.

Origin уже предоставляет через API объекты репозитория, коммитов, проверок, запросов на слияние и различает формальные отзывы и обычные обсуждения.

Эти структурированные состояния затем могут быть напрямую использованы Automations. Триггеры push, PR opened или PR pushed запускают cloud agent, результат выполнения записывается обратно в checks и PR, при неудаче процесс переходит в обработку. MCP, hooks и Agent API позволяют внешним инструментам присоединиться к этой же цепочке событий.

“Отключить от GitHub” решает путь миграции. Команда может сначала создать зеркало репозитория GitHub, оставив GitHub в качестве источника истины, одновременно перенеся рабочие процессы Agent на Origin; после стабильной работы можно отключить синхронизацию, передав управление репозиторием исключительно Origin.

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

Логика продукта Origin поэтому ясна: Git продолжает отвечать за контроль версий, а Origin стремится пересоздать уровень управления, который работает вокруг частых агентов на верхнем уровне Git.

03 ЛаМа объединяет цепочку производства ИИ

За последние более чем год ряд действий между xAI, X, SpaceX и Cursor постепенно сформировал более полные связи между верхними и нижними звеньями.

xAI приобретает X, после чего входит в систему SpaceX; Cursor получает вычислительные ресурсы Colossus и также входит в систему SpaceX. В то же время выпускается Grok 4.6, и Origin начинает открываться.

Этот подход схож с вертикальной интеграцией, которую Маск ранее применял в Tesla: когда внешние этапы начинают создавать трение при итерациях, компания продолжает расширяться вверх и вниз по цепочке, включая ключевые интерфейсы в единую систему.

Агент сейчас сталкивается именно с такой проблемой. Модель может выполнить рассуждение, но для выполнения программной задачи необходимо получить доступ к репозиторию, изменить файлы, запустить тесты, обработать CI, получить отзыв, устранить конфликты и восстановить выполнение при сбое.

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

Colossus, Grok, Cursor и Origin могут соответствовать различным уровням этой цепочки: Colossus предоставляет вычислительную мощность, Grok предоставляет модельные возможности, Cursor предоставляет код-агент и среду выполнения, Origin сохраняет репозитории, PR, статусы проверок и обзоров.

Код генерируется, образуя непрерывную цепочку: модель принимает решение, Cursor преобразует это решение в реальные изменения, а Origin сохраняет состояние проекта и управляет последующей совместной работой.

Это также изменило критерии оценки Grok 4.6. Способности модели по-прежнему важны, но результаты агентной системы зависят от среды выполнения и инженерной инфраструктуры. Даже если код сгенерирован качественно, если после этого требуется ручное копирование, выполнение, проверка и повторная отправка, способности модели сложно постоянно масштабировать.

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

Позиция X в этой цепочке пока остается нечеткой. Он обладает контентом в реальном времени, пользовательскими связями, идентичностью и сетью распространения, и в будущем может стать источником задач и точкой входа для их распределения; на текущем этапе Grok Bot по своей продуктовой форме ближе к уровню постоянного выполнения задач, а не просто к «пассивному ожиданию вопросов чистому чат-боту», как многие представляют.

Почему Cursor нужен Origin, и это также объясняет: после генерации кода требуется система, которая будет длительное время сохранять состояние проекта, координировать изменения, проверять результаты и связывать последующие выполнения. Если это место всегда находится вне системы, в производственной цепочке программного обеспечения Agent возникает критическая зависимость.

А Origin заполняет именно этот слой.

04 Разногласия между GitHub и Origin

GitHub уже имеет стекированные PR, очередь слияний, REST API, и продолжает интегрировать агента Copilot для кодирования в Issues, Actions, PR и код-ревью. Если смотреть только на список функций, в будущем между ними будет все больше пересечений.

Различия в основном обусловлены исходными предпосылками проектирования.

GitHub построен на основе зрелой сети человеческих разработчиков, поэтому более естественным путем является интеграция Agent в существующие системы Issue, PR, Actions и защиты веток.

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

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

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

Соответственно, показатели Agent-native forge также изменятся. 22,6 commit/s выглядит впечатляюще, но само количество коммитов не может служить показателем производительности программного обеспечения. Более значимыми показателями будут время от поступления задачи в систему до слияния, способность к локальному восстановлению после сбоев, доля изменений, автоматически завершенных в рамках policy, вычислительная стоимость принятых изменений и объем человеческого внимания, затрачиваемого на высокорисковые изменения.

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

Конкуренция между GitHub и Origin постепенно развернется по двум направлениям: GitHub будет расширяться от зрелой системы человеческого сотрудничества к агентам, а Cursor попытается перепроектировать forge с учетом рабочей нагрузки агентов.

05 Старый Ма уже на следующем уровне

Кстати, после выпуска Grok 4.6 внешнему миру легко продолжать обсуждать кодовые возможности, баллы рассуждения и цену на основе тестов. Но если посмотреть на Colossus, Grok, Cursor и Origin вместе, становится ясно, что эта стратегия уже простирается на программную производственную цепочку после модели.

Colossus предоставляет вычислительные мощности, Grok отвечает за вывод, Cursor превращает возможности модели в изменения кода, а Origin принимает последующее состояние репозитория, PR, проверки и обзоры. После повышения возможностей модели выгода может напрямую передаваться вдоль цепочки выполнения; даже если отдельные поколения моделей не демонстрируют явного преимущества, последующая инфраструктура продолжает накапливать преимущества.

Таким образом, позиция Grok 4.6 сегодня в каком-либо рейтинге может быть лишь временным результатом. Более долгосрочный вопрос заключается в том, кто сможет организовать модель, среду выполнения и состояние программной инженерии в единую постоянно функционирующую производственную систему.

Пока все спорят, какая модель в этом цикле умнее, Маск уже перешел на следующий уровень.