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. Поддержать меня можно подпиской на канал "сбежавшая нейросеть", где я рассказываю про ИИ с творческой стороны.
Комментарии (69)
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Это будет следующим большим этапом развития ИИ. Современный ИИ пока что слишком маленький для того, чтобы учить его, как человека, на энциклопедиях, и на текущих вычислительных мощностях такое обучение заняло бы слишком много времени.
Pubert
20.07.2026 22:27На самом деле, зря заминусили. Я себе так и представляю развитие нейросетей. Представьте: модель сама читает книгу, сама по ней ТРЕНИРУЕТСЯ, то есть сама себе генерирует обучающие данные по теоретической базе
Правда, для этого моделям нужно добавить воображение, способность самом себе ставить задачи и цели, реализовать сознание...)) утрирую, конечно, но это тот самый недостижимый AGI
koreychenko
20.07.2026 22:27А почему вы думаете, что книги не попали в обучающую выборку? Проблема в том, что в обучающую выборку попало дофига всего, зачастую взаимоисключающего. Поэтому если вам необходимо следовать мудрости Танненбаума или подходам, описанным в "кабанчике", то проще эти книги проиндексировать, положить в какое-нить хранилище, вроде Obsidian и сказать модели явно, что работаем вот так.
DarthVictor
20.07.2026 22:27Код https://github.com/tursodatabase/turso скорее всего тоже был в обучающей выборке.
dimaaannn
20.07.2026 22:27Ну в целом, оптимизацию можно считать уже следующим этапом. Суть ведь не в том чтобы похвастаться "мы написали еще один sqlite" - а в том что выполнение огромного количества непротеворечивых бизнес требований технически может быть реализовано с не такими уж большими затратами.
Думаю если натравить нейронку на результат работы - то она сможет оптимизировать бенчмарки. Хотя стоимость будет сильно выше, конечно же.
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Осталось только нанять команду сеньёров, чтобы написать эту самую документацию так, чтобы на выходе получился правильный и рабочий код...
ViashelavCz
20.07.2026 22:27Нужно определиться с тем что мы хотим, если просто переписать, сделать публикацию и забыть то конечно ИИ дешевле, если же мы хотим сделать новый продукт на Rust-е, поддерживать его и откусить какую то часть рынка, то с одним ИИ не получиться долго продержаться, нужны сеньёры которые будут разбираться с кастомеровскми ишуями, которые будут развивать продукт и т.д. ИИ может помочь команде сеньёров побыстрее написать код, но потребность в этой команде ни куда не денется.
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 строк кода если суммировать размер трейтов
И столько же непонятно чего, видимо тестов
Wesha
20.07.2026 22:27Открыл случайный файл.
Строки 1-106 — код.
Строки 106-227 — тесты.Тесты порадовали.
assert!(trunk_leaf_count(&[0, 0, 0, 0]).is_err()); assert!(trunk_leaf_count(&[0, 0, 0, 0, 0, 0, 0]).is_err()); assert!(trunk_leaf_count(&[0, 0, 0, 0, 0, 0, 0, 0]).is_ok());(А где тесты для случаев 1, 2, 3, 5, 6, 9, 10,.... 100500 элементов, я вас спрашиваю?) /s
Закрыл случайный файл.
Sap_ru
20.07.2026 22:27Там везде так. Но ладно тесты: я открыл штук 20 файлов - там ужас. На первый взгляд всё нормально, но если вчитаться и представить, что это коммерческий проект... Это тупо неподдерживаемый код.
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 : точный текст сообщений об ошибках
Sap_ru
20.07.2026 22:27У них по графикам максимум 85% тестов пройдено. Про 100% там слова без указания, времени стоимости и условий. Все цены, это за 60..85% тестов. Причём самый простых тестов, похоже.
LuciusWill
20.07.2026 22:27Прогресс. Это хорошо. Но как многие точно подметили, сама подробнейшая спека это уже почти готовый код.
Интересно посмотреть, как такие рои могли бы сами автономно разрабатывать подобные системы. Без готовых спеков.
Если они всё ещё слабы в этом, то надо прокачивать их в данном направлении.
Pubert
20.07.2026 22:27Тут вопрос направления развития: как инструмент, или как замена программистам. Cursor видимо выбрали первое
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 + рой (а рой это сколько, кстати) агентов на недорогих моделях может работь лучше и дешевле, чем подход, что давайте все сбросим в модель и оно само.
foggy-f
20.07.2026 22:27Извините, не удержусь:
так и запишем синьер+архитектура,написаная синьером+постановка задач синьером+собраный синьером харнес+рой агентов(а сколько, кстати это в джунах?) может работать лучше и дешевле чем все это без синьеров.
Согласен на все 100
svl87
20.07.2026 22:27Увы или к счастью, но пока нет, область применения недорогих моделей очень ограничена (типа сортировки почты, всяких комментов в соцстеях или написание hello-world'а). Когда даешь сеньору простенькую модель и случаются галлюцинации уровня чатгпт 3 года назад, возникает лишь желание выбросить это всё и не тратить время на разбор нейромусора
Если собрать рой из дипсиков (как раз та самая недорогая модель), то получается не сильно лучше одно дипсика
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В данном случае модель играет роль сеньора, который УЖЕ всё написал гораздо раньше и теперь ему надо просто повторить. И нет, при таком варианте у него никаких проблем не будет.
nidalee
20.07.2026 22:27Вы по тем же докам за год перепишете sqlite с нуля на расте?
Sap_ru
20.07.2026 22:27Напишу, кстати. Только вам результат не понравится :) Но тесты проходить будет. Возможно, что даже ничего кроме прохождения тестов делать не будет, ну кроме простейших операций.
И внутрь их результата тоже не нужно заглядывать - этот код не поддерживаем и нерасширяем. Это будут 100к выброшенные на ветер.А за $20k (как в описанном эксперименте) я вам наверное даже те же 60..85% прохождения тестов запилю за пару месяцев. Только, чур, я выбираю, какие именно тесты проходим для набора нужного процента (всё честно - всё, как у них в эксперименте).
Это я к тому, что у них стоимость приведена до уровня 60..85% успешных тестов, а не до 100% ;)
Sap_ru
20.07.2026 22:27Они и на этих не уложились. Цены указаны не до 100% прохождения, а до 60..85%, в зависимости от модели. Там не написано, сколько времени и денег стоило довести до 100%. Как и не написано, что для этого потребовалось. Написано лишь, что "в дальнейшем Fable 5 смогла достичь 100% прохождения тестов".
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 тысяч баксов и кучу кода, который вроде бы запускается.
Ranlod
20.07.2026 22:27связка моделей уложилась в счет $1339 за четырехчасовой прогон
я правильно понимаю что это было самое дорогое и длительное копирование опенсорса? Модель то обучалась на нем скорее всего
fillrate
20.07.2026 22:27рой ИИ-агентов Cursor создал SQLite с нуля за $1339
Не совсем с нуля. Есть огромная разница, сделать миграцию существующего ПО (документация, годы бакфиксинга, куча правок архитектуры и т.д.) и написать что-то новое. Причем не просто написать, а потом еще и поддерживать, внося изменения.
К тому же, почему-то не учитывается зарплата операторов ИИ-агентов, т.е. кто им ставил задачу, кто все это настраивал, возможно правил скилы ведь большая часть подобных экспериментов - это узкоспециализированный паттерн, а не универсальная dark factory.
Ну и последнее. А сколько потратили ресурсов на верификацию того, что сделали агенты? Допустим, агенты написали все за 4 часа и потом в этой писанине 10+ синьоров месяц разбирались и проверяли на читинг?
Очень интерсно было б посомтреть на статистику затрат по исправлению багов. Т.е. через месяц в продукте обнаруживается баг (запрос корректный, результат нет), то сколько будет стоить его подправить? Не придется ли перечитывать/переписывать большую часть кода за сопоставимый с "написанием с нуля" бюджет?
Но в общем если отобросить бестолковый кликбейт и маркетинг, это отличные потенциальные возможности для ускорения написания кода под контролем профессионального инженера.
Sap_ru
20.07.2026 22:27Да, и не создал... Стоимость указана до 60..85% прохождения тестов. Сколько потрачено до 100% они не сказали. Ну и код там тоже ужасный.
b_vova
20.07.2026 22:27Не мог пропустить эту новость т.к. пилю свой однофайловый SQL движок (один файл БД и один файл бинарника). Не планировал так быстро выкладывать, но тут появился крутой инфо-повод. Уже многое готово и весь мой бюджет это несколько месяцев на pro аккаунте в claude.
Вся база хранится в одном файле .fdb - как в SQLite. Можно подключиться как к настоящей PostgreSQL или MySQL, надо просто сменить порт. Значимые фишки во встроенном web-ui: дашборды, парсер из разных источников, AI агент которые помогает работать с sql командами.
PVZon
20.07.2026 22:27Я вот тоже сомневаюсь, что прямо с нуля. Какие-то исходники должны же быть. Если модель обучения ИИ аналогична с человеческой (что прям так логично), человек же без изучения, к примеру литературы (хотя бы базовых принципов) не сможет ничего. Почему ИИ должен смочь без базы?
Sap_ru
20.07.2026 22:27Ха! Очередной маркетинговый вброс. Кроме того "научность" этой статьи такова, что в любом серьёзном сообществе их бы ссаными тряпками гнали.
1. Фактически получился непредсказуемый результат. Причём, как в финансовом плане, так и буквально: вы не можете заранее предсказать, сколько потратите $1500 или $20'000.
То есть магия, зависящая от каждого конкретного случая и элемента везения. Даже результаты одной и той же сети сильно зависят от шаманизма с конфигурацией.
Кроме того авторы запускали тесты несколько раз и показали только успешный результат. Сколько там было сожжено токенов в ходе опытов мы не знаем, но, скорее всего, в разы больше
Интересно так же и то, что даже в пределах одной и той же ИИ в размер исходников результата отличался более чем в 6 раз!!! И заранее этого предсказать нельзя.
Но это наименьшая из претензий, так как именно это они и проверяли.
Тем не менее с точки зрения реального бизнеса практический результат именно такой - максимальная финансовая непредсказуемость и непредсказуемость результатов.
То есть ничего нового.
2. Результат получился более чем странный (ужасный результат!) - достаточно даже просто бегло глянуть на "тесты", которые ИИ нагенерировал. Там многие тесты именно, что в кавычках - они ничего не проверяют или проверяют одно и то же.
Кроме того я заглянул в несколько случайных файлов - ну нейрослоп/индусокод же!
- Файлы, содержащие одни объявления, и не имеющие смысла;
- Монстрические switch в критических частях кода;
- Файлы из 10 строк не имеющие кода, зато имеющие супер-громкие названия.
- Комментарии длиннее кода, которые ничего не объясняют и/или содержат ошибки.
- Массовые ошибки в именах в комментариях: например, в комментариях имена для членов enum отличаются от реальных имён членов, которые они описывают - чистая галлюцинация! Это просто трындец же! Это даже хуже просто неправильного когда или полного отсутствия комментариев! Чтобы эти вайбкодеры всегда только с таким кодом и работали!
- Очень странная структура кода: 20 строк комментариев, которые описывают три строки, которые и так понятны. Причём иногда ещё и с ошибкой описывают.
- Очень плохое разбиение на функции - повсеместно какие-то сложные if, разбитые по функциям совершенно произвольным образом.
Про тесты я уже говорил - там минимум половина тестов липовый нейрослоп.
Этот код невозможно читать и поддерживать - его нужно брать и руками процентов на 60% перелопачивать, включая комментарии! И это я только очень бегло глянул!
Ясное дело, что у них на таком коде геометрически сложность изменений росла!
И это при том, что результат контролировался, а управляли всем лучшие специалисты в своей области.
То есть галлюцинации никуда не делись и внутрь этого шедевра лучше не заглядывать. Успехов всем те, кто вот так пытается коммерческий продукт создать.
3. У них на графиках отсечка идёт на максимум на 85% успешных тестов. При это количество новых успешных тестов уменьшается со временем. 85% (максимум!) успешных тестов это мало, так как наверняка последние непройденные тесты и содержат самую сложную логику, а разбор синтаксиса SQL и работа со строками, это не интересно и банально.
4. Все нейросети к своему максимальному проценту тестов приближались асимптотически . То есть цена разработки росла логарифмически! Последние 15..25% сожгут во много раз больше, чем вся предыдущая разработка. Именно поэтому они обрезали графики именно на этом месте. Это чистая манипуляция!
5. Геометрический рост сложности и стоимости показывает, что архитектура результат была стабильно неудачной - нейройсетям приходилось раз за разом переписывать заново всё бОльшие части проекта ради каждого нового теста. И эта ситуация не менялась, то есть архитектура результата не улучшалась, а оставалась стабильно плохой и не масштабируемой (но позволяющей пройти ещё несколько новых тестов).
Более того, даже самая продвинутая LLMв какой-то момент "застраяла" - количество успешных тестов стало уменьшаться. Причём дальнейшего графика авторы не опубликовали - снова манипуляция.
Вот именно на это и нужно обращать внимание при прогнозировании разработки в реальных проектах.
На реальном проекте даже в самом успешном случае вот это всё кончилось бы катастрофой и неподдерживаемым кодом с плохой архитектурой, который не смог бы пройти все тесты.
6. Почему вся эта статья вообще должна пойти в топку, а авторы - в ад:
Они утверждают, что их лучшая конфигурация достигла 100% прохождения тестов. Но цифры все приводят только для уровня максимум 85% успеха! Это, напомню, при экспоненциальном росте расхода токенов!
Сказано лишь, что "в дальнейшем сети удалось достичь 100% прохождения тестов".
Когда "в дальнейшем"? Во сколько это обошлось? Было ли вмешательство человека в ход эксперимента?
Судя по тому, что никакой информации не дали что-то из этого точно нельзя называть. Более того, ещё раз обращаю внимание, что даже в варианте с топовой моделью количество успешных тестов в какой-то момент начало снижаться.
С точки зрения практики там ОЧЕНЬ странный результат: всё выглядит так, как будто длительность графиков подбирали под такую, чтобы показать преимущество последней сети, но при этом не показать какой-то катастрофы на последних этапах разработки! Формально по их графикам выходит, что прогон самой успешной Fable 5 закончился полным провалом с 64% успешных тестов, зацикливанием и двойным расходом токенов относительно Opus 4.8! Но при этом утверждается, что именно Fable 5 сумела достичь 100% прохождения тестов.
Что за маркетинговая дичь?!
Именно поэтому, эта статья не имеет смысла - это не "написали SQLite" за $1500, а "написали нечто с плохой архитектурой и кучей ошибок за случайную сумму в диапазоне от $1500..20'000, а потом неизвестным способом за неизвестное время и деньги получили 100% прохождения тестов".Добавлено:
Посмотрел на код более детально... Да это просто ужас ужасный - идите обратно в свой лес, черти рогатые! Там реально крыша едет на первых пяти минутах анализа архитектуры.
На первый взгляд кажется, что всё прилично, но потом выясняешь, что даже по дереву исходников уже какая-то катастрофа: всё, вроде, прилично так разложено и названо, а потом читаешь и понимаешь, что некоторые файлы просто в случайных местах находятся, а названия имеют очень опосредованное отношение к содержимому! Плюс куча каких-то ненужных абстрактных прокладок (зато каждая в своём файле!), из-за которых категорически непонятно, что с чем работает. Ощущение, что код писал сумасшедший студент, который вусмерть напился, отмечая прочтение очередного трёхтомного толмуда об идеальном коде.
corw
Я не очень понимаю, как выражение "с нуля" соотносится с документацией на 835 страниц. Это можно трактовать как угодно, но не с нуля. Кхм.
beskov
по тз — это условно с 0, тк ни одной строчки кода не было
Wesha
whoisking
А вы полагаете, что эти 835 страниц все родились то того, как была написана первая строчка кода?
Kano
Так подждите, а что на счёт публичного репозитория (на котором с большой долей вероятности обучалась бям)?
Dhwtj
У неё не бесконечная память и весь код она не вызубрит
mynameco
это документация api. контракт. как без контракта/api написать код? типа вы пишите, а потом мы вам документацию вышлем.
как у нас в геймдеве. ну вы фичу пилите, а через недельку мы вам ее описание пришлем )
svl87
по сути это примерно тоже самое что переписать с какого-то legacy-языка на rust/go. такие задачи тоже нужны, но да, проработать API и логику работы и кучу всего другого что было в документации это (особенно в современном мире) даже более ценно чем сам код