Предприниматель из сферы управления недвижимостью уже прошёл классический путь: команда разработчиков, no-code инструменты, ИИ-конструкторы приложений. Каждый этап давал что-то полезное, но упирался в потолок. No-code позволяет быстро проверить гипотезу и «потрогать» интерфейс руками, однако в какой-то момент перетаскивание блоков перестаёт решать задачи — нужна инженерная составляющая. Разработчик предложил нестандартный выход: не просто взять задачи от заказчика, а ввести его в общую среду разработки.
Техническая основа эксперимента — виртуальный выделенный сервер (VDS), на котором хранится весь рабочий каталог проекта. Cursor подключается к нему через Remote SSH: пользователь видит файлы, терминал, git и документацию так, будто работает локально, хотя код и окружение физически находятся на удалённой машине. Каждый участник — заказчик, члены его команды, разработчики — заходит на сервер под отдельным Linux-пользователем. Это не формальность: если все сидят под одним системным пользователем, невозможно понять, кто создал файл, кто изменил права и какой агент переписал не тот фрагмент проекта.
Отдельный вопрос — аккаунты Cursor. Со стороны заказчика используется один корпоративный PRO+ аккаунт, к которому подключаются он и его сотрудники с разных устройств. Разработчики работают каждый под своим личным аккаунтом — это удобно и с точки зрения настроек, и с точки зрения оплаты токенов. Здесь важно не смешивать две сущности: аккаунт Cursor отвечает за доступ к IDE, моделям и агентам, а Linux-пользователь на сервере — за доступ к файлам и процессам внутри удалённой среды.
Разграничение доступа строится не в Cursor, а на уровне ОС — через группы и ACL, что защищает от случайных правок агентов.
Главная техническая проблема возникает из природы современных ИИ-агентов. Cursor — не просто редактор: агент умеет читать проект, менять файлы, запускать команды и создавать новые артефакты. Когда к одному workspace подключены несколько человек, каждый из которых может попросить агента «поправь вот это», риск случайных изменений в чужих файлах становится реальным. SSH открывает дверь, но не решает вопрос — куда именно можно заходить и что трогать.
Решение — стандартная Linux-механика: группы и списки контроля доступа (ACL). Группы задают грубую модель: кто относится к разработчикам, кто к команде заказчика, у кого есть доступ к Docker и runtime-каталогам. ACL позволяют точнее: конкретному пользователю можно читать весь проект, но писать только в свою директорию; группе разработчиков — писать в общий workspace; заказчику — запускать деплой, но не редактировать .env и compose-файлы. Ключевой принцип: порядок держится не на договорённостях, а на файловой системе. Если права настроены правильно, часть ошибок агента будет остановлена автоматически — без участия человека.
При этом у участников остаётся общий контекст: все видят проектные документы, инструкции и задачи — иначе агенту просто неоткуда взять информацию для работы. Workspace в этой схеме перестаёт быть просто папкой, открытой в редакторе, и становится структурированной средой, где у каждого элемента — кода, документации, задач, правил для агентов — есть своё место и свои права доступа. Именно эта структура, по мнению автора эксперимента, и является настоящей точкой сборки между бизнесом, разработкой и ИИ-агентами.
