Claude Code написал поиск за 3 дня, а принять код команде Jmix удалось за 3 недели

Агенты быстро пишут код, но человеку всё равно нужно его прочитать, понять и взять на себя. Команда open-source платформы Jmix описала это на собственном опыте. Новый поиск и индекс для ИИ-ассистента они написали за три дня вместе с Claude Code. Чтобы в команде появился человек, готовый отвечать за результат, понадобилось почти три недели.

Два таймера вместо одного

Сам ассистент перед ответом ищет фрагменты документации в векторной базе. Команда добавила туда карточки классов из Javadoc и нарезала документацию на короткие законченные примеры. Качество проверяет контур оценки: 74 контрольных вопроса, ответы на которые оценивает модель-судья.

Первый вариант кода писал Claude Fable 5, отдельные куски независимо перепроверял GPT-5.6 Sol. Получился дифф на 122 файла и почти 15 тысяч строк. Авторы заранее рассчитывали на два-три дня ревью. Каждое изменение они видели, агента можно было спросить о любом решении. Но просмотреть дифф и понять его настолько, чтобы отвечать за него без агента, оказалось разными вещами.

Команда описывает это как два таймера. Первый идёт, пока не появится рабочий код, и остановился за три дня. Второй идёт, пока в команде не появится человек, способный починить систему по памяти. Этот момент авторы называют код-адопшеном, по смыслу это ownership. Признаки такие: человек проследит путь данных от входа до результата, объяснит инварианты, предскажет, что зазаденет правка, и поменяет контракт, понимая, что придётся перепроверить. Зелёная сборка этого не гарантирует, потому что отвечает только на заранее заданные вопросы. Например, проверил ли кто-то, что при сбое посреди переиндексации старые фрагменты останутся на месте?

Куда ушли три недели

Скорость чтения объясняет лишь часть. По данным SmartBear и Cisco, за подход стоит смотреть 200–400 строк за 60–90 минут. Из 15 тысяч строк около трёх тысяч занимают HTML-фикстуры, которые читать не нужно. Остаётся примерно 12 тысяч, то есть 30 подходов и 30–45 часов чтения. Это около рабочей недели, а тесты читаются быстрее. Авторы признают, что оценка грубая, а исследованию почти двадцать лет.

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

По истории коммитов: 44 коммита за первые три дня, потом 53 за полторы недели разбора и ещё 47 за последние девять дней.

Контекст из отраслевых данных такой. По DORA 2024, рост использования ИИ на 25% связан с лучшей документацией и более быстрым ревью, но пропускная способность поставки падала примерно на 1,5%, а стабильность на 7,2%. Это корреляция по опросу, а не эксперимент. В DORA 2025 связь с пропускной способностью стала положительной, со стабильностью осталась отрицательной. В эксперименте METR опытные разработчики с ИИ тратили на задачи на 19% больше времени, но считали, что ускорились на 20%. Инструменты там были начала 2025 года, и повторный замер в феврале 2026-го оказался статистически ненадёжным.

Что команда делает теперь

Главная идея — различать три границы. Поставка определяет, что целиком попадёт в main. Агентная итерация доводит работу до устойчивого состояния, которое можно поднять и проверить. Точка код-адопшена показывает, какой кусок человек уже сопровождает сам. Раньше команда совместила их в одном большом пул-реквесте, и второй таймер стартовал только после первого.

Теперь работу режут на три среза: жизненный цикл корпуса, поиск с API, контур оценки. Каждый срез проверяется и принимается человеком до следующего. Срезы идут стеком веток, а в main уходит один итоговый пул-реквест, где проверяют только стыки. Например, что после неудачной переиндексации поиск по-прежнему отдаёт старое поколение данных.

Шесть практик: описать контракт всей системы до первой сессии, резать работу на устойчивые состояния и оставлять записку между сессиями, просить у агента подтверждение вместо отчёта, отдавать проверку отдельному агенту со свежим контекстом, подключать человека после каждого среза и закончить полной интеграционной приёмкой. Схожие идеи есть в экспериментах Anthropic с длинными задачами агентов и в рекомендациях Claude Code по проверке диффа субагентом.

Ограничения

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