Агент умеет писать код, а до слияния дело не доходит: скрипты заточены под чужой компьютер, команды — в головах людей, проверки — руками. В Cursor у себя облачные агенты уже закрывают больше половины принятых слияний — и сами пишут, что упёрлись не в модель, а в рабочую машину.
Инструкции по командам почти не сдвинули дело. Помогло выровнять машину агента с тем, чем пользуются разработчики, упростить запуск сервисов и научить систему самой ловить и чинить поломки. Цифра внутренняя, на чужой проект её не переносят — но прежде чем гнаться за новой моделью, стоит спросить: есть ли у агента нормальная машина и способ доказать, что код работает.
Цифра про половину слияний — внутренняя и с оговорками
В конце июля 2026 Cursor выложил пост How we set up our cloud agent environment. Там прямо: в декабре облачные агенты авторствовали примерно каждый десятый принятый запрос на слияние в их собственном монорепозитории. К моменту поста — уже больше половины кода, который они выпускают. В треде в X та же история звучит как 56%. Это не аудит рынка и не обещание «у вас будет так же» — это отчёт вендора про свой репозиторий, свои правила ревью и то, какие задачи вообще отдают агенту.
Доля принятых слияний — не то же самое, что доля удачных попыток, скорость поставки или экономия часов. На цифру влияют маршрутизация задач, политика слияния и рост команды. Разбор на AI Insiders и инженерный разбор на AgentPedia сходятся в одном: цифра на витрине красивая, но это не промышленный бенчмарк. Читать стоит причину скачка, а не процент как талисман.
Потолок оказался в машине, а не в названии модели
Тезис Cursor простой: среда разработки — продукт, а пользователи этого продукта теперь ещё и агенты. Облачная машина должна совпадать с локальной. Репозиторий должен читаться без устного знания команды. Среду надо держать живой, когда код и зависимости меняются.
У разработчиков Cursor в основном Mac. Облачная виртуальная машина — Linux. Пока скрипты и утилиты жили «как на маке», агент спотыкался на ерунде: пути, пакеты, предположения о системе. Они переписали подготовку под Ubuntu и положили критичные зависимости в образ, с которого стартуют облачные агенты. Это скучная инженерия. Именно она сдвигает долю слияний сильнее, чем очередная «самая умная» модель в чате.
Документация облачных агентов у Cursor говорит то же: изолированная виртуальная машина с полноценной средой, а главный рычаг — настройка клонов, зависимостей, секретов, запуска и сети. Если у вас агент «умный», а старт среды кривой — вы смотрите не туда.
Одни инструкции по командам почти не сдвинули долю слияний
Cursor честно пишут: описания команд сами по себе сдвинули дело на полях. Команды были запутанные, с ловушками. Агент читал текст и всё равно ошибался, потому что интерфейс среды оставался враждебным.
Сдвиг пошёл, когда появился единый способ поднимать сервисы и утилиты: простая командная утилита с нормальной справкой по флагам, плюс служба, которая перезапускает долгую сборку. Модели больше не нужно «нянчить» процесс руками. После этого агенты смогли гонять проверки до конца и показывать результат — в Slack или в самом запросе на слияние. Для части задач инженеры стали сливать и выкатывать без выгрузки ветки к себе на ноутбук. Доверие выросло не от красивой инструкции, а от повторяемой машины.
Среда должна сама ловить поломки и чинить их
Следующий слой — не «ещё один промпт», а самолечение. Через Cloud MCP агент видит свою среду: сбои подготовки, политику исходящей сети, сменившиеся секреты — и может восстановить то, что сломалось. Поверх этого у Cursor крутится автоматизация вроде Cloud Doctor: отличает случайный сбой от системного, разбирает причину, при необходимости открывает запрос на слияние с фиксом, смотрит следы других агентов и правит кривые навыки, пути и саму среду.
Имена anydev и Cloud Doctor — внутренний стек Cursor в этом кейсе. Копировать названия смысла нет. Смысл — свой канонический вход в командную строку, свои проверки «сквозняком» и свой контур здоровья среды, который не ждёт, пока человек ночью починит сломанный старт.
Отдельно — безопасность, без которой агенту нельзя давать секреты. В посте Cursor: ограничения исходящей сети, доступ к git через прокси, сканирование секретов в коммитах и сообщениях, затирание значений в результатах инструментов. Агент не должен читать пароль даже если пытается. Иначе «умная машина» превращается в дыру.
Три вопроса к своему репозиторию до смены модели
Cursor сводят готовность к трём проверкам. Есть ли у агента те же инструменты и данные, что у разработчика? Находятся ли навыки так, как люди реально работают, а не как написано в устаревшей вики? Может ли агент сам проверить и доказать ключевые сценарии — не словами «всё ок», а кодом выхода, тестом, демо?
Если скрипты только под чужой ноутбук, канонической команды теста нет, а секреты размазаны по личным конфигам — новая модель ничего не спасёт. Если агент сказал «готово», а артефакта проверки нет — это не проверка. Если в переиспользуемую среду агента положили широкие личные ключи от git — вы экономите время на ревью и покупаете риск.
Практический маршрут короткий. Выровнять облачную машину с тем, чем пользуется команда. Упростить запуск сервисов до одного понятного входа. Дать агенту способ прогнать сквозной сценарий и показать результат. Только потом спорить о модели. И не переносить 56% Cursor на свой продукт как норму — смотреть, что у вас ломается до слияния.
Половина слияний у Cursor — не про «модель стала умнее». Это про машину, которую агенту не стыдно отдать. Пока у вас кривой старт и проверки руками — новая модель только дороже повторит ту же беду. Разборы таких кейсов и рабочие связки Cursor, Make и нейросетей — в канале «Ковчег» и в том же канале в MAX. Если нужен стек под агентов и субагентов без воды — есть обучение Cursor, Make и AI.
