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 під навантаження агентів — обидва шляхи все більше конкурують.

Автор статті, джерело: Leiphone

Власник репозиторію коду перетворюється з людини на агента.

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 зазнає змін, а набагато важливіше — forge control plane на основі 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 може стати контрольною точкою для агента, надаючи завданню здатність локальної перевірки, локального повторного спроби та відстеження залежностей.

Купівля Cursor компанії Graphite також може бути розуміна саме так. Поточна рання бета-версія Origin ще не повністю підтримує стекований робочий процес Graphite, але довгострокові вкладення Graphite у стековані PR та стеково-орієнтовані черги злиття точно відповідають наступним обмеженням, які виникають після збільшення швидкості генерації коду агентом.

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

Після того як A увійшов у main, результати тестування B можуть підтвердити працездатність коду лише у старому стані, але не можуть гарантувати безпеку після переходу до нового main. Тому queue потрібно перебудовувати кандидатські стани з урахуванням змін у main, повторно виконувати перевірки та обробляти залежності між PR.

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

огляд також структуруватиметься. Людська співпраця в значній мірі залежить від природної мови та досвіду команди, а тривалий час роботи агента вимагає чіткого визначення, який перевірка не пройшла, які потоки ще не вирішені, яка політика не виконана, і який поточний SHA голови.

Origin вже експонує через API об’єкти repository, commit, checks, PR та розрізняє формальний огляд та звичайну дискусію.

Ці структуровані стани можна безпосередньо споживати за допомогою 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, і це також пояснює: після генерації коду потрібна система, яка довгостроково зберігає стан проекту, координує зміни, перевіряє результати та з’єднує подальші виконання. Якщо ця позиція завжди розташована ззовні, у виробничому ланцюжку агентського програмного забезпечення існує критична залежність.

А Origin заповнює саме цей рівень.

04 Розбіжності між GitHub та Origin

GitHub вже має стековані PR, чергу злиття, REST API, і продовжує інтегрувати Copilot coding agent у Issue, Actions, PR та код-рев’ю. Якщо дивитися лише на список функцій, майбутнє обох платформ буде все більше перетинатися.

Різниця в основному походить із передумов дизайну.

GitHub побудований на досвідченій мережі розробників, тому більш природним шляхом є інтеграція Agent у існуючі системи Issue, PR, Actions та захисту гілок.

Cursor може переробити ці компоненти за допомогою інтенсивної співпраці агентів. Якщо в репозиторії довготривало працюють десятки агентів, кількість PR зростає, гранулярність змін зменшується, а стан швидко змінюється, то системи огляду, перевірок, злиття та прав доступу потрібно перебудувати навколо поведінки машин.

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

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

Відповідно, показники Agent-native forge також зміняться. 22.6 commit/s дуже помітно, але сама кількість комітів не може відображати ефективність виробництва програмного забезпечення. Більш значущими показниками будуть час від входу завдання в систему до merge, здатність до локального відновлення після невдачі, частка змін, автоматично виконаних policy, обчислювальні витрати на accepted change, а також людська увага, витрачена на високоризиковани зміни.

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

Конкуренція між GitHub та Origin поступово зосередиться на двох шляхах: GitHub розширюється від зрілої системи людської співпраці до агентів, тоді як Cursor намагається перепроектувати forge з урахуванням навантаження агентів.

05 Старий Мар вже на наступному рівні

Якщо подивитися на це з іншого боку, після випуску Grok 4.6 зовнішній світ легко продовжує обговорювати кодові здібності, оцінки міркувань і ціну за benchmark. Але якщо розглянути Colossus, Grok, Cursor і Origin разом, стає зрозуміло, що ця стратегія вже розширюється на програмний виробничий ланцюг після моделей.

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

Отже, місце Grok 4.6 на цьому списку сьогодні може бути лише тимчасовим результатом. Більш тривалим питанням є те, хто зможе організувати модель, середовище виконання та стан програмної інженерії в єдину безперервно працюючу виробничу систему.

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