Рой ИИ-агентов компании Cursor воссоздал движок SQLite на языке Rust, потратив $1339 за четыре часа работы. Восемь конфигураций моделей выдали одинаковый результат, но разброс цен достиг 8-кратной величины - до $10 565. Ключ к эффективности - архитектура разделения труда, где дорогие модели планируют, а дешевые пишут код.
Эксперимент важен не столько суммой в чеке, сколько демонстрацией работающей модели координации. Старая версия роя с Grok 4.5 за два часа сгенерировала 68 000 коммитов и 70 000 конфликтов слияния - проект утонул в хаосе. Новая архитектура с планировщиками, воркерами и арбитрами решила проблему: меньше тысячи коммитов, девять пакетов и чистый код, проходящий тесты.
Разберем экономику, архитектуру и практические выводы эксперимента, который меняет представление о том, как ИИ-агенты могут вместе писать production-код.
Экономика роя: почему $1339 - это прорыв, а не просто чек
Счет в $1339 за воссоздание SQLite на Rust выглядит как маркетинговый заголовок. За ним стоит конкретный механизм снижения затрат, который можно воспроизвести в своих проектах. Разберем структуру расходов и токеномику, обеспечившую восьмикратную разницу между самой дешевой и самой дорогой конфигурацией.
Разбор счета: от $1339 до $10 565 за один и тот же результат
Все восемь конфигураций агентов решали одну задачу - написать аналог SQLite на Rust, ориентируясь на документацию оригинального проекта. Результат оценивался по прохождению sqllogictest, и все варианты показали сопоставимое качество кода. Различалась только цена.
| Конфигурация | Модель планировщика | Модели воркеров | Итоговая стоимость |
|---|---|---|---|
| Самая дешевая | Opus | Composer (быстрые) | $1 339 |
| Средняя | GPT-5.5 | Смешанный пул | $4 200 |
| Самая дорогая | Opus (макс. контекст) | Opus (часть задач) | $10 565 |
Разрыв в 8 раз при одинаковом результате - прямое следствие архитектурного решения. В дорогих конфигурациях планировщики держали расширенный контекст и часть работы выполняли на тех же мощных моделях, что и планирование. Дешевая конфигурация жестко разделила роли и отдала 90% работы быстрым моделям с минимальным контекстом.
Токеномика: почему 90% трат приходится на дешевых воркеров
Планировщик получает задачу, читает документацию SQLite, выделяет архитектурные блоки и для каждого формирует спецификацию - дизайн-док. Этот этап требует глубокого понимания контекста, поэтому планировщик работает на дорогой модели с длинным окном. Но объем генерируемого текста невелик: несколько абзацев спецификации на каждый модуль.
Воркер получает изолированную подзадачу - реализовать парсер SQL-запросов, обработчик транзакций, менеджер страниц. Его контекст ограничен спецификацией и релевантными фрагментами кодовой базы. Модель воркера - быстрая и дешевая. Токенов тратится много: генерация сотен строк кода, итеративные правки после проверок, повторные прогоны при ошибках компиляции.
Итоговое распределение: 90% токенов сжигают дешевые воркеры, 10% - дорогие планировщики. Если перевернуть пропорцию и заставить мощную модель писать весь код соло, счет вырастет до $8 000–12 000 за тот же объем работы. Архитектура роя - это арбитраж стоимости токенов между разными классами моделей.
Архитектура роя: планировщики, воркеры и война с хаосом
Первый запуск роя Cursor с Grok 4.5 закончился провалом. За два часа агенты сгенерировали 68 000 коммитов - в 70 раз быстрее, чем новая версия. Вскрытие показало катастрофические проблемы: 54 пакета вместо разумных 9, три независимых реализации SQL-парсера, один файл накопил 7 771 конфликт от 1 173 агентов. Агенты боялись трогать код ядра - любые изменения ломали десятки зависимостей. Проект окостенел.
Разработчики Cursor пересобрали архитектуру с нуля, применив принципы корпоративного менеджмента к рою агентов. Результат - система, которая генерирует меньше тысячи коммитов за четыре часа и стабильно проходит тесты.
Планировщик не пишет код, воркер не планирует: жесткое разделение ролей
Первый принцип новой архитектуры - полное разделение функций. Планировщик декомпозирует задачу, читает документацию, выделяет модули и пишет дизайн-доки. Он не генерирует ни строчки кода и не хранит в памяти детали реализации. Воркер получает спецификацию, изолированный контекст и требование реализовать ровно то, что описано. Он не принимает архитектурных решений и не пытается понять проект целиком.
Разделение решает проблему «загрязнения контекста». Когда агент одновременно планирует и пишет код, его окно быстро забивается деталями реализации, и качество архитектурных решений падает. Когда воркер пытается планировать, он выходит за границы задачи и создает конфликты с соседними модулями. Жесткие роли устраняют оба класса ошибок.
Новый рой зафиксировал девять пакетов на раннем этапе и не добавил ни одного до конца работы. Никакого расползания архитектуры, никаких дублирующихся реализаций.
Дизайн-доки, арбитры и принудительная поломка: как рой договаривается
Планировщики фиксируют решения в дизайн-доках - структурированных спецификациях, которые становятся источником истины для всех воркеров. Дизайн-док описывает интерфейс модуля, контракты данных, ожидаемое поведение и границы ответственности. Воркер не имеет права отклониться от спецификации.
Конфликты слияния неизбежны, когда десятки агентов одновременно модифицируют кодовую базу. В старом рое они накапливались лавинообразно. В новом работает арбитр - агент, который получает список конфликтующих изменений и разрешает их, опираясь на дизайн-доки как на арбитражный свод правил.
Раздувание файлов - еще одна проблема, погубившая старый рой. Когда один файл накапливает тысячи конфликтов, его блокируют и принудительно режут на модули. Воркеры получают новые, изолированные файлы с четкими контрактами.
Самый контринтуитивный механизм - принудительная поломка. В старом рое агенты боялись трогать код ядра, потому что любое изменение вызывало каскад ошибок. Проект окостенел: ядро оставалось монолитным и неоптимальным. Новый рой получил разрешение намеренно ломать код ядра, если это требуется для реализации спецификации. Арбитр и дизайн-доки дают гарантию, что сломанное починят, а воркеры - что починят быстро. Окостенение устранено.
Уроки для реальных проектов: когда рой окупается, а когда - нет
Эксперимент Cursor впечатляет, но его результаты нельзя механически переносить на любую задачу. Воссоздание SQLite по документации - специфический случай с четкой спецификацией, известной архитектурой и объективными критериями качества. Разберем, какие условия делают рой эффективным и где подход ломается.
Корпоративный менеджмент в мире кода: что общего у роя и команды людей
Архитектура нового роя зеркально отражает практики управления человеческими командами разработки. Дизайн-доки - аналог технического задания, которое тимлид пишет до старта разработки. Арбитр - роль техлида, разрешающего конфликты между разработчиками на основе утвержденной архитектуры. Блокировка раздувшихся файлов - аналог code-freeze и рефакторинга монолита на микросервисы.
Принудительная поломка - управленческое решение «разрешить трогать легаси», которое в человеческих командах часто блокируется страхом и политическими границами. Рой реализует его буквально: агент получает санкцию сломать код ядра, потому что арбитр гарантирует восстановление.
Специализация ролей - еще одна параллель. В эффективных командах архитектор не пишет рутинный код, а джуниор не принимает архитектурных решений. Рой формализует это разделение до уровня системного ограничения: планировщик физически не может писать код, воркер не получает контекст для планирования.
Практический вывод: если ваша команда уже работает по этим принципам, внедрение роя агентов будет эволюционным шагом. Если команда хаотична, рой только усилит хаос - как показал первый эксперимент Cursor.
Ограничения и подводные камни: что осталось за кадром эксперимента
Прогресс роя измерялся по прохождению sqllogictest - стандартного набора тестов для SQL-движков. Агенты не знали о существовании тестов и не оптимизировали код под них. Это сильный результат, но он не означает, что сгенерированный код готов к production. Тесты покрывают функциональность, но не краевые случаи, безопасность и производительность под нагрузкой.
Данные о Grok 4.5 в старом рое могут устареть - модель обучалась совместно с xAI, которая теперь называется SpaceXAI. Прямое сравнение старой и новой архитектуры справедливо для демонстрации принципов, но не для точных бенчмарков моделей.
Самое важное ограничение: SQLite воссоздавали по готовой документации. Четкая спецификация существовала до начала работы. В реальных проектах спецификация рождается в процессе, требования меняются, а заказчик не всегда знает, чего хочет. Рой эффективен, когда задача хорошо определена и может быть распараллелена на независимые модули. Разработка с нуля, исследовательские задачи и проекты с высокой неопределенностью остаются зоной ответственности человека.
Риски внедрения роя в реальный проект: нестабильность генерации, потребность в надзоре и верификации, ограниченная применимость для творческих и архитектурных задач. Подробнее о когнитивных ловушках при использовании code-агентов - в статье Code-агенты: ускорение разработки или когнитивная ловушка?.
Будущее автоматической разработки: от роя к экосистеме
Эксперимент Cursor - точка на траектории, которая меняет роль разработчика. Когда рой агентов за $1339 воссоздает SQLite за четыре часа, написание кода перестает быть главной компетенцией. На первый план выходят постановка задач, проектирование архитектуры, контроль качества и принятие решений о том, что строить.
Архитектура обвязки агентов становится критическим компонентом. Эксперименты показывают: смена harness-обвязки влияет на результат в 7.8 раза сильнее, чем смена модели. Разбор архитектурных ставок при проектировании обвязки и принцип «build to delete» для разделения временных костылей и несущей архитектуры - в материале Архитектурные ставки обвязки кодинг-агентов: разбор пяти harness и выводы для 2026 года.
Платформы вроде Google Antigravity уже реализуют асинхронную мультиагентную оркестровку, где агенты работают часами без вмешательства человека. Детальный разбор архитектуры Antigravity 2.0 с JSON-хуками и планировщиком Scheduled Tasks - в обзоре Google Antigravity 2.0: автономные ИИ-агенты без IDE.
Рынок движется к экосистеме, где разработчик управляет роем агентов, а не пишет код. Экономика токенов, архитектура разделения ролей и механизмы координации, отработанные в эксперименте Cursor, станут стандартными компонентами инструментария. Вопрос не в том, заменит ли рой разработчика, а в том, как быстро разработчик научится управлять роем.