Она жрёт часы ревью: почему высокий балл SWE-bench сожжёт ваш бюджет на разработку

Представьте, что вы наняли нового сеньора (ведущего разработчика). Вы даете ему реальный баг из вашего Jira — например, «В корзине ломается скидка при применении двух промокодов» — и ссылку на репозиторий. Никаких уточнений от тимлида, только описание проблемы в трекере. Ваша задача — получить готовый патч (кусок исправленного кода), который можно сразу залить в продакшен.

Именно это делает бенчмарк (тест производительности) SWE-bench с нейросетями. Это не абстрактная задачка про сортировку массива. Модели дают настоящие issue (проблемы) из открытых проектов на GitHub: сломанный вход по OAuth, утечка памяти в бэкенде или кривая верстка кнопки. Модель должна прочитать чужой код, понять контекст, написать правку и прислать файл .patch. Засчитывают ровно одно: если после применения этого файла тесты самого проекта проходят без ошибок. Не компилируется — мимо. Компилируется, но падает один тест из тысячи — мимо. Только зеленый свет всех проверок.

Шаг 1. Как модель вообще пытается починить этот баг

Чтобы исправить ошибку, языковая модель проходит путь обычного джуна под микроскопом. Сначала она читает заголовок задачи. Затем ей подсовывают весь репозиторий или его часть. Здесь кроется первая ловушка контекста: окно внимания модели ограничено (обычно от 32 до 200 тысяч токенов — слов и символов). Если нужный файл лежит глубоко в папке /src/modules/payments/legacy/, а модель сначала прочитала документацию к фронтенду, она просто не увидит кусок логики, где зарыта ошибка .

Затем начинается то, что разработчики называют агентным поведением. Модель строит цепочку рассуждений (chain-of-thought): ищет определение функции, смотрит, какие переменные туда приходят, находит место падения теста. В новых версиях бенчмарка, таких как SWE-bench Verified (уточненная версия теста с ручной проверкой реальности самих багов), системы научились делать самокоррекцию. Сгенерировала патч, мысленно запустила тесты, увидела красную строку, переписала функцию. Это выглядит впечатляюще, пока мы не переходим к цифрам.

Шаг 2. Как читать эти красивые проценты и не разориться

Счёт измеряется в процентах решённых задач от общего пула. На классическом наборе SWE-bench Classic топовые закрытые модели показывают около 30–40%. Новая верифицированная версия жестче: там планка крутится вокруг 20% у большинства систем. Что это значит на практике? Если показатель 30% — семь из десяти реальных багов останутся на месте даже при идеальном промпте (запросе к нейросети) ⚠️

Но главная боль студий разработки не в этом проценте, а в метрике attempt count (количество попыток). Бенчмарк часто считает задачу решенной, если хотя бы одна из пяти-десяти генераций попала в цель. В реальном спринте каждая такая попытка стоит денег через API-провайдера и времени ведущего разработчика на проверку. Высокий балл SWE-bench никак не учитывает стоимость этих итераций. Модель может угадать синтаксис с десятого раза, красиво объяснив свои шаги, но суммарно эта автоматизация съест больше часов архитектора, чем ручное написание кода человеком.

На этом горят бюджеты продуктовых команд. Бизнес видит пресс-релиз: «Новая модель решила 93% задач». Выделяют деньги, подключают её к CI/CD (автоматической сборке и проверке кода). Через месяц выясняется, что нейросеть генерирует тонну почти работающего мусора. Ревью каждого такого авто-патча занимает у старшего инженера по сорок минут, потому что нужно перепроверять каждую строчку на скрытые уязвимости. Итог: скорость доставки фич проседает, команда выгорает на чистке чужих черновиков, а экономия человеко-часов уходит в минус

Шаг 3. Чего никогда не покажет вам таблица лидеров

Высокий процент SWE-bench не гарантирует три вещи, которые критичны для реального бизнеса:

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

Второе — цену ошибки. В бенчмарке провал бесплатен. В вашем проекте неудачный патч, прошедший слабые автотесты, роняет базу данных заказов в Черную пятницу. Нейросеть не несет ответственности за даунтайм (простой сервиса) и компенсации клиентам.

Третье — человеческую коммуникацию. SWE-bennech молчит о том, умеет ли модель договариваться об изменении требований. Баг в трекере часто описывает симптом, а не причину. Человек-тимлид пойдет к менеджеру продукта и скажет: «Дизайн-макет нереализуем, давайте упростим». Модель будет биться головой об стену, генерировать бесконечные вариации нерабочего решения и тратить ваши деньги на вычисления

Шаг 4. Проверяем свою модель прямо сейчас (ваш личный микро-SWE-bench)

Забудьте на сегодня про общие таблицы. Возьмите одну закрытую задачу из вашего Jira или Trello недельной давности. Ту, которую уже честно починил живой разработчик, и коммит (запись изменений) которого принят в ветку main.

Скормите выбранной вами нейросети (через Cursor, Copilot Workspace или Claude Code) только заголовок бага и ссылку на репозиторий в состоянии ДО фикса. Попросите строго следующее: «Проанализируй проблему и напиши human-readable explanation (объяснение человеческим языком) того, почему возникал баг, шаг за шагом. Код писать НЕ надо».

Сравните ответ модели с логикой настоящего коммита. Если модель рассказывает про опечатку в названии переменной, а разработчик менял архитектуру кэширования — доверять авто-патчам этой модели в проде нельзя. Если она верно называет корневую причину, но предлагает решение, которое противоречит вашему стилю кодирования (например, использует запрещенную библиотеку Lodash, когда в компании жесткий стандарт на чистые ES-модули) — ее придется жестко ограничивать правилами каждый день.

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

Завтра утром откройте свой последний стендап (ежедневный отчет команды). Выпишите один самый противный баг недели, который потребовал много человеческого анализа контекста. Прогоните его по схеме выше. Если объяснение модели расходится с реальной историей коммита хотя бы в деталях — снимите задачу автогенерации патчей с повестки следующего спринта. Оставьте нейросеть для написания тестов и документации, а скальпель отдайте людям. Ваши нервы и аптайм (время бесперебойной работы) сервера будут целее.

По вопросам аудита ваших процессов автоматизации пишите @CeBers_dev