Чему нас учит эксперимент Cursor с SQLite и Rust
MMaximilian Schwarzmüller
Computing/SoftwareInternet Technology
Transcript
00:00:00SQLite переписали на Rust.
00:00:02И я знаю, что только что переписали Bun на Rust,
00:00:04и вы можете задаться вопросом, почему все переписывают
00:00:06абсолютно всё на Rust, но дело тут не в Rust.
00:00:09И даже не в SQLite.
00:00:11Я знаю о существовании базы данных Turso,
00:00:15которая уже является модернизированной реализацией
00:00:18SQLite на Rust.
00:00:19Именно её и стоит использовать,
00:00:21если вам нужна готовая к продакшену
00:00:23база данных SQLite на базе Rust.
00:00:26Этот же эксперимент, mini SQLite,
00:00:29ссылка на который есть ниже и с которым можно ознакомиться,
00:00:32создан не ради SQLite или Rust.
00:00:34Это эксперимент команды Cursor,
00:00:37посвящённый роям агентов, проектированию
00:00:40системы ИИ-агентов и выяснению того, что работает,
00:00:44а что нет при создании чего-то вроде
00:00:47SQLite исключительно на основе документации,
00:00:51поскольку именно в этом и заключается суть эксперимента.
00:00:53Есть суперподробная и очень интересная статья в блоге,
00:00:56и мы в неё углубимся.
00:00:57Там много ценных выводов,
00:00:59о которых стоит поговорить (ссылку вы найдёте в описании),
00:01:02где объясняется проведение эксперимента. А отправной точкой
00:01:07и замыслом было взять документацию SQLite,
00:01:12которая насчитывает 835 страниц, если собрать всё в один документ,
00:01:18и которая, разумеется, написана в первую очередь для людей.
00:01:23Это не самая простая для восприятия документация,
00:01:27но очевидно, что она предназначена для людей, ведь она появилась задолго до ИИ-агентов.
00:01:32Тем не менее она также служит невероятно подробной спецификацией,
00:01:37детально описывая, как использовать SQLite
00:01:43и каковы её предполагаемое поведение и функции.
00:01:48Команда Cursor взяла эту документацию
00:01:52и публичный набор тестов SQLogicTest,
00:01:57представляющий собой множество тестов для проверки работы SQLite
00:02:02или, если точнее, выполнения запросов.
00:02:05Они использовали его, чтобы проверить, работает ли реализация,
00:02:09созданная их агентами на основе документации,
00:02:13с этим официальным и огромным набором тестов.
00:02:19Однако сначала нужно сделать пару важных предостережений.
00:02:23Этот набор тестов предназначен только для проверки запросов и их поведения.
00:02:29Он не тестирует абсолютно все возможности и функции SQLite.
00:02:35Он не проверяет общую производительность.
00:02:38Он не тестирует параллелизм.
00:02:40В SQLite есть еще много того, что здесь не проверяется.
00:02:44А результат этого эксперимента, mini SQLite (один из результатов,
00:02:49ведь они пересоздавали SQLite несколько раз с разным составом агентов,
00:02:53и мы к этому ещё вернёмся) — это проект исключительно для изучения.
00:02:57Он не готов к продакшену.
00:02:59Использовать его в реальных задачах не стоит.
00:03:01Это лишь итог эксперимента, целью которого было взять документацию,
00:03:06воссоздать SQLite и добиться того, чтобы воссозданная версия прошла все эти тесты.
00:03:13Команда Cursor использовала здесь различные комбинации моделей.
00:03:17Почему комбинации?
00:03:18Потому что, как мы узнаем, они применили подход,
00:03:21при котором несколько агентов работали вместе: планировщики, исполнители и рецензенты.
00:03:28Они воссоздали базу данных SQLite с помощью различных комбинаций моделей и оценили их с точки зрения качества.
00:03:37Все эти связки добились аналогичного качества и процента пройденных тестов, но авторы замерили, во сколько обошлась каждая из них.
00:03:45К примеру, использование GPT 5.5 для всего — и для планировщиков, и для исполнителей — привело к стоимости реализации SQLite на Rust по документации примерно в $10 000.
00:03:59С другой стороны, комбинация Opus 4.8 с Composer 2.5 (а Composer 2.5 — это невероятно быстрая, очень дешёвая и эффективная, хотя и не самая интеллектуальная модель от Cursor) позволила достичь такого же качества и числа пройденных тестов всего за $1 300.
00:04:24Идея заключалась в том, чтобы задействовать Opus 4.8 как более продвинутую модель для планирования и проектирования задач, которые затем передавались агентам-исполнителям на базе Composer 2.5.
00:04:39И это уже один из главных выводов этой статьи, хотя идея, конечно, не абсолютно нова.
00:04:44Вы и сами можете применить такой подход при разработке ПО.
00:04:47Разумно разделять работу (в зависимости от сложности, разумеется) на отдельные задачи, выполняемые разными агентами или субагентами, где одни фокусируются на планировании,
00:05:03то есть на проектировании конкретного подэтапа в рамках общей задачи, а затем подключать других агентов, реализующих эту задачу.
00:05:14Как оказалось, для генерации качественного кода вовсе не обязательно использовать топовый интеллект, если предоставлен хороший контекст.
00:05:24То есть если задача четко сформулирована, а вся полезная информация содержится в её описании, хотя, конечно, важны и другие факторы.
00:05:33Например, имеет значение то, как выглядит окружающая кодовая база и какие примеры вы предоставляете агенту.
00:05:39Всё это влияет на результат, но агенты-исполнители, просто пишущие код, могут быть проще, если задача хорошо специфицирована и контекст качественный.
00:05:49И именно этому была посвящена большая часть эксперимента:
00:05:52как спроектировать систему, способную справиться с задачей такого масштаба.
00:05:57Ведь, как я уже упомянул, в ваших собственных проектах тоже стоит рассмотреть связку из планировщиков и исполнителей.
00:06:07Конечно, это нужно далеко не всегда.
00:06:10Если у вас быстрое исправление бага или элементарная задача, вполне достаточно просто дать указание кодинг-агенту (Codex, Claude Code или любому другому):
00:06:19“Эй, у меня тут проблема.
00:06:20Я хочу, чтобы ты сделал вот это”.
00:06:21Передайте ему дополнительный контекст и дайте сделать свою работу.
00:06:24Он может, в зависимости от платформы, запустить субагентов.
00:06:28Тот же Claude Code вполне способен на это.
00:06:31Другие среды, вроде Pi, могут этого не делать без нужных расширений.
00:06:36Но даже без субагентов с большинством задач прекрасно справляется один агент.
00:06:43Однако для более сложных проектов такое разделение труда, включая агентов-рецензентов, бывает крайне полезным.
00:06:51Лично я тоже люблю практиковать подобное,
00:06:54опять же, в зависимости от сложности задачи.
00:06:56Но само разделение ролей работает действительно отлично.
00:06:59И в этом, конечно, нет ничего кардинально нового.
00:07:02Новизна же заключается в том, что для задачи вроде переписывания SQLite запускается множество параллельных процессов из планировщиков, исполнителей и рецензентов: много исполнителей, а также несколько планировщиков и рецензентов.
00:07:18И они постоянно сталкиваются друг с другом.
00:07:19Именно к такому выводу в итоге пришла команда Cursor.
00:07:22В этой очень интересной статье
00:07:26они упоминают, что ранее в этом году уже проводили эксперимент с системой агентов, создав веб-браузер с нуля.
00:07:33И теперь они использовали ту же систему агентов для переписывания SQLite.
00:07:40Но кроме того, они построили и новую систему в качестве эксперимента, опираясь на полученный опыт.
00:07:47Затем в ходе эксперимента и в самой статье они сравнивают эти подходы и разбирают все трудности, с которыми столкнулись при настройке и запуске системы, воссоздающей SQLite.
00:07:59И одна из первых проблем, возникших при работе с системой, где одновременно трудятся сотни и тысячи исполнителей, заключалась в том, что традиционный контроль версий (Git) больше не справляется.
00:08:13Как они пишут в предыдущем посте о рое, такие инструменты, как Git и Cargo, полагаются на грубые блокировки для управления параллелизмом. Это значит, что один и тот же фрагмент данных блокируется, исключая одновременную запись несколькими источниками.
00:08:30Это нормально для одного разработчика, но совершенно неприменимо для объёма работы, производимого сотнями параллельных агентов.
00:08:36Рой, создававший браузер в начале года, достигал пика примерно в 1 000 коммитов в час.
00:08:41Это показания роя, который переписал тот браузер.
00:08:45А новая система, разработанная для этого эксперимента, достигает пика около 1000 коммитов в секунду.
00:08:52То есть у старого роя, запускавшегося ранее в этом году, было 1000 коммитов в час, что, разумеется, чуть больше, чем у большинства людей.
00:09:02Однако новая система выдавала около 1000 коммитов в секунду — это поразительно много и явно не то, для чего создавался Git.
00:09:14Что совершенно очевидно.
00:09:15«Чтобы обеспечить такую активность, мы разработали новую систему контроля версий с нуля.
00:09:21Пропускная способность была не единственной причиной создать собственный уровень.
00:09:25Каждое изменение в системе проходит через систему контроля версий.
00:09:29Поэтому коллизии впервые становятся видны именно там.
00:09:31И некоторые механизмы координации из следующего раздела реализованы прямо внутри неё».
00:09:37И это действительно интересно.
00:09:39Они построили новую систему контроля версий для эпохи ИИ-агентов.
00:09:43Потому что со старой — Git, которой мы все пользуемся, — конечно, всё в порядке.
00:09:48Просто чтобы внести ясность.
00:09:49Мы говорим об эксперименте такого масштаба и задачи, за которые многие из нас никогда не возьмутся, по крайней мере скоро.
00:09:57И всё же старая система, Git, не рассчитана на то, чтобы сотни агентов, сотни сущностей одновременно работали над одним кодом.
00:10:07Поэтому они создали новую систему контроля версий, способную справляться с безумно высокой параллельностью и помогать разрешать конфликты с помощью агентов.
00:10:19Ведь именно в системе контроля версий конфликты становятся очевидны, когда два изменения затрагивают один и тот же участок кода в файле.
00:10:28И это первый важный момент.
00:10:30Они создали совершенно новую систему контроля версий для этого эксперимента, чтобы эффективно его провести.
00:10:37Естественно, как они упоминают, на таком масштабе и при скорости в 1000 коммитов в секунду они столкнулись со множеством проблем.
00:10:48Например, и это بسیار интересно, все эти проблемы и способы их решения дают нам представление о том, как разработка ПО может выглядеть в будущем, хотя бы в некоторых сценариях.
00:11:01Проблема архитектурного расщепления (split-brain).
00:11:03«Два планировщика, не зная друг о друге, реализуют одну и ту же концепцию разными способами в разных частях кодовой базы».
00:11:10То есть дублирование: одна концепция реализована по-разному в разных местах.
00:11:16Обычно хочется вынести и переиспользовать такую логику, верно?
00:11:21«Мы исправили это с помощью промптинга».
00:11:24То есть никаких замысловатых систем, а просто грамотный промптинг.
00:11:28«Планировщики принимают ключевые решения самостоятельно, а не делегируют их.
00:11:34И мы требуем от них следить за тем, чтобы никакие два делегированных поддерева не решали один и тот же вопрос».
00:11:39Так что это вопрос настройки.
00:11:40Всё сводится к тому, чтобы при разделении системы на планировщики, исполнители и так далее, разным планировщикам (ведь параллельно работают и планировщики, и исполнители) давались чёткие задачи без пересечений.
00:12:02И начинается всё с того, как систему проектирует человек.
00:12:08То есть как ставится задача и составляются промпты, верно?
00:12:11«Мы исправили это с помощью промптинга».
00:12:13Это проходит по всему дереву агентов со всеми узлами и листьями, где нужно гарантировать: когда агенты разбивают задачи на подзадачи, в их промптах заложено сведение к минимуму вероятности накладок.
00:12:34В конечном счёте это задача планирования для человека — правильно настроить систему со своей стороны.
00:12:43Вот как они решили или попытались решить эту проблему.
00:12:47Ещё одна проблема, с которой они столкнулись, — состязательность между планировщиками.
00:12:51«Более сложная форма конфронтации — когда два планировщика знают друг о друге и воюют, переписывая одни и те же файлы.
00:12:59Проблема в том, что есть две картины реальности, и инструменты слияния не могут устранить разногласие.
00:13:04Вместо этого агенты фиксируют решения в общих документах проектирования.
00:13:08Код, зависящий от решения, содержит скомпилированную ссылку на соответствующий документ.
00:13:13Когда планировщики невольно противоречат друг другу, согласовыватель объединяет документы, и ссылки передают решение дальше».
00:13:21Возвращаясь к предыдущей мысли: даже при разделении работы между планировщиками в разработке ПО невозможно полностью избежать пересечений или общих областей кодовой базы, затрагиваемых агентами.
00:13:43И когда агенты-планировщики начинали спорить из-за реализации, проблему решили введением агента-согласовывателя (полагаю), объединяющего созданные планировщиками документы.
00:13:59Документы, подготовленные для передачи исполнителям.
00:14:02Промежуточный шаг согласования объединяет документы конфликтующих планировщиков, приходя к единому языку и единой реализации, что предотвращает дублирование кода в разных частях проекта.
00:14:21Так что эти два подхода работают в связке, насколько я понимаю.
00:14:24Естественно, они сталкивались и с конфликтами слияния.
00:14:29Планирование и устранение пересечений — важный первый шаг.
00:14:38Но даже несколько исполнителей, работающих над одним планом, с высокой вероятностью затронут одни и те же файлы и войдут в противоречие.
00:14:50Есть множество других воркеров, которые не будут следить за тем, чтобы не брать одинаковые файлы.
00:14:55Поэтому они не избегут работы с теми же файлами.
00:14:57Из-за чего пересечения неизбежны.
00:14:58«Чтобы разрешить коллизию, им пришлось бы остановиться, усвоить контекст другого агента и выполнить слияние».
00:15:03Естественно: если два агента (или человека) меняют один файл, для разрешения конфликта им нужно остановиться и найти общее решение,
00:15:19реализацию, устраняющую конфликт.
00:15:23«Однако агенты-исполнители плохи в этом и на практике либо перезаписывают чужие правки, либо бросают свои».
00:15:29Возможно, вы тоже это замечали.
00:15:31Я — точно.
00:15:32Если вы работаете над кодовой базой вместе с ИИ-агентами и вносите правку...
00:15:38Да, знаю, страшно, но писать код всё ещё можно.
00:15:40Допустим, вы внесли изменение.
00:15:42Что-то поменяли в коде.
00:15:44Агент просто отменит и перезапишет это.
00:15:48Он не уважает чужие правки.
00:15:50У него есть своя задача.
00:15:52И если он решил отредактировать данный файл, он это сделает.
00:15:57Ему плевать, что вы тем временем успели изменить.
00:16:01Ситуация немного меняется, если закоммитить правку, так как агенты обучены не отменять коммиты бездумно.
00:16:13Но если правки не закоммичены, воркеру просто всё равно.
00:16:17Агенту всё равно.
00:16:19И именно с этим столкнулись авторы.
00:16:21«Чтобы решить это, мы создали систему, где нейтральный сторонний агент вмешивается при конфликтах слияния и разрешает их от лица всех сторон.
00:16:29Его единственная цель — быть беспристрастным и эффективным, по аналогии с очередями слияния в командах разработки».
00:16:35И я думаю, это тоже очень интересно.
00:16:38Это снова форма согласования.
00:16:41Опять же, как я понимаю, речь идет об остановке этих агентов — как и раньше, когда нужно было сделать шаг назад и найти
00:16:49решение для конфликта.
00:16:51Но что это четко показывает (и это не новое открытие), так это то, насколько невероятно важен чистый контекст с правильной информацией.
00:17:03Решаете ли вы масштабную задачу вроде Cursor, или работаете над небольшим проектом,
00:17:12главное преимущество разделения на планировщиков, исполнителей и рецензентов — это работа с чистыми окнами контекста.
00:17:24Это не значит, что контекст пуст.
00:17:26Это значит, что у вас есть новые сессии агентов, наполненные ровно тем контекстом, который нужен для конкретной задачи.
00:17:33Например, исполнитель плохо проверяет свою работу, так как в его контекстном окне уже есть весь процесс реализации.
00:17:41Он предвзят, если можно так выразиться.
00:17:44Поэтому агент-рецензент должен начинать с чистого окна, получая информацию о задаче, плане и затронутых файлах — и ничего лишнего.
00:17:55Чтобы он мог честно оценить работу.
00:17:59Вот почему свежие окна контекста с правильным наполнением так важны.
00:18:04И то же самое произошло здесь: они разрешали конфликты слияния с помощью нового агента с точечным контекстом и без предвзятости.
00:18:17Затем, полагаю, система передавала исполнителям указание не перезаписывать это решение, либо запускались новые агенты.
00:18:30Здесь это описано не до конца понятно.
00:18:32Другой проблемой стали «мегафайлы».
00:18:35«Некоторые файлы становятся излюбленными местами работы агентов.
00:18:39Каждый агент может добавить лишь немного кода, и ни один не отвечает за то, чтобы файл оставался небольшим.
00:18:45Эти мегафайлы перегружают всё задействованное окружение.
00:18:49Их дорого передавать, сравнивать и сливать, и они становятся очагами постоянных коллизий».
00:18:54С этим вы тоже могли сталкиваться, пусть и на гораздо меньшем масштабе.
00:19:00Я — точно.
00:19:01Одна из вещей, с которыми мы имеем дело.
00:19:02Особенно что касается тестирования.
00:19:03По моему опыту, агенты просто обожают добавлять всё больше и больше тестов в один и тот же файл.
00:19:08И дело, конечно, не только в тестах, но это та сфера, где я вижу подобное чаще всего.
00:19:13Особенно когда у вас работают несколько агентов, и у каждого из них своя задача.
00:19:18Им всё равно, потому что они не люди.
00:19:21Да и как их вообще может что-то волновать?
00:19:23Они просто выполняют задачи, верно?
00:19:24Их не волнует ни размер файла, ни общая архитектура системы.
00:19:30Если у вас есть куча агентов, просто исполняющих свои инструкции, ваша кодовая база рано или поздно погрузится в хаос.
00:19:37Потому что агентам всё равно.
00:19:39Их волнует только выполнение своей конкретной задачи.
00:19:42И эти мегафайлы, разумеется, выступают четким индикатором данной проблемы.
00:19:48Они неизбежно появляются, чем больше агентов работает в вашем проекте на протяжении долгого времени.
00:19:55Среди них нет агента, который отвечал бы за разбиение файла или поддержание хорошей архитектуры.
00:20:02Это просто не входит в их задачи.
00:20:04Чтобы исправить это, мы дали рабочим агентам возможность помечать разросшиеся файлы.
00:20:09Как только файл помечен, мы блокируем новые коммиты, и сторонний агент разбивает раздутый файл на более мелкие модули.
00:20:16То есть снова привлекается чистый агент.
00:20:19И этот паттерн прослеживается везде.
00:20:21Для всех этих проблем суть сводилась к выявлению неполадки и вызову свежих агентов с нужной задачей
00:20:28и правильным контекстом для её устранения, чтобы затем остальные агенты могли продолжить работу.
00:20:35То же самое сработало и в случае с мегафайлами.
00:20:38Закостенение кода — ещё одна проблема, с которой они столкнулись.
00:20:40Работая в существующих кодовых базах вместе с людьми,
00:20:44агенты научились не трогать ключевой код, даже если его необходимо изменить.
00:20:48И это не совсем то, о чём я говорил раньше,
00:20:50когда вы вносите правку в файл, над которым работает агент, и он её просто выбрасывает.
00:20:55Здесь речь идёт о ситуациях в целом.
00:20:57У агента есть чёткая задача, основанная на плане и вашем промпте.
00:21:03И это, естественно, предполагает изменение определённых файлов.
00:21:07И вот что мы уже знаем или видим каждый день при работе с агентами: в зависимости от модели,
00:21:16некоторые из них очень неохотно отказываются от существующего кода.
00:21:21Они скорее добавят 10 запасных вариантов, 10 проверок «if» и ещё больше устаревшего кода, вместо того чтобы удалить его и навести порядок.
00:21:31Вам приходится явно прописывать в промпте, чтобы агент действительно удалил функцию или избавился от какого-то файла.
00:21:39Сами по себе они этого не делают из-за тонкой настройки, ведь провайдеры очевидно не хотят создавать модели,
00:21:47которые будут бесконтрольно хозяйничать и ломать продакшен-код.
00:21:50Но если вы работаете не над существующим проектом и не над кодовой базой, которая уже работает в продакшене,
00:21:57то эта склонность не трогать код и хранить всё вечно может стать крайне проблемной и раздражающей.
00:22:05Она также приводит к побочным эффектам, как в данном случае: агенты просто не улучшали код, написанный другими агентами,
00:22:16а лишь достраивали что-то сверху раз за разом, что в итоге, конечно же, приводило к раздуванию кодовой базы.
00:22:23Чтобы решить эту проблему, мы разрешили намеренные нарушения.
00:22:27Агент, посчитавший изменение в ядре целесообразным, может сделать точечный патч за пределами своей зоны ответственности и оставить комментарий с объяснением.
00:22:36И это снова то, что вы в меньшем масштабе можете применять и в своих проектах — именно так делаю я.
00:22:41Нужно прямо разрешить и сказать агентам: «Эй, мы только разрабатываем этот проект».
00:22:46«Мы на ранней стадии разработки».
00:22:48«Проект ещё не запущен».
00:22:49«Мне нужны кардинальные изменения».
00:22:51«Так что смело чистите код».
00:22:54«Рефакторинг только приветствуется».
00:22:56И всё в таком духе.
00:22:58Вам нужно подталкивать агентов и эти ИИ-модели, переопределяя инструкции их тонкой настройки.
00:23:04То есть обойти их встроенные ограничения, чтобы они действительно могли развивать кодовую базу, а не просто накапливать код.
00:23:14Опять же, это то, что мы видим в меньшем масштабе, но здесь показано масштабно.
00:23:19Что касается ревью, они использовали подход под названием «линзы рецензирования».
00:23:24Итак, у нас есть агенты-планировщики и агенты-исполнители, но их работу нужно проверять, чтобы ставить новые задачи и repeating цикл, пока баг не будет исправлен или код не станет лучше.
00:23:38В долгоживущей многоагентной системе ошибки накапливаются, и рою нужен способ самокоррекции, пока мелкие промахи не стали системными.
00:23:47И это снова логично.
00:23:48Мы все сталкивались с этим и в меньших масштабах.
00:23:50Мы экспериментировали с разной фокусировкой ревью: давали агенту-проверщику полный транскрипт исполнителя, только его результат или вообще ничего, кроме кодовой базы.
00:24:00Мы также пробовали ревьюеров на разных моделях с разным обучением и разным «характером».
00:24:05Ни одна линза не замечает всё, но комбинация линз дает сложение эффекта — точно так же системы автопилота превосходят человека по надежности без идеальных компонентов.
00:24:16Затраты ресурсов на ревью высокоэффективны, так как проверка обходится гораздо дешевле самой работы.
00:24:21Мы полагаем, что эта многоуровневая система ревью стала главным фактором стабильно высокого качества прогонов.
00:24:28Главный вывод отсюда:
00:24:30невозможно заставить одного или нескольких агентов-ревьюеров полностью проверять всю кодовую базу.
00:24:39Это слишком большой объём.
00:24:41Вместо этого они пробовали разные подходы: передавали полный транскрипт, только итоговый вывод или только саму кодовую базу.
00:24:47И в итоге они выяснили, что лучше всего помогает использование разных ревьюеров с разными ролями и узкой специализацией на отдельных аспектах.
00:25:00Им дают кодовую базу, насколько я понимаю, и, возможно, некоторую информацию о том, что сделал рабочий агент.
00:25:06И именно комбинация результатов от нескольких проверяющих давала общий итог, который затем снова подхватывался планировщиком для составления плана исправления кода.
00:25:23И опять же, в меньшем масштабе, я думаю, это то, что мы тоже можем применять.
00:25:28Понятно, что мы не строим системы такого уровня.
00:25:34Но по моему опыту, отлично работает наличие нескольких агентов-ревьюеров с разными задачами, где один проверяет, насколько код идиоматичен для Rust,
00:25:46другой фокусируется на производительности и безопасности, если настройки позволяют,
00:25:51третий проверяет стандарты наименования, если это важно, и так далее.
00:25:58То есть у вас есть разные «линзы», и вы даёте этим проверяющим строго необходимый контекст.
00:26:03Например: «Эй, агенты работали над этой фичей».
00:26:07Можно передать им план исполнителя и краткую информацию о его шагах, но не более того.
00:26:15Затем вы собираете отзывы всех ревьюеров и объединяете их, возможно, с помощью ещё одного агента.
00:26:22Мне также нравится идея ставить ревьюера для проверки самих результатов ревью, потому что модели любят находить проблемы везде.
00:26:36Какой бы код им ни дали, даже в одну строчку,
00:26:40мне иногда кажется, что они найдут там пять замечаний.
00:26:43Поэтому наличие агента, который классифицирует замечания и отсеет ложные, на мой взгляд, работает بسیار эффективно.
00:26:55И именно такая комбинация и каскад ревьюеров помогают получать качественные результаты для последующего внедрения.
00:27:06Конечно, всё зависит от масштаба вашей задачи и разрабатываемого ПО.
00:27:11Очевидно, для большинства программ это избыточно сложно, но это отличная возможность взглянуть на то, как может выглядеть инженерия и подобные системы в будущем, что лично мне кажется невероятно интересным.
00:27:27И последнее, что они сделали — позволили агентам формировать рабочую среду.
00:27:32Идея заключалась в том, чтобы дать агентам написать полевое руководство — по сути, документ или набор документов, где им не давали никаких инструкций, кроме того, что этот гайд должен служить контекстом для общей задачи, благодаря чему агенты могли формировать общую память с выводами и ключевыми решениями.
00:28:00Таким образом, у агентов была эта дополнительная система памяти для ведения заметок и документирования решений.
00:28:10В целом, как и в случае с переписыванием BUN на Rust, я нахожу этот эксперимент очень захватывающим.
00:28:16Это может и пугать.
00:28:17Я прекрасно это понимаю.
00:28:18И не стоит делать вывод, что отныне всё ПО должно создаваться именно так.
00:28:24Во-первых, это пока даже не готовый к продакшену продукт.
00:28:28И доведение его до продакшена наверняка потребует немало времени.
00:28:33Не стоит недооценивать этот момент.
00:28:35Нельзя просто собрать нечто подобное за пару часов и думать, что доводка до ума займет ещё немного.
00:28:43Первые 80% достигаются гораздо быстрее, чем оставшиеся 20%.
00:28:48Все мы это знаем.
00:28:49Так что это один из важных выводов.
00:28:51Также важно понимать, что для задачи по переписыванию SQLite агенты получили документацию и готовый набор тестов.
00:29:04Но очевидно, что здесь имелась невероятно подробная спецификация, чего никогда не бывает в новых проектах.
00:29:13Создавая новое ПО с нуля, у вас нет настолько детализированных спецификаций, как документация к проекту с 20-летней историей.
00:29:24И даже если агентам дали только документацию, исходники SQLite и аналогичные реализации (вроде Turso на Rust) почти наверняка входили в обучающие данные большинства использованных моделей.
00:29:46Так что для этих моделей задача не была абсолютно новой.
00:29:51Это совсем не то же самое, что разработка совершенно нового продукта, где итерации — важнейшая часть процесса.
00:29:58Вам будет очень сложно, и я бы даже сказал невозможно, создать новое ПО с нуля — что бы это ни было — так, чтобы оно постоянно не менялось.
00:30:11Потому что нельзя написать идеальную спецификацию заранее и на этом успокоиться.
00:30:17Вы всегда находите что-то новое или хотите внести изменения во время разработки, вне зависимости от масштаба.
00:30:26И поэтому, конечно, этот случай не отражает то, как ПО должно создаваться в целом.
00:30:34Тем не менее, это крайне любопытный эксперимент.
00:30:37Это очень интересный эксперимент, и он содержит ключевые выводы, важные для всех нас.
00:30:43Эти выводы не новы — например, декомпозиция задач и использование чистых окон контекста со строго нужной информацией.
00:30:50Интересны мысли о том, что в будущем могут появиться и потребоваться совершенно новые системы контроля версий.
00:30:57И, разумеется, то, что многоагентная оркестрация становится трендом.
00:31:01Всё это доказывает, что роль человека в проектировании таких агентных систем и принятии архитектурных решений остается ключевой.
00:31:21Составление спецификаций, проработка архитектуры, создание агентных систем для реализации и последующий ревью — вот что действительно важно.
00:31:33Именно к этому мы движемся, и хотя это сильно отличается от разработки шестилетней давности, меня это очень вдохновляет.
00:31:45Здорово, что мы переходим к системному мышлению — как при создании агентных систем, так и при проектировании архитектуры ПО.
00:31:59И затем объединяем оба этих подхода.
00:32:01Я нахожу подобные эксперименты невероятно увлекательными.
00:32:04Выводы из них действительно ценны.
00:32:07И некоторые из этих идей в более простом масштабе вполне применимы к повседневным проектам разработки.
00:32:17Но как всегда, делитесь своим мнением и пишите, что вы думаете о подобных экспериментах.