На прошлой неделе в инженерном блоге Cursor был опубликовал манифест «The third era of AI software development». В посте описываются три эры AI-разработки в контексте использования самого продукта. Пост содержит интересную внутреннюю статистику Cursor, которая показывает: смена парадигмы — это уже не прогноз, а то, что происходит прямо сейчас.

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


Когда мы несколько лет назад начали создавать Cursor, большая часть кода писалась вручную. Автодополнение по Tab изменило это и открыло первую эпоху ИИ-кодинга.

Затем появились агенты, и разработчики перешли к тому, чтобы направлять их через синхронные циклы «промпт → ответ». Это была вторая эпоха. Теперь наступает третья. Её определяют агенты, которые способны самостоятельно браться за более крупные задачи — на более длинных временных отрезках и с меньшим количеством человеческих указаний.

В результате Cursor больше не про то, чтобы в первую очередь писать код. Он про то, чтобы помогать разработчикам строить «фабрику», которая создаёт их ПО. Эта фабрика состоит из множества агентов, с которыми разработчики взаимодействуют как с членами команды: задают направление, оснащают инструментами для самостоятельной работы и затем проверяют результат.

Многие из нас в Cursor уже работают именно так. Сейчас более одной трети PR, которые мы мёрджим, создаются агентами, работающими автономно на собственных компьютерах в облаке. Мы считаем, что через год подавляющая часть разработки будет выполняться такими агентами.

От Tab(автодополнения) к агентам

Tab отлично выявлял места, где простую, повторяющуюся работу можно автоматизировать. Почти два года он давал заметный прирост эффективности.

Потом модели стали лучше. Агенты смогли удерживать больше контекста, использовать больше инструментов и выполнять более длинные последовательности действий. Привычки разработчиков начали меняться — сначала медленно летом, а затем быстро за последние несколько месяцев на фоне релизов Opus 4.6, Codex 5.3 и Composer 1.5 (собственная модель Cursor).

Преобразование оказалось настолько полным, что сегодня большинство пользователей Cursor вообще не нажимают клавишу Tab. В марте 2025 у нас было примерно в 2,5 раза больше пользователей Tab, чем пользователей агентов. Теперь всё наоборот: пользователей агентов примерно в 2 раза больше, чем пользователей Tab.

Использование агентов в Cursor выросло более чем в 15 раз за последний год.
Использование агентов в Cursor выросло более чем в 15 раз за последний год.

Но уже сейчас этот сдвиг уступает место чему-то ещё более масштабному. Эпоха Tab длилась почти два года. Вторая эпоха — когда большая часть работы делается с синхронными агентами — может не продлиться и одного.

Облачные агенты и артефакты

По сравнению с Tab синхронные агенты работают на более высоком уровне абстракции. Они берут на себя задачи, требующие контекста и рассуждений, но при этом на каждом требуют участия разработчика. Однако такой формат взаимодействия в реальном времени, вместе с тем что синхронные агенты конкурируют за ресурсы локальной машины, означает: на практике удобно работать лишь с несколькими агентами одновременно.

Облачные агенты снимают оба ограничения. Каждый запускается на своей виртуальной машине, поэтому разработчик может передать задачу и заняться чем-то ещё. Агент прорабатывает её часами, итерируется и тестирует, пока не будет уверен в результате, а затем возвращается с тем, что можно быстро проверить: логами, видеозаписями и живыми превью — а не только диффами исходных кодов.

Это делает параллельный запуск агентов практичным: артефакты и превью дают достаточно контекста, чтобы оценить результат, не восстанавливая каждую сессию «с нуля». Роль человека смещается от ведения каждой строки кода к постановке задачи и заданию критериев проверки.

Сдвиг уже происходит внутри Cursor

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

  1. Агенты пишут почти 100% кода.

  2. Люди тратят время на декомпозицию задач, проверку артефактов и выдачу обратной связи.

  3. Они запускают сразу несколько агентов, вместо того чтобы «вести за руку» одного до конца.

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

Мы думаем, что вчерашний релиз облачных агентов Cursor — это начальный, но важный шаг в этом направлении.

Имеется в виду релиз Cursor, в котором обоачные агенты стали существенно автономнее: запускаются в изолированных облачных VM, сами подключаются к вашему репозиторию, тестируют изменения, собирают артефакты (видео/скриншоты/логи) и выдают PR, готовые к мерджу.)


Про AI-driven разработку и агентов пишу в Telegram: @aidialogs

Комментарии (7)


  1. Dhwtj
    02.03.2026 16:43

    разработчик может передать задачу и заняться чем-то ещё. Агент прорабатывает её часами, итерируется и тестирует, пока не будет уверен в результате, а затем возвращается с тем, что можно быстро проверить

    Очевидно, ТЗ или сотен тестов подготовленных вручную нет: дорого.

    Внимание, вопрос: что же именно решает LLM всё это время?

    У вас 5 минут, время пошло!

    Агент проверяет ровно то, что автоматизировано.

    Существующие автотесты (юнит, интеграционные). Скомпилируйтся или нет (то есть работают ли уже сформулированные утверждения выраженные в типах).

    Работает на

    Багфиксы с готовым тест-кейсом. Даешь падающий тест, агент крутится, пока не сделает его зеленым.

    Рутинные миграции. Например, обновить вызовы старого API на новое по всей кодовой базе.

    Чистые функции и изолированные алгоритмы. Там, где очевидны входы и выходы.

    Бойлерплейт

    если агент реально крутится часами автономно, на практике он занят не глубоким проектированием, а вязнет в болоте. А лучшем случае брутфорс кривого апиAPI. Читает кривую доку в сети, дергает эндпоинты, получает 400 Bad Request, перебирает структуру JSON вслепую.

    Либо происходит взрыв когда простое требование меняет огромный объем кода


    1. Dhwtj
      02.03.2026 16:43

      Более осмысленный вариант:

      Брутфорс кривых требований - "сделай чтобы пользователь видел X" и 50 попыток пока скриншот не совпадет. Тесты как оракул, визуальный diff как оракул. Агент не понимает что делает, но конвергирует с скриншотом или системой-образцом.

      Копирование другой системы - "вот API/UI/скриншот образца, сделай такое же". Оракул внешний, верификация дешевая. Оракул должен быть машиночитаемым - скриншот, API-ответ, тест. Не человек. Это реально часы осмысленной автономной работы, только тупой и совсем дешёвой, которой человек бы не стал заниматься.

      Оба случая объединяет: дешевая проверка, дорогая генерация человеком. Агент дешево генерирует, проверяет сам, итерирует. Человек тут не нужен в цикле. Но он и не стал бы заниматься такой фигнёй.


    1. FSmile
      02.03.2026 16:43

      Токены то крутятся. ИИ "революция" идет


  1. FixicusMaximus
    02.03.2026 16:43

    Как же радует, что внутри этих говноконтор инженеров почти не осталось и код пишут электронные болваны, ждемс, когда это все благополучно схлопнется


  1. arch1lochus
    02.03.2026 16:43

    Автор перевода говорит, что описанные практики совпадают с тем, что он реально наблюдает в своей работе. Но я, как человек с gpt plus за 20$, копирующий в "чатик" время от времени небольшие куски кода, всё никак не пойму, как должна выглядеть работа с автономными агентами.
    Получается, агент контролирует мою рабочую машину, сам в IDE переключается между проектами? Сейчас я, например, отлаживаю несколько микросервисов, каждый из которых живет в отдельном проекте.
    OK, допустим агент сделал небольшую доработку - далее он должен сам собрать docker images для обоих микросервисов, запушить их в репозиторий; зайти на dev-сервер по ssh, там в нужной директории сделать docker-compose pull, up -d, отправить толстенный xml на эндпойнт одного из них и отправиться в логи сначала одного сервиса, затем другого.
    По результатам этого действия, итерации могут повторяться.
    Нынешние агенты могут выполнять всё это автономно? Какое примерное количество токенов они съедят за одну такую простую итерацию?


    1. Dhwtj
      02.03.2026 16:43

      Возьмите вместо вашего девопс электронного болвана


    1. Daimonn
      02.03.2026 16:43

      у меня на пет проекте именно так агент и делает, ходит по ssh на сервер, все обновляет и настраивает, поднимает стэк, который я понятия не имею, как самому поднимать, т.к. не девопс. Я понимаю, что это все может быть дырявым, но это пет проект для себя.

      На работе не доверяю ему никакой автономности и архитектурных решений, максимум "реализуй такой-то интерфейс" или функцию, с детальным ревью после.