Как измерять coding agents в диалоге

Алексей представляется: больше 13 лет в IT, работал и инженером, и менеджером, долго руководил отделом разработки больше чем на сто инженеров, строил там инженерную стратегию и найм, а сейчас внедряет искусственный интеллект в крупные и средние компании, сделал обучающую программу и написал книгу, которую готовит к изданию на русском и английском. Александру в этой паре статей понравилось сразу несколько вещей: они вышли одновременно, из двух связанных лабораторий — Meta и компании, долю которой Meta выкупила, а её бывший руководитель возглавил там AI-направление, — и при похожей теме сделаны с разных сторон. Идея, соглашаются оба, задним числом очевидная: раньше мерили ситуацию, когда постановку выгружают целиком, агент автономно уходит работать, а в конце проверяют результат, но люди работают с агентами не так. Алексей делится читательским впечатлением: SWE-Together упакован так плотно, что напомнил ему старый хардкорный учебник по алгоритмам, а вторая статья читается заметно легче.

Дальше участники разводят понятия. Single turn — это гигантский промпт, после которого просто ждут, справилась модель или нет, причём справилась в заранее ожидаемом виде. Алексей замечает, что мечта закинуть один промпт и сразу получить результат чаще живёт у бизнеса, далёкого от техники, а инженеры уходят в обратное искажение и заходят слишком итеративно. Multi-turn — это когда агенту отвечают по чуть-чуть, разблокируют его и подкидывают требования по ходу. В первой статье, вспоминает Алексей, разбираются случаи, когда топовые лаборатории вообще перестают участвовать в бенчмарках: агент реально решает задачу, но проверка смотрит слишком узко и не засчитывает правильное решение, полученное другим путём. Отдельно Александр просит аудиторию придумать хороший русский термин для single turn — одноходовый и одношаговый звучат криво — и обещает автору удачного варианта отдельный эфир.

SWE-Together построен снизу вверх: из реальных сессий собрали чуть больше сотни воспроизводимых задач. Александр разбирает воронку по слайду: у сессии должно быть достаточно взаимодействий и действий, чтобы было видно, что работал агент, а не человек; задачу нужно уметь воспроизвести и оценить; под неё надо собрать окружение с верифаером. Это сложная инженерная работа, и она же объясняет, почему больше 99% реальных сессий выбрасывается. Выборка получается очень чистой, но не случайной: если задача требует знания CI/CD или интеграции с внешней системой, её просто не меряют, и непонятно, на какую генеральную совокупность обобщать результат. Алексей спрашивает, почему Meta с её объёмом собственных данных собирала open source; Александр отыгрывает другую сторону — на внутренних данных бенчмарк нельзя было бы интерпретировать вне контекста самой компании. Оба хотели бы увидеть ту же методологию на внутренних задачах хотя бы опубликованной.

SWE-INTERACT идёт сверху вниз: 75 задач, по 25 из трёх готовых бенчмарков — названия в субтитрах разобрать трудно, — причём два фреймворка из трёх авторам свои, а верификаторы остаются исходными. Отсюда то, чего нет у Meta: одноходовый бейзлайн, относительно которого видно, насколько выдача информации частями деградирует агента. Требования раскрывает придирчивый сеньор-микроменеджер — одна из user-персон, которые авторы выделили кластеризацией сессий; он подбрасывает точные, директивные, но неполные инструкции. Симуляторы устроены по-разному: у Meta он видит траекторию действий агента, что ближе к человеку, наблюдающему за отчётами в консоли; в SWE-INTERACT у симулятора есть shell, он грепает файлы и смотрит дифы — так человек не успевает, и участники предлагают ограничить его когнитивную пропускную способность, иначе это уже отношения агента с агентом. Александр напоминает про полувековую экономическую задачу принципала и агента: заказчик платит за результат, исполнитель хочет вознаграждения за активность и норовит прокопать не всю траншею, а начало и конец, потому что проверяют обычно их. Алексей добавляет, что за эту задачу, кажется, дали Нобелевскую премию 2016 года, доказав, что оптимально она не решается.

В SWE-Together оценку разложили на три оси: финальная корректность, сохранение исходного intent и user correction — число подруливаний пользователя. Александр говорит, что такого разложения раньше почти не встречал: обычно бенчмарк отвечает решено или нет, иногда со степенью корректности через LLM-судью. Главный результат: сильным моделям нужно меньше коррекций, коэффициент связи почти −0,92. Алексей переводит это в деньги: user correction — это стоимость времени человека, ведь заранее не знаешь, какая именно задача сделана неправильно, и не проверять нельзя; чем меньше коррекций, тем раньше можно переключиться на другое. В статье, жалеет он, нет сопоставления стоимости внимания инженера со стоимостью модели. Александр вспоминает отчёт Cursor, вышедший, по его памяти, в апреле или мае: одна из моделей там была примерно в восемь раз дешевле моделей GPT и раз в шестнадцать дешевле Opus, уступая всего 3–5 процентных пунктов, — но мерили только одноходовый режим.

В SWE-INTERACT и Opus 4.8, и GPT-5.5 в одноходовом режиме были почти вдвое сильнее: при постепенном раскрытии требований успешность падает примерно вдвое, шагов становится до четырёх раз больше, а стоимость растёт примерно в 3,5 раза. Sonnet, по памяти Алексея, почти не пострадал — около 27% против 24–25%, — откуда его практический вывод: если вы всё равно микроменеджите агента, экономьте на моделях. Больше всего просели frontier-модели, дообученные долго работать над одной задачей: бенчмарки просили оптимизировать именно это. У самых новых моделей он видит оверинжиниринг: без явно проговорённого минимума ожидаемых изменений агент делает лишнее. Среди неуспешных траекторий 34% — техническая ошибка реализации, дальше идут забытые требования, хотя GPT-5.5 не забывала их больше чем в 90% случаев. В финале Алексей сводит всё к экономике проверки: ИИ удешевил производство кода, но не его проверку, и час вашего внимания на 500 строк никуда не делся, потому что правдоподобное от правильного не отличить, пока не проверишь.