Google влил в Anthropic сорок миллиардов, Cursor "собрали" браузер на GPT-5.2, а я начал писать код совместно с заказчиком.

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

А что если показать заказчику как работать с Cursor и использовать ИИ-агентов?

Есть клиент. Он предприниматель и у него бизнес в недвижимости, при этом он не программист, - он не пишет backend, не проектирует схемы БД, но он очень хорошо знает своё дело и это важнее, чем кажется.

На старте клиент не был человеком из серии "хочу приложение, но не знаю какое" - он уже прошёл классический флоу разработки с командой разработчиков, который не дал желаемого результата. Затем пробовал nocode и ИИ инструменты для написания приложения с нуля. Они дают быстрые прототипы и классный старт, позволяют CEO очень быстро проверить гипотезу, почувствовать интерфейс руками. Но у них есть потолок, в какой-то момент появляются вопросы, которые уже не решаются перетаскиванием блоков - здесь и должна появиться инженерная составляющая, инженерное сопровождение.

Как правило в разрааботке бизнес софта есть классический разрыв. Заказчик знает как всё работает в реальности, а разработчик знает, как это положить в код. Между ними живут созвоны, документы, скриншоты, "а я имел в виду не это", "а вот у нас в сезон бывает иначе"... Если проект маленький, это терпимо, но в процессе масштабирования и усложнения всё начинает сыпаться.

Первый слой эксперимента не код, а среда

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

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

Технически, но упрощенно. Я сделал одну связанную конструкцию: на VDS (виртуальный выделенный сервер) живёт общий каталог проекта, Cursor открывает его через Remote SSH, каждый участник входит под своим Linux ползователем, а код, документация, задачи и сопутствующие материалы оказываются в одном рабочем пространстве, где порядок держит не "давайте все будем аккуратно", а связка прав ограниченных ОС, групп и ACL, разграничение доступа в GitHub и обычный цикл веток с pull request.

SSH: сначала надо договориться, где вообще живёт разработка

Если мы хотим, чтобы все участники работали в одном контексте, то локальная папка на моём компьютере плохо подходит на роль центра системы. Поэтому базовая идея такая. Есть удалённый сервер, на нём лежит рабочее пространство проекта, а Cursor подключается к этому серверу через Remote SSH (MCP). Для пользователя это выглядит почти как обычная работа в IDE - открыл Cursor, подключился к серверу, видишь файлы, терминал, git, документацию, задачи. Но фактически код и окружение находятся не на локальной машине, а на VDS.

Здесь есть важный организационный момент. Cursor как продукт живёт на стороне пользователя: у каждого есть приложение, аккаунт, настройки, модели, доступ к агентам. В нашем случае со стороны клиента используется один корпоративный (PRO+) Cursor аккаунт для него и членов его команды. Технически это удобно, можно подключаться с разных устройств и давать людям единый вход в инструмент. При этом такую схему нужно отдельно сверять с условиями тарифа и политикой аккаунтов Cursor, потому что "технически можно" и "правильно по лицензии" не всегда одно и то же.

Со стороны разработки подход другой - у каждого специалиста свой аккаунт Cursor и свои привычные настройки - они подключаются к проекту уже как профессиональные участники разработки, а не как пользователи корпоративного аккаунта заказчика. Что так же верно с точки зрения оплаты токенов.

На этом этапе важно разделить две сущности, которые легко смешать:

- аккаунт Cursor отвечает за доступ к IDE, моделям, агентам и пользовательским настройкам;

- Linux-пользователь на сервере отвечает за доступ к файлам, терминалу, процессам и правам внутри удалённой среды.

То есть человек может открыть один и тот же проект в Cursor, но на сервер он должен заходить под своим пользователем. Это не бюрократия, а основа безопасности и нормальной диагностики. Если все сидят под одним "dev" пользователем, потом невозможно понять, кто создал файл, кто сломал права, какой агент внезапно переписал не тот кусок проекта. И на этом этапе повествования появляется первая серьёзная проблема.

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

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

## Linux пользователи и ACL. Порядок должен держаться не на обещаниях

Следующий слой это обычная, скучная и очень полезная Linux механика. Каждый участник получает отдельного пользователя на сервере. Один человек один Linux пользователь. Новый участник проекта есть новый пользователь.

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

Для такого сценария удобно использовать группы и ACL. Группы дают грубую модель, к примеру, - кто относится к разработчикам, кто к заказчику, кто может работать с docker, кто имеет доступ к runtime каталогам. ACL дают более точную настройку. Конкретному пользователю можно читать весь проект, но писать только в свою директорию, этой группе можно писать в workspace, а этому пользователю можно только запускать деплой, но нельзя редактировать ".env" и compose файлы. В нашем опыте отдельная важная идея означала что сотрудникам можно давать право редактировать свои рабочие директории, а чужие материалы только читать. Это частично решает конфликт между двумя потребностями.

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

Но тут появляется следующая проблема. Даже если права настроены, людям и ИИ всё равно нужно где-то жить в общем контексте проекта. Нужна структура, в которой понятно, где код, где документы, где инструкции, где правила для агентов, где личные и общие задачи. Иначе у нас будет просто сервер с папками, а не рабочая среда. И так рождается необходимость организации workspace.

Workspace не просто папка, а общий контекст проекта

Слово workspace легко недооценить. Кажется, что это просто "папка, которую открыли в Cursor". Но в данном эксперименте workspace становится гораздо более важной сущностью. В нашем проекте workspace это общий контекст, в котором живут

- команды, скилы и агенты Cursor

- репозитории приложения

- архитектурные документы

- материалы встреч

- инструкции и правила для ИИ

- директории задач

- черновики решений

- артефакты ревью и т.д.

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

В Cursor это особенно интересно, потому что часть поведения ИИ можно задавать на уровне workspace. В проекте могут лежать общие правила, команды, skills, subagents и инструкции, которые будут действовать для всех участников, открывающих этот workspace. Это уже похоже не просто на "репозиторий с кодом", а на проектную операционную систему.

Подробней.

- правила проекта объясняют агентам архитектуру, стиль, ограничения и процесс

- команды позволяют запускать повторяемые сценарии, например работу над задачей

- skills описывают специализированные навыки или регламенты

- subagents могут брать на себя отдельные роли: git, код, ревью, тесты, деплой

- task-директории хранят описание задачи, план, результат и транскрипты

В целом cursor предоставляет два уровня таких настроек. Первый это уровень workspace, функции которого описаны выше. Второй - уровень пользователя. У конкретного человека могут быть свои локальные настройки Cursor, свои привычки, предпочтения, команды или расширения. Они работают на его устройстве и не обязаны становиться общими правилами проекта. Это разделение важно. Общими должны быть инварианты процесса, а личными удобства конкретного участника. Например, правило "не работаем прямо в 'dev' ветке backend репозитория" должно быть общим. А цветовая тема, локальные хоткеи или личный способ вести заметки — это уже уровень пользователя.

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

Но workspace не решает всё, в подобной схеме есть физическое ограничение. Если два человека одновременно редактируют одни и те же файлы на сервере, они будут мешать друг другу. Это не Figma, где несколько курсоров двигаются по макету. Кодовая база и markdown документы в общем каталоге не становятся автоматически удобной real-time collaborative средой.

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

И да, конечно. Самый верное решение этой проблемы GitHub.

GitHub: общий workspace не заменяет ветки

На первый взгляд может показаться: если у нас уже есть общий сервер и общий workspace, зачем ещё усложнять жизнь GitHub ветками? Ответ простой. Общий workspace решает проблему контекста, но не решает проблему параллельной разработки.

GitHub здесь возвращает нормальную инженерную модель в новом прочтении:

- под задачу создаётся отдельная ветка

- изменения живут изолированно

- результат оформляется как pull request

- CI и ревью проверяют, что это можно влить

- 'dev' остаётся интеграционной веткой, а не песочницей для всех подряд

В такой модели участники могут работать по-разному.

Например, заказчик или сотрудник заказчика работает на удалённом сервере через Cursor, потому что ему важен общий контекст, инструкции, task-директории и возможность быстро поднять preview контур. А backend- или frontend-разработчик может спокойно работать локально у себя - склонировать репозиторий, отвести ветку, сделать изменения в привычном окружении, открыть PR.

Это особенно важно, когда пересекаются зоны ответственности. Если заказчик через ИИ делает небольшую задачу в интерфейсе, а frontend разработчик параллельно перестраивает компоненты, им лучше не работать в одном и том же рабочем дереве. Один может использовать удалённый workspace как среду задачи и проверки, другой — локальную ветку и свой dev setup. GitHub потом сведёт изменения через pull request, diff, ревью и конфликты, если они есть.

По сути, получается такая модель:

- workspace нужен для общего контекста и работы ИИ

- Linux-права нужны, чтобы люди и агенты не лезли куда не надо

- GitHub нужен, чтобы параллельные изменения не превращались в драку за файлы

- PR нужен, чтобы инженерное ревью оставалосьь обязательным слоем перед интеграцией

И вот здесь мы возвращаемся к клиенту.

Даже если у него есть Cursor, доступ к workspace и ИИ агент, этого всё ещё недостаточно. Ему нужен понятный сценарий для работы в сессии с ИИ агентом. Как начинать задачу, что спросить у агента, как заставить агента сначала составить план, где хранить результат, как не работать в 'dev', что делать с pull request. Иначе вся конструкция опять скатится в хаос, только теперь уже более технологичный.

Поэтому следующим шагом стала инструкция для работы заказчика с ИИ агентом. Не просто промт "сделай задачу", а полноценный регламент: от проверки git состояния и создания ветки до плана, реализации, тестов, preview и PR.

Об этом будет мой следующий пост. Cпойлер, cуществует далеко не единственный способ обеспечить подобный флоу для работы агента. На данный момент я эксперимнтирую с subagents и skills в Cursor.