Разделение труда в AI-разработке: как роли «планировщика» и «исполнителя» меняют подход к кодингу
Cursor разделил AI-агентов на планировщиков и исполнителей и переписал SQLite на Rust с идеальным результатом. Репозиторий сократился на 85%, конфликты слияния — в 70 раз, затраты — до 15 раз. Разбираем, как новый подход меняет работу разработчиков.
Почему один мощный AI-агент не справляется с большими проектами
Команда Cursor поставила перед AI-агентом задачу: переписать SQLite на Rust. Без доступа к исходному коду, без интернета, только спецификация и тесты. Результат с традиционным подходом - провал. Один агент, даже очень мощный, генерировал код, который тут же вступал в конфликт с работой других таких же агентов. Бесконечные конфликты слияния, перерасход токенов, итоговый продукт низкого качества.
Представьте стройку, где один универсальный рабочий пытается одновременно проектировать фундамент, класть кирпичи и тянуть проводку. Без чертежей, без разделения зон ответственности. Через час он забывает, где оставил уровень, и заливает бетон поверх кабелей. Примерно так выглядит попытка масштабировать одного AI-агента на крупный проект. Контекст раздувается, модель теряет нить, а правки разных агентов накладываются друг на друга, порождая хаос.
Проблема не в мощности модели. Проблема в отсутствии структуры. Мозг, отвечающий за стратегию, не может одновременно контролировать каждое движение рук. Cursor наглядно показал: для эффективной AI-разработки нужно не просто наращивать вычислительные ресурсы, а грамотно распределять задачи между специализированными агентами.
Архитектура с планировщиком и исполнителем: как это работает
Решение, которое принесло успех в эксперименте Cursor, построено на разделении контекста и ролей. Вместо одного универсального агента работает тандем: планировщик и исполнители. Планировщик - это мощная стратегическая модель. Она анализирует задачу целиком, разбивает её на подзадачи, определяет архитектуру и формирует спецификации. Исполнители - более лёгкие и дешёвые модели. Они получают узкие, чётко описанные задания и пишут код строго по спецификации.
Ключевой момент: исполнители не видят весь проект. Они работают в изолированном контексте, что предотвращает конфликты слияния. Планировщик следит за тем, чтобы кусочки пазла сошлись, а исполнители не мешают друг другу. Такой подход позволил сократить объём репозитория на 85% и снизить число конфликтов в 70 раз. Вычислительные затраты упали до 15 раз, потому что дорогая модель включается только для стратегических решений, а рутину делают экономичные агенты.
Разделение труда в AI-разработке - это прямой перенос принципов эффективного производства в кодинг. Как в Cursor Router, который направляет простые запросы дешёвым моделям, а сложные - мощным, архитектура с планировщиком и исполнителем распределяет нагрузку по уровню интеллектуальной сложности задачи.
Context-io: как передавать контекст без гигабайтов логов
Одно из узких мест при смене агента - передача контекста. Обычно приходится заново скармливать модели всю историю сессии. Для 500 записей полный лог раздувается до 143 000 токенов. Это медленно и дорого. Context-io решает проблему радикально: он записывает контекст сессии в обычный Markdown по мере работы, используя git-хуки. Когда новый агент вступает в дело, он получает не гигабайты логов, а компактный handoff frame - сжатое описание текущего состояния.
В стресс-тесте с 500 записями handoff frame занял 40 токенов. Сокращение на 99,97%. Для возобновления сессии требуется менее 500 токенов вместо 20 000+. Никаких вызовов LLM для генерации контекста - только git и несколько правил. Это не просто экономия. Это возможность быстро переключать агентов, не теряя нить проекта и не сжигая бюджет на повторную обработку истории.
Результаты эксперимента Cursor: цифры, которые впечатляют
Эксперимент Cursor по переписыванию SQLite на Rust с новой архитектурой дал конкретные, измеримые результаты. Переписанный код прошёл все тесты идеально - его поведение полностью соответствовало оригинальному SQLite. Напомним: агенты не имели доступа к исходному коду и интернету. Они опирались только на спецификацию и тестовые сценарии.
- Объём репозитория сократился на 85%. Код стал компактнее и чище.
- Число конфликтов слияния снизилось в 70 раз. Изолированные контексты исполнителей устранили главную проблему традиционного подхода.
- Вычислительные затраты упали до 15 раз. Дорогие модели использовались только для стратегического планирования.
Эти цифры - не теоретические оценки, а практический итог работы новой архитектуры. Они показывают, что грамотное разделение труда между AI-агентами даёт больший прирост эффективности, чем простое наращивание мощности одной модели. Похожий принцип изоляции и распределения задач мы разбирали в статье про VS Code 1.130, где AI-агенты теперь работают в отдельных процессах, повышая стабильность и безопасность.
Граф влияния изменений: как AI-агенты видят скрытые связи в коде
Разделение на планировщика и исполнителей решает проблему конфликтов, но остаётся другой риск: локальная правка может сломать что-то дальше по цепочке. AI-агент быстро добавляет функцию, правит тест, меняет API-клиент. Локально всё выглядит убедительно. Ошибка проявляется позже, в неожиданном месте. Чтобы этого избежать, используется граф влияния изменений.
Граф хранит происхождение каждой связи в кодовой базе. Для каждого ребра - например, между сервисом и репозиторием - фиксируется три слоя информации: факт (конкретная строка кода), вывод (что из этого следует) и наблюдение (как связь проявляется в работе системы). Такой подход отличает доказанные зависимости от предположений.
Анализ влияния строится как последовательность стадий с устойчивыми артефактами: сканирование кодовой базы, фильтрация релевантных связей, извлечение зависимостей, индексирование, разрешение конфликтов, подтверждение гипотез и обход графа для поиска цепочек влияния. Когда агент предлагает изменение, граф показывает все потенциально затронутые компоненты. Это не даёт абсолютных гарантий исполнения в runtime, но создаёт цепочку доказательств, достаточную для принятия взвешенного решения.
Что это значит для разработчиков: новые навыки и роли
Эксперимент Cursor - не просто технический курьёз. Он указывает на сдвиг в профессии разработчика. Фокус смещается с написания кода на проектирование архитектуры и постановку задач для AI-агентов. Программирование не исчезает, но меняется способ работы - как когда-то переход от ручного труда к управлению станками с ЧПУ не отменил производство, а изменил квалификацию рабочего.
Навык правильного формулирования требований становится критически важным. Разработчик превращается в дирижёра агентов: он ставит задачу планировщику, проверяет спецификации, контролирует качество кода от исполнителей. Понимание архитектуры и системного мышления ценятся выше, чем скорость печати и знание синтаксиса. Это перекликается с трендами рынка труда: как мы писали в разборе увольнений в tech-секторе, 78% компаний связывают сокращения с AI-стратегиями, а востребованными становятся специалисты, умеющие управлять AI-инструментами.
Применимо ли это к небольшим проектам и командам
Может показаться, что архитектура с планировщиком и исполнителями - удел гигантов, переписывающих SQLite на Rust. Это не так. Принцип разделения труда масштабируется вниз. Даже в небольшом проекте можно использовать дорогую модель для архитектурных решений и дешёвую - для рутинных задач: генерации шаблонного кода, написания тестов, форматирования.
Создание мини-CRM с помощью AI-агента, рефакторинг модуля, генерация документации - во всех этих сценариях выигрыш в скорости и качестве может быть значительным. Не обязательно строить полноценный пайплайн с Context-io и графом влияния. Достаточно осознанно разделять задачи: «сейчас я думаю над архитектурой и использую мощную модель, а сейчас - генерирую boilerplate с помощью экономичной». Экономия на вычислительных затратах и времени проявляется даже на малых масштабах.
Будущее AI-разработки: от помощников к автономным командам агентов
Эксперимент Cursor - это ранний сигнал более масштабного тренда. AI-агенты эволюционируют от одиночных помощников к автономным командам, способным самостоятельно вести проекты, распределять задачи и проводить код-ревью. Планировщик ставит цели, исполнители пишут код, другие агенты тестируют и проверяют безопасность. Разработчик наблюдает за процессом и вмешивается только в ключевых точках.
Быстрое развитие AI создаёт информационный шум, в котором легко потеряться. Наша задача - помогать вам ориентироваться в этих изменениях без технического жаргона и перегруза. Если хотите понимать тренды раньше других и принимать взвешенные решения, следите за новостями и кейсами на платформе. Есть вопрос или заметили неточность? Напишите нам - мы открыты к диалогу.
