Следующая большая гонка в ИИ-разработке — гонка харнессов

Совсем недавно выбор ИИ-инструмента для программирования сводился исключительно к выбору модели. Выходит новая версия Claude, GPT, Kimi или DeepSeek — и всем надо срочно проверить её на своём репозитории, решить, переезжать ли на неё. Модели менялись быстрее, чем команды успевали перестраивать рабочие процессы…

В какой-то момент возник не очень удобный вопрос: что именно мы сравниваем — способности модели или качество системы, которая заставляет её работать?

Повод задуматься дала история Revolut. Компания с примерно 2000 инженеров сделала GLM 5.3 на выделенной инфраструктуре моделью по умолчанию для разработки. Claude Code и Codex сохранили для отдельных случаев. Расходы на инференс, по данным Revolut, сократились примерно в десять раз.

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

Что на самом деле произошло в Revolut

13 октября на конференции AI Engineer в Нью-Йорке руководитель направления инфраструктуры Revolut Дэвид Абитбол рассказал, как компания меняла подход к ИИ-разработке.

Коммерческие инструменты оказались дорогими: инженеры берегли токены для сложных задач, а искать требования в Confluence или разбирать тикеты Jira с помощью агента казалось расточительством.

Затем Revolut перешёл к размещению GLM на выделенных GPU. Сегодня около 2000 инженеров обслуживает инфраструктура на 56 NVIDIA B200. Смешанная стоимость, по оценке компании, — около $0,30 за миллион входных и выходных токенов; расходы составляют примерно десятую часть прежнего счёта за сервисы Anthropic и OpenAI. Это экономика конкретного развёртывания, а не универсальная цена открытых моделей.

Revolut также отчитался о сокращении времени написания кода примерно на 60%, а lead time — срока от принятия таски до доставки её в прод — примерно на 70%. Но это внутренние измерения, не контролируемый эксперимент: параллельно менялись инструменты, бюджеты и привычки инженеров.

Зато механизм понятен. Без жёстких лимитов агенту поручают не только код, но и поиск требований, диагностику ошибок, документацию. Растёт не обязательно смышлённость модели — меняется объём работы, переданный системе.

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

Здесь, правда, лучше не смешивать понятия. Инференс-инфраструктура и agent harness — не одно и то же. Но история Revolut показывает общий сдвиг: оптимизировать стали не абстрактное качество ответов, а целостную производственную систему.

Модель как процессор, харнесс, как весь ПК

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

Этот цикл организуется с помощью harness — агентной оболочки.

Одна модель в двух оболочках работает по-разному. Первая просто загружает гигантский фрагмент репозитория с просьбой исправить какой-нибудь баг. Вторая помогает собрать релевантный контекст, проверить гипотезу, увидеть тесты. Веса не меняются — но изменились условия работы.

Возьмём простой пример: пользователь просит устранить превышение лимита одновременных задач в очереди. Агент находит проверку active < limit и исправляет знак сравнения. Выглядит логично. Но если два воркера одновременно прочитали одно и то же значение active, оба могут пропустить новую задачу. Ошибка не в знаке, а в отсутствии атомарного резервирования слота.

Агенту нужно исследовать вызовы функции, воспроизвести конкурентный сценарий тестом, исправить транзакционную логику и перепроверить поведение. Харнесс не думает вместо модели, но определяет, сможет ли она опереться на данные и довести рассуждение до проверяемого изменения.

Конечно, плохую модель никакая обвязка не сделает гениальной. Если она не понимает гонку данных, доступ к терминалу сам по себе её не научит. Но хорошая модель в плохой оболочке тоже легко теряет значительную часть своих возможностей.

Почему длинного контекста и длинного промпта уже мало

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

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

Харнесс решает, какую информацию сохранить, какую повторно получить из репозитория, а какую не показывать модели. Короткое резюме проверенных фактов и путей к файлам бывает полезнее 100 тысяч токенов логов.

На длинных задачах добавляется проблема памяти между сессиями. Без сохранённого плана, изменений и результатов тестов агент после перезапуска начинает расследование заново. Об этом, кстати, писала и Anthropic в материале об эффективных харнессах.

Поэтому развитие харнесса — это всё больше context engineering, работа с состоянием и инструментами, а не соревнование в том, кто напишет самый длинный system prompt.

Мы тоже проверили влияние харнесса!

В Kodik мы подошли к вопросу буквально: чтобы измерить вклад оболочки, нужно зафиксировать модель и задачи и менять только харнесс.

В качестве бенчмарка взяли DeepSWE 1.1, 113 инженерных задач в 91 открытом репозитории. Агент получает исходное состояние проекта и требование; официальный verifier проверяет итоговый патч. Запуски через Harbor: модель и задания одинаковые внутри пары, инструкции и инструменты оболочек — свои.

Получилась такая картина:

Результаты наших сравнительных запусков на DeepSWE 1.1. Пример: Kodik с Luna и соответствующий запуск Codex. Полный отчёт об исследовании — в другом Хабр-материале.

Главный результат — GPT-6 Luna. На одной модели и одних задачах Kodik решил 66 задач, Codex — 44. Разница в 19,5 процентного пункта: на 50% больше успешных решений относительно Codex. Объяснить её более сильной нейросетью нельзя.

С более мощной GPT-6.1 Sol отрыв составил две задачи в нашу пользу. Это ещё не доказывает, что слабые модели всегда сильнее зависят от харнесса: нужны повторы и больше моделей. Но гипотеза понятная: сильная модель может компенсировать часть недостатков процесса, а менее мощной важнее контекст, инструменты и проверки.

Этот выигрыш не всегда бесплатен. С Luna Kodik тратил больше времени и токенов на попытку, но оценочная цена одного решённого задания была на 25% ниже. С Sol — на 19%, с GLM — на 22%. С DeepSeek Harness решили больше задач и быстрее, но успешное решение стоило чуть дороже.

Пользователь покупает не миллион токенов, а работающий патч — с учётом неудачных попыток и времени проверки.

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

Эффективность теперь измеряем в задачах, а не токенах

Раньше было удобно сравнивать цену миллиона токенов или результаты моделей на тестовых наборах. Для агентной разработки обе метрики полезны. Но уже есть потребность в новой, третьей метрике либо комбинация двух прежних.

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

Полезнее стоимость успешного решения: все расходы, включая неудачные попытки, делятся на число проверенных задач. Дополнительно — время, ручные вмешательства, регрессии. В enterprise цена дефекта легко превышает цену инференса.

Именно здесь кейс Revolut пересекается с нашим экспериментом. Дешёвая модель делает автоматизацию доступной в большем числе сценариев. Хороший харнесс повышает вероятность, что эта автоматизация завершится полезным действием.

Первое снижает цену попытки. Второе — себестоимость результата.

Эффекты дополняют друг друга. Рутину можно отдать открытой модели, архитектурную задачу — фронтирной, а выбор делегировать маршрутизатору. Главное — не терять состояние задачи при переключении.

Где пройдёт следующая гонка

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

Это умение работать с большим репозиторием, а не просто принимать большой контекст. Умение сохранять прогресс между сессиями, а не повторять вчерашний поиск. Инструменты, которые надёжно выполняют команды и возвращают диагностируемые ошибки. Проверки, которые не позволяют принять компилирующийся, но неправильный патч. Безопасная работа с файлами, Git и внешними системами; воспроизводимые действия, логи, контроль доступа. Оркестрация нескольких исполнителей там, где параллелизм действительно сокращает путь к результату, а не только увеличивает счёт за токены.

Это менее эффектно, чем презентация модели с миллионным контекстом. Чаще результат собирается из сотен изменений в инструкциях, состояниях, инструментах и проверках.

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

Разве модели перестанут улучшаться?

Нет. Утверждать, что LLM достигли фундаментального предела, преждевременно. Архитектуры, обучение и инференс развиваются, а на сложных задачах разрыв между бюджетными и премиальными моделями всё ещё велик.

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

Плато практической отдачи может наступить раньше конца прогресса моделей — в повседневной работе, где важно, дошла ли задача до рабочего результата.

Мнение Kodik или Вывод

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

Однако сегодня качество ИИ-разработки определяется не только возможностями модели, но и тем, насколько эффективно эти возможности используются. Мы прогнозируем, что всё больше компаний будут выбирать не одну лучшую модель, а оптимальную комбинацию модели и харнесса под свои задачи. Revolut уже демонстрирует экономическую сторону такого подхода, наш эксперимент на DeepSWE — техническую.

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

И мы намерены вступить в гонку харнессов во всеоружии. Запомните этот твит.