Cursor теперь хранит код
17 августа 2026 года Cursor начал rollout Origin Code Hosting. Early beta получила базовый набор функций Git-платформы: собственные repositories, browsing и search по коду, pull requests, review, merge и синхронизацию с GitHub. Со страницы repository можно вызвать агента, попросить его объяснить код, внести изменения, обновить PR или отправить branch.
Для обычного редактора это странное расширение. IDE исторически заканчивается на локальном checkout:
IDE
↓
Git
↓
GitHub / GitLab
↓
PR → CI → review → mergeНо Cursor уже строит не обычный редактор. Cloud Agent живёт дольше локальной session, создаёт branch, запускает tests и возвращается к работе после feedback. Для него hosting — часть runtime, а не внешний сайт, куда человек однажды нажал git push.
Repository стал state machine задачи
Задача «исправить duplicate webhook и подготовить PR» не заканчивается зелёным PHPUnit. После push появляются новые состояния:
OPEN
↓
CI FAILED
↓
NEW COMMIT
↓
CHANGES REQUESTED
↓
APPROVED
↓
MERGEDКаждый переход может потребовать следующего действия агента. Прочитать failure, воспроизвести его в cloud environment, исправить код, ответить reviewer и снова отправить commit. Git hosting в таком workflow хранит уже не просто source code. Он хранит состояние исполнения.
Для человека переключение между IDE, browser и CI давно стало мышечной памятью. Agent platform платит за эту границу API-вызовами, permissions, webhooks и синхронизацией нескольких версий state. Origin уменьшает количество таких переходов внутри Cursor.
Что именно доступно в первой beta
У Origin есть два режима. Новый repository можно создать непосредственно в Codebase tab и работать с ним через стандартный Git или отдельный Origin CLI. В этом случае Cursor является hosting layer и source of truth.
Существующий GitHub repository можно подключить как синхронизируемую копию. Cursor прямо фиксирует границу: для проекта, начатого на GitHub, GitHub остаётся source of truth, а push продолжает идти туда. Origin обновляет зеркало в реальном времени и даёт browsing, search и pull.
Pull requests синхронизируются в обе стороны. Comment из Cursor появляется на GitHub, ответ или reaction с GitHub возвращается в Cursor. В самом Origin PR показывает timeline, commits, checks и changed files; там же можно провести review и merge.
Почему одной GitHub-интеграции Cursor мало
GitHub API уже позволяет создать branch, открыть PR и прочитать checks. Технически agent loop можно собрать поверх него — Cursor так и работал до Origin.
Разница появляется в co-design. GitHub проектировался вокруг разработчика, который вручную создаёт branch, открывает PR и отвечает на review. AI-функции добавляются к зрелой человеческой модели. Cursor может исходить из другой нагрузки:
10 agents
├── 10 isolated branches
├── 10 concurrent PRs
├── repeated CI iterations
└── human review at checkpointsКогда runtime агента, code browser и PR принадлежат одной платформе, интерфейс можно оптимизировать под машинную активность: быстрее передавать repository context, связывать действия с PR и показывать человеку результат на уровне задачи. Не требуется притворяться, что каждый worker — человек, который сидит перед вкладкой browser.
Origin пока не реализует все возможные agent-native сценарии — в анонсе Cursor отдельно говорит, что такие функции будут появляться позже. Но собственный forge снимает архитектурное ограничение: теперь их не нужно встраивать только через чужую модель данных.
PR становится долговечным checkpoint
Conversation агента может закончиться, VM — остановиться, локальный context — исчезнуть. Pull request продолжает хранить diff, commits, checks и feedback. Новый worker или человек может восстановить состояние задачи без полного execution trace.
Поэтому PR в agent workflow выполняет сразу несколько практических функций:
artifact diff и commits
checkpoint проверяемое состояние
channel comments и review
status checks и mergeability
handoff agent ↔ human ↔ agentЯ не называл бы PR полноценной памятью агента: там нет всех hypotheses и неудачных поисков. И хорошо. Reviewer обычно нужен сжатый engineering result, а не сотни tool calls. PR сохраняет ровно тот уровень состояния, на котором удобно принять решение.
Builds отвечают «где», Origin — «с чем»
В предыдущем материале о Cursor Builds development environment стал заранее подготовленным компьютером агента. Origin добавляет постоянный объект работы:
Build
↓
ready execution environment
Origin
↓
repository + branch + PR stateОтдельная VM решает isolation. Build убирает повторный setup. Repository переживает конкретную машину, а PR удерживает workflow после завершения session. Эти слои полезны именно вместе.
У Cloud Subagents каждая branch была результатом изолированного worker. Native hosting превращает такие branches в управляемый fleet: их можно просматривать, сравнивать, отправлять на review и закрывать, не покидая общий agent workspace.
Как это выглядит на Symfony-задаче
Допустим, нужно добавить отзыв всех API tokens пользователя. Cloud Agent получает issue, стартует из готового Build, находит authenticator и token service, меняет код, запускает PHPUnit и PHPStan.
Дальше начинается repository loop:
Agent branch
↓
Origin PR
↓
SecurityTest failed
↓
Agent reproduces in its VM
↓
fix + PHPUnit + PHPStan
↓
new commit
↓
human reviewВ этой схеме разработчик не работает почтовым голубем между CI и editor. Он приходит к содержательному checkpoint: поведение реализовано, проверки приложены, diff готов к оценке.
Origin уже соединяет agents с repository и PR, а Vercel, Depot и Buildkite доступны как apps для Origin repos. Это не означает, что любой failed check автоматически запустит нужного worker. Такая automation требует отдельно определить trigger, ответственность и permissions. Но все основные объекты теперь находятся рядом.
Следующая ценность — provenance, а не ещё один diff viewer
Текущий PR показывает timeline, commits, checks и files changed. Для AI-generated change этого уже мало: reviewer хочет знать, что запускалось, в какой среде и какие риски agent оставил нерешёнными.
Native stack создаёт место, где эти данные можно связать:
Task
↓
Agent run
↓
Environment Build
↓
Commit
↓
Pull Request
↓
Checks + reviewЭто пока архитектурное следствие, а не обещанный формат Origin PR. Но именно такой provenance снижает стоимость асинхронной работы. Утром нужно понять не «что модель думала три часа», а на каком commit она работала, какие проверки выполнила и где требуется человеческое решение.
Hosting становится policy layer
Agent, который умеет push и merge, нуждается в тех же ограничениях, что service account. Origin settings уже разделяют repository access, visibility и rules/protections. Для практического проекта я бы начал с узкой политики:
ALLOW
read repository
create feature branch
push commits
open and update PR
REQUIRE HUMAN
merge protected branch
change repository settings
production deploymentАвтономность не требует полного доступа. Наоборот, branch и PR удобны тем, что дают агенту широкую свободу внутри обратимой области, а protected branch оставляют точкой ответственности человека.
Цена вертикального stack — lock-in
Если editor, agents, environments, repositories и review принадлежат одному продукту, switching cost растёт. Сменить IDE легко, пока source of truth и governance остаются на GitHub или GitLab. Перенос всего workflow сложнее.
Поэтому GitHub sync — не второстепенная функция beta, а страховка стратегии. Команда может оставить GitHub источником правды, проверить Origin на одном agent-heavy workflow и отключить зеркало, если преимущество не окупает новый platform dependency.
Для greenfield-проекта баланс может быть другим: создать repository прямо рядом с Cloud Agents проще, чем собирать интеграции по отдельности. Но enterprise-команде я бы сначала проверил permissions, export path, CI coverage и поведение при недоступности Cursor. Source code — слишком центральный asset для решения на основании одного удобного demo.
Редактор становится интерфейсом development platform
Origin нужен Cursor не ради ещё одного места для хранения Git objects. Он расширяет agent loop от изменения файлов до branch, PR, checks, review и merge. Repository становится shared state, а pull request — понятной границей между автономной работой и человеческой ответственностью.
После этого слово IDE описывает только одну поверхность продукта:
Cursor
├── editor
├── agent harness
├── cloud environments
├── repositories
├── pull requests
└── reviewГлавный тест Origin будет не в том, насколько приятно просматривать code browser. Он будет в другом: сокращает ли native repository workflow число ручных handoff, даёт ли reviewer достаточно evidence и удерживает ли agent внутри понятных policy boundaries.
Если ответ окажется положительным, Cursor конкурирует уже не только с редакторами. Он собирает AI-native development platform, где computer, code и состояние инженерной задачи принадлежат одному execution loop. Следующее давление на такую архитектуру очевидно: repository уже генерирует events — осталось научиться безопасно превращать их в работу без нового ручного prompt.
