Секрет не в размере, а в проверке
До марта 2026 года все знали одну простую истину: чтобы хорошо решать задачи из SWE-bench, нужна огромная модель. Типа Claude Opus, GPT-4o или как минимум Qwen3.5-32B. Меньшие модели, такие как Qwen3.5-14B, считались хорошими помощниками, но не топовыми исполнителями. Их результаты на бенчмарке решений реальных проблем из GitHub были скромнее.
Пока не выяснилось, что разница не в интеллекте, а в цикле мышления. Прямо как у человека – можно набросать код сходу, а можно проверить его и поправить. Второй способ всегда надежнее.
Что такое verify-on-edit и почему это не Rocket Science
Идея до смешного проста. Большинство кодинг-агентов работают по схеме "прочитал задачу – сгенерировал ответ". Стратегия verify-on-edit добавляет один шаг: "проверил сгенерированное – исправил ошибки".
Но не просто мысленно. Агент буквально выполняет код или запускает тесты в изолированной среде, анализирует ошибки и использует их как фидбек для следующей итерации. Это превращает одноходовую модель в итеративного агента, способного к самокоррекции.
Звучит очевидно? Абсолютно. Но до недавнего времени все пытались улучшать результаты через увеличение контекста, тонкую настройку или ансамбли моделей. Просто заставить модель проверить свою работу оказалось самым эффективным апгрейдом.
1 Где брать среду для проверки?
Не нужно разворачивать полноценный CI/CD. Достаточно легковесного контейнера или sandbox, куда можно скопировать код проекта, применить патч и запустить конкретный тест. В 2026 году для этого часто используют инструменты вроде Docker-in-Docker или специализированные sandbox API.
2 Что именно проверяет агент?
Не все тесты подряд. Только релевантные для текущего issue. Агент должен уметь прочитать traceback, понять, в каком файле и на какой строке ошибка, и связать это с изменениями в своем патче. Это критический навык.
Важный нюанс: модель не должна видеть исходные тесты до генерации патча (это было бы читерством). Но после генерации она может запустить их и увидеть результат – успех или провал с конкретными ошибками. Это разрешенный и мощный фидбек.
Пошаговый план: как собрать своего агента с verify-on-edit
В теории все модели умеют "думать шагами". На практике нужно построить конкретный пайплайн. Вот как это выглядит для Qwen3.5, но подход универсален.
- Шаг 0: Подготовка. Убедитесь, что у вас работает Qwen3.5 последней версии (на 04.03.2026 это, например, Qwen3.5-32B-Instruct). Локально его можно развернуть через llama.cpp с правильными настройками или использовать облачный эндпоинт. Производительность критична – итераций будет несколько.
- Шаг 1: Первоначальный анализ. Агент получает полный контекст: описание проблемы, релевантные файлы кода. Его первая задача – не писать код, а понять проблему и наметить план исправления. Промпт должен явно требовать: "Сначала проанализируй, что нужно изменить".
- Шаг 2: Генерация патча. На основе анализа модель генерирует конкретные изменения в коде. Важно: формат должен быть четким, например, unified diff, чтобы его можно было автоматически применить.
- Шаг 3: Применение и верификация. Здесь магия. Ваш скрипт-оркестратор применяет сгенерированный патч к коду проекта в sandbox-среде, запускает целевые тесты и захватывает вывод. Весь вывод (особенно ошибки) передается обратно агенту.
- Шаг 4: Анализ ошибок и корректировка. Это ключевая фаза. Агент получает сообщение: "Твой патч привел к ошибке: [traceback]. Проанализируй эту ошибку и исправь патч." Модель должна связать ошибку со своим кодом.
- Шаг 5: Повтор. Шаги 3-4 повторяются до тех пор, пока тесты не пройдут успешно или не будет достигнут лимит итераций (обычно 3-5). Часто успех приходит на второй-третьей попытке.
Этот цикл превращает односложную генерацию в диалог модели с окружением. Модель учится на собственных ошибках, причем на конкретных, а не гипотетических.
Где собака зарыта: нюансы и типичные ошибки
Казалось бы, все просто. Бери и делай. Но на каждом шаге есть подводные камни, которые сведут на нет весь эффект.
| Ошибка | Последствие | Как исправить |
|---|---|---|
| Sandbox слишком "глухой" | Агент получает только код возврата (pass/fail), без traceback. Без деталей ошибки он не может ее исправить. | Всегда передавайте полный stderr и stdout. Для модели это золотая жила информации. |
| Неограниченное число итераций | Модель может зациклиться, внося бессмысленные изменения и не сходя с места. | Жесткий лимит попыток (3-5). Если не вышло, значит, задача слишком сложна для текущего подхода. |
| Модель "забывает" исходную задачу | В погоне за исправлением конкретной ошибки агент уходит в сторону и ломает что-то еще. | В каждом промпте напоминайте контекст исходной проблемы. Можно прикреплять его как системное сообщение. |
| Использование сырых Qwen3.5 без инстурктов | Базовая модель может плохо следовать инструкциям по итеративному исправлению. | Берите только Instruct-версии. Для сложных агентов рассмотрите специализированные версии, заточенные под код. |
Самая большая ошибка – думать, что verify-on-edit это просто "запусти тесты еще раз". Нет. Это изменение архитектуры агента, где среда выполнения становится частью его когнитивного контура.
Ответы на главные вопросы
Этот трюк работает только с Qwen3.5?
Нет, он универсален. Но Qwen3.5 показал особенно впечатляющий прирост потому, что изначально хорошо понимает код и инструкции. С более слабыми моделями прирост будет, но не такой драматический. С гигантами вроде Claude Opus метод тоже улучшает результаты, но их базовая точность уже высока.
Сколько это стоит? Итерации удорожают работу.
Да, в 3-5 раз больше запросов к модели. Но альтернатива – использовать модель в 10 раз больше и дороже (как Opus). С точки зрения стоимости и скорости, итеративный Qwen3.5 часто выигрывает. Особенно если вы запускаете его локально на эффективно квантованной версии.
Можно ли использовать для продакшена, а не только для бенчмарков?
Абсолютно. Именно так и стоит строить серьезных кодинг-ассистентов. Например, для автоматического исправления багов в вашем репозитории или генерации патчей по описанию. В production этот цикл работает даже лучше, потому что задачи часто более конкретны, чем в SWE-bench.
Почему это не делали раньше?
Делали, но не системно. Ранние подходы были завязаны на ручном промптинге ("проверь свой код"), что не давало реального фидбека. Автоматизация запуска тестов и анализ их вывода – это тот самый недостающий пазл, который встал на место с развитием инфраструктуры sandbox-сред и пониманием, как эффективно давать моделям обратную связь.
Что это меняет в большом picture?
Революция не в том, что Qwen3.5 теперь "такой же умный", как Opus. Революция в том, что эффективность кодинг-агента перестала быть линейной функцией от размера модели. Она стала функцией от качества его цикла обратной связи.
Это открывает двери для более легких, быстрых и дешевых моделей, которые могут решать сложные задачи, если дать им возможность учиться на ошибках. Прямо как джуниор-разработчик, который с хорошим ментором (в виде системы верификации) быстро догоняет сеньора.
Так что не спешите апгрейдить видеокарту для 72B модели. Возможно, ваша 14B модель с правильной стратегией verify-on-edit сделает ту же работу в три раза быстрее и в десять раз дешевле. Просто дайте ей возможность проверить домашку.
