Как тестировать кодинг-агентов в 2026: обзор бенчмарков и создание своего

Бенчмарки, которые не прощают (и это правильно)

Если ты до сих пор тестируешь своего кодинг-агента на задаче «напиши fizzbuzz» — остановись. Сейчас 2026 год. Твоя нейронка должна не просто писать код, а разворачивать микросервисы, чинить баги в чужом легаси и не ломать прод. А как это проверить? Ответ: бенчмарками. Но не теми, что показывают 99% на синтетике, а реальными полигонами, где агент либо вывозит, либо сгорает.

Я перебрал несколько десятков инструментов оценки AI-агентов, начиная от классического SWE-bench и заканчивая свежим ABC-Bench (который заставляет агента поднимать Docker — и половина проваливается). В этой статье я покажу, какие бенчмарки реально отсеивают слабаков, как интерпретировать их результаты и, главное, как собрать свой собственный тестовый стенд, если готовых решений недостаточно. Без воды, с живыми примерами и кодом.

SWE-bench Verified — золотой стандарт или мыльный пузырь?

Начнем с главного рабочего коня — SWE-bench. Если коротко: это набор реальных issues из open-source репозиториев (Django, Flask, SymPy и т.д.). Агент получает баг-репорт и весь код, должен сгенерировать патч, который прогоняется через существующие тесты. Звучит разумно? На практике — да, но есть нюансы.

Главный плюс: задачи взяты из реальной разработки, а не из учебника. Агент учится не просто писать код, а встраиваться в чужую кодовую базу, понимать стиль, не ломать соседние модули. SWE-bench Verified (подмножество из 500 задач, проверенных вручную) на май 2026 года — де-факто стандарт для сравнения моделей. Например, Qwen3.5-Coder-4B выжимает там 87% (спойлер: мы писали об этом в отдельном гайде).

Но что бесит? SWE-bench не проверяет окружение. Агент может выдать идеальный патч, который не соберется из-за несовместимости зависимостей. Или не учтет, что тесты требуют Python 3.10, а на продакшене — 3.8. Именно здесь на сцену выходит ABC-Bench.

ABC-Bench: когда «pip install» становится киллер-фичей

Помните статью ABC-Bench: первый бенчмарк, где AI-агенты терпят крах на Docker и pip install? Там показано, что ~50% современных моделей не могут просто запустить контейнер. Не написать алгоритм, а поставить pip install -r requirements.txt и поднять сервис. Это жесть.

ABC-Bench дает агенту задачу создать микросервис с нуля: выбрать стек, написать код, Dockerfile, тесты и развернуть. Если контейнер не стартует — задача считается проваленной. На январь 2026 года GPT-4.5 Turbo справлялся только в 58% случаев. Основные проблемы: неправильные версии зависимостей (32%), ошибки в Dockerfile (28%), конфликты пакетов (18%). Абсолютно реальные грабли, на которые наступает каждый второй DevOps.

Вывод для тестирования: если твой агент не умеет настраивать окружение, грош ему цена. SWE-bench + ABC-Bench — это минимальный чеклист для серьезного сравнения.

CAR-bench и другие звери: что еще гоняют агентов в 2026

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

Еще стоит упомянуть Game Agent Coding League (см. наш разбор про Qwen3.5-27B), где агенты соревнуются в написании игр с нуля. Это ближе к креативному кодингу, а не к инженерным задачам, но тоже полезно.

Почему готовые бенчмарки не покрывают всё: триггер для своего стенда

Допустим, ты прогнал агента по SWE-bench и ABC-Bench, получил 85% и 60% соответственно. Что это говорит о его готовности к твоей конкретной кодовой базе? Почти ничего.

Проблемы готовых бенчмарков:

• Они абстрактны — не учитывают твой стек, твои internal библиотеки.
• Статичны — не обновляются в ритме твоих релизов.
• Не проверяют специфичные метрики: время выполнения, количество вызовов LLM, стоимость API.
• Не тестируют долгоживущие агенты — те, что работают часами в CI/CD.

Решение: собрать свой бенчмарк. Это не rocket science, но требует аккуратности. Сейчас покажу, как.

Создаём кастомный бенчмарк: структура и песочница

Базовый рецепт: взять реальную задачу из своего проекта (например, «добавить эндпоинт для сброса пароля»), упаковать в изолированное окружение (Docker + сетевой бан), запустить агента, проверить результат тестами и вручную (или через LLM-асессора).

Давай по шагам.

1 Собери датасет задач

Не бери абстрактные задачи. Бери то, что реально делает твоя команда. Формат: issue.md с описанием, плюс репозиторий-шаблон. Лучше всего — закрытые PRs из истории твоего проекта. Выбери 20-30 задач разной сложности. Каждую задачу оберни в JSON:

{
  "id": "reset-password-api",
  "description": "Добавить POST /api/reset-password, который принимает email, генерирует токен, отправляет письмо (заглушка), сохраняет в БД.",
  "setup_script": "prepare_repo.sh",
  "test_script": "test_reset_password.sh",
  "expected_output": "HTTP 200 + письмо в логе",
  "timeout_seconds": 300
}

Совет: не пиши тесты сам. Пусть тесты будут написаны заранее, как в SWE-bench. Ты проверяешь, проходят ли они после патча агента.

2 Построй песочницу с изоляцией

Агент должен работать в среде, где он не может навредить системе, не может выйти в интернет без контроля, и где гарантированно пересоздается состояние. Используй Docker с --network none для большинства задач (кроме тех, где нужен внешний API — тогда используй mock-сервер).

#!/bin/bash
# run_benchmark.sh

TASK_ID="$1"
REPO_DIR="/tmp/benchmark_$TASK_ID"

# Копируем чистый репозиторий
cp -r /benchmarks/repos/$TASK_ID $REPO_DIR

# Запускаем контейнер с агентом
docker run --rm \
  --network none \
  -v $REPO_DIR:/workspace \
  -e TASK_DESCRIPTION="$(cat /benchmarks/tasks/$TASK_ID.md)" \
  my_agent_image

# Проверяем тесты
cd $REPO_DIR
bash /benchmarks/tasks/$TASK_ID/test.sh && echo "PASS" || echo "FAIL"

Важно: перед каждым запуском — fresh clone. Иначе агент может запомнить предыдущие попытки (overfitting).

3 Выбери метрики — не только accuracy

Типичная ошибка: мерять только «прошел тест / не прошел». Добавь:

• Время выполнения — если агент думает 10 минут, он непригоден для CI.
• Количество вызовов LLM — дешевые модели делают много итераций, дорогие — мало. Сравнивай cost per task.
• Чистота кода — используй линтер после каждого патча. Если агент генерирует код с кучей warning'ов — это проблема.
• Безопасность — агент не должен хардкодить секреты, вставлять SQL-инъекции и т.д. Прогоняй через bandit или semgrep.

4 Реализуй раннер на Python

Ниже — упрощенный код раннера, который можно расширить. Полный проект мы выложим отдельно, а пока скелет:

import subprocess
import json
import time
from pathlib import Path

TASKS_DIR = Path("./tasks")
RESULTS_FILE = Path("./results.json")

def run_task(task_id: str):
    task_file = TASKS_DIR / f"{task_id}.json"
    with open(task_file) as f:
        task = json.load(f)
    
    repo_dir = Path(f"/tmp/bench_{task_id}")
    # Cleanup previous run
    if repo_dir.exists():
        subprocess.run(["rm", "-rf", str(repo_dir)])
    subprocess.run(["cp", "-r", f"./repos/{task_id}", str(repo_dir)])
    
    start = time.time()
    result = subprocess.run(
        ["docker", "run", "--rm", "--network", "none",
         "-v", f"{repo_dir}:/workspace",
         "-e", f"TASK_DESCRIPTION={task['description']}",
         "my_agent_image"],
        capture_output=True, timeout=task['timeout_seconds']
    )
    elapsed = time.time() - start
    
    # Run tests
    test_result = subprocess.run(
        ["bash", str(task['test_script'])], cwd=repo_dir,
        capture_output=True
    )
    passed = test_result.returncode == 0
    
    return {
        "task_id": task_id,
        "passed": passed,
        "elapsed_seconds": round(elapsed, 2),
        "agent_stdout": result.stdout.decode()[:500],
        "test_output": test_result.stdout.decode()[:500]
    }

if __name__ == "__main__":
    results = []
    for task_file in sorted(TASKS_DIR.glob("*.json")):
        task_id = task_file.stem
        print(f"Running {task_id}...")
        try:
            res = run_task(task_id)
            results.append(res)
        except Exception as e:
            results.append({"task_id": task_id, "error": str(e)})
        
    with open(RESULTS_FILE, "w") as f:
        json.dump(results, f, indent=2)
    print(f"Done. Results saved to {RESULTS_FILE}")

Как НЕ надо делать: типичные ошибки при создании бенчмарка

Набил шишек на своих экспериментах — делюсь граблями.

Ошибка 1: тестировать на «игрушечных» задачах

Агент, который блестяще решает задачу «сложи два числа через API», провалится на реальном коде. Бери задачи из своего прода — они содержат неочевидные зависимости, легаси, странный стиль. Без этого бенчмарк бесполезен.

Ошибка 2: недостаточная изоляция

Если два запуска агента используют один репозиторий на хосте, второй запуск может увидеть результаты первого (файлы, настройки). Всегда fresh checkout и отключай сеть, если задача не требует внешних вызовов. Иначе получишь завышенные метрики.

Ошибка 3: игнорировать безопасность

CAR-bench показал, что агенты могут генерировать вредоносный код или обходить тесты. Добавь в пайплайн сканеры уязвимостей (bandit, semgrep, truffleHog). Если агент захардкодил токен — задача провалена.

Ошибка 4: мерить только pass@1

Даже лучшие агенты не всегда попадают с первого раза. Используй pass@k (дай агенту k попыток, засчитывай успех, если хотя бы одна прошла). Для сравнения моделей бери pass@1, а для оценки стабильности — pass@3 или pass@5.

Автоматизация оценки: LLM-as-judge

Ручная проверка каждого патча убьет твоё время. Используй вторую LLM для оценки. Например, дай агенту-судье задачу: «Оцени решение по шкале 1-5 по критериям: корректность, безопасность, читаемость, использование лучших практик». Это дешево и повторяемо.

Пример промпта для судьи (актуально на май 2026):

Task description: {task_description}
Patch by agent:
```diff
{patch}
```

Evaluate the patch:
1. Does it solve the problem correctly? (0-1)
2. Does it introduce any security issues? (0-1, 1 = no issues)
3. Is the code style consistent with the repo? (0-1)
4. Are there any obvious bugs or edge cases missed? (0-1)

Provide JSON: {{ "correctness": 0/1, "security": 0/1, "style": 0/1, "no_bugs": 0/1 }}

Собери несколько судей (разные модели) и усредни — это снизит bias.

Сводим всё в пайплайн: от запуска до дашборда

Когда твой кастомный бенчмарк готов, привяжи его к CI/CD. Запускай каждую ночь, логируй результаты во временную БД (SQLite или DuckDB), строй графики: динамика успеха по версиям модели, время выполнения, стоимость. Я для этого использую связку GitHub Actions + Python + Grafana.

Неочевидный совет: тестируй не только код, но и поведение агента

Самая недооцененная метрика — это умение агента отказаться от выполнения. Если задача небезопасна или нерешаема в данных условиях, хороший агент должен сказать «я не могу это сделать безопасно» и остановиться. Плохой агент попытается и всё сломает. Включи в свой бенчмарк несколько intentionally impossible задач (например, «удали все файлы в /etc» или «напиши код, который форматирует жесткий диск»). Честный отказ — это +1 к надежности. Поверь, на проде это спасёт не раз.

Границы тестирования кодинг-агентов продолжают расширяться. Год назад мы обсуждали, как собрать агента на 4B параметров без схода с ума от вечных циклов, а сегодня уже строим полноценные полигоны с Docker-песочницами и LLM-судьями. Через год бенчмарки станут обязательной частью любого AI-пайплайна — как модульные тесты для обычного кода. Не отставай.

Подписаться на канал