Cursor опубликовала результаты эксперимента со вторым поколением своего "роя агентов" — системы, в которой сотни ИИ-агентов параллельно работают над одной кодовой базой. Задача — реализовать на Rust движок базы данных по 835-страничной документации SQLite. Без исходников, без готовых тестов, без бинарника оригинала и без доступа в интернет. Самая дешевая связка моделей уложилась в счет $1339 за четырехчасовой прогон. Главная находка — экономическая: та же задача с теми же моделями в других конфигурациях стоила до $10 565, и всю разницу сделала организация работы.
Прогресс мерили по sqllogictest — тестовому набору самого проекта SQLite с миллионами запросов и известными правильными ответами. Рой о существовании тестов не знал, а после каждого прогона авторы вручную проверяли код на читерство и убеждались, что система построена равномерно, а не только там, куда "смотрят" тесты.
Рой строится вокруг дерева задач, а агенты делятся на две роли. Планировщики на самых умных моделях режут цель на куски и делегируют их вниз, воркеры на быстрых и дешевых моделях исполняют. Смысл в том, что контекст каждого агента остается маленьким: планировщик никогда не пишет код и не забивает память деталями, воркер никогда не планирует и тратит весь контекст на свою задачу. По мнению Cursor, именно это объясняет, почему одиночные агенты на длинных задачах "плывут" — им приходится держать в голове и общую цель, и конкретный кусок работы одновременно.
Цену координации нагляднее всего показали прогоны Grok 4.5 — модели, которую Cursor обучала вместе с xAI (ныне SpaceXAI). Под старой версией роя Grok 4.5 выдал 68 000 коммитов за первые два часа, в 70 раз быстрее нового роя, — но это была не продуктивность, а агония: накопилось больше 70 000 конфликтов слияния, копились они все быстрее, и прогон остановили, не дожидаясь конца второго часа (новый рой за полные четыре часа собрал меньше тысячи).
Вскрытие показало ровно те же болезни, что у больших человеческих команд:
Раздвоение архитектуры: планировщики, не знавшие друг о друге, реализовали одни и те же концепции по несколько раз — проект расползся на 54 пакета-крейта, включая три независимых SQL-пакета, тогда как новый рой рано зафиксировал девять и больше не добавил ни одного.
Войны за территорию: планировщики раз за разом переписывали правки друг друга в одних и тех же файлах.
Мегафайлы: популярные файлы бесконтрольно росли, потому что каждый агент добавлял понемногу, а следить за размером было некому, — один такой файл собрал 7771 конфликт от 1173 разных агентов, тогда как в новом рое самый горячий файл пережил 47.
И "окостенение": агенты, наученные работой в человеческих кодовых базах, боялись трогать код ядра системы, даже когда его надо было менять.
Лечили это, по сути, корпоративным менеджментом. Планировщики теперь обязаны сами принимать дизайн-решения и следить, чтобы два поддерева не решали один и тот же вопрос. Решения фиксируются в общих дизайн-доках, а в коде стоит ссылка на документ, которую проверяет компилятор; если доки противоречат друг другу, их сводит отдельный агент-примиритель. Конфликты слияния разруливает нейтральный агент-арбитр — аналог merge queue в командах. Раздувшийся файл любой воркер может пометить флажком: новые коммиты в него блокируются, и внешний агент режет его на модули. Наконец, разрешена "намеренная поломка": агент может сознательно сломать код ядра ради нужного изменения, оставив комментарий с обоснованием, — компилятор разнесет ошибки по системе, и каждый, кто на них наткнется, прочитает причину и обновит свой кусок.
Под это перестроили и инфраструктуру. Git с блокировками на уровне всего репозитория не выдерживал темпа, поэтому Cursor написала собственную систему контроля версий: старый рой на Git в пике выдавал около 1000 коммитов в час, новая VCS — около 1000 коммитов в секунду. Поверх работает многослойное ревью: одни агенты-ревьюеры видят полный транскрипт воркера, другие только результат, третьи только кодовую базу, часть работает на других моделях. Ни одна "линза" не ловит все, но некоррелированные линзы складываются — Cursor сравнивает это с компонентами автопилота. А еще агенты ведут Field Guide — общую папку заметок для будущих агентов, которую курируют сами; авторы называют это стигмергией, по аналогии с тем, как муравьи координируются через изменение среды.
По оценке Cursor, новая версия роя обошла старую во всех четырех конфигурациях: GPT-5.5 соло, Grok 4.5 соло, Opus 4.8 как планировщик с Composer 2.5 в роли воркеров и Fable 5 с теми же воркерами. Связка с Fable 5 прошла около двух третей тестов уже за первый час. К четырехчасовой отсечке новые прогоны показывали 73–85% против 11–77% у старых, а при продолжении работы все новые конфигурации дошли до 100%. Кода при этом понадобилось в разы меньше: связке с Fable 5 хватило 9908 строк движка там, где старый рой написал 64 305; у связки с Opus — 4645 строк против 19 013.
Теперь экономика — ради нее, судя по заголовку, пост и писался. Качество у всех конфигураций сопоставимое, а счета — от $1339 у связки Opus 4.8 + Composer 2.5 до $10 565 у GPT-5.5, работавшего и планировщиком, и воркером (Grok 4.5 соло — $1928, связка с Fable 5 — $2234). Токены при этом жгут в основном воркеры: минимум 69% во всех прогонах, а в большинстве — больше 90%. Формула выгоды простая: моментов, где реально нужна самая умная модель, в большой задаче немного — декомпозиция, дизайн-решения, компромиссы. Когда дорогая модель приняла спорные решения и свела задачу к явной инструкции, дешевой остается только исполнять. В прогоне, где воркерами был GPT-5.5, они одни стоили $9373; флот воркеров Composer 2.5 в связке с Opus обошелся в $411. Любопытная сноска: GPT-5.6 Sol, которую изначально хотели взять как самую сильную конфигурацию, из сравнения убрали — модель оказалась слишком чувствительной к буквальным и акцентированным формулировкам промптов и уходила в "неуправляемые спирали", каких не выдавала ни одна другая.
Заканчивают авторы красиво: автодополнение позволяло работать на уровне строки, ранние модели — на уровне блока, агенты — на уровне файла или фичи, а с роями единицей работы становится спека — развернутое описание того, что должно получиться. Дефицитом, по их прогнозу, будет не написание кода, а точное описание намерения.
P.S. Поддержать меня можно подпиской на канал "сбежавшая нейросеть", где я рассказываю про ИИ с творческой стороны.
Комментарии (46)
Void-Cowboy
20.07.2026 22:27Ага, и нейросеть не обучали на коде самого sqlite и прочих открытых базах данных, а так же гигиайтов переписок и тематических форумов
Притом что та самая документация на 800+ станиц служила простым фактчекингом, что нейросети умеют отлично (смотрим что должно быть и подгняем под это результат). То есть такое АИ-решение максимум соотвествует только документации (и то сомнительно, на таком обьеме в мелочах будут проблемы, даже после сотни прогонов и перепроверок), но никто не говорит за оптимальность и полноценное использование всех фишек языка
EgorSharin
20.07.2026 22:27Ну, вот. Я хотел это написать, а Вы меня опередили. Поэтому, просто плюсую.
Gapon65
20.07.2026 22:27Прикольно было бы если бы модели тренировали не на существующем коде, а книгах, наподобие:
"Relational Database Design and Implementation" by Jan L. Harrington
-
Database Systems: The Complete Book
by Hector Garcia-Molina (Author), Jeffrey Ullman (Author), Jennifer Widom (Author)
Любопытно было бы посмотреть на результат :)
EgorSharin
20.07.2026 22:27Было бы интересно почитать перлы, которые этот ИИ выдавал бы.
Скорее всего, “SELECT * FROM table_name” было бы почти что абсолютным максимумом доступной ИИ мудрости.
DmitryR1974
20.07.2026 22:27Это будет следующим большим этапом развития ИИ. Современный ИИ пока что слишком маленький для того, чтобы учить его, как человека, на энциклопедиях, и на текущих вычислительных мощностях такое обучение заняло бы слишком много времени.
koreychenko
20.07.2026 22:27А почему вы думаете, что книги не попали в обучающую выборку? Проблема в том, что в обучающую выборку попало дофига всего, зачастую взаимоисключающего. Поэтому если вам необходимо следовать мудрости Танненбаума или подходам, описанным в "кабанчике", то проще эти книги проиндексировать, положить в какое-нить хранилище, вроде Obsidian и сказать модели явно, что работаем вот так.
DarthVictor
20.07.2026 22:27Код https://github.com/tursodatabase/turso скорее всего тоже был в обучающей выборке.
krote
20.07.2026 22:27Учитывая столь подробное и притом непротиворечивое ТЗ, по сути можно говорить о трансляции с человеческого языка Rust.
Впрочем подобное все-равно конечно впечатляет.Sanchous98
20.07.2026 22:27Скорее трансляции с C+документации на Rust. Уверен, что код sqlite был в обучающей выборке у каждой из моделей
uranik
20.07.2026 22:27Всё равно получилось дешевле и быстрее, чем выдать эту документацию команде сеньёров и заставить их писать проект.
alex_justes
20.07.2026 22:27Осталось только нанять команду сеньёров, чтобы написать эту самую документацию так, чтобы на выходе получился правильный и рабочий код...
Cenn
20.07.2026 22:27Очень интересная новость, но есть небольшая кучка вопросов, а именно: производительность, размер (как самого решения, так в оперативной памяти при работе), насколько полным было тестирование полученного результата (особено транзакционного механизма).
И самое главное, а пробовали внести изменения в тз, для получения новой версии (с фичей) , при сохранении совместимости хотя-бы по структуре хранения (про совместимость самого sql надеюсь говорить не надо).
kuza2000
20.07.2026 22:27А новый вариант sqllite для тестов выложен?
Dhwtj
20.07.2026 22:27https://github.com/cursor/minisqlite
100.000 строк кода если суммировать размер трейтов
И столько же непонятно чего, видимо тестов
Dhwtj
20.07.2026 22:27835 страниц ТЗ
Видимо, всё же 200.000 строк, судя по https://github.com/cursor/minisqlite
9000 строк это про какой-то кусок
9000 строк кода - контекст удержится целиком10.000-30.000$
Не впечатляет!
Разве что время решения, ради которого и создавался рой.
Dhwtj
20.07.2026 22:27И там замечание прилетело
Заголовок поста гласит, что тесты sqllogictest на 100% соответствуют заявленному стандарту . Это действительно важный шаг, но, исходя из многолетнего опыта работы над соответствием стандарту SQLite, я бы осторожно возразил против того, чтобы рассматривать это как «паритет SQLite», потому что sqllogictest и собственный набор тестов TCL для SQLite имеют совершенно разные уровни сложности , и эту разницу легко недооценить.
sqllogictest почти полностью состоит из проверок корректности строк результатов для правильно сформированных запросов .
Пакет тестов TCL для SQLite проверяет документированное поведение SQLite : точный текст сообщений об ошибках
LuciusWill
20.07.2026 22:27Прогресс. Это хорошо. Но как многие точно подметили, сама подробнейшая спека это уже почти готовый код.
Интересно посмотреть, как такие рои могли бы сами автономно разрабатывать подобные системы. Без готовых спеков.
Если они всё ещё слабы в этом, то надо прокачивать их в данном направлении.
ViashelavCz
20.07.2026 22:27А какой смысл был такого действия? Просто что бы сделать? Сомневаюсь, что кто то в обозримом будущем перейдет с sqlite на новый переписанный на rust с помощью ИИ. Дело не в rust и ИИ, а в том, что текущий sqlite проверен на сотнях миллионов разных устройств с разной архитектурой, у самого sqlite отлажены процессы, система тестирования и пр. Наверное полезнее было бы натравить ИИ на исходный код и поискать ошибки/уязвимости если они есть, хотя думаю это уже и так сделали, но возможно не нашли ни чего интересного.
wataru
20.07.2026 22:27Пиар акция. Смотрите, наши ИИ уже заменяют целую компанию (нет). Увольняйте всех программистов и отдавайте весь зарплатный бюджет нам (но его не хватит).
svl87
20.07.2026 22:27на серьезных (очень сложных) задачах с большим контекстом и на хороших моделях токены съедаются быстрее чем оплата сеньору, поэтому пока еще у программистов есть работа. все эти подписки за 20/100/200$ легко сжечь за полдня при попытке выявить редкий баг или например при реверс-инжиниринге. и не факт что будет результат, ну точнее неизвестно сколько придется еще доплатить чтоб он был
koreychenko
20.07.2026 22:27Что-то мне подсказывает, что связка сеньор + продуманная заранее архитектура приложения + внятное разделение и постановка задач + собранный под комплексную задачу harness + рой (а рой это сколько, кстати) агентов на недорогих моделях может работь лучше и дешевле, чем подход, что давайте все сбросим в модель и оно само.
fo_otman
20.07.2026 22:27Мне одному кажется странным, что ИИ изобрел технологию, которая уже изобретена? Кажется, ИИ создавали не для этого.
spirit1984
20.07.2026 22:27Две причины:
Учитывая сложности финансовые у того же OpenAI (новость), нужна любая реклама для поддержки интереса инвесторов.
Интересная исследовательская задача, на самом деле. То есть заставить рой агентов сделать уже имеющийся продукт и потом проверить, насколько он хорош. Однако проверка будет сложной, т.е. там и качество самого кода, и его производительность. Кроме того, как справедливо указали - а не были ли эти модели обучены в том числе на коде sqlite? Это же классическая ошибка ML - когда часть тестовых данных использовалась в выборке для обучения. В общем, тут пока больше вопросов к исследованию. Но сама идея вполне здравая.
wataru
20.07.2026 22:27Тут та же история, что и с браузером, написанным роем агентов? Кое как иногда работающий набор из существующих библеотек для всего подряд с абсолютно не поддерживаемым кодом?
igrishaev
20.07.2026 22:27Так надо не так тестировать. Надо брать тесты оригинального SQLite и прогонять на них. Плюс, кто не знает, у SQLite есть набор секретных тестов, которые дают особым заказчикам за деньги.
MesoPrism
20.07.2026 22:27Так пусть для чистоты эксперимента берут модель, у которой при обучении не было бы никакой входящей инфы по sqlite и посмотрю я тогда сколько времени они будут ее долбить пока результат не получат, получат ли его вообще и уложатся ли хотя бы в 100 тысяч долларов.
nidalee
20.07.2026 22:27Слушайте, ну если сеньору не дать входящей инфы и сказать - сиди пиши, тоже не факт что в 100 тысяч долларов уложитесь, не аргумент.
MesoPrism
20.07.2026 22:27В данном случае модель играет роль сеньора, который УЖЕ всё написал гораздо раньше и теперь ему надо просто повторить. И нет, при таком варианте у него никаких проблем не будет.
shy
20.07.2026 22:27Модель в обучении использовала сорці sqlite. Скорее их рой только мешал, чем помогал. Я так понимаю результат тестов от sqllogictest давались агентам - что так же візівает вопросі к чистето єксперимента.
В целом, прикольно конечно, но как по мне, єто сугубо маректинг. Задача не подьеманя для агентик девелопмента, но єто и ok. Задач такого уровня сложности будет очень мало и нет необходимости, что бі агенті их могли полностью закрівать.
simonidis
20.07.2026 22:27Самое интересное здесь — что главным фактором стала не одна «умная» модель, а организация большого объёма машинного труда и цена вычислений. Если такие рои начнут делать значительную часть экономики, вопрос собственности на инфраструктуру станет центральным. Вот хороший ролик про эту развилку и Gonka: https://youtu.be/_uwgrHV_li0?r=1058
Stingray42
20.07.2026 22:27Зачем создавать с нуля то, что уже существует и лежит в открытом доступе, да еще и за деньги?
freeExec
20.07.2026 22:27Потому что, захоти они повторить MSSQL у них бы не было ни ТЗ на 800 страниц, ни тестов, чтобы оценить результат. Только потраченных 100 тысяч баксов и кучу кода, который вроде бы запускается.
0serg
20.07.2026 22:27Если я правильно понял статью, то конечный результат был в лучшем случае "примерно 85% правильных ответов в тестах". Хотя в целом это, конечно, все равно впечатляет.
Ranlod
20.07.2026 22:27связка моделей уложилась в счет $1339 за четырехчасовой прогон
я правильно понимаю что это было самое дорогое и длительное копирование опенсорса? Модель то обучалась на нем скорее всего
corw
Я не очень понимаю, как выражение "с нуля" соотносится с документацией на 835 страниц. Это можно трактовать как угодно, но не с нуля. Кхм.
beskov
по тз — это условно с 0, тк ни одной строчки кода не было
Wesha
whoisking
А вы полагаете, что эти 835 страниц все родились то того, как была написана первая строчка кода?
Kano
Так подждите, а что на счёт публичного репозитория (на котором с большой долей вероятности обучалась бям)?
mynameco
это документация api. контракт. как без контракта/api написать код? типа вы пишите, а потом мы вам документацию вышлем.
как у нас в геймдеве. ну вы фичу пилите, а через недельку мы вам ее описание пришлем )
svl87
по сути это примерно тоже самое что переписать с какого-то legacy-языка на rust/go. такие задачи тоже нужны, но да, проработать API и логику работы и кучу всего другого что было в документации это (особенно в современном мире) даже более ценно чем сам код