ИИтог

Cockroach Labs добавила в MOLT поддержку Db2 менее чем за два дня силами ИИ-агентов

ИИ-агентыРедакция ИИтогHacker News🔥57Рейтинг ИИтог57Влияние55Новизна60Релевантность95Неожиданность60Участники35Достоверность75
Cockroach Labs добавила в MOLT поддержку Db2 менее чем за два дня силами ИИ-агентов

Cockroach Labs рассказала о пятимесячном эксперименте: компания построила конвейер ИИ-агентов MOLT Sinai, устроенный как учебная больница, и прогнала через него реальную работу над MOLT, инструментом, который компания поставляет для миграции баз данных в CockroachDB. Название, сплав MOLT и Mount Sinai (известная учебная больница в Торонто и Нью-Йорке, где живут авторы). В этой метафоре задачи на GitHub, «пациенты», слияние, «выписка», а люди, отвечающие за систему, «главные врачи» (Chiefs of Medicine).

Главный результат, по словам компании: между вечером среды и днём пятницы в апреле (год в тексте не указан) в MOLT появилась поддержка IBM Db2 как источника миграции. Для этого понадобились новый конвертер схем, новый путь Fetch (выгрузка строк и загрузка в CockroachDB), новый путь Verify (сверка после загрузки), подключённая грамматика ANTLR, Docker-образ для CI и более десяти тысяч строк тестовых данных. Когда в 2024 году в MOLT добавляли поддержку Oracle, эквивалентная работа заняла 9 месяцев и обошлась примерно в $160 тыс. затрат на инженеров. Db2 занял менее двух дней, ни одной строки кода человек не писал, а счёт за токены составил $4172: по заявлению авторов, в 164 раза быстрее и в 38 раз дешевле.

Всё началось с одной задачи (issue) на GitHub. Агент-планировщик счёл её слишком крупной и разбил на пятнадцать подзадач с явным графом зависимостей: основа, система типов, итератор строк, Fetch, Verify, Convert, CI, тестовые данные. Две подзадачи оказались слишком большими и были разбиты ещё раз; по ходу работы агенты завели ещё около дюжины задач на собственные недочёты (пробелы в тестовых данных, ошибка отображения типов, исправление уровня изоляции). К закрытию родительской задачи под ней было открыто 32 подзадачи, слито 27 pull request'ов (запросов на слияние), рецензенты возвращали работу на доработку 55 раз, девять задач были эскалированы, две из них, человеку. Покрытие тестами, по оценке авторов, оказалось равным покрытию PostgreSQL, самого протестированного диалекта в проекте.

Компания объясняет выбор модели «больницы». Её волновало не «сколько PR в час», а «сколько из этих PR нам было бы стыдно принять самим»: тонкая ошибка в инструменте миграции может испортить данные клиента. Поэтому подход, оптимизированный под пропускную способность (авторы приводят Gas Town и эксперимент Cursor с пересборкой SQLite), они сочли неподходящим и взяли модель с обязательными передачами смены и обязательными вторыми мнениями. Вся система работает на GitHub Actions: состояние «пациента» хранится в метках задачи и служебных файлах, метка «на входе» запускает этап, а метка «на выходе» становится входом следующего. Сверх этого работают агенты вне основного потока: Charge Nurse раз в тридцать минут ищет «застрявших пациентов», Infection Control останавливает все рабочие процессы, если ломается ветка main, Safety Department пишет еженедельные разборы процессов, а Research Department предлагает новую работу.

Безопасность держится на нескольких правилах, зашитых в инструкции агентов. Нет кода без плана и плана без рецензии: агент Fellow сначала воспроизводит проблему, ставит «диагноз» и публикует план лечения, а другой экземпляр агента (Review Attending), настроенный искать изъяны, одобряет или отклоняет план. «Не импровизируй»: при изменении объёма работ Fellow останавливается и возвращается к рецензии плана. Тест нельзя отключать, пропускать, ослаблять или менять, чтобы он прошёл; изменение теста, отдельный коммит с отдельным обоснованием. Застрявший агент не «давит сильнее», а пишет структурированную передачу по формату I-PASS и эскалирует выше. Discharge Nurse не пересматривает код, а проверяет, что рецензия прошла как положено: есть одобрение, заполнен шаблон, нет нерешённых веток обсуждения, CI зелёный, история коммитов чистая. Наконец, перед эскалацией к человеку агент обязан сверяться с журналом прецедентов; прецеденты создаёт только человек, и за пять месяцев это сократило число эскалаций к главному врачу.

С 21 апреля по 11 сентября в зеркальном репозитории инструментов MOLT конвейер внёс «значительно больше миллиона строк кода» небольшими порциями, которые агенты могли уверенно рецензировать. Авторы отдельно выделяют число 1299 в таблице статистики: почти половина задач в репозитории заведена самой «больницей», это дочерние задачи после декомпозиции, доработки, вынесенные Fellow за рамки плана, предложения Research Department и корректирующие действия Safety Department. Человек решает, что принять в работу, но уже со второго месяца люди перестали быть основным источником задач. После первой недели автономной работы включили «режим одобрения человеком»: каждое слияние стал просматривать человек. Уже в этом режиме система писала то, ради чего её строили, Migration Assistant, ИИ-инструмент, ведущий пользователя через полную миграцию из Postgres в CockroachDB; он сейчас в предварительной версии (preview) и почти целиком написан «работниками больницы».

Стоимость: с апреля MOLT Sinai израсходовала чуть больше $135 тыс. в токенах Claude, это около $84 на среднего «пациента» (задачу GitHub). Обычно задача проводит в «больнице» от одного до двух дней, причём основное время, ожидание ответа человека-рецензента.

Ключевые факты

  • Поддержка IBM Db2 в инструменте миграции MOLT добавлена менее чем за два дня без кода от людей; счёт за токены, $4172. Поддержка Oracle в 2024 году заняла 9 месяцев и около $160 тыс. затрат на инженеров.
  • Родительская задача разошлась на 32 подзадачи, 27 слитых pull request'ов, 55 возвратов от рецензентов и девять эскалаций (две, человеку); покрытие тестами авторы называют равным PostgreSQL.
  • Конвейер MOLT Sinai целиком работает на GitHub Actions; ключевые правила: нет кода без плана и рецензии плана, тесты нельзя ослаблять, передача по I-PASS, отдельный агент проверяет сам процесс рецензии.
  • За период с 21 апреля по 11 сентября конвейер внёс значительно больше миллиона строк кода; расход, чуть больше $135 тыс. в токенах Claude, около $84 на задачу.
  • Авторы прямо не называют систему дешёвой или простой: они утверждают лишь, что она даёт более качественный результат, чем рой агентов или одиночный агент, ценой бюрократии, ожиданий и стоимости.

Почему это важно

Большинство историй про кодинг-агентов измеряют скорость и объём кода. Здесь компания, чей продукт, база данных и инструменты миграции, строит систему вокруг качества: вопрос не «сколько PR в час», а «сколько PR нам было бы стыдно принять». Для такого результата выбраны обязательные планы, независимая рецензия, запрет ослаблять тесты и аудит самого процесса. Заявленная цифра, Db2 за менее чем два дня и $4172 против 9 месяцев и около $160 тыс. для Oracle, показывает масштаб эффекта, а описание правил, на чём, по мнению авторов, он держится.

Кому это важно

Командам, которые пробуют отдавать агентам не отдельные фрагменты, а целые функции, и ищут способ не терять в качестве. Особенно тем, кто пишет код с высокой ценой ошибки (данные, миграции, инфраструктура). Также интересно руководителям, которые считают стоимость агентной разработки: в тексте есть расход на задачу и на пять месяцев работы.

Как это применить

Из текста можно взять сами правила, а не название: перед кодом агент воспроизводит проблему и публикует план; план проверяет другой экземпляр агента, настроенный искать изъяны; тест нельзя менять ради прохождения, а правка теста, отдельный коммит; застрявший агент пишет структурированную передачу (формат I-PASS) и эскалирует; финальный этап проверяет, что рецензия состоялась по правилам, а не пересматривает код; прецеденты решений человека записываются в журнал, и агент обязан сверяться с ним до эскалации. Технически всё построено на GitHub Actions: состояние задачи хранится в метках, а метка «на выходе» запускает следующий этап. Ориентир по цене из текста: около $84 в токенах на среднюю задачу и чуть больше $135 тыс. за пять месяцев.

Можно ли доверять

Это рассказ самой компании о собственном эксперименте, независимой проверки в тексте нет. Сравнение нужно читать аккуратно: $4172, только счёт за токены и не включает стоимость создания «больницы» и время людей; $160 тыс. по Oracle, оценка затрат на инженеров, основание оценки не приведено. Показатели «в 164 раза быстрее» и «в 38 раз дешевле», формулировка самих авторов. Утверждение о равном покрытии тестами с PostgreSQL тоже авторское; данных о числе дефектов или инцидентов после слияния в тексте нет. Сам двухдневный прогон Db2 не описан как прошедший «режим одобрения человеком», его включили после первой недели автономной работы.

Риски и подводные камни

Авторы сами называют цену подхода: бюрократия, ожидания и стоимость, и подчёркивают, что система не дешевле роя агентов и не проще одиночного агента. Задача обычно проводит в системе один-два дня, во многом из-за ожидания человека-рецензента. Чтобы быть уверенными в качестве для клиентов, компания включила обязательный просмотр каждого слияния человеком. Сам Discharge Nurse нужен потому, что агенты порой делают не то, что им велено. Наконец, конвейер порождает собственный бэклог: почти половина задач в репозитории заведена самой системой, так что людям приходится решать, что принимать в работу.

«Сколько из этих PR нам было бы стыдно принять самим?»

— авторы статьи, Cockroach Labs