Проект без repository: Cursor Agent теперь может начать разработку с пустого места
Как intent превращается в работающий preview и Origin repo ещё до решения сохранить проект.

Сначала prompt, потом repository

27 августа 2026 года Cursor добавил для Cloud Agents режим Start from scratch. В repo picker можно выбрать пустой старт и сразу описать приложение. Cursor создаст временный Origin repository в фоне, агент соберёт проект, а результат можно открыть через live preview в браузере.

Если эксперимент стоит сохранить, кнопка Create repo превращает его в полноценный Origin repository: пользователь задаёт имя и visibility, после чего проект появляется в Codebase tab. Для web-приложения можно подключить Vercel и получить live URL.

Раньше

idea → create repo → scaffold → configure → agent

Теперь

idea → agent → running preview → save as repo

Экономия минуты на git init здесь почти неинтересна. Изменилась входная абстракция: пользователь приносит intent, а project workspace становится частью исполнения.

Repository стал видимым результатом работы

Технически Git никуда не исчез. Cursor всё равно создаёт Origin repo в фоне — агенту нужен persistent state для файлов и commits. Поэтому фраза «repository становится output» описывает пользовательский workflow, а не отказ платформы от source control.

Но этот сдвиг важен. До Start from scratch человек обязан был заранее решить, где живёт проект, создать его и подключить к Cloud Agents. Теперь repository может оставаться implementation detail до первого полезного результата:

USER SEES
intent → preview → keep or discard

PLATFORM MANAGES
temporary work state → Origin → environment

Так experiment не требует организационного commitment заранее. Сначала можно проверить идею, затем дать ей имя, visibility и постоянное место.

В существующем проекте половина решений уже принята

Обычный coding agent приходит в мир с framework, directory structure, database, tests и историей решений. Его свободу ограничивает codebase. Это полезное ограничение: прежде чем написать новый service, он может найти существующий pattern.

В пустом проекте исследовать нечего. Агент должен интерпретировать задачу и самостоятельно выбрать первый набор engineering решений:

intent
  ↓
scope and stack
  ↓
project scaffold
  ↓
data model
  ↓
first vertical slice
  ↓
run and preview

Это не обязательно более сложная работа по объёму. Но цена ранней ошибки выше: случайный выбор architecture размножится по всем следующим файлам. Greenfield проверяет judgment сильнее, чем способность найти нужный Controller.

Пустое место требует более жёстких границ

Prompt «сделай CRM» отдаёт модели слишком много взаимосвязанных решений: от auth и schema до frontend и deployment. Для disposable demo это допустимо. Для проекта, который команда собирается поддерживать, я бы задавал baseline сразу.

Создай MVP CRM для страхового брокера.

Stack:
PHP 8.4, Laravel 13, PostgreSQL, Blade + Tailwind.

Scope:
clients, deals, tasks, notes.

Constraints:
no microservices;
no SPA;
private access only;
fixtures and feature tests required.

First checkpoint:
working skeleton with live preview.

Человек здесь не занимается scaffolding, но остаётся владельцем границ. Агент получает свободу внутри явно выбранного stack и не расходует время на архитектурную импровизацию, которой никто не просил.

Что я бы проверил на Laravel-проекте

Возьмём небольшой внутренний сервис контроля ответа на лиды. Нужны Lead, ответственный, время первого ответа, SLA и список просроченных заявок. Хороший первый проход должен дать не россыпь моделей и migrations, а работающий vertical slice:

Laravel project
├── PostgreSQL connection
├── Lead model + migration
├── SLA calculation
├── dashboard route + Blade
├── representative fixtures
└── feature test for overdue leads

После preview я бы смотрел не на количество созданных файлов. Важнее четыре вопроса: можно ли воспроизвести setup, отделено ли SLA rule от view, покрыт ли основной сценарий test и не появился ли лишний architecture layer ради одного dashboard.

И только затем имеет смысл сохранить repository и продолжать feature work. Если первая версия уже прячет business rule в Blade или требует ручной настройки database, кнопка Create repo не делает её хорошим starter project.

Live preview проверяет продукт раньше кода

Cursor проксирует порт живого environment агента в browser. Для greenfield это важнее обычного diff viewer: на первой итерации нужно понять, ту ли систему вообще построили.

intent
  ↓
agent builds
  ↓
live preview
  ↓
"нужна воронка, а не таблица"
  ↓
agent rebuilds

Product correctness и implementation correctness проверяются разными объектами. Preview отвечает, соответствует ли behavior ожиданию. Code review — можно ли безопасно развивать реализацию. Ранний визуальный feedback уменьшает риск идеально написать не тот продукт.

Для backend-only проекта preview тоже может быть содержательным: OpenAPI contract, sample requests, test report или небольшой diagnostic UI. Главное — показать проверяемое поведение, а не просто сообщить, что создано 27 файлов.

Origin отделяет временную машину от постоянного проекта

Cloud environment нужен агенту для исполнения: поставить dependencies, запустить database, собрать приложение. Эта машина может завершиться вместе с run. Код должен пережить её.

Cloud Agent VM
      ↓
ephemeral execution

Origin repository
      ↓
persistent project state

В материале про Cursor Origin repository был state machine для branch, PR и review. Start from scratch добавляет ещё одну роль: Origin становится default persistence layer для software, созданного самим агентом.

Без собственного hosting workflow оборвался бы сообщением «теперь создайте GitHub repo и подключите его». С Origin платформа сама доводит experiment до durable project. GitHub или другой SCM больше не обязателен на входе, хотя для существующих команд внешняя интеграция никуда не исчезает.

Работающий preview ещё не production service

Самая опасная часть такого workflow — не плохая генерация. Это хороший prototype, который слишком легко принять за готовую систему. Login открывается, dashboard красивый, Vercel дал URL — значит, можно пользоваться. Через месяц выясняется, что никто не определил backup, authorization boundaries и owner.

Я бы разделял promotion явно:

START FROM SCRATCH
        ↓
EXPERIMENT
        ↓
product feedback
        ↓
CREATE REPO
        ↓
engineering hardening
        ↓
security + CI + ownership
        ↓
PRODUCTION

Кнопка Publish означает доступный deployment, а не production readiness. Для demo и внутреннего prototype короткий путь идеален. Для системы с персональными или платёжными данными он должен заканчиваться review gate, а не публичным URL.

Дешёвое создание переносит стоимость в поддержку

Когда новый application начинается с одного prompt, компания быстро получает десятки узких tools: CSV converter, report viewer, migration checker, dashboard для одной команды. Многие из них раньше не стоило создавать — fixed cost setup был выше пользы.

Это реальный экономический эффект agentic development: мы не только быстрее пишем прежний software, но и создаём то, что раньше не окупалось. Однако maintenance не становится бесплатным. У каждого micro-app остаются dependencies, данные, vulnerabilities и пользователи.

Поэтому policy должна появиться раньше sprawl:

• sandbox repositories можно создавать свободно;
• переход к общему использованию требует owner и README;
• production deployment требует CI, security review и monitoring;
• неактивные experiments получают срок жизни и архивируются.

Снижение creation cost повышает ценность inventory и decommissioning. Иначе через год самый загруженный agent будет не создавать проекты, а выяснять, какие из сотни repositories ещё нужны.

Skills превращают генератор demo в scaffolding layer

Без project conventions два запуска Start from scratch могут выбрать разные test stacks, logging и структуру. Для личного spike это терпимо. В команде variation быстро становится долгом.

Полезнее дать агенту company skill:

Company Laravel Service

PHP 8.4
Laravel 13
PostgreSQL
health endpoint
PHPUnit + PHPStan
structured logs
Docker environment
CI baseline
README with local setup

Тогда intent определяет предметную задачу, а Skill — инженерный минимум. В отличие от static template агент может адаптировать scaffold: не добавлять frontend в API worker или queue в синхронный internal tool. Но результат всё равно нужно валидировать, потому что dynamic template по определению менее детерминирован.

Август снял четыре prerequisites подряд

Start from scratch особенно понятен рядом с тремя предыдущими релизами Cursor:

Builds
ready computer
      ↓
Origin
persistent repository workflow
      ↓
Always-on Agents
goal + event-driven continuation
      ↓
Start from scratch
project no longer required as input

Builds дают готовый environment. Origin хранит результат. Always-on workflow продолжает работу после событий. Новый режим переносит агента ещё на шаг раньше — до первой строки существующего проекта.

Минимальный input постепенно сокращается с repository + environment + task до intent + constraints. Это не магия модели: недостающие части создаёт platform stack вокруг неё.

Новый benchmark — хочется ли сохранить этот repository

Для Start from scratch слабая проверка звучит так: «агент показал работающий dashboard». Сильная начинается после demo. Понятна ли architecture? Воспроизводится ли environment? Есть ли минимальные tests и документация? Можно ли добавить вторую feature без переписывания первого scaffold?

Главный вопрос релиза не «может ли Cursor создать проект без GitHub». Может — это уже функция интерфейса. Интереснее качество перехода:

intent
  ↓
working experiment
  ↓
maintainable repository
  ↓
continued engineering

Хороший greenfield agent создаёт не максимальное количество code, а минимальный проект, который честно решает задачу и оставляет понятный путь развития. Если такие результаты станут стабильными, repository действительно перестанет быть обязательной точкой старта.

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