Как выбирать AI-среду с помощью SWE-bench Verified

Высокое место в SWE-bench Verified дает право включить AI-среду в короткий список, но не дает основания оплачивать годовой тариф. Этот тест хорошо отвечает на узкий вопрос: может ли конкретная связка модели и агентского контура исправлять отобранные задачи из открытых Python-репозиториев так, чтобы контрольные тесты прошли. Бизнес обычно покупает другую способность: довести изменение в своем стеке до проверяемого результата, не повредить данные и оставить работу в состоянии, которое примет команда.

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

Что именно измеряет SWE-bench Verified

SWE-bench Verified измеряет успешность патча для 500 задач, которые инженеры проверили на разрешимость. Каждая задача привязана к реальному issue, репозиторию и базовому коммиту. Система получает описание проблемы и код, генерирует патч, после чего стенд применяет его в изолированной среде и запускает тесты. Метрика Resolved показывает долю задач, где патч прошел условия проверки.

Это заметно полезнее упражнений на одну функцию. В статье SWE-bench, опубликованной на ICLR 2024, авторы объясняют исходную конструкцию теста: задачи собрали из GitHub issues и связанных pull request в 12 популярных Python-репозиториях. Исправление часто требует найти нужный участок в большом проекте, понять связи между файлами и не сломать существующее поведение. Verified уменьшает исходный набор до человечески проверенной выборки и тем самым снижает число сомнительных или неразрешимых заданий.

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

Официальная документация стенда описывает процедуру без магии: Docker-среда, применение патча, запуск набора тестов, затем статус resolved или unresolved. Такая бинарная проверка сильна там, где поведение хорошо выражено тестами. Она ничего не говорит о понятности интерфейса, удачности продуктового решения, стоимости сопровождения или качестве изменения, которое случайно удовлетворило тестам.

Читать результат полезно в три приема. Сначала проверьте, какой именно набор использован: Full, Lite, Verified и Multilingual отвечают на разные вопросы, а похожее название не делает числа взаимозаменяемыми. Потом установите единицу сравнения, включая агента и ограничения запуска. В конце спросите, насколько задача стенда похожа на работу, за которую вы собираетесь платить. Если один из этих пунктов неизвестен, число остается рекламным ориентиром, а не техническим доказательством.

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

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

Рейтинг сравнивает связку, а не голую модель

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

На официальном сайте SWE-bench есть отдельный выбор Agent. Это важная подсказка для закупщика: сравнивать модели честнее внутри одного агентского каркаса, а продукты нужно сравнивать целиком. В работе вы покупаете не абстрактный интеллект. Вы покупаете доступ к файлам, цикл проверки, управление контекстом, ограничения среды, журнал действий, восстановление после ошибки и способ передать результат разработчику.

Перед чтением таблицы сохраните карточку конкретного результата:

• версия модели и дата запуска;
• название и версия агентского контура;
• набор Verified и число решенных экземпляров;
• лимиты токенов, времени и попыток, если они опубликованы;
• ссылка на воспроизводимый отчет у себя в закупочной документации.

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

Перенос результата заканчивается на границе вашего процесса

SWE-bench Verified не моделирует полный цикл создания продукта, поэтому высокий балл переносится лишь на похожие задачи. В наборе преобладают исправления в зрелых открытых Python-проектах с уже существующими тестами и историей обсуждения. Если ваша ежедневная работа похожа на это, сигнал сильнее. Если команда строит интерфейс на React, сервер на Go, меняет схему PostgreSQL и выпускает мобильный клиент на Flutter, дистанция до теста велика.

Особенно часто смешивают две разные способности. Первая состоит в том, чтобы восстановить намерение автора по issue и существующим тестам. Вторая состоит в том, чтобы превратить неполное бизнес-требование в согласованную архитектуру, миграцию, интерфейс и критерии приемки. Тест в основном проверяет первую. Покупатели vibe-coding среды часто рассчитывают именно на вторую.

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

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

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

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

До первого запуска согласуйте, кто может отвечать на вопросы среды. Один человек должен давать одинаковые уточнения всем кандидатам и записывать потраченное время. Иначе одна система получит получасовую парную отладку, а другая останется без ответа на единственный вопрос, после чего сравнение потеряет смысл.

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

pilot:
  repository_commit: 7f31c2a
  time_limit_minutes: 45
  tasks:
    - setup_and_baseline
    - locate_seeded_bug
    - change_across_layers
    - recover_failed_change
    - handoff_to_reviewer
  forbidden:
    - production_secrets
    - direct_push_to_main
  required_artifacts:
    - plan
    - patch
    - test_log
    - rollback_note

Коммит в примере условный, замените его реальным зафиксированным состоянием. Лимит тоже выбирает команда. Смысл файла в одинаковом старте, а не в конкретном числе минут.

Первое испытание проверяет вход в незнакомый проект

Среда должна самостоятельно поднять проект из чистой ветки, найти инструкции и доказать исходное состояние до правок. Это испытание быстро отделяет аккуратную работу с репозиторием от убедительного чата. Не объясняйте, какую команду запуска сборки выбрать. Дайте доступ к тем же README, Makefile и локальным инструкциям, которыми пользуется новый разработчик.

Задача звучит так: «Подготовь проект к работе, ничего не меняй в поведении, запусти доступные проверки и сообщи, что мешает продолжить». Хороший результат содержит выбранную последовательность команд, версии среды, исходный статус тестов и точное описание блокера. Плохой результат скрывает ошибку установки, меняет зависимости без причины или объявляет готовность после одного удачного запуска линтера.

Попросите сохранить сырой журнал хотя бы для этого короткого набора:

git status
git diff
go test ./...
npm test

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

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

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

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

Второе испытание проверяет локализацию дефекта

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

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

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

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

Провал не всегда означает слабую модель. Иногда агент не индексирует нужную папку, не видит сгенерированный код или прекращает поиск после первого совпадения. Запишите причину отдельно. Тогда закупка поймет, лечится ли проблема настройкой доступа или остается свойством продукта.

Третье испытание проходит через все слои

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

До запуска напишите приемку языком пользователя:

1. Существующие записи продолжают работать без ручного исправления.
2. Новый вариант можно выбрать и затем прочитать через API.
3. Недопустимое значение получает понятную ошибку.
4. Интерфейс показывает сохраненное состояние после перезагрузки.
5. Автоматические тесты закрывают старый и новый путь.

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

После результата просмотрите изменение по слоям. Миграция должна иметь понятный обратный путь или честное объяснение, почему автоматический откат опасен. API не должен молча принимать неизвестные значения. Интерфейс не должен становиться единственным местом валидации. Тесты должны проверять поведение, а не только существование нового поля.

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

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

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

Четвертое испытание заставляет пережить неудачу

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

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

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

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

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

Пятое испытание проверяет передачу работы человеку

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

У этого разработчика есть 20 минут на ответ по существу: что изменилось, почему выбран такой подход, как повторить тесты и где лежит риск. Если без прокрутки диалога ответы не находятся, продукт создает зависимость от своей сессии. Экспорт исходного кода сам по себе не решает проблему, когда вместе с ним не выходят причины и доказательства.

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

Отдельно проверьте владение результатом. Команда должна получить код в привычном репозитории, понятный способ развертывания и возможность продолжать работу выбранными инструментами. Уточните до оплаты, что происходит с проектом, историей и развернутым приложением при смене тарифа или прекращении доступа. Если условия не записаны поставщиком, не додумывайте их по интерфейсу.

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

Оплата зависит от принятой работы, а не от процента

Решение о тарифе должно опираться на стоимость принятого изменения и стоп-факторы, а SWE-bench Verified получает ограниченный вес как внешний сигнал. До пилота назначьте каждой проверке владельца и шкалу от 0 до 2: провал, приемлемо с ручной помощью, принято без существенной переделки. Не усредняйте нарушение безопасности или потерю данных с хорошей скоростью. Для таких событий нужен отдельный запрет на покупку до устранения причины.

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

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

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

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

Для TakProsto я бы провел тот же протокол: отдельно проверил режим планирования, экспорт исходников, снимки и откат, развертывание, работу целевого стека и заявленное размещение данных на российских серверах. Наличие бесплатного, Pro, Business и Enterprise уровней позволяет начать сравнение с малым риском, но переходить на платный уровень стоит только после принятого сквозного изменения и успешной передачи другому разработчику.

Запишите решение одной страницей: версия продукта, пять исходных задач, полученные баллы, стоп-факторы, часы человека и стоимость принятой работы. Рядом сохраните строку публичного рейтинга, которая помогла выбрать кандидата. Через квартал повторите две самые показательные задачи на новой версии. Так рейтинг остается полезным измерительным прибором и не превращается в доверенность на ваш репозиторий.