Cursor стал для меня не редактором, а диспетчерской

Когда я впервые начал пользоваться Cursor, я воспринимал его довольно предсказуемо. Это редактор кода. Только с AI. Можно быстрее писать функции. Можно задавать вопросы по проекту. Можно попросить изменить несколько файлов. Можно получить autocomplete заметно умнее привычного.

То есть сама модель оставалась старой:

IDE
    ↓
я пишу код
    ↓
AI помогает

Менялся инструмент. Но не его место в моей работе.

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

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

Раньше центр разработки был очень понятным

Есть IDE. Есть developer. Есть код. Я открываю нужный класс. Пишу. Запускаю тест. Ставлю breakpoint. Снова пишу. Смотрю diff. Основная работа происходит непосредственно между мной и исходным кодом.

Даже если рядом открыт браузер, терминал, документация или Jira, центр процесса всё равно понятен.

задача
    ↓
developer
    ↓
IDE
    ↓
code

AI сначала прекрасно встроился именно сюда. Он стал ещё одним инструментом внутри IDE. Но потом схема постепенно начала переворачиваться.

Я стал начинать задачу не с открытия файла

Это, наверное, самый простой признак изменений. Раньше приходит задача: добавить возможность повторной отправки уведомления. Первая мысль: где у нас NotificationService? Открываю файл. Начинаю читать.

Сейчас всё чаще первая мысль другая: что вообще затрагивает эта задача? И вместо поиска конкретного класса начинается исследование.

найди текущий flow
покажи связанные сервисы
найди существующие тесты
посмотри похожие реализации
найди ограничения
проверь, какие entry points участвуют

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

Код перестал быть единственным объектом работы

Это важное изменение. Когда IDE воспринимается прежде всего как редактор, естественно считать главным объектом работы файл. OrderService.php. NotificationController.php. PaymentHandler.php.

С agentic-разработкой объектом становится скорее задача. Например:

TASK: добавить ручной retry notification

А вокруг неё уже собирается всё остальное:

код
тесты
документация
контекст
архитектурные правила
логи
database
browser
commands
agents

То есть я всё меньше думаю: сейчас работаю с этим файлом. И всё чаще: сейчас веду вот эту задачу через процесс разработки. Это небольшая разница в формулировке. Но она сильно меняет роль инструмента.

Cursor стал местом постановки задачи

Сначала AI получал довольно локальные инструкции: измени этот метод. Теперь задача может начинаться намного выше.

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

То есть Cursor становится местом, где задача постепенно превращается в инженерную работу. Не обязательно местом, где эта работа целиком выполняется. Это важное различие.

Потому что непосредственный исполнитель теперь может быть вообще другим

Например, я могу использовать такую схему:

Cursor
    ↓
task / context / environment
    ↓
Claude Code
    ↓
implementation
    ↓
Codex
    ↓
review
    ↓
Cursor
    ↓
verification

Именно здесь понятие «редактор» начинает немного ломаться. Если Claude Code написал большую часть feature, а Codex сделал review, что именно делал Cursor? Очень много. Просто не обязательно писал production-код. Он был местом, где я управлял всем процессом. Это продолжает ту же мысль, что и в заметке про нескольких AI-разработчиков вместо одного.

Мне нравится сравнение с control plane

Наверное, именно так я сейчас воспринимаю эту роль. Не «Cursor — редактор, который умеет AI». А скорее:

Cursor
    ↓
control plane development workflow

Есть исполнители. Есть окружение. Есть состояние задачи. Есть проверки. Есть разные инструменты. А есть одна точка, из которой я стараюсь всем этим управлять.

Это немного похоже на инфраструктуру. Сам control plane не обязательно непосредственно выполняет каждую операцию. Он координирует систему. В разработке у меня постепенно появляется похожее ощущение.

Исследование теперь происходит там же, где реализация

Раньше research часто был довольно разрозненным. Открыл IDE. Пошёл в браузер. Погуглил. Посмотрел документацию. Вернулся. Запустил grep. Открыл database client. Посмотрел логи. Снова IDE.

С AI часть этого постепенно начинает собираться вокруг одной задачи. Я могу попросить агента: найди, где формируется этот статус. Потом: проверь, где он отображается. Потом: посмотри связанные тесты.

И получаю уже не просто список файлов. Получаю некоторое представление о системе. Это делает редактор ещё и инструментом навигации по проекту. Не только файловой. Смысловой.

Подготовка задачи стала отдельной частью работы

Это особенно хорошо чувствуется перед запуском более автономного агента. Я не хочу просто сказать Claude Code: сделай feature. Сначала полезно подготовить землю.

Понять текущее состояние repository. Убедиться, что тесты проходят до изменения. Посмотреть, нет ли незакоммиченных изменений. Собрать требования. Определить ограничения. Проверить документацию. Найти релевантные участки проекта.

Иногда уже на этом этапе задача меняется. Например, оказывается, что предполагаемая новая feature наполовину существует. Или исходная постановка конфликтует с существующим поведением. И только потом имеет смысл запускать implementation. Cursor в таком процессе становится местом staging задачи.

Потом задача уходит исполнителю

И здесь возникает довольно непривычное ощущение. Я могу не открывать каждый будущий файл заранее. Могу сформулировать результат: вот задача. Вот найденный контекст. Вот ограничения. Вот план. Реализуй.

Дальше агент сам начинает работать с repository. Открывает файлы. Меняет. Запускает команды. Возвращается с результатом.

В старой модели IDE я был непосредственным исполнителем. Теперь иногда я скорее человек, который отправил работу в выполнение. Это очень похоже на диспетчерскую.

Но принять результат всё равно нужно здесь

Агент закончил. Это не означает: задача закончена. Теперь начинается другая часть. Посмотреть diff. Понять масштаб изменений. Проверить подозрительные места. Запустить приложение. Пройти сценарий. Посмотреть логи. Передать независимому reviewer. Вернуть замечания автору.

То есть задача снова возвращается в центральную точку. Получается цикл:

prepare
    ↓
dispatch
    ↓
execution
    ↓
return
    ↓
verification
    ↓
review
    ↓
decision

И чем больше я работаю так, тем меньше слово «editor» описывает происходящее.

UI testing особенно хорошо это показывает

Для backend-разработчика очень легко остановиться на «tests green → готово». Но если feature имеет интерфейс, этого часто недостаточно. Нужно реально открыть приложение. Нажать кнопку. Проверить состояние. Посмотреть сообщение об ошибке. Убедиться, что loading state нормальный. Проверить, что действие исчезает там, где недоступно.

И здесь AI-процесс начинает выходить за границы исходников. Важно уже не только, правильный ли PHP-код, но и работает ли пользовательский сценарий. Поэтому browser/UI testing для меня становится ещё одним этапом общего workflow.

И редактор оказывается центром не только code-generation, но и проверки результата в работающей системе. Про зелёные тесты, которые сами по себе меня уже меньше успокаивают, я писал отдельно.

Environment тоже стал частью разработки

Раньше окружение было чем-то вроде фона. Проект поднят. Docker работает. База есть. Redis есть. Можно писать код. Но как только работу начинает выполнять агент, окружение превращается в часть его возможностей.

Если он не может поднять приложение — автономность резко падает. Если не может выполнить migration — падает. Если не видит тестовую базу — падает. Если не умеет посмотреть логи — падает. Если окружение нестабильно — агент может начать чинить симптомы инфраструктуры как bugs приложения.

Поэтому я стал намного внимательнее относиться к тому, насколько проект вообще готов к машинной работе.

Хорошее окружение — это ещё один API для агента

Есть команда composer test. Есть composer quality. Есть понятный способ запустить приложение. Есть test fixtures. Есть отдельный environment. Есть доступные логи. Есть способ сбросить состояние.

Для человека всё это просто удобство разработки. Для AI — интерфейс управления проектом. Чем он стабильнее, тем больше работы можно отдать агенту без ручного вмешательства. И снова Cursor оказывается местом, из которого я управляю этим интерфейсом.

Автоматизация постепенно съедает мои повторяющиеся действия

Раньше после каждой реализации я вручную делал примерно одно и то же. Запустить тесты. Проверить PHPStan. Посмотреть diff. Иногда formatter. Поднять браузер. Проверить feature.

Теперь возникает очевидное желание собрать это в команды и workflows. Например:

verify-feature
    ↓
tests
    ↓
static analysis
    ↓
lint
    ↓
application check

И тогда вместо «теперь сделай вот это, потом вот это, потом ещё это...» у меня появляется один этап: запусти verification. Чем больше таких вещей автоматизировано, тем сильнее ощущение control plane. Это та же дорога, по которой я всё меньше пишу промпты и всё больше строю workflow.

Самое интересное — я стал управлять не файлами, а состояниями задачи

Раньше задача для меня могла находиться в очень простом состоянии: не сделано → пишу код → сделано. Сейчас состояний намного больше.

new
    ↓
research
    ↓
ready for plan
    ↓
planned
    ↓
ready for implementation
    ↓
implemented
    ↓
needs review
    ↓
reviewed
    ↓
needs verification
    ↓
done

Это уже почти workflow engine. И в каждой точке может работать другой инструмент. Research сделал один агент. Implementation другой. Review третий. UI verification я проверил сам. Получается, я всё меньше управляю конкретным агентом. Я управляю переходом задачи между состояниями.

Возможно, поэтому мне всё меньше важен вопрос «какой AI встроен в редактор»

Потому что редактор перестаёт быть контейнером одной модели. Если завтра один инструмент лучше делает implementation, я могу использовать его. Другой лучше review — использовать его. Третий хорошо работает с UI — подключить туда.

Ценность центральной среды тогда заключается не в том, что внутри находится «самый лучший AI». А в том, что через неё удобно собрать весь процесс.

task
context
agents
terminal
browser
tests
diff
environment

Вот это уже намного интереснее.

Cursor для меня постепенно стал местом встречи разных инструментов

Они не обязательно идеально интегрированы друг с другом: иногда связь только концептуальная. Есть задача. Я вижу код. Рядом terminal. Рядом agent conversation. Можно отправить работу Claude Code. Можно получить review от Codex. Вернуться к diff. Запустить приложение. Проверить результат.

То есть редактор становится интерфейсом не только к source code. Он становится интерфейсом к процессу изменения source code. Это тонкое, но важное различие.

При этом я всё ещё пишу код в Cursor

И это важно. Не хочется создавать впечатление, будто я теперь только управляю агентами с большой красной кнопкой. Нет. Я по-прежнему открываю файл. Правлю строку. Переписываю метод. Смотрю SQL. Запускаю debugger. Иногда задача быстрее решается руками, чем через любого агента.

Просто это перестало быть единственным режимом работы. Теперь рядом существуют:

я сам пишу
я + AI пишем вместе
AI пишет, я проверяю
один AI пишет, другой проверяет
AI исследует, я принимаю решение
AI выполняет workflow

И все эти режимы удобно иметь в одном рабочем пространстве.

Поэтому слово «IDE» начинает казаться немного узким

IDE исторически интегрировала инструменты разработки. Редактор. Debugger. Build. Version control. Terminal. Так что в каком-то смысле ничего принципиально нового не происходит. Просто появляется ещё один слой интеграции.

Теперь IDE начинает интегрировать не только инструменты, но и исполнителей. Это уже интереснее. Раньше кнопка запускала compiler. Теперь команда может запустить агента, который двадцать минут исследует проект и возвращается с реализацией. Разница довольно большая.

Появляется новая задача — наблюдать за процессом

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

То есть вместо постоянного написания кода появляется supervisory work. Не обязательно микроменеджмент. Скорее контроль направления. И снова редактор становится хорошим местом для этого.

Я всё больше ценю возможность быстро вмешаться

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

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

То есть хорошая диспетчерская нужна не для тотального контроля каждого действия. А для дешёвого human checkpoint.

UI постепенно начинает быть важнее самого prompt

Раньше большой вопрос был: что написать AI? Теперь мне интереснее: как удобно увидеть, что он сделал?

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

То есть интерфейс разработки должен помогать не только генерировать. Он должен помогать управлять и проверять. Это совсем другой класс требований к редактору.

Я начал воспринимать Cursor как рабочий стол над системой разработки

Наверное, так точнее всего. Под ним могут находиться разные слои:

repository
    ↓
environment
    ↓
tools
    ↓
agents
    ↓
workflows
    ↓
verification

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

Это меняет даже ощущение от программирования

Иногда вечером я смотрю на день и понимаю: я практически не написал production-код руками. Но при этом разобрал три задачи, подготовил контекст, скорректировал два плана, отклонил одну неправильную архитектуру, запустил несколько реализаций, провёл cross-review, проверил UI, исправил найденный edge case, принял итоговые изменения.

Был ли это день программирования? Для меня — совершенно точно да. Просто программирование всё меньше сводится к непосредственному набору кода.

Возможно, редакторы вообще идут к этому

Не просто «здесь удобно писать код с AI», а «здесь удобно управлять изменениями системы, которые выполняются человеком и AI совместно». И тогда основными сущностями становятся не только file, function и class, но ещё:

task
agent
plan
workflow
verification
review
environment

Вот это развитие мне сейчас особенно интересно наблюдать. Потому что оно меняет не отдельную функцию редактора. Оно меняет его место в работе разработчика.

Поэтому Cursor для меня уже не только редактор

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

То есть схема постепенно стала выглядеть так:

раньше:

Cursor
    ↓
code


сейчас:

                 Claude Code
                      ↓
TASK → Cursor → workflow → implementation
         ↓                         ↓
    environment                  Codex
         ↓                         ↓
     testing ← verification ← review

Конкретные инструменты в этой схеме наверняка ещё много раз поменяются. Сегодня Claude Code и Codex. Завтра что-то другое. Поэтому мне интересна не конкретная комбинация названий. Мне интереснее сама роль центральной точки.

Cursor
≠
только место написания кода


Cursor
    ↓
control plane development workflow

И если раньше я открывал редактор, чтобы писать программу, то теперь всё чаще открываю его, чтобы управлять процессом изменения программы. Для меня это гораздо более серьёзное изменение, чем любой новый autocomplete.