Привет, Хабр! Вот и пришло время выпустить продолжение статьи про то, как мы писали свой RAG! Итак, новый поиск и индекс для нашего ИИ-ассистента мы написали за три дня вместе с Claude Code. Агент генерировал код, а мы по ходу просматривали каждое изменение. А чтобы кто-то в команде смог за этот код отвечать, понадобилось ещё три недели. Знакомая история? Агенты здорово ускорили первую половину работы, когда код пишется, а вот вторую, когда его надо прочитать, понять и взять на себя, почти не тронули.

Мы — команда Джеймикс. Джеймикс — open-source платформа с ИИ-инструментами для стандартизации разработки корпоративных Java-приложений. В первой части мы рассказали, как перестраивали поиск нашего ИИ-ассистента. Если коротко, ассистент перед ответом ищет подходящие фрагменты документации в векторной базе. Мы добавили туда карточки классов из Javadoc и разрезали документацию на законченные укороченные нейрослоп-примеры. Весь этот набор фрагментов в базе дальше называем корпусом. А ещё собрали контур оценки: 74 контрольных вопроса, ответы на которые автоматически проверяет модель-оценщик и ставит каждому балл. В конце первой части мы пообещали рассказать, «как этот поиск за три дня написал Claude Code и почему ревью и правки заняли три недели». Обещание выполняем.

Код первого рабочего варианта генерировал Claude Fable 5, а отдельные куски потом независимо перепроверял GPT-5.6 Sol (дальше просто Sol). Дифф вышел на 122 файла и почти 15 тысяч строк. Сам бэкенд ассистента — это приложение на Jmix 2.8: сущности, экраны, роли и миграции Liquibase. Рассчитывали мы на два-три дня ревью. Агент под рукой, его можно спросить про любое решение. Чёрным ящиком код для нас не был, каждое изменение мы видели. Но просмотреть дифф и понять его настолько, чтобы за него отвечать, оказалось разными вещами. В итоге почти три недели ушли на чтение, исправления и повторные проверки. Код работал, но выпускать его мы не спешили: пока в нём не разобрался человек, чинить его при первом баге было бы некому.

Для себя мы описали эту историю как два таймера. Первый идёт, пока не появится рабочий вариант кода. Второй — пока в команде не появится человек, который понимает этот вариант настолько, чтобы отвечать за него по памяти. Первый таймер у нас остановился за три дня. Со вторым всё сложнее.

Ниже прикинем, сколько кода человек вообще способен прочитать, и покажем, где у второго таймера финиш и куда ушли наши три недели. Посмотрим, как с этим справляются в Anthropic и OpenAI, и расскажем о шести практиках, по которым мы теперь работаем, чтобы второй таймер запускался раньше. В конце — где эти практики не помогают.

Сколько кода человек успевает прочитать

Начнём с самого простого предположения. Может, второй таймер ускоряется так же, как первый, и надо просто читать быстрее?

Данные о скорости чтения кода появились задолго до агентов. В середине 2000-х SmartBear вместе с Cisco разобрала около 2500 ревью и 3,2 млн строк за десять месяцев. А на странице с рекомендациями SmartBear сводит выводы так: за один подход стоит смотреть 200–400 строк, на это уходит 60–90 минут, и так находится 70–90% дефектов. Если гнать быстрее 500 строк в час, доля найденного резко падает. В правилах ревью Google жёсткой планки нет, но около 100 строк там считают разумным размером изменения, а около 1000 — как правило, уже слишком большим.

Мы приложили эти цифры к своей ветке. Из 15 тысяч строк около трёх тысяч приходится на HTML-фикстуры, то есть сохранённые страницы Javadoc, на которых гоняются тесты. Читать их не нужно. Остаётся около 12 тысяч, и приличная доля из них — сами тесты. Если поделить 12 тысяч строк на подходы по 400, выйдет 30 подходов и 30-45 часов чистого чтения, то есть примерно рабочая неделя, а с учётом тестов, которые читаются быстрее, скорее меньше. Оценка грубая, так как исследованию почти двадцать лет, да и меряет оно, сколько дефектов находит один проход, а не то, когда человек начинает отвечать за систему. Так что одним чтением наши три недели не объясняются, и ниже мы покажем, куда ушло остальное.

С агентами изменения становятся больше и приходят чаще, и в отраслевых отчётах уже видно, чем это оборачивается для поставки. DORA — ежегодное исследование Google о том, как команды поставляют софт. По данным DORA 2024, рост использования ИИ на 25% связан с более качественной документацией и кодом и с более быстрым ревью. Отдельно, по мере роста внедрения ИИ, пропускная способность поставки (throughput) падала примерно на 1,5%, а стабильность на 7,2%. Это корреляция по опросу, а не эксперимент, но авторы прямо пишут, что без маленьких порций изменений и надёжных тестов ускорение разработки до поставки не доходит. Год спустя, в DORA 2025, связь ИИ с пропускной способностью поставки стала положительной, а со стабильностью так и осталась отрицательной. ИИ там называют усилителем! Что в команде было – то он и усилит, слабые тесты в том числе.

Хуже всего, что ускорение легко переоценить. В эксперименте METR 16 опытных разработчиков решали 246 задач в знакомых им открытых репозиториях, и с ИИ-инструментами им понадобилось на 19% больше времени! При этом после эксперимента они были уверены, что ИИ ускорил их на 20%! Правда, это инструменты начала 2025 года (в основном Cursor с Claude 3.5/3.7 Sonnet), и сейчас на странице исследования висит пометка, что результаты устарели. В феврале 2026 года METR повторила замер: оценка сместилась в сторону ускорения, но доверительные интервалы пересекают ноль, и авторы сами называют новый сигнал ненадёжным — часть разработчиков просто отказалась работать без ИИ. Так что те 19% сегодня ничего не доказывают. Нам здесь интересен другой эффект того эксперимента: ощущение скорости легко расходится с реальной скоростью.

Где у второго таймера финиш

Сгенерированный код может собираться, проходить тесты и выглядеть вполне разумно. И всё равно рано или поздно в нём случится баг, и кто-то должен будет его чинить без агента под рукой. Момент, когда в команде появляется такой человек, мы называем код-адопшеном (от англ. adoption — «принятие на себя»). Это как передача проекта новому владельцу, ведь мало, чтобы всё работало, — нужно, чтобы кто-то умел это починить (и желательно так хорошо, что ему не понадобился бы дебаггер). Слово, честно говоря, неуклюжее (по смыслу ближе всего английское ownership), но «принятие кода» по-русски слишком похоже на обычное ревью.

Разница между ними простая. Ревью решает, можно ли вливать изменение. Код-адопшен решает, кто будет его сопровождать. 

Проверить, случился ли он, можно по четырём признакам. Если человек действительно понимает систему, он способен самостоятельно сделать следующее, используя агента разве что для навигации по коду:

1. проследить путь данных от входа до результата;

2. объяснить инварианты, то есть условия, которые должны выполняться в каждом устойчивом состоянии системы: до операции, после неё и после сбоя;

3. предсказать, какие сценарии заденет правка;

4. поменять контракт, понимая, что после этого придётся перепроверить.

Зелёная сборка до этой черты не довозит, потому что отвечает только на те вопросы, которые кто-то задал заранее. Например, у нас при переиндексации новое поколение фрагментов (полный новый набор фрагментов источника с общей пометкой) сначала записывается целиком, и только потом удаляется старое. Если запись падает, недописанное поколение откатывается, а старые фрагменты остаются на месте. Зелёная сборка не скажет, проверял ли кто-то это свойство на сбое посреди записи.

Время у нас ушло как раз на такие вопросы.

Почему понадобилось три недели

Дни по задачам мы не засекали, но история коммитов показывает картину довольно точно. Первые три дня мы вместе с агентом собирали первый вариант — это 44 коммита. Следующие полторы недели разбирали код, возвращали то, что агент поменял без спроса, и попутно правили поиск и проверки — ещё 53 коммита. Последние девять дней ушли на поздние правки по всему контуру и повторные проверки — ещё 47 коммитов.

Большой дифф по списку файлов читать бесполезно, это мы поняли быстро. Удобнее пройти путь одной страницы документации. Её режут на фрагменты, поиск находит их по вопросу, а оценщик ставит ответу балл. И на каждом шаге всплывали неписаные правила. Что останется в базе, если обновление упадёт на середине? Снимать ли балл за запрос, который работает, но написан не как в эталоне? И где вообще кончается один прогон (полный запуск всех контрольных вопросов)?

С навигацией агент здорово помогает. Спросишь, где считается балл, и он сразу покажет нужное место. Но его объяснения всё равно приходится сверять с кодом, моделировать сбои на разных этапах и просить подтвердить спорное свойство тестом. Ловушка тут та же, что в эксперименте METR, только с объяснениями. Агент объясняет одинаково уверенно, прав он или нет.

Ещё агентная ветка много чего меняет «попутно», и это тоже надо ловить. Например, на третий день из кода пропала поддержка нескольких версий Jmix, и на следующий день её пришлось вернуть. Формат ответа /api/search агент поменял ещё в первый день, а на третий день ревью мы вернули старый контракт, и новый формат уехал в отдельный /api/v2/search. На второй день ревью из репозитория пришлось убирать скриншоты и выгрузки на 3,5 МБ, которые попали туда вместе с кодом, и отдельно — логи Playwright. А потом почти неделю подряд идёт серия коммитов с названиями вида «Restore … as in main»: так мы возвращали то, что агент попутно поменял без спроса. Мелкими эти находки были далеко не все. Скриншоты, выгрузки и логи Playwright — просто мусор, который надо заметить среди 122 файлов диффа, но совместимость они не ломают. А выкинутая поддержка версий и сменённый контракт /api/search ломали совместимость! С ними ветку нельзя было выпускать, даже если бы кто-то прочитал её за день.

А потом пришли поздние правки. Под конец второй недели ревью порог зачёта стал отдельным полем прогона, а не настройкой внутри конфигурации оценщика. В последний день правила оценщика стали строже наказывать ответы, которые противоречат эталону. Отдельно в эталон добавили сокращённую форму запроса DataManager вроде e.status = :status — тот самый случай из первой части, когда оценщик считал такой запрос неверным JPQL и снимал за него баллы. Всё, что мы к тому моменту уже поняли про смысл балла, пришлось перепроверять.

Тут напрашивается вопрос: “почему бы тогда не нарезать работу на маленькие пул-реквесты?”. Мы думали об этом. Но корпус без нового поиска лежал бы мёртвым грузом, поиск без корпуса нечем было бы проверить, а без контура оценки не отличишь настоящее улучшение от ошибок, которые просто звучат убедительнее. Риски жили на стыках, так что резать поставку мы не стали. Фича-флаг тут помог бы с выкаткой, но не с приёмкой. Корпус за флагом всё равно нечем проверить без поиска. Как мы режем такую работу сейчас, расскажем в практике 2.

Как это делают в Anthropic и OpenAI

Перед той же развилкой стоим не только мы. Компании, которые сами делают агентов, давно гоняют их на длинных задачах, и волшебного правила вроде «одна функция — один пул-реквест» нет даже у них. Зато в двух экспериментах Anthropic видно, как дробить не поставку, а сам процесс работы агента.

В статье Effective harnesses for long-running agents первая попытка собрать приложение одним заходом провалилась. Посреди работы у агента закончился контекст — объём текста, который модель держит в голове за один разговор. Следующая сессия (новый запуск агента, который о прошлом знает только то, что записано в файлах) долго разбиралась, что тут вообще происходило. Рабочая схема выглядела иначе. Сначала агент-инициализатор раскладывал требование на список функций со сквозными шагами проверки. Каждая следующая сессия читала этот список, журнал прогресса и историю Git, поднимала приложение и первым делом гоняла базовый сценарий. Только после этого она брала одну недоделанную функцию — авторы так и пишут: «work on only one feature at a time». А уходя, оставляла репозиторий прибранным и задокументированным, без крупных багов, чтобы следующей сессии не пришлось сначала чинить чужое.

Во втором эксперименте роли разделили ещё сильнее. Агент-планировщик держал спецификацию, агент-генератор писал код, а проверяющий агент (в статье он называется evaluator) смотрел на живой результат через UI, API и базу. Перед каждым спринтом генератор и проверяющий договаривались, что будет считаться готовым, ещё до первой строки кода. И автор честно пишет, что из коробки Claude — слабый проверяющий… Находит настоящие проблемы, а потом уговаривает себя, что это не страшно, и всё равно принимает работу =) 

Придирчивости его пришлось учить отдельно. У нас похожую роль играл Sol. Модель у него была другая, так что помог ли свежий взгляд или другая модель, мы отделить не можем, но отдельного проверяющего мы оставили. В обновлённой версии эксперимента, уже с Opus 4.6 (старшей моделью Anthropic на момент эксперимента), спринты убрали. Модель держала сборку больше двух часов без нарезки. Готовым с первого раза приложение всё равно не было — проверяющий находил дыры, и вышло три раунда Build→QA, из которых второй и третий ушли на доработку.

В Claude Code best practices для нас главный совет такой: перед тем, как считать задачу готовой, отдать дифф на проверку субагенту (сабагент/subagent) — отдельному запуску агента, который не видел переписки того, кто писал код. У OpenAI идея похожая – Codex делает задачу в изолированном окружении и возвращает изменения вместе с логами проверок, а в приложении Codex можно держать несколько агентов в отдельных копиях репозитория и смотреть их результаты до интеграции. В посте Introducing Codex OpenAI прямо пишет, что код агента человек должен вручную просмотреть и проверить до интеграции и запуска. Правда, писали его ещё про исследовательское превью Codex в мае 2025 года. Нам запуск нескольких агентов параллельно не подходил. Куски шли друг за другом, и поиск без жизненного цикла корпуса проверить было нечем.

Общего правила «человек смотрит только в конце» ни у кого из них нет. Между крупными кусками работы есть состояние, которое можно проверить, не перечитывая всю историю рассуждений агента. Мы же оставили приёмку на конец, как привыкли с обычными пул-реквестами. Для агентной ветки такого размера так никто не советует.

Три границы вместо одной

Есть три границы, которые очень легко склеить в одну:

• поставка определяет, что целиком попадёт в main;

• агентная итерация доводит работу до устойчивого состояния (дальше коротко — срез), которое можно поднять, проверить и продолжить без археологии. В main срез попадать не обязан, проходов и сессий может быть несколько;

• точка код-адопшена отмечает кусок системы, который человек уже сопровождает сам.

Совпадать эти границы не обязаны. Наш поиск вполне можно было поставить одним пул-реквестом, но собрать за несколько итераций и принимать по частям, как только очередная часть становилась устойчивой. Мы, как принято с обычным пул-реквестом, совместили точку код-адопшена с поставкой, поэтому второй таймер стартовал только после того, как остановился первый:

Как было:
3 дня — агент пишет, мы просматриваем диффы
3 недели — люди разбираются во всём сразу, на стыках — поздние правки

Как работаем теперь:
итерация 1: жизненный цикл корпуса → проверка → человек принимает
итерация 2: поиск и API → проверка → человек принимает
итерация 3: контур оценки → проверка → человек принимает
финал: один пул-реквест в main, приёмка стыков

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

Шесть практик, чтобы запустить второй таймер раньше

По сути, летняя ветка оказалась для нас экспериментом, получится ли у человека принять агентный дифф такого размера целиком. Не получилось, по крайней мере за разумное время. Записки между сессиями со списком отложенных улучшений (практика 2) и Sol в роли отдельного проверяющего (практика 4) появились ещё на той ветке, только поздно, когда дифф уже разросся. Остальное мы добавили после неё и сейчас так и работаем. Регламентом это пока не стало, и замеров, сравнимых с летними тремя неделями, у нас ещё нет. Коротко практики такие:

1. описать контракт всей системы до первой сессии;

2. резать работу на устойчивые состояния и оставлять записку между сессиями;

3. просить у агента подтверждение, а не отчёт;

4. отдавать проверку отдельному агенту со свежим контекстом;

5. подключать человека сразу после каждого устойчивого состояния;

6. закончить полной интеграционной приёмкой.

1. Описать контракт всей системы до первой сессии

Планировщик, будь то человек или агент, описывает не только экраны и классы, но и сквозные свойства. Раскладку сущностей, экранов, ролей и миграций мы в контракт не писали. В проекте она и так фиксирована. Писали то, чего в этой раскладке нет. Версию корпуса, поведение при неудачном обновлении, границы поискового API и смысл метрик. Рядом с каждым свойством сразу пишется, чем его проверить: тестом, командой, трассировкой или ручным сценарием. План при этом общий на весь поиск, и обещать, что каждый пункт можно выпустить отдельно, он не обязан.

2. Резать работу на устойчивые состояния

Срезы мы держим стеком веток: каждая следующая отходит от предыдущей, а в main уходит один итоговый пул-реквест. Бросать такой стек на три недели нельзя: весь стек перекладывают на свежий main одним движением и только потом смотрят разницу среза с родительской веткой, а не накопленные 12 тысяч строк. В нашем случае состояний напрашивалось три: жизненный цикл корпуса, поиск с API и контур оценки (и нет, это не обычное разделение, ведь при разработке с ИИ половина фич может появиться уже на ходу, агенту добавить их легко). Пользователю результат был бы виден только после третьего, но работать должно каждое. Качество поиска без контура оценки не измеришь, а вот его инварианты проверить можно и раньше.

Между состояниями агент оставляет хэнд-офф — короткую записку для следующей сессии. Удобно держать её в репозитории, а правило «прочитай записку перед началом работы» прописать в AGENTS.md (файле с инструкциями для агента в корне репозитория). Мы остановились на шести полях, потому что дневник на несколько страниц тут только мешает:

Цель итерации:
Изменённые контракты и инварианты:
Подтверждения и фактический вывод команд:
Что сознательно не делали:
Известные риски:
Следующий безопасный шаг:

Новая сессия читает записку и историю, поднимает приложение и гоняет базовый сценарий уже принятого среза. Для корпуса это переиндексация одного источника, после которой в хранилище остаётся одно полное поколение. Проверять ответ /api/search в этой итерации рано, это сценарий следующего среза. Если сценарий уже сломан, дальше сессия не идёт.

И ещё одна привычка, которую мы выработали по ходу ветки. Полезные улучшения за рамками итерации агент не делает сразу, а записывает в отдельный список задач. Правильное изменение, сделанное не вовремя, всё равно раздувает поставку, и потом его приходится выпиливать (те самые «Restore … as in main»).

3. Просить подтверждение, а не отчёт

Задача «проверь переиндексацию» оставляет агенту слишком много свободы, и в ответ обычно приходит отчёт о том, как всё хорошо. Лучше дать ему проверяемое свойство и заранее договориться, что будет считаться опровержением. Для той же переиндексации это выглядит так:

Инвариант: после завершения или сбоя переиндексации у источника есть полное поколение фрагментов — старое или уже записанное новое
Контрпример: запись нового поколения оборвалась, а недописанные фрагменты не откатились или старые удалили раньше времени
Подтверждение: тест роняет запись и проверяет, что старые фрагменты на месте, а обрывков нового поколения нет
Область изменения: запись и удаление фрагментов одного источника

Нет подтверждения — задача не закрыта. Фраза «код выглядит корректно» подтверждением не считается!

Задание генератору мы формулируем так же, через одно свойство, а не через название модуля. Примерно так:

До изменения кода проследи текущий путь данных, назови затронутые контракты и предложи проверку, которая упадёт при нарушении свойства.

После реализации запусти целевую проверку и базовый E2E, покажи фактический результат и перечисли всё, что осталось за границей этой итерации. Не объявляй готовым весь продукт.

Итерация при этом может задеть и несколько пакетов, и пару таблиц. Размер итерации меряется не строками, а тем, можно ли однозначно сказать, выдержала система проверку или нет.

4. Отдать проверку свежему проверяющему

Проверяющему агенту дают спецификацию, дифф текущей итерации и команды проверки. Переписку генератора с автором не дают, и в этом весь смысл. Другая модель для этого не обязательна. Новая сессия той же модели с чистым контекстом и своим промптом уже не тащит за собой допущения генератора.

Проверку, которой закрывается итерация, фиксируют ещё до работы генератора, и проверяющий запускает её сам, а не верит чужому логу. Инструменты ему нужны те же, что генератору. У нас в AGENTS.md агенту прописано проверять каждый изменённый файл инспекциями IDE через MCP (протокол, по которому агент вызывает внешние инструменты; в проекте на Джеймикс среди них есть и проверки, специфичные для платформы), а экраны проходить в браузере через Playwright. Такой сигнал идёт от инструмента, а не от мнения модели. Логи, скриншоты и выгрузки прогона в коммит не входят: если они попали в дифф, это тот же мусор, что мы вычищали на ревью, а не часть проверки. Полный набор тестов проверяющему здесь гонять необязательно, он понадобится в итоговой приёмке. Зато сверх целевой проверки он ищет сценарий, которого в тестах ещё нет. Для интерфейса проходит пользовательский путь, для API вызывает ручку и сверяет ответ с контрактом, для данных смотрит состояние до операции, между шагами и после.

От него ждут одного из трёх ответов. Воспроизводимый контрпример, подтверждение, что свойство выдержало проверку, или честное NOT VERIFIED с пометкой, какого сигнала не хватило. Исправления — потом. Если разрешить проверяющему сразу чинить, он быстро превращается во второго генератора и начинает дописывать код вместо проверки.

5. Подключать человека сразу после устойчивого состояния

После проверяющего агента к тому же срезу приходит человек и проходит по четырём признакам код-адопшена из раздела «Где у второго таймера финиш». Лучше, если это будущий владелец модуля, а не тот, кто писал промпты, и время на приёмку стоит заранее поставить ему в календарь, иначе после каждой итерации будет расти очередь непрочитанных срезов. Агентом при этом пользоваться можно, но только для навигации по коду, а не для выполнения этих четырёх действий. Если без агента выполнить их не получается или для этого пришлось перечитывать всю ветку, код-адопшен не случился.

Поздние правки от этого никуда не деваются. Если следующая итерация задела уже принятый контракт, как у нас с правилами оценщика в последний день, сценарий открывают заново и проверяют по диффу. Но возвращаться в знакомое место всё-таки сильно проще, чем видеть его впервые посреди 12 тысяч строк.

6. Закончить полной интеграционной приёмкой

Когда всё собрано, нужен сквозной прогон всего контура, проверка стыков и независимый просмотр итогового диффа. У нас это прогон от загрузки источника до расчёта метрик и отдельно — обновление уже существующего корпуса со сбоями между шагами. Например, сбой загрузки одного UI-примера не должен ронять обновление всего корпуса. Это мы чинили уже по ходу ревью. На чистой установке старых фрагментов ещё нет, поэтому такой прогон покажет сам сбой, но не то, что прежние данные его пережили.

Где схема не помогает

Бесплатной эту схему не назовёшь. План со сквозными свойствами, записки между сессиями и отдельный проверяющий окупаются, когда агент трогает несколько связанных механизмов и дифф уже не читается за один-два подхода по 400 строк. На правке в один экран всё это выйдет дороже самой правки, там обычного ревью хватает с головой. Заметили мы и ещё одно: второй таймер короче там, где код ложится в заранее известную структуру. Сущности и миграции в нашей ветке мы приняли быстрее остального, так как они устроены так же, как в других наших приложениях на Джеймикс (аннотации сущности, changelog Liquibase в привычной раскладке), и ревьюеру в основном достаточно сверить их с образцом, а не восстанавливать замысел. Время ушло на корпус, поиск и оценщик, у которых такой готовой структуры нет. И второй таймер схема не обнуляет. Куски становятся меньше, но читает и понимает их всё равно человек. Если на это нет времени, скорость агента просто превращается в очередь непрочитанных диффов.

Вывод

Свои цифры мы бенчмарком не считаем! Это одна ветка, один поиск и одна команда. Но два таймера, похоже, есть у любой задачи, которую делает агент, и мерить стоит оба. Код, который никто не принял, — это бесхозная часть продукта, и узнаёте вы об этом обычно при первом баге в проде.

Если вы отдаёте агенту задачу, в которой несколько связанных механизмов, вот что мы советуем сделать ещё до первой сессии:

• запишите сквозные свойства системы и то, чем каждое из них проверить;

• договоритесь, после каких устойчивых состояний человек садится принимать код, а не ждёт финального пул-реквеста;

• засеките оба таймера: когда появился рабочий вариант и когда кто-то из команды смог сопровождать его без агента.

Если вы руководите командой, не превращайте второй таймер в ещё один срок. На планёрке по большой агентной задаче достаточно спросить, какое устойчивое состояние в работе и кто по имени принимает его сейчас, а не когда появится пул-реквест. Ответ «поиск целиком, посмотрю в конце» не считается. Пока на второй вопрос ответить некому, статус задачи не «почти готово», а «код есть, владельца нет».

Написать наш дифф за три дня было дёшево, а понимание всё равно заняло три недели. Теперь мы начинаем с плана, где расписаны точки приёмки и у каждой есть владелец, а промпт вроде «собери поиск» пишем уже потом. Похоже, работы у инженеров от агентов не убавилось, она просто переехала из написания кода в приёмку.

С ИИ такие задачи по ходу работы часто разрастаются в два-три раза, и по объёму кода, и по набору фич. Изначально мы собирались сделать только одну из трёх — укороченные нейрослоп-примеры для корпуса. Но в процессе стало понятно, что для нормального результата этого мало.

Повторить замер можно на своём проекте. Каркас корпоративного Java-приложения собирает Студия Джеймикс. Сама Студия второй таймер не сокращала. Быстрее остального у нас прошли сущности и миграции, о которых мы писали выше, а основное время ушло на корпус, поиск и оценщик. Поручите агенту не типовой экран, а стык: сервис с инвариантом, миграцию Liquibase и тест, который падает, если инвариант нарушен. Файлы инструкций для агента лежат в jmix-agent-toolkit, свой AGENTS.md можно начать с них. Первый таймер остановите, когда появится рабочий вариант, а второй — когда сможете пройти по четырём признакам код-адопшена без агента.

А как у вас? Сколько дней агент пишет большую задачу и сколько дней команда её принимает, пока кто-то не сможет чинить её без агента? Расскажите в комментариях. Нам правда интересно сравнить. И отдельно интересно, что у вас лежит в AGENTS.md? Правила под свой фреймворк или общие инструкции?